公众号名称：AI学不会

作者名称：我是杰克

发布时间：2026-05-09 18:01

最近使用Claude的时候，在网上看到一个技巧，说把”第一性原理”写进CLAUDE.md里，我试了一下，效果还不错。

就四条规则：

1. 不要假设用户清楚自己想要什么，不清晰时停下来讨论

2. 目标清晰但路径不是最优时，直接建议更好的办法

3. 遇到问题追根因，不打补丁，每个决策要能回答”为什么”

4. 输出说重点，砍掉一切不改变决策的信息

我试了。确实好用。

AI不再闷头干活了。它会主动停下来问我：“你这个需求是不是想解决X问题？“而不是一股脑给你搞出一堆你不需要的东西。

但我用了一段时间后发现，光有这四条，还不够。

这四条为什么有效？

先说说这个方法为什么有效。

说白了，这四条规则就干了一件事：改变了AI和你之间的协作关系。

没有这些规则的时候，AI是”你说了我干”的模式。你说写个函数，它就写。你说加个功能，它就加。它不会质疑你，不会反问，也不会主动优化你的想法。

有了这四条，AI变成了一个会思考的搭档。它会在你需求模糊的时候说”等等，你是不是想解决X问题？“，会在你方案绕弯路的时候说”其实有更简单的做法”。

这个转变很大。

我自己的感受是，加了这几条之后，返工少了很多。之前经常是AI做完了，我一看不对，又得重来。现在AI会在第一步就帮你把方向理对。

但它没解决什么？

问题来了。这几条规则管的是”思考方式”，但管不了”工作流程”。

打个比方。第一性原理是教一个人怎么思考问题，但你还得告诉他：你在什么场景下工作、你的项目结构是什么、你的团队规范有哪些、哪些东西绝对不能碰。

这些是”工作流”层面的事。第一性原理不管这些。

举个我自己的例子。

我用Claude Code做公众号写作。如果没有在CLAUDE.md里写清楚写作流程，光有”追根因不打补丁”这条原则，AI会怎么做？

它会说：“好的，我来帮你写一篇文章。“然后就开始写了。

但写什么角度？给谁看？用什么风格？要不要先调研？要不要先看看我之前写过的文章学一下风格？用不用我自己的真实素材？

这些问题，第一性原则回答不了。你得自己想清楚，然后写进CLAUDE.md里。

我的做法：不是塞原则，而是设计系统

我自己有个写作的CLAUDE.md配置大概300行。我花了比较长的时间迭代了好几版才稳定下来。

核心思路就一句话：把CLAUDE.md当成你给AI写的”使用说明书”来设计。

不是塞一堆原则进去就完事，而是要想清楚：你和AI到底怎么协作？

下面说几个我觉得比较重要的设计。

1. 先告诉AI”你在哪”

CLAUDE.md的第一件事，不是写原则，是告诉AI：你现在在什么项目里、这个项目是干什么的、有哪些工作区。

我自己的配置用了”两层判断机制”：

• 第一层：先判断任务属于哪个工作区（公众号写作？视频创作？其他？）

• 第二层：判断具体任务类型（新写作？修改文章？快速咨询？）

然后不同的任务走不同的流程。

为什么这么做？因为AI拿到一个任务时，如果没有这个判断框架，它就只能猜。猜对了运气好，猜错了你还得纠。

有了这个框架，AI会在第一步就问：“这个任务属于公众号写作还是视频创作？“而不是直接开始做。

这一步的价值是：减少方向性错误。

2. 把你的”规矩”写清楚

每个人都有自己的做事规矩。AI不知道你的规矩，除非你写出来。

我写了几条核心规矩：

• 绝不编造数据——AI写文章的时候，不允许编造任何数据、产品功能、用户反馈。不确定就说”我没找到这个信息”。

• 调研先行——涉及新概念、新技术时，必须先做网络调研，不能凭训练数据直接写。

• 用个人素材——我有一个素材库，里面有我的即刻动态、历史文章。写文章时必须先从素材库里找真实素材，用我的真实经历和观点。

这几条规则有个共同点：都是AI默认不会做的，但你又特别在意的事。

所以配置CLAUDE.md的一个思路是——想清楚哪些事AI不做你会很恼火，把它写进去。

3. 把工作流写成流程，不是写成原则

这是我觉得最关键的一点。

很多人配置CLAUDE.md的方式是写原则：“写高质量的代码”、“保持代码整洁”、“遵循最佳实践”。

这些原则没错，但没用。因为AI不知道在你的项目里，“高质量”具体意味着什么。

有效的做法是把工作流写成具体步骤。

比如我的写作流程是9步：理解需求→信息搜索→选题讨论→创建协作文档→学习风格→使用个人素材→等待测试数据→创作初稿→三遍审校。

AI拿到任务后，不是直接开始写，而是先走这个流程。先讨论选题，我确认了才开始写。写完还要过三遍审校。

这样做的好处是：每一步的输出质量都有保障。不是一口气写完然后发现方向错了。

4. 控制”个人偏好”和”团队规范”的边界

CLAUDE.md有几个层级的位置：

• ～/.claude/CLAUDE.md —— 全局的，所有项目通用

• 项目根目录的 CLAUDE.md —— 团队共享的

• CLAUDE.local.md —— 个人的，不提交到Git

我一开始把所有东西都塞在一个文件里，后来发现不对——有些配置是我的个人偏好（比如用中文回复），有些是团队规范（比如代码风格）。

后来我分开了：通用偏好放全局配置，项目规范放项目配置，个人习惯放local文件。

这个分层的意思是：想清楚哪些规则是你自己的，哪些是团队的，别混在一起。

几个被验证有效的技巧

除了上面说的思路，还有几个具体技巧我觉得值得分享。

技巧一：写指令，不写描述。

❌ “这个项目是一个用Flutter开发的自我提醒App”

✅ “技术栈：Flutter + Dart，使用Provider做状态管理，本地数据用SharedPreferences存储”

前者是描述，AI知道了但不一定会遵守。后者是指令，AI可以精确执行。

技巧二：只写能改变AI行为的规则。

如果删掉这条规则，AI的输出不会变差，那就别写。

“写干净的代码”——AI本来就在做，删掉没影响。不用写。

“所有金额以整数（分）存储，不以元存储”——这是你的业务规则，删掉AI就会犯错。必须写。

技巧三：标记关键规则。

对于特别重要的规则，用 IMPORTANT、NEVER、MUST 这样的词标记。但别滥用——如果全标IMPORTANT，那就什么都不重要了。

技巧四：记”经验教训”。

把AI犯过的错记下来。比如：

• “本项目使用ESM模块，禁止使用require()”

• “用户表有软删除字段，所有查询必须过滤deleted_at”

这种”踩坑记录”比任何通用原则都有效。

技巧五：控制在200行以内。

有人做过研究，前沿大模型能稳定遵循的指令大概150-200条。超过这个数，不是AI忽略了新加的规则，而是开始均匀地忽略所有规则。

规则多了，不如把细节拆到单独文件里，用 @ 引用。

写在最后

回到开头那个”第一性原理写进CLAUDE.md”的技巧——它确实好，好在它改变的是AI的思考方式。

但配置CLAUDE.md这事，不是在写prompt，是在想清楚”我和AI怎么协作”。

你想要AI帮你做什么？你的工作流是什么样的？你的底线是什么？哪些事AI绝对不能做？哪些事必须先问你？

这些问题想清楚了，写进CLAUDE.md，AI才能变成一个懂你的搭档。

而不是一个很聪明、但总猜不对你心思的工具。

如果你也在用Claude Code，还是建议花点时间好好写写你的CLAUDE.md。四行”第一性原理”是好的开始，但别停在那里。

你的工作流值得被认真对待。

---

内容效果不满意？点此反馈