“这个功能 AI 已经写好了，测试也通过了，可以算完成吧？”
在 AI 编程工具普及之后，这句话会越来越常见。它听起来合理，却把三个不同状态混在了一起：代码已经生成、代码可以运行、产品增量已经完成。
事实上，在 AI 出现之前，成熟的 Scrum 团队就不应把“代码写完”理解为“完成”。AI 带来的新问题，不是旧的 DoD 失效了，而是“伪完成”变得更容易、更快速，也更具迷惑性。
所以，AI 时代需要重新审视的，不是 Done 的含义，而是团队用什么证据证明一个增量真的 Done。
01 先把 DoD 放回正确的位置
《Scrum 指南》将完成的定义（Definition of Done，DoD）描述为：当增量达到产品所需的质量措施时，对其状态的正式描述。DoD 是对增量的承诺，它的首要作用是提升透明度。
也就是说，当团队说某项工作“完成”时，所有人应当对这个状态有共同理解。没有满足 DoD 的产品待办项，不能成为增量的一部分，也不能被包装成已经完成的成果。
这里还需要区分两个容易混淆的概念：
- 验收标准
通常描述某个产品待办项要实现什么、在什么条件下被接受； - DoD
描述所有增量都必须达到的共同质量状态。
如果组织已经制定了适用的 DoD，Scrum 团队应将其作为最低标准；如果没有，则由 Scrum 团队为产品建立合适的 DoD。开发人员必须遵循它，而不是在 Sprint 结束时再由测试人员“把关”。
代码可以快速生成，Done 仍需要被证明。
02 AI 放大的，是“伪完成”
AI 显著降低了代码生成成本，却不会自动消除理解、验证和维护成本。相反，它可能让团队更快地抵达一个“看起来完成”的状态。
可运行，不等于团队真正理解
AI 可以给出结构完整、运行正常的实现，但团队未必理解其中的边界条件、架构取舍和潜在副作用。代码能跑，不代表团队能解释它、维护它，并在故障发生时承担后果。
测试通过，不等于风险已经覆盖
如果代码和测试都由 AI 基于同一套假设生成，它们可能彼此自洽，却共同偏离真实业务。测试数量增加，并不自动等于验证质量提高。
变更更快，不等于交付更可靠
审查流于形式、依赖来源不清、安全检查缺失、上线后不可观测、出现问题难以回滚——这些原本就存在的薄弱环节，会随着 AI 提高变更吞吐量而更快累积。
03 DoD不必无限加长，证据需要更可靠
应对 AI 风险，不是简单地给 DoD 增加十几项审批。清单越长，不代表质量越高；如果每一项都只是形式化打勾，反而会降低 DoD 的可信度。
可以围绕需求、工程质量和可交付性检查 Done 的证据。
① 需求正确性的证据
确认实现满足该产品待办项的验收标准，关键业务规则与异常场景已经验证。AI 方案可以成为起点，但不能替代对产品意图的理解。
② 工程质量的证据
代码审查、自动化测试、静态检查、安全扫描和必要的性能验证，应与变更风险相匹配。AI 生成的关键逻辑必须有人能够解释、维护并负责。
③ 可交付性的证据
增量不仅要能运行，还应按产品需要具备部署、监控、日志和回滚能力，相关配置、接口约定与必要文档也应保持同步。
每一项 DoD 标准都应能回答两个问题：它在防范什么风险？团队如何确认它已经满足？
04 一份可供调整的 DoD 示例
下面不是通用答案，而是一份适合 AI 编程团队继续讨论的起点：
产品待办项满足验收标准，关键业务路径与异常场景已经验证； 代码已按团队约定完成审查，AI 生成的关键逻辑有明确责任人； 与变更风险相称的自动化测试及质量检查已经通过； 必要的安全、隐私、性能或合规要求已经验证； 增量可部署，并具备必要的日志、监控和回滚措施； 相关配置、接口约定与必要文档已经同步。
它并不是一份“AI 专属 DoD”。这些本来就是高质量增量可能需要满足的条件。AI 的出现，只是让团队更难依靠“看起来差不多”蒙混过关。
05 不要把 DoD 与价值验证混为一谈
DoD 解决的是增量是否达到产品所需的质量状态、是否处于可用状态。至于它是否真正解决了用户问题、产生了预期业务价值，则需要通过 Sprint 评审会、上线数据和真实反馈持续检视。
前者帮助团队诚实地判断“是否完成”，后者帮助团队继续判断“是否值得”。它们彼此关联，但不能互相替代。
写在最后
AI 改变的不是 Scrum 对完成的定义。在 AI 出现之前，代码写完就不等于完成；在 AI 出现之后，这一点只会更加重要。
当生成、测试与合并都变得更快时，团队更需要保有对质量、风险和责任的真实掌握。
真正的 Done，不是 AI 生成了多少代码，而是 Scrum 团队能否有依据地确认：这个增量达到了产品所需的质量标准，处于可使用、可维护、可以承担后果的状态。
你们团队现在的 DoD，能应对 AI 生成代码带来的新风险吗？欢迎留言分享。
