# DoD：大模型时代的任务完成定义


![DoD首页头图：大模型时代的验收契约 重制版.png](https://developer.qcloudimg.com/http-save/yehe-10550024/c6c212bd474abbc15ee877cc4feee5eb.png)
## DoD 是什么


DoD（Definition of Done，完成的定义），回答的是一个看似简单却经常被忽略的问题：**做到什么程度，才算做完了？**

在软件开发中，软件一般需要经历两个实现阶段：一个是在脑海中的实现，一个是在计算机上的真实实现。在真正实现之前，软件只存在于设计者、开发者、使用者各自的想象里——而这些想象之间往往差别很大，甚至南辕北辙。

为了拉齐大家的共同想象，让最终开发出的软件满足所有人的预期，我们发明了 PRD、发明了原型图：用 PRD 定义软件完成后应该具备哪些功能，用原型图定义开发完成后软件的可视化界面。**这就是软件开发中的 DoD——为「软件开发完成」所下的定义。**

## 为什么大模型时代更需要 DoD


同样的，DoD 在大模型的使用过程中，也是一个非常重要的行为，甚至更加重要。

最近一年，模型能力飞速提升，尤其是在长程任务的执行和任务完成情况的检查上。在 AI 交流会上，很多人兴奋地说：「我现在每天晚上睡觉前都会交给 Agent 一个任务，第二天起床后验收。」大家能明显感受到，模型的自主能力越来越强，我们可以把越来越多的任务交给大模型。

但这随之引入一个问题：**我们怎么验证大模型做得对不对？大模型又怎么验证自己做得对不对？**

如果只是丢给大模型一句「开发一个交友网站」，第二天清晨迎接你的，往往是一个不合人意的产物，外加一本厚厚的 Token 账单。问题不在模型的执行力，而在于——**你从来没有定义过什么叫「完成」**。

![插图：模糊指令vs清晰DoD 重制版 1.png](https://developer.qcloudimg.com/http-save/yehe-10550024/6baad12702160da175e8c2e6c472db54.png)

所以，我们需要像软件开发中使用 PRD、原型图那样，把定义 DoD 的行为引入大模型的使用过程：在与大模型的交互中，**提前确定每项工作的完成定义**。然后：


- 大模型可以按照 DoD 自检产物（这也是 Agent 自我验证、自我迭代的基础）；

- 人可以根据 DoD 验收大模型的产物，验收标准从「感觉不对」变成「逐条核对」。


一句话总结：**DoD 是人类与大模型之间的验收契约。**

## DoD 长什么样


DoD 的定义必须**可检查、可判定**。很多时候它就是一份清单，由一个又一个检查项构成。就像 PRD 文件会写明某个菜单具有哪些功能、每个按钮点击后应该产生什么效果——当开发完成之后，可以照着 DoD 清单逐项检查最终产物。

一份好的 DoD 检查项，通常具备这些特征：


|特征|反例|正例|
|:-:|:-:|:-:|
|**可判定**：能明确回答是/否|「界面要好」|「登录页在 375px 宽度下无横向滚动条」|
|**可量化**：有数字边界|「性能要好」|「首屏加载 P95 < 2s」|
|**覆盖边界情况**：不止正常路径|「支持导出」|「空数据导出时提示『暂无数据』且不生成文件」|
|**包含隐含预期**：把默认假设写出来|「加个搜索」|「搜索为空时展示『无匹配结果』文案」|

注意最后一条：大模型不会读心术。人类验收时那些「这不言而喻吧」的隐含预期，恰恰是大模型最容易漏掉的部分，也是 DoD 最大的价值所在——**把隐性预期显性化**。

### 一个完整的 DoD 示例


假设交给大模型一个任务：**「给后台管理系统的人员列表页增加导出 Excel 功能」**。一份合格的 DoD 大概长这样：

**任务**：人员列表页新增「导出 Excel」按钮，点击后下载包含当前筛选结果的人员清单。

**DoD 清单**：


- **功能主路径**
	- 列表页工具栏出现「导出 Excel」按钮，仅对拥有 `user:export` 权限的账号可见
	- 点击按钮后导出当前筛选条件下的全部记录（不受前端分页限制），文件为 `.xlsx` 格式
	- Excel 包含 8 列：工号、姓名、部门、岗位、手机号、邮箱、入职日期、状态，列顺序与列表页一致

- **边界情况**
	- 筛选结果为空时点击导出，提示「当前筛选条件下无数据」，不生成文件
	- 结果超过 10 万行时导出仍可完成，超过 30 秒的操作有进度提示或改为异步任务通知
	- 手机号在 Excel 中保持文本格式，不丢失前导零、不转科学计数法

- **质量门槛**
	- 单元测试覆盖导出数据组装逻辑，`npm test` 全部通过
	- 无新增 ESLint 告警；不引入新依赖，或新增依赖需在说明中列出理由

- **交付物**
	- 附带变更说明：改动了哪些文件、新增了哪些权限点
	- 自检报告：逐条勾选本清单并附每条的验证方式（命令或操作路径）


第二天早上验收时，你不需要重新脑补「应该是什么样」，只要对着清单打勾——模型也会在交付前用同一份清单自检。**一份 20 分钟写下的清单，换来的是验收时的一分钟，和返工次数的指数级下降。**

## DoD 与 SDD 的关系


![插图：DoD写在哪里的三层载体 重制版.png](https://developer.qcloudimg.com/http-save/yehe-10550024/db854b25ac6dc1f7f8261210c74c80a5.png)
说到这里，很容易联想到近年很火的 SDD（Spec-Driven Development，规格驱动开发）。一个常见的直觉是：「DoD 是不是 SDD 的一部分？」——毕竟 SDD 的规格文件里，确实写满了任务的完成结果和验收标准。

更准确的理解是：**两者不是包含关系，而是「概念」与「方法论」的关系。**


- **广义 DoD 是一个概念**：「任何任务开始之前，显性定义完成标准」。这个思想比 SDD 古老得多——PRD、原型图、验收测试、敏捷的验收标准，都是它在不同时代的形态

- **SDD 是一套方法论**：它回答的是「这个概念如何落地」——用 EARS 场景语法写需求（「WHEN 用户提交空表单 THE SYSTEM SHALL 显示错误提示」，逐条可判定，本质上就是验收标准）、用 tasks 清单带勾选框逐项验收、用 check 命令（lint/test）做质量门禁。**SDD 把广义 DoD 拆散内嵌进了规格工作流的每个工件里**


所以准确的表述是：SDD 是目前把「完成定义」执行得最完整的 AI 开发范式。实践中实践 SDD 时，你不需要单独再写一份 DoD——它已经化在 spec 的场景描述和 tasks 的勾选框里了。

## 如何写好一份给大模型的 DoD


这一节回答四个具体问题：**写在哪、什么格式、写什么、给模型哪些信息**。

### 1. 写在哪：按任务规模选载体


插图：DoD写在哪里的三层载体 重制版 2.png


|任务规模|DoD放哪里|说明|
|:-:|:-:|:-:|
|**即席任务**（一段对话内完成：改个脚本、写个组件）|直接写在提示词里|任务和 DoD 一起发出，对话即上下文|
|**项目级任务**（跨多轮、要改多个文件）|写成独立文件，如 `docs/dod-导出功能.md`|文件可被反复引用、勾选、版本管理；任务结束前不删|
|**团队级质量底线**（对所有任务生效）|写进仓库的全局约束文件：`AGENTS.md` / `CLAUDE.md` / `.cursorrules`|主流编码智能体都会自动读取，相当于每次任务自动附带的默认 DoD|

分层的意义：全局文件管「永远要遵守的」（测试过、无调试代码、改完自检），任务 DoD 只写「这个任务专属的」。越往上层越稳定、越少改。

### 2. 写什么：一份任务 DoD 的固定结构


不管是写在提示词里还是独立文件，都建议按这五段组织：

```
## 任务目标
一两句话说清要做什么、给谁用。（例：给后台人员列表页加导出 Excel）

## DoD 清单
- [ ] 功能主路径：……（逐条可判定）
- [ ] 边界情况：……
- [ ] 质量门槛：……（或直接引用全局约束，不重复写）

## 上下文
- 相关文件：`src/pages/UserList.tsx`、`api/user.ts`
- 现状说明：导出接口已有雏形 / 权限体系见 `docs/permissions.md`
- 技术约束：TypeScript、不新增重量级依赖

## 验证方式
- 自动：`npm test`、`npm run lint`
- 人工：登录测试账号 → 列表页 → 点导出按钮 → 检查文件内容

## 交付物
- 代码变更 + 变更说明
- 按 DoD 清单逐条自检，附每条的验证结果
```
其中「上下文」一段最容易被省略，也最影响质量——**模型找不到正确的文件，DoD 写得再好也是对着错误的靶子验收**。

### 3. 怎么写好每一条：五个原则


1. **先写 DoD，再下任务**。顺序反了，DoD 就成了事后找补。

2. **从用户可见的行为出发**，而不是从技术实现出发。「接口返回 200」是内部标准，「页面展示收藏列表」才是完成定义。

3. **每条一个断言**，避免「并且」「同时」把多个检查点粘在一起。

4. **给验证方式**：能自动验证的写明命令，需要人工的写明操作路径。

5. **允许 DoD 被迭代**。验收时发现模型产物某个方面出乎意料地好或差，把它补进 DoD 或沉淀到全局约束文件——这份清单会越用越完备，本身就是团队知识的积累。


### 4. 即席任务的懒人模板


日常小任务不必动用完整结构，五行够了：

```
任务：{做什么}
DoD：1) … 2) … 3) …（3~5 条，含一条边界情况）
相关文件：{路径}
验证：{命令或操作路径}
交付时：逐条自检 DoD 并说明验证方式
```
「睡前委派、起床验收」能成立的唯一前提，就是模型出发前就知道终点长什么样。

## 结语


软件工程的过去几十年里，我们把「完成的定义」写进 PRD、写进验收标准；大模型时代的下一个十年，我们要把「完成的定义」写进每一次与模型的对话里。**模型负责执行，DoD 负责定义完成，人负责守护 DoD**。

DoD（Definition of Done，完成的定义），回答的是一个看似简单却经常被忽略的问题：做到什么程度，才算做完了？

DoD：大模型时代的任务完成定义

职业发展

架构设计

开发工具

DoD是明确大模型任务完成标准的验收清单，包含可判定、可量化的检查项，覆盖边界情况和隐含预期。它解决"做到什么程度算做完"的问题，通过提前定义完成标准，让模型自检、人工验收，有效降低返工率，是AI协作时代的核心交付契约。

软件工程

软件开发

单元测试

验收测试

代码解释

TypeScript 

智能体

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

DoD：大模型时代的任务完成定义-腾讯云开发者社区-腾讯云

DoD：大模型时代的任务完成定义

DoD：大模型时代的任务完成定义

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐