完成标准的新定义

背景

在软件开发领域，“完成”（Done）是一个看似简单却极易被误解的概念。许多开发者会在功能尚未真正就绪时急于宣布完成，导致交付质量下降、用户满意度受损、技术债务累积。Hacker News 上的一篇短文《The Definition of Done》直击这一痛点，提出了一个更严格、更务实的完成标准，并延伸至 AI 协作场景下的判断责任。该文以精炼的清单形式揭示了开发者常见的“伪完成”陷阱，并给出了一个可操作的定义：完成不是努力结束，而是价值在真实世界中生效。

核心内容

原文的核心主张是：“完成”是对现实的声明，而不是对努力的声明。 作者指出，许多软件开发者最容易掉入的陷阱就是将明明还没完成的东西当作已完成。具体而言，以下情况都不能算作“完成”：

• 如果它只在你的机器上能工作，那就不算完成。
• 如果它没有经过测试，或者没有经过多轮反馈和迭代，那就不算完成。
• 如果 Pull Request（PR）还没有合并，那就不算完成。
• 如果它部署在 dev 或 staging 环境，但没有上 production，那就不算完成。
• 如果你完成了自己的部分，但另一位开发者还需要完成他/她的部分，那就不算完成。
• 如果它已经部署了，但目标用户仍然无法访问，那就不算完成。

基于这些反例，作者为软件开发者给出了自己的“完成”定义：

完成 = 它在所有支持的设备上都能正常工作，经过了多轮反馈和迭代测试，PR 已合并，团队的相关工作也已就绪，并且已经上线到 production 环境、用户能够正常使用。

此外，文章还特别提到 AI 的局限性：AI 无法真正告诉你它何时完成了。 你必须亲自告诉 AI 它何时完成。如果你轻信了 AI 说“完成了”的反馈，那么你就应该担心 AI 会取代你的工作。因为真正的完成不是你的工作结束，而是价值在世界上被创造出来。文章最后反问读者：“请再告诉我一次，你完成了吗？”

关键要点

• 完成的本质是对现实的检验，而非对个人努力或单方面进度的自我宣告。
• 常见“伪完成”情形包括：仅本地运行、未测试/未迭代、PR未合并、仅部署到dev/staging而非production、依赖他人工作未完成、已部署但用户仍不可访问。
• 严格完成的六项标准：
  1. 在所有支持的设备上正常工作
  2. 经过多轮反馈和迭代测试
  3. PR已合并
  4. 团队相关关联工作已完成
  5. 已上线production环境
  6. 目标用户真正可用
• AI无法判断“完成”，判断完成的主动权必须由人类（开发者）掌握，AI的输出不能作为完成的最终判决依据。
• 价值导向：完成的标志是价值在现实中落地，而非开发者个人任务清单的勾选。

意义与影响

该文的意义在于将“完成”这一模糊概念具象化、可操作化，帮助团队成员、产品经理和开发者对齐期望，减少因为“我觉得做完了”而导致的返工、事故或用户投诉。它直接挑战了敏捷开发中常见的“故事点估算”或“冲刺结束即完成”的粗放认知，强调交付质量与用户可及性才是真正的终点。

在 AI 辅助编程日益普及的当下，文章关于“AI不能告诉你完成”的提醒尤其值得警惕。开发者很容易将AI生成的代码当作“做完”的信号，而忽略测试、集成、部署、用户验证等复杂环节。文章鼓励开发者保持主动判断权，避免被AI的“自信心”误导。这实际上是在维护人类在交付链条中的主体性和责任。

长远来看，“The Definition of Done”不仅适用于软件研发，也适用于任何需要交付价值的协作场景——它提醒我们，完成不是一个个人截止日期，而是一个系统级的状态切换：只有当所有依赖、环境、用户和验证都满足时，才算真正完成。这种严谨思维有助于提升团队整体交付质量，减少“看起来做完但实际上没做完”的隐形债务。