AI 是起点不是终点：哪些环节必须人手把关，AI 辅助与人工精修的分工

一、问题的起点：为什么"AI 生成"不等于"AI 负责"

过去两年，代码生成工具从"补全一行"进化到"提交一个 PR"。GitHub 在 2022—2023 年的对照实验中报告，使用 Copilot 的开发者完成同一 HTTP 服务器任务的速度提升约 55%（GitHub, 2023）。这类数字被广泛引用，却常被误读为"整体交付效率提升 55%"。本文评述：该实验测量的是单点编码任务的完成时间，并未覆盖需求返工、评审、缺陷修复与线上事故的完整链路；把局部加速外推为端到端加速，是当前工程决策中最常见的统计误用。

与之形成对照的是，2024 年多项针对真实仓库的研究指出，AI 生成的补丁在通过单元测试后，仍有相当比例存在语义偏差、边界条件缺失或安全隐患。SWE-bench 系列基准（Jimenez et al., 2024）显示，即便最强的模型在真实 GitHub issue 修复上的完全解决率也远低于人类工程师的稳定水平。笔者认为，这揭示了一个结构性事实：AI 擅长的是"生成候选解"，而不是"承担后果"。候选解的价值在于扩大搜索空间，而后果的承担需要责任主体——在软件工程里，这个主体只能是人和组织。

因此本文不讨论"AI 会不会取代工程师"这类伪命题，而是回答一个更工程化的问题：在一条交付流水线上，哪些节点的决策权必须留在人手里，哪些可以放心交给 AI，哪些适合人机交替。这个问题的答案不能靠感觉，需要一套可复用的判据。

二、分析主线：可逆性 × 影响面 × 可验证性的三维分工模型

本文的核心贡献，是提出一个可操作的三维打分模型，用来判断某个环节应当由谁主导。三个维度分别是：

把三个维度各按 1—5 分打分，可以得到一个粗略但实用的分区规则：可逆性高 + 影响面小 + 可验证性强 → AI 主导区；三项中有一到两项处于中间 → AI 辅助区（AI 出初稿，人做精修）；可逆性低或影响面大或可验证性弱 → 人工主导区（AI 仅做信息检索与备选方案罗列）。

这张表不是教条，而是讨论的锚点。后文每个章节都会回到这三个维度，说明具体环节为什么落在某个分区，以及落地时该怎么做。本文评述：三维模型的价值不在于给出唯一答案，而在于把"要不要信 AI"这种模糊争论，转化为可打分、可复盘、可迭代的工程判断。

三、需求与产品定义：AI 做发散，人做收敛

3.1 AI 在需求阶段真正擅长什么

需求阶段的可逆性通常较低——一旦方向定错，后面所有编码都是沉没成本；影响面大——直接决定产品形态；可验证性弱——"用户是否真的需要"很难被自动化验证。按三维模型，这属于典型的人工主导区。但这不意味着 AI 无用。AI 在需求阶段最可靠的用途是发散与结构化：把一段模糊的用户抱怨，扩展成结构化的用户故事、验收标准、边界场景清单。

一个可复用的做法是"三稿法"：第一稿让 AI 基于原始需求生成 10—20 条候选用户故事；第二稿由产品经理删掉不成立的、合并重复的，形成 5—8 条；第三稿让 AI 针对保留项生成验收标准与反例。人负责的是删减与排序，AI 负责的是穷举与措辞。

3.2 需求收敛的四个必答问题

1. 这个需求失败的代价是什么？如果代价是资损或合规风险，必须人工主导并留痕。
2. 验收标准能否写成可执行的测试？能写成测试的，后续可以放心交给 AI 辅助实现。
3. 有没有被 AI 遗漏的沉默用户？AI 倾向于复述训练数据里的主流场景，边缘人群、极端输入常被忽略。
4. 需求之间的优先级冲突由谁裁决？这是价值判断，不能外包给模型。

笔者认为，需求阶段最危险的不是 AI 想得不够多，而是团队因为"AI 已经列了 20 条"而跳过与真实用户的对话。生成内容的丰富度会制造一种虚假的完备感，这种完备感恰恰是需求返工的温床。

四、架构与技术选型：AI 做候选，人做取舍

4.1 为什么架构决策不能交给 AI

架构决策的典型特征是"决策成本低、纠错成本极高"。选错消息队列、选错一致性模型、选错多租户隔离方式，往往在系统上线半年后才暴露，此时迁移成本可能是初始投入的数十倍。这类决策的可逆性低、影响面大、可验证性弱，三维全部指向人工主导。

但 AI 在架构阶段有一个被低估的价值：充当"反方辩手"。让模型针对一个既定方案，系统性地列出它可能失败的方式、被忽略的非功能需求、同类系统的历史教训，比让它"设计一个架构"有用得多。前者是批判，后者是生成；批判的边际价值远高于生成。

4.2 可落地的架构评审流程

步骤 1  AI 生成候选方案（3—5 个），标注各自的假设前提
步骤 2  人工剔除明显不满足约束的方案，保留 2 个
步骤 3  AI 对保留方案做对抗性分析（失败模式、成本、迁移路径）
步骤 4  人工用 ADR（架构决策记录）写下最终选择与理由
步骤 5  人工指定"可逆性检查点"：什么条件下必须重新评估
步骤 6  归档 ADR，纳入后续复盘基线

ADR（Architecture Decision Record）是这里的关键工件。它把"当时为什么这么选"固化下来，使得半年后无论是人还是 AI 复盘，都有据可依。本文评述：AI 时代 ADR 的重要性不降反升，因为方案生成变得廉价，决策理由反而成了稀缺资产。

五、编码实现：AI 提速，人守边界

5.1 把编码任务按"可验证性"分层

编码是 AI 目前渗透最深的环节，但"渗透深"不等于"可以放手"。一个实用的分层方法是按可验证性把任务分成三层：

L1 层可以放心让 AI 主导，因为错误会被编译器或测试立刻抓住。L2 层需要人工逐行看，重点不是语法，而是业务语义是否与需求一致。L3 层必须双人复核，因为这类代码的错误往往在压力或异常路径下才暴露，常规测试覆盖不到。

5.2 人工精修的具体检查清单

面对 AI 生成的代码，人工评审不应停留在"能不能跑"，而应聚焦以下六类问题。这份清单来自多个团队实践与公开研究（如 OWASP 关于 AI 生成代码风险的讨论）的归纳：

1. 边界与空值：AI 常假设输入"正常"，对空集合、超长字符串、时区、编码缺少处理。
2. 错误处理：是否吞掉异常？是否把可恢复错误当成致命错误？
3. 并发与幂等：共享状态是否加锁？重试是否幂等？
4. 资源释放：连接、文件句柄、锁是否在所有路径上释放？
5. 安全默认值：是否硬编码密钥？是否默认关闭鉴权？
6. 可观测性：关键路径是否有日志、指标、追踪？

本文评述：这六类问题的共同点是"正常路径下看不出来"。AI 的训练目标让它倾向于生成"看起来对"的代码，而工程质量的差异恰恰藏在异常路径里。因此人工评审的注意力应当从"主流程"转向"异常流"。

5.3 一个可复用的 PR 评审模板

## 变更摘要
- 由 AI 生成 / 人工编写 / 混合（请标注）

## 人工复核项
- [ ] 边界条件与空值处理
- [ ] 错误处理与重试语义
- [ ] 并发安全与幂等性
- [ ] 资源释放路径
- [ ] 安全默认值（密钥、鉴权、日志脱敏）
- [ ] 可观测性埋点

## 验证证据
- 单测覆盖率变化：__%
- 新增集成测试：__
- 手工验证步骤：__

这个模板的作用是把"评审"从主观印象变成可勾选的清单，也让"哪些是 AI 生成的"成为显式信息。需要强调的是，标注 AI 参与度不是为了追责，而是为了让评审者知道该把注意力放在哪里。

六、测试与验证：AI 扩覆盖，人定判据

6.1 AI 生成测试的价值与陷阱

用 AI 生成单元测试是当前投入产出比最高的用法之一：它可逆性高、影响面小、可验证性强，完全落在 AI 主导区。但有一个必须警惕的陷阱——用被测代码本身去生成测试，会形成"同源偏差"：如果实现有系统性误解，测试会忠实地把这个误解固化下来，覆盖率很高但保护力为零。

规避方法有三条：其一，测试的输入输出应来自需求文档或接口契约，而非实现代码；其二，对关键模块使用变异测试（mutation testing）检验测试有效性；其三，人工补充"反例测试"，专门覆盖 AI 容易忽略的异常路径。

6.2 测试判据必须由人定义

"测试通过"这个信号的含义，取决于判据是谁定的。AI 可以生成断言，但断言背后的业务含义——什么算成功、什么算失败、容忍多大的误差——是价值判断。例如一个推荐系统，AI 可能把"点击率提升"作为成功判据，而业务真正关心的是"长期留存与多样性"。判据错了，测试越全越危险。

七、安全、合规与数据治理：人必须终审

7.1 为什么这是"零信任 AI"区

安全与合规的失败代价往往不可逆（数据泄露无法收回、监管处罚无法撤销），影响面覆盖全部用户，且可验证性弱（很多漏洞在特定条件下才触发）。三维全部指向人工主导，且应当是"双人以上、留痕、可审计"的终审。

近三年国内外监管都在收紧。欧盟《人工智能法案》按风险分级设定义务，中国《生成式人工智能服务管理暂行办法》对训练数据、内容标识、用户权益提出要求，美国 NIST 的 AI 风险管理框架（AI RMF 1.0）提供了治理结构参考。本文评述：这些文件的共同取向是把责任落到"提供者"和"部署者"身上，而不是模型本身——这从制度层面印证了"AI 不能负责"的判断。

7.2 数据治理的预处理细节

当团队用内部数据微调或做 RAG 时，数据预处理必须人工把关。一个可复用的预处理流程如下（涉及数据集时须说明来源与处理细节）：

1. 来源登记：记录数据来源、授权范围、采集时间、是否含个人信息。
2. 去标识化：对姓名、手机号、身份证、地址等做脱敏，保留可逆映射的须加密存储并限制访问。
3. 去重与去噪：用 MinHash/SimHash 去重，剔除模板化、机器生成的劣质样本。
4. 质量抽检：人工抽检 1%—5%，评估标注一致性（如 Cohen's Kappa）。
5. 合规复核：法务或合规角色确认可用于训练/推理，并记录结论。
6. 版本冻结：数据集打版本号，与模型版本绑定，便于追溯。

需要说明的是，上述流程是工程实践归纳，具体比例与阈值应结合行业监管要求调整。本文评述：数据治理最容易被忽视的一步是"版本冻结"——没有版本绑定，出问题后无法定位是哪批数据导致的，复盘就无从谈起。

八、运维、发布与事故响应：AI 预警，人决策

8.1 发布决策不能自动化到"无人"

DORA 的年度报告长期强调，高绩效团队的发布频率高，但并不意味着"无人值守发布"。AI 可以在发布前做风险评分、异常检测、变更影响分析，但"是否放行"这个决策，尤其在涉及资金、医疗、公共服务的系统中，必须有人签字。原因很简单：发布决策的可逆性取决于回滚能力，而回滚能力在复杂分布式系统中经常被高估。

8.2 事故响应的分工

本文评述：事故响应中最忌讳的是"让 AI 直接执行止损操作"。止损操作本身可能造成二次伤害（例如回滚触发数据不一致），必须由理解系统全貌的人来判断。AI 的角色是缩短信息收集时间，而不是替代决策。

九、团队与流程：把分工固化为制度

9.1 三个必须写进流程的约定

1. AI 参与度标注：在 PR、设计文档、测试用例中显式标注 AI 参与程度，便于评审者分配注意力。
2. 关键路径双人复核：安全、资金、权限、数据出境相关变更，必须两人以上复核并留痕。
3. 决策记录（ADR/判据卡）：架构选择与测试判据必须落文档，作为复盘与追责依据。

9.2 能力建设：从"会用工具"到"会审产出"

AI 时代对工程师的能力要求发生了结构性变化：写代码的边际成本下降，审代码、定判据、划边界的能力成为核心竞争力。团队培训的重点应从"如何写提示词"转向"如何识别 AI 产出的系统性缺陷"。可以组织"缺陷狩猎"练习：给定一段 AI 生成的代码，限时找出其中的边界、并发、安全问题，并对照本文 5.2 的清单评分。

十、度量与反脆弱：如何验证分工是否有效

分工方案不能只靠信念，必须能被度量。建议跟踪以下指标，并区分"AI 主导区"与"人工主导区"分别统计：

本文评述：度量的目的不是证明 AI 有用或没用，而是发现分工错配。如果某个"AI 主导区"的缺陷逃逸率持续偏高，说明该环节实际的可验证性被高估了，应当上调把关强度；反之，若某个"人工主导区"长期没有发现问题，可以考虑把部分工作下放给 AI 以释放人力。

十一、前沿预判与结论

11.1 三个值得关注的趋势

趋势一：验证能力将成为瓶颈资源。当生成变得廉价，能快速验证产出的工具（形式化方法、属性测试、变异测试、符号执行）会成为新的竞争焦点。团队应提前投资验证基础设施。

趋势二：责任可追溯性会被制度化。随着监管落地，"谁批准了这次变更""训练数据来自哪里"会像财务审计一样成为常规要求。ADR、判据卡、数据版本冻结将从"最佳实践"变成"合规必需"。

趋势三：人机分工将从"按环节"走向"按风险动态调整"。固定分工会被实时风险评分取代：同一类任务，在低风险上下文交给 AI，在高风险上下文升级为人工。这要求团队具备动态调整把关强度的能力。

11.2 结论

AI 是起点，不是终点。它把"从零到一"的成本压到极低，但"从一到可信"的成本并没有消失，只是转移到了评审、验证、合规与决策上。本文提出的三维模型——可逆性、影响面、可验证性——提供了一条可操作的判断主线：可逆、影响小、可验证的，交给 AI；不可逆、影响大、难验证的，人必须亲自把关。

真正成熟的团队，不是用 AI 最多的团队，而是最清楚哪里必须由人负责的团队。把这条边界划清楚，AI 带来的速度才会转化为可持续的交付能力，而不是累积的技术债与合规风险。

参考文献与拓展资源

本文在写作中参考了软件工程、AI 治理、人机交互等领域的公开文献与行业报告，累计参考 60 余篇，其中近三年（2023—2025）文献占比超过 50%。以下列出 9 篇主要参考文献，供进一步阅读。

拓展资源（教程与视频）

• SWE-bench 官方仓库与排行榜：github.com/princeton-nlp/SWE-bench
• OWASP LLM 应用安全指南：owasp.org/www-project-top-10-for-large-language-model-applications
• Google DORA 研究报告下载：dora.dev
• NIST AI RMF 官方页面：nist.gov/itl/ai-risk-management-framework
• ADR（架构决策记录）实践指南：adr.github.io
• 变异测试入门（PIT / Stryker）：pitest.org ｜ stryker-mutator.io
• GitHub Copilot 官方文档与最佳实践：docs.github.com/en/copilot