开发

为什么需要这个工作流

智能体写坏代码，多数时候不是因为不会写，而是没搞清楚要做什么就开始写。Develop 把一次实现拆成两段：先把目标、验收行为、范围外、假设和方案边界讲清楚，然后停下；只有你在检查点之后发出的行动语言，才允许它动生产代码。之后的纠正、补漏和追问都留在同一个任务里，不需要重新调用。

流程逐阶段拆解

下面每一条规则都取自源仓库里的工作流定义——这就是智能体真正被要求做的事。

1. 01

   一次性发现

   把该读的读完，而且只读一次。

   • 读适用的项目指令和权威需求/设计文档。
   • 检查版本控制状态，保护无关的未提交改动。
   • 读相关实现、测试、调用方和邻近的既有写法。
   • 如果是已有行为本身坏了，转用 Diagnose 生命周期。
   • 证据只收集一次并全程复用，不为了"看起来在工作"重复执行没有变化的命令。
2. 02

   澄清到可安全实施

   只问会改变结果的问题，而且一次问完。

   • 一个问题必须同时满足三个条件才允许提出：答案会改变验收行为；请求本身未决，或权威证据与请求矛盾；契约、权威文档和同类操作的先例都没有解决它。
   • 仓库里查得到的实现事实——字段名、关联关系、辅助函数选择、存储形态——属于调查范围，不能推给你来选。
   • 提问前先清点所有被标为"未定义/未知/有意为之/尚未建立"的行为。"未定义"本身从来不等于"范围外"。
   • 对删除和写操作，未知资源或资源不存在时的结果是硬停问题，不能从成功返回值、缺少先例或相邻的读接口推断出来。
   • 所有独立且合格的问题合并成一批一次问完；只有答案引出的依赖问题才继续追问。
   • 完整的契约会关闭它覆盖的输入域，契约外的输入保持范围外，不用来扩大访谈。
3. 03

   给出检查点

   把最终理解摆到台面上，然后停下。

   • 给出目标、验收行为、范围外、假设和实质方案边界。
   • 内容少时留在对话里；实质需求优先写进项目已有的权威文档，没有适用约定时新建 docs/requirements/<feature-slug>.md，状态 Draft。
   • 首轮请求已经给出完整契约时，就在这一轮创建并核实 Draft，契约外的假设性可选输入不能拖住它。
   • 批准之前不改生产代码、测试和配置——写需求记录是允许的。
   • 给完检查点就结束这一轮。调用 Develop 本身不是编码授权。
4. 04

   批准人工关卡

   只有你的一句明确指令能打开这道门。

   • 只有检查点之后发出的行动语言才算批准，例如"开始实施""按上述方案执行"。
   • 初始请求、澄清问题的回答、"我看过了/明白了"，都不算批准。
   • 获得批准后把需求记录标记为 Accepted 并直接继续，不会要求你再调用一次 Develop。
5. 05

   选定边界与反馈

   决定改动该落在哪里，以及用什么证据证明它。

   • 只有同一领域职责、且应该共同演进的行为才允许复用。
   • 规则放在拥有相关数据和不变式的模块；改动共享行为前先看兄弟调用方。
   • 选择能证明每个行为切片的最高稳定公共缝隙。
   • 回归和有价值的业务行为走红-绿-重构；机械改动、纯展示、配置和框架接线用编译、lint 或集成检查。
   • 新增的稳定行为填上了覆盖缺口时留下聚焦测试，除非它只是仪式，或根本测不出该行为。
6. 06

   实施与加固

   在拥有该规则的边界上做最小改动，只为真实风险加固。

   • 在拥有该规则的边界上做最小且清晰的改动，控制流、副作用、失败和状态转换保持显式。
   • 不引入投机抽象、依赖和配置，也不顺手做无关清理。
   • 保留校验、权限、安全、数据完整性、兼容性、可访问性和无关工作。
   • 只在结果可能变化时才跑反馈命令，绝不对同一状态重复同一条命令。
   • 只为真实风险补测试：输入、数值/时间、集合、状态/生命周期、重复/并发、权限/信任、资源/外部失败、迁移、兼容性。
   • 实施过程中发现实质需求变化，只对齐这个增量、更新检查点，并再次暂停等待批准。
7. 07

   完成与对齐

   每条验收行为都要有证据，文档也要重新变成真的。

   • 重读验收行为，检查 diff 的正确性、安全、归属、可读性、测试敏感度、范围和临时产物。
   • 把每条验收行为标记为已验证、部分验证、未完成或有偏差。
   • 标记 Implemented 之前，把"将会添加""待创建""待补充"这类未来时改写成事实，并写上真实文件与新鲜证据；只改状态不算完成。
   • 只为发生变化的事实更新权威文档；只为跨任务的长期规则更新项目指令文件。
   • 删掉临时诊断代码，并报告剩余缺口。
   • 未获授权不提交、不推送、不发布、不创建外部 issue、不安装依赖、不修改全局配置。

不可绕过的规则

一次真实调用

从你发出的 token 到你拿回的证据，这次对话实际长什么样。

1. 智能体

   读项目规则、Git 状态、现有的导出与权限代码，然后只提一个会改变结果的问题：导出中包含不存在的订单 ID 时应该怎么办？

2. 你

   报错，返回 404。

3. 智能体

   给出检查点——目标、验收行为、范围外、假设、方案边界，创建 docs/requirements/order-batch-export.md（状态 Draft），然后停下。

4. 你

   按上述方案执行。

5. 智能体

   把记录标为 Accepted，在订单模块边界内实现，为 404 分支补一个聚焦测试，跑验证，最后把记录标为 Implemented 并写上真实文件和最新测试结果。

什么时候用它

• 新功能、重构、只补测试，或者可维护性改造。
• 改动会影响产品行为，需要先对齐再动手。
• 任务跨多轮对话，纠正和补漏要保留上下文。
• 你希望在写任何代码之前，有一个明确的批准点。

什么时候改用别的

常见问题