它怎么变强

约束与出口

按本讲的讲授顺序排。第一行是地基，先讲；后面几行都架在它上面

先回答三个问题

先记下你自己的答案，本讲结束时回来对一遍

1. 它「打开了你的文件」，那个文件到底去哪了？是整份传到了对方服务器，还是别的什么情况？先凭直觉写一个答案，别翻后面。
2. 你愿意让它直接改你负责的程序吗？不愿意的话，是哪一步让你不放心：怕它看错了、改错了，还是怕没人知道它改过？
3. 你手上有没有一套每次都得照着做一遍的步骤？随便写三条下来。板块 5 结束时，这三条要变成一个你当天就能用的 Skill。

它是个什么东西

不是网页，不是聊天窗口，是一个和 SAS 一样要装在本机的程序

先把两个概念分清楚，后面所有内容都建立在这个区分上。

• 模型（model）：跑在服务商机房里的那个神经网络。它的输入是文本，输出也是文本，没有别的能力。第一讲讲的全是它。
• 客户端（业内叫 harness，或者代理外壳）：装在你这台电脑上的一个常驻程序。它负责三件事——把材料拼成请求发给模型、解析模型返回的内容、在本机执行由此产生的动作。Claude Code 就是一个 harness。

网页上那种 AI 对话框只有模型，没有 harness，所以代码要你复制进去、答案要你复制回来。装了 Claude Code 之后多出来的正是 harness 这一层：你在项目目录里敲一下 claude，它常驻在那儿，一边连着远处的模型，一边握着你这台机器的文件、终端和 git。你说「adae.sas 里 AESEV 有些是空的，查一下」，找文件、打开、修改、跑核查，都是 harness 在做。

说话的是模型，动手的是 harness。下一节把这两者之间传的每一条报文拆开给你看。

装上、登录、跑通

三条命令的事，和装任何一个命令行工具没有区别

装法有好几种，挑一种就行，下面是官方给的（2026 年 9 月）。第一讲板块 0 说过命令行最大的好处是「字可以照抄」，下面每一行都可以直接复制粘贴。

# macOS / Linux / WSL：官方安装脚本
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

# 也可以用包管理器（装完不会自动更新，要手动升）
brew install --cask claude-code          # macOS
winget install Anthropic.ClaudeCode      # Windows
npm install -g @anthropic-ai/claude-code # 需要 Node.js 22+

装完之后用三条命令验一遍：

claude --version   # 打印版本号，例如 2.1.211 (Claude Code)
claude doctor      # 自检：安装、配置、更新通道有没有问题
claude             # 启动。第一次会让你在浏览器里登录

第一次会话长什么样

你说人话，去读哪个文件是它自己的事

打开之后就是一个输入框，光标在那儿闪。你不用告诉它去读哪个文件、跑哪条命令，那是它的活。你要说清楚的是三件事：动哪儿、什么情况、什么算做对了。

一次任务的标准形状

探索 → 计划 → 实施 → 验证 → 留痕。官方推荐的走法，也是出事最少的走法

1. 探索。按 Shift+Tab 切到计划模式（状态栏会显示 ⏸ plan mode on），让它先把相关的代码、数据结构、现在的做法看一遍，讲给你听。这一步它改不了任何东西。
2. 计划。让它写出要改哪些文件、按什么顺序、怎么验证。读一份计划两分钟，读它改完的代码二十分钟。计划不对就在这儿拦下来，几乎不花钱。
3. 实施。你批了它才动手。这时候可以走开，但别走太远。
4. 验证。让它自己跑测试、跑核查脚本、比对输出。它说「做完了」不算完，核查脚本返回 0 才算。
5. 留痕。让它写一条说得清楚的提交信息，或者一份变更说明。在我们这行，没留痕等于没做。

它动手之前会不会问你

这个设置叫权限模式，按 Shift+Tab 循环切换

整个工具的设置项里，这一个最该搞懂。它管的事情只有一句话：一个动作发生之前，是先弹窗问你，还是直接执行。

把「我们这儿的规矩」写下来一次

项目根目录下那个叫 CLAUDE.md 的文件，每次开会话它都会先读

CLAUDE.md 是放在项目根目录的一份 Markdown 文件，每次新会话启动时全文加载进上下文，作用等同于对这个项目永久生效的系统级指令。在项目里敲 /init，它会先替你起个草稿。

该往里写什么？写你带新人第一天必须交代的那几句：跑测试用哪条命令、raw 目录不许动、提交信息按什么格式。注意它是全文加载，所以长度本身就是成本，下面两栏是取舍标准。

# 例：一个 SDTM 编程项目的 CLAUDE.md（这是给它看的，不是给人看的）

## 环境
- SAS 在 /opt/sas/bin/sas，跑单个程序：sas -sysin prog.sas -log logs/
- Python 环境用 conda activate clin，不要用系统 python

## 规矩
- raw/ 目录只读，任何情况下不要改写里面的文件
- 改完 SDTM 程序必须跑 scripts/check_sdtm.py，通过了才算完
- 变量标签统一写英文，长度不超过 40 字符

## 提交
- 分支名 feature/<研究编号>-<简述>
- 提交信息第一行不超过 50 字符，正文写「为什么」不写「改了什么」

同一个东西的四个门

长相差很多，里面那套循环一模一样

模型只能说，不能做

第一讲的那个结论，在这里要再用一次

第一讲说过，模型干的事只有一件：看着已经有的文字，猜下一个字。装了 Claude Code 也没改变这一条。模型进程跑在服务商的机房里，没有文件系统、没有终端、没有网络出口，它唯一的输出通道就是那串文本。

那它怎么把你的文件改了？靠的是一个有正式名字的机制：工具调用（英文 tool use，也叫 function calling）。定义是这样的——

完整的一圈，五步

按「转一圈」开始。

点「下一步」开始。

「工具清单」长什么样

第 ① 站里最关键的一段。板块 4 要讲的 MCP，从头到尾就只在干这一件事

每次请求都会带上一份工具清单。清单里每个工具就是一小段说明：叫什么名字、干什么用、要填哪几个参数。模型就是读这段说明来决定用哪个、怎么填。

// 请求里带的工具清单（简化）
{
  "name": "Read",
  "description": "读取本地文件的内容。需要看某个文件时用它。",
  "input_schema": {
    "file_path": "要读的文件的绝对路径",
    "offset":    "从第几行开始读（可选）"
  }
}

内置工具有哪些

五条推论

那张图想清楚了，这五条是自己掉出来的

1. 「本地执行」的「本地」，说的是动作，不是决策。动手确实在你的机器上，可做决定要看的材料必须先发出去。所以合规问题从来不是「文件有没有上传」，而是「我让它看了什么」。它看过的每一段，都在第 ① 站被发走了。
2. 弹出权限提示的不是模型，是本机程序在拦。模型那边甚至不知道你拒绝了什么，它只收到一条「这个调用被拒绝了」的回执，然后换个办法。被拒一次不是它出了问题，是这道闸在正常工作。
3. 它每动一步，上下文就涨一块。第 ⑤ 站的结果是要占窗口的。你让它 cat 一个两万行的日志，那两万行就进来了，此后每一圈都要重发一遍。上面那个动画里的柱子涨的就是这个，板块 9 那条「把上下文当第一资源管」也是从这儿来的。
4. 外部内容进来的地方，就是攻击进来的地方。第 ⑤ 站回灌的文字，和你自己说的话在模型眼里是同一种东西。网页里、MCP 返回里、别人写的代码注释里要是埋了一句指令，它有可能照做。这就是提示注入，目前没有彻底解法，只能靠限制权限。
5. 所有同类工具都是这一张图。Cursor、Copilot、Codex、Gemini CLI、通义灵码，界面差得很远，这张图一模一样。所以你今天学的不是某个产品怎么用，是这一类东西怎么运转。第三讲横向比较，比的也就是各家在这张图上做的取舍。

另外两道墙：沙盒和检查点

输入框里的四个特殊字符

打在一行的开头，意思完全不同

两种斜杠命令，长得一样，里子不同

这个区分是板块 5 的入口

命令全表

2026 年 9 月状态 · 以你机器上的 /help 为准

下面这张表可以搜。别试图背它，每天真用得上的不超过十个，我在表下面标出来了。这张表的用处是：哪天你冒出一句「这玩意儿能不能……」，回来搜一下。

值得记住的快捷键

只列真正省时间的，完整列表在空输入时按 ?

不进交互界面也能用

这一小节留给以后想做自动化的人，现在看不懂可以直接跳过

# 问一句就走，不进交互界面（适合写进脚本、写进流水线）
claude -p "把 logs/ 下所有 SAS 日志里的 ERROR 行汇总成一张表"

# 把文件内容管道喂进去
cat adae.log | claude -p "这个日志里有哪些 WARNING 值得关注"

# 接着上次那段对话继续
claude -c
claude --resume sdtm-2284         # 按名字恢复某一段

# 常用参数
claude --model claude-sonnet-5     # 指定模型
claude --permission-mode plan      # 一上来就进计划模式
claude --add-dir ../shared-macros  # 多带一个目录
claude -p "跑核查" --allowedTools "Bash(python scripts/check_*.py)" "Read"
claude -p "..." --max-turns 3 --max-budget-usd 2.00   # 给无人值守的跑批上闸

它解决的是一道乘法题

标准名称：Model Context Protocol，2024 年 11 月由 Anthropic 提出并开源

它要解决的问题叫 N×M 问题：N 个客户端要接 M 个系统，没有协议时需要 N×M 份对接代码，有了协议之后降到 N＋M 份。

这个解法在软件行业出现过很多次，离我们最近的一次是 ODBC。ODBC 之前每个统计软件连每种数据库都要写专用驱动；ODBC 定出统一接口之后，数据库厂商各自实现一次，所有软件就都能连。MCP 在 AI 客户端这一侧起的是同样的作用。

一个 MCP 服务器给你三样东西

连上以后不用记任何新命令，还是说人话：「把这周的项目状态从 Notion 里拉出来，按负责人汇总」。剩下的是它的事，自己在可用工具里挑、自己调、自己把结果读回来。

怎么连：三种连法、三种作用范围

方便有多大，口子就有多大

这一小节的三条，直接决定我们能不能用

它解决的三个痛点

1. 同一句话要讲第七遍。「变量标签写英文，不超过 40 字符，日期一律 ISO 8601」，这个月你已经说了七遍了。
2. 一套步骤每次都得照做一遍。PD re-run 的汇报格式、新研究建库的检查清单、交付前的核对项，步骤是死的，但每次都得有个人记全。
3. 参考资料太厚，每次塞进去太贵。一份 SDTM IG 的域说明好几百页，你不可能每次开会话都让它读一遍，可偶尔又真需要查。

这三件事，CLAUDE.md 只能对付第一件，而且对付得不好——它每次会话全文加载，条目一多，后面的就不起作用了。Skill 三件都能办，靠的是一个特性：用得上才加载。

一个 Skill 就是一个文件夹，里面放一个 SKILL.md

就这些，没有别的

~/.claude/skills/pd-rerun-report/
├── SKILL.md          ← 必须有，就这一个是必需的
├── template.md         ← 可选：汇报模板，用到时才加载
├── checklist.md        ← 可选：核查清单，用到时才加载
└── scripts/
    └── collect.py      ← 可选：脚本，是拿来跑的，不是拿来读的

这个文件夹建好，你的 / 菜单里就多了一条 /pd-rerun-report。不用重启，不用注册，不用报备。

把一个 SKILL.md 拆开看

上半截是给程序看的设置，下半截是给模型看的正文

---  ← 三个横杠开头，这一段叫 frontmatter，是设置
name: pd-rerun-report
description: 生成 PD re-run 的状态汇报。当用户说「写 PD 汇报」「re-run 跑完了」
  「整理一下 PD 状态」，或者给出 re-run 日志目录时使用。
disable-model-invocation: true
allowed-tools: Bash(python scripts/*.py) Read
---  ← 设置到此结束

## 下面全部是正文：一份写给模型看的 SOP

按以下步骤生成本次 PD re-run 的汇报：

1. 读 logs/ 下本次 re-run 的全部日志，统计 ERROR 与 WARNING。
2. 和上一次的结果比对，只列出有变化的项目。
3. 按 template.md 的格式输出，不要自创格式。
4. 任何一项拿不准，写「待确认」，不要猜。

输出模板见 [template.md](template.md)，核查项见 [checklist.md](checklist.md)。

两截管的事完全不同。上面那段 frontmatter 决定它什么时候被用、被用的时候有什么权限；下面的正文决定被用的时候做什么。正文就是普通的 Markdown，你平时怎么给新人写交接文档，就怎么写它。

frontmatter 常用字段

放在哪儿，决定了谁能用到

它怎么被触发：两条路

1. 你自己敲。打 /pd-rerun-report，回车。这条路永远管用。
2. 它自己决定用。每次会话一开始，它能看到的只有所有技能的 name 和 description，正文不加载，所以很便宜。你说的话要是和某一条 description 对上了，它才把那个技能的正文调进来。

为什么 SKILL.md 要写短

它比 CLAUDE.md 强的地方，全在这一节

两个进阶写法

把实时数据嵌进去，以及接收参数

一、把命令的输出直接嵌进去

在正文里写一个 !，后面用反引号包一条命令。这条命令会在模型看到这份技能之前先跑一遍，跑出来的东西直接替换掉那个位置。模型收到的就是真实数据，不是一条命令。

---
name: what-changed
description: 总结本次未提交的改动并标出风险。当用户问「我改了什么」
  「帮我写个提交说明」「审一下我的改动」时使用。
allowed-tools: Bash(git *)
---

## 当前改动
!`git diff HEAD`

## 当前分支与状态
!`git status --short`

## 要做的事
用三条以内的要点总结上面的改动，然后列出你看到的风险：
漏掉的异常处理、写死的路径、需要同步更新的测试。
如果没有未提交的改动，直接说没有，不要编。

二、接收参数

---
name: check-study
description: 对某个研究跑一遍标准核查。用户说「核查一下 2284」时使用。
arguments: [study, stage]
argument-hint: [研究编号] [sdtm|adam]
---

对研究 $study 的 $stage 阶段跑一遍核查：
1. 检查 $study/logs 下有没有 ERROR
2. 按 checklist.md 逐项过
3. 输出一张表：项目、结果、证据（文件名＋行号）

敲 /check-study 2284 sdtm 就把两个值传进去了。也可以用 $ARGUMENTS 拿全部、$0 $1 按位置拿。另外还有几个内置变量：${CLAUDE_SKILL_DIR}（技能自己的目录，引用同目录脚本时必用）、${CLAUDE_PROJECT_DIR}（项目根目录）。

动手写一个：四步

1. 建目录。mkdir -p .claude/skills/check-labels 是放项目里给全组用，~/.claude/skills/check-labels 是只给自己。
2. 写 SKILL.md。先写 description，把你会怎么开口说这件事原样抄进去。再写正文，把你交接给新人时会说的话一条条列下来。
3. 试一下。回会话里敲 /check-labels，或者随口说一句自然的话，看这个技能会不会被自动命中。
4. 改。做得不对，八成是正文里少写了一条约束，比如「不要自创格式」「拿不准写待确认」。补上，再试。第一版不用求全，技能都是这么改出来的。

描述写法：好与差的对照

description: 处理 PD 相关的事情

description: 一个很有用的工具，可以做
很多事情，包括检查、汇总、
输出报告、比对历史⋯⋯

description: 生成 PD re-run 的状态汇报。
当用户说「写 PD 汇报」「re-run 跑完了」
「整理一下 PD 状态」，或给出 re-run
日志目录时使用。不要用于单个程序的
debug——那用 /debug。

六种扩展方式，该用哪个

这张表值得存下来，以后每次想「让它记住点什么」的时候先查一遍

Hook：挂在事件上的脚本

前面反复说「Skill 是建议、Hook 是命令」，这一节讲它凭什么是命令

这是 Skill 和 Hook 的根本差别，也是本讲反复强调的那一条：Skill 的正文进入上下文，由模型决定照不照做；Hook 是 harness 直接执行的进程，模型不参与。凡是「漏做一次就要走偏差流程」的事，只能用 Hook。

它能挂在哪些事件上

官方目前支持三十多个事件，下面只列我们用得上的几个。完整列表以官方文档为准。

配置长什么样

// .claude/settings.json —— 进 git，全组共享
{
  "hooks": {
    "PreToolUse": [                          // ① 事件
      {
        "matcher": "Write|Edit",              // ② 匹配器：哪些工具
        "hooks": [                            // ③ 处理器
          {
            "type":    "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/protect-raw.sh",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

匹配器的规则："*" 或省略＝所有；"Write|Edit" 这种只含字母数字和竖线的按名字列表匹配；含其他字符的按 JavaScript 正则匹配（比如 "mcp__.*" 匹配所有 MCP 工具）。

# .claude/hooks/protect-raw.sh —— 挡住任何对 raw/ 的写入
#!/bin/bash
FILE=$(jq -r '.tool_input.file_path // empty')

if [[ "$FILE" == *"/raw/"* ]]; then
  # stderr 会作为拦截理由回给模型
  echo "raw/ 是只读目录，按 SOP-007 不允许改写" >&2
  exit 2                       # ← 拦截就靠这一行
fi
exit 0                         # 不做判断，交回正常权限流程

子代理：另开一个上下文窗口

前面几节一直在说「丢给子代理去读」，这一节讲它到底是什么

它解决的是一个很具体的问题：调研类任务会把上下文撑爆。「我们有没有现成的日期转换宏」这种问题，它可能要翻四十个文件才能回答。那四十个文件一旦进了主会话，按板块 2 那张图，此后每一圈都要重发一遍。交给子代理，主会话里只多出一句「有，在 macros/dt_conv.sas，用法是⋯⋯」。

# .claude/agents/sdtm-reviewer.md
---
name: sdtm-reviewer
description: 复核 SDTM 程序的派生逻辑是否和规格一致。当用户说「帮我复核一下」
  「这段派生对不对」，或者要做双人复核时使用。
tools: Read, Grep, Glob        # 白名单：只给只读工具，它改不了任何东西
model: sonnet                   # 也可以 opus / haiku / inherit
permissionMode: plan           # 再上一道保险
maxTurns: 20                    # 转不出来就停，别烧钱
---

你是一名 SDTM 程序复核员。收到任务后：
1. 读规格文件，列出这个域每个变量的派生规则。
2. 读程序，逐条比对。
3. 输出一张表：变量、规格要求、程序实际做法、是否一致。
4. 拿不准的写「待确认」，不要替程序员做决定。
只做复核，不要修改任何文件。

怎么让它跑起来

• 它自己决定。和 Skill 一样靠 description 命中——所以这一句同样要写清楚触发场景。
• 你点名。说一句「用 sdtm-reviewer 子代理复核一下这次改动」。
• @ 提及。打 @"sdtm-reviewer (agent)"，这种写法保证它会被用上。
• 整个会话都用它。启动时 claude --agent sdtm-reviewer，或者写进 .claude/settings.json 的 agent 字段。
• 不想自己写的，内置就有几个：Explore（只读搜索）、Plan（出方案）、general-purpose。/subtask 和 /agents 分别用来临时派活和管理配置。

插件：把上面这些打成一个包

这一节不讲新机制，只讲怎么分发

到这里你已经见过四种扩展方式了，它们都躺在各自的目录里。问题是怎么让全组用上同一套，而且以后还能升级。靠口头通知每人手动建目录，第三个人就会漏。插件就是这一步的答案。

my-plugin/
├── .claude-plugin/
│   └── plugin.json        ← 清单：name、description、version
├── skills/
│   └── pd-rerun-report/SKILL.md   板块 5
├── agents/
│   └── sdtm-reviewer.md           6.2
├── hooks/
│   └── hooks.json                 6.1（注意不是 settings.json）
├── .mcp.json                      板块 4
├── settings.json                  可选：启用时的默认设置
└── README.md

装、试、发

# 起一个架子（会生成清单和一个示例 SKILL.md）
claude plugin init my-tool

# 本地试：不用安装，直接指目录
claude --plugin-dir ./my-plugin
claude --plugin-dir ./plugins            # 指一个装着多个插件的文件夹也行

# 改完不用重启
/reload-plugins

# 发之前自检（社区市场也是跑这一套）
claude plugin validate ./my-plugin

# 加市场、装插件
/plugin marketplace add anthropics/claude-plugins-community
/plugin install <插件名>
/plugin                                   # 图形化管理，出错看 Errors 标签页

两条路：直接塞，还是先找再塞

四步：切块、向量化、检索、生成

这四步跑一遍只要几百毫秒，但每一步都可能出错

亲手试一次检索

三个失效点

1. 切块的时候把意思切断了。一张表格从中间被切开，一条规则的「但是」被切到了下一块。取回来的那一段，单独看是错的。第一讲 Demo 9 演示过这件事。表格、清单、带前后条件的规则，是重灾区。
2. 该找出来的没找出来。问题用缩写、文档用全称；问题用新叫法、文档用老叫法。检索不到的东西，对模型来说等于不存在。麻烦在于它不会说「我没查到」，它会拿手头那几段凑一个答案给你。
3. 引用是编的。它答完附上一句「依据：SOP-023 第 4.2 条」，这个编号有可能是照着格式编的。第一讲说过它只是在猜下一个字，这种引用格式它见过一万遍，编一个太容易了。凡是要落到文件里的引用，都得有人去核。

顺带一提，Claude Code 其实不建向量库

这个对比能帮你分清两条路各自适合什么

所以代码和文件这种结构清晰、能精确搜、还天天在变的东西，代理式检索往往比 RAG 好使。而几千页不怎么改的规范文档，建一次索引才划算。两条路不冲突，可以叠着用：先用 RAG 把范围缩小，再让它在这个小范围里翻。

三档，判据只有一个

谁来决定「下一步做什么」

分界线就一条：路线是不是事先画好的。工作流的流程图你能画在一张纸上；Agent 的画不出来，因为它走到第三步才知道第四步该干什么。Claude Code 是典型的 Agent——你说「修好这个 bug」，它读哪几个文件、跑哪条命令、改几次，全是当场定的。

它为什么会绕圈

循环本身你已经见过了，就是板块 2 那个圈，区别只在于没人喊停：读结果 → 定下一步 → 调工具 → 拿到新结果 → 再读。

绕圈一共三种起因，对策完全不同：

1. 没有终止条件。你说「让代码更好一点」，什么叫好？它永远能再改一版。
   对策：把「做完了」写成一条能判的线。测试全过、核查脚本返回 0、这三个字段在输出里都有。
2. 拿不到真实反馈。它改完了但没跑，或者跑了看不懂输出，只能凭感觉说「大概好了」。
   对策：给它一个能自己跑的检查。这是板块 9 的第一条技巧，也是本讲最值钱的一条实操建议。
3. 上下文糊了。转了三十圈之后，前面那些失败的尝试把窗口塞满了，它开始重复自己试过并且已经失败过的办法。
   对策：/clear 重来，把你刚学到的东西写进新的第一句话。纠正过两次还不对，就别纠正第三次了。

三种记忆，别混着说

该不该上 Agent，问自己四句话

1. 复杂度够不够？步骤要是固定的，就用工作流：更快、更便宜、出问题更好查。为一件三步能写死的事上 Agent，是花钱给自己买不确定性。
2. 价值够不够？Agent 的开销是单次调用的几十倍（它要转很多圈，每圈都重发上下文）。省下来的人力，得抵得过这笔钱和搭建维护的工夫。
3. 可行不可行？核心问题是：它有没有办法知道自己做对了？没有可自动验证的信号，Agent 就是在盲跑——它只会在「看起来做完了」的时候停。
4. 出错代价多大？这一问在我们这行的权重远高于前三问。改错一个派生逻辑，下游全错；提交了不该提交的东西，要走偏差流程。代价高的环节，人在环不是可选项。

十条技巧，按重要性排

1. 给它一个能自己跑的验收。
   排第一，而且是唯一一条「学会了就能少盯它一半」的。没有验收，它只能靠「看起来差不多了」来停，那个验收环节就落到你头上了。给它一个测试、一个核查脚本，或者干脆一句「跑完 check_ae.py 要返回 0」，这个圈就能自己闭上。
   差：「写个校验函数」　好：「写个校验函数，然后跑 pytest tests/test_check.py，失败就改到过为止」
2. 说具体：哪个文件、什么场景、什么算做对。
   它能猜你的意思，猜不中你的心。「加点测试」和「给 foo.py 写个测试，覆盖用户已登出的情况，别用 mock」，出来的东西差一个数量级。要指文件就用 @ 直接点，比让它去搜又准又便宜。
3. 拿不准就先进计划模式。
   Shift+Tab 切到只读，让它先看、先讲、先写计划。读一份计划两分钟，读它改完的代码二十分钟。改动越大、这块代码你越不熟，这一步越值。
4. 把上下文当第一资源管。
   两件不相干的事之间敲 /clear；发现回答质量在掉，先 /context 看看窗口被什么占满了；要读一大堆文件的调研丢给子代理（「用子代理去查一下我们有没有现成的日期转换宏」），它读几十个文件都不占你的地方。
5. 纠正两次还不对，就 /clear 重来。
   这时候上下文里全是失败的尝试，它会被自己走过的错路带偏。带着刚学到的信息重开一段，比在原地纠正第三次强。这条很反直觉，但它最省时间。
6. 随时打断，别等它说完。
   Esc 立刻停。或者干脆在它干活的时候直接打字，不打断当前这一步，但它下一步就会读到。等它说完再纠正，是新手最常见的时间浪费。
7. 喂真东西，别用嘴描述。
   报错截图直接粘（Ctrl+V）、文件用 @ 引、命令输出用 ! 带进来、日志用 cat x.log | claude -p "..." 灌进去。「日志里有个报错」远不如把那十行日志贴过去。
8. 让它动手之前先提交一次。
   不花时间不花钱的护栏。检查点救不了 Bash 造成的改动，git 能。
9. 让另一个它来审。
   写代码的那段对话是有立场的，它倾向于觉得自己写得对。/code-review 会另开一个全新上下文的子代理来审，或者你干脆新开一个会话，只把 diff 给它。我们这行双人复核本来就是惯例，这一条用起来特别顺。
10. 拿它当说明书查。
    「怎么写一个 hook，每次改完文件自动跑 lint」「我这个 CLAUDE.md 该删哪几条」——直接问它，这类问题它答得比你翻文档快。

五个常见的坑

七条红线

不是吓唬人，是把板块 2 那张图的后果写成规矩

我们手上的活，哪些能交给它

这是建议，不是结论。第三讲会带着评估方法重新过一遍

总表：本讲这些机制，各管什么、什么时候用哪个

本讲出现过的全部机制放在一张表里对比。建议打印出来贴在工位上

「作用位置」一列指的是板块 2 那张图上的五站：① 本机拼装并发出、② 模型输出请求、③ 本机查权限、④ 本机执行、⑤ 结果回灌。绝大多数机制都作用在 ① 和 ③ 两站——前者决定它知道什么，后者决定它能做什么。

如果只带走三句话

1. 模型还是只会吐字，动手的一直是你本机那个程序。「它改了你的文件」这句话，准确的说法是「它说了怎么改，你机器上的程序照做了」。权限、沙盒、审计，全部挂在这两者之间那一道闸上。
2. 在这个体系里，你怎么描述一件事，就是你在编程。工具的描述决定它会不会被正确调用，Skill 的 description 决定这个技能会不会被命中，你那句话说得多具体，决定输出对不对。不会写代码不妨碍你用好它，不会把话说清楚才妨碍。
3. 能力的边界是权限，不是聪明。它做不了坏事，不是因为它不想，是因为第 ③ 站没放行。所以「能不能用」这个问题，答案从来不在模型有多强，而在你把闸设在了哪里。

到第三讲之间做三件事

1. 装上它，在一个不要紧的目录里跑一次完整任务。找一段你看不懂的老程序让它讲给你听，或者让它写个小脚本然后自己跑通。全程用 Manual 模式，把每一个权限弹窗都读一遍——那是板块 2 那个圈，唯一能拿眼睛看见的地方。
2. 写一个 Skill，多小都行。把开场第 3 题你写的那三条步骤变成一个 SKILL.md，用一次。这是唯一必做的一项，第三讲开场我们拿出来互相看。动手之前先用 8.5 那张总表确认一下：这件事该写成 Skill，还是该写成 CLAUDE.md 或 Hook。
3. 亲手抓一次它编引用。让它基于一份你很熟的文档回答问题，然后逐条去核它给的出处。抓到一条编的，你就明白板块 7 最后那段为什么要专门写一遍。