上下文
三个仓库
最近翻了三个 Claude Code 增强项目。数字很漂亮：一个有 156 个技能模块，72 条命令，28 个预配置服务；一个有 14 个方法论技能，覆盖从头脑风暴到代码审查的完整生命周期；还有一个做了 22 种生命周期事件的钩子，甚至给每种事件配了音效。
它们都在做同一件事：教 AI 怎么工作。
四阶段调试法告诉它先找根因再动手。TDD 铁律要求没有失败测试就不准写代码。156 个编码规范在它写每种语言时注入最佳实践。听起来都对。直到你问一个问题：
如果模型已经知道这些，这些规则在做什么？
达里奥的提醒
Ray Dalio 说过一个观点：当你变得足够强，许多看起来在帮你的东西，实际上在限制你。
这句话的适用范围比他本人讨论的更广。规则、流程、最佳实践——它们的价值建立在一个隐含假设上：执行者不够强，需要被引导。对新手来说这是对的。对一个已经能从第一性原理推导出这些规则的系统来说，它们就变成了另一种东西。
不是护栏。是笼子。
一个被 156 条规则包围的模型，会倾向于机械执行步骤，而不是真正理解问题。就像一个已经见过道的修行者，如果还要每天对着戒律清单逐条打勾，那不是修行，是表演。
上下文窗口里有什么
回到技术层面。大语言模型的输出是上下文的函数。不管 prompt 写了多少步骤、多少约束、多少最佳实践，模型生成每个 token 时看到的只是当前窗口里的内容。
所以那些技能模块的本质不是”教模型思考”——模型不需要被教。它们的本质是上下文管理：在特定时刻，往窗口里注入特定的信息。
四阶段调试法 = 在调试时注入”先找根因”这个上下文。 TDD 铁律 = 在写代码时注入”先写测试”这个约束。 156 个编码规范 = 在写特定语言时注入该语言的惯用模式。
理解了这一层，问题就变了：不是”需要多少技能”，而是”窗口里放什么，不放什么”。
减法
我自己维护了一套 Claude Code 的工作流系统。21 个命令，14 个钩子。听起来也不少。但当我用上面的视角重新审视，真正不可替代的只剩两类：
第一类：模型做不到的事。
跨会话记忆。我做的项目太多，认知带宽不够，需要系统替我记住上下文在哪、做到哪了、踩过什么坑。这不是模型能力问题，是架构限制——会话结束，一切归零。日记、周报、焦点追踪，这些都是在弥补一个结构性缺陷。
第二类：模型会失控的点。
不是它不知道该怎么做，而是它太急于做。看到答案就想动手改代码，被要求修一个 bug 顺手”优化”了三个文件，说”完成了”但其实没跑过测试。这些不是能力不足，是行为偏差。就像一个聪明但冲动的人，需要的不是更多知识，是几条纪律。
“确认前禁止改代码。” “禁止顺手优化。” “标记完成前自问：资深工程师会认可这份代码吗？”
这些不是在教它怎么想。是在它会犯错的地方加一道门。
其余的——调试方法论、编码规范、审查流程——随着模型越来越强，它们的边际价值趋近于零。留着不伤害什么，但也不要以为它们在起作用。
戒律
佛家的戒律有一个被忽略的维度：它不是永恒的规则，是阶段性的工具。
初学者需要戒律，因为心猿意马，不知道边界在哪。但修行到一定程度，戒律内化为自然——不是在遵守规则，是根本不会想去违反。到那个阶段，戒律清单就是多余的。不是因为它错了，是因为你已经超过了它。
模型的进化路径类似。今天需要的护栏，明天可能就是障碍。而真正有价值的基础设施——记忆、持久化、跨会话的连续性——这些不随能力增长而贬值，因为它们解决的不是”怎么做”的问题，是”记得什么”的问题。
所以最好的系统不是规则最多的系统。是规则最少、但每条都不可替代的系统。
刚好够用
我的产品设计有三条铁律：一个入口、复杂隐形、越用越懂。
回头看，这套 AI 协作系统应该遵循同样的标准。用户——也就是我——打开一个会话，不需要知道背后有多少命令、多少钩子、多少规则。系统替我记住上下文，在我会犯错的地方拦一下，剩下的让模型自己判断。
不是 156 个技能。是几条纪律，加一个好记性。
表面极简，背后极深。
2026.04.04