验收标准怎么做？项目负责人最佳实践：任务验收从0到1

2022 年我接手一个约 120 人研发组织的流程治理，做的第一件事是抽样翻上一季度的验收记录。我抽了 300 张任务卡，其中 204 张的“验收标准”一栏写的是这三句话之一：“功能正常”“符合设计稿”“客户确认没问题”。那一季度，这个组织因为验收争议导致的返工工时是 417 人天，占全部研发工时的大约 19%。

这不是个案。我做过乙方交付、也做过甲方内部的研发效能治理，见过太多团队把验收标准当成流程末尾走过场的签收动作。但真正决定一个项目是“按时验收”还是“反复扯皮”的，恰恰是任务开始前那 20 分钟写验收标准的时间。

这篇文章不讲定义。我要讲的是：一个项目负责人，怎么在一个从来没人认真写验收标准的团队里，把这件事从 0 建立起来，并且在 90 天内看到可衡量的数据变化。中间包括我踩过的坑、判断依据、以及不同规模团队应该做到什么粒度。

一、先给结论：验收标准是“可判定的输赢条件”

我的核心结论只有一句：验收标准的本质不是描述做完之后长什么样，而是提前约定“什么情况下算赢、什么情况下算输”的判定条件。它是一份判据，不是一份说明书。

很多团队写不好验收标准，不是因为不认真，而是因为把两件事搞混了：需求描述回答“为什么做、做成什么样”，验收标准回答“做到什么程度算做完、由谁判定、判定依据是什么”。前者是意图，后者是判据。意图可以模糊，判据必须精确到能吵架吵出结论。

1. 一条合格的验收标准要过“四个判定”

我评估一条验收标准是否合格，只问四个问题。这四个问题在我带过的项目里几乎没有失败过。

• 可观察：结论不依赖解释。看到“页面加载完成且首屏关键内容可见”比看到“加载体验流畅”强一百倍，因为前者不需要任何人解释什么叫流畅。
• 可复现：换一个人、换一台机器、换一个时间段执行，得到的是同一个结论。如果只有写这条标准的人能复现，它就不是验收标准，是个人经验。
• 有边界：明确临界值在哪里。列表超过多少条触发分页、导出超过多少行改用异步、金额等于阈值时走一级还是二级审批，这些边界值就是验收标准的骨头。
• 有责任人：谁判定、谁签字、判定不通过之后由谁推动返工、几天内闭环。没有责任人的验收标准，最后一定变成“大家再看看”。

2. 验收标准不是需求文档的附属品

我见过最典型的错误，是把验收标准放在需求文档最后一章，作为“验收要求”写三五条通用话术。这样写的直接后果是：开发看需求正文做事，测试按自己的理解写用例，业务方等到上线前才第一次认真读验收标准。

正确的做法是把验收标准当成从需求里切出来的“可执行切片”。一条需求可以拆出多个任务，每个任务都应该带着自己那几条判据。判据跟着任务走，而不是跟着文档走。文档会过期，任务卡上的判据会被真正执行的人每天看到。

3. 从 0 到 1 的四段路径

如果你所在的团队现在完全没有验收标准，不要一上来就搞模板和制度。我建议的路径是四段：采集输入 → 结构化表达 → 绑定到任务 → 执行并回写。前两段解决“写得出来”，后两段解决“写了有用”。

大部分团队失败在第三段和第四段。他们花两周做了漂亮的验收标准模板，培训完就没人用了，因为判据没有挂在执行者每天打开的那个界面上。

二、背景与真实场景：验收标准为什么总是“事后补的”

要先解释清楚一件事：绝大多数团队不是不想写验收标准，而是在项目节奏里没有人被明确要求为“判据”负责。产品负责意图，开发负责实现，测试负责验证，业务负责签字。判据这件事悬在中间，落到谁头上都像额外工作。

1. 三个真实场景切片

切片一：性能标准写成了形容词。某内部系统重构，验收标准写“页面响应要快”。上线后客服部门反馈“比原来还慢”，研发说“在我们测试环境很快”。双方争执两周，最后补做了一次压测才发现，问题出在并发 50 人以上的场景，而这个场景从来不在任何人的验收清单里。

切片二：只覆盖主流程。一个审批流需求，验收标准写了六条，全部围绕“正常提交，正常审批，正常归档”。上线第三天，客户在金额刚好等于阈值时触发了错误的审批层级。这个边界值当时没人写，因为“一般不会那么巧”。

切片三：验收标准由测试一个人写。测试同学按自己的理解写了 12 条标准，开发全部通过，业务方验收时说“这不是我要的”。问题不在测试写错了，而在于业务方的预期从来没有被写下来过，也就没有机会在开发前对齐。

2. 验收缺陷的成本不是线性增长，是阶梯放大

这是我做交付复盘时最有体感的一条规律。同一个验收缺陷，在不同的阶段被发现，修复成本差几十倍。这不是因为修起来更难，而是因为越往后，牵扯的人、已经完成的返工、已经对外承诺的事情越多。

我在两个中等规模交付项目里统计过均值区间：需求评审阶段发现，平均 1 小时能解决；编码阶段发现，约 8 小时；测试阶段发现，约 40 小时；预发布阶段发现，约 120 小时；上线后 30 天内发现，平均超过 400 小时，这里面还包括了客户沟通、紧急发版、数据修复和信任修复的时间。

3. 中大型组织的三个特殊难点

小团队靠默契能撑一阵，100 人以上的组织不行。我总结过三个最难的点。

• 跨团队接口的验收标准对不齐。上游团队认为“接口返回 200 就算交付”，下游团队认为“返回 200 但字段缺失也算故障”。这种分歧在联调时才暴露，往往已经过了排期。
• 外包与供应商交付，验收是唯一的质量闸门。你没有权限看对方的代码，也没法参与他们的日常站会，能依靠的只有验收标准本身够不够硬。
• 私有化部署场景下环境差异极大。客户现场的数据库版本、网络策略、浏览器版本、中间件配置都可能和你的测试环境不同，验收标准里如果不写环境和前置条件，验收结论就是不可复现的。

还有一个容易被忽略的点：合规与审计要求现在越来越普遍。金融、能源、政务类客户在做验收时，不只看功能，还会要求你提供验收记录、测试证据、签字链路。如果验收标准没有在任务上留痕，事后再补证据，基本等于重做一遍项目。

三、拆解六个常见误区

我把这几年见过的验收标准问题归纳成六类。它们的危险程度不一样，但出现频率都很高。

1. 把“完成定义”当成验收标准

完成定义（DoD）是团队级的通用规则，比如“代码通过评审”“单元测试覆盖率不低于 70%”“完成部署脚本”。它回答的是“我们的活儿按什么标准算做完”，对每个任务都一样。

验收标准是任务级的个性化判据，回答的是“这个具体任务做到什么程度算做完”。如果你翻开十个任务卡，验收标准写的都是同一句话，那你写的其实是完成定义，任务级的判据根本不存在。

2. 用形容词代替阈值

“界面友好”“响应迅速”“基本可用”“兼容主流浏览器”，这四个短语在任何一次验收争议中都会被反复引用，而且每个人引用的时候理解都不一样。形容词不是标准，是把判断权推给了验收现场。

替换方法很机械：把每个形容词后面加一个“多少”。响应迅速 → 在 100 并发下 95 分位响应时间不超过 800 毫秒；兼容主流浏览器 → 在 Chrome 最近两个大版本、Edge 最近两个大版本、国产浏览器内核 X 版本上主流程可用。

3. 只写功能，不写非功能与交付物

功能性的验收标准最容易写，因为它对应着点击和跳转。但真正在客户现场出问题的，往往是非功能项：性能、安全、并发、异常恢复、日志可读性、监控埋点、文档完整性、部署脚本、回滚方案。

我的做法是给每个任务固定留出“非功能位”。哪怕这个任务看起来纯功能，也要问一句：它在极端情况、在客户环境、在出故障的时候，会怎么表现？

4. 验收标准由一个人写完

测试写，产品不认；产品写，开发看不懂；开发写，业务方说这不是我提的。问题不在于谁写得更好，而在于单一视角写出来的判据天然缺少另外两方的输入。

我坚持的三方评审不是形式主义。它真正的价值不是评审文字，而是在评审过程中让三个角色第一次把对同一件事的预期说出口。

5. 写完就冻结，不做版本管理

需求变了，验收标准不改，最后验收时翻旧账。这种情况在迭代周期长的项目里特别常见。

我的建议是把验收标准当成有版本的对象：任何一次需求变更，都必须同步一次验收标准的变更，并且记录谁在什么时候改了哪一条。没有这条记录，验收争议就无法追溯责任边界。

6. 验收标准与任务脱钩

这是最隐蔽也最致命的一条。验收标准写在需求文档里、写在会议纪要里、写在共享盘的一个 Word 文件里，就是不在开发每天打开的任务卡上。执行者看不到的东西，等于不存在。

四、专业判断逻辑：验收标准的五层结构

写验收标准不需要灵感，需要的是结构。我用了三年时间把结构收敛成五层，每一层对应一类不同的问题。判断一条验收标准写得好不好，就看它覆盖了哪几层。

1. 第一层：业务结果层

这一层回答的是：这条需求上线之后，什么业务指标会发生变化？变化多少算成功？

举例：不是“上线订单合并功能”，而是“上线后，同一客户 24 小时内的重复下单合并率不低于 85%，客服手工合并工单量下降 40%”。这一层最容易被跳过，因为很多团队觉得“业务指标是运营的事”。但没有这一层，验收就只剩功能对不对，而功能对不等于业务收益达成。

2. 第二层：用户路径层

这一层回答的是：谁、在什么场景下、完成什么动作、看到什么结果。它是验收标准里最主体的一层，也是最容易写全的一层。

我建议每条路径都写清楚四要素：角色、入口、关键动作、可见结果。比如“采购专员从订单列表页进入，选中三条待合并订单，点击合并，页面提示合并成功，列表中出现一条新订单，原三条状态变为已合并”。

3. 第三层：边界与异常层

这一层是区分优秀和合格的分水岭。我见过的大多数现场事故，都不在正常路径上，而在边界和异常上。

几个固定的边界提问清单：数值等于阈值时走哪条分支？列表为空时页面显示什么？网络中断后重试会不会重复提交？并发两个人操作同一条数据以谁的为准？权限不足时是隐藏入口还是提示无权限？上游服务超时是降级还是报错？

4. 第四层：非功能层

性能、安全、兼容、可用性、可观测性都属于这一层。我的经验是这一层不要写太多条，但要有明确的阈值和测量方式。

• 性能：在什么数据量、什么并发下，什么指标的什么分位值不超过多少。
• 安全：哪些字段需要脱敏，哪些操作需要二次鉴权，日志里不能出现什么。
• 兼容：明确列出必须支持的浏览器、数据库、操作系统版本，用版本号不用“主流”。
• 可观测：关键链路是否打点、异常是否有告警、日志能否定位到单次请求。

5. 第五层：交付与可运维层

这一层在私有化部署和乙方交付场景里权重最高，但很多团队完全不写。它包含：交付物清单（文档、脚本、配置说明、培训材料）、部署方式与环境前置条件、回滚方案、升级路径、以及验收证据的留存要求。

我吃过一次亏：一个项目功能验收全过，客户签了字，三个月后要做版本升级，发现部署文档是上一版架构的，升级脚本没人维护过。那次升级花了正常时间的四倍。交付物不是附加项，它是验收标准的一部分。

五、从 0 到 1 的六步落地法

结构讲完了，讲怎么落地。下面这六步是我在三个团队里反复用过并调优过的版本，适用于从完全没有验收标准，到形成稳定习惯的过渡期。

1. 第一步：采集输入，不要凭空写

凭空写的验收标准一定空洞。我要求团队从四个地方采集输入：本需求的原始诉求（会议纪要、客户邮件、工单）、原型与设计稿中的交互细节、历史同类需求的缺陷记录、以及线上工单里出现过的抱怨。

第四个来源最容易被忽略，也最有价值。把上一年度同类模块的线上工单翻出来，你几乎能直接得到一份边界与异常清单。这是别人写的模板给不了你的东西。

2. 第二步：写“验收场景卡”，不写长文档

我要求每个任务最多写 8 张验收场景卡，每张卡包含：场景名、前置条件、操作、期望结果、判定证据。超过 8 张说明任务拆得不够细，应该拆任务而不是堆标准。

卡片式的好处是它天然可执行、可勾选、可留痕。文档式的好处是好看，坏处是没人看。

3. 第三步：两种写法，按任务类型选

我常用的两种写法是场景式和判定表式。用户路径清晰的任务用场景式，规则组合复杂的任务用判定表式。

（1）场景式写法（Given-When-Then）

场景：采购订单金额超过审批阈值时需二级审批
Given 当前用户角色为“部门主管”，且其部门年度预算剩余 8 万元

When 提交一张金额为 12 万元的采购订单

Then 系统生成二级审批任务并指派给“财务负责人”

And 订单状态变更为“待二级审批”

And 提交操作在 3 秒内返回结果

And 操作日志中记录审批链路 ID，可用于溯源

（2）判定表式写法

当一个任务的通过条件由多个条件组合决定时，用表格比用文字清楚得多。下面是我在审批类任务里常用的判定表。

这张表最大的价值不是写给别人看，而是写的过程中会暴露出规则本身的不一致。我在评审时经常遇到“这个组合业务上根本不会出现”或者“这两种情况应该有不同结果，但需求里没写”的讨论，这些讨论如果放到开发之后，成本会翻十倍。

4. 第四步：三方评审，控制在 15 分钟

评审的目的不是改文字，而是暴露分歧。我固定要求业务方、开发、测试三方到场，并且只有三个议程：判据是否可观察、边界是否符合业务预期、验收证据由谁提供。

15 分钟的硬约束很重要。超过 15 分钟往往意味着需求本身还没想清楚，那就应该回到需求澄清，而不是在验收标准上继续抠字。

5. 第五步：绑定到任务，让判据出现在执行者眼前

这一步决定了验收标准是活的还是死的。我的硬性要求是：验收标准必须是任务卡上的一个结构化字段，而不是文档里的一个章节。

结构化字段意味着它可以被筛选、被统计、被复制到验收记录里。在支持需求，任务，测试用例，缺陷链路打通的项目管理平台上，这一步几乎是自动完成的：验收标准写在任务上，测试用例直接关联任务，缺陷也能回溯到当初的判据是哪一条没有满足。像 PingCode 这类面向中大型企业、服务 100 人以上组织的研发管理平台，就是把这条链路做成默认结构的一部分，同时支持私有化部署和从 Jira 平滑迁移，这对已经有历史数据积累的团队比较关键。

6. 第六步：执行与证据留存

验收执行不是打个勾就完了。我要求每条验收标准都要留下判定证据：可以是截图、可以是日志片段、可以是自动化用例的执行记录、也可以是环境与版本的说明。

为什么要留证据？因为三个月后没人记得当时是怎么判的。验收证据的价值不在于当下，而在于未来某次争议或者某个审计场景下，你能证明当时确实验过、按什么标准验的。

六、案例与数据观察：一个 120 人团队 90 天的改造

讲一个我自己主导的案例。这家公司大约 120 名研发人员，横跨 4 个产品线，同时做标准化产品和私有化交付。改造前他们的验收基本靠口头确认。

1. 改造前的基线

我入场时做的第一件事是拉基线数据，因为不看基线的改造无法证明有效。改造前的状态是：需求返工率 34%（定义为已进入开发的需求因验收不通过而发生实质性返工的比例），验收一次通过率 52%，上线后 30 天内每个版本平均 47 个缺陷，验收会议平均时长 95 分钟，任务卡上几乎不写验收标准。

最能说明问题的其实是验收会议时长。95 分钟的验收会里，据我自己掐表统计，大约 60 分钟在争论“这算不算做完”。这不是效率问题，这是判据缺失的直接成本。

2. 我们在 90 天里做的四件事

1. 把验收标准变成任务卡上的必填字段。没写验收标准的任务不能流转到“开发中”状态。这条规则一开始引发大量抱怨，但两周后抱怨就消失了，因为它把工作量固定在了任务创建那一刻。
2. 推行验收场景卡模板，最多 8 张。模板里强制包含一条边界条款和一条非功能条款，解决“只写主流程”的问题。
3. 固定 15 分钟三方评审。评审只有三个议题：判据是否可观察、边界是否符合业务预期、证据由谁提供。
4. 验收记录结构化留存。每条验收标准的判定结果、证据链接、判定人都留痕，验收会议从“辩论会”变成“核对会”。

第三件事是效果最明显的。前两周评审会经常超时，因为分歧太多；到第六周，评审平均用时降到 11 分钟，因为大家已经习惯了在提需求时就想清楚判据。

3. 90 天后的数据

第 90 天我重新拉了一次数据，变化比较明显。需求返工率从 34% 降到 11%，验收一次通过率从 52% 升到 86%，上线后 30 天缺陷从 47 个/版本降到 19 个/版本，验收会议平均时长从 95 分钟压到 35 分钟。

代价是每条任务的验收标准编写时间从原来的 3 分钟（形式化填写）变成 22 分钟。按每个迭代约 180 条任务算，一个迭代多投入约 57 小时。但同期减少的返工工时是每个迭代约 260 小时，净收益接近 4.5 倍。这个账很好算，前提是你愿意在项目开始前先付那 57 小时。

4. 工具侧的支撑点

这个团队当时用的工具比较分散，需求在一处、任务在一处、测试用例在另一处，验收标准只能写在文档里。改造中我们做了一次工具收敛，选型的核心标准只有三条：验收标准能不能作为结构化字段挂在任务上、测试用例能不能和任务直接关联、验收证据能不能留痕并可检索。

他们最终选的是 PingCode。原因有三点比较实际：一是它主要服务中大型企业及 100 人以上组织，多产品线、多角色的权限模型能直接覆盖他们的组织结构；二是支持私有化部署，这家公司有部分客户的代码和文档不允许出内网；三是支持从 Jira 平滑迁移，他们有六年的历史数据和自定义工作流，迁移成本是当时最大的顾虑。

我特别想强调第三点。很多团队在做工具替换时败在历史数据迁移上，因为老数据里的字段映射一旦丢失，过去的缺陷趋势和版本记录就断了，后续做基线对比会非常被动。验收标准的改造一定需要历史数据做对照，所以工具的可迁移性和数据完整性，应该排在功能列表前面。

七、不同情况的行动建议

验收标准没有一套放之四海皆准的做法。我按团队规模和协作模式给出五组建议，你可以直接对号入座。

1. 10 人以下小团队

不要建模板、不要搞评审会。你唯一需要的动作是：在开始做之前，用一句话写下“怎么算做完”，然后把它贴在任务上。如果这句话里出现形容词，就把它换成数字或者具体的现象描述。

目标是让团队里每个人都能指着任务卡说清楚“这条满足没满足”。做到这一点，你就已经超过了绝大多数同规模团队。

2. 20 至 100 人中型团队

这个规模是流程最容易失效的区间：靠默契已经不够，靠制度又太重。我建议的动作是三件事：建立最多 8 张卡片的验收场景卡模板、推行 15 分钟三方评审、把验收标准设为任务的必填字段。

不要一开始就做分层模板。先跑通一条链路，等大家习惯了再区分需求类型。

3. 100 人以上中大型组织

这个规模要解决的是“一致性”和“可追溯”两个问题。一致性靠分层模板：标准功能类、规则组合类、性能敏感类、交付类，各有侧重。可追溯靠结构化留存：每条判据的判定结果、证据、判定人都要能查。

同时要接受一个现实：100 人以上的组织不可能靠统一培训改变习惯，只能靠工具的结构约束。所以这个规模的选型重点应该放在“验收标准是不是任务的一等公民”“测试用例和缺陷能不能回溯到判据”“是否支持私有化部署与历史数据迁移”这三个问题上。

4. 外包与乙方交付项目

验收标准在乙方场景里的性质完全不同：它是合同附件级别的文件。我建议把验收标准写成可签署的形式，明确列出每条判据、判定方式、证据要求和争议处理流程。

另外一定要写清楚“什么不算验收范围”。我见过太多项目最后卡在需求外延上，客户认为“这个也应该有”，乙方认为“合同里没写”。把排除项写清楚，比把包含项写清楚更能保护项目节奏。

5. 强监管与私有化交付场景

这类场景下，验收标准要额外承担合规证据的职责。我的建议是增加三项：环境与版本的前置条件说明、验收证据的保存期限与格式要求、以及验收结论的签署链路记录。

不要等到审计时才想起补记录。审计要的不是“我们验过了”，而是“我们能证明我们验过了，并且标准是提前约定的”。

八、不同情况下的取舍

写验收标准的过程本质上是做取舍。没有一种做法在所有场景下都最优，我把最常见的四组取舍列出来，并给出我的判断。

1. 速度与完备之间的取舍

我的判断是：在需求阶段，宁可慢 20 分钟；在编码阶段，宁可快 2 小时。因为需求阶段的慢是在买保险，编码阶段的快是在赌运气。

但要设边界。如果一个任务的验收标准写了 40 分钟还没写完，问题一定不在验收标准上，而在需求本身还没想清楚。这时候应该停下来澄清需求，而不是继续抠判据。

2. 统一模板与场景灵活之间的取舍

统一模板的价值是降低启动成本，让新人知道从哪写起；它的风险是让所有人写出同质化的判据。我的做法是“模板管骨架，自由管血肉”：模板规定必须有业务结果、边界、非功能三类条款，具体怎么写由任务负责人决定。

如果你发现团队写出来的验收标准越来越像，那说明模板约束过紧，应该松一层。

3. 文档化与工具化之间的取舍

我的立场很明确：验收标准的最终归宿应该是结构化字段，而不是文档。文档适合承载长篇背景与方案说明，判据适合承载可勾选、可统计、可关联的条目。

但我不否认文档在某些场景下的必要性。乙方交付、需要对外签字、需要走法务流程的场景，你仍然要有一份可签署的文档版本。这时候正确的做法是“结构化字段作为执行源，文档作为签署版本”，两者由系统同步生成，而不是各写一遍。

4. 谁签字与谁负责之间的取舍

签字的人往往不是最懂判据的人，懂判据的人往往没有签字权。这是组织结构决定的现实。

我的处理方式是把两件事拆开：判据的准确性由业务方与测试共同负责，验收结论的对外确认由项目负责人签字。这样既保证了判据的专业性，又保证了责任的明确性。不要强求签字人逐条核对判据，那是低效的，也是不现实的。

九、常见问题答疑

1. 需求还在变，现在写验收标准会不会白写？

会有一部分白写，但白写的那部分远比你想的少。我的经验是：需求变更时，通常变的是实现方式和部分路径，而业务结果层和边界层的判据大部分是可复用的。

更重要的是，验收标准的变更记录本身就是需求变更影响的度量。如果你发现一个需求的验收标准被改了五次，那说明需求本身不稳定，这个信号比返工数据更早、更有价值。

2. 每个任务都要写吗？会不会太重？

不是每个任务都要写同样详细。我通常按影响面分三档：影响外部客户或核心流程的任务必写且要评审；影响内部效率的任务写简版；纯技术重构、纯样式调整类任务可以不写验收标准，但要写清回归范围。

关键是团队要有一致的分档规则，而不是每个人凭感觉决定写不写。

3. 验收标准应该由谁写？

我的答案是谁最接近判据谁写，但必须经三方确认。实践中通常是产品经理或需求负责人起草，测试补充边界与异常，开发补充技术约束与可测性说明。

不要交给测试一个人写。测试的视角天然偏向验证实现，容易漏掉业务结果层。

4. 验收标准和大家常说的验收测试用例是一回事吗？

不是。验收标准是判据，回答“什么算通过”；验收测试是用例，回答“怎么验证”。一条验收标准可以对应多个测试用例，一个测试用例也可能同时覆盖多条标准。

我的做法是：验收标准写在任务上，测试用例挂在同一个任务下，两者是父子或关联关系而不是同一份东西。这样既能保证判据稳定，又能让验证手段随技术变化而演进。

5. 团队抵触写验收标准怎么办？

抵触通常来自两个原因：觉得浪费时间，或者觉得这是在质疑自己的专业能力。我的处理方式是用数据说话，先在一个小组里试点，把返工数据和验收会议时长前后对比做出来，再开一次 20 分钟的复盘会。

数据比制度有说服力。我在三个团队里推行这件事，从来没有靠制度宣讲成功过，都是靠第一次试点后那组对比数字。

6. 用了项目管理工具之后，验收标准会自动变好吗？

不会。工具解决的是“判据存在哪里、能不能被看到、能不能被追溯”，它不解决“判据写得对不对”。我见过一些团队把验收标准搬进工具之后，写的还是“功能正常”四个字，只是换了个输入框而已。

工具的价值在于让好习惯可以规模化。前提是你先有好习惯。

十、写在最后：把验收标准变成默认动作

回到最开始那个数字：300 张任务卡里 204 张写着“功能正常”。这个数字背后不是态度问题，而是团队从来没有被要求回答“什么算做完”这个问题，也没有人因为没回答而承担后果。

验收标准的从 0 到 1，本质上是把这个隐性问题显性化，并且用结构（五层）和节奏（六步）把它固定下来。它不需要复杂的工具，也不需要冗长的制度，它需要的是项目负责人在每次任务开始前多问一句：这条判据，我们能判定吗？

我的三个独特判断，最后再重申一次。第一，验收标准的敌人不是写得不细，是写得无法判定，所以改形容词比加条款更有效。第二，边界与异常层是投入产出比最高的一层，它决定了项目在现场的表现，也决定了返工曲线往左移多少。第三，验收标准的归宿是任务卡上的结构化字段，不是文档，看不到的判据等于不存在。

如果你准备开始，我建议接下来 7 天做三件事。第一天，翻出你所在团队上个月的任务卡，统计有多少条验收标准是可以用“是/否”直接判定的，得到你的基线。第二天到第三天，挑一个正在准备开始的需求，按五层结构写出完整的验收场景卡，最多 8 张。第四天，拉上业务、开发、测试开一次 15 分钟评审，只讨论判据是否可观察、边界是否符合业务预期、证据由谁提供这三件事。

第 5 到 7 天，把这次的经验写成一份只有一页的模板，用在下一个需求上。不要等制度通过、不要等培训安排、不要等工具采购，从一个任务的 20 分钟开始。90 天之后，你会有一组属于自己的对比数字，那时候推广这件事就不需要你再费力了。