从 AI 助手到可信交付：AI 辅助编码的工程化思考

这几年，我一直在实际项目里使用 AI 辅助编程。从最早的代码补全、问答和片段生成，到现在让 Coding Agent 读取整个仓库、跨文件修改、执行命令、运行测试，AI 能够承担的工作越来越多，完成任务的速度也越来越快。

但用得越深入，我越觉得，真正值得讨论的问题已经不是“AI 能不能写代码”，而是“AI 写出来的代码，怎样才能进入真实的团队交付流程”。做 Demo、交互原型或者一次性脚本时，生成得快往往就能直接看到收益；可一旦代码要进入商业项目和共享仓库，我们还得继续回答：需求有没有理解对？改动能不能被 Review 和联调？出了问题能不能定位、回滚？最后又由谁根据什么证据决定它可以上线？

这篇文章整理自我最近做的一次内部分享。我不准备比较哪个模型或工具更强，也不想用一个简单的百分比概括 AI 带来的效率变化。接下来，我会结合外部研究、自己的使用记录以及团队协作实践，讨论代码生成之后那些更容易被忽略的问题：任务边界怎样确定，生成结果怎样验证，多人和多个 Agent 怎样协作，以及团队最终凭什么决定一段代码可以被合并和发布。

一、Coding Agent 的能力扩大了，管理边界也要跟着扩大

1. 别再把 Coding Agent 当成一个更聪明的聊天框

早期的 AI 编程助手主要负责回答问题和生成片段，真正接触仓库、执行命令的人还是开发者。现在的 Coding Agent 已经可以搜索项目、修改多个文件、调用终端、运行测试，甚至操作 Git。

这意味着我们需要重新关注三个问题：AI 能接触多大的系统范围？它开始执行前受什么约束？执行以后又由谁根据什么证据判断结果？

微软把管理 Agent 上下文、工具、权限、审批、状态和执行循环的基础设施称为 Agent Harness。这个概念对我很有帮助，因为它把关注点从“模型有多聪明”拉回到了“模型在什么运行环境里工作”。

2. 生成完成和交付完成，是两个完全不同的终点

假设让 AI 给接口增加一个字段。它几秒钟改完代码，本地编译也通过了，这最多只能说明我们拿到了一个候选答案。

真正准备交付时，还需要确认需求是否理解正确、旧客户端会不会受影响、权限和缓存是否同步变化、数据库和多语言是否需要调整、测试有没有覆盖边界、出问题后怎样回退。最后还要有一个明确的人看过这些证据，并愿意承担合并和发布的判断。

所以以后看到“AI 把开发时间缩短了多少”时，我会先问一句：这里测量的是代码生成完成，还是完整交付完成？终点不同，数字的意义也完全不同。

3. 从 Chatbot 到 Agent，变化的不只是交互界面

Chatbot 主要提供解释和代码片段；代码补全开始进入编辑器；Vibe Coding 把自然语言和快速试错放到前面；Coding Agent 则进一步拥有规划、搜索、修改、测试和版本控制能力。

在此基础上，Context 和 Spec 用来补充项目事实、任务边界和验收标准，Agent Harness 管理工具、权限和执行循环。这不是一张严格的产品发布时间表，而是想说明一件事：AI 的影响范围越大，约束、证据和责任也必须同步升级。

Thoughtworks 对 AI-native engineering 的讨论也采用了类似视角：真正的工程能力不只来自模型，还来自 Agent、Context、Spec 和 Methodology 的组合。

4. 新名词很多，但它们解决的问题并不一样

Agentic Coding 关注谁来规划和执行；Context Engineering 关注 Agent 根据什么理解项目；Spec-Driven Development 关注这次到底要做成什么样；Structured-Prompt-Driven Development 则尝试把 Prompt 变成可以版本化、Review 和复用的工程资产。

Agent Harness 解决安全、可控运行的问题；Agent Team System 解决多人和多个 Agent 如何共享事实、分工与集成；AI-native Engineering 则把这些能力放回整个研发组织中考虑。

我现在看到新概念时，通常不会先记定义，而是先问：它补的是计划、上下文、契约、运行控制、协作，还是治理？这样反而更容易判断它在项目里有没有实际价值。相关概念可以继续看 Martin Fowler 网站上的 SPDD 实践文章。

5. Vibe Coding 适合探索，但不能不分风险地接受结果

Vibe Coding 经常被理解成“随便让 AI 写”，其实它更像一种快速试错方式：先用自然语言描述效果，让模型不断生成和修改，尽快获得反馈。周末原型、一次性数据脚本、低风险样式实验都很适合这么做。

这个词最初来自 Andrej Karpathy 的公开讨论。问题不在于这种方式本身，而在于我们是否把同样的接受标准带到了公共 API、数据库迁移、权限安全和多服务联动等高风险任务里。

我不反对 Vibe Coding。我反对的是不看影响面、可逆性和验证能力，就直接接受生成结果。

把能力和边界讲清楚以后，下一步不是马上给出一套流程模板，而是先回到外部证据：AI 在什么条件下真的更快，又为什么有时会把成本推向 Review、CI 和集成阶段。

二、外部研究没有给出统一答案，但给出了边界条件

AI 编程相关的数据很多，方向也经常相反。如果只挑一个数字，很容易得到自己本来就想得到的结论。

我更愿意先看研究对象、样本和指标，再判断它能说明什么、不能说明什么。我们需要寻找的不是一个漂亮的平均提升率，而是哪些条件能把 AI 变成收益，哪些条件会把成本推到 Review、CI 和集成阶段。

1. 先区分研究方法，再看百分比

随机对照实验适合回答明确任务中使用 AI 是否改变结果，但场景往往比较窄；问卷可以了解使用行为和主观感受，却不能直接证明真实交付更快；GitHub 仓库研究更接近真实协作，但会混入任务选择、仓库差异和开发者差异。

厂商案例和创始人观点可以帮助我们了解行业正在尝试什么，但更适合提出假设，而不是直接当作普遍效果的证明。

例如，GitHub Copilot 受控实验、DORA 2025 报告、AgenticFlict 仓库研究和 Cursor 对第三阶段开发方式的判断，证据类型完全不同，不能放在同一个尺度上直接比较。

2. 为什么一项研究快了 55.8%，另一项却慢了 19%

GitHub Next 与 Microsoft 的受控实验让 95 名专业开发者完成同一份 JavaScript HTTP server 任务。允许使用 Copilot 的组，成功完成任务的平均时间从 160.89 分钟降到 71.17 分钟。这里的 55.8% 是特定任务的完成时间减少，不是代码质量提高了 55.8%。GitHub 也发布了对应的研究解读。

METR 的真实仓库研究问的是另一件事：资深开发者在自己非常熟悉的真实开源仓库里使用 AI，是否仍然更快？16 名开发者处理 246 个任务，允许使用 AI 的任务平均反而多花了 19% 时间。METR 后续还发布了实验设计更新，提醒读者不要把单次实验结果简单外推。

两项研究并不矛盾。熟悉度、任务结构、上下文获取和验证成本都会改变结果。AI 是否提速，取决于它省下的生成时间能否覆盖额外的理解、检查和返工成本。

3. DORA：AI 更像放大器，而不是独立变量

DORA 长期研究的不是一个开发者写代码有多快，而是什么技术能力和团队条件能够让软件安全、快速、稳定地进入生产。

2025 年的调查收集了近 5,000 名技术从业者的问卷和 100 多小时定性资料。90% 的受访者表示会在工作中使用 AI，超过 80% 感觉生产力提高，但也有 30% 对 AI 生成代码几乎不信任或不信任。

这些数据并不冲突：使用率描述行为，生产力描述主观感受，信任度描述愿不愿意直接接受代码。一个人完全可能每天使用 AI、觉得自己写得更快，同时仍然不敢在没有检查的情况下把结果合进主干。

DORA 更重要的观察是，AI 的效果像一个放大器。架构解耦、内部平台、自动测试、版本控制和反馈循环成熟的团队，更容易把局部提速转化成交付收益；原有流程混乱的团队，则可能把更多问题更快推向下游。完整结论可以参考 2025 State of AI-Assisted Software Development。

4. AgenticFlict：合并冲突开始变成并发控制问题

AgenticFlict 不是一家工具公司，而是美国内华达大学拉斯维加斯分校两位软件工程研究者构建的一套数据集和合并模拟流程。他们从 AIDev 数据集中提取 Agent PR，还原对应代码状态，执行确定性的 Git merge，并提取冲突文件和细粒度冲突区域。

AgenticFlict 论文收集了超过 14.2 万个 Agent PR，其中 107,026 个能够完成确定性合并模拟，29,609 个出现文本冲突，冲突率为 27.67%，并提取出超过 33.6 万个细粒度冲突区域。

这里必须强调两个限制。第一，27.67% 的分母是成功完成模拟的 PR，不是最初收集的全部 PR。第二，它检测的是 Git 能识别的文本冲突，不能识别接口契约、业务语义和系统不变量之间的冲突。

这组数据不能证明 AI 一定比人更容易制造冲突，也不能直接代表企业私有仓库。它能说明的是，当多个 Agent 和开发者同时修改共享代码库时，冲突管理已经不只是最后执行一次 Git 操作，而是团队级的任务编排和并发控制问题。

5. PR 被合并，不等于代码不再需要调整

Watanabe 等人的研究对比了 567 个明确使用 Claude Code 的开源 PR，以及同一作者、同一仓库匹配的人类 PR。Agent PR 的合并率为 83.8%，匹配的人类 PR 为 91.0%；在已经合并的 Agent PR 中，45.1% 在首次提交后仍发生过修改。

这个 45.1% 是后续修改率，不是质量不合格率。它说明 Agent PR 进入 Review 后仍然经常需要调整，不能理解成“AI 写完就能直接合并”。

另一项 Ehsani 等人的研究分析了约 3.3 万个 Agent PR。文档、CI 和构建更新类任务的合并率相对更高，性能与 Bug 修复类任务相对较低；未合并 PR 往往范围更大、修改文件更多，也更容易出现 CI 失败。

把两项研究放在一起，我更愿意得到一个工程结论：Agent 可以参与真实协作，但任务选择、PR 大小、CI 和独立 Review 会显著影响结果是否可接收。

6. 质量问题不是一个维度

CodeRabbit 的开源 PR 分析比较了 470 个 PR。在它的样本中，AI 协作 PR 平均发现 10.83 个问题，人工 PR 为 6.45 个，约相差 1.7 倍。

这不能代表所有团队，但至少提示我们：代码生成速度提高，不代表 Review 面对的问题同步减少。

更麻烦的是，问题不只表现为 Bug 数量。它还可能影响架构一致性、重复代码、抽象质量、测试有效性和安全性。例如，代码能够运行，却绕开项目已有抽象；测试数量增加了，却只验证实现细节；局部修改看起来合理，组合到整个系统后却破坏了既有约束。

关于这些风险的结构化讨论，可以继续阅读 AI Code Quality Crisis 2026。这篇文章适合用来组织问题维度，但不能单独当作所有因果结论的证明。

7. 技术债往往来自持续累积的“局部正确”

AI 生成代码的风险不一定是一次写出大量明显错误，而是持续给出“局部看起来正确”的答案。模型知道大量通用写法，却不知道项目为什么采用当前架构，也不知道某段看起来别扭的逻辑是否来自过去的生产事故。

这些偏差可能只是复制一段逻辑、引入另一种异常处理方式，或生成只验证实现、不验证行为的测试。单独看都不严重，长期积累后却会变成系统性的维护成本。

安全问题需要单独提高标准。Veracode 的 2025 GenAI Code Security Report在特定安全编码任务中测试了 100 多个模型，其中 45% 的结果没有通过安全测试。这个数字不能解释成现实项目中 45% 的 AI 代码都有漏洞，但它说明“语法正确、功能可运行”不等于模型自动选择了安全实现。

更早的用户实验也讨论了类似问题，可以参考 Do Users Write More Insecure Code with AI Assistants?。认证、授权、输入校验、密码学和敏感数据处理，不应该只走普通代码检查。

8. 把研究翻译成五个可以执行的动作

从这些互相并不完全一致的研究中，我提炼了五件适合先做的事：

  1. 按任务类型试点，优先选择边界清楚、低耦合、验收可自动化的任务。
  2. 记录端到端时间，不只记录代码生成用了几分钟。
  3. 控制 PR 大小，并在最新主干组合上重新验证。
  4. 分开生成者和验证者，保留独立 Review 和确定性的质量门。
  5. 采用率和“感觉变快”只能作为辅助信号，协作体验、缺陷、返工和交付稳定性不能恶化。

这五点不是某篇研究已经验证过的标准答案，而是我把 Copilot 受控实验、METR 真实仓库研究、DORA 2025、AgenticFlict、Failed Agentic PRs和 Veracode 安全报告暴露出的风险，转换成下一轮试点应该收集的证据。

9. 三种行业观点：执行可以更自治，但意图和放行仍然属于人

Cursor 联合创始人兼 CEO Michael Truell 提出软件开发正在进入“第三阶段”：开发者更多负责定义问题、准备工具和验收标准，由多个云端 Agent 长时间、并行执行。这是 Cursor 的产品方向和内部实践观察，不是整个行业已经完成转型的证明。

Andrej Karpathy 发布的 autoresearch提供了另一个具体例子：人维护 program.md，Agent 只能修改 train.py；每次训练固定五分钟，再用同一个验证指标决定保留还是丢弃实验。它的价值不是让 Agent 随意研究，而是先固定范围、预算和评价标准。

Cognition 联合创始人兼 CEO Scott Wu 则强调 Agent 的目标不是取代程序员。Agent 可以承担迁移、升级和长期维护等端到端任务，但做什么、为什么做和最终是否接受，仍应由人决定。这里引用的是 TechCrunch 对 Scott Wu 的访谈，属于创始人的产品主张，不是对照实验。

三个人的观点并不是共同结论，但它们指向同一个值得讨论的方向：Agent 可以承担更多执行工作，人仍然需要守住意图、边界、评价标准和最终放行。

三、回到自己的使用记录：我怎样和 Coding Agent 协作

外部研究最多告诉我们 AI 的效果和任务、场景、验证成本有关，却不能直接回答自己的工作应该怎么做。因此，我又回头整理了几个月的本机 Codex 使用记录。

这部分不是团队调查，也不是严格实验。我想看的不是 Prompt 写得好不好，而是面对不确定任务时，我通常先让 AI 做什么、什么时候允许它开始修改，以及哪些控制权会留在自己手里。

1. 数据范围和限制

本机记录覆盖 2026 年 3 月 18 日到 8 月 9 日，共扫描到 956 个 JSONL 会话存档，原始体量约 2.72GB。剔除没有实质用户请求的文件后，得到 699 个有效会话，其中 527 个是我主动参与的人工会话，172 个是按固定合同运行的自动化会话。后续行为比例主要以 527 个人工会话为分母。

处理时，我剥离了系统自动注入、审批历史回灌和拼接的旧转录；人工与自动化会话分开；分析数据只保留不可逆哈希、标签、长度和少量去敏片段，再通过规则识别分析、证据、授权、范围和验证信号。

这组数据只能说明我的协作过程中出现过哪些行为，不能外推成所有开发者的稳定习惯。

2. 多数会话不是从“直接修改”开始

527 个人工会话中，有 310 个以分析或证据先行，占 58.8%；明确要求直接修改、或边界足够清楚可以直接执行的有 41 个，占 7.8%。另有 112 个开场无法稳定归类；即使全部算成直接开工，直接开工的上界也只有 29%。

跨项目观察也符合这个模式：Bug、核心数据流、接口和分支迁移通常先确认“现在到底发生了什么”；文案、小样式和固定工具操作等低风险任务，更适合直接执行。

这不能证明先分析一定更快，只能说明我会根据不确定性和可逆性调整 Agent 的开工方式。

3. 分析门和授权门最好分开

527 个人工会话里，有 201 个停在分析、诊断或审查阶段，没有进入实施；另有 182 个先分析，再进入不同形式的实施。两组共 383 个，占 72.7%。

这里不能把 72.7% 误读成“都出现了明确授权”。授权是另一条单独编码的信号：有 200 个会话检测到分析后出现明确实施许可。普通的“确认”不自动等于授权，因为它也可能只是确认结论或方案方向。

我现在更倾向于把它理解成两道门：分析门允许 AI 读取、对比、推演和提出方案；授权门才允许它写代码、改配置或影响外部状态。

4. 控制范围，以及用新证据更新假设

两个特别容易失控的地方，一是范围越做越大，二是没有新事实却不断换一种猜法重试。

在 527 个会话中，有 180 个检测到明确的范围边界，占 34.2%。这些边界往往是“只迁移方案 A，其他能力先不动”“不操作正在运行的页面”“视觉验收由用户完成”这种可以直接执行的限制。

另有 122 个会话在 Bug 实施前出现了日志、复现条件、运行状态等新证据，占全部人工会话的 23.1%。

这些数字不能证明缺陷或返工减少了多少，但从工程过程看，先补证据再换假设，通常比没有新事实就持续试错更可控。

5. 我把这套做法收成了五步

最后，我把反复出现的协作动作整理成五步：发现、取证、决策、授权、复核。

  • 发现：先把症状或目标说清楚，不急着指定修法。
  • 取证：沿代码、日志、接口、分支差异或运行状态确认事实。
  • 决策：比较方案的行为影响、修改范围、风险和验证成本。
  • 授权：明确允许按照哪套方案、在哪个边界内写入。
  • 复核：回到真实 diff、验证结果和未验证项，判断结果能否接受。

这套流程最重要的不是“五”这个数字，而是每一步都允许停止。取证发现前提不成立，可以停止；方案成本不合适，可以不授权；实施结果缺少证据，也可以回去更新假设。

6. 这种做法也有成本

如果一个很明确的小任务仍然层层分析和审批，流程可能比修改本身还重。我的人工会话轮次中位数是 5，75 分位为 17，90 分位为 31。会话越长，早期约束越容易被稀释；视觉或运行验证由用户完成但没有回写时，记录里也只能保留“未确认”。

所以结论并不是让所有任务都使用同一个模板，而是根据不确定性、可逆性、影响面和验证成本调整流程档位。由于这组个人数据没有对照组，也没有系统采集交付时间和缺陷结果，它还不能证明这套方法一定更快或质量一定更高。

7. Prompt 不应该只存在于个人聊天记录里

前面的使用记录也暴露了另一个问题：分析得到的事实、授权时确定的边界，以及验证后修正的判断，如果只留在一次聊天里，会话结束以后就很难被下一次任务继续使用。

所以 SPDD 的重点不是把 Prompt 写得越来越长，而是把聊天中的关键判断转化成看得见、能 Review、也能更新的工程资产。PRD 或 Spec 说明做什么、为什么做、怎样验收；Rules 或 AGENTS.md 记录目录边界、测试命令和禁止事项；接口、类型、依赖与既有代码提供仓库事实；测试和质量门独立回答“凭什么接受这次改动”。这些信息不一定要分别形成长文档，关键是后续 Agent 和接手的人能够找到。

这里最重要的是回写：如果运行和验证证明原来的理解不正确，不仅要修改代码，还要同步修正 Spec、规则或测试。下一轮 Agent 读到的应该是修正后的知识，而不是继续继承同一个误解。团队可以参考开放的 AGENTS.md 格式；如果使用 PRD 驱动 Cursor，也可以对照 ChatPRD 的实践说明。

到这里，个人协作习惯开始变成可以复用的工程资产。接下来再把视角放大到团队，讨论多人、多个 Agent 和不同角色怎样共享这些信息。

四、把个人习惯变成团队可以接手的工程接口

一次个人会话里，背景还可能保留在上下文中；到了团队协作里，产品、前端、后端、Reviewer、测试和发布人员往往在不同时间接手任务，主干代码也在持续变化。

如果事实和决策只留在某一轮聊天或某个人脑中，AI 生成得越快，信息丢失、范围漂移和集成冲突也可能越快。

DORA 对生成式 AI 的专题研究同样强调，AI 效果需要放在整个交付系统中理解。团队真正需要的不是更复杂的 Prompt，而是让事实、任务边界、验证证据和责任能够被后续角色继续使用。

在给出自己的团队结构之前，我想先放两个外部参照。一个回答模型之外还需要哪些工程组成，另一个展示规则进入真实仓库以后，怎样才能被 Agent 找到、执行，并留下证据。

1. Thoughtworks：模型只是引擎，不是工程操作系统

Thoughtworks 是一家长期从事企业软件设计、交付和现代化的技术咨询公司。它关注 AI Coding 时，不只看模型能不能写代码，也关注这套能力进入复杂企业系统后能不能持续维护和稳定交付。

在 Beyond vibe coding 一文中，Thoughtworks 指出，只把一个原始 Prompt 交给聊天窗口，很难得到生产级软件。Agent 即使可以读文件、跑命令，也可能因为缺少目标、边界和方法而反复自我修正，形成所谓的 agent thrashing。

它把 AI 原生工程拆成 Model、Agent、Context、Spec 和 Methodology 五部分。这里最值得带走的不是五个英文词本身，而是其中三类团队可以持续治理和沉淀的资产：项目上下文、任务契约和工程方法。模型和工具会换，这些资产却可以留下来。需要注意的是，这是一套来自行业实践的工程框架，不是经过对照实验验证的唯一标准答案。

2. 规则写进仓库，还要变成真正的质量门

GitHub 分享的 AutoGPT 项目实践给了一个更具体的例子。项目最初补充了贡献指南、文档和 Wiki，但 Agent 并不会主动找到它们。后来，团队把目录相关规则放到代码旁边的 AGENTS.md，把跨目录、按任务触发的操作流程做成 Skill，让规则在真正需要时可以被发现。

接下来是把规则变成门禁。PR 模板、CI、覆盖率阈值和 CLA 不只是在文档里告诉 Agent 应该怎么做，而是条件不满足就不能继续。处理 Review 意见时，AutoGPT 还要求先修复、提交和推送，再使用真实 commit SHA 回复，之后才能关闭线程。“我已经处理了”不算完成，代码、提交和验证证据能够对应起来才算。

这个案例不能证明固定的效率收益，但它说明了一件很实际的事：规则需要能够被发现、被执行，并留下可以复核的证据。下面再回到自己的团队场景，看看应该明确哪些责任。

3. 先统一四类责任

产品说“增加一个取消订单按钮”，前端看到的是页面，后端知道订单状态机，测试知道哪些边界不能破坏，而 Agent 可能只获得其中一部分信息。模型再强，只要大家掌握的不是同一套事实，结果就容易漂移。

我把团队需要明确的内容分成四类：

  • Context：以哪个分支、接口版本、设计稿、日志和现有测试为事实基线。
  • Contract：目标、非目标、系统不变量和验收条件是什么。
  • Validation：哪些结论必须由类型、测试、真实请求、日志或 Review 证明。
  • Responsibility：谁说明本次改动、哪些目录必须经过 CODEOWNER 或模块 Owner 审查、哪些 CI 检查必须通过，以及谁有权限决定合并。

这里的 Responsibility 不是增加一个线下签字环节，也不是要求每个 AI 辅助任务都再走一套额外审批流程。更实际的做法，是把责任落实到团队已有的 PR 流程中：PR 作者讲清楚为什么改、实际改了什么；涉及特定目录时，由对应的 CODEOWNER 或模块 Owner Review；Lint、类型检查、自动测试和范围检查等必需条件全部通过以后，再由拥有权限的人决定是否合并。

这些证据本来就会留在 PR 里，包括改动说明、Review 意见、Approval 状态、CI 结果和最终合并人。团队可以利用 GitHub CODEOWNERS固定特定代码范围的审查责任，并通过 GitHub Rulesets约束必需审查、状态检查和合并条件。

机器适合持续执行确定性规则，但需求有没有理解对、架构取舍是否合理、例外能不能接受，仍然需要 Reviewer 或模块 Owner 判断。这里真正要避免的，是让 Agent 自己生成代码、自己证明没有问题，最后再由自己决定合并。对于安全要求更高的项目，还可以参考 NIST Secure Software Development Framework补充相应的安全开发基线。

4. 从“它说做完了”变成证据闭环

很多 AI Coding 流程是：写 Prompt、生成代码、点击接受、创建 PR。这条路径上的每一步都可能只有 Agent 自己声称完成，却没有独立证据。

更稳妥的流程是先用任务契约固定目标和边界，再按风险决定 Agent 能做多少；写入前由人明确授权；实施过程在独立分支或工作区小批次推进；之后通过类型、测试、安全和契约等确定性的质量门。

AI 可以根据真实 diff 做自审，但不能替代独立人工 Review。随后还要进行真实联调、最新主干组合复验，以及发布后的监控和回滚准备。

这种闭环也要求把失败经验写回工程系统：联调发现字段语义不一致，不应该只修改页面，还要同步更新接口 Schema、交付文档、契约测试或仓库规则。关于变更规模，可以参考 Google 的 Small CLs 实践；多个 PR 并发进入主干时，则可以参考 GitHub 的 Managing a merge queue。

5. 高质量 AI 辅助开发，需要四类关键信息

把 AI 辅助开发做得更规范，不等于每个任务都要额外填写四份文档。真正需要保证的，是任务从提出到合并的过程中，四类关键信息没有缺失：AI 知道要做什么、准备怎么做；人能够看懂它实际改了什么，也能根据证据判断它有没有做对。

第一类是任务边界。这里需要讲清楚目标、修改范围、约束条件和验收标准，同时明确哪些内容不在本次任务中。它可以写在需求卡片、Issue 或任务描述里。边界不清楚时，AI 即使生成了可以运行的代码，也可能解决了错误的问题。

第二类是改动方案。对于简单任务，几句话说明准备修改哪些位置、怎样验证就够了；只有涉及多个模块、接口、数据或高风险逻辑时，才需要进一步记录影响范围、技术取舍、风险和回滚方式。这个过程的重点不是把计划写长，而是在 AI 写入以前发现方向性错误。

第三类是变更说明。代码完成以后，需要能够回答实际改了什么、影响了哪些文件和行为、是否偏离原计划，以及还有什么遗留问题。这些内容可以直接放在 PR 描述、Commit 或 Agent 的执行摘要中，不一定单独形成一份交付文档。PR 描述的组织方式可以参考 Google 的 Writing good CL descriptions。

第四类是验证证据。自动检查是否通过、运行了哪些测试、Reviewer 关注了什么、哪些内容还没有验证，都应该明确留下来。只有修改确实跨越前后端、服务或外部系统时，才需要增加相应的联调记录；一个样式调整或局部空值修复，没有必要为了流程专门生成一份前后端联调报告。

所以，这四类信息并不对应四份固定模板。小改动可以把它们浓缩在一张任务卡和一个 PR 里；影响范围越大、不可逆性越高，方案和验证证据才需要越完整。目标不是增加文书工作，而是让 AI 的改动可理解、可检查、可验证。

6. 根据风险调整流程重量

流程一刀切会出现两个问题：小改动觉得太重，真正危险的改动又不够严。我通常先看四个变量：目标和原因有多不确定、出错后能否快速恢复、影响多少用户和模块，以及最后要付出多大成本才能证明正确。

  • 文案、明确样式和机械替换可以走快速档：锁定范围、回读 diff、运行覆盖主要风险的检查。
  • 常规功能、接口适配和普通 Bug 走标准档：分析、计划、授权、实施、测试和 Review。
  • 认证授权、支付、数据迁移、删除、公共 API 和生产配置走严格档：先取证和比较方案，由领域 Owner 审批，并准备分层验证、灰度与回滚。

档位改变的是流程重量和 Agent 的自主范围，不改变最终责任。高风险任务中，Agent 不应该自己审批、自己合并或绕过必须检查。GitHub 的 Rulesets和 CODEOWNERS可以把部分边界落到仓库配置中。

7. 试点不要只比较谁生成的代码多

AI 试点真正要回答的是：它有没有让团队更好地交付，同时没有把成本从开发者转移给 Reviewer、测试和线上。

我会先看质量护栏，例如变更失败率、回滚、部署返工、缺陷逃逸和安全事件是否恶化；再看协作体验，例如首轮 Review 等待、Review 轮次、人工返工时间和 Reviewer 负担；守住这两层以后，才看端到端效率和真实吞吐。

PR 有效大小、首轮 CI 通过率、文本或语义冲突、合并队列失败和超范围修改，可以用来解释问题，但不应该变成个人 KPI。指标定义可以参考 DORA Metrics。试点初期可以选择一个活跃但不是最高风险的仓库，挑选 10 到 20 个类型与风险相对可比的真实任务。这个规模便于人工复核，但不足以证明普遍因果。

五、最后：没有证据的代码，只能叫候选修改

回到最开始的问题：AI 给出代码，只代表生成完成。需求边界有人确认、验证结果真实存在、独立 Reviewer 能解释主要风险、最新主干组合通过、发布后能够监控和回退，才接近工程上的交付完成。

团队不需要强制所有人使用同一个模型，也不需要复制同一段 Prompt。更重要的是，无论工具怎样变化，它都在同一套 Context、Contract、Validation 和 Responsibility 下工作：知道事实基线，遵守任务边界，提交可以检查的证据，并由明确的人承担最终判断。

快速生成当然可以保留，但没有证据的代码只能叫候选修改，不能默认接受；一次检查通过不能默认合并；合并成功也不能默认发布。

AI 真正值得加速的，不只是从 Prompt 到代码的几分钟，而是从发现问题、形成证据、做出决定，到把失败经验沉淀为下一轮规则和测试的整个闭环。工具会变，模型会变，但责任链不能跟着消失。

原始资料与延伸阅读

为了方便后续核对，这里集中保留分享中引用过的公开原始资料：