AI 研发交付工作流公开版

阅读索引

这份公开版可以直接发给不了解内部背景的人。HTML 图文版就是当前页面；Markdown 版保留在源稿入口，方便纯文本阅读和复制。

按角色阅读

关键词索引

1. 这套工作流解决什么问题

很多团队使用 AI 写代码后，会很快遇到同一类问题：

• AI 能生成代码，但不一定理解真实业务边界。
• AI 能写测试，但可能只是验证自己刚写出的错误实现。
• AI 能读接口文档，但接口文档、源码和运行态经常不一致。
• AI 能快速改动多个文件，但需求范围、数据契约和验收证据容易断链。
• AI 能说“完成了”，但团队不知道它到底证明了什么。

所以，这套工作流的核心不是“让 AI 更快写代码”，而是把 AI 放进一条可追踪、可验证、可复盘的交付链路里。

一句话概括：

先用第一性原理把需求变成可验证证据，再让 AI 去取证、实现、对抗式验证和复盘。

2. 核心原则

2.1 人负责判断，AI 负责执行和证据整理

AI 适合做：

• 大范围搜索源码和文档。
• 梳理调用链、字段、状态机和边界条件。
• 生成方案、任务拆分、测试用例和交接材料。
• 按现有代码风格实现低风险改动。
• 运行测试、收集日志、汇总证据。
• 把失败沉淀为下一次的防御规则。

人必须负责：

• 业务目标和范围取舍。
• 高风险契约确认。
• 是否接受剩余风险。
• 真实上线判断。
• 生产环境、资金链路和数据修复等不可逆操作。

2.2 源码和运行态优先于二手材料

需求文档、接口平台、截图、会议纪要都很重要，但它们通常不是最终事实源。

推荐事实源优先级：

2.3 实现者不能自证完成

写代码的 AI 或开发者，不应该单独宣布需求通过。

最终判断应来自独立证据：

• 自动化测试报告。
• 真实页面截图。
• 接口请求和响应。
• 订单号、业务单号或关键业务数据。
• 配置修改和恢复记录。
• 独立评审人或测试人员的确认。

2.4 没有证据债隐藏

如果缺少真实数据、缺少业务链路、缺少截图、缺少支付/退款验证、缺少配置恢复，就应该明确标记为部分完成或阻塞，而不是把“测试跑完了”包装成“需求通过了”。

2.5 先回到第一性原理

AI 很容易被相似实现、历史方案、接口文档或局部 bug 带偏。高风险需求进入方案和契约前，要先回到最基本的问题：

• 这个需求真正要改变的业务事实是什么？
• 哪些约束不可变，例如金额、身份、状态机、权限、数据归属、回调和补偿？
• 哪些材料只是线索，不能直接当成最终事实？
• 当前方案是在修根因，还是只是在修表象？
• 还缺哪些负责人决策或运行态证据？

第一性原理不是哲学装饰，而是防止 AI “看起来很懂、其实沿着错误类比一路狂奔”的刹车。

2.6 实现后做对抗式审查

实现完成后，不要只问“正常路径是否通过”，还要主动找事故路径。

推荐用红队视角检查：

• 恶意输入、脏数据、空数据和超大数据。
• 重复提交、重试风暴、网络超时和并发竞态。
• 缓存污染、配置缺失、时区异常和精度问题。
• 多端表现不一致、老版本兼容、灰度和回滚。
• 订单、支付、退款、回调、补偿等高风险链路乱序。

每个风险都要有归宿：要么已有防御和证据，要么进入测试、自动化场景、人工检查点或剩余风险清单。

3. 总体流程

这套工作流可以理解为一个“需求到验证”的闭环：

需求输入
→ 影响面识别
→ 源码和运行态取证
→ 第一性原理门禁
→ 契约收口
→ 实施计划
→ 代码实现
→ 对抗式审查
→ 自动化和人工验收
→ 失败复盘和规则沉淀

主流程仍然是八个交付阶段，但多了两道关键门禁：方案前先反推基本事实，验收前主动攻击自己的实现。每一步都要有明确产物：

4. 阶段一：需求输入

AI 接到需求时，不应该立刻写代码。第一步是把需求结构化。

需要问清楚：

• 用户或业务方想解决什么问题？
• 目标平台是什么：Web、App、小程序、后台、服务端，还是多端？
• 验收标准是什么？
• 哪些内容明确不做？
• 是否涉及订单、支付、权限、登录、配置、报表、通知、风控等高风险域？
• 最终需要证明到什么程度：单元测试、接口验证、真实用户链路，还是资金闭环？

推荐输出一张需求卡：

requirement:
  title: ""
  background: ""
  target_platforms: []
  acceptance_criteria:
    - id: ac-001
      desc: ""
  out_of_scope: []
  risk_flags: []
  expected_evidence_level: ""
  open_questions: []

5. 阶段二：影响面识别

复杂系统里，一个看起来很小的页面改动，可能牵涉多个端、多个服务和多个数据源。

AI 在动手前要先画地图：

• 哪些前端页面会展示这个能力？
• 哪些接口提供数据？
• 哪些服务负责核心状态？
• 哪些配置或后台开关影响行为？
• 哪些测试工具或发布工具只能作为辅助证据？
• 哪些仓库只是参考实现，不能直接照搬？

关键判断：

6. 阶段三：源码和运行态取证

AI 最有价值的能力之一，是在大代码库中快速建立事实链。

取证时要沿着真实链路走：

页面入口
→ 状态管理 / API 客户端
→ HTTP 或 RPC 接口
→ 服务端入口
→ 领域逻辑
→ 数据库 / 缓存 / 消息
→ 返回字段
→ 页面展示或后续状态

取证输出不要只写结论，要写依据：

6.1 第一性原理门禁

源码取证之后，不要马上写方案。先用第一性原理做一次方案审查，尤其是多端、多仓、订单、支付、权限、配置、发布和数据修复类需求。

这一步要输出：

只有这一步能说清楚，后面的契约和计划才不容易建立在错误假设上。

7. 阶段四：契约收口

契约是 AI 研发里最容易出错的地方。

常见风险：

• 接口文档写了字段，但源码没有返回。
• 前端使用了字段，但字段含义没有负责人确认。
• 参考实现有类似逻辑，但订单类型、金额来源、状态机不同。
• 服务端新增字段后，下游依赖的客户端包没有发布。
• 本地构建通过，但测试环境没有部署。

契约收口要回答：

8. 阶段五：实施计划

实施计划不是待办列表，而是风险隔离和协作协议。

计划至少包含：

• 实现顺序。
• 依赖关系。
• 哪些任务可以由 AI 独立完成。
• 哪些任务必须由负责人确认。
• 哪些操作需要人工批准。
• 测试命令。
• 回滚方案。

任务可以分三类：

9. 阶段六：代码实现

进入实现阶段后，AI 应遵守几个约束：

• 复用现有代码风格和架构，不发明一套新抽象。
• 小步修改，保持代码变更可审查。
• 不覆盖用户或其他人的未提交改动。
• 不把无关重构混进需求实现。
• 涉及高风险逻辑时先停下来确认。
• 每次实现后补对应测试或解释为什么暂时不能补。

好的实现交付，不只是“代码改了”，还应该包含：

• 改动摘要。
• 关键文件。
• 测试命令和结果。
• 未验证项。
• 风险和回滚方式。

9.1 对抗式审查门禁

代码实现后、验收前，要做一次对抗式审查。它不是普通 code review，而是主动假设系统会被异常输入、真实环境和未来维护方式挑战。

每个风险至少写清楚：

如果对抗式审查发现高风险缺口，就不能只用本地正常路径测试宣布 PASS。

10. 阶段七：验收验证

验收要分层，不同证据证明不同范围。

推荐最终结论只用三种：

不要用模糊说法代替结论，例如“基本没问题”“应该可以”“测试都过了”。

11. 阶段八：反馈闭环

AI 工作流真正变强，靠的是失败后能沉淀规则。

每次失败都要问：

• 是需求没说清，还是 AI 没追到事实源？
• 是接口契约错了，还是实现错了？
• 是测试没覆盖，还是自动化流水线误报？
• 是环境问题，还是发布链路问题？
• 是否应该补一条自动化测试？
• 是否应该补一条团队规则或 lesson？

复盘输出可以很短，但必须可执行：

failure_loop:
  symptom: ""
  root_cause: ""
  missed_gate: ""
  fix:
    code: ""
    test: ""
    docs: ""
    workflow_rule: ""
  prevention_next_time: ""

12. 推荐的人机协作方式

12.1 给 AI 的好任务

• “帮我从页面入口追到服务端字段来源。”
• “比较接口文档、前端调用和服务端源码的差异。”
• “把这个需求拆成验收标准和测试数据矩阵。”
• “按现有风格补一个低风险字段透传，并加单测。”
• “跑测试并把失败分成环境问题、代码问题、契约问题。”
• “根据这次 bug 写一条下次能防住的规则。”

12.2 不该直接交给 AI 拍板的任务

• “直接设计支付状态机。”
• “直接改生产配置。”
• “直接写数据修复脚本。”
• “直接决定这个需求可以上线。”
• “直接照搬参考项目的订单、金额、回调语义。”
• “测试跑过了就帮我说 PASS。”

13. 常用提示词模板

新需求启动

这是一个新需求：<需求描述>

请先不要写代码。请先输出：
1. 需求目标和目标平台。
2. 验收标准，给每条标准一个稳定 ID。
3. 可能影响的模块、服务、数据和配置。
4. 风险标记：订单、支付、权限、配置、数据、发布等。
5. 需要补充确认的问题。

源码取证

请只做源码和运行态取证，不修改代码。

从用户入口开始，追踪到接口、服务端、数据来源和返回字段。
输出：调用链、关键文件、关键函数、字段来源、分支条件、证据缺口。
不要只给结论，必须给依据。

契约分析

请比较需求描述、接口文档、前端调用、服务端源码和真实响应。

输出字段契约表：
字段名、类型、来源、是否必填、兼容策略、前端使用点、服务端负责人待确认项、验证方式。
如果事实源冲突，请标出冲突，不要自行猜最终口径。

实现前检查

请在修改代码前做实现前检查：
1. 当前工作区是否有未提交改动。
2. 本次只会修改哪些文件。
3. 哪些属于低风险 AI 可执行任务。
4. 哪些需要负责人或人工确认。
5. 测试命令和回滚方式。

第一性原理审查

请从第一性原理出发审查这个需求或方案。

不要先类比历史实现，先列出：
1. 这个需求的基本事实和不可变约束。
2. 金额、身份、ID 映射、状态机、回调、退款、补偿、配置等关键事实的权威来源。
3. 哪些历史实现、接口文档、设计稿或口头假设不能直接继承。
4. 当前方案是否只修表象，真正的根因和根方案是什么。
5. 仍需负责人决策或运行态取证的问题。

最后给出 pass / partial / blocked 结论。

对抗式审查

请对刚完成的实现做对抗式审查。

请站在恶意用户、脏数据、网络失败、重复提交、缓存污染、时区异常、精度问题、配置缺失、多端不一致、支付或订单回调乱序、部署回滚失败的角度，找出可能导致线上事故的路径。

每个风险都要给出：
- 触发路径
- 当前防御
- 缺口
- 可复现验证方式
- 应进入的测试、自动化场景或人工检查点

最后按 pass / partial / blocked 汇报，不允许用实现者本地测试自证需求 PASS。

验收判断

请按 PASS / PARTIAL / FAIL 验收这个需求。

请逐条核对验收标准、测试结果、截图、接口证据、真实业务数据和剩余风险。
缺少目标证据等级时，不要报 PASS。

失败复盘

这次失败现象是：<现象>

请判断根因属于需求、取证、契约、实现、测试、环境、发布还是流程规则。
请给出需要补的代码、测试、文档和下次防御规则。

14. 对外介绍时可以怎么讲

如果只用 1 分钟介绍：

我的 AI 工作流不是让 AI 直接写代码，而是把需求到上线判断拆成一条证据链。
先结构化需求和验收标准，再让 AI 做源码取证，并用第一性原理审查关键假设。
代码实现之后，不由实现者自己宣布完成，而是用对抗式审查、测试报告、真实链路截图、接口数据和业务单据来判断 PASS、PARTIAL 或 FAIL。
最后把失败回流成测试、文档或规则，让下一次 AI 协作更稳。

如果用 5 分钟介绍：

这套流程保留八个交付阶段：需求输入、影响面识别、源码取证、契约收口、实施计划、代码实现、验收验证、反馈闭环。

中间额外加两道门禁：契约和计划前做第一性原理审查，先回到基本事实、不可变约束和权威来源；实现后、验收前做对抗式审查，主动从异常输入、脏数据、并发、缓存、回调乱序和回滚失败等角度找事故路径。

它解决的是 AI 研发中最常见的断链问题：需求不清、事实源不清、接口契约不清、验证证据不清。

我的做法是让 AI 尽量做它擅长的事情，比如搜索、整理、实现、测试和复盘；人保留业务取舍、高风险判断和最终验收。

最终交付不看 AI 说了什么，而看证据：测试是否通过、真实链路是否跑通、关键接口和业务数据是否存在、配置或数据是否恢复、还有哪些风险没有覆盖。

这让 AI 从“代码生成器”变成了“研发交付协作者”。

15. 最终判断标准

一套 AI 工作流是否有效，不看它写了多少文档，也不看它用了多少工具。

只看七件事：

• 需求是否能变成可验证的验收标准。
• AI 的结论是否能追溯到事实源。
• 方案是否回到基本事实和不可变约束。
• 代码改动是否小而清晰。
• 实现是否经过对抗式审查。
• 验收是否有独立证据。
• 失败是否能让下一次更不容易失败。

如果这七件事成立，AI 就不只是提高编码速度，而是在提高交付确定性。