阻抗匹配 · Impedance Matching · Claude Code 工程师手册

阻抗匹配 · Impedance Matching

电子工程 · 用于 Prompt 与模型思维方式的对齐

物理

核心概念

阻抗匹配原理（电子工程）：当信号源阻抗 = 负载阻抗时，功率传输效率最高。不匹配 → 信号反射，能量损耗，传输质量下降。 LLM 的类比：信号源 = 你的意图（Prompt）负载 = 模型的"接收方式" 阻抗匹配 = Prompt 的结构契合模型的处理方式匹配良好 → 模型准确执行意图，最小幻觉匹配不良 → 模型误解，过度脑补，反复错方向

关键直觉：模型的"阻抗"是固定的——它有偏好的信息格式和结构。问题不是模型不够聪明，而是你的 Prompt 和它的接收方式不匹配。

常见阻抗不匹配模式

不匹配类型	症状	匹配方案
意图太模糊	模型过度脑补，答案方向偏	写明"你不需要做什么"
约束没有层次	模型平等对待所有要求，优先级混乱	用 1/2/3 明确优先级顺序
输出格式未指定	模型猜测格式，每次不同	给出示例格式（few-shot）
一次请求太多	模型完成了大部分，遗漏了少数	拆分为顺序的子任务
专业术语不统一	模型用的词和你的系统不一致	在 CLAUDE.md 定义项目术语表

阻抗匹配的实际改造

prompt-before-after.md 阻抗匹配前 vs 后

// 低阻抗匹配（常见写法）
"帮我优化这段代码"

// 问题：意图模糊，"优化"可以是性能/可读性/安全性/…
// 模型会根据自己的判断选一个方向，可能不是你想要的

// ─────────────────────────────────────────────

// 高阻抗匹配（对齐模型接收方式）
`
目标：优化这段代码的执行性能（不是可读性）

当前问题：每次调用都重新查询数据库，高并发时有瓶颈
约束：不能改变函数签名，不能引入新依赖

输出格式：
1. 问题诊断（1-2句）
2. 修改方案（列出具体改动）
3. 改动后的代码

不需要：解释语言基础，不需要写测试
`

// 现在模型知道：做什么、不做什么、输出什么格式
// 阻抗匹配 → 功率（信息）传输效率最高

✓ 阻抗匹配三要素

明确意图边界：说清楚做什么，更重要的是说清楚不做什么
给出输出示例：一个好的 few-shot 示例比 100 字约束更有效
拆分而不是堆叠：一次对话解决一个问题，顺序比并行更可靠

⚠ 常见误区 认为"Prompt 越长越好"。实际上，超过一定长度后，每增加一条规则都可能降低效果——因为模型要在众多约束之间权衡，阻抗反而增大。真正的匹配是精简的 Prompt + 明确的优先级。

拿走就能用 — 粘贴进你的 CLAUDE.md

CLAUDE.md Prompt 阻抗匹配规则

## Prompt 设计规则（阻抗匹配原则）

### 必须包含的元素
- 任务目标：一句话说清楚要做什么
- 排除项：明确说"不需要做什么"（减少过度脑补）
- 输出格式：提供一个示例（哪怕是简单的）

### 禁止的模式
- 不用"帮我优化/改进/完善"这类模糊动词，改用具体的"减少函数调用次数/减少代码行数"
- 不在单次请求中混合多个不同类型的任务（分开说）
- 不用"尽量/最好/如果可以"，这类措辞会让模型降低执行优先级

### 术语表
[在这里定义项目特有的术语，避免模型使用不同词汇]
- user = 终端用户，不是我们的工程师
- service = 微服务，不是 Go service struct
- pipeline = 内容生成流水线

12阻抗匹配 · Impedance Matching

阻抗匹配 · Impedance Matching