分享2个Vibe Coding必备的超实用Prompt。

周末跟几个之前的老朋友吃饭。

大家也都不由自主的聊到了AI，然后也聊到了Vibe Coding。

因为几乎都不是专业的程序员，都是各个其他职业的，有基金经理、设计师、老师、产品经理、媒体人等等等等，所以大家也都说了蛮多自己使用Vibe Coding的心得，也聊了不少过程中遇到的坑。

然后他们就问我，你几乎每天都在Coding，也写了那么多的教程和分享，问我说如果让你给大家安利几个Vibe Coding中最实用的小技巧，你觉得是什么。

我当时还真的想了半天。

最后，我想到了两个技巧，同时也是两个神级Prompt，是我觉得上至巨佬，下至萌新都有用的超级好用的东西：

1. 第一性原理。

2. 对抗式审查。

可以说，我自己在这将近1年的Vibe Coding时间里，这两个词，绝对是我如今每天跟AI说的最高频词汇。

前者管生成，后者管验证，基本能保证你在Vie Coding的时候，写出来的代码和最后的运行，有质的飞跃。

其他的技巧当然也有用，比如我自己一直在说的约束先行、洁癖skill做文档迭代等等，这些也都是好东西。

但如果你只能选两个，那我就选这两个，它们加在一起构成了一个完整的闭环，是我当今心目中Vibe Coding的两大基石，并肩站在一起的那种。

然后给大家在饭桌上解释了一下，大家说，你不如写成文章吧，他们觉得还挺有用。

所以，这篇文章就来了。

也强烈给给大家安利一下这两个技巧。

1. 第一性原理

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

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

举个我周末的例子。

我自己做的AIHOT周五出了一个很严重的事故，就是我们的精选消息飞书推送出了BUG，导致周六凌晨，像OpenAI发布GPT-5.6这种大新闻，在飞书群里居然没有被推送。

然后用户直接反馈，有的甚至都在别的消息卡片下面评论，我周六中午一醒，飞书的反馈提醒直接炸了，二十多条用户反馈。

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

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

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

细节我就不太好说了，不过它找到了我们抓取海外信源的规则中的一个巨大的隐患，而且这个隐患非常的底层非常的深，是流量路由层面的，这个代码甚至都是今年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的水平，会有一个质的飞跃。

文章来自于"数字生命卡兹克"，作者 "卡兹克"。