# AI 研发交付工作流公开版

> 这是一份可对外分享的 AI 工作流说明。它不依赖任何特定公司、仓库、工具或内部文档，适合给团队成员、合作方、外部评审者或同行理解：如何把 AI 从“写代码助手”升级成“可验证的研发交付协作者”。

## 阅读索引

这份公开版可以直接发给不了解内部背景的人。HTML 图文版用于展示，Markdown 版保留为纯文本阅读和复制版本。

### 按角色阅读

| 读者 | 建议章节 |
| --- | --- |
| 研发负责人 | 第 1、2、15 节 |
| 开发者 | 第 6、8、9 节 |
| 测试 / QA | 第 10、11 节 |
| 产品 / 业务方 | 第 4、14 节 |
| 想直接复用的人 | 第 13 节 |

### 关键词索引

| 关键词 | 位置 |
| --- | --- |
| 事实源 | 第 2.2、6 节 |
| 第一性原理 | 第 2.5、6.1 节 |
| 契约 | 第 7 节 |
| 对抗式审查 | 第 2.6、9.1、13 节 |
| 验收分层 | 第 10 节 |
| 人机分工 | 第 2.1、12 节 |
| 复盘闭环 | 第 11 节 |

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

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

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

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

一句话概括：

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

## 2. 核心原则

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

AI 适合做：

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

人必须负责：

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

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

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

推荐事实源优先级：

| 优先级 | 事实源 | 说明 |
| --- | --- | --- |
| 1 | 真实源码和运行态行为 | 最接近系统真实逻辑 |
| 2 | 测试环境接口响应、数据库状态、日志 | 能证明当前环境实际发生了什么 |
| 3 | 产品需求、设计稿、接口文档 | 说明目标和预期，但可能滞后 |
| 4 | 历史实现、参考项目、旧方案 | 可作为入口，不能直接当成目标契约 |
| 5 | 聊天记录和口头描述 | 只能作为线索，必须落盘或验证 |

### 2.3 实现者不能自证完成

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

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

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

### 2.4 没有证据债隐藏

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

### 2.5 先回到第一性原理

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

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

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

### 2.6 实现后做对抗式审查

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

推荐用红队视角检查：

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

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

## 3. 总体流程

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

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

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

| 阶段 | 目标 | 典型产物 |
| --- | --- | --- |
| 需求输入 | 把模糊需求变成可判断范围 | 需求卡、验收标准、风险标记 |
| 影响面识别 | 知道要读哪些端、服务、工具和数据 | 影响仓库/模块清单、职责说明 |
| 源码取证 | 证明系统现在怎么做 | 源逻辑说明、调用链、字段表 |
| 第一性原理门禁 | 从基本事实和不可变约束重新推导方案 | 事实清单、权威来源、不可继承假设、根因判断 |
| 契约收口 | 统一接口、状态、数据和边界 | 契约表、缺口清单、待确认问题 |
| 实施计划 | 决定先后顺序和风险边界 | 任务清单、依赖关系、回滚方案 |
| 代码实现 | 按计划完成可审查改动 | 代码变更、测试、构建结果 |
| 对抗式审查 | 从事故路径反推缺口和验证归宿 | 攻击向量、现有防御、补测项、人工检查点 |
| 验收验证 | 判断是否真的满足需求 | 测试报告、截图、业务数据、结论 |
| 复盘沉淀 | 让下一次更稳 | 经验规则、补测试、补文档 |

## 4. 阶段一：需求输入

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

需要问清楚：

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

推荐输出一张需求卡：

```yaml
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 最有价值的能力之一，是在大代码库中快速建立事实链。

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

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

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

| 内容 | 示例 |
| --- | --- |
| 文件和函数 | 哪个文件、哪个函数、负责什么 |
| 字段来源 | 字段从请求、配置、数据库还是下游服务来 |
| 分支条件 | 哪些开关、状态、身份会改变行为 |
| 边界场景 | 空数据、异常、取消、重复提交、超时 |
| 证据缺口 | 哪些只能从源码推断，还没运行验证 |

### 6.1 第一性原理门禁

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

这一步要输出：

| 审查项 | 要回答的问题 |
| --- | --- |
| 基本事实 | 这个需求到底改变哪个业务事实？ |
| 不可变约束 | 哪些金额、身份、状态、权限、数据来源不能被简化？ |
| 权威来源 | 哪些结论来自源码、运行态、负责人决策或真实数据？ |
| 不可继承假设 | 哪些历史实现、接口文档、设计稿或口头描述只能当线索？ |
| 根因判断 | 当前方案是在治本，还是只修了最容易看到的表象？ |
| 缺口归宿 | 哪些问题必须进入契约、计划、人工确认或阻塞清单？ |

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

## 7. 阶段四：契约收口

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

常见风险：

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

契约收口要回答：

| 问题 | 需要写清楚 |
| --- | --- |
| 字段叫什么 | 最终字段名、类型、是否必填 |
| 字段从哪来 | DB、配置、下游服务、计算逻辑 |
| 谁是权威 | 源码、接口平台、运行态、负责人决策 |
| 怎么兼容 | 老端、老接口、缺省值、灰度窗口 |
| 怎么验证 | 单测、接口测试、真实链路、截图 |
| 怎么回滚 | 配置恢复、代码回滚、数据补偿 |

## 8. 阶段五：实施计划

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

计划至少包含：

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

任务可以分三类：

| 类型 | 含义 |
| --- | --- |
| AI 可执行 | 低风险适配、样式、文案、测试、fixture、文档整理 |
| 负责人收口 | 金额、订单、支付、权限、核心状态机、数据模型 |
| 人工确认 | 生产配置、真实支付、退款、数据修复、不可逆发布 |

## 9. 阶段六：代码实现

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

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

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

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

### 9.1 对抗式审查门禁

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

每个风险至少写清楚：

| 内容 | 说明 |
| --- | --- |
| 触发路径 | 用户、接口、任务、配置或数据如何触发问题 |
| 当前防御 | 代码、配置、测试或流程里已有哪层保护 |
| 缺口 | 哪些异常路径还没有覆盖 |
| 可复现方式 | 如何用测试、脚本、页面操作或日志证明 |
| 验证归宿 | 进入自动化测试、人工检查点、上线观察还是剩余风险 |

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

## 10. 阶段七：验收验证

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

| 等级 | 证明范围 | 例子 |
| --- | --- | --- |
| L1 单元测试 | 函数或组件逻辑正确 | 价格计算、字段转换、按钮状态 |
| L2 契约测试 | 接口字段和固定数据兼容 | mock 响应、schema、fixture |
| L3 真实接口测试 | 服务端或接口链路可用 | 测试环境 API、数据库状态 |
| L4 用户真实链路 | 用户路径到关键业务节点可用 | 登录、选择商品、提交、截图、业务单号 |
| L5 资金或补偿链路 | 真实支付、退款、回调、补偿可控 | 支付单、退款单、对账、人工窗口 |

推荐最终结论只用三种：

| 结论 | 含义 |
| --- | --- |
| PASS | 目标验收等级的关键证据齐全 |
| PARTIAL | 部分通过，但缺少目标等级证据或有剩余风险 |
| FAIL | 核心验收项失败或无法证明 |

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

## 11. 阶段八：反馈闭环

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

每次失败都要问：

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

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

```yaml
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. 常用提示词模板

### 新需求启动

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

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

### 源码取证

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

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

### 契约分析

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

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

### 实现前检查

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

### 第一性原理审查

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

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

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

### 对抗式审查

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

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

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

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

### 验收判断

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

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

### 失败复盘

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

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

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

如果只用 1 分钟介绍：

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

如果用 5 分钟介绍：

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

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

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

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

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

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

## 15. 最终判断标准

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

只看七件事：

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

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