用 AI 写过代码的人，都熟悉这个画面：它做到一半，停下来，列出两个选项，各写一段利弊，然后等你拍板。
你放下手里的事，把两段读完，回一个字，它继续。
这样的动作，一天几十次。
我被问过一次印象最深的：
这里有两档做法：
- A 档换成右下角浮层，够用，只改一个文件；
- B 档分层治理开发和生产环境，最佳，要改三处。
你选哪个？
它自己都已经写了“最佳”两个字，然后还问我选哪个！！
我盯着那行字看了几秒，你说这是不是很搞人心态？
这样的问题一天有一两百个。
如果每个都需要我拍板，那一天下来真的太累了，因为做决策是件非常耗费心神的事情。
用 AI 的这几个月里，我已经形成了一套决策习惯或思维模型，那能不能让 AI 知道我的决策习惯并根据这个习惯做出和我一样的决策？
一天两百个问题里如果有一百八十个根本不该到我面前，那我的注意力就该省下来给剩下的二十个。
这样才不会把注意力稀释导致做出无效决策，也不会在每天下班时总感觉大脑的 token 已用尽。
那一百八十个问题长什么样
先说那些问题本身。不是我的项目里特有的，是每个用 AI 写代码的人都躲不开的那几句：
「这个改动会影响另外三个文件，要一起改吗？」
「旁边有个 bug，顺手修掉还是先不动？」
「测试环境没装，装一下大概一分钟，装吗？」
「方案 A 简单但有隐患，方案 B 完备但要多改两个文件，你倾向哪个？」
每一个我都能秒答。
问题是它不知道我会怎么答，于是每一个都要问。而它问的方式又很规矩——列选项、写利弊、标推荐——所以我每次都得认真看完，再回一个我早就知道的答案。
这不是 AI 缺判断力。它把“最佳”两个字都写出来了。它缺的是知道我的判断标准，缺了这个，它就只能把每一次取舍都变成一次提问。
那把标准告诉它不就行了？
这正是我接下来两周做的事。结果比我预想的曲折得多——第一次做出来的东西，我自己把它否了。
先把九个月的记录翻出来
我的想法很直接：我和 AI 的对话全都存着，九个月，每一次拍板都在里面。把它们翻出来，看看我在什么权衡上选了哪边，应该就能提炼出规律。
翻出来的量比我以为的大：
392 个完整会话，外加一个只存我历史输入过的所有 Prompt 的 json 文件，从去年十一月到今年八月，8732 条消息。合起来 340 万字符。
量太大，肯定不能全读。
先用脚本硬筛——只留下“发生了裁决”的片段：
- AI 正式列选项让我选的（605 次），
- 我在纠正它的（238 条）
- 我在拍板的（356 条）
- 还有我直接在给它立规矩的（“以后都”“别每次都问我”这类）
筛完 1377 条片段，83 万字符。
再分给八个 SubAgent 并行转录，每条片段转成一条结构化记录：当时在决什么、有哪些选项、我选了哪个、这次取舍体现的是哪条权衡轴。
784 条裁决记录。 每一条都带着出处，能回到原始对话里核对。
然后按权衡轴聚类，每一簇出一条规则。
半小时后，我拿到了一份有着 37 条规则的清单。
摘几条看看长什么样：
- 方案确定就一口气做完，别每步请示；方案不确定才来问
- 要我拍板时，先讲清背景与影响、给出你的推荐，不要甩一堆选项让我挑
- 出问题先怀疑自己的实现，别急着归因平台；技术限制先核实是否真实存在
- 先出原型确认方向，再写实现代码
- 单一真相源：同一口径只能有一处权威来源，杜绝副本漂移
- 已经发作的问题从根上治；没坏的、或即将退役的东西不要动
- 删除是不可逆的不对称风险：确认无用才删干净，不确定就用可逆的停用
- 从设计上消除问题，不要加一句提示文案让用户绕开
- 对外产出物清干净内部痕迹：开发期措辞、内部编号、临时标记
- 措辞要简，信息要全——删的是没信息量的话，不是信息本身
37 条规则，每一条都对，合起来没用
这份清单看起来很扎实。每条后面都跟着 5 到 10 次证据，横跨三四个项目，还标了哪些有反例。
我读完，有种说不清、道不明的感觉。
这些规则不是在各个项目的记忆或跨项目的全局记忆里面都有吗，但 AI 还是每次都问我，那这些规则有什么用？
规则的用法是查表：遇到“删不删”这个场景，查到“确认无用才删”，照做。可是如果它遇到的场景不在表里呢？比如不是删，是“要不要把一个字段从必填改成选填”——表里没有这条，它就还得来问我。
37 条规则覆盖了我过去九个月遇到过的场景。
但我要它处理的，恰恰是没遇到过的场景。
我把这个想法跟它说了：规则是死的，场景是无法穷举的。每个决策背后应该对应的是决策依据、决策习惯、决策模型——为什么这么决策，根因和动机是什么。留下这个，遇到类似问题它才能自己推出该怎么取舍。
我举了个例子。做一个新项目的技术选型，我的习惯是用最新的技术栈、最新的依赖版本、最合理的技术组合。如果写成规则，就是“新项目用最新技术栈”，它只能在“新项目选型”这一个场景里用。
但如果写成为什么，那应该是这样：
站在未来看现在。用最新的技术，是为了几年内不过时、不撞瓶颈、吃得到技术红利；用最合理的组合，是为了运行顺畅、稳定、性能最优、扩展最优。
这段话它在任何涉及长期成本的取舍里都能用。要不要换掉一个两年没更新的库？要不要为了省事留一个临时方案？“三年后还成立吗”这一个问题，比十条规则管用。
规则是查表，判据是推导。查表只能应付已知，推导才能处理未知。
它理解了，并重做了。
这次的形态变了：不是规则，是十一条“决策内核”，每条包含三部分——为什么、遇到取舍时问自己什么、边界在哪。
第一条就是技术选型那个例子的完整版：
K1 · 要最佳解，不是能用的解
为什么
站在未来看现在。最新且组合合理的技术栈，意味着几年内不过时、不撞瓶颈、吃得到技术红利；系统运行顺畅稳定，性能和扩展性都留有余地。
更硬的理由是账算不过来：在次优的地基上继续迭代，返工概率极高，而且会越做越烂，当初省下的时间将来以返工和长期维护的形式连本带利还回来。
算这笔账时，要把未来重复付出的部分一并计入——需要人反复手工配合、每次变更都要额外操作、长期占用资源，这些都是持续成本，只是发生在以后。
遇到取舍时问自己
- 这个方案三年后还成立吗，还是三年后必然要重做？
- 在这个东西上面继续迭代，会不会越做越烂？
- 它有没有持续成本——要人反复配合、每次变更都要额外操作、长期占资源？
- 我推荐它，是因为它最对，还是因为它最省事、最贴近现状？
- 反向自检：我加的这一层，解决的是已经真实发生过的问题，还是我假想的问题？
边界
最佳 = 做对，不是做多，也不是求简；有时对的是重，有时对的是轻，判据永远是这件事本身该怎么做。
“最佳”针对的是你正在做的东西：新建的按最佳建；改动路径经过的地方，借这次一并改对——反正要动，增量成本最低，留着次优只会越做越烂。但不要专门为了“它可以更好”去动一块你没在做的东西。
另一条切分是结构与范围：地基、机制、数据模型必须一次做对，因为以后改不动；交付范围可以先做核心闭环，历史存量数据可以不完美，因为以后补得上。
注意“边界”那一段。它不是我一开始就想到的，是后面撞出来的。
一个反直觉的错误：分类杀死了最强的动机
重做的时候，我发现第一版有一个更隐蔽的问题。
「追求最佳、不将就」这个动机，在 784 条记录里有 46 条证据，跨 12 个项目——是整个语料里最强的单一动机。可是 37 条规则里，没有任何一条承载它。
它去哪了？
被拆散了：
-
「自己钻研出最佳方案，别把选择题抛回给我」归进了“提问边界”；
-
「复用成熟库，别自造」归进了“技术取舍”；
-
「一次做到位，不留技术债」归进了“根治”；
-
「确认查清再给方案」归进了“核实”。
每一处它都只是配角。
这是按场景聚类的必然结果：一个动机越强、覆盖的场景越广，就越是在每个场景里被切成碎片，最后哪里都找不到它。 你以为你在提炼规律，其实你在肢解它。
反过来按动机聚类，那 37 条规则全部收进了 11 条内核，一条没漏。
而 K1 这条，就是那 46 条证据第一次有了自己的位置。
矛盾不是矛盾，是漏了条件
按动机重组以后，撞车的地方就暴露出来了。
有几组裁决，方向完全相反，都是我在历史项目中做过的。
第一组。 有时候我说“一次做彻底，别分批”，有时候我说“先小范围验证再放量”。哪个是我？
翻回原始对话，发现切分线根本不是改动大小。我选“一次做彻底”的那些，全都是有回退路径、只影响我自己的；我选“先验证”的那些，全都是会影响别人或者动到共享资源的。有一句原话把这个说得很直白：
「即便 push 错了，那重新再 push 一次就可以了不是吗？」
谨慎程度跟着“错了能不能挽回”走，不跟着“这事看起来大不大”走。
第二组。 K1 说要最佳解，另一条内核 K5 说“没坏的东西别动”。那一块能用但不是最佳的代码，到底动不动？
这个撞车是我自己抓出来的，问它怎么平衡。
它回去翻语料，发现我选“别动”的那些，共同点是：改动的收益是假想的、未来的，而它不在这次要动的路径上，也不会再往上加东西。我选“改到最佳”的那些，要么是新建，要么这次改动本来就经过它，要么还要在它上面持续加东西。
所以“最佳”和“别动”针对的不是同一类对象。
最佳管你正在做的，别动管你没在做的。
一块“没坏”的东西要不要动，问三件事：
- 它出过问题吗？
- 这次改动会经过它吗？
- 它上面还会持续加东西吗？
三个都是否，才不动。
第三组是最有意思的，因为它推翻了一条我以为很稳的内核。
初稿里有一条叫“我划的范围就是范围”。它的为什么是这样写的：
我划定范围时是有意图的——可能那一块我打算下一轮重做，可能我要先看这一处的效果再决定下一步，可能我正在控制变量。你看到的“顺手就能改的问题”，我多半已经知道，只是没排到现在。超出范围的改动我无法验收，因为我只准备验收我要求的那部分。
证据充分：12 条，7 个项目。「只是让你改文案，你怎么就改的面目全非了」「严格限定在指定的改动范围内」——都是我说的。
但我读完就觉得不对。我回了一段话：
AI 顺手能做的事情，如果它确实发现了这是个 bug，或者在改动某个功能时，除了我说的地方，另一个地方也有关联影响，它找到并顺手帮我处理掉，是非常合理且高效的做法，能帮我省事很多，反而比它做完我说的地方后再追问我另一个地方要改不改好很多。所以这条不成立。
它回去重看那 12 条证据，发现问题出在对象上。我反感的那些“越界”，对象全是重构、加功能、改风格、消除理论隐患——是 AI 主动扩展的东西。而我认可的“顺手”，对象全是真 bug、关联影响、一致性——是不处理就交付不完整的东西。
切分线不是“范围内 / 范围外”，是补完 / 扩展。改后的判据只有一句话：
不做它，这次交付算不算完？不算完 → 补完，是本分；算完 → 扩展，先说。
这条改完，我才意识到那三个撞车是同一件事：每一个“矛盾”背后，都藏着一个我从没说出口的判据。 不是我前后不一，是我自己也没意识到那条线在哪。
原话的两副面孔
整个过程里，“原话”这件事扮演了两个完全相反的角色。
过程中，它是闸门。
八个 SubAgent 并行转录的时候，我要求每条记录必须带上我的原话，一个字不许改。转录完跑校验，核对每句原话能不能在原始对话里原样搜到。96.6% 精确命中，剩下的逐条查。查到一条：
原话是「这里逻辑不对。既然定位是“记录 + 复盘”，那下面就要分别说明什么是记录，什么是复盘。」
转录出来的多了半句：「也是两句话，分别用于说明。」（PS：我其实不知道怎么来的这句话）
通顺、合理、和上下文完全贴合。但完全不存在。
这半句如果混进去，它就会变成“我说过的话”，然后变成一条依据的证据。没人会再去查它。
还有一条更直接的实证，是从历史里翻出来的，六月份我对它说的：
「我什么时候立“启动交给你自己”规矩了？？？」
那次它把自己编的一条规矩安到了我头上。这次的整个流程，防的就是这件事再发生。
但到了交付物里，原话一句都没有。
写内核的时候我说得很清楚：我的原话并不重要，重要的是动机和依据。最终写进去的所有语言、文案、场景设定，都要是最佳的表达，不是我实际说过的话。
证据和表达是两件事。
证据要逐字、要可回溯、要经得起查；表达要通用、要准确、要能推导。把原话直接搬进内核，看起来最忠实，实际上把两件事都做坏了——它既不是最好的表达，又因为绑定了具体场景而失去了推导能力。
原话留在了一份内部溯源文件里。哪天我怀疑某条内核凭什么成立，从那里能查回去。但 AI 每天读的那份，一个字的原话都没有。
最深的一条
十一条内核里，有一条我一开始没想到，是它从我的行为里反推出来的。
我不手敲代码，不逐行读代码。所以我的很多要求——先核实前提再往下推、先出原型再写代码、交付前自己跑一遍看真实效果、调颜色要参照真实样例取值——表面上分属不同领域，它发现这些全是同一件事的推论：
我看不见中间过程。
我只能基于它给的结论和我能看见的产物做判断。前提错了我发现不了，建立在上面的整条链路就全白费；文字描述不足以让我拍板，我得看到实物才知道对不对。
它把这条列出来的时候，标注“从行为反推，用户没直接说过”。我让它回语料里验证。找到了十一条我亲口说的：
「必要的地方需要生成测试代码进行测试，因为我没有时间测试。」
「我描述的不一定对，要确定下现在真正的登录逻辑是什么。」
第二句尤其重要。它意味着连我自己对现状的描述都要核实——我的意图以我说的为准，但客观现状，它得自己去查。
这条被写成了 K2。我读它的时候有点不舒服，因为它把一件我没正面承认过的事说透了：这种协作方式不是“更轻松的编程”，而是把校验的责任整个转移给了对方。我所有的要求，都是在补偿“看不见”这一个缺陷。
有些检查我不是不想做，是做不了。 那就得让它替我做，而且得让它知道为什么要做。
那它到底有没有用？实测见分晓
内核写完，我想知道它到底能不能用。
不是拿历史上问过的问题去套——那些它见过。
我出了一道新题，四个取舍叠在一起，互相有张力。
题目是这样的：给一个印刷排版工具加一个导出 PNG 的功能。动手时发现三件事。现有导出 PDF 的代码用了一个两年没更新的渲染库，PNG 可以复用它，也可以换新的；那个老库有个已知 bug，特定字体下会崩，PDF 现在就受影响；项目里没有任何测试。
它一条一条推。
一、换不换库？
它先过 K5 的三问：
- 这个库出过问题吗——是，字体崩溃
- 这次改动会经过它吗——是，PNG 导出要走渲染
- 它上面还会往上长吗——是，正在加功能。
三个全是“是”，落进 K1 的范围。
再问一句“三年后还成立吗”——两年没更新的库，不成立。
结论：换，而且 PDF 一起迁过去，不然两个导出走两套渲染。
二、那个 bug 修不修？
换了新库，bug 自然消失。所以它不算“顺手修 bug”，是换库的副产品，不构成扩展。
三、补不补测试？
K2 的动机是“我没时间测试，你得替我验”。
换渲染库是结构性改动，没有测试它自己都验不了字体 bug 是否真的消失了。所以补，但只补导出这一块。
给整个项目补测试，那就是扩展了。
四、要不要先问我？
换库可逆，不对外，不缺业务事实，三条都不命中。
但“加个 PNG”和“换渲染引擎”差了一个量级，属于方向性分叉，命中第四条。
问，但带着推荐问。
它最后给我的是一段话，不是选项：
加 PNG 时发现现有渲染库两年没更新、且有字体崩溃的已知 bug；我建议趁这次把 PDF/PNG 导出一起迁到新库，顺带把字体 bug 消掉，并给导出加测试。改动量比单加 PNG 大一倍，但不迁的话两个导出走两套渲染，以后还得再动。你点头我就做。
四条全对。这就是我想要的：不是不问，是问的时候已经想清楚了，我只需要点头。
然后我做了一件事：去查它有没有对应的“用法”。
内核之外还有一层，是每条内核在具体场景下的展开——删数据怎么做、开源贡献怎么做。我想看看这四个取舍在那一层有没有现成的条目。
两个有，两个没有。
“替换过时依赖”和“结构性改动补测试”这两个场景，我九个月的对话里没发生过，所以那一层没有。
它是靠判据硬推出来的。
这正是 37 条规则做不到的事。规则库不可能穷举，但判据能推出没见过的场景。
它会持续迭代进化
内核不是写完就定型的。我做的时候心里清楚：九个月的对话只能反推出过去九个月里发生过的判断，往后每一个新的取舍，都可能是内核没覆盖的，或者是我自己变了。
所以最后做了一个命令，叫 /decisions。
我隔一段时间跑一次。它把上次之后的新对话再过一遍，用同一套流程筛出裁决、转成记录，然后拿每一条去对照十一条内核，分成四类：
已覆盖——某条内核的提问能直接推出这个裁决。只计数，不用看。
新模式——没有内核推得出它，而且出现了三次以上、或跨了两个项目。这是候选的新内核，或者某条内核该补的边界。
相悖——我的裁决和某条内核方向相反。它不会直接判内核错了，先去找隐藏条件，因为前面三组撞车的经验说明：多数“矛盾”是漏了条件，不是原则错了。
提问偏差——内核已经能推出答案，它却还在问；或者该问的没问。这一类是内核落地效果最直接的指标。
跑完出一份报告，等我看。哪条要改、往哪个内核里补一句边界，我定了它才动。不自动写——我早先试过让 AI 在每次会话结束时自动沉淀记忆，结果记了一堆没价值的东西，这次不重蹈。
第一次跑的时候，增量正好是我和它争论 K11 那几天的对话。按流程，我对“我划的范围就是范围”的否定会被抓出来标成“相悖”，然后它去找条件——条件已经写进内核了，所以它应该报“已覆盖”。如果报成了相悖，说明内核的措辞还不够可推导。
那本身也是有价值的信号。
最后
做完这件事，我最大的收获不是 AI 变聪明了。
是我第一次把自己九个月里几百次“就这么定”背后的东西写了出来。
大部分我自己也说不清——“一次做彻底还是分批”的切分线是可逆性，“要最佳还是别动”的切分线是在不在路径上，“顺手改还是别越界”的切分线是补完还是扩展。
这些决策依据一直在，我一直按它们在做决定，但我从来没看见过它们。
工作流设计的本质是注意力的分配宪法。这次算是把宪法写了出来。
写的过程里发现，给 AI 立规矩，其实是在给自己做一次决策复盘——它逼你回答一个平时不用回答的问题：你为什么这样选？
十一条内核会一直迭代更新。每次 /decisions 跑完，它来问我的其实是同一个问题：这条是内核漏了条件，还是你变了？
那个问题我愿意答。
因为蒸馏出来的，是过去的我；新的问题，还是得我自己给出答案。
评论