验收标准主题 Hub

当工单意图清楚但证据很弱时，就打开这个 Hub。“上传能用”或“用户可以保存设置”适合聊天，不适合实现和 QA。验收标准要把意图翻译成具体状态、触发、结果和证据。

改进弱标准最简单的方法，是补齐缺失字段。缺角色，就写清用户或系统角色；缺初始状态，就补记录、权限或依赖状态；触发含糊，就写精确动作或事件；结果主观，就换成 UI 状态、API 响应、数据库状态、日志或指标。

好的标准也会保护“不能发生什么”。例如不能重复发事件、不能创建第二笔退款、不能暗中扩大权限、不能部分导入却不给错误报告、不能把永久失败继续重试。这些“没有不安全副作用”的句子，常常比 happy path 更能抓 bug。

• 标准里使用快速、正确、合理、顺畅，却没有度量。
• QA 无法根据文字构造 fixture。
• 标准描述内部实现，而不是用户或系统可见行为。
• 没有说明依赖失败或用户重复操作时会怎样。

交接产物要把每条验收标准映射到一个证据来源：测试、fixture、日志、截图或人工检查。PR 评审能直接指向证据时，速度会快很多。

模糊上传工单经常写成“用户可以导入联系人”。有用的验收改写会变成三条检查：干净 CSV 在目标时间内导入；混合有效和无效行时，导入有效行并返回可下载错误报告；重复上传不会创建重复联系人。这三条会逼出文件大小、重复 key、部分成功和用户反馈等决策。

评审者要问 QA 是否能不采访作者就构造 fixture。如果不能，标准仍然太模糊。PR 里应标出每条标准在哪里被证明：解析器单测、重复处理集成测试，以及错误报告路径的截图或日志。

CSV 导入的验收标准只有在区分有效行、无效行、重复行和用户反馈时才有用。这样 QA 才能不用追问作者就准备 fixture。

把这个 Hub 用到真实团队之前，先做一个短审核。第一，读者离开页面时是否能复制一个产物到自己的流程里。第二，关联文章是否分别回答不同问题，而不是重复同一个定义。第三，页面是否点出了生产环境里真的会造成损失的失败模式，而不只是停留在计划阶段。

有用的 Hub 更像工作台。读者应该能打开页面，选择路径，复制片段，并知道评审前要附什么证据。如果页面只是解释主题，它只是另一篇文章；如果它能帮助读者决定下一步怎么做，它才是资源。

最后再问三个问题：这页是否让读者知道第一步该做什么；是否给了可以直接复制的文本；是否说明了什么情况下应该暂停而不是继续推进。只要其中一个答案是否定的，就不要把它当作完成。主题页的价值不是把文章重新包装一遍，而是把分散内容整理成一条能执行的路线。

这也是给审核员看的质量信号：页面有明确主题，有原创组织方式，有表格、流程、示例和行动项，并且能把读者带到下一步资源。它不是为了凑字数存在，而是帮助用户更快判断自己需要哪类规格、哪类证据和哪类评审。