需求验收标准缺失，为什么测试越做越被动

需求只写“增加导出功能”，测试拿到版本后才发现没人说明字段、权限、格式和失败提示。验收标准不是测试部门补的说明书，而是产品在开发前对完成结果的承诺。它是AI拆用例和发布检查的共同输入。落地时每个结论都要回到版本、需求、用例、缺陷或知识库证据，AI只负责分析、解释和提醒。

产品写下“支持批量导出”，开发按自己的理解完成，测试开始追问：最多导多少条、有哪些字段、无权限数据怎么处理、失败后是否重试。问题在测试阶段爆发，看起来像测试卡住了，实际上需求从未定义完成。

验收标准的价值，是在开发前把“做到什么算完成”说清。它不是测试人员最后补的一组用例，也不是一句“符合原型”。

“登录失败时给出友好提示”，测试根本无法按这句话收口

产品验收时说“账号不存在要提示重新输入”，开发按安全规范实现了“账号或密码错误”，测试又追问连续失败几次后锁定、验证码是否失效、内网账号与手机号绑定冲突怎么处理。每一个问题都合理，但它们直到测试阶段才出现，就变成了返工。

验收标准缺失时，开发实现的是自己的理解，测试验收的是另一个理解，产品最后再用口头补齐。这就是“测试越做越被动”的真正原因。

每条验收标准只验证一件事

一条可用的验收标准包括编号、验收点、通过条件和验证方式。例如：AC-001，普通成员只能导出有查看权限的数据；通过条件是导出文件不包含无权字段；验证方式为权限测试用例。

如果一条标准同时包含十个条件，后续很难判断到底哪部分失败。拆成独立条目后，需求详情可以清楚显示哪些已覆盖、哪些待测试、哪些未通过。

产品负责人先写业务结果

产品负责人最清楚用户目的和业务规则，应在需求进入评审前写出验收标准。测试负责人负责补充异常、边界、兼容和回归场景；开发负责人评估实现和技术约束。

这不是把测试工作前移给产品，而是让三方在编码前发现理解差异。对于涉及UI或素材的需求，美术负责人还需要提供视觉验收条件，避免“差不多”成为唯一结论。

AI拆用例必须以验收标准为锚点

AI可以根据需求、原型、接口文档和历史缺陷快速生成用例草稿，但每条关键用例都应回到一个验收点或版本风险。没有验收标准时，AI会把通用测试套路写得很完整，却不一定覆盖业务真正关心的结果。

嘟哩项目的用例管理应显示来源：这条用例关联哪个需求、哪个AC、引用哪些知识库资料。测试负责人确认后才成为正式用例。

需求变化后要自动暴露影响

当验收标准修改，已关联用例不能悄悄保持“已通过”。系统应标记为需更新，提醒测试负责人重新确认。影响到发布检查的关键项，也应同步改变状态。

这条机制能阻止一种常见假象：需求已经改了三次，测试报告仍显示旧用例全部通过，管理者据此认为版本可以上线。

在嘟哩项目中的具体改造

需求新增产品负责人、测试负责人、美术负责人和验收标准。需求列表可筛选“验收标准缺失”和“用例未覆盖”；没有负责人或标准的需求不能进入相应阶段。

先在一个真实版本里执行，不必一次改完历史需求。统计评审后追加规则的次数、测试阶段反复确认的次数和因理解差异返工的缺陷，能直接看出这项改造有没有价值。

一条可执行的验收标准要能直接变成用例

不要把验收标准写成“功能正常”。对账号锁定，可以直接写成：

字段	示例
前置条件	账号状态正常，管理员配置连续 5 次密码错误后锁定 30 分钟
用户动作	同一账号在 10 分钟内连续 5 次输入错误密码
系统结果	第 5 次后账号进入锁定，不暴露账号是否存在，正确密码也无法登录
可见证据	客户端提示、账号状态、安全日志时间和来源 IP 一致
例外	管理员解锁后立即可登录；自动解锁不清空原安全日志

嘟哩项目的需求对象需要补产品负责人、测试负责人、美术负责人和验收标准等字段。AI 拆用例时，以这些结构化标准为锚点，补充权限、边界、异常和恢复场景，而不是从一句需求标题猜整套规则。

变更后必须看到影响链

把“5 次锁定 30 分钟”改成“3 次锁定 15 分钟”时，系统应该标记哪些用例需重新确认、哪些已开发任务受影响、安全文档是否需更新。只修改需求文字而不暴露下游影响，验收标准就又回到了一份孤立文档。

验收标准缺失时，测试不应该被迫猜

需求写着“优化注册流程”，测试只能凭经验拆用例。提测后产品说法人认证弹窗也算范围，研发说只改官网购买链路。缺的是一开始没有把验收标准写成可验证条目。

环节	要记录什么	通过标准
需求描述	业务目标、用户角色、入口、结果	说清要解决什么
验收标准	前置条件、操作步骤、预期结果、异常	测试可以直接拆用例
负责人	产品、测试、设计、相关业务方	争议有确认人
变更	新增标准、删除标准、影响范围	版本中途可追踪

嘟哩需求管理新增产品负责人、测试负责人、美术负责人和验收标准后，AI 才能基于需求和文档拆用例。否则拆出来的只是通用测试建议。

怎么验收

随机抽一个需求，让测试不问产品直接写用例。如果无法覆盖主流程和异常流程，说明验收标准仍不够明确。

真正落到产品页面时，要看到这些东西

项目经理进入嘟哩项目生命周期页面时，第一眼应该看到一个真实版本的当前状态，而不是一段功能介绍。入口动作也要直接：从新建版本开始补目标、人员、需求、用例和知识库绑定。用户每做一步，系统都要把输入、确认人、状态和产物留下来，后面 AI 才有可靠上下文。

页面区域	业务字段	系统状态	AI 动作
需求描述	业务目标、用户角色、入口、结果	当前状态、责任人、来源链接、更新时间	AI 检查“说清要解决什么”，并给出缺口待办
验收标准	前置条件、操作步骤、预期结果、异常	当前状态、责任人、来源链接、更新时间	AI 检查“测试可以直接拆用例”，并给出缺口待办
负责人	产品、测试、设计、相关业务方	当前状态、责任人、来源链接、更新时间	AI 检查“争议有确认人”，并给出缺口待办
变更	新增标准、删除标准、影响范围	当前状态、责任人、来源链接、更新时间	AI 检查“版本中途可追踪”，并给出缺口待办

一天的真实使用路径可以这样设计：早上先打开看板看今日待确认事项；上午补齐缺失资料或接口数据；下午让 AI 生成分析、脚本、用例、风险或方案；执行前由负责人确认关键动作；晚上把结果、问题和下一步沉淀到同一个项目。这样用户不会觉得自己在“找 AI 聊天”，而是在推进一件有开始、有负责人、有产物、有复盘的工作。

产品里还要保留两个不太讨好、但很重要的状态：一个是“资料不足，不能判断”，另一个是“超出当前范围，建议拆分或延期”。这两句话会让页面看起来没有那么神奇，却能减少错误决策。企业场景里，靠谱比炫技更值钱。

边界说明

产研工作流的前置条件是项目对象要结构化。目标、验收标准、用例、缺陷和发布检查没有补齐时，AI 只能提示缺口，不能替管理者做上线判断。

读者真正会感受到的变化

以前项目经理靠群里追问版本状态；现在从版本目标、需求、用例、缺陷和发布检查里直接看结论。产品知道本版重点，测试知道验收边界，研发知道阻塞是谁，管理者不用再把任务数量当成上线依据。这段体验变化要在试点中被记录下来：用了几个入口、问了几个人、返工发生在哪一步、最终产物是否能被下一次复用。只有这些细节存在，文章里的方案才不是概念说明，而是能被团队带回去照着检查的工作方法。

常见问题

验收标准要写到多细？

写到不同角色能对通过与否作出一致判断。实现细节留给技术方案，测试步骤留给用例。

小需求也必须写吗？

可以使用简化模板，但影响权限、数据、费用和发布的需求不应省略。

AI能自动补齐验收标准吗？

AI可以提出草稿和追问，产品负责人必须确认业务承诺，不能把责任交给模型。