我每天对 AI 说得最多的两句话：第一性原理和对抗式审查

要说我最近这一个月跟 AI 对话里冒出来频率最高的话，排在最前面的不是「帮我写个函数」，也不是「这个报错怎么修」，而是两句听起来有点装的话。

一句是「从第一性原理出发」。

一句是「对抗式审查一下」。

前一句管生成，后一句管验证。我现在写代码、改 bug、让 agent 帮我设计架构，几乎条件反射地往 prompt 后面缀上这两句里的一句。说真的，自从这俩成了肌肉记忆，我手里那些 vibe coding 出来的东西，从「能跑」到「敢上线」之间的那道坎，肉眼可见地变矮了。

这事我得从我自己的活儿说起。我日常的工作是给大模型搭脚手架，就是让模型真正能干活的那层工程，agent 的工具链、调度、超时重试、上下文管理这些。这个位置有个好处也有个坏处，好处是我天天看 AI 在生产环境里怎么干活，坏处是我天天看它怎么翻车。看多了你就会发现，AI 写代码翻车，基本就翻在这两个地方，一是方向错了，二是边界没兜住。而这两句 prompt，刚好一句治方向，一句治边界。

最近数字生命卡兹克写了篇文章专门聊这两个 prompt，我看完特别有共鸣，正好借他的几个例子，把我自己的体感也唠一唠。

先说第一句，从第一性原理出发。

这个 prompt 简单到有点离谱，你平时怎么说就怎么说，最后加一句「从第一性原理出发」就完事了。但加与不加，AI 给你的东西能差出一个段位。

卡兹克举了个我觉得特别典型的例子。他那个 AI 资讯产品有天出了事故，本来该推送的大新闻没推出去。他让 agent 去查，agent 很快回话，说是之前测试别的模型时把抓取规则改坏了，断了三天，修好就行。听起来合情合理，对吧。但他有点不对劲的直觉，补了一句，根据第一性原理来找一下原因。

这一下就不一样了。agent 顺着往下挖，挖出来的根本不是抓取规则坏了这么表层的事，而是底层流量路由的一个深坑，那段代码几年前就埋在那儿了，这次只是被表层的小改动给顶出来了。结果他没去打那个补丁，而是花了半天把底层重构了一遍。

一个是治表，一个是治本。我看到这儿是真的会心一笑，因为这种场景我太熟了。

你想想 AI 现在写代码是怎么个写法。你让它写一个过滤函数，它干的事其实是在训练数据里找几万个长得差不多的过滤函数，然后糅一个看起来贴合你项目的版本出来。这个过程快，结果大概率能用。但它跳过了一个我觉得最要命的问题，这个问题真的应该这么解吗？

「从第一性原理出发」这七个字，干的就是强行打断 AI 这套类比推理，把它从「别人怎么解我就怎么解」拽回到「从最基本的事实重新推一遍」。

这套思路本身不新，亚里士多德两千多年前就讲过第一性原理。后来被讲得最出圈的是马斯克，当年所有人都说火箭发射就得烧掉几个亿，这是行业共识。马斯克的做法是回到原材料，铝合金、碳纤维、航空级燃料这些东西加起来才几个钱，凭什么要几个亿。然后 SpaceX 从这个数字倒推，把整条制造流程重新设计了一遍，发射成本干到了行业的零头。

放回到跟 AI 对话这件事上，它格外好用。GitHub 上甚至有人把它做成了一个专门的 skill，名字就叫 first-principles。不过我跟卡兹克的看法一样，你真没必要装什么 skill，也不用写什么系统提示词，需要的时候在 prompt 末尾加那一句就够了。任务只要稍微复杂一点，这一句几乎是万能的。

这里我补一个我自己摸出来的小边界，第一性原理不是无脑加。任务越简单，它带来的增益越小，反而会让 AI 绕一大圈给你写一堆论证。我现在的习惯是，遇到「改个文案」「调个颜色」这种活儿就不加，遇到「这个方案该不该这么设计」「这个 bug 为什么反复出现」这种需要往深里想的，才把它甩上去。它是给硬骨头准备的，不是给软柿子的。

还有个用法我特别推荐，让它先回答再质疑。你可以加一句，从第一性原理出发，先说清楚这个问题最根本的约束是什么，再判断现有方案是不是在解一个伪命题。这么一引导，AI 就不会上来直接给方案，而是先把地基亮给你看。地基对了，上面盖什么都好说。

但第一性原理有个边界，它能帮你找到好方案、找到 bug 的真正根因，可它管不了一件事，就是开发完了到底能不能稳稳上线。

这就轮到第二句出场了，对抗式审查。

如果说第一性原理是让 AI 站在你这边帮你想，那对抗式审查就是让 AI 转过身，站到你对面来揍你。你给它的指令大概是这样，你现在是一个想搞垮这个系统的恶意用户，从攻击者的视角，把这段代码从入口到崩溃完整走一遍，告诉我哪里能被打穿。

卡兹克在文章里举的几个 bug，我看的时候是真的没绷住，因为每一个都精准踩在我职业生涯被坑过的点上。

一个是 OOM 死循环。后台 worker 处理一个超大任务时内存爆了，被系统杀掉，然后自动重试，重试又爆，又被杀，无限套娃。对抗式审查是怎么发现的呢，它从「如果我是坏人，我提交一个 50MB 的 HTML 来撑爆你的 worker」这个角度，把整条路径走穿了。OOM 就是 out of memory，内存溢出，对搞后端的朋友来说这玩意儿半夜把你 call 醒的次数应该不少。

还有一个我觉得最妙，未来时间污染。某篇文章因为时区错误，发布时间显示成了明天，于是它的时间戳是全场最新的，直接被排到信息流最前面，还可能被推送出去。一篇来自未来的文章，把整个流给污染了。这种 bug 你自己写代码的时候压根不会想到，但你让 AI 站在「我要拿各种奇形怪状的脏数据搞垮你」的角度去审，它自然就会问，那如果发布时间是未来呢？

这就是对抗式审查的精髓。它替你补上了你自己想象力的盲区。

而且这件事，对我这种干 harness 的人来说，简直是刚需。我每天面对的就是各种 agent 在生产里以你想不到的方式翻车，缓存穿透的假阳性、清洗模块的性能炸弹、探活逻辑被一个边界值带崩。这些东西的共同点是，正常路径下永远不会出事，它们只在某个没人测过的角落里蹲着，等哪天流量一上来集中爆发。对抗式审查的价值，就是提前把这些蹲着的东西一个个揪出来。

我自己更进一步的玩法，是多开几个 agent 一起审。一个 agent 的攻击想象力是有限的，但你让好几个并发地从不同角度来攻，覆盖面立刻就上去了。在 Claude Code 里我会直接说，开多个 agent 对之前那个功能做对抗式审查；Codex 也一样，说一句开多 agent 帮我对抗性审查，它会自动铺开好几个。极致且纯粹的攻防战，听着就带劲。

说到这我得插一句真诚的话。vibe coding 这个东西，好用是真好用，但漏洞也是真多。很多用 Cursor、Claude Code 这类工具的朋友其实不写代码，或者写得不多，全靠跟 AI 聊把东西聊出来。这没问题，但如果你不在上线前把这些坑提前想到，直接把一坨没审过的代码扔到线上，最后伤的是你的用户。那就不是 bug 了，那是事故。

所以这两句 prompt 在我这儿是配套用的。第一性原理负责把方案做对，对抗式审查负责把方案做稳。一个往深里挖根因，一个往坏里想边界，俩搁一块儿才是个完整的环。

卡兹克还提了一个我觉得值得抄作业的习惯，他每隔两三周，会对整个项目做一次全局的、从第一性原理出发的对抗式审查。让一堆 agent 从最底层原理出发，去并发审架构、依赖关系、代码质量、文档对不对得上。

我试着把这个习惯搬到自己的项目里，体感是真好。平时写代码是往前赶的，赶的时候你看不见技术债，它就一层层悄悄堆在那儿。但你每隔一段时间专门停下来，开几个 agent 当审计员，从根上把整个工程过一遍，每次都能抠出几个你压根没注意到的隐患。这些东西你不主动去找，它们就一直潜伏，等某天流量上来或者数据变脏，集中给你引爆。提前找出来，提前补，比线上炸了再半夜爬起来救火，划算太多了。顺手还能拿来测新模型的能力，一举两得，有点子牛逼。

厉害了的是，这两套思路根本不只在写代码时管用。

你写完一篇文章，让 AI 对抗式审查一下，它会从逻辑漏洞、事实准确性、论证力度好几个维度给你挑刺，比你问它「帮我看看这篇写得咋样」有用太多了，后者只会夸你。你做完一个方案，让它从第一性原理审一遍，它会把你那些没说出口的假设一层层剥掉，直接质问你的核心逻辑到底成不成立。

我有时候觉得，这俩与其说是 prompt，不如说是两种思维习惯。第一性原理的核心就一句话，回到最根本的事实重新推。对抗式审查的核心也就一句话，你永远需要一个站在你对面的力量，来提醒你，你可能是错的。

这话听着有点像处世哲学，但我是真信。我们写代码的人，最怕的从来不是不会写，而是写错了还自我感觉良好。一个帮你想得更深，一个逼你认错得更早。

想想还挺浪漫的。

这两个习惯一旦内化进你跟 AI 协作的方式里，你会发现，你用 AI 的水平，是会有一个台阶式的跳变的。不夸张。