09 - 进阶技巧食谱

元层级的 Prompt 技巧：链式编排、上下文管理、多模型协作、会话分治、元提示词、个人提示词库。

适用场景

场景	你的状态	目标
复杂任务需要多步骤	单个 Prompt 无法胜任	用 Prompt 链编排多步流程
上下文即将耗尽	会话质量下降，AI 开始遗忘	主动管理上下文窗口
不同任务需要不同能力	一个模型无法兼顾所有	按任务分配最合适的模型
大型功能开发	一个会话装不下	跨会话分治协作
反复写类似 Prompt	效率低，质量不稳定	用元提示词自动生成
好 Prompt 散落各处	经验无法积累复用	构建个人提示词库

食谱 1：Prompt 链（Prompt Chaining）

场景描述

单个 Prompt 难以处理的复杂任务，拆解为多个有序步骤，前一步的输出作为后一步的输入。每步都有确认点，避免 AI 一次性跑偏。

核心模板

text

# Step 1: 分析（只读，不做修改）
阅读 {{目标文件或模块}}，分析当前实现。输出：
1. 架构概览（50 字以内）  2. 核心数据流  3. 潜在问题清单
不要写代码，只输出分析结果。

# Step 2: 方案设计（基于 Step 1 的分析）
基于上一步的分析结果，设计 {{改动目标}} 的方案：
- 需要修改的文件清单
- 每个文件的改动点与风险评估
不要写代码，只列改动计划。

# Step 3: 实现（逐文件执行）
按确认的方案，先实现 {{第一个改动文件}}。
参考 {{锚定文件}} 的模式，保持风格一致。
完成后跑 {{测试命令}} 验证。

# Step 4: 验证与收尾
所有改动完成后：
1. 运行 {{全量验证命令}}
2. 用 git diff 展示所有改动
3. 总结本次改动的影响范围

变量说明

变量	说明	示例
`{{目标文件或模块}}`	要分析的代码范围	`src/auth/`
`{{改动目标}}`	本次任务的目标	`将 JWT 迁移到 Session`
`{{第一个改动文件}}`	方案中的首个文件	`src/auth/session.ts`
`{{锚定文件}}`	风格参考文件	`src/auth/jwt.ts`
`{{测试命令}}`	单步验证命令	`npm run test -- auth`
`{{全量验证命令}}`	全量验证	`npm run lint && npx tsc --noEmit && npm run test`

好坏对比

❌ "把 JWT 认证改成 Session 认证，要支持 Redis 存储，兼容现有 API。"
   → 一次性给太多要求，AI 大量改动不可控

✅ 按 Step 1→2→3→4 逐步执行，每步确认后再推进
   → 每个环节有检查点，偏差能及时纠正

实战案例

Step 1: "阅读 src/payment/，分析支付流程架构。只输出分析。"
  → AI 发现 3 个耦合点
Step 2: "设计将支付渠道抽象为策略模式的方案。列改动点。"
  → 确认方案后继续
Step 3: "实现 PaymentStrategy 接口。参考 src/payment/wechat.ts。"
  → 跑测试验证
Step 4: "重构 PaymentService 使用策略模式。跑全量测试。"

Claude 增强 💡

多轮对话：每个 Step 就是一轮交互，天然支持分步确认
/compact 跨步骤：链条过长时用 /compact 保留方案和已完成步骤 释放空间
子代理拆分：Step 1 的分析可委派 Explore Agent，不消耗主会话上下文

食谱 2：上下文管理（Context Management）

场景描述

上下文窗口是最稀缺的资源。主动管理——何时压缩、何时清空、何时设检查点——直接决定 AI 输出质量。

核心模板

text

# 检查点模式：大任务分里程碑管理上下文

## 里程碑 1：{{第一阶段目标}}
实现 {{具体任务}}。完成后 git commit。

## 检查点动作
/compact 保留：
1. 当前任务总目标：{{总目标}}
2. 已完成：里程碑 1 — {{完成内容摘要}}
3. 待完成：里程碑 2 — {{下阶段目标}}
4. 关键决策：{{本阶段做的架构决策}}
5. 测试命令：{{验证命令}}

## 里程碑 2：{{第二阶段目标}}
基于里程碑 1 的成果，继续实现 {{具体任务}}。

变量说明

变量	说明	示例
`{{总目标}}` / `{{阶段目标}}`	整体和各里程碑目标	`实现用户认证模块` / `完成 Service 层`
`{{完成内容摘要}}` / `{{下阶段目标}}`	已完成和待做	`AuthService 完毕` / `API 路由`
`{{关键决策}}` / `{{验证命令}}`	跨步骤记忆和验证	`用 bcrypt` / `npm test -- auth`

好坏对比

❌ 一个会话从头做到尾，不压缩不清空
   → 上下文填满后 AI 遗忘规则、重复犯错、产生幻觉

✅ 每个里程碑后 git commit + /compact（或 /clear 新会话）
   → 每个阶段上下文干净，AI 输出质量稳定

实战案例

里程碑 1："实现 Post 模型和 Prisma migration。"
  → git commit → /compact 保留模型设计和待做步骤
里程碑 2："实现 PostService CRUD。参考 UserService。"
  → git commit → /compact 保留接口签名
里程碑 3："实现 /api/posts 路由。跑全量测试。"
  → git commit

Claude 增强 💡

/compact [指令]：带保留指令的压缩，精确控制保留内容
/clear + --continue/--resume：里程碑间清空或恢复历史会话
主动 > 被动：> 50% 考虑 /compact，> 70% 立即处理，不依赖自动压缩

食谱 3：多模型协作（Multi-Model Collaboration）

场景描述

Opus 擅长复杂推理，Sonnet 编码性价比高，Haiku 快速便宜。按任务特性分配模型，兼顾质量与成本。

核心模板

text

# 多模型分工方案

## 主会话（Opus）— 高价值决策
{{复杂推理任务}}：架构设计、方案权衡、安全审计

## 子代理（Sonnet）— 日常编码
委派 Sonnet 子代理执行：
- 任务：{{编码任务描述}}
- 参考：{{锚定文件}}
- 约束：{{技术约束}}
- 验证：完成后运行 {{测试命令}}

## 后台代理（Haiku）— 研究与分类
后台用 Haiku 代理完成：
- 任务：{{研究或搜索任务}}
- 输出格式：{{期望的输出结构}}

变量说明

变量	说明	示例
`{{复杂推理任务}}` / `{{编码任务描述}}`	按模型分配的任务	`设计微服务拆分` / `实现 CRUD`
`{{锚定文件}}` / `{{技术约束}}`	参考和限制	`auth.service.ts` / `用 Prisma`
`{{研究或搜索任务}}`	后台轻量任务	`搜索所有 TODO 并分类`

好坏对比

❌ 所有任务都用 Opus 主会话直接执行
   → 简单搜索也消耗昂贵的 Opus 上下文，成本高效率低

✅ Opus 做决策，Sonnet 做编码，Haiku 做搜索
   → 整体成本降低 50-70%，质量不降反升

实战案例

Opus："设计通知架构，对比推送/WebSocket/SSE" → 选定 SSE
Sonnet 子代理："实现 NotificationService，参考 email.service.ts"
Haiku 后台："搜索所有需要发通知的场景，按模块分类" → 不阻塞主线程

Claude 增强 💡

model 字段：.claude/agents/ 中为不同代理指定模型；context: fork 隔离执行
成本参考：Opus $5/$25、Sonnet $3/$15、Haiku $1/$5（每百万 token）
决策原则：Sonnet 编码接近 Opus（SWE-bench 79.6% vs 80.8%），日常编码优先 Sonnet
异构审查：高风险变更可引入 Codex MCP 做跨模型族反证审查

食谱 4：会话分治（Session Divide and Conquer）

场景描述

大型功能无法在单个会话中完成。拆分到多个专注会话，每个会话单一目标，通过 git commit 传递状态。

核心模板

text

# 会话分治计划

## 总目标：{{项目总目标}}

## 会话 1：探索与设计（只读）
- 阅读 {{相关代码目录}}，分析架构
- 产出：设计方案 → git commit + /clear

## 会话 2：核心实现
- 恢复："上个会话完成了 {{功能}} 的设计，方案详见 {{方案位置}}。"
- 实现 {{核心模块}}，参考 {{锚定文件}}
- 结束：git commit + /clear

## 会话 3：集成与测试
- 恢复："{{核心模块}} 已实现（见最近 commit）。"
- 编写集成测试，处理边界情况
- 运行 {{全量验证命令}} → git commit

## 会话 4：审查（独立视角）
- "审查 git diff main..{{分支名}} 的所有改动，
  重点关注安全边界、错误处理、性能。"

变量说明

变量	说明	示例
`{{项目总目标}}` / `{{核心模块}}`	总目标和实现对象	`OAuth2.0 登录` / `OAuthService`
`{{相关代码目录}}` / `{{分支名}}`	探索范围和分支	`src/auth/` / `feature/oauth`
`{{方案位置}}` / `{{全量验证命令}}`	方案和验证	`commit message` / `npm test`

好坏对比

❌ 一个会话干到底：探索 → 设计 → 实现 → 测试 → 审查
   → 上下文耗尽，后期 AI 质量严重退化

✅ 四个会话各司其职，git commit 传递状态
   → 每个会话上下文干净，AI 始终高质量输出

实战案例

会话 1："阅读 src/storage/，分析架构" → git commit
会话 2："实现 StorageService（S3+本地），参考 media.service.ts" → git commit
会话 3："实现上传路由 + 集成测试" → git commit
会话 4："审查 git diff main..feature/file-upload" → 修复 → git commit

Claude 增强 💡

--continue/--resume//rename：恢复或定位历史会话
git 传递状态：git log 和 git diff 让新会话快速恢复上下文
隔离审查：审查者没有实现者的认知偏差，能发现更多问题

食谱 5：元提示词（Meta-Prompts）

场景描述

用 Prompt 生成 Prompt。当你反复为类似场景写提示词时，创建元提示词模板，让 AI 根据参数自动生成高质量任务提示词。

核心模板

text

# 元提示词：生成任务提示词

你是 Prompt 工程师。根据以下参数生成一个高质量任务提示词。

## 输入参数
- 任务类型：{{任务类型}}
- 技术栈：{{技术栈}}
- 目标文件：{{目标文件}}
- 锚定文件：{{锚定文件}}
- 特殊约束：{{特殊约束}}

## 生成规则
1. 必须包含技术栈约束（用什么/不用什么）
2. 必须包含范围约束（改哪里/不改哪里）
3. 必须包含行为约束（先做什么/后做什么）
4. 必须引用锚定文件作为风格参考
5. 必须指定验证方式

## 输出格式
输出一个可直接复制使用的 Prompt，不加额外解释。

变量说明

变量	说明	示例
`{{任务类型}}`	任务分类	`新增 API` / `重构模块` / `修复 Bug`
`{{技术栈}}`	项目技术栈	`Next.js + Prisma + PostgreSQL`
`{{目标文件}}`	要改的文件	`src/api/orders/route.ts`
`{{锚定文件}}`	参考现有代码	`src/api/users/route.ts`
`{{特殊约束}}`	额外限制	`不要修改数据库 schema`

好坏对比

❌ 每次手写 Prompt，质量参差不齐
   "帮我加个订单 API" → 缺约束、参考、验证

✅ 用元提示词生成标准化 Prompt
   → 自动包含四要素（技术栈、范围、参考、行动指令）

实战案例

输入：任务=新增API, 技术栈=Next.js+Prisma+Zod, 锚定=users/route.ts
AI 生成："实现订单创建 API。参考 @users/route.ts 模式（Zod 校验 +
  AppError + { data, error }）。额外：创建前校验库存。只改 route.ts。"

Claude 增强 💡

Skill = 固化的元提示词：常用模板写成 .claude/skills/，通过 $ARGUMENTS 接收参数
CLAUDE.md 注入：元提示词自动读取 CLAUDE.md 中的技术栈和规范
/retro 提炼：回顾时将有效 Prompt 提炼为模板并沉淀

食谱 6：个人提示词库构建（Personal Prompt Library）

场景描述

将验证有效的 Prompt 系统化整理，形成可复用的个人知识库。好的提示词不是用完就丢，而是不断积累迭代。

核心模板

text

# 个人提示词库管理流程

## 1. 收集：每次会话后回顾
/retro 执行回顾，关注：
- 哪个 Prompt 效果特别好？为什么？
- 哪个 Prompt 失败了？怎么修正的？

## 2. 提炼：从具体到通用
- 原始 Prompt：{{实际使用的具体 Prompt}}
- 通用模板：将项目特定内容替换为 {{变量}}
- 适用条件：{{什么场景下使用}}
- 注意事项：{{已知的局限或陷阱}}

## 3. 分类存储
- 高频通用 → CLAUDE.md 常用 Prompt 章节
- 场景专用 → .claude/skills/ 固化为 Skill
- 实验性的 → 个人笔记（待验证）

## 4. 迭代优化（每周/每月）
- 删除过时模板，合并相似模板，升级更好的变体

变量说明

变量	说明	示例
`{{实际使用的具体 Prompt}}`	效果好的原始 Prompt	`参考 @users/route.ts 实现 orders API`
`{{变量}}`	通用化后的占位符	`{{锚定文件}}`、`{{新API名}}`
`{{什么场景下使用}}`	适用边界	`新增 REST API 时`
`{{已知的局限或陷阱}}`	注意事项	`GraphQL API 不适用`

好坏对比

❌ 好 Prompt 用完就忘，下次从头想
   → 每次重新发明轮子，效率无法提升

✅ 系统化收集 → 提炼 → 分类 → 迭代
   → 提示词质量螺旋上升，常用场景一键复用

实战案例

原始："API 返回 500。先不修复。1.读路由 2.搜异常 3.检查捕获 4.写复现测试 5.修复"
提炼：将具体路径替换为 {{API路径}}、{{Service名}} 等变量
存储：.claude/skills/debug-api/ | 验证：3 个项目有效

Claude 增强 💡

Skills 结构化存储：.claude/skills/<场景>/ 每个场景一个 Skill，$ARGUMENTS 参数化
/retro 提炼：会话回顾时自动触发 Prompt 提炼流程
分层存储：高频通用 → CLAUDE.md（自动加载）；场景专用 → Skills；全局 → ~/.claude/CLAUDE.md

食谱 7：多代理协作（Multi-Agent Collaboration）

场景描述

多个子代理并行处理不同模块后，需要确保各自产出兼容、接口对齐。核心痛点：子代理间无法直接通信，各自基于接口契约独立工作，提交时可能出现契约漂移。

核心模板

模板 A：子代理检查点自查（每个子代理提交前执行）

text

请对比最初的接口契约，确认你的改动是否 100% 兼容。列出：
1. 新增了哪些接口（函数签名 / 类型定义 / API 端点）
2. 是否修改了已有接口的签名、参数或返回值
3. 是否存在契约外的副作用（新依赖、全局状态变更、环境变量）

如果第 2 或第 3 项非空，停止提交，报告偏差。

模板 B：合并验证（所有子代理完成后，由 Lead 或 Judge 执行）

text

以下是各模块的修改结果：{{各模块 git diff 或变更摘要}}

请检查：
1. 接口对齐：各模块间的函数签名、类型定义、API 契约是否一致
2. 合并冲突：是否有多个模块修改了同一文件或同一类型定义
3. 集成测试：现有集成测试是否需要更新，是否需要新增跨模块测试
4. 副作用：各模块是否引入了预期外的共享状态或环境依赖

输出：兼容 / 不兼容（列出冲突点和修复建议）

好坏对比

❌ 子代理各自完成后直接 merge，发现接口不对齐再返工
   → 排查成本高，可能需要重做整个模块

✅ 每个子代理提交前自查契约兼容性 → 汇总后统一合并验证
   → 在合并前发现问题，修复成本最低

实战案例

1. Lead 锁定接口契约："UserService.getById(): Promise<User>"
2. Worker A（API）自查："新增 getByEmail()，未修改已有接口 ✅"
3. Worker B（UI）自查："依赖 getById() 签名未变 ✅"
4. Lead 合并验证："接口对齐 ✅，无文件冲突 ✅，需新增集成测试"

Claude 增强 💡

Worktree 隔离：每个 Worker 用 isolation: worktree，物理隔离文件冲突
Agent Teams：Lead 通过 TaskCreate 分发，Worker 完成后先自查再标记 completed
Judge 角色：大型任务用专门 Judge Agent 执行合并验证，避免 Lead 自验偏差
doc-03 §8：Agent Teams 完整架构详见 doc-03 子代理体系

组合技巧

组合	食谱	要点
链式分治	1 + 4	会话 1 规划（Step 1-2）→ git commit → 会话 2-N 各执行一个模块
多模型链	1 + 3	Opus 分析 → Sonnet 编码 → Haiku 搜索 → Opus 审查
元提示词 + 个人库	5 + 6	元提示词生成模板 → 项目验证 → 有效存入 skills / 无效调整规则
上下文 + 分治	2 + 4	会话内部按里程碑 /compact，会话间 git commit 传递
多模型 + 多代理	3 + 7	Opus Lead 锁契约 → Sonnet Worker 编码+自查 → Opus Judge 合并验证

09 - 进阶技巧食谱 ​

适用场景 ​

食谱 1：Prompt 链（Prompt Chaining） ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 2：上下文管理（Context Management） ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 3：多模型协作（Multi-Model Collaboration） ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 4：会话分治（Session Divide and Conquer） ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 5：元提示词（Meta-Prompts） ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 6：个人提示词库构建（Personal Prompt Library） ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 7：多代理协作（Multi-Agent Collaboration） ​

场景描述 ​

核心模板 ​

模板 A：子代理检查点自查（每个子代理提交前执行） ​

模板 B：合并验证（所有子代理完成后，由 Lead 或 Judge 执行） ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

组合技巧 ​

相关资源 ​

09 - 进阶技巧食谱

适用场景

食谱 1：Prompt 链（Prompt Chaining）

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 2：上下文管理（Context Management）

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 3：多模型协作（Multi-Model Collaboration）

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 4：会话分治（Session Divide and Conquer）

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 5：元提示词（Meta-Prompts）

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 6：个人提示词库构建（Personal Prompt Library）

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 7：多代理协作（Multi-Agent Collaboration）

场景描述

核心模板

模板 A：子代理检查点自查（每个子代理提交前执行）

模板 B：合并验证（所有子代理完成后，由 Lead 或 Judge 执行）

好坏对比

实战案例

Claude 增强 💡

组合技巧

相关资源