人与 AI 协作的新工作流

结论

AI 编程不是让 AI 独立完成软件，而是重新分配整条研发链路中的工作。AI 负责高强度执行，人负责目标、边界、关键取舍和最终责任。

AI 改变的是整条研发链路

只把 AI 当成代码生成器，得到的主要是编码环节提速。真正的变化发生在需求、设计、开发、测试、部署和运维的完整链路中：

阶段	AI 适合参与	人必须负责
需求	扩展场景、发现遗漏、整理验收标准	用户价值、业务方向、范围取舍
设计	提供候选方案、比较优缺点、检查遗漏	架构边界、长期成本、关键决策
开发	生成代码、补测试、执行机械性重构	关键路径、异常语义、代码取舍
测试	生成用例、跑回归、分析失败	测试边界、风险等级、放行判断
部署	生成脚本、检查环境、执行标准步骤	上线时机、回滚决策、事故责任
运维	汇总日志、定位线索、提出修复建议	故障定级、业务影响、处置决策

不同环节的自动化程度不同。代码和测试更容易由 AI 主导；需求、架构、上线和故障处置通常只能由 AI 辅助。

AI 的价值不只在编码，而在于参与整条研发链路，并在各阶段承担不同程度的工作。

工作流发生的三处变化

产出物既要给人读，也要给 AI 执行

传统文档主要解决“人能否理解”。团队成员可以结合会议、口头约定和历史背景补全细节，AI 却只能依据当前获得的上下文执行。因此，文档除了说明背景，还要把范围、约束和验证方式写清楚：

产出物	需要补充的内容	解决的问题
需求文档	范围、非目标、业务规则和可验证的验收标准	避免 AI 自行补齐需求或扩大实现范围
技术方案	关键决策、接口契约、异常语义和不可违反的约束	让生成结果与现有架构保持一致
实现计划	任务的输入、输出、依赖、代码入口和完成标准	把大目标转换为可独立执行和验证的小任务
项目规则	AGENTS.md、Skills、Hooks 和权限策略	把高频约定变成执行时约束
验证结果	测试、构建、运行日志和监控信号	为下一轮修正提供可定位的事实

不是所有文档都要写成机器指令。背景、理由和取舍仍然服务于人；只有会影响执行的规则，才需要转换为明确、稳定、可检查的约束。文档因此同时承担项目记录、AI 上下文和执行控制面三种作用。

协作从阶段交接变成持续分工

传统协作常以阶段交付为界：需求完成后交给设计，设计完成后交给开发。人与 AI 的协作更像一个持续循环，AI 在每个阶段都可以参与，但承担的工作随风险变化：

1. 启动前：人定义目标、范围、成功标准和不可自主操作的事项，AI 负责检查材料缺口、发现歧义并提供候选方案。
2. 执行中：AI 负责搜索、生成、重复修改和检查，人在关键决策点处理方案取舍、业务歧义和高风险操作。
3. 产出后：自动检查先过滤格式、类型和测试问题，人再审核业务正确性、长期成本和剩余风险。
4. 交付后：失败原因、Review 意见和运行数据回到下一轮，稳定的经验再沉淀为规则、测试或 Hook。

分工不应按“人写还是 AI 写”划分，而应按风险、可验证性和责任划分。低风险且容易验证的任务可以让 AI 连续执行；影响架构、数据、权限和生产环境的决策，必须保留人工关口。

反馈循环从事后发现变成过程校验

AI 生成速度越快，在错误方向上扩展的速度也越快。如果只在交付前集中检查，一个早期误解可能已经影响多个文件和后续任务。因此，反馈要尽量靠近错误发生的位置：

• 快速反馈：格式检查、静态分析和类型检查，用于立即拦截明显错误。
• 行为反馈：单元测试、集成测试、构建和实际运行，用于确认实现是否符合契约。
• 业务反馈：人工 Review、用户验收和生产监控，用于发现自动检查无法表达的业务和风险问题。

三层反馈共同组成一个可持续收敛的循环：

目标与边界
    ↓
规格与任务
    ↓
AI 执行
    ↓
静态检查 / 测试 / 构建 / 运行观测
    ↓
人工 Review 与风险判断
    ↓
修正、交付、沉淀规则

反馈不仅要告诉 AI“失败了”，还要能定位到具体任务、错误和期望结果。权限负责事前限制，测试与 Hooks 负责过程校验，人工 Review 负责机器难以判断的业务和工程取舍。只有反馈足够快、信息足够具体，AI 执行才能从“快速生成”变成“稳定收敛”。

自动化的真实边界

判断一个任务是否适合高度自动化，可以看三个条件：

1. 范围明确：输入、输出和禁止事项可以写清楚。
2. 标准清晰：测试、构建或业务状态能够验证结果。
3. 存在参照：有旧实现、接口契约、样例或成熟规则可供比对。

结构化迁移、重复 Issue 处理、测试生成和机械性重构通常更符合这些条件。模糊需求消歧、从零设计大型系统、跨团队利益协调和生产责任承担则不适合完全自动化。

能否自动化，不取决于代码量，而取决于范围、验证标准和参考依据是否充分。

单次成功不等于生产可靠

关于“AI 能否自动写大型软件”，乐观案例和失败记录可以同时成立。两者衡量的不是同一件事：

• Demo 证明某次任务能够完成；
• 测试通过证明已覆盖断言没有失败；
• 生产可用还要经过长期运行、异常流量、真实数据和故障恢复验证；
• 可复制性还要求普通团队在不同项目中稳定复现。

因此，判断 AI 工程能力时，不应只看代码量、PR 数或单次完成时间，还要看人工介入、前置准备、失败率、返工量和生产观察周期。

图中的比例和案例属于原材料的阶段性快照，真正可复用的结论是：人仍在循环中，可靠性仍是生产落地的主要瓶颈。

Bun 迁移案例说明了什么

原材料用 Bun 的 Zig 到 Rust 迁移说明大规模 AI 编程。这个案例值得关注，但不能简化成“AI 在几天内从零写出大型软件”。它具备几个重要前提：

• 原有 Zig 代码提供了完整参考实现；
• 团队提前定义了大量翻译规则；
• 代码结构为迁移做过准备；
• 测试套件提供持续反馈；
• 人负责阶段划分、启停和合并决策。

这更接近“工程约束充分的结构化迁移”，而不是“AI 自主完成产品设计和软件建造”。它证明了人机协作在合适场景中的效率上限，但不能直接作为普通项目的效率基线。

案例的重点不是生成了多少代码，而是参考实现、规则、测试和人工决策共同组成了可收敛的工作流。

一条可落地的协作链路

1. 明确目标和边界

写清要解决的问题、不做什么、谁负责最终验收，以及哪些操作必须人工确认。

2. 准备可执行上下文

提供代码入口、业务规则、接口契约、参考实现和验证命令。资料不在于多，而在于相关、可信、可定位。

3. 拆成可验证任务

每个任务都应有清晰输出和独立检查方式。任务越大，AI 越容易在错误方向上连续执行。

4. 设置自动反馈

把格式检查、静态分析、单元测试、集成测试和构建放进执行链路，让错误尽早返回，而不是最后集中发现。

5. 保留人工关口

架构变化、数据写入、权限调整、生产发布和不可逆操作不能只依赖模型自评。人工关口应根据风险设置，而不是所有步骤都逐行审批。

6. 沉淀有效规则

把重复出现的问题写成项目规则、Skill、测试或 Hook。真正有效的工作流会随着项目推进越来越清晰，而不是不断堆积说明文字。

工作流设计比工具技巧更重要

工具熟练度会随着产品迭代贬值，Prompt 技巧也会被模型能力逐步吸收。工作流设计能力更稳定，因为它处理的是目标、分工、反馈和责任。

训练重点不应停留在具体工具和提示技巧，而应转向能够跨工具复用的工作流设计能力。

保留的边界

• AI 参与完整流程，不等于 AI 可以独立承担完整流程。
• 测试通过不等于生产可用，自动验证也不能覆盖全部业务风险。
• 个别高效率案例不能直接换算成普通团队的交付速度。
• 人在循环中不是自动化失败，而是当前可靠交付的必要设计。

人与 AI 协作的核心不是追求“人退出”，而是让机器承担适合机器的执行，让人把精力放在目标、判断和责任上。