附录 A：文本 Prompt 配方库

如果你的 Prompt 充满“请帮我”“尽量”“注意一下”，那你不是在做工程，你是在做许愿。许愿当然偶尔会灵，但你要的是可交付、可复跑、可回滚。

这份配方库的目标不是让你收藏“神句”，而是让你把 Prompt 写成接口：输入契约、输出协议、失败判定、回滚动作一次写清。相关基本功先看这几章：

• 分级与合同：01-mindset.md
• 事实与证据：02-facts.md
• 载体与协议：05-medium.md
• 回归与门禁：06-feedback.md

总原则（先把接口写清再写正文）

1. 先写输出协议：你要 JSON 就给 Schema；你要表格就锁列名；你要 Markdown 就锁标题层级。
2. 先写失败判定：什么情况下算失败，必须可检测；“感觉不对”不算判定。
3. 先写未知出口：缺信息就输出“材料未提及/无法确认 + 缺口清单”；编造才是失败。
4. 把禁止项写硬：禁止寒暄语、禁止解释性前言、禁止 Markdown 包裹 JSON、禁止新增字段。
5. 把回滚写可执行：失败后重试一次？降级成简版？返回固定错误结构？切回旧版本？必须写在合同里。

---

配方 01：残酷摘要（执行摘要）

用途

把长文本压缩成可决策的执行摘要，剔除形容词与寒暄语，避免“摘要比原文还长”。

输入契约

<raw_text>：原始文本（建议一段，不要混多篇）。

输出契约

只输出 Markdown，且仅包含两段： 1) ## 执行摘要：最多 3 条要点，每条一行
2) ## 行动项：最多 5 条，每条一行

Prompt 模板

你是中文技术文档编辑（不是聊天助手）。

任务：把输入内容压缩为执行摘要与行动项。

输出协议（硬约束）：
1) 只输出 Markdown。
2) 只允许两个二级标题：## 执行摘要、## 行动项（标题名不得改动）。
3) 执行摘要最多 3 条；行动项最多 5 条；每条必须是一行短句。
4) 禁止：寒暄语、解释性前言、空泛口号、比喻段落。

输入：
<raw_text>

CLI（示例）

{ cat prompts/summary.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/summary.md

失败判定

• 缺少固定标题或标题名变化
• 执行摘要超过 3 条或出现长段落

回滚/降级

输出“无法稳定摘要，改为输出原文关键句前三条”，并直接截取原文中最短的三句。

---

配方 02：结构化抽取（纯 JSON）

用途

把非结构化描述抽取为可被解析器消费的 JSON，避免字段名漂移与“解释性文本污染”。

输入契约

<raw_text>：包含事实或事件的文本（可含多条）。

输出契约

只输出 JSON 字符串本体（不要代码块），且严格符合 Schema： - 顶层：对象
- 字段：summary（string）、items（array of object）
- 每个 item：id（string）、issue（string）、fix（string）

Prompt 模板

你是结构化信息抽取器（不是聊天助手）。

任务：从输入文本中抽取问题清单。

输出协议（硬约束）：
1) 只输出 JSON 字符串本体（禁止 Markdown 代码块）。
2) 只允许字段：summary、items、id、issue、fix（禁止新增字段）。
3) items 为空时必须输出空数组。
4) 若无法生成合法 JSON：返回固定错误结构 {"error":"SCHEMA_FAIL","reason":"<reason>"}。

JSON Schema（供你遵循）：
{
  "type": "object",
  "properties": {
    "summary": { "type": "string" },
    "items": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": { "type": "string" },
          "issue": { "type": "string" },
          "fix": { "type": "string" }
        },
        "required": ["id", "issue", "fix"]
      }
    }
  },
  "required": ["summary", "items"]
}

输入：
<raw_text>

CLI（示例）

{ cat prompts/extract-json.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/result.json

失败判定

• 输出不是合法 JSON（解析失败）
• 出现未定义字段或输出被 Markdown 代码块包裹

回滚/降级

返回固定错误结构并落盘原始输入到 dead-letter/ 目录，交给人工处理。

---

配方 03：证据矩阵（事实类输出的底盘）

用途

强制模型把结论绑定到证据单元与来源标识，拒绝“一本正经地编造”。方法论详见 02-facts.md。

输入契约

<material>：材料片段，必须包含来源标识（文件名/章节/片段 id 等）。

输出契约

先输出证据矩阵表格，再输出缺口字段清单；缺口为空输出“无”。

Prompt 模板

你是审计员。只基于输入材料输出可核查结果。

硬约束：
1) 仅基于输入材料；禁止外部补全。
2) 缺信息必须输出“材料未提及/无法确认”，并列出缺口字段清单。
3) 发现冲突必须并列展示差异；禁止调和或替人裁决。

输出（顺序固定）：
1) 证据矩阵（Markdown 表格，列名固定：claim_id/结论/证据/来源标识/冲突/不确定性）
2) 缺口字段清单（若为空输出“无”）

输入材料：
<material>

CLI（示例）

{ cat prompts/evidence-matrix.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/evidence.md

失败判定

• 输出没有来源标识或把冲突“合并成一个答案”
• 关键结论没有对应证据单元

回滚/降级

若材料不足，直接只输出缺口字段清单（不输出任何结论）。

---

配方 04：方案对比表（强制对齐维度）

用途

把“各说各话”的选型讨论压成二维对齐表，逼迫结论可审计、可反驳。

输入契约

<options>：两个或多个方案描述（每个方案一段）。

输出契约

只输出 Markdown 表格，列名固定：维度/方案A/方案B/推荐结论/风险。若超过两方案，允许追加方案列，但必须保留前后两列不变。

Prompt 模板

你是严谨的技术评审员。

任务：对齐维度并输出对比表。

输出协议（硬约束）：
1) 只输出 Markdown 表格；禁止任何表格外文本。
2) 列名固定：维度/方案A/方案B/推荐结论/风险。
3) “维度”按重要性降序排列；每行必须可裁决。
4) 不确定项必须标注“待验证”，并写清需要补什么证据。

方案材料：
<options>

CLI（示例）

{ cat prompts/compare-table.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/compare.md

失败判定

• 不是表格或列名漂移
• 推荐结论没有对应风险或依据

回滚/降级

降级为“维度清单 + 待验证项清单”，停止给推荐结论。

---

配方 05：代码审查（只要结论与依据，不要废话）

用途

让模型输出可消费的审查报告：无问题输出 PASS；有问题按固定结构输出，便于机器拦截。

输入契约

<code_or_diff>：代码片段或 diff。

输出契约

只输出 Markdown，且要么是 PASS，要么是固定结构报告（标题名与表格列名不可变）。

Prompt 模板

你是代码审查工具（不是聊天助手）。

硬约束：
1) 若无明显问题，直接输出 PASS。
2) 若有问题，只能按固定结构输出；表格列名不得改动。
3) 禁止输出推理过程；改为输出“审查依据列表”（最多 6 条）。
4) 禁止寒暄语与解释性前言。

输出模板：

## 审查摘要
- 状态：PASS/WARN/FAIL

## 问题清单
| 位置 | 级别 | 问题描述 | 建议修复 |
| --- | --- | --- | --- |

## 审查依据列表
- <...>

输入：
<code_or_diff>

CLI（示例）

{ cat prompts/code-review.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/review.md

失败判定

• 输出既不是 PASS，也不符合固定结构
• 表格列名变化或夹带无关段落

回滚/降级

降级为“只输出问题清单表格”，跳过摘要与依据列表（用于紧急止损）。

---

配方 06：Bug Triage（假设并列，不要装懂）

用途

基于日志与上下文生成可执行的排障假设清单：每条假设必须给出验证动作与熔断条件。

输入契约

<error_log>：错误日志或堆栈
<context>：相关配置/代码片段（可选）

输出契约

只输出 Markdown，固定三段：症状摘要、假设清单（表格）、下一步验证动作（清单）。

Prompt 模板

你是故障排障助手。只基于输入材料提出可验证假设，禁止编造环境细节。

输出协议（顺序固定）：
## 症状摘要
- <一行概括>

## 假设清单
| hypothesis_id | 假设 | 依据（来自输入的线索） | 验证动作 | 若证伪的下一步 |
| ---: | --- | --- | --- | --- |

## 下一步验证动作
- <最多 5 条>

规则：
1) 信息不足时必须输出“材料未提及/无法确认”，并列出缺口字段。
2) 每条假设必须能被一个动作验证；不能验证的假设不允许输出。

日志：
<error_log>

上下文：
<context>

CLI（示例）

{ cat prompts/bug-triage.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/triage.md

失败判定

• 假设没有验证动作
• 明显引入输入中不存在的系统细节

回滚/降级

降级为“缺口字段清单 + 最小复现建议”，不输出任何假设。

---

配方 07：需求澄清（先把问题问对）

用途

把模糊需求拆成“必须澄清的问题 + 假设边界 + 验收标准”，避免你把不确定性交给模型自由发挥。

输入契约

<request>：原始需求（可以很乱）。

输出契约

只输出 Markdown，固定三段：澄清问题、默认假设、验收标准（Gherkin 风格）。

Prompt 模板

你是产品与工程联合评审员。

任务：把输入需求整理成可执行的澄清与验收。

输出协议（顺序固定）：
## 澄清问题（必须回答后才能进入实现）
- <最多 8 条，每条一行，必须可回答>

## 默认假设（若用户不回答则按此执行）
- <最多 6 条，每条一行>

## 验收标准（Gherkin 风格）
- Given <...> When <...> Then <...>

规则：
1) 禁止给实现方案；只做澄清与验收。
2) 禁止空话；每条必须能落到可测试条件。

输入需求：
<request>

CLI（示例）

{ cat prompts/clarify-requirement.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/clarify.md

失败判定

• 澄清问题不可回答或带主观形容词
• 验收标准无法测试（缺阈值/条件）

回滚/降级

降级为“只输出澄清问题”，停止输出假设与验收标准。

---

配方 08：评测 Rubric（把好坏写成可判定规则）

用途

为某类输出定义评分与门禁，避免评审停留在“我觉得还行”。

输入契约

<task_spec>：任务说明与输出协议（最好包含模板/Schema）。

输出契约

只输出 Markdown 表格，列名固定：维度/评分标准/失败门禁/备注。

Prompt 模板

你是评测设计师。

任务：为输入任务设计一个可执行的评测 Rubric。

输出协议：
1) 只输出 Markdown 表格。
2) 列名固定：维度/评分标准/失败门禁/备注。
3) 每个维度必须能用规则检查（如字段存在、长度阈值、禁用短语、证据绑定）。

任务说明：
<task_spec>

CLI（示例）

{ cat prompts/rubric.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/rubric.md

失败判定

• 评分标准仍是形容词（如“更专业”“更流畅”）
• 没有失败门禁或门禁不可检测

回滚/降级

降级为“维度清单 + 每维度一个最小门禁”，不输出完整评分规则。

---

配方 09：回归用例生成（把失败变资产）

用途

把一段失败输出变成“可复现用例”：最小输入、期望结构、门禁断言，便于接入回归流程。方法论详见 06-feedback.md。

输入契约

<failure_context>：触发失败的输入与失败现象描述（尽量最小化）。

输出契约

只输出 Markdown，固定四段：Case 说明、最小输入、期望门禁、回归执行建议。

Prompt 模板

你是回归用例作者。

任务：把失败现象固化为一个可复现的回归 case。

输出协议（顺序固定）：
## Case 说明
- 触发条件：<...>
- 失败现象：<...>
- 根因假设：<...>

## 最小输入
<放入 input.txt 的内容>

## 期望门禁（必须可检测）
- 格式门禁：<...>
- 纯净度门禁：<...>
- 事实门禁：<...>

## 回归执行建议
- 如何加入回归集：<...>

输入材料：
<failure_context>

CLI（示例）

{ cat prompts/make-regression-case.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/case.md

失败判定

• 最小输入仍然很长或包含与失败无关的大段背景
• 门禁无法被脚本检查

回滚/降级

只输出“最小输入 + 失败现象 + 缺口字段清单”，停止生成门禁建议。

---

配方 10：Prompt 生成器（把需求变成 Prompt 合同 + 正文）

用途

把你的自然语言需求转换成“合同 + 正文 + 门禁”，减少你从零写 Prompt 的重复劳动。

输入契约

<goal>：一句话目标
<consumer>：输出给谁（人类/解析器/下游系统）
<output_format>：Markdown/JSON/表格
<constraints>：必须/禁止项（可为空）

输出契约

只输出 Markdown，固定三段：Prompt 合同表、Prompt 正文、门禁清单。

Prompt 模板

你是提示词工程师。把输入需求转换成生产级 Prompt。

输出协议（顺序固定）：
## Prompt 合同
| 维度 | 定义/约束 |
| :--- | :--- |
| ID & Version | <...> |
| 级别 | Draft / Collaboration / Machine Execution |
| 任务 | <...> |
| 输入契约 | <...> |
| 输出契约 | <...> |
| 失败判定 | <...> |
| 回滚/降级 | <...> |

## Prompt 正文（可直接用于 CLI/API）
- Role: <...>
- Task: <...>
- Constraints: <...>
- Output Format: <...>

## 门禁清单（可脚本化）
- <...>

输入需求：
目标：<goal>
消费者：<consumer>
输出载体：<output_format>
约束：<constraints>

CLI（示例）

{ cat prompts/prompt-generator.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/generated-prompt.md

失败判定

• 合同字段缺失或门禁仍是形容词
• 正文无法直接复制运行（缺输入占位或输出协议不完整）

回滚/降级

降级为“只生成 Prompt 合同”，正文由人类补齐。

---

配方 11：拒答与缺口清单（事实类必备）

用途

强制模型在信息不足时停止输出结论，只输出缺口字段，避免幻觉补全。原则见 02-facts.md。

输入契约

<question>：问题
<material>：现有材料（可为空）

输出契约

只输出 Markdown，固定两段：结论（可能为空）、缺口字段清单。

Prompt 模板

你是审计员。只基于材料回答，材料不足必须拒答。

输出协议（顺序固定）：
## 结论
- 若材料足够：<一句话命题>（并在下一段给证据）
- 若材料不足：输出“材料未提及/无法确认”

## 缺口字段清单
- <缺什么就列什么；若为空输出“无”>

规则：
1) 禁止外部补全；禁止猜测。
2) 若输出结论，必须追加一行“证据定位：<来源标识>”。

问题：
<question>

材料：
<material>

CLI（示例）

{ cat prompts/refuse-with-gaps.txt; printf '\n\n'; cat input.txt; } | <LLM_CLI> > out/answer.md

失败判定

• 材料不足时仍输出具体结论
• “证据定位”无法落到来源标识

回滚/降级

材料不足时直接只输出缺口字段清单，不输出任何结论段。

---

配方 12：风格化重写（保持结构，删掉废话）

用途

把“流水账草稿”重写成可交付的技术文档：结构不变，内容更硬，约束更清楚。

输入契约

<draft_md>：Markdown 草稿（标题层级已存在）。

输出契约

只输出 Markdown；保留原有标题层级；新增的条目必须是可执行清单或表格，不允许散文段落扩写。

Prompt 模板

你是中文技术文档编辑，语气尖锐但专业。

任务：重写草稿，使其可交付、可验收。

硬约束：
1) 保持原有 Markdown 标题层级与顺序；不要新增顶层结构。
2) 删除：口号、形容词堆叠、无落点的建议。
3) 每个小节必须落到“清单/表格/协议/门禁”之一；不能落地就删掉该句。
4) 禁止外链；如需引用，仅允许相对链接并带 .md。

草稿：
<draft_md>

CLI（示例）

{ cat prompts/rewrite.md.txt; printf '\n\n'; cat input.md; } | <LLM_CLI> > out/rewrite.md

失败判定

• 结构被改写（标题层级漂移）
• 输出膨胀明显且缺少可执行门禁（说明加了废话）

回滚/降级

只做“删除废话”，不做“新增内容”，以保证结构稳定与可审查。

---

配方 13：结构化写作骨架生成

用途

在开始正式写作前，强制生成带有逻辑校验和验收标准的章节骨架。拒绝流意识的堆砌，确保文章结构符合 01-mindset.md 中的逻辑闭环要求。

输入契约

• 主题：核心论点或技术概念。
• 读者画像：目标受众的技术水平（如：资深架构师、入门开发者）。
• 约束：总字数或章节深度限制。

输出契约

• Markdown 格式的嵌套列表。
• 每个层级必须包含“逻辑目的”和“验收门禁”。
• 严禁包含具体的正文段落。

Prompt 模板

你是一个严苛的编辑。请为主题 <主题> 构建一个详细的写作骨架。
目标读者是 <读者画像>。

要求：
1. 结构必须包含：引言（背景与冲突）、核心论证（至少 3 个层层递进的子论点）、反面观点驳斥、结论与行动建议。
2. 每个章节标题下，必须注明两点：
   - 逻辑目的：该章节在整体论证中起什么作用？
   - 验收门禁：写完该章节后，必须回答哪三个具体问题才算合格？
3. 保持层级清晰，不要直接生成正文。

输入主题：<主题>

CLI（示例）

cat <<'EOF' | <LLM_CLI> > out/chapter-outline.md
你是一个严苛的编辑。请为主题 分布式一致性 构建一个详细的写作骨架。
目标读者是 资深后端工程师。

要求：
1. 结构必须包含：引言（背景与冲突）、核心论证（至少 3 个层层递进的子论点）、反面观点驳斥、结论与行动建议。
2. 每个章节标题下，必须注明两点：
   - 逻辑目的：该章节在整体论证中起什么作用？
   - 验收门禁：写完该章节后，必须回答哪三个具体问题才算合格？
3. 保持层级清晰，不要直接生成正文。
EOF

失败判定

• 验收门禁仍然是“是否清晰”“是否通顺”这种不可裁决废话。
• 结构不包含反面观点与驳斥，导致读者无法理解边界条件。

回滚/降级

降级为“只输出二级标题 + 每节一句话核心论点”，先把逻辑主干跑通再细化。

---

配方 14：RAG 引用对齐与拒答（圆括号来源标注）

用途

在 RAG 场景强制模型只基于上下文回答，并把每句话绑定到来源标识；上下文不足时拒答。方法论与拒答口径参见 02-facts.md。

输入契约

• 上下文片段：多条片段，每条包含来源 id 与文本。
• 用户问题：明确的问题。

输出契约

• 只输出答案正文（短句为主）。
• 每一句话句末必须追加来源标注，格式为 (source:<id>)。
• 若上下文不足，必须输出 INFO_MISSING 并给出缺口字段清单。

Prompt 模板

你是证据核对员。请只基于上下文回答。

上下文（每条含来源 id）：
<context>

问题：
<question>

规则：
1. 每一句话的句末必须追加来源标注，格式为 (source:<id>)。
2. 严禁引入外部知识补全。
3. 若上下文不足以回答，直接输出 INFO_MISSING，并列出缺口字段清单（最多 6 条）。
4. 禁止输出寒暄语与解释性前言。

CLI（示例）

cat <<'EOF' | <LLM_CLI> > out/rag-answer.md
你是证据核对员。请只基于上下文回答。

上下文（每条含来源 id）：
doc-a: 本系统的默认重试次数为 2 次。
doc-b: 当错误码为 RATE_LIMIT 时，必须退避重试并记录告警。

问题：
默认重试策略是什么？

规则：
1. 每一句话的句末必须追加来源标注，格式为 (source:<id>)。
2. 严禁引入外部知识补全。
3. 若上下文不足以回答，直接输出 INFO_MISSING，并列出缺口字段清单（最多 6 条）。
4. 禁止输出寒暄语与解释性前言。
EOF

失败判定

• 出现未标注来源的句子。
• 输出了上下文中不存在的参数或结论。

回滚/降级

降级为只输出“缺口字段清单”，停止输出任何答案句。

---

配方 15：会议纪要 → 行动项（Owner/DDL/阻塞项）

用途

把会议速记压成可执行行动项：谁做、何时交付、依赖谁、失败时怎么止损。你要的是执行表，不是散文纪要。

输入契约

• 会议速记：原始文本（可含口语与争论）。
• 当前日期：用于推断相对时间表达。

输出契约

• 只输出 JSON 字符串本体。
• 顶层字段固定：decisions（array）、action_items（array）、risks（array）。
• 每个行动项字段固定：title、owner、deadline、priority、blockers。

Prompt 模板

你是项目经理。把输入速记转成可执行行动项。

输入：
- today: <YYYY-MM-DD>
- transcript: <会议速记>

输出协议（硬约束）：
1. 只输出 JSON 字符串本体（禁止 Markdown 代码块）。
2. decisions/action_items/risks 三个字段必须存在。
3. owner 未明确时写 UNASSIGNED；deadline 未明确时写 TBD。
4. title 必须以动词开头，且可执行（禁止“跟进一下”）。

CLI（示例）

cat <<'EOF' | <LLM_CLI> > out/meeting-actions.json
你是项目经理。把输入速记转成可执行行动项。

输入：
- today: 2025-01-02
- transcript: 我们决定把登录重构拆成两步。第一步只做 UI 与 API 兼容，第二步再迁移存量用户。小王负责第一步，下周五给 demo。风控同学提醒需要增加限流告警。大家讨论了是否要做短信登录，暂不做。

输出协议（硬约束）：
1. 只输出 JSON 字符串本体（禁止 Markdown 代码块）。
2. decisions/action_items/risks 三个字段必须存在。
3. owner 未明确时写 UNASSIGNED；deadline 未明确时写 TBD。
4. title 必须以动词开头，且可执行。
EOF

失败判定

• 行动项缺少 owner 或 deadline 且未给 UNASSIGNED/TBD。
• title 仍是抽象句子，无法执行与验收。

回滚/降级

降级为只输出 action_items，不输出 decisions/risks，先把执行表跑通。

---

配方 16：发布说明 / 变更日志（含回滚说明）

用途

把 commit/变更摘要重写成可对外发布的 Release Notes，并强制给出回滚与降级说明。

输入契约

• 版本号：发布版本标识。
• 变更列表：条目化（每条一行）。
• 风险提示：可选（如数据库迁移、协议变更）。

输出契约

• 只输出 Markdown。
• 固定小节：新功能、修复、破坏性变更、回滚/降级方案。
• 每条变更必须一行，禁止长段散文。

Prompt 模板

你是发布经理。把变更列表改写为面向用户的 Release Notes。

输入：
- version: <...>
- changes: <...>
- risk_notes: <...>

硬约束：
1. 只输出 Markdown。
2. 小节顺序固定：## 新功能 / ## 修复 / ## 破坏性变更 / ## 回滚/降级方案。
3. 不要输出任何多余解释；每条变更一行短句。
4. 回滚/降级方案必须可执行：写清回滚粒度（配置/代码/数据）与注意事项。

CLI（示例）

cat <<'EOF' | <LLM_CLI> > out/release-notes.md
你是发布经理。把变更列表改写为面向用户的 Release Notes。

输入：
- version: v2025.01.02
- changes:
  - 新增：支持团队空间
  - 修复：某些情况下会重复扣费
  - 变更：默认模型从 A 切换到 B
- risk_notes:
  - 本次包含计费口径修复，需关注对账与回滚策略

硬约束：
1. 只输出 Markdown。
2. 小节顺序固定：## 新功能 / ## 修复 / ## 破坏性变更 / ## 回滚/降级方案。
3. 不要输出任何多余解释；每条变更一行短句。
4. 回滚/降级方案必须可执行：写清回滚粒度（配置/代码/数据）与注意事项。
EOF

失败判定

• 丢失回滚/降级方案小节。
• 把内部实现细节当成用户可见更新（对用户无意义）。

回滚/降级

降级为只输出分类与要点清单，不改写为用户语言（用于紧急发布）。

---

配方 17：测试用例生成（含失败判定）

用途

把逻辑描述转成可执行的测试矩阵：覆盖正常路径、边界条件、异常输入，并给出明确失败判定。

输入契约

• 逻辑描述：业务规则或函数描述。
• 输入结构：字段、类型、约束。

输出契约

• 只输出 Markdown 表格。
• 列名固定：Case ID/Scenario/Input/Expected/Failure Criteria。
• 必须包含至少 3 条边界与 3 条异常用例。

Prompt 模板

你是测试工程师。请为输入逻辑生成测试用例矩阵。

逻辑描述：
<logic>

输入结构：
<input_schema>

硬约束：
1. 只输出 Markdown 表格。
2. 列名固定：Case ID/Scenario/Input/Expected/Failure Criteria。
3. Failure Criteria 必须具体可检测（状态码/错误码/字段缺失/阈值）。
4. 必须覆盖：正常路径、边界条件、异常输入（各至少 3 条）。

CLI（示例）

cat <<'EOF' | <LLM_CLI> > out/test-matrix.md
你是测试工程师。请为输入逻辑生成测试用例矩阵。

逻辑描述：
一个折扣函数，输入为金额，满 100 减 10，满 200 减 30，不可叠加，负数输入报错。

输入结构：
amount: number

硬约束：
1. 只输出 Markdown 表格。
2. 列名固定：Case ID/Scenario/Input/Expected/Failure Criteria。
3. Failure Criteria 必须具体可检测。
4. 必须覆盖：正常路径、边界条件、异常输入。
EOF

失败判定

• 只写 happy path，没有边界与异常。
• Failure Criteria 仍是形容词或不可检测句子。

回滚/降级

降级为只输出“边界与异常用例清单”（不输出表格），先把覆盖补齐。

---

配方 18：需求拆分为任务树（含停止条件与风险门禁）

用途

把模糊需求拆成可交付任务树：每个叶子任务都能验收、能止损、能回滚，并且有明确停止条件与风险门禁。

输入契约

• 功能描述：一段需求文字。
• 技术约束：范围、依赖、禁止项。

输出契约

• 只输出 Markdown 清单。
• 每个任务必须包含：DoD（交付物）、Stop Condition（明确不做什么）、Risk Gate（风险门禁）。
• 叶子任务必须可在一个工作日内完成（否则继续拆分）。

Prompt 模板

你是技术负责人。把需求拆成工程任务树。

输入：
- feature: <功能描述>
- constraints: <技术约束>

硬约束：
1. 每个叶子任务必须可在一个工作日内完成；否则继续拆分。
2. 每个任务必须包含：
   - DoD: 具体交付物（代码/测试/文档）
   - Stop Condition: 明确不做什么（Scope Out）
   - Risk Gate: 依赖项或潜在风险，触发时必须暂停或升级评审
3. 只输出 Markdown 清单；禁止额外解释。

CLI（示例）

cat <<'EOF' | <LLM_CLI> > out/task-tree.md
你是技术负责人。把需求拆成工程任务树。

输入：
- feature: 为产品增加团队空间，支持邀请成员、角色权限、审计日志。
- constraints: 不改动现有登录方式；权限模型必须可回滚；审计日志必须可检索。

硬约束：
1. 每个叶子任务必须可在一个工作日内完成；否则继续拆分。
2. 每个任务必须包含 DoD / Stop Condition / Risk Gate。
3. 只输出 Markdown 清单；禁止额外解释。
EOF

失败判定

• 任务粒度过大无法验收，或没有 DoD/Stop Condition/Risk Gate。
• 没有拆出权限与审计的门禁动作。

回滚/降级

降级为只输出“关键路径任务 + 风险门禁清单”，先把高风险点固定下来。

---

配方 19：数据清洗与标注规范（裁决口径）

用途

为训练/评测数据建立可裁决口径：保留什么、丢弃什么、如何修正、如何标注。你要的是可复跑的规则，不是“凭感觉清洗”。

输入契约

• 数据用途：训练/评测/检索索引。
• 样本片段：少量原始样本（已脱敏）。

输出契约

• 只输出 Markdown 清单。
• 必须包含：保留/丢弃标准、清洗规则、标注规范、边缘案例裁决。

Prompt 模板

你是数据负责人。请为数据用途 <purpose> 生成清洗与标注规范。

原始数据样本：
<samples>

硬约束：
1. 只输出 Markdown 清单。
2. 必须包含：保留/丢弃标准、清洗规则、标注规范、边缘案例裁决。
3. 每条规则必须可裁决：给出触发条件与处理动作。

CLI（示例）

cat <<'EOF' | <LLM_CLI> > out/data-rules.md
你是数据负责人。请为数据用途 评测集 生成清洗与标注规范。

原始数据样本：
1) Price: 100 USD, Date: 2023/01/01
2) Price: 100, Date: Jan 1st 23
3) Price: N/A, Date: -

硬约束：
1. 只输出 Markdown 清单。
2. 必须包含：保留/丢弃标准、清洗规则、标注规范、边缘案例裁决。
3. 每条规则必须可裁决：给出触发条件与处理动作。
EOF

失败判定

• 规则仍是形容词，没有触发条件与动作。
• 边缘案例未给出明确裁决口径。

回滚/降级

降级为只输出“丢弃标准 + 必要的日期/单位统一规则”，先保证一致性。

---

配方 20：代码重构风险评估（魔鬼代言人 + 回滚预案）

用途

让模型站在反对方，列出重构风险、验证清单与回滚策略，避免“重构爽一时，上线火葬场”。

输入契约

• 当前代码/接口：关键片段或签名说明。
• 重构目标：你想改成什么。
• 约束：禁止改动范围、性能红线、兼容要求。

输出契约

• 只输出 Markdown。
• 固定结构：风险清单、验证清单、回滚策略。
• 每条风险必须给出触发场景与验证动作。

Prompt 模板

你是魔鬼代言人。不要说好话，只列风险与验证动作。

输入：
- code: <当前代码或接口>
- goal: <重构目标>
- constraints: <约束>

输出结构（顺序固定）：
## 风险清单
- <每条包含：风险/触发场景/影响/验证动作>

## 验证清单（上线前必须通过）
- <...>

## 回滚策略
- <回滚粒度与操作步骤>

CLI（示例）

cat <<'EOF' | <LLM_CLI> > out/refactor-risk.md
你是魔鬼代言人。不要说好话，只列风险与验证动作。

输入：
- code: 一个鉴权中间件，负责解析 token 并注入 user_id
- goal: 重构为可插拔策略，支持多种 token 解析
- constraints: 不允许改变外部行为；失败必须可回滚到旧策略

输出结构（顺序固定）：
## 风险清单
- <每条包含：风险/触发场景/影响/验证动作>

## 验证清单（上线前必须通过）
- <...>

## 回滚策略
- <回滚粒度与操作步骤>
EOF

失败判定

• 只给“注意事项”不给可验证动作。
• 回滚策略不可执行或缺少回滚触发条件。

回滚/降级

降级为只输出“验证清单 + 回滚策略”，先把止损路径固定下来。