两个 Prompt 套路让 AI 代码少踩一半坑摘要加一句从第一性原理出发AI 写代码从治表变治本。写完功能再让它做对抗式审查提前挖出那些半夜报警才暴露的坑。一个管生成一个管验证两个 Prompt 套路就够了。你给 AI 一个需求它写出了代码跑通了。你看了一眼逻辑说得过去测试也过了就上线了。然后用户反馈出问题了。它改好了一个地方埋了三个新坑。你盯着日志与代码一脸茫然“这地方明明是它写的我也看了怎么上线就炸”如果这个场景你经历过你不是一个人。AI 写代码最大的坑不是它写不出来是它写出来了你以为它对。你能看懂每一行代码在干什么但你看不到它跳过了什么——那些被训练数据平均化掉的边界情况那些看起来合理但其实不该这么做的设计选择那些在训练数据里出现频率太低所以被模型忽略掉了的极端场景。下面这两个 Prompt 套路一个管生成方案对不对一个管验证代码稳不稳。加在 Prompt 里成本几乎为零但省下来的半夜 debug 时间很实在。套路一在 Prompt 末尾加七个字方法简单到让人怀疑在你提给 AI 的任何需求后面加一句——“从第一性原理出发。”就这样。七个字。为什么这七个字有效AI 默认的工作方式叫类比推理。你让它写一个数据过滤器它在训练数据里搜到几千个数据过滤器的实现找一个最像的改一改给你。代码能跑逻辑也说得过去但它跳过了最关键的一步“你确定这件事应该用过滤器来解决吗”类比推理快但它有一个致命缺陷如果你提的问题本身就有偏差AI 会在一个有偏差的方向上给你一个看起来没问题的答案。就像你问怎么让马车跑得更快类比推理的 AI 会告诉你换更好的马、减重、改装轮子——唯独不会告诉你你应该发明汽车。第一性原理做的事刚好相反不参考现有方案回到最根本的事实重新推演。它不是让 AI 更聪明是让 AI 先停下来想清楚这个问题的本质是什么再动手。一个真实的例子AIHOT 是一个 AI 资讯聚合项目从海外信源抓取内容。某天抓取功能挂了开发者把报错甩给 AIAI 第一反应是修那个报错的函数——哪里报错修哪里几分钟改好。跑了一下午又挂了。换了个姿势把整个需求重新描述一遍末尾加上从第一性原理出发。AI 这次没有直接修报错而是从更底层往回推这个抓取功能依赖的流量路由逻辑是四月份写的当时的设计假设——比如信源响应格式、网络拓扑——现在已经不成立了。于是问题从修一个报错的函数变成了重构一层路由逻辑。不是换个更大的创可贴是把伤口清创、重新缝合。案例来源腾讯新闻《分享 2 个 Vibe Coding 必备的超实用 Prompt》2026.6.29不加 vs 加了AI 给出的方案差多远假设你让 AI 写一个消息队列的消费者。不加这七个字它给你一个教科书式的while-true-poll循环whileTrue:messagesqueue.receive_messages(MaxNumberOfMessages10)formsginmessages:process(msg)queue.delete_message(msg)能跑。但消息量翻十倍的时候消费者来不及处理消息越堆越多内存吃满OOM。这个方案的本质是不管来多少消息我每次只取十条——它没考虑如果消息来得比我处理得快怎么办。加了从第一性原理出发AI 会重新推演消费消息这件事的终极目标不是为了消费而消费是为了在延迟可接受的前提下不丢数据、不爆内存。方案变了whileTrue:queue_depthqueue.get_queue_depth()batch_sizemin(max(10,queue_depth//10),100)messagesqueue.receive_messages(MaxNumberOfMessagesbatch_size)withThreadPoolExecutor(max_workersbatch_size)asexecutor:futures[executor.submit(process,msg)formsginmessages]forfinas_completed(futures,timeout30):...它自己加了背压感知和动态批次调整——积压越多批次越大处理越快压力小了自动缩回默认值。这不是什么高深技术但你没提类比推理的 AI 不会主动加因为它见过的几千个消息队列示例里大部分都是固定批次的简单写法。这七个字什么时候最管用不是所有场景都需要第一性原理。写一个简单的 CRUD 接口、配一个 Nginx 路由类比推理就足够了不需要重新发明轮子。但下面三种情况值得加你在修一个反复出现的 bug。AI 修了三次还出问题说明它只在表面修修补补没有找根因。你要做一个设计决策。选数据结构、定模块边界、设计 API——这些事如果方向错了后面改的代价很大。你也不确定最优方案是什么。需求模糊的时候类比推理会给你一个别人都这么做的方案。第一性原理至少能让你看清楚这个方案的前提假设是什么。套路二让 AI 攻击自己的代码功能写完了测试跑过了Code Review 也过了。这时候你再跟 AI 说一句“开启多 Agent 对抗式审查这段代码。站在恶意用户和极端场景的角度找出所有可能导致系统崩溃或数据异常的漏洞。”正常开发的时候你的大脑处于建设模式——想着功能怎么实现、逻辑怎么走通、正常路径怎么覆盖。你不会去想如果发布时间是 2038 年会怎样也不会去想如果用户上传了一个 50MB 的纯文本、但所有内容都在一行里、HTML 清洗函数要遍历多少 DOM 节点。对抗式审查逼 AI 切到攻击模式。它不再是帮你写代码的助手而是你的对手——它要找到你代码里所有能被搞崩的地方。两个大概率你没想到的 bug还是 AIHOT 项目的真实案例。开发者用 Claude Code 开启了约 40 个 Agent 做对抗式审查跑出来的问题列表让整个团队出了一身冷汗。挑两个最典型的OOM 死循环。从某些海外站点抓到的内容文件特别大worker 进程处理到一半被系统的 OOM killer 杀掉。原来的代码逻辑是A 任务失败了就重试——worker 被杀掉之后调度器自动拉起一个新的 worker。新 worker 拿到同一个 A 任务读同一份超大文件又被 OOM killer 杀掉然后又被拉起……一个死循环。正常开发的时候你在乎的是重试逻辑对不对你不会去想如果导致失败的原因是资源不足重试是在帮倒忙。但对抗式审查的 Agent 上来就问了一句“如果单条消息的处理所需内存超过 worker 的内存上限你的重试机制会发生什么”未来时间污染。某海外信源的服务器配置错了时区返回的文章发布时间是明天中午十二点。爬虫收到之后不做任何校验直接按信源给的时间写入数据库。结果用户的信息流排序逻辑是按发布时间倒序——于是那几篇来自未来的文章永远排在所有人的信息流最顶端。对抗式审查的 Agent 问了开发团队自己从没想过的问题“如果外部数据源的任何字段值落在合理范围之外你的代码会怎么样”这些 bug 有一个共同特征上线前很难被发现但一旦触发影响很大。而且它们不是某个人写错了代码导致的是整个设计里根本就没有考虑过这条路径。传统测试 vs 对抗式审查测试方式能发现的 bug发现不了的 bug单元测试逻辑错误、边界值跨模块交互问题、资源竞争集成测试接口不匹配、数据格式错误极端输入、资源耗尽、时序异常人工 Code Review代码风格、明显逻辑漏洞隐蔽的边界条件、组合爆炸对抗式审查恶意输入、资源泄漏、外部数据污染、死循环条件业务逻辑本身的合理性对抗式审查补的不是测试的短板——它补的是你能想到的测试用例之外的那个世界。传统测试验证的是我想到的可能出问题的场景对抗式审查探索的是我根本没想到的场景。这是两种完全不同的思维所以两种都需要。两个套路怎么搭第一性原理管生成AI 动手写代码之前先让它想清楚这件事的本质是什么。方向对了方案不会差太远。对抗式审查管验证代码写完之后让 AI 换个角色找那些正常思维路径上根本不会去想的漏洞。逻辑对了还要扛得住边界攻击。一个在前一个在后。前一个避免做错事后一个避免做漏事。两个加起来就是一个足够轻量但仍然有效的质量闭环。注意一个坑对抗式审查跑出来的结果不能全信也不能全改。它有时候会为了找问题而找问题——把一个发生概率无限接近零的边界条件描述得像是随时会炸。你需要自己做判断这个问题发生的概率多大发生了影响多大修它的成本多大优先级排一下先改那些高概率、高影响的。剩下的记在 TODO 里写明触发条件下个迭代再看。另外一个教训每次改完核心功能就跑一次对抗式审查别攒到上线前一天。那时候发现问题属于灵魂拷问——半夜改代码上线还是带着已知的坑上线两个都很难受。一个额外的应用场景前面说的是代码。但这两个套路其实不止于写代码。写技术方案的时候加一句从第一性原理出发AI 会帮你追问这个方案到底要解决什么问题而不是堆砌别人的架构。写完方案再让它做对抗式审查“如果你是评审人你会质疑哪些点”能提前暴露很多逻辑漏洞。做商业分析、写项目复盘、甚至做个人决策这两个套路都能用。本质上是让 AI 先退一步想清楚本质再换个角度找盲点——这套思维方式比任何具体的 Prompt 模板都值钱。总结两个句子记住就行问方案加一句从第一性原理出发。问安全加一句对抗式审查。试一次成本为零。不好用你就当多打了几个字。作者唐悦玮 公众号同名从后端出发用 AI 拓展到全栈的工程师。