周末跟几个老朋友吃饭，话题不由自主地聊到了AI和Vibe Coding。

在座的基本都不是专业程序员——有基金经理、设计师、老师、产品经理、媒体人——大家聊了不少各自用Vibe Coding的心得，也谈了很多路上踩过的坑。

然后他们问我，几乎天天在写代码，又写了那么多教程和分享，如果非要推荐几个Vibe Coding中最实用的小技巧，会是什么。

当时愣了半天。

最后想到两个技巧，也是两个神级Prompt，从顶尖高手到刚入门的新手都绝对能用上：

1. 第一性原理。

2. 对抗式审查。

可以说，将近一年的Vibe Coding经历里，这两个词是如今每天跟AI交谈时最高频的词汇。

一个负责生成，一个负责验证，基本能保证Vibe Coding时写出来的代码和最终的运行效果有质的飞跃。

其他技巧当然也有用，比如一直强调的约束先行、洁癖skill做文档迭代等等，都是好东西。但如果只能选两个，一定就是这两个。它们加在一起，构成了一个完整的闭环，是Vibe Coding的两大基石，并肩站在一起的那种。

饭桌上解释完，大家说不如写成文章吧，觉得还挺有用。于是，这篇文章就来了。

也强烈推荐给各位这两个技巧。

1. 第一性原理

这个技巧有多简单呢？平时该怎么说就怎么说，但最后加一句“从第一性原理出发”就行。

加了这一句话后，会发现Agent写方案的能力、找BUG的能力，都进化了一大截。

举一个周末的例子。

AIHOT项目上周五出了一个很严重的事故——精选消息的飞书推送出现了BUG，导致周六凌晨，像OpenAI发布GPT-5.6这样的大新闻，在飞书群里完全没有被推送。用户直接反馈，有的甚至在别的消息卡片下面评论。周六中午一醒，飞书的反馈提醒直接炸了，二十多条用户反馈。

赶紧让Agent去修复。它查了一下，说是之前测试一个国产模型的时候，OpenAI的抓取被那个国产模型给瞎改坏了，所以断了三天，OpenAI的官网信源一直没有被抓取到，直到今天才发现。修复就好。

但当时有一种直觉——这不对，背后感觉有更严重的问题，这个修复好像治标不治本。于是又补了一句，根据第一性原理来找一下原因。

这一次，瞬间就不一样了。

细节不便多说，但Agent找到了抓取海外信源的规则中一个巨大的隐患，而且非常底层、非常深，是流量路由层面的。这段代码甚至是今年4月中写的，只是因为那个国产模型瞎改代码，在表层上做错了一个小点，才把整个底层的流量路由问题暴露出来。

当然可以把OpenAI的抓取单独修复一下，但未来因为这个底层机制，保不齐又有什么信源会出问题。到时候再修再补，就像一艘破船，缝缝补补，最后堆成一座屎山，再暴雷就真的是天大的了。

花了半天时间，把这个底层的路由问题直接重构了。从机制上看，未来大概率可以安心了。

一个是治表，一个是治本。这个差异，是巨大的。

这就是第一性原理的力量。在跟AI对话时，格外好用。社区里甚至有朋友称它为“神之Prompt”之一。

坦率地说，现在的AI很多都还在做类比推理，跟人类一样。你跟它说写一个过滤函数，它会在训练数据里找到几万个类似的过滤函数，然后给你写一个看起来差不多的出来。这个过程很快，结果也能用，但它跳过了最最关键的一步——这个问题真的应该这么解吗？

“从第一性原理出发”这七个字，做的事情就是强制打断AI的类比推理，逼它回到问题的本质去思考，不要参考别人的方案，从最基本的事实出发，重新推导。

这个道理，亚里士多德两千多年前就说过了。然后马斯克把这套思维用在了SpaceX上。当时行业里所有人都说火箭发射就是得花几个亿，行业共识。马斯克不信，重新从材料成本开始算——铝合金、碳纤维、航空级燃料，这些原材料加一起才多少钱？你说几个亿？然后SpaceX从这个数字出发重新设计整个制造流程，最后发射成本降了90%。

GitHub上甚至已经有人做了专门的skill，就叫first-principles。但不必装什么Skill，也不需写什么System Prompt——在需要的时候，比如解决问题、修BUG、让AI帮你设计架构时，在你Prompt后面加一句“从第一性原理出发”，这就够了。只要任务稍微复杂一点，这个Prompt几乎是万能的。神级Prompt，当之无愧。

2. 对抗式审查

这是之前发现的，超级有用的一个审查Prompt。

现在只要做开发，最后的测试流程，几乎都必然是对抗式审查这句话。

第一性原理可以保证帮你找到好方案、找到BUG的真正本质解法，但它们没办法保证开发完后能稳定上线。而这，就是这个Prompt要解决的问题——怎么保证AI写的代码确实没啥毛病。

今年6月初，Claude Opus 4.8和动态工作流上线之后，对AIHOT做了一次比较大的对抗式审查，纯找BUG。记得当时开启了近40个Agent，跑了很久，找出了N个可能的风险。

比如有一个叫OOM的死循环问题——后台worker如果处理一个特别大的任务时内存爆了，会被系统杀掉，然后自动重试，结果必然又爆，又被杀，无限循环。对抗式审查从“如果我是一个恶意用户，我会提交一个50MB的HTML来搞崩你的worker”这个角度，把整条路径从入口到崩溃全走了一遍，找出了这个缺口。后面信源加多了之后，还真的看到过100M的HTML……

最搞笑的是还有一个“未来时间污染”的BUG。如果某个信源发布了一篇文章，但发布时间因为时区错误或别的原因，显示的是未来的某个时间，比如明天，那这篇文章就会排到整个精选信息流的最前面，因为它时间戳最新。它甚至可能会被推送给用户，进入飞书群PUSH，进入RSS订阅，日报也会把它排在最前面。一篇来自未来的文章，就会把整个信息流都污染了。

这种BUG，自己写代码时根本不会想到。但当你让AI站在“我要用各种奇怪的数据来搞崩你的系统”这个角度来审查时，它就会问——如果发布时间是未来怎么办？

还有一堆乱七八糟的：HTML清洗模块的性能冲击波、翻译模块的同类隐患、部署探活的缓存穿透假阳性……各种奇奇怪怪的BUG。提前发现问题，提前解决，考虑到所有情况，尽可能不让真实项目出现问题。

毕竟不懂代码，只能依赖AI来进行Vibe Coding。而Vibe Coding出来的东西，漏洞确实也多。如果不提前把这些问题全部考虑到，直接扔到线上，伤害的就是用户，就是真正的事故了。

对抗式审查，强烈建议多开Agent进行。比如Claude Code，现在就很喜欢说：“开启Ultracode（动态工作流，会有N个Agent进行并发）来对之前开发的功能进行对抗式审查。”

Codex也可以，直接说“开启多Agent帮我进行对抗性审查”就行，它会自动开好几个Agent。极致且纯粹的攻防战。

自从用了对抗式审查之后，对代码和项目的信心反而变得很强了。

写在最后

现在除了日常开发，几乎每2到3周，会对整个项目进行全局性的“从第一性原理出发的对抗式审查”。让Agent从最底层原理出发，并发去审查架构、依赖关系、代码质量、文档对应等等。正好用来测试新模型的能力，也能整体review一下开发的功能。最好玩的是，每次都能挑出来之前没注意到的技术债和潜在风险。

特别有意思。这些问题如果不主动去找，就会一直潜伏在那里，等到某天突然爆发。

作为一个纯粹不懂代码的小白，用纯Vibe Coding方式做出来的AIHOT，最近一周的请求量就超过千万，Skill的调用量也远远超乎预期，是网页端的10倍以上。虽然偶尔出一些小BUG，但能稳定地为这么多用户提供服务，心里还是很自豪的。

这两个Prompt——第一性原理和对抗性审查——居功甚伟。

而且说实话，这两个东西的应用范围远远不止Vibe Coding和代码。它甚至是我们对待世界的处世哲学。写完一篇文章，可以让AI帮你对抗式审查，从逻辑漏洞、事实准确性、论证力度多个维度来挑毛病；做完一个商业方案，让AI从第一性原理出发审视，它会剥掉所有假设，直接质问核心逻辑是否成立；甚至在人生决策时也可以用这两套思路——要不要换工作？先从第一性原理想清楚自己到底想要什么，再用对抗式审查让AI专门找思考中的盲点和下意识回避的风险。

因为这两个Prompt的核心逻辑，从本质上来说，跟具体领域无关，只是在Vibe Coding领域格外好用。

第一性原理的核心就一句话：回到最根本的事实重新推导。

对抗式审查的核心也就一句话：你永远需要一个站在你对面的力量来告诉你——你可能是错的。

想想还挺浪漫的。

这两种思维习惯一旦内化，用AI的水平，会有一个质的飞跃。