Vibe Coding 的工程纪律：任务、审查与验证怎么分工

AI 能很快生成一段看起来合理的代码，但上线需要另一种能力：确认它在真实环境、边界条件和失败路径中仍然正确。本文讨论工程中的 AI 辅助编程，用“Vibe Coding”这个流行说法作入口，重点是任务分工、证据和责任。

本文综合公开工程报告、工具文档和原始生产力研究；建议流程属于工程推导，不把单个团队的报告写成所有项目都能获得的提效倍数。

按风险与可验证性分工

“核心代码永远自己敲”并非唯一正确分工；更重要的是能否可靠验证，以及谁负责最终结果。数据迁移也不是天然低风险：一个短脚本可能影响全库，不能与文案修改用同样的审查力度。

图 1 · 自动化程度取决于风险、范围和验证能力，不能只按代码是否容易生成判断。

给 AI 一份可验收的任务书

任务包含背景、具体失败、范围、约束和验收。例如：

现象：文章目录在生产静态构建中不能 sticky。
范围：检查文章页及祖先容器的样式，保留现有视觉布局。
约束：使用仓库约定的构建命令，不引入新依赖。
验收：生产产物滚动后目录仍可见，移动端无横向溢出。
输出：改动原因、相关 diff 和验证结果。

写清事实与猜测：“可能是 overflow”是待验证假设，不是要求模型证明的结论。复杂任务先定位再修改；明确不变量往往比提供大量无关历史更有效。

项目文件如 AGENTS.md 或 CLAUDE.md 保存构建、目录和工作约定，定期删掉过期内容。它们帮助模型工作，不能代替权限和机器检查。

审查：优先看最容易隐蔽出错的地方

先看 diff 是否只处理目标问题，再看输入、授权、密钥、并发状态、错误与取消路径。新依赖是否必要、旧数据是否兼容、失败是否能恢复，也应随风险检查。

测试按影响选择：文案与小样式修改通常靠渲染检查；状态、协议和计算逻辑需要有意义的回归。测试先行对可明确描述的 bug 很有效，但不能为了每个低影响修改写一套只镜像实现的测试。

另一个 AI 会话可提供独立审查视角，仍可能同源犯错；不能把“两个模型都说没问题”当作正确证明。已知模式用静态分析，正确性用任务相应的测试和人工判断。

OpenAI 与 Anthropic：让验收独立于生成

OpenAI Harness engineering^[6]讨论仓库知识、隔离运行环境与机械执行的架构约束。可借鉴的是：给 Agent 可导航的项目知识，把重要不变量写成会执行的检查，让它能在实际环境里验证改动。

Anthropic 的长任务开发报告^[7]使用 planner、generator 与 evaluator，借助结构化契约推动增量实现与浏览器验收。生成与评审分工有助发现自我评价的盲点，但仍需清晰标准与可靠检查。

报告中更复杂 harness 同时扩大了任务实现范围和执行预算，不能只把展示效果视为同等成本下的严格比较。工程推导：团队实验应控制需求范围、工具版本和验收标准，记录完整时间与费用，再判断规划、独立评审或浏览器验证的净收益。

团队怎样把经验写成可执行规范

任务书描述目标、范围和验收；AGENTS.md / CLAUDE.md 提供可导航的项目规则；类型、lint、契约测试和 CI 执行可机械验证的不变量。审查意见与故障复盘回流文档，反复出现且能确定判断的规则再固化为检查。

核心算法、性能关键路径、安全与合规设计由负责人确定不变量和风险边界，AI 可辅助分析和起草；合并责任不能转给工具。新成员通过示例任务、审查解释和失败案例理解规则，组件文档写清接口、恢复和使用边界，避免只留一句“已经测试”。

UI 验证示例：sticky 与滚动祖先

目录无法 sticky 时，检查所有祖先的计算样式与滚动容器，而不是反复增加 top 或 z-index。MDN position^[4]与 overflow-x^[5]说明相关 CSS 行为；具体问题仍需用 DOM、计算样式与滚动实测定位。

桌面、手机与生产产物验证覆盖长表格、图片放大和跨页导航。开发模式正常不保证构建后的样式顺序与 hydration 正常，这也是 Agent 的验收环境应贴近交付环境的原因。

自动检查必须放在真的会执行的位置

Hooks 可以在工具执行或提交环节检查，CI 则验证提交后的统一规则。安装依赖脚本、Git hooks 和 AI 本身也可能修改检查逻辑；“本地有 hook”不保证永远绕不过。重要门槛放进受控 CI 与分支策略，必要时审查规则自身的变更。Claude Code hooks^[2]

把权限、审查和发布边界单独配置，详见 本地 Agent 安全篇。能自动执行的低风险动作在明确范围内推进，高影响提交需要可 review 的结果和相应授权。

提效：总时间里必须包括审查与返工

任务总耗时 = 定义任务 + 生成或编码 + 审查
           + 验证 + 返工 + 上线后的修复

按任务类型记录真实耗时、通过率、缺陷和工具费用，同类任务作比较。不能只计“AI 写了五分钟”，忽略工程师审查两小时；也不能因一个复杂任务负收益就否定所有辅助用途。

METR 对早期 2025 工具、熟悉大型开源项目的开发者做过随机实验，观察到该样本使用 AI 后完成时间增加约 19%。这有明确的时间、工具和样本边界，既不证明 AI 永远减速，也提醒我们感知提效需要实测。研究原文^[3]

工具更新很快，过去的倍数不能承诺给今天的项目。最有用的指标是团队在当前工具与流程下的交付质量和总时间。

落地检查

1. 按风险与可验证性分工，先写目标、约束和验收。
2. 事实与假设分开，定位后做范围明确的改动。
3. 审查优先看权限、并发、错误、副作用和旧数据。
4. 验证按影响选择，UI 在实际构建产物检查。
5. 机器门槛有受控执行位置，AI 审查不代替验收。
6. 测总交付时间、返工和质量，持续调整分工。

参考资料