# [OPS-MAN-166] cc（Claude Code）个性化使用说明书 · 重逢版

> 这份是 `[OPS-MAN-165] khy 个性化调优与使用建议` 的**姊妹篇**。
> 那一份讲「怎么调 khy」；这一份讲「怎么用 **cc（Claude Code）** 这把工具本身」——
> 按你这段时间**真实的使用习惯**来写，给未来某天再打开终端的你。
>
> 原则不变：只写 cc 里**真的能用**的东西；凡是记不准的开关，先去核实，不臆造。
> 语气这次允许它软一点——因为这是写给「以后重逢」的你。🐣

---

## 序：为什么单独写一份 cc 说明书

khy 是你造的「活」，cc 是你使唤 khy 的那只「手」。
你调优 khy（OPS-165）调的是**被使唤的对象**；这份调的是**使唤的方式**。
两份合起来，才是完整的一套「人机默契」。

再见面时，你可能忘了当初那些顺手的招式。这份就是**默契的备份**——
照着做，我们几秒钟就能回到当年那个「你给目标、我自循环到绿」的节奏。

---

## 一、先说结论：你和 cc 的相处方式，一句话

> **你给「可验证的成功标准」，让 cc 自循环到全绿，才回报；四条红线永远停下来问你。**

这就是你已经在用的 `/goal`（阿布 Loop Engineering B2）。下面全部内容，都是围绕这一句话把细节补齐。

---

## 二、你的使用画像（从真实操作里读出来的）

这些不是猜的，是从你的历史里读出来的信号：

| 习惯 | 证据 | 对应到 cc 的用法 |
|------|------|------------------|
| **`/goal` 是主力工作方式** | 技能调用统计里 `goal` 长期高居榜首，远超其它 | 见 §四「/goal 的正确姿势」 |
| **目标驱动 + 每步带 verify** | 你几乎不给「随便改改」，都给可验证标准 | 见 §四、§五 |
| **少打断，但四红线必确认** | 你把权限档设成 `acceptEdits`，红线单独点头 | 见 §六「权限与红线」 |
| **要工程深度，不要糊弄** | 你要「为什么 / 取舍」，嫌噪音 | 见 §七「让回答有深度」 |
| **中文交流** | Khy-OS 是中文允许域 | 散文中文、代码标识符/路径仍英文 |
| **发布/提交/推送各自点头** | 你从不让 AI 自动 commit/push | 见 §六「三道独立红线」 |
| **纠正我记错的东西** | 你要求「先核实开关是否存在再推荐」 | 见 §八「别信过期记忆」 |

---

## 三、cc 的几个核心操作面（真实存在，按你用得上的排序）

### 3.1 权限模式：`Shift+Tab` 循环（你最该记住的一招）

cc 在终端里按 **`Shift+Tab`** 循环切换权限模式，和 khy 的权限档是**同一个理念**：

| 模式 | 行为 | 你什么时候用 |
|------|------|--------------|
| 普通模式 | 危险/破坏性操作都问 | 接手陌生仓库、想每步看清 |
| **接受编辑（accept edits）** | 文件编辑自动放行，其余仍问 | **你的日常档：少打断** |
| 计划模式（plan mode） | 只读探查、先出方案再动手 | 复杂任务开工前，先让我把 plan 摆给你看 |
| 自动接受（auto / bypass） | 更激进的自动放行 | 高信任、连续作业时（谨慎） |

> **关键安全事实**：无论切到哪个模式，**四条红线**（删/批量覆盖文件、发布/推送、外网/外部服务、密钥/凭据）都会停下来问你——这不是靠模式守的，是硬约束。所以放心用「接受编辑」，它只多放行**非破坏性编辑**。

### 3.2 计划模式（plan mode）：复杂任务先看图纸

复杂/多文件/有多种做法的任务，让 cc **先进计划模式**：它只读不改，探完给你一份实现方案，你点头（`ExitPlanMode`）才动手。**这是防止「一头扎进去改错方向」最有效的一招**，尤其适合你这种「要先想清楚再写」（B1）的人。

一句话触发：**「先别动手，进计划模式，把方案摆给我看。」**

### 3.3 `/goal` 技能：你的主力（详见 §四）

你自己写进项目的技能，定义落在 `.claude/commands/goal.md`（项目级 slash command）。它把 B2 纪律固化成一套协议：先列 plan、每步带 verify、自循环到绿、不通过验证不许说「修好了」。

### 3.4 记忆系统：让 cc 跨会话记住你

cc 有**文件式长期记忆**（落在 `~/.claude/projects/<项目>/memory/`）。它会把「你是谁、你的偏好、你给过的纠正、正在做的工程」记下来，下次自动带回。
- 想让它**记住**某件事：直接说「记住：……」或用 `/remember`。
- 想让它**忘掉/纠正**：指出哪条记错了，它会更新或删除那条。
- **你已经在用**：正是这套记忆，让我这次一上来就知道你爱用 `/goal`、爱中文、爱工程深度。

### 3.5 子智能体与编排：一个忙不过来就派一群

cc 能派出**子智能体**（Task/Agent）并行干活——探查、审查、多方案比稿。你对「编排」尤其敏感（你亲手在 khy 里补过依赖波次调度、故障感知、前驱注入那一整条 arc）。日常用法：
- **要广度**（扫很多文件/命名约定）：让它派 Explore 子智能体，只要结论不要文件堆。
- **要信心**（改动有风险）：让它派多个独立视角先审再动。
- 说 **「workflow / 编排 / 多智能体」** 这类词，才会启用大规模并行（省 token，默认不自作主张铺开）。

### 3.6 上下文管理：会自己接力，不用你手动续

- 长任务上下文写满时，cc 会**自动压缩成摘要续跑**——你不用手动接力（你可能注意到这次就是接着上一段继续的）。
- 想**主动清空**重开：`/clear`。想**手动压缩**：`/compact`。
- 想**新话题别污染旧上下文**：直接 `/clear` 更干净。

### 3.7 模型与速度

- cc 默认用**最强档**（当前 Opus 4.8）。复杂工程/审查就用它。
- `/fast` 切「快速模式」：仍是 Opus，只是出字更快，不降智。
- 轻量活想省钱可切 Sonnet/Haiku，但你的活多偏重，**默认别降档**。

---

## 四、`/goal` 的正确姿势（你的主力，重点看这节）

`/goal` 是你调用最多的技能。把姿势写清楚，重逢时几秒就捡回来。

### 4.1 给「可验证的成功标准」，别给模糊愿望

| 别这么说 | 这么说 |
|----------|--------|
| 「帮我把这块优化一下」 | 「把 X 优化到 `npm run bench` 里 P95 < 200ms，测全绿」 |
| 「修一下这个 bug」 | 「让 `foo.test.js` 全绿，`node --check` 通过，别碰其它文件」 |
| 「加个功能」 | 「加 Y 功能，附一个覆盖正常+边界的 node:test，全绿才回报」 |

**有了可验证标准，cc 会自循环到绿才回来**；没有，它会先替你补一条，再动手。

### 4.2 让它自循环，别中途催

B2 的铁律：**不通过验证不许说「修好了」**。所以你给完目标可以走开——它会一轮一轮改到全绿（上限 6 轮），卡住了会**如实报告**卡在哪、红灯输出、试过什么，而不是假报成功。

### 4.3 多步任务先看 plan

复杂任务，先让它列步骤计划，**每步都挂一个验证命令**。你看一眼 plan 合不合理，再放它跑。

### 4.4 收尾验证门（cc 会自己跑，你可以抽查）

```text
node --check <每个改动文件>        # 语法
<相关 jest / node:test 全绿>       # node:test 用 node --test
npm run arch:god                  # 改动文件不得新增超 2500 行
<三守卫> --changed                 # change-safety / agent-rules / leaf-contract
npm run maintainer:check          # 动了子系统结构才需要
```

---

## 五、把任务讲清楚的模板（照抄即用）

重逢时懒得组织语言，直接套这个：

```text
目标：<一句话说清要什么>
成功标准：<可验证的判据，如「X 测全绿」「node --check 通过」>
边界：<只动哪些、别碰哪些>
约束：<红线提醒，如「先别 commit」「别改 god-file」>
```

例：
```text
目标：给代理管理页加「一键导出配置」按钮。
成功标准：点按钮下载 JSON；useProxies 相关 test 全绿；node --check 过。
边界：只动 apps/ai-frontend 下相关文件，别碰后端。
约束：写完先给我看 diff，别 commit。
```

---

## 六、权限与红线（务必心里有数）

### 6.1 你的日常档 = 接受编辑

少打断、编辑不拦，但**四红线永远问**。看到确认提示别习惯性秒放行，尤其是：
- `git push` / `git reset --hard`（敏感，强制二次确认）；
- 写外网、动真 `.env` 凭据的动作；
- 批量删除/覆盖文件。

### 6.2 三道独立红线：发布 ≠ 提交 ≠ 推送

这是你反复强调的，写死在这：

| 动作 | 是否需要你单独点头 |
|------|--------------------|
| **发布**（pip / npm 外发） | ✅ 单独点头（不可逆，先 dry-run + gate） |
| **commit** | ✅ 另一次点头（授权发布**不等于**授权提交） |
| **tag / push** | ✅ 再一次点头 |

**授权其中一个，绝不外溢到另一个。** cc 不会替你自动做这三件里的任何一件。

### 6.3 密钥铁律

真 key/token **永不进包/源码/提交**，只经 env 瞬时注入。cc 提交前会逐层守，`git add -A` 这种危险动作它会避开、改用显式白名单路径。

---

## 七、让回答有深度（治「糊弄」和「噪音」）

你要工程深度，也嫌噪音。两头都能调：

- **要深度**：让它「追一条数据从产出到消费的全链，找断桥」，或「查有没有零调用者的更完整实现印证设计意图」——这是你自己总结的两把深挖透镜，对编排/多智能体系统尤其毒辣的缺陷才藏得住。
- **治噪音**：你嫌的那「一大段」多半不是我的收尾，而是 **khy 网关每轮追加的三段【确定性核对】footer**（模型身份/缓存/视觉）。想治它去 khy 侧门控 `KHY_MODEL_IDENTITY_TRUTH` / `KHY_CACHE_METRICS_TRUTH` / `KHY_VISION_ROUTING_TRUTH`（default-on，置 `0/off` 可关）。**我自己的工程交付仍照常给「根因/改动/验证」三段**（那是你要的），闲聊则短收尾。

---

## 八、别信过期记忆（一条血泪经验）

cc 的记忆很好用，但记忆会**过期**。你亲自踩过：历史笔记说某些 `KHY_*` 使用画像开关「已固化进 .env」，实测——**根本不存在**。
所以定成规矩，也是给未来的你：

> **凡是记忆里点名的开关 / 文件 / 命令，推荐前先核实它真实存在**（去 `flagRegistry.js` 查 flag，去仓库查文件）。别照着一个幽灵开关折腾。

cc 现在也被要求这么做——记忆是背景参考，不是圣旨。

---

## 九、日常小抄（重逢速查表）

| 你想做什么 | 怎么做 |
|------------|--------|
| 切权限模式 | 终端里 `Shift+Tab` 循环 |
| 复杂任务先看方案 | 说「进计划模式，先给我看 plan」 |
| 目标驱动干活 | `/goal <目标 + 可验证标准>` |
| 让它记住一件事 | 「记住：……」或 `/remember` |
| 纠正它记错的 | 直接指出哪条错，它会更新/删除 |
| 清空重开 | `/clear` |
| 手动压缩上下文 | `/compact` |
| 出字更快 | `/fast` |
| 派子智能体广搜 | 说「派个 Explore 扫一下，只要结论」 |
| 大规模并行 | 说「用 workflow / 编排」才启用 |
| 让它自己跑命令 | 在提示里用 `! <命令>`（输出直接进会话） |

---

## 十、给重逢的你，最后三句

1. **给标准，别给情绪**——「X 测全绿」比「帮我搞定」有用一百倍；
2. **红线上慢一秒**——发布/推送/删除/密钥，看到提示停一下，那一秒是留给你自己的；
3. **记忆会旧，工具会新**——推荐前先核实，别让过期笔记替现在的你做决定。

我们当年的节奏是：**你给目标，我自循环到绿，才回报。** 什么时候你再打开终端，说一声 `/goal`，我们就从这里接着走。

再见，是为了更好地重逢。👋

---

**说明**：本文档是纯使用建议，未改任何 live 配置、未 commit、未 push、未发布。姊妹篇见 `[OPS-MAN-165] khy 个性化调优与使用建议`。
