结构化提示生成验收标准的实战方法

能生成可用验收标准的提示结构：五槽位模板、失败模式播种，以及在幻觉场景送到 QA 之前把它们拦下来的评审闭环。

发布于 2026-03-10 · ✓ 已更新 2026-05-06 · 阅读约 7 分钟 · 作者：Spec Coding 编辑部 · 审校：编辑与事实核查政策

我最常见到的提示，恰恰是最失败的那一条

十次里有九次，我看到工程师粘贴给助手的提示都是这么一句：“根据这份功能规格，生成 5 条验收标准的要点。”输出语气自信、格式工整，但几乎毫无用处。你会得到类似“系统优雅地处理错误”“UI 响应迅速”这种要点，彼此互相重叠，根本没法翻译成一条测试用例。我想讲清楚真正能产出可测试标准的提示结构，讲清楚那种能打破“幸福路径默认值”的失败模式播种，以及那个能在 QA 白白浪费一周之前就捕捉到幻觉场景的评审闭环。

五槽位模板就是全部

每一条值得上线的验收标准，都会填满五个槽位：actor（谁发起的）、preconditions（触发前的状态）、trigger（具体事件）、expected outcome（可观察的结果），以及 observable side-effect（其他地方发生了什么变化来证明结果确实发生了）。我会在提示里强制每一条标准都必须产出这五项。side-effect 这一槽位专门用来识别偷懒：如果模型说不出一条审计日志、一行数据库记录、一个发出的事件或一个变化的指标，那这个行为就是不可验证的，这条标准也就没准备好。

失败模式播种胜过幸福路径

放任不管的话，LLM 默认会走阳光大道，而自由格式的要点式提示正好让它借着文笔流畅打马虎眼。我会在每一个生成验收标准的提示里追加一段必填内容：“列出这个功能在生产环境会以哪三种方式崩掉。针对每一种，生成一条能提前捕捉到它的验收标准。”就这一条指令，大致能把标准数量翻一倍，而且分布会明显向 QA 真正在意的场景倾斜。我会搭配边界播种一起用：每个提示都会声明 null、empty、max、min、重复、乱序作为默认的输入形态，模型必须考虑或明确说明为什么可以跳过。我还会强制每条标准都要走一轮正反示例：“Given 输入 X，结果 Y。Given 输入 not-X，结果 Y-prime。”这一步能把那些只在单向成立的标准筛出去。“持有有效 token 的用户可以重置密码”只算半条标准；另一半是“没有有效 token 的用户不能，而且系统返回一个具体的、不泄露信息的错误”。

一个具体的前后对比：密码重置

这是规格：“忘记密码的用户可以通过邮件申请重置链接。链接 15 分钟后过期。已使用的链接不能被二次使用。”

第一版尝试，用那条幼稚的“生成 5 条要点”提示：

• 用户可以申请密码重置。
• 系统发送带有重置链接的邮件。
• 链接 15 分钟后过期。
• 已使用的链接不能被二次使用。
• 系统优雅地处理错误。

每条要点都是规格的复读。没有一条按原文就能测。“优雅地”毫无意义。既没有 actor，也没有 precondition，更没有 side-effect。现在换成五槽位模板加上失败模式播种，处理同一份规格：

Given an unauthenticated user whose email matches an active account
When they submit the reset form
Then the system sends exactly one reset email within 30 seconds
And writes one row to password_reset_requests with a 15-minute expiry

Given a reset link issued 16 minutes ago
When the user clicks it
Then the system shows "link expired" and increments expired_link_attempts
And does not reveal whether the account exists

Given a reset link already consumed once
When the user clicks it a second time
Then the system rejects the request and logs a reuse_attempt event
And the original password remains unchanged

Given an email that does not match any account
When a reset is requested
Then the system returns the same success message as the valid case
And writes nothing to password_reset_requests

第二版是 1:1 可测的。每一段都齐了 actor、precondition、trigger、outcome 和 side-effect。第四段之所以能冒出来，完全是因为失败模式播种逼出了那个问题：“这里会不会泄露账户是否存在？”幼稚的提示根本不会把它暴露出来。

捕捉幻觉的评审闭环

AI 起草标准。人类在十秒内给每条标准打上 testable 或 not-testable。对于每条 not-testable，让 AI 用这句话重写：“rewrite this so a tester can pass or fail it without asking a question.” 上限是三轮；一条标准如果三轮都撑不下来，那就是规格本身坏了，这时候你应该停下来去修规格，而不是继续改标准。闭环的另一半是幻觉检测：把每条标准映射回源规格里的具体条款。如果找不到对应，就拒掉。模型非常乐意凭空编出限流、留存策略和 SLA，而这些根本不在文档里。Trace-to-source 是唯一的防线。

把提示当代码一样存起来，并且知道哪些东西永远不要问

我会维护一个带版本的提示库，每种功能类型一个文件：CRUD、workflow、integration、auth、migration、batch job。每份提示都声明槽位模板、针对该类型特有的失败模式种子、以及需要关注的边界形态。integration 提示默认带上 “network partition、timeout、partial success”。CRUD 提示默认带上 “concurrent write、soft delete、orphan reference”。一旦某份提示产出的标准漏到了生产环境，我更新的是提示本身，而不是只改那条标准。还有几件事永远不要放进任何提示：不要让模型估算业务价值、影响或优先级——它会一本正经地编出错得最难察觉的那种数字。也不要把标准和实现放在同一个提示里要，模型会把标准优化成配合更简单的实现。

当规格和标准对上了

这套流程里最有用的信号，就是生成的标准和规格互相矛盾的那一刻。如果 AI 在五槽位的约束下、并且被要求映射回源规格，产出了一条规格作者不同意的标准，那就说明这份规格没写到位。矛盾本身就是产物。我会带着这个矛盾回到作者那里，只问一个问题：“哪一边是对的？”十次有九次，答案揭示的是一个此前根本没人做过的决定。

元验收标准

如果这套模板真的好用，它应该也能套在自己身上：

Given a feature spec and the five-slot criteria-gen prompt
When an engineer runs the prompt and applies the review loop
Then every output criterion has a filled actor, preconditions, trigger, outcome, and side-effect
And every criterion maps to a specific clause in the source spec
And any criterion failing either check is rejected or sent back for rewrite

这就是底线。低于这条线的一切，都是披着流程外衣的表演。把模板用上，把种子播下去，把闭环跑起来，你的 QA 团队就不会再去追那些本来就不在规格里的幻觉。

评审时看什么

这篇文章适合用在用结构化 prompt 生成验收标准时。别从“原则”聊起，直接拿一条真实改动来对照，看看规格里还缺什么。

• 限定模型只能使用给定材料。
• 信息不足时输出 UNKNOWN。
• 每条 AC 都能改写成 Given/When/Then。
• 检查模型有没有新增原材料里没有的状态或字段。

好的 prompt 不是让 AC 更像文档，而是让缺失信息更早暴露出来。

验收标准 prompt 要逼模型写出失败路径

只要求“生成验收标准”，模型会给你一串漂亮 happy path。更好的 prompt 会固定输入字段，并强制输出成功路径、失败路径、权限路径和可观测证据。

Acceptance criteria prompt:
Input:
- feature goal
- non-goals
- actors and permissions
- data states
- external services
Output:
- 3 happy-path criteria
- 3 failure-path criteria
- 2 permission criteria
- evidence for each criterion: API response, DB row, event, log, UI state

边界：不要让 prompt 自己补业务规则。规则缺失时，让它输出澄清问题，而不是猜一个“合理默认值”。

输出后做一遍字段化

生成的标准如果还停留在“成功显示”“合理提示”，就继续改。把它字段化：API status、error code、数据库状态、事件名称、UI 文案、日志字段。每条至少落到一种证据，否则测试人员还是要重新猜。

我还会让 prompt 输出一段“不可判定项”。如果缺 API 字段、权限 owner、数据状态或回滚证据，就列为问题，而不是硬生成测试。能承认信息不足的 prompt，比装作完整的 prompt 更可靠。

可复制产物：AI 编码评审包

在 AI 生成 diff 进入代码评审前使用。它把提示词范围、允许变更和证据要求合并成一个可审查产物。

AI 编码评审包：结构化提示生成验收标准的实战方法

本次要做的决策：
- 确认 AI 只在批准范围内生成变更，并为每条验收标准提供证据。

责任人检查：
- 产品责任人：
- 工程责任人：
- QA 或运维评审：

范围边界：
- 本次包含：
- 本次不包含：
- 仍需确认的假设：

验收证据：
- 测试或 fixture：
- 日志、指标或截图：
- 人工复核步骤：

AI 边界：生成变更必须留在书面范围内，每条验收标准都要能找到证据。

评审追问：
- 没参加需求会的人还会误解哪里？
- 哪个证据能证明这次改动足够安全，可以发布？

编辑复核记录

复核日期：2026-04-28。本次补充了可复用产物，按相关主题 Hub 检查了文章定位，并收紧下一步链接，让页面更像可操作参考，而不是孤立长文。