你让模型”写一份不错的会议摘要”。两分钟后回了 600 字。“不错”吗？你读了。还行。你追问”再好一点”。下一版也还行，方向略微不同。你花了 20 分钟在版本间纠结，没一个让你明确说”对了”。问题不在模型。问题在”不错”：你没说不错是什么样，模型默认走”听着自信”，你默认走”看到就知道”。两个定义构造上都错。Prompt 里没有成功标准时，模型是在”自信”上爬山，不是在”有用”上爬山。
最快的修法： 在 prompt 末尾加一个 5 行的 ## Success criteria 块，把每个形容词都换成一个数字、一个必含项或一个禁词（模板见下面 Step 1），再让模型在停下前对照这个块打印一份 pass/fail 清单。这正是两家厂商都推荐的循环——Anthropic 让开发者在写 prompt 之前先定义具体、可测的成功标准，OpenAI 的 GPT-5.5 指南也说应该”describe the destination”（写清目标结果、成功标准、约束、停止条件），而不是把每一步都写死。
本文讲为什么没有成功标准的 prompt 永远卡在改稿地狱里，以及怎么写一个让”完成”机械化的成功标准块。
常见原因
1. Prompt 写任务，不写门槛
你写了要做什么（“写摘要”）但没写什么算对（长度、必须包含、禁内容）。模型产出”形态合理”的就停。
如何判断：搜 prompt 里”应当”、“通过”、“必须包含”。一个都没有就是没门槛。
2. 质量被默认从上下文知道
“你应该懂我要什么”是真实的内心独白。模型不懂。它没有你团队累积的上下文。
如何判断：你的 prompt 默认和模型共享口味。
3. 多个 stakeholder，多个定义
两个评审对”完成”有分歧。模型平均后谁都不满。
如何判断：评审用不同理由拒绝。
4. 主观形容词冒充标准
“好”、“清晰”、“专业”、“有用”——全不可测。模型用训练分布平均态解读。
如何判断：标准是形容词不是数字/规则/checklist。
5. 每个输入的”成功”不一样
5 行消息的”好摘要”和 50 页报告的”好摘要”不同。标准要随输入规模缩放或写成比例。
如何判断：小输入有效，大输入失效。
真正的成功标准长什么样
Anthropic 自己的开发者指南把”好的成功标准”归纳为四个属性（2026 年 6 月）。这套属性不只适用于 API 开发，任何 prompt 都能借用：
| 属性 | 模糊 | 具体且可测 |
|---|---|---|
| Specific（具体） | “好摘要" | "抓住每个决议、负责人、截止日期” |
| Measurable（可测） | “简洁" | "80-120 字；没有任何一句超过 25 字” |
| Achievable（可达） | “完美" | "对得上我上周接受的那份留底示例” |
| Relevant（相关） | “专业" | "下游 Slack bot 能解析：3 条编号” |
Anthropic 的经典示例就是把”模型应该把情感分类做好”换成”在 10000 条留底测试集上 F1 score 至少 0.85”。日常写 prompt 你很少需要 F1 score，但动作是一样的：把形容词换成一个几秒钟就能核对的数字、必含项或禁词。
动手前先确认
- 用 5 个 bullet 写出完美输出长什么样。
- 5 条里哪些可测，哪些只是 vibe。
- 找一份”完美”历史输出反推标准。
- 想清楚受众和他们拿这个去做什么。
- 标准需要随输入规模缩放就提前规划。
需要收集的信息
- 当前 prompt。
- 2-3 个你接受的输出 + 2-3 个拒绝的。
- 每个接受/拒绝的原因（隐性标准）。
- 下游消费者（人读、parser、数据库）。
- 模型 + system prompt。
最短修复路径
Step 1：加可测的成功标准块
Prompt 末尾：
## Success criteria
- Length: 80-120 words
- Must include: 1 decision made, 1 owner, 1 deadline
- Banned: "circling back", "going forward", "let me know"
- Format: 3 numbered points + 1 followup question
- Tone: 2nd person, present tense, no hedging可测、可强制、易核查。
Step 2：每个形容词换成检查
| 形容词 | 检查 |
|---|---|
| ”好摘要" | "抓住 3 个关键决议。每条决议 ≤25 字。" |
| "清晰写作" | "每句 ≤20 字。无嵌套从句。" |
| "有用分析" | "至少 1 条可执行下一步 + 负责人 + 日期。" |
| "专业语气" | "无感叹号。无 emoji。无第一人称。" |
| "彻底审查" | "引用 3+ 具体行/文件。同时列利弊。“ |
Step 3：让模型对照 rubric 自查
末尾加：
After writing, output a checklist:
- Length: [actual word count] / 80-120 → pass/fail
- Required items present: [list] → pass/fail
- Banned phrases used: [list, or "none"] → pass/fail
- If any fail, rewrite and re-check, then print the final pass/fail.不靠人 reviewer 就能挡掉问题。有两个细节让自查真正可靠，都直接来自 Anthropic 的 LLM 评分指南（2026 年 6 月）：
- 强制给出离散结论。 让模型输出
pass/fail或 1-5 分，绝不要一段话。“纯定性的评判很难快速、规模化地核对。” - 先推理再下结论。 让模型在打分前先想一遍，能提升判断密集型任务的评分准确度。在推理模型上（GPT-5.5 Thinking、Claude Opus 4.7、Gemini 3.1 Pro）还能更进一步：让它先建一个 5-7 个类别的 rubric，给自己打分，没拿到每个类别的最高分就重写，再给最终答案——OpenAI 的 GPT-5.5 cookbook 对高风险输出正是这么建议的。
凡是要反复跑的 prompt，把评分搬进一个真正的 eval harness（一小组接受/拒绝示例，每次改 prompt 都重新打分），而不是逐个用肉眼看。怎么搭这个打分集见评判标准模糊。
Step 4：给”通过”和”不通过”示例
Passes the criteria:
"1. Decision: ship v2 on Friday. Owner: Alex. Deadline: 2026-05-26.
2. Decision: hold the launch tweet. Owner: Sam. Deadline: TBD.
3. Decision: roll back if error rate > 2%. Owner: on-call. Deadline: continuous.
Follow-up: who owns the rollback playbook?"
Fails the criteria (too vague):
"The team aligned on shipping the new feature soon and will keep an eye
on metrics. Sam will coordinate communications. Let me know if questions."对比远强于描述。
Step 5：随输入缩放标准
输入会变的任务：
Success criteria (scaled):
- Length: min(input_word_count / 10, 200) words
- Must capture: at least 1 decision per 100 words of input
- ...Step 6：稳定标准挪到 project / system 指令
老在写一样的标准就挪到一个常驻指令里，让每一轮都自动继承。截至 2026 年 6 月，放置位置是：
- ChatGPT： 某个 Project 的 instructions，或自定义 GPT 的 “Instructions” 字段。
- Claude： 某个 Project 的 custom instructions，或 API 的
systemprompt。 - Gemini： 某个 Gem 的 instructions，或 Settings 里的 “Saved info”。
省 prompt 空间，跨轮门槛一致，而且标准只在一处维护。
怎么确认已经修好
- 每个输出模型自检都过。
- 两个评审看同一输出，accept/reject 结论一致。
- 同 prompt 跑 3 次，3 个都过标准。
- 你判断”完成没”用不超过 60 秒。
- “再做好点”不再是主要追问——具体修复取代了。
如果还是没修好
- 标准可能还是太虚——自己写一个”通过”示例；你的示例都模棱两可就说明标准松。
- 加 1-2 个 pass/fail 示例；few-shot 胜规则。
- 任务可能真的没有单一成功——拆子任务、各自给标准。
- 评审对过标准的输出仍分歧 = 标准没捕到你真要的东西——修改。
预防建议
- 默认：每个 prompt 末尾都带可测成功标准块。
- 按任务类型建模板，标准可复用。
- 团队任务：先共同定义成功，再交给 AI。
- 每月审已接受输出：是真过了标准还是只过了 gut？
- “再做好点”是一个 smell——这话出口就说明标准缺或错。
- 不知道好是什么样时让模型先给 3 套候选，你选一个。
常见问题
一个成功标准块该有几条？
3 到 6 行。Anthropic 指出大多数真实任务需要沿多个维度（长度、必含项、语气、格式）做”多维”标准，但超过大约 6 行通常意味着你在编码一种自己还没想清楚的口味。先从真正导致拒绝的那 2-3 条开始，只有当输出过了这个块你却仍然拒绝时，再加新条。
严格的成功标准块会不会让输出变得僵硬、扼杀创造力？
不会——只要你约束的是门槛，不是路径。现代模型在你”describe the destination”（写清结果以及如何评判它）、把路线留给它时表现最好——这正是 OpenAI 对 GPT-5.5 的明确建议。禁掉”circling back”、要求每个决议带一个负责人，约束的是形式，不是想法。如果输出读着平淡，那是你的标准在过度规定措辞而不是结果；放松措辞规则，保留必含项即可。
模型自查说”pass”，但输出还是错的，为什么？
清单在核对错误的东西。自查只验证你写下的标准，所以”过了却仍然错”意味着标准漏掉了你真正在意的点。把那份输出原样拿来，写下你为什么拒绝它，再把这个理由作为新的一行加进去。这是收紧松标准最快的办法。另外要把结论强制成一个字面的 pass/fail token，而不是一段话——你要一段话，模型会替自己把 pass 合理化掉。
能让 AI 帮我写成功标准吗？
能，而且是个不错的起手。把你接受的 2-3 个输出和拒绝的 2-3 个粘进去，让模型推断区分二者的规则，再让它给 3 套候选成功标准块。挑最好的那套，手工再改一遍。别上线你没读过的标准——模型很乐意编一套听着合理、其实不是你要的门槛。
我的 prompt 短输入有效、长输入失效，是标准问题吗？
通常是。固定的”80-120 字”规则对 50 页报告就是错的。把门槛写成比例或下限（见 Step 5）：length = min(input_words / 10, 200)，以及”输入每 100 字至少抓 1 个决议”。标准不随输入规模缩放，是调好的 prompt 一换到更大任务就崩的最常见原因。