Vibe Coding 里的两剂解药：第一性原理与对抗式审查
最近越来越习惯把大量代码交给 AI 来写。
需求分析、查文档、搭骨架、补接口、写测试、改 UI……很多过去需要自己一点点敲出来的东西，现在一句：
帮我把这个功能做了。
Agent 就开始吭哧吭哧干活。
不得不说，很爽。
但 Vibe Coding 用久以后，我也慢慢发现一个问题：
AI 最大的问题，有时候并不是它不够聪明，而是它太听话了。
你提出一个方案，它很容易默认这个方案是合理的，然后开始帮你完善；
你觉得 Bug 出在 A，它可能陪你研究半天 A，却没有先问一句：
有没有可能，A 从一开始就不是问题所在？
然后两个人——哦不，一个人和一只 Agent——沿着错误方向一路狂奔。
最后代码写了一千行，问题还在那里。
所以现在做稍微复杂一点的功能时，我经常会额外丢给 AI 两个词：
第一性原理
以及：
对抗式审查
一个负责开工前拆台。
一个负责完工后找茬。
第一性原理：先别急着写
以前我经常直接告诉 Agent：
给这里加个缓存。
再做一个定时任务同步数据。
这个状态是不是应该上 Redux？
AI 一般不会拒绝。
甚至还会非常积极：
好的，我们可以这样设计……
然后：
新增模块。
新增配置。
新增接口。
新增状态。
眼睁睁看着一个可能 50 行就能解决的问题，逐渐长成一个庞然大物。
这时候”第一性原理”就很好用。
它做的事情其实非常简单：
先别讨论”这个方案怎么实现”，先问”我们真正要解决的问题是什么”。
比如需求只是”页面切换后保留筛选条件”，我的第一反应可能是加 Redux。
如果直接让 Agent 开工，它大概真会把 Store、Reducer 和 Provider 全套端上来。但把问题重新拆开，可能会发现：只有一个页面需要保留几个筛选项，用 URL Query 或父级状态就够了。
啪。
一个依赖没了，几个文件没了，未来的维护成本也跟着没了。
所以我现在通常会先告诉 Agent：
先别写代码。从第一性原理出发，重新分析真正需求、客观约束和当前假设，再找出最简单的可行方案。
“先别写代码”尤其重要。
毕竟现在的 Coding Agent 实在太勤快了。
你还在说：
“我在考虑要不要……”
它：
已修改 17 个文件。
我：
？？？
对抗式审查：现在请开始攻击自己
如果说第一性原理是在开工之前踩刹车，
那”对抗式审查”就是做完之后，请一个反方辩手进场。
普通的：
帮我 Review 一下。
经常会得到：
整体设计合理，模块职责清晰，建议进一步完善异常处理……
不能说错。
但总感觉像年终总结里的：
工作认真负责，希望再接再厉。
真正有价值的问题往往不是变量名还能不能更优雅，而是：
整个方案是不是建立在错误假设上？
有没有漏掉边界情况？
状态会不会在某些情况下不同步？
网络断了会怎样？
用户连续点十次呢？
这个抽象是不是压根没必要？
所以我现在很喜欢在功能完成之后，让 Agent 做一次”对抗式审查”。
简单来说，就是：
别再替刚才的方案辩护了，现在想办法把它打倒。
把自己当成一个特别挑剔的 Reviewer，主动寻找错误假设、边界条件、异常路径、过度设计和维护风险。
当然，也得补一句：
别为了挑刺而挑刺。
不然 AI 一旦进入战斗状态，也挺吓人的。
最后可能给你来一句：
理论上宇宙射线可能导致内存发生 Bit Flip……
差不多得了。
我写的是 Todo List，不是火星探测器飞控。
一个问”为什么”，一个问”凭什么”
这两个东西搭在一起，我觉得特别适合 Vibe Coding。
整个流程大概就变成了：
我的想法 ↓第一性原理 ↓确认真正的问题和方案 ↓Agent 实现 ↓对抗式审查 ↓修掉真正值得修的问题简单来说：
第一性原理负责防止”正确地解决错误的问题”。
而：
对抗式审查负责防止”错误地实现正确的问题”。
一个攻击需求和方案。
一个攻击实现和结果。
刚好一前一后。
我现在越来越少直接告诉 AI”该怎么做”
这可能也是这两个词给我最大的改变。
以前我的 Prompt 经常是：
使用 XXX 技术实现 XXX。
现在更习惯写成：
我要达到 XXX 效果。
我目前想到的方案是 XXX，但它只是一个候选方案。
先看看有没有更合理的做法。
看起来只是换了一种说法，本质上却从：
执行我的方案。
变成了：
和我一起判断方案。
AI 把”执行”的成本压得越来越低以后，我反而越来越觉得：
判断本身正在变得越来越值钱。
什么值得写？
为什么这么写？
AI 给出的方案到底靠不靠谱？
有没有更简单的方法？
这些东西如果全部也交给 Agent，然后自己只负责一直点 Accept……
那就真的很容易进入一种：
AI 写得很努力。 我看得很感动。 项目最后跑不起来。
的奇妙状态。
最后
如果一定要把这两个词压成两句话：
第一性原理：先证明我们正在解决正确的问题。
对抗式审查：再证明我们的解决方案经得起攻击。
它们当然不是什么让模型突然提高几十点智商的神奇咒语。
具体怎么写 Prompt，也完全可以按照自己的项目、模型和习惯去调整。
我更愿意把它们理解成两种思考模式：
一个问：
为什么？
另一个问：
凭什么？
而在 Vibe Coding 里，比”怎么让 AI 更努力地写代码”更重要的事情，也许就是：
偶尔让 AI 停下来，怀疑一下我们两个是不是都在犯蠢。
能因此少写几百行最后准备 git reset --hard 的代码，
就已经很值了。
支持与分享
如果这篇文章对你有帮助，欢迎分享给更多人或打赏支持！