Vibe Coding 的 Definition of Done：完成证据与交付边界
Agent 说“已完成”可能只表示代码已生成或某条命令变绿。本文区分验收条件、团队完成定义、发布门和非目标，并用绑定当前变更的证据阻止漏项与顺手扩张。
本文要点
- 主题聚焦：AI、Vibe Coding、DevOps
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
在 Vibe Coding 会话里，“完成了”可能有五种含义：文件已经生成、页面能打开、类型检查通过、需求看起来实现、或者改动真的具备交付条件。若团队不预先定义，Agent 通常会选择最容易声明的那个。于是一个漂亮 Demo 带着未跑的迁移、缺失的权限分支和未解释的依赖变更进入评审。
Definition of Done（DoD）不是任务末尾临时追加的检查清单。它是团队对“什么样的 Increment 才算可用”的共同质量基线。Scrum Guide 明确指出，不满足 DoD 的工作不能作为 Increment 发布或在 Sprint Review 中按完成呈现。对 Vibe Coding 项目，更要把自然语言承诺转换为当前变更上的证据。
分清四类边界
先把容易混淆的内容拆开：
- Acceptance criteria：这个切片特有的业务行为，例如“重复上传同一文件不会创建第二份结果”；
- Definition of Done：所有同风险改动都必须满足的工程基线，例如评审、测试、安全扫描和文档同步；
- Release criteria：是否允许暴露给某批用户的运行门，例如迁移窗口、监控、回滚和支持值班；
- Non-goals：本次明确不交付的能力，以及用户碰到它时的安全行为。
MVP 垂直切片负责本次做哪条结果链，API 合同与请求响应示例提供接口行为，非功能预算给性能、安全与可用性量化门。DoD 不重复这些正文，而是引用其版本并要求对应证据齐全。
例如反馈导入切片的验收条件关注 CSV 解析、依据展示和重复提交；通用 DoD 要求 lint、类型检查、相关测试、人工 diff 评审、数据迁移说明、依赖审计、无秘密提交和用户可见文案复核；发布条件再要求备份、灰度指标和关闭开关。三层混在一起，会导致本地开发被生产操作阻塞，或反过来把本地绿色误称为可发布。
用风险档位配置 DoD
不是每次改文案都需要灾备演练，也不能因首版快速验证就跳过鉴权。为改动设可解释档位：low 是无行为变化的内容或样式；medium 涉及普通业务逻辑和持久化；high 涉及身份、权限、支付、隐私、不可逆迁移或公共接口。每档在仓库中对应固定门禁，任务只能升档，降档需负责人和理由。
一个 medium 切片可采用以下基线：
- 所有 acceptance criteria 有可失败的测试或明确人工验收步骤；
- 加载、空、错误、无权限及重试状态按UI 状态矩阵覆盖；
- 新旧数据能迁移，失败不会留下无法解释的部分状态；
- lint、类型检查、受影响单元/集成测试和一条端到端主路径通过；
- 新依赖、配置、环境变量、遥测和数据保留变化已披露；
- diff 仅含获准范围，生成文件能从登记的源重建；
- 已知限制、回滚方式和后续 owner 可见。
high 档再加入威胁复核、权限反例、备份恢复或迁移回滚演练等。门禁必须写成项目实际可运行的命令和人工步骤，而不是笼统的“保证安全”“充分测试”。GitHub 受保护分支可以强制评审和状态检查，但配置一个名叫 test 的 required check 并不能证明它运行了正确测试；检查输出仍需绑定当前 commit 和配置。
让完成声明携带回执
Agent 每完成一步，报告 claim -> evidence -> scope：声称满足哪条标准；运行了什么命令或执行了何种观察；结果绑定哪个工作树或 commit；哪些检查未运行及原因。退出码、测试数和失败摘要应来自真实执行，不能根据代码推测。若检查因外部服务不可用而没跑，状态是 BLOCKED 或 NOT_RUN，不是“预计通过”。
编程 Agent 需求验收追踪进一步把 claim 连到 diff 和测试。日常小项目不必先建证据图，也至少应保存命令、工作目录、退出码和运行后的 git diff。测试通过后又改了代码，旧回执立刻过期，需要重跑受影响门禁。
人工检查也要可复现。“页面看过了”应改成：使用哪个 viewport、账户角色和 fixture，从哪个入口操作，观察到什么结果。视觉截图只能支持视觉声明，不能证明键盘可用或数据库状态。无法自动化的项目可保留短 checklist，但每项有明确观察者和日期。
Non-goals 必须定义用户看到什么
“本轮不做团队协作”还不够。若用户能看见邀请按钮却得到空白页，边界仍泄漏。对每个 non-goal 决定：完全不显示入口；显示不可用状态及原因；还是只允许内部开关访问。API 对未支持操作返回稳定错误，数据模型不预写半成品字段，文档不承诺未来日期。
新需求进入时，先检查它是否修复当前验收、满足 DoD，或处理阻断风险。都不是就进入后续清单。若确实改变当前范围，按规格变更日志与重新验收提升规格版本，重新评估受影响证据；不能让 Agent “顺手做了”之后用沉没成本倒逼接受。
完成评审最后问三件事：目标用户能否独立走完主路径；关键失败是否以安全且可理解的方式结束；另一个开发者能否从干净环境重现结果。任一答案依赖作者口头提示，就不满足交付边界。通过后冻结证据清单和已知限制；是否立即上线仍由 release criteria 决定。
一份有效 DoD 不会让开发变慢，它把“还差什么”提前显性化，减少 AI 生成之后的集中返工。完成不是 Agent 的语气，也不是文件数量，而是约定范围内的行为和质量都由当前证据支持，同时范围之外没有伪装成半成品入口。
Related