我在日常开发中总结的一套 AI 开发流

我目前在参与 mooth.ai 的开发，此前主要做 SG 源安全网关。在这些工程实践中，我也持续使用 AI 辅助开发，并逐步把自己的协作方式整理成了一套流程。

我给这套流程定的目标很具体：降低从需求到结果之间的不确定性，并控制错误被快速放大的风险。

AI 可以很快开始写代码，但一个任务是否做对，还取决于它有没有理解目标、看到当前实现、遵守修改边界，以及拿出足够的验证依据。我希望把这些事情放进日常协作，而不是每次都靠临时提醒。

这篇文章记录的是我目前的做法。它还会继续调整，也没有经过严格的效率量化对比。对我来说，它首先要能帮助自己把真实项目做好。

先把需求变成一个可以判断的结果

接到需求后，我会先让 AI 回答：要解决什么问题，谁会受到影响，完成以后能观察到什么变化。

“优化一下这个功能”很难直接执行。假设要修复列表搜索，我更希望把目标说成：输入关键词后能找到对应记录，清空输入后恢复完整列表，已有筛选条件仍然有效。这个例子是为了说明需求表达方式，并不代表某次实际交付。

接着再看哪些问题必须由我决定。如果两种理解会产生不同的产品行为，就先确认；如果只是已经明确范围内的实现细节，就让 AI 根据代码自行处理。

对于一个很小的修改，这一步可以只有两句话。流程需要帮助理解问题，而不是让清楚的需求重新变得复杂。

用当前事实检查方案能不能成立

需求明确以后，我会让 AI 先只读检查相关代码和依赖，找到实际入口、负责的模块以及直接消费者。历史记录可以帮助定位，但当前实现仍然需要重新核对。

涉及跨系统调用时，还要看接口、数据、权限和目标环境是否支持方案。一个看起来合理的设计，可能依赖尚不存在的字段，也可能假设本地和部署环境完全一样。

我把这一步的结果分成三种情况：

• 已经有证据支持实现路径，可以进入方案确认。
• 缺少关键事实，先说明卡在哪里以及应该去哪里取证。
• 必须做实验才能回答，就先做一个范围明确的最小实验。

尤其是第三种情况，我会把“验证一个假设”和“完成整个功能”分开。实验的结果可能改变方案，没必要提前铺开全部实现。

根据影响决定流程的重量

我会按修改的实际影响，把任务分成 Lite、Standard 和 High Risk。代码行数只能说明改动大小，不能充分说明风险。

一个模块内的局部修复，通常只需要短方案、明确确认和一次定向验证。跨模块、共享接口或复杂依赖的任务，需要写清楚约束、影响和验收方式。涉及部署、数据迁移、认证权限或难以撤销的操作时，还要明确目标版本、检查点和回滚方法。

我确认方案时，关注的是：改什么，为什么这样改，影响哪里，怎么证明有效，以及失败以后怎么办。

批准也有具体边界。如果执行过程中发现需要改变公共接口、扩大目标环境或降低验收要求，就要重新说明变化。已经确认范围内的缺陷修复和等价实现调整，则不需要不断停下来重复询问。

给 AI 足够的上下文，也给任务留下恢复入口

我会用 AGENTS.md 保存经常适用的协作规则，用 Skill 承载具体任务的方法，再通过项目入口定位相关源码和文档。

这些材料按任务需要加载。一次局部修复，通常没有必要重新阅读整个项目的历史。

复杂任务会留下几份简短记录：需求为什么成立、当前事实和约束是什么、批准了哪个方案，以及最后完成了什么。它们的价值在于换一个会话后，仍然能继续推进同一个目标。

我希望记录里保留结论、证据入口、未完成项和下一步。完整聊天、成段日志和多份重复的进度说明，只会增加恢复成本。简单任务则直接在对话中保留这些信息。

实现时控制改动范围，审查时追问复杂度

真正动手前，要确认代码基线，保留已有的无关改动。实现过程中，优先复用现有模块，只修改当前需求需要的部分。

我会特别留意那些“顺便做一下”的改动：重构旁边的代码、增加尚未使用的配置、为未来需求提前抽象。每多加一层，都需要说明它解决了哪个当前问题。

代码审查除了检查正确性，我也会追问几个问题：

• 有没有更简单、行为等价的实现？
• 新增的分支、配置和抽象是否有实际消费者？
• 删除这部分以后，是否仍能满足需求？

这里的简单仍然要保留必要的边界校验、数据保护和明确要求的行为。需要额外审查时，再引入独立上下文，并由执行者核实审查意见；模型之间的认同本身不能证明实现正确。

让验证结果和交付结论对应起来

这是我比较重视的一步：一份证据能说明什么，就报告到什么程度。

例如在 Agent 工程里，工具已注册、服务能发现工具、工具可以直接调用、Agent 实际使用了工具，以及最终业务结果成立，是不同的结论。直接调用成功，不能自动推导出 Agent 会在真实对话里正确使用它。

因此，我会在实现前明确这次任务需要证明到哪一步，再选择对应的检查方式。运行时证据还要能对应到具体版本和环境，避免拿旧结果证明新代码。

验证范围也按风险决定。小修改做能直接证明行为的定向检查；共享契约变化关注直接消费者；部署和数据变更检查目标环境、失败路径与恢复方式。已经通过且相关代码没有变化的检查，不为走流程反复运行。

最后的交付说明要分清：代码完成了什么，自动验证通过了什么，部署到了哪里，还有什么需要人工体验或验收。这样，“完成”才有清楚的含义。

把重复出现的问题变成下一次的改进

任务结束以后，我会再判断哪些经验值得长期保留。

一个反复出现、可能影响未来决策的问题，可以整理成规则、Skill 或排查入口。只发生一次的细节，留在当前任务里就够了。长期记录也需要控制范围，避免相同结论散落在多个地方，后来互相矛盾。

我也会用同样的标准检查流程本身：它有没有减少返工和歧义？有没有让恢复上下文更容易？它增加的确认、文档和检查，是否真的降低了风险？

如果某一步只是在重复已知信息，就应该把它缩短或去掉。

目前，我用这套开发流来分配人与 AI 的工作：我负责目标、关键取舍和最终验收，AI 在明确范围内承担调查、实现与取证。随着项目和工具变化，这个分工还会继续调整。我会把后续真正有用的实践继续写在这里。