02.6 提示词链与工作流编排

一个提示词干不完的活，用多个提示词接力。

读完你能做什么：判断什么任务该拆、怎么拆、以及如何在 Claude Code 里把链条自动化。

---

一、什么时候必须拆

单个提示词的失败模式有一个共同特征：任务的不同阶段对模型有相互冲突的要求。

症状	冲突所在	解法
让它"分析并重构"，结果分析很浅就开始改代码	分析要发散，重构要收敛	拆成两轮
让它"写代码并写测试"，测试总是刚好通过它写的实现	实现和验证需要独立视角	拆成两轮，且第二轮不看实现细节
让它"总结 10 份文档"，后面几份明显敷衍	上下文压力导致后期质量下降	每份单独处理
让它"设计方案"，给出的方案总是第一个想到的	缺少"生成多个候选再择优"的结构	拆成生成阶段 + 评估阶段

---

二、四种基础链式模式

2.1 顺序精炼链（Refinement Chain）

第 1 轮：生成原始产出
第 2 轮：以批判者视角审查第 1 轮
第 3 轮：根据审查意见修订

实例 —— 写技术方案：

# 轮 1
<task>
针对「对账模块耦合严重」的问题，给出一个重构方案。
只写方案，不要自我评价。
</task>

# 轮 2（关键：切换视角）
<role>
你现在是一名怀疑论者，你的任务是找出上面这个方案的致命缺陷。
你的绩效取决于找到多少个真正的问题，而不是让方案通过。
</role>

<task>
逐条列出这个方案的风险与漏洞。特别关注：
- 迁移期间新旧逻辑并行会不会导致数据不一致
- 有没有哪个步骤一旦失败就无法回滚
- 团队规模是否真的支撑得起这个改动量
</task>

# 轮 3
<task>
基于上述批评，修订方案。对于你不认同的批评，说明理由而不是盲从。
</task>

为什么有效：单轮里让模型"设计并自我批评"，两个任务在同一个生成过程中相互干扰 —— 它倾向于给出一个自己能自圆其说的方案。分轮之后，第 2 轮的模型面对的是一份"别人写的"方案，批判性显著更强。

2.2 分而治之链（Map-Reduce）

适合处理大量同质材料。

Map 阶段：对每份材料独立处理，输出结构化中间结果
Reduce 阶段：只把中间结果喂给模型，做汇总

# Claude Code 中的实现
for f in reports/*.md; do
  claude -p --model haiku "$(cat <<EOF
<document>
$(cat "$f")
</document>

<task>
抽取以下字段，输出 JSON：
{"file": "$f", "topic": "", "key_findings": [], "risks": [], "date": ""}
只输出 JSON，不要任何其他内容。
EOF
)" >> summaries.jsonl
done

# Reduce 阶段
claude -p --model opus "$(cat <<'EOF'
<data>
$(cat summaries.jsonl)
</data>

<task>
基于上述所有报告的结构化摘要，输出一份综合分析：
1. 跨报告的共性问题（出现在 3 份以上）
2. 相互矛盾的结论（明确指出是哪几份文件矛盾）
3. 优先级建议
</task>
EOF
)"

关键设计：Map 阶段用 Haiku（便宜快速，任务简单），Reduce 阶段用 Opus（需要综合推理）。

2.3 分支择优链（Generate-Then-Select）

第 1 轮：生成 N 个差异化的候选方案（要求它们必须在某个维度上明确不同）
第 2 轮：用明确的评估标准打分
第 3 轮：实施得分最高的

# 轮 1
<task>
给出 3 个解决方案。它们必须在「实现成本」这个维度上明确拉开差距：
- 方案 A：1 天能做完的临时方案
- 方案 B：1 周的中等改造
- 方案 C：1 个月的彻底重构

每个方案只写要点，不超过 5 行。
</task>

# 轮 2
<criteria>
按以下维度给三个方案打分（1-5），并给出总分：
- 解决问题的彻底程度（权重 3）
- 引入新风险的可能性（权重 3，越低分越高）
- 团队当前能力可承接程度（权重 2）
- 未来 6 个月的可维护性（权重 2）
</criteria>

<task>
打分并推荐一个。如果三个都不理想，说明还缺什么方案。
</task>

为什么有效：模型的第一个想法往往是训练分布中最典型的那个，未必是最适合你情境的。强制生成差异化候选，等于强制它探索分布的其他区域。

2.4 验证链（Verification Chain）

第 1 轮：产出结果
第 2 轮：在不看第 1 轮推理过程的情况下，独立验证结论

在 Claude Code 中用子代理实现最干净：

---
name: verifier
description: 独立验证一个技术结论是否正确。在主会话得出重要结论后，用它做交叉检查。
model: opus
tools: Read, Grep, Glob, Bash
---

你是独立验证者。你只会收到一个「待验证的断言」，不会收到得出该断言的推理过程。

你的任务：
1. 用工具独立查证这个断言
2. 输出：`确认` / `否定` / `无法验证`，并给出你查到的证据（含文件路径与行号）
3. 不要试图猜测原始推理，只看证据

上下文隔离是关键 —— 如果验证者能看到原始推理，它会被那条推理链锚定，验证就退化成了确认偏误。

---

三、在 Claude Code 里固化链条

上面的链条如果每次手动敲，成本太高。把它们变成 Skill：

---
name: design-review
description: 对一份技术方案执行「设计 → 批判 → 修订」三轮精炼。当用户提出一个架构方案并希望经过严格评审时使用。
disable-model-invocation: true
---

# 三轮方案精炼

对用户提供的方案（或你刚生成的方案）执行：

## 第 1 轮 · 补全
如果用户只给了粗略想法，先补全成完整方案，包含：改动范围、实施步骤、验证方式、回滚方案。

## 第 2 轮 · 批判
切换视角。你现在是这个方案的反对者，任务是找出致命缺陷。至少检查：
- 有没有步骤一旦失败无法回滚
- 迁移期的数据一致性如何保证
- 是否假设了团队具备实际不具备的能力
- 有没有隐含的、未被声明的依赖

在 `<critique>` 标签内输出，每条批评标注严重度。

## 第 3 轮 · 修订
基于批评修订方案。对于你不认同的批评，明确说明理由，不要盲目采纳。

在 `<final>` 标签内输出最终方案，并附一节「已知残余风险」。

保存为 .claude/skills/design-review/SKILL.md，之后：

> /design-review 我想把对账逻辑抽成独立服务

Skill 的完整写法见 08.2 SKILL.md 规范全解。

---

四、链条设计的四条原则

原则 1：每一环的输出必须是结构化的

链条中间的产物如果是自由文本，下一环需要重新解析它，误差会累积。用 JSON 或明确的标签：

本轮输出必须是合法 JSON，schema 如下：
{
  "candidates": [{"id": 1, "summary": "", "cost_days": 0, "risk": "low|medium|high"}],
  "unknowns": []
}
不要输出 JSON 以外的任何内容。

在 Claude Code 中可以用 --json-schema 强制校验：

claude -p --json-schema '{
  "type": "object",
  "properties": {
    "candidates": {"type": "array"},
    "unknowns": {"type": "array"}
  },
  "required": ["candidates", "unknowns"]
}' "生成三个候选方案"

原则 2：视角切换必须是显式的

不要指望"接下来请客观评价"就能真的切换视角。要显式重设角色：

<role>
忘掉你刚才作为方案设计者的立场。你现在是一名从未参与设计的评审专家，
你的职责是保护生产系统不被有缺陷的方案破坏。
</role>

原则 3：链条不要超过 5 环

每一环都有误差。5 环之后，误差累积会超过链式带来的收益。如果一个任务需要 10 步，考虑：

• 中间加一个"人工检查点"
• 或者拆成两个独立的链条

原则 4：给链条设计失败退出

如果第 2 轮的批评中出现「致命」级别的问题超过 2 条，
不要进入第 3 轮修订，直接停下来告诉我：这个方案方向可能是错的。

没有失败退出的链条会一路修补一个根本不该继续的方案。

---

五、什么时候不该用链

场景	用链的代价	更好的选择
探索性讨论	链条太僵硬，扼杀发散	自然对话
一次性简单任务	设计链条的时间超过任务本身	单个提示词
需要看到中间过程的任务	链条会隐藏中间态	单轮 + Extended Thinking
大量并行的独立任务	链是串行的	子代理并行

---

延伸阅读

• 02.7 反模式清单
• 06.4 Subagents 子代理编排 —— 链条的并行化实现
• 08.6 Skill 实战示例集
• 11.2 从零构建全栈功能 —— 一条完整的实战链条