今天刷 GitHub，看到了一个让我愣住的仓库。44.6k star，当天 Trending 榜单第一。

这个仓库叫 claude-code-best-practice，里面整理的是 Boris Cherny 和社区贡献者的 69 条最佳实践。

说实话，我接触 Claude Code 也有一段时间了，一直觉得自己用得还挺溜的。结果看完这个仓库，我发现我可能连入门都没到。今天就跟大家聊聊这个仓库里最值得记住的几条，以及我的一些思考。

先说说这个仓库的背景。

Claude Code 是 Anthropic 官方出的命令行工具，让你可以直接在终端里用 Claude 写代码。

Boris Cherny 是 Claude Code 项目负责人，算是最懂 Claude Code 的人了。他在 GitHub 上非常活跃，经常发推分享自己的使用心得。这次被人整理成仓库的 69 条最佳实践，就是从他推文和各种社区分享里扒出来的。

💡 核心感受：信息密度非常高。大部分内容都是在讲怎么真正用好 Claude Code，而不是停留在"粘贴 bug 说 fix"这种表面层。

说几个让我印象最深的。

1️⃣ Agent 模式：不是单个助理，是一整个特工队

我之前一直以为 Agent 就是让 AI 自己跑任务，但实际上远不止如此。

文档里提到的 Subagents 模式，是让你在隔离的上下文里运行独立的 AI agent，每个 agent 有自己的工具、权限、模型、记忆和持久身份。

📝 翻译成人话：你可以同时让好几个"分身"帮你干活，而且互不干扰。

我一直以为我需要的是一个能干的助理，结果人家给我的是一整个特工队。

2️⃣ 上下文超过 50% 立刻 /compact

这是另一个让我"卧槽"的点。

我们平时用 Claude Code 的时候，经常会遇到一个情况：聊着聊着，Claude 开始"变蠢"了。给它的提示它好像看不懂了，让它修的 bug 越修越离谱。

很多人会觉得是模型本身的问题，或者是自己表达不够清楚。但 Boris 指出，真相是上下文超载了。

⚠️ 关键问题：当对话长度超过上下文窗口的 50%，Claude 的表现就会开始下降。它开始"忘记"早期给的信息，或者被中间大量的历史对话干扰。

解决方法：手动触发 /compact，让 Claude 压缩一下之前的上下文，腾出空间。

💎 Boris 的习惯：他每次对话都会下意识看一眼 context 使用量，一旦超过 50%，立刻 compact。

3️⃣ CLAUDE.md 不要超过 200 行

这一条可能很多人会反驳。"我经验这么丰富，200 行哪够写？"

Boris 的观点是，越多越好这种东西，在 CLAUDE.md 这个场景下，是完全错误的。

Claude 对长文档的利用率是递减的。当 CLAUDE.md 超过 200 行，Claude 反而会开始忽略里面的内容。原因很简单：太长了它记不住，也分不清哪些是重点。

好的 CLAUDE.md 应该是精炼的、核心的，剩下的细节用多个文件分散存储：

• 在 .claude/rules/ 目录下放领域特定的规则
• 用 <important if="..."> 标签包裹关键信息
• 让 Claude 在文件变长的时候依然能识别重点

4️⃣ Commands vs Agents vs Skills：用对场景

关于 Agents、Commands、Skills 的使用，很多人刚接触的时候会把这三个概念混着用。

但 Boris 的建议非常明确：

🎯 核心逻辑：让专业的人做专业的事。 Commands 处理每天重复做的事情Agents 处理需要专门思考的事情Skills 处理需要积累和复用的知识

5️⃣ 不要 railroad Claude

Railroad 这个词，直译是"铁路"，在这里的意思是像火车一样把 Claude 固定在轨道上，不让它有任何偏离。

很多人写 Skills 的时候，喜欢把步骤写得特别详细：

"第一步做这个，第二步做那个，第三步检查这个，第四步如果失败就回退"

但 Boris 的观点完全相反。

✅ 好的 Skills 应该是：给目标、给约束，而不是给步骤。 告诉 Claude 你想要什么结果，以及什么情况下绝对不能做，而不是手把手教它怎么走。

因为 Claude 的推理能力比你想象的强。你写的步骤可能只是在你当前的认知下最优的，但 Claude 可能有更好的路径。

🔥 给它目标，让它自己找路，比把路画死效果要好得多。

6️⃣ 原型大于 PRD

Boris 在一次访谈里说，他更倾向于先 build 20-30 个版本，而不是写一堆 spec 文档。

💬 核心观点："build 的成本很低，试错才是最高效的方式。"

这话听着有点反直觉。我们习惯了先想清楚再动手，但 Boris 认为，在 AI 编程这个领域，很多东西想不清楚的，只有做了才知道对不对。

而且当你有一个 working prototype 的时候，跟别人沟通也更容易。比起干巴巴的文档，一个能跑的东西更能激发讨论和反馈。

🤔 我的思考：不能说谁对谁错，不同场景用不同策略。有些系统级的决策，确实需要先想清楚再动手。

7️⃣ 用 test time compute 来分离上下文

简单来说，就是让一个 agent 实现功能，让另一个 agent 来测试和找 bug。

很多人可能觉得这是资源浪费。同一个模型，为什么要跑两遍？

但 Boris 的解释让我觉得很有道理：

• 当你在实现一个功能的时候，你的思维模式是"怎么把它做出来"。这个视角会让你自动忽略很多潜在的问题。
• 当你切换到测试视角的时候，你的问题变成了"这个东西会不会有问题"。

🧠 认知视角：两个视角在认知上是冲突的。让同一个 agent 同时兼顾两种视角，它的表现往往会两边都不讨好。分开跑，反而能得到更好的结果。

这些东西，总结起来是什么？

Boris 在他的各种分享里，其实一直在强调一个概念，叫做 agentic engineering（代理工程/AI工程）。

🎯 核心定义：Agentic engineering 的核心不是说让 AI 替你做事，而是说用 AI 的方式重新思考整个开发流程。

开发流程的演变

在这个新范式下，很多旧观念需要被打破：

• ✅ 不需要在意代码是谁写的，只需要在意的代码是不是对的
• ✅ /compact 比写长文档更重要，因为上下文质量决定了 AI 的表现上限
• ✅ 与其花时间写详细的 spec，不如快速 build 一个原型，在迭代中找方向

我有时候觉得，AI 编程这个领域，有点像 1880 年代的电力普及。

那时候很多工厂主买了发电机，以为这就完成工业革命了。结果发现，生产效率根本没提升。因为他们只是用电动机替代了蒸汽机，但整个工厂的布局、流程、管理方式都没有变。

AI 编程也是这样。很多人开始用 Claude Code 了，但工作流还是老的：先自己想清楚，再让 AI 执行。

🔄 这不是 AI 原生的开发方式。 真正的 AI 原生开发，是把你习惯的人类工作流，转化成 AI 可以参与的人机协作流程。这需要大量的练习和试错。

说实话，看完这个仓库，我最大的感受是：

我以为自己会用 Claude Code，但其实只是会用最表面的那层。

44.6k star 说明什么？

说明太多人跟我一样，在用错误的方式使用这个工具，然后发现效果不好，就觉得 AI 编程是噱头。但真相是，我们还没有真正理解这个新范式。

从 vibe coding 到 agentic engineering，差的不是工具本身，是一套全新的思维方式和工作流。而这套东西，目前还处于非常早期的探索阶段。

Boris 的这些经验，可能很快就会过时。但至少现在，它们是我们能看到的、最接近真相的东西。

值得认真研究一下。