给 AI 立规矩：一份全局配置，让 AI 天然更聪明

先讲一个「叫主人」的段子

有位博主分享过一个「怪癖」：他让自己的 AI 每次回答前，都得先喊他一声「主人」。他自己说，真没这癖好，多两个 token，纯浪费。

但他坚决不改。原因很有意思：一旦上下文过大、AI 开始抽风降智，它第一件掉链子的事，就是忘了叫「主人」。就这么一个看似无用的称谓，成了他的「AI 降智警报器」。只要 AI 一不叫，他就知道该止损了。

多花两个 token，买个全天候体检仪，值。

这个故事想说的是：决定一个 AI 聪不聪明的，很多时候不是模型本身，而是你给它立了什么规矩。

一个你每天都可能遇见的翻车现场

上周我让 AI 帮我整理一份错误日志。它一顿操作，把无关报错、重复代码、没用的注释全塞进回复，我翻了整整三页才找到关键信息。我气得只差摔键盘。

后来我给它加了一句规矩：「回答之前先给结论，再给理由，删掉所有铺垫和客套。」同样的日志，它三十秒就拎出三个最该修的错，还附了证据和修法。

差别就在一句话。你给 AI 立的规矩，就是它的「出厂性格」。但大部分人的 AI 压根没有规矩，全靠模型自由发挥，于是讨好、瞎猜、废话连篇、乱改一通，全来了。

规矩住在哪里

真正的高手，都在维护同一个东西：一份全局配置文件。Claude Code 里叫 CLAUDE.md，Codex 里叫 AGENTS.md。

名字唬人，其实就是个纯文本文件，用大白话写下「你希望 AI 一直遵守的规矩」。放高一层，全项目生效；放项目里，这一个项目生效。

有人把配置拆成过这些块，我挑了最有代表性的几块给你看：

配置块	一句话任务	例子
沟通原则	规定 AI 怎么跟你说话	直接给结论，删掉客套
工程纪律	规定 AI 怎么干活	动手前先复述理解，确认一致再干
红线操作	规定 AI 绝对不能碰什么	不删除用户文件，不擅改密钥
交付自检	规定 AI 交活前查什么	删光占位符和待办
已犯错误	规定 AI 哪些坑不许重踩	上次在 X 上栽了，这次禁止

这些块里的每一条，几乎都是拿血泪换来的。清一色是踩过坑之后沉淀的规矩，不是拍脑袋想出来的。

好规矩的三条不成文规则

看了这么多高手配置，我发现真正好用的，都守着三条规则。

规矩越精简越好。 配置不是越长越聪明。文件过于庞大，每轮都得多读一遍，token 烧得快，上下文一长 AI 反而降智。规矩是约束，不是百科全书。

写「反例」比写「正例」顶用。 与其写「你要认真负责」，不如写「不要臆测需求」「没验证别声称完成」。AI 对「别做什么」的理解，常常比对「要做什么」更准。

规矩要用代价换。 就像那个「叫主人」的逗号，有些看似浪费，实则是信号。我加过一条「交付前必须自查删光占位符」，多花几个 token，换来的是不用逐字检查输出。

一句话：好规矩不在于多，在于「极简、反例、能当信号」。

白纸起步，别抄大神的

别一上来就抄大神那几十行的配置，你大概率用不上，还容易绕晕。

我的建议：从你最痛的那个点写起。今天最烦 AI 哪个毛病？废话多，就写「直接给结论，删铺垫」；爱编造，就写「不确定必须标注，禁止编来源」；爱抢跑，就写「先复述再确认」。

你的痛点	写进配置的一句话
废话连篇	直接给结论，删掉铺垫客套
爱编造来源	不确定的必须标注，禁止编造
爱抢跑乱改	动手前先复述理解，确认后再干
找不准重点	先给最关键的，再给细节

每遇到一个新坑，就往里加一条。用上两个月，你的配置里条条都是血泪，比任何网上的通用模板都适合你。

那时候你会惊讶地发现：同一个模型，在你的规矩下，就像换了个人。

---

投个票：你最想让 AI 改掉的那个毛病是什么？评论区聊聊，我看看能不能帮你想一句规矩。

如果这篇文章对你有用，点个「在看」，让更多人早点给 AI 立上规矩。