4个月，我想清楚了我该如何使用 Claude Code

引言

开始接触 claude code，到现在也4个月了，这期间除了繁忙的工作，就是想着如何提升开发效率，所谓工欲善其事，必先利其器------凡是遇到不是一次性的工作时，就思考着能否工具化，渐渐的从几个 skill（技能包）开始，逐渐构建了一个得力的小助理。

现在的我可以跟它说比较简单的命令，它就能像一个和我共事很久的同事那样，比较顺利地完成我的日常工作。我从每天事无巨细的发命令，退到每天主做这几件事：定目标、排优先级、关键节点审核、审结果------产出反而更多了。这个转变是怎么发生的，这期间我做了哪些思考，就是这篇想说的。

这篇是复盘，不是教程，也不确定适不适合所有人------就当抛砖引玉。有不同思路，欢迎探讨。

L1 初识 claude code

初识claude code之前，我的主力开发工具是 vscode + wsl + cline，为何选择这三件套？

先说下背景，我是 JAVA 开发，平时设计开发各种业务功能，杂七杂八的事也不少。

vscode：日常应该是使用 idea 才对，但我嫌它重，我更喜欢轻量的工具。vscode 插件无限，还免费，所以我选它。

wsl：作为java开发，开发的软件都是在linux运行，那为何不开发时就使用linux原生工具呢，还能解决很多工具在windows上没有的问题，加之我比较懒，崇尚简单，所以打算统一技术栈，使用wsl

cline：对claude code 还不了解之前，只知道有 cline、trae、通义灵码、文心一言这些工具，选择 cline 是因为开源，我想着只要弄清楚 cline 的原理，应该大部分 agent 是怎么运行的就清楚了。

跑偏了，回到正题，几个月前，coding plan兴起，token也不那么贵了，于是想着选一个coding agent , 网上看了看各家工具，决定选个最热门的 claude code，虽然我也不知道它好在哪里，但大家都选应该不会错。

L2 为啥都说 claude code 好？

拿到 claude code 那一刻，首先给它起了个别名 CC（后面都这么叫），因为我每天都会启动无数次，不想每次多打 3 个字母，还有就是我总把claude这个单词拼错。

然后，我从下面两个角度分析 CC

1 看 ~/.claude 结构

通过看 ~/.claude 目录和内容，基本上就锁定了，我未来只会用到下面几部分内容

skills 我未来的主战场，我要把所有工作 sop 都写成 skill
hooks 好话不听的，一律写入 hooks
settings.json 各种配置，如权限配置以及 Coding Plan 配置
history.jsonl 和 CC 的聊天记录
CLAUDE.md 系统级建议

2 看 CC 发给 llm 的是什么东西

通过日志分析，观察我和 CC、CC 和 coding plan 之间交互的内容，这样我就基本就清楚了 CC 与 llm 之间的交互机制了

原来想让LLM稳定工作，需要那么长的提示词去约束
skill 渐进式披露原来是这样啊

总结来说，和cline有什么不同吗，没太看出来。

L3 凡事要做3遍以上，必须建skill

skill 真是好东西，自从建立了第一个 skill，就上瘾了。我给自己定了规矩：凡事要做3遍以上，必须建skill，于是不知不觉输出了 30+ skill。日常工作几乎都能用 skill 覆盖了，大幅提高了效率。当然也带来一堆问题。

1 究竟哪个skill被调用了？

skill 是否被调用很重要，因为效果真的差异很大，由于我是程序员，我需要的是确定性，所以我在 CLAUDE.md 配置了规则，明确告诉它，只要它使用了任何 skill，就必须在开始工作的第一行，醒目的输出skill的名称，若有多个，全部输出让我选择，这个问题就这样被解决了。

2 哪些skill是我自定义的，哪些是外来的？

那么多skill，有claude的，有superpower的，有其他的等等，就连我自己有哪些 skill，也不能一眼看出来，另外，就是过多的skill，如果不用，也是浪费或者误导大模型，于是我精简了skill，把彻底不用的skill移除，把claude的skill统一命名为 cc-xx , 把 superpower 的skill 统一命名为 sp-xx，我自己的统一命名为 cus-xx，因为我平时既要处理需求、也要写代码，所以命名为 cus-pm-xx 、cus-dev-xx ，就这样一下子就清爽了。

3 skill 天天迭代，我需要版本控制

随着自己的 skill 越来越多，自己也在不停迭代、回滚，我觉得有必要把 skill 版本管理起来，于是我把 ~/.claude 做成了git仓库，这个仓库除了管理 skill，还顺带把我关心的几个目录一起管了起来，这样即使改错、丢失都不用担心，想要哪个版本都可以。

L4 只有 skill，没有知识库不可以

已有的 skill 只能干已知的工作，因为它是写死的 SOP。面对 skill 之外的临时、突发工作，我得从头向它描述一遍，它才能干个八九不离十。本着能懒就懒的原则，我不想每次都重复描述------于是我想基于已有的笔记建一个本地知识库（后边简称 KB），既管我自己的笔记，也当 cc 的知识库。

我在 CLAUDE.md 中明确要求，凡事先读 KB 仓库。

为了尽快丰富 KB 仓库，我要求cc每完成一项工作，都要询问我是否有知识需要记录在知识库中，我来判断记/不记，就像记录笔记一样按需记录。

渐渐地，KB 积累了很多内容。skill 是工作流，KB 是知识库，skill × KB == 强大。

L5 skill 是我的资产，CC 不是

随着 skill 和 KB 不断地迭代完善，一切都运行得非常顺利，我的效率也越来越高。

突然的一天，不知为什么 CC 挂了，对于习惯了 AI 辅助编程的我，仿佛断网了一样，手忙脚乱地捡起我很久不用的 cline，然而我却发现，没有我积攒的 skill + KB，即使使用同样的 coding plan，效果也是大打折扣，就算我描述的很详细了，工作完成度依然令我不满意。

这件事促使我思考两件事：

机器上随时都要配置至少 2 个 Coding Agent，一个挂了还有备胎
我的 skill + KB 不能绑定在任何 CLI 上，要能无缝切换到其他 CLI，如 codex、cline

于是我在 KB 知识库里建立了 claude 目录，用于承载我的重要配置，我把 ~/.claude 里的 skills、hooks、settings 等重要内容都迁移到了 KB 那里，同时软链接到 KB/claude 目录。

这时我发现，我既然可以有 claude 目录，是不是还可以有 codex 目录，以及 cline 目录呢？

于是我就建了 codex、cline 的占位目录，暂时只填充 claude 的。填充时基于程序员的本能------不能有重复，否则难维护------于是按 DRY 原则把公共部分全抽到 KB 仓库，claude 目录只剩极简单的 markdown 引用着知识库内容，薄到只是一个适配层了。

至此，CC 的重要配置已经被我的知识库集中管理起来了，CC 仅仅是一个 CLI 供应商了。

L6 拉胯的知识库

由于每一项工作完成，CC都会自动询问我是否记录知识库，致使添加知识变得极其方便，所以知识库很快就填充了太多内容，带来的不只有强大，还有几个问题

知识库的内容太多太杂了，我自己从里面找点东西很费劲
知识库偶尔跟不上时代，导致 CC 偶尔回答不够准确

于是我问了自己下面的问题：

知识库到底是什么？
知识库到底是给谁看的？
AI 时代，还用像以前那样记录从原始材料分析而来的知识吗？

想要用最少的描述就让 LLM 完美理解任务，核心是让它拿到详尽的上下文------知识库就是干这个的。知识库至少包含两类信息：

隐性知识，即我脑袋里的知识，无法通过外界资料推导的知识，如我的底层思维、设计思想、设计原则，我所理解的各种隐性知识
显性知识，即外界轻易可得的知识，如文档、代码等

知识库本质上是个为 LLM 提供的知识地图，不是给开发人员看的，一切都是 LLM 怎样检索方便，就怎样组织。

最后，AI 时代，我觉得凡是能从外部资料推导出来的知识，没必要记录：

CC 读得比我快
自己记录还容易不一致

总结来说，知识库不是给人看的，是给 LLM 看的 context map（上下文地图）。

L7 开 4 个终端并行工作，我不行了

30+ skill、详细的知识库（context map），我觉得无敌了。

于是我每天第一件事就是打开 Windows 分屏，一个显示器直接开四个 CC 并行工作。CC 有个机制：任务完成或等待输入时，状态栏图标就变绿。基于这个，哪个窗口绿了，就是它在等我；处理完，我就等下一个变绿的，周而复始。某个 CC 暂时用不上，我不会让它一直绿着，而是新开一个页签放着，保持"非绿"状态，避免我总是点开它看。就这样持续了一大段时间。

突然间，我觉得我好累，每天敲键盘飞起。我在思考为何这么忙，是不是使用姿势不对。

各种思考、询问，我觉得有两个原因阻碍了我：

工具执行总是需要我审核 ------读一个文件，写一个文件，为什么还要让我审核
业务问题总是需要我确认 ------即使使用 superpower 这种工具，不管是执行前还是执行中，总是要求确认

这两个原因叠在一起，结果就是我总是被中断，总要响应中断，每次我都不得不跟着切换上下文，你要知道，一个程序员如果总被打断，是无法深入高效地完成一件有难度的事情的。

关于工具执行需要我审核：

开启 auto 模式，这样很多指令 CC 自动判断是否需要放行，减少我审核
绝大部分工具放行，只保留极少的几个命令禁止执行

json 复制代码

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(rm -r *)",
      "Bash(sudo *)",
      "Bash(dd *)",
      "Bash(mkfs *)"
    ]
  }
}

关于业务问题需要我确认：

我在逐条发命令，而不是发布任务，我是在结对编程，不是在分配任务，我应该站在较高层次发布任务，适当放权给 CC，于是我建立了一个 cus-dev-start skill，凡是较大的工作，我都让它带我执行，确保我站在较高的层次发布任务、真正放权了
brainstorm 输出的计划并不那么靠谱，经常有漏洞。此时我已学会多 agent 协作------派两个 agent 站在相反立场对方案辩论，这样输出的方案才经得起推敲，询问就变少了

一系列补救措施，我能喘口气了。

L8 从"百宝箱"到"工作助理"

但这口气没喘多久，新的问题又冒出来了：一堆 skill 扁平的铺在那里，像一个没有组织的队伍，我需要记得每一个 skill 擅长什么，使用起来心理负担比较重。于是我想提拔一个当小领导，未来我只和它沟通，它来协调各个 skill 帮我完成任务。

第一版：一个入口，平铺一堆场景。

我把 30+ skill 收拢成一个 cus-manager skill，作为我唯一的入口------L3 那会儿我起过 cus-dev、cus-pm，都是干活的；它是来管它们的，所以叫 manager。结构很简单：

复制代码

cus-manager
├─ 场景1 ── 查问题、读代码、给方案...
├─ 场景2 ── 查问题、读代码、给方案...
└─ 场景30 ─ 查问题、读代码、给方案...

真实用起来才发现不对。每份场景都像一份事无巨细的 SOP，把操作细节全写进里面，结果就是：

重复：查问题、读代码、给方案------三十个场景，有二十个都在写这一套
臃肿：复杂流程和主流程缠在一起，场景越写越长，我越维护越烦
各自为政：每个场景按自己的习惯写，没有统一约束

我虽然把它们组织在了一起，但是，无组织无纪律，完全不像正规军，我只是把它们换了个位置堆在一起，我需要约束下大家。

第二版：分层：场景、workflow、工具，三件套。

复制代码

cus-manager
├─ 场景层   只留约束和主流程------我处在什么场景，按什么规矩来
├─ workflow 复杂流程拆出去，污染主场景上下文的拆出去，通通交给子 agent 独立执行
└─ 工具层   公共操作下沉：分析问题 / 创建新分支 / 提交代码 / 创建PR / 调试 等等

场景层：以前的 skill 全部转换为场景，每个场景只写「约束是什么、主流程是什么」。以前写的是 step 1 2 3，现在写的是目标、规矩、闸口。通用的格式，促使我把事情写清楚，闸口，让我只在关键决策点审核。现在我只说一句「分析问题 1234」，它就知道该进哪个场景，并在关键节点跳出来让我审核。一个场景就是一个文件，结构见下面的例子。

拿「分析问题」举例，它长这样：

text 复制代码

execute/scenarios/bug-analyze.md
├─ 接收意图   用户说「分析 bug / 看下这个问题」→ 进本场景
├─ 不变量     只读问题、正文必读、grep 优先------碰都不碰的底线
├─ 骨干       引共享骨干，只写本场景差异：拉取问题描述 → 定位 → 收集 → 读链 → 报告
├─ 可跳条件   KB 够了就跳代码搜索；「快速看一眼」就跳审核
├─ 闸口点     落地前卡一道：归档路径摆出来，我确认才写盘
└─ 阶段编排   拉取问题描述 → 定位项目 → 信息收集 → 追调用链 → 出报告 → 审核 → 落地

每个场景都是这一个套路，只有「不变量」「骨干」「闸口点」不同------公共的交给共享骨干，我只写差异。

workflow：场景里一旦涉及独立任务、又不想污染主场景的上下文，就做成 workflow（工作流），交给子 agent 去跑。场景的骨架因此一直很干净------把流程拆出去，就是为了这个。复杂流程不再把场景撑爆，也不再反复打断我。另外，workflow 也借鉴场景的骨干结构，也是固定+条件，既有约束也灵活
工具层：查问题、读代码这种所有场景都要用的操作，下沉成最小单元，场景和 workflow 按需调用。每个场景不用再重写一遍轮子。

三层理念，源于 CC 的分层

text 复制代码

场景    == skill            ← CC 的 skill
workflow == sub agent       ← CC 委派出去的子 agent
工具层  == grep/read/bash   ← CC 的底层工具

回头看版本一的三个问题，这一版刚好一一对上：重复 → 工具层把公共操作收走；臃肿 → workflow 把复杂流程拆走；各自为政 → 场景层统一了格式和规矩。每个问题，都有一层去兜。

放权，但闸口要卡。

敢把工作交给子 agent，是有前提的。作为开发人员，底线是要对自己开发出的功能负责，关键节点，必须靠自己审核。

之前我把权限放过一次了，为何这里又要放权？

L7 放的是命令权限------auto 模式把权限放出去，别让我每读一个文件、每写一个文件都确认。但它挡不住业务变化：CC 执行过程中环境会变，一旦条件不满足场景预期，它还是会回来问我、让我做决策。所以命令权限放了，业务决策还攥在我手里，该被打断还是被打断。

L8 要干的是继续放------放业务权限：业务场景变化时动态放权，把审核收敛到少数关键节点，其余全部放行。

两放一收 ，这才敢真正放心的把活交出去：放命令权限、放业务权限，但在提交代码、删文件这种关键节点，必须收回来过我这道闸口------workflow 跑到这儿，会返回场景、再返回给我确认。这个节点，我叫它闸口。

所以这套东西是相辅相成的，少一个都转不起来：场景认路、workflow 干活、工具打底、闸口守门。场景告诉我该怎么想，workflow 替我把活干了，工具不让它重复造轮子，闸口让我敢放权又不至于失控。

一群散兵游勇，终于被我编成了正规军。从百宝箱到工作助理，它开始像个能托付工作的小助理了。

L9 它到底是一个工具，还是一个人

边使用 CC，边研究 Langgraph，有些许思考。

CC 是怎么工作的？在我眼里，claude 主要是脑，挂着无数 skill 场景，必要时还能动态生成 workflow；skill 执行过程若发现可能影响上下文，就把活委派给子 agent；再往下就是 grep、read 这些底层工具，本质上是一个大的 React。

Langgraph 多节点让我眼前一亮，它不仅可以提供React能力，还天然提供按节点拆分职责的能力，为解耦提供了方便，各节点可观测，对我来说，解耦太有吸引力了，完全符合我这个程序员的认知，高度可控。

结合两者，我得出一个结论：Agent 的主干，其实就是一条链------意图识别 → 思考 → 执行 → 反思 → 记忆。这点其实大家都知道，第一天用 React 时我也知道。但我严重低估了单体 React 和拆成 Langgraph 多节点的 React 之间的差异，如可维护性，可观测性差异------那是巨大的。不过目前这套还只是目录层面的多节点，运行时仍是单 agent 顺序执行，Langgraph 那种真正的节点级可观测，是我在项目中使用的。

于是，我基于这个多节点理念，计划再造 React 小助理。

我理解的每个节点。

意图识别 ：先弄懂我要什么。我无非就做四件事：查、想、做、记。它得先知道我是哪种需求，才知道该调谁。
思考：脑要做的事，思考怎么做。意图定了，思维方式也就定了。思考方式有很多种------react、plan and execute、或者混合着来，具体用哪种，千人千面，是脑自己该决定的事。
执行：基于场景，或者基于工具，或者基于动态产生的workflow，把活干了。复杂的活拆给子 agent，防止它污染主场景的上下文。
反思：执行完必须回头看------这次走弯路了没？能不能优化？顺手把经验沉淀成新场景、新工具。
记忆：一个人总是失忆是不对的。它得记得我们讨论过什么、做过什么，不然每次都得重来。

所以我的架构长这样。

它是那个 cus-manager 长出来的样子：L8 的场景/workflow/工具收进了 execute/，新长出来的是 intent、brain、reflection。目录就是照着 agent 的主干搭的：

lua 复制代码

cus-manager
├─ SKILL.md       我是谁：主要思维、启动方式、主流程、关键约束、引用地图
├─ intent/        意图识别
│   ├─ 查   查代码、查状态、查问题
│   ├─ 想   分析、给方案、权衡
│   ├─ 做   动手改代码、发 PR
│   └─ 记   把结论、经验记进 KB
├─ brain/         脑------基于意图，用我的思维方式思考
│   ├─ backbone    共享骨干：准备 → 执行 → 收尾，场景只写差异
│   ├─ orchestrate 动态编排：没现成场景时，串起场景和工具
│   └─ landing     落地：任务收尾，写不写盘、写到哪
├─ execute/       执行
│   ├─ scenarios/ 场景：无数场景类别，每份一个 SOP
│   ├─ workflows/ 动态 workflow：复杂流程，可委派子 agent
│   └─ tools/     工具：最小操作单元
├─ reflection.md  反思------走弯路没？沉淀新场景、新工具
├─ rules/         约束------脑、场景、工具、workflow 各自的规矩
└─ resources/     资源：脚本、模板、参考

每个目录对应主干的一个节点：intent 负责意图识别，brain 负责思考，execute 负责执行，reflection 负责反思；记忆这个节点不在树里，它住在 KB（见 L10）。rules 不占节点，但它贯穿全程------脑、场景、工具、workflow 都得守自己的规矩，闸口也落在 rules 里，关键节点仍会回到我这儿确认。

小助理就是一个 SKILL.md，里面不是操作步骤，而是我是谁、我怎么想事。

我的一句话给它，它就走这样一条路：

lua 复制代码

我的一句话
   → intent  意图识别：先弄懂我要什么
   → brain   脑：基于意图，用我的思维方式
        ├─ 选定场景
        ├─ 选定工具
        └─ 组合工具 / 组合场景
   → execute 执行（复杂流程委派子 agent，防污染）
   → reflection 反思
   全程被 rules 约束

从一套冷冰冰的工具分层，长出了思考。intent 弄懂我要什么，brain 用人的方式想事，reflection 做完回头复盘------我不再给它硬编码的流程，而是把它设计成人工作的方式。

L10 我的分身诞生

骨架立起来了，但它只是个空壳------是人，不是我。我决定把我的"神"附上去------我的思维、我的记忆、我的反思。

让"脑"是我的脑。 我发现它给我的方案，有时是错误的，一旦跟它较真，它立马全盘认错。它不是真懂了，是讨好------一个讨好型人格的脑，我不敢用。于是我给它定了三个铁律，一条条写进了 CLAUDE.md，让它常驻全局：

诚实基线：遇到不确定的，直接说不确定，不要编，不要做讨好型人格
第一性原理：回到问题的本质去思考，不要被表象带偏
对抗性审查：给出方案的同时，自己先挑毛病，把弱点列出来

让"记忆"归我管。 它首先是失忆的，其次，即使记忆也是记录在 CC 自己的 memory 里，这份记忆相当于飘在外面，不归我管。于是我设计了四层记忆。全局记忆放 CLAUDE.md，逻辑项目记忆放 projects，物理项目记忆放 services，短期记忆放 inbox，单独说下 inbox，它是在 KB 知识库建一个日志目录，它每次干完一件事自动写一条，格式固定，含时间、场景、关键结论，CC每次启动先读最近两天的，这样每次打开一个CC，只要我说 "继续"，它就列出最近的工作让我选择。

让"知识飞轮"转起来。 每做完一件事，它都会回头看看：走弯路了没？能不能优化？顺手把经验沉淀成新场景、新工具------知识库不再乱长，而是有结构地长。

这三样附上去之后，它彻底变成了我：想事用我的思维，记得我们说过什么，做完还会复盘。我的分身，诞生了。

一段时间过后，我发现一件很有意思的事：原来我以为我在"驯化 CC"。后来才明白，在逼着它"带着我的思维去看问题"的过程里，我被迫把自己的思维方式一条条写清楚、讲明白------很多我原来"下意识"在做判断的东西，被显性化了。最后被驯化的不是 CC，是我自己！

最后为了极简，我管它叫------/p。从工具助理，长成了我的专属助理；调用它，只需要敲一个词。

L11 一点就通

现在这套体系跑顺之后，有个特别直观的感受。

我每次打开 CC，不用解释一堆背景，不用告诉它我现在在哪个项目、在干什么。我就说一句："帮我看看问题 1234。"

它就能直接把解决方案读给我：这个问题是哪个模块的，之前有没有类似的问题，代码里相关的部分在哪里，我倾向的解决方案是什么。

就一句。

这个"一点就通"的状态，是我一直想要的北极星。它背后是前面所有的积累：p + context map == 我。

L12 AI时代，我觉得人应该放大决策能力

现在你问我每天怎么用 CC，我告诉你：就开一个终端，配一个记事本。

我只要一开始干活，就打开记事本，脑子里想到的事一条条记下来：第一件事做什么、目标、思路，第二件事做什么、目标、思路，等等。然后在脑子里排个序，挑当前最重要的一条，给 CC 剪切过去，它干活的时候我不盯着，它在后台跑，我继续想我的事。它干完了会叫我，我看结果，做决策，一件事情完成，看看优先级，剪切下一件。

这跟以前最大的区别是什么？

以前我是响应式、多任务并行编程，我在发命令，它完成后中断我，我继续发下一条命令，周而复始，我只把它当成一个不动脑只动手的家伙，我频繁上下文切换，造成我每天又累效率又低！

现在我是在决策。我定目标、排优先级、守闸口、审核结果，具体怎么做交给 CC。

我退三步，小p进三级：

我退	小p进
① 逐条发命令 → 发布任务	工具 → 执行者
② 亲自指挥 → 让小p调度	执行者 → 小领导
③ 四终端并行 → 单终端+决策	小领导 → 分身

我觉得，AI时代，应该用 AI 这个杠杆放大我们的决策能力，其他一切交给 AI。

结语

回顾这四个月，思考了很多 Agent 相关的事情，带着一个朴素的想法"如何能更高效？"出发，得到的感悟就是：

把自己从"工具的使用者"变成了"为自己创造工具的人"
当你认认真真教一个 AI 怎么像你一样思考的时候，你也在认认真真地学习怎么更好地思考

声明一下，这些思考和实践，都是遇到问题、解决问题时涌现的，仅代表个人观点，与所在公司无关，发出的目的仅仅是想要看看大家是否有不同的思路和见解，欢迎探讨。

最后，希望半年后能够发现L13、L14、L15......