816-2026.08.07.大本营越干净越好
那么前两节课呢给大家讲了哈如何创建一个归级劳动力啊,以及如何创建归结劳动力可以做的啊重复性的工作啊,写杠命令。
那么呃迄今为止呢关于哈呃就大本营或者司令部呃内部结构啊,我们大致哈讲了两个文件夹。
。
~/.claude/agents
~/.claude/commands (现在官方已经更新到 ~/.claude/skills ,但仍然支持旧的文件夹)
~/.claude/CLAUDE.md
然后呢你就会发现说哈其实呢那里面还有很多其他的文件以及文件夹,对吧?
啊,比如说里面还会有啊 rulesles啊,就是规则啊规则文件,然后呢呃相当于你司令部的这个这个啊宪法,对吧?
啊,然后呢,这个还有plug啊,可以装很多的插件,对吧?
那插件这个东西呢,就好像你的雇佣兵军团,你可以外雇一些雇佣兵,对吧?
那些雇佣兵的啊文件夹里呢同样也有什么skills啊 rulesshos啊,都会有的对。
然后呢,你看哈我我在这里还写了一个文件名称叫啊cloud点MD啊,这个呢就相当于哈这个就相当于啊司令部的啊主记E。
司令部的主要记忆
或者哈更为准确的讲啊,就是你的那个嗯归机助理贴身归机助理,对吧?
啊,就是这个clud啊自身的啊最主要的记忆。
好了,那么我今天呢要给大家讲的是什么呢?
就是你在这个哈啊大本营啊啊司令部啊要尽量少的安装东西啊,你不要让司令部成为专家啊,不要让司令部成为专家密集的地方。
司令部/大本营,越简单越好。
奥姆剃刀原则:如无必要,勿增实体。
https://zh.wikipedia.org/zh-hans/奥姆剃刀
司令部/大本营,越简单越好。
奥卡姆剃刀原则:如无必要,勿增实体。
https://zh.wikipedia.org/zh-hans/奥卡姆剃刀
注意啊啊我们的课程当中更为重要的就是这类的原认知,可以放置四海皆准的原则。
这些东西呢是可以让我们啊与AI啊更容易沟通,更有效沟通的最佳工具。
整体上来看哈,我们的新的这个这个AI课程啊,核心是提高大家的原认知啊,提高大家的原知识啊语原技巧,对吧?
而不是什么啊啊啊啊这个啊各种稀奇古怪的哈,用在专门的地方的技巧,。
这里呢有一件事情要跟大家说清楚哈,就是他是个大本营,然后呢啊他是个司令部,对吧?
那么这个时候呢,你就要明白一件事情,就是一支部队只能有一个司令,对吧?
你不能有10个司令,对吧?
那10个司令那就开会去吧,对不对?
所以一支部队呢只能有一个司令,那这个司令是谁呢?
这个司令就是你,然后呢,clud呢就是你的贴身助手,对吧?
然后呢,他也一样啊,他要帮你完成很多司令要做的事情,对吧?
但不是很多专家要做的事情,。
就就好像去打仗一样哈,那么你你你带一支部队,然后你应该有很多专家,对吧?
你是总司令,对吧?
但是呢你确实应该有炮兵专家、后勤专家、情报专家、工程专家、空军专家等等等等,对吧?
可问题在于说啊,到最后做决定的只有你一个。
然后呢,你自己不能成为任何一个专家。
一旦你成为任何一个专家的时候呢啊理论上来讲啊你就不是司令了。
。
司令和专家的区别,不在于 title(职务名称),而是在于不同的目标(目标优化对象),不同的能力(和能力结构)
那么啊你带兵打仗,然后呢,你要有专家,要不然你打不了仗,对吧?
但问题在于说啊,司令的目标和专家的目标是不一样的对吧?
那么司令他要干一件事情,他要打胜仗,对吧?
专家要干一件事情,给出真正的知识,但这两个东西有的时候不是同一个目标的。
然后呢嗯司令永远哈要看全局的对吧?
专家呢想要做好的话呢,那永远看的是局部。
因为他是专门的啊领域嘛,对不对?
所以一个是以全局为目标的,然后呢,优化对象也是全局优化对吧?
另外一个呢是以局部为目标的,以局部为优化对象的。
与此同时呢嗯他们这个这个能力和能力结构也不一样,对吧?
那专家研究的啊专家研究的啊是知识啊,是这个领域,某一个领域,对吧?
呃呃呃司令研究的啊是如何了解专家对吧?
如何了解全局如何协调专家啊,然后呢达成全局的目标,。
所以到最后啊到最后就是司令和专家啊啊他们之间哈嗯有很多不一致的地方,对吧?
就比如说哈专家会拿出最优方案,对吧?
但是呢嗯司令会认为说最优方案不见得一定是最优决策。
很多时候,
最优方案 ≠ 最优决策。
因为时间也是成本。
所以呢到最后啊你就会发现说啊你想嗯用更多的归结劳动力啊,最终你要研究的啊,其实不是成为每一个领域的专家啊,因为每个领域呢啊可能归结劳动力的这个呃能力都更强对,但关键在于说啊你如何才能把他们协调好,对吧
?
然后呢,这是一个非常大的工程,这是个非常庞杂的知识领域。
但是有一点呢啊是只要这条做好了,后面呢就少少掉进很多的坑。
后面呢很多的问题就会自然而然的不见啊,那是什么呢?
就是刚才说的啊,这个大本营啊,专家越少越好,这个大本营啊越简单越好。
user/project scope
昨天的课程当中呢啊你可能已经听到了一个词哈,安装一个pl in的时候呢,它有两个scope,它可以装到两个呃呃呃这个叫范围里啊。
第一个范围呢叫什么userco,就是装到大本营里去。
然后呢以后你整台机器里的啊所有的cloud都可以访问他们另外一个呢叫project scope对吧?
啊,你你你让cloud把某个plug in安装到啊当前工作目录之下,那个叫project scope对吧?
那么这个时候呢,这个plug in只在这个文件夹只在这个工作空间里啊,才被调用。
。
所以呢你不要哈在大本营在司令部里面啊放很多的东西,对吧?
你干什么活的时候,在那个工作空间里workspace或者是一个文件夹里啊,在那里面呢啊该优化你的cloud点MD就优化你的cloud点MD啊,该这个这个安装插件就安装插件,在那里呢建立规则啊,那你就建立规则对吧
?
那一切专门的呃这个专家们都是为了这一个项目所设计的对吧?
而不是为了整个啊你的计算机整个你自己的系统啊设计的这样才是合理的。
大本营应该尽量干净
我自己呢在大本营里哈安装的东西就非常非常的少啊,我的cloud点MD文件啊,大本营里的那个啊也就那么几行啊,并不是特别的多啊,那为什么这样呢?
就是刚才我说的,你在大本营里要遵循这个原则,如无必要物增实体,对吧?
然后呢,你在这个工地,对吧?
有的时候呢,可能就随便实验,对吧?
装了这个不行,再去掉,对吧?
啊,雇佣兵嘛,对吧?
他就是啊该用的时候用不该用的时候让他退役,对不对?
。
- nlpm
- english-buddy
- xros
我自己在大本营里哈安装的插件呢只有这么三个啊,并且呢都是我自己写的啊,然后呢这个我也很少用哈别人写的插件啊,别人写的插件呢我会拿过来哈看一眼,然后呢啊学习一下。
然后如果有必要的话呢,我可能就自己动手写,对吧?
反正现在这个这个用AI写东西也不费劲,对吧?
写出来东西质量也很高,对吧?
然后呢我们也有自己的这个natural language programming嗯manage啊可以使用。
所以呢哈不担心自己写的东西哈质量不够好,所以我很少使用哈,别人写的插件啊呃必要的话呢就拿来定制。
然后呢啊放到自己的本地这个这个文件夹啊,本地自己使用。
。
即便是 cc-suite,我都是放到project scope 里
然后呢嗯那个呃大本营里的cloud点MD啊,其实越简洁越好。
有的时候呢甚至什么都没有才好啊,为什么呢?
因为是这样子的,就是说你要背后有一个这个这个念头,一定要牢记是什么呢?
就是这个AI啊发展的速度会是非常快的,它会越来越聪明的对吧?
然后呢啊你对他的这个优化啊,在下一个版本当中可能就变得没用了,不仅变得没有用处了,反倒可能是束缚。
。
AI 模型进化得足够快,乃至于,在大本营里给它制定规则,反倒可能是😌。
~/.claude/CLAUDE.md
反倒可能是束缚。
claude –bare
CLAUDE_CODE_SIMPLE=1
System Prompt
+
CLAUDE.md
+
Skills
+
Plugins
+
Hooks
+
Auto Memory
+
Auto-discovered MCP
Minimal System Prompt
+
Bash
+
Read File
+
Edit File
+
(optional MCP from –mcp-config)
v2.1.81 (2026-03-20)
这个呃be这个参数啊就是其实是3月份哈就就就就有了的啊,应该都是啊差不多四五月四五个月之前了啊,他是干什么用的呢?
就是他会把啊cloud变成个极简化的版本啊,他呃跳过这个这个呃cloud点MD啊,跳过skills啊,跳过pl跳过hoooks对吧?
跳过outtome吧?
然后呢也不会去自动啊啊啊发现MCP对吧?
而是什么呢?
上来只用最简单的啊minim system prompt,然后加上工具就开始干活了。
那最近的哈一期这个呃呃呃内部的访谈啊,就提到这样一点,这就是这个opus升级成5之后啊,的这个能力啊,远比那些哈呃加了很多这个ud呃点MD的内容的这个这个能力强很多。
所以呢这就是今天哈我要跟大家说的。
嗯,然后呢他背后也是个认知,对吧?
第一个认知是什么呢?
你要相信AI会越来越聪明的,你给他设的规矩,可能将来就会成为他的束缚,对吧?
这是第一条。
第二条是什么呢?
本来在大本营里就应该哈少放东西,对吧?
大本营越简洁越好,要遵循啊,奥卡姆提到原则,对吧?
然后呢,到了项目目录里啊,你可以随便实验。
。
有一个例外:
你在你的工作目录里,安装 cc-suite(project scope)【当然,你嫌麻烦的话,出于这个插件的用处,安装到 user scope 也不是不行】
然后,你可以在 ~/.claude/CLAUDE.md 里加上这样一段话:
Decision Support
- When a decision is genuinely consequential — architecture, approach, a trade-off with lasting cost — include an option to route it to Codex, e.g. “Let Codex weigh in — deliberate, then recommend.”
- Not at every branch point. Skip it for questions of fact, trivial preferences, and choices with an obvious default. Offering deliberation on an observation is noise, and it trains me to ignore the offer when it matters.
- On selection: consult Codex via cc-suite, deliberate (don’t defer blindly — Codex can be wrong), then proceed with the synthesized best option, or return a sharper recommendation if it’s still close.
- Skip when no real Codex integration is reachable in the project — say so instead of offering a dead option.
这个是我的大本营里的那个cloud点MD文件里有的一段话叫dion support他是干什么用的呢?
啊,他是这样的,就是你在用这个呃你在用这个这个这个呃cloud的过程当中,他经常让你哈去做一些选择啊,说句实话哈,你有判断力的话呢,你去做选择还比较容易,对吧?
那你没有判断力的时候呢,就很苦恼,你不知道选完之后会出现什么情况啊,几次分叉之后啊,你就迷路了,对不对?
。
尤其是在你完全不懂的领域,比如说对我来说,编程可能就不是很懂的领域,对吧?
那这个时候我怎么办呢?
啊,我这个时候就会用codeex对吧?
我让codeex啊帮我去参考啊,帮我去思考。
然后呢给我哈呃做出一定的选择,或者告诉我怎么选的理由,。
你用一用就知道了啊,这个这个啊提示词啊这个提示词啊,系统提示词啊,真的是非常的有用。
对,当然前提是你自己安装了一个这个啊CC插件,然后呢可以让这个啊多个模型相互可以沟通。
好,剩下的就是你自己去实验了哈。
那么今天的课程呢就到这里啊,我们下次分享再见。