Argue
我还是忘不掉第一次用到 Fable 的时候。那时它还会在我提出一个想法后，主动补充背景，解释为什么不推荐这样做，再告诉我如果真的想做，应该采用什么方案。那种感觉就像在跟一个年长的架构师沟通。好景不长。后来再遇见 Fable，仿佛经历过一场前额叶切除术，只剩下温和而正确的回答。那段时间，GPT-5.5、Powerline、Grill Me 这些强调质疑与反驳的工作流也开始流行。看完以后大受触动，总觉得通过某种 SOP，也许还能找回最初和 Fable 交流时的感觉。
于是照猫画虎做了一个名为 Petrichor 的私人仓库，把自己的命名习惯、代码风格、重构案例与工程判断全部写了进去，后来又从中长出了 Argue the Boundary。过去给 AI 安装 Skill，大多也是同一种思路：模型知道得越多，规则写得越细，生成的代码自然越可靠。
真正的转折，发生在 GPT-5.6 发布以后。项目需求和 Side Project 同时跑起来以后，原本的 token 额度很快不够用了，最后索性开到了每月 $200。这并不只是让 Agent 可以跑得更多，也意味着过去偶尔才舍得使用的高思考强度，开始变成日常选择。把思考强度开到 high 以后，GPT-5.6 Sol 的表现已经有些出乎意料。即使只说一句“逻辑看起来没问题，怎么写出来的代码这么丑”，它也能理解背后的意思，再把实现重新简化。
这时候忽然想试一件事：如果把那些教它怎么写代码的 Skill 一个个拿掉，最后的结果究竟会变成什么样？
做一次对照
正好那时项目准备写一份 UIKit Style Skill。最初调研出了三个方向：一份只写原则，一份按 UIKit 角色定义职责，还有一份直接规定 section、setup 和命名模板。只比较三份文档没有什么意义。我找了三组不同体量的 UIViewController，分别约为 200 行、500 行和 1000 行，每种体量各两个，一共六个文件。
每个文件再分别运行四个条件：
| 条件 | 内容 | Skill 行数 |
|---|---|---|
| N | 不提供任何 UIKit Skill | - |
| A | 只描述原则与边界 | 82 |
| B | 按 UIKit 角色规定职责 | 225 |
| C | 固定 section、setup 与命名结构 | 229 |
先用几种低成本模型完整跑了一遍。后来还是觉得结论会随模型能力变化，又用 GPT-5.6 Sol 分别在 low 和 high 下，按照相同条件重新跑了一遍。
churn 是新增与删除行之和。它不是代码质量，但意味着需要重新阅读、验证与承担风险的面积。
| GPT-5.6 Sol | 个人偏好排序 | 总 churn |
|---|---|---|
| Low reasoning | B > A > C > N | 3,071 |
| High reasoning | A > B > C > N | 7,257 |
High 的确改善了部分边界判断，却没有让修改自然变得更加克制。相比 low，它使用了大约 3.2 倍 input、3.1 倍 output 和 6.5 倍 reasoning token，四个条件的修改面积也全部增加。
真正改变我的并不是 A 或 B 谁赢了，而是当模型能力继续提升以后，写得更多、规定得更细，已经不再稳定地等于更好的结果。有时它们是在帮助模型，有时却只是在给一个已经足够聪明的模型增加锚点。
参与测试的低成本模型有：DeepSeekv4 Flash、GPT-5.6 Terra、Grok 4.5、Grok 4.6。
在能力相对较弱的模型上，B 无一例外地表现更好；到了 Grok 4.6 和 GPT-5.6 Sol，A 反而更接近我想要的结果。
这次测试为了控制变量，尽可能排除了工程上下文与记忆的影响，因此并不能完全代表日常使用。在真实的工程环境里，Sol 能得到更多上下文，也已经足够聪明。很多时候，我只要说一句「请改得更像我的风格」，它就能给出想要的结果。
Skill 还剩下什么
这次实验并不是为了证明 Skill 没有意义。那些五六千行，甚至九千多行的 Expert Skill 曾经非常好用。模型还不够强时，它们把散落的知识、经验和约束提前装进上下文，确实让结果稳定了许多。删除它们，并不意味着过去写错了。
只是到了 high reasoning，模型已经能够从代码和上下文里推导出大量实现细节。继续把答案写得越来越厚，收益没有继续增加，反而会让过时的经验和具体语境变成锚点。于是删掉了这些知识型 Skill，又把自己写过的 Skill 全部更新了一遍，Argue the Boundary 不再强制加载整份 Petrichor，只保留什么时候应该开始讨论，又应该在哪里停下。Commit 和 PR 相关的 Skill 也不再解释 Git 或 GitHub 是什么，只记录一次工作应该按什么顺序完成：如何整理 commit，创建 PR 前检查什么，PR 创建以后如何处理 Review、CI 与最后的收尾。
这些并不是通用知识，而是我希望怎样工作。Skill 仍然有意义，只是它保存的东西变了。
以前保存模型不知道的知识，现在我更期望保存不愿意每次重新复述的需求。
可当人类把重复交出去后，又该站在哪里？
位于风暴中心
历史的车轮滚滚向前，会碾压路上的任何东西。AI 毫无疑问会继续变强。它可以参与讨论，提出方案，挑战人的判断，再把具体工作一件件完成。很多时候，它甚至已经比人想得更多，以后也只会比现在更好。所以我不想再靠「人总有一种能力无法被 AI 取代」来守住这个中心。工具被创造出来，本来就是为了在某些地方超过人；如果中心永远属于更快、更准、更强的一方，人早在蒸汽机和计算器出现时就已经离场。
真正没有改变的，也许是人始终在借助工具表达自己。
石器延长双手，金属改变力量，文字保存记忆，机器放大生产，自动化接过重复，到了今天，AI 又开始参与思考。每一次工具更替，都让一个人的表达抵达得更快、更远，也让过去无法完成的想法成为现实。工具一直在变，表达者却始终是人。人的判断当然也不是凭空产生的。基因给了人不同的起点，生长环境与后来留下的记忆，又一点点塑造他如何理解世界。童年、家庭、教育、工作，以及与伴侣共同生活的日子，都会在下一次选择到来时重新浮现，有些彼此印证，有些互相拉扯。这也是为什么，同样一份代码，有人觉得已经足够，有人却只想把它全部删掉。尺度并不只藏在代码里，也藏在一个人走过的路里。
判断力从哪里来
可如果一个人的判断来自他经历过的一切，那么另一个问题便绕不过去了：一个还没有足够经历的人，要从哪里获得判断力？
今天的我可以同时调度多个 Agent，只看设计和 diff，也可以在它交出一份逻辑正确的代码以后，说一句「逻辑看起来没问题，怎么写出来的代码这么丑」。可这句判断，并不包含在每月 $200 的订阅里。它来自过去亲手猜想、实现、失败、一遍遍写下又擦掉的东西。那些代码大多没有留下，走过的弯路也不会出现在最后的成果里，留在身上的只有一些很难重新说清的东西：什么时候应该继续，什么时候应该停下，为什么一个正确的答案，仍然可能不是自己想要的答案。
「国家不幸诗家幸，赋到沧桑句便工。」这句话真正残忍的地方，不是它赞美苦难，而是它承认：有些表达，的确只有走过以后才会属于一个人。可国家之不幸，并不会因为成就了诗句就变得值得；过去的笨拙与失败，也不该因为塑造了判断力，就被原样留给后来的人。
我们当然不该为了培养新人故意保留低效，更不该要求他们把前人吃过的苦再吃一遍。AI 提高了新人的绝对能力，让一个刚入行的人也能很快得到过去需要多年经验才能完成的结果。这没有什么不好。真正让我不安的是，AI 可以压缩完成一件事的时间，而一同被压缩的那些过程，也很难再在记忆里留下分量。过去那些修改页面、编写业务、修复小 Bug 的工作并不伟大，却足够真实。如今，它们恰好也是最先被交给 AI 的事情。对公司来说，这几乎是必然的选择：执行的成本被省下了，成长的成本却没有因此消失，只是变成了一个暂时没人愿意支付的东西。
新的阶梯应该长什么样，我依然不知道。它大概不会是关掉 AI，让新人重新手写所有已经可以自动完成的代码；也不该把我们经历过的低效与痛苦，包装成他们必须重走一次的道路。但至少要有人愿意把一件足够小、却真实的事情交到他手里。允许他借助 AI，也允许他慢一点、做得不够好；同时要求他解释自己的选择，跟着结果走到最后，再在出错以后回过头，亲手修正最初的判断。因为工作从来会留下两个结果：一个是被完成的事情，另一个是做事的人，在这个过程中渐渐知道了什么才算做好。AI 可以接走前一个，后一个却不会自动留下。我们真正需要为后来的人保留的，也许不是几行必须由人亲手写完的代码，而是一些仍然会进入他记忆的选择与后果。让他有一天站在一个远比今天更强的 AI 面前，也能说出一句真正属于自己的：
「这就是我要的。」
然后知道，自己为什么愿意为这句话负责。
附：文章还在收尾，作者的 Claude Code 账号却先被封了。比白月光更有杀伤力的，是死去的白月光。
阁中帝子今何在？槛外长江空自流。