Work · Develop Harness
Develop流程 —人机协同工作
主会话负责决策与任务分派，低模型子会话和 Subagent 负责实现，再用验证证据决定继续、退回或完成。
Evidence Control Room
Project context
项目背景
这是一个面向 A 股业绩点评的投研程序。用户输入股票代码和报告日期，程序从多个数据源收集事实，再由受控 Writer 生成多组件 Markdown 研报。
同步流程的问题
用户点击生成后，只能等待整份报告一次成功或失败。
一个组件证据不足，会让已经完成的内容一起无法交付。
页面刷新或服务重启后，用户无法继续观察原任务。
失败后只能重跑整份报告，不能只重试失败组件。
B 只是内部任务单编号，不是产品名。本案例选择 B，是因为它完整经历了目标、规格、失败测试、实现、两轮独立检查和重新验证。
Flow panorama
流程全景
这张图回答事情按什么顺序发生。模型不是额外步骤，框内标出谁负责；问题出现时，工作会带着证据回到对应环节。
准备
Resume 与代码审计
主会话和 Luna定义
Intent、Spec、Ticket
用户、主会话和 Sol实现
Red 与 Green
DeepSeek检查
Review 与 Verification
Terra 和 Luna交付
UAT、范围审计、提交
用户和主会话
- 审查发现问题回到实现环节，先补失败测试再修复。
- 验证失败进入诊断，复现并确认根因。
- 需求变化回到定义环节，重写行为说明。
- 发现故障进入诊断，先复现再定位。
流程阶段像生产线上的工序，角色则是完成工序的人。主会话负责方向和完成权，DeepSeek 负责写代码，Terra 负责独立检查，Luna 负责协调和整理验证证据。发现问题就回到最早需要补证据的环节，不必从头重做。
Role console
谁来执行
Develop 先判断这一步需要做决定、写代码、独立检查，还是整理大量证据，再选择对应角色。点击角色查看它收到什么、交回什么，以及真实证据是否已经确认。
主会话 / Sol
主会话保留产品方向、任务边界和完成权。它把用户目标变成冻结的任务说明，分派工作，并根据返回证据决定继续、退回还是结束。
- 负责环节
- Intent、Spec、Ticket、Gate、范围审计
- 收到
- 用户目标、当前代码、各角色的结构化报告
- 交回
- 任务说明、通过或退回决定、本地提交
- 写入权限
- 默认不与 DeepSeek 同时写代码
Evidence chain
案例拆解
业务问题很直接：研报任务刷新后不能丢失，已经完成的组件要保留，失败组件可以单独重试。
任务恢复
B 是这次后端改造的内部任务单编号。主叙事使用普通中文，内部标识只放在证据索引中。
确认目标
用户发起研报后可以离开页面再回来；已完成组件不能丢失；失败组件可以单独重试。
| 原来 | 目标 |
|---|---|
| 同步等待整份报告 | 创建后立即获得任务编号 |
| 刷新后无法继续观察 | 断开不影响任务继续 |
| 一个失败阻断全部 | 成功内容保留，失败组件单独重试 |
Acceptance boundary
验收边界
B 完成的是本地后端任务单，不代表整个投研产品已经通过最终验收。
已经证明
- 同步流程的真实问题与任务单边界
- 持久化 Job、SSE、恢复、Retry 和 410 协议
- 两轮独立检查与最终测试数字
- B 结构化状态为 complete
尚未证明
- 前端组件看板通过最终验收
- 整个投研产品已经完成
- 真实生产环境的高并发与长期稳定性
- 745 项测试等同于真实研报内容质量
CONTINUE THE CONVERSATION