转载自微信公众号「数字生命卡兹克」[1]

非程序员背景下做 AI 辅助开发，最大的风险不是“写得慢”，而是“看起来能用，其实埋了雷”。这篇文章作者总结了自己每天高频使用的两个 Prompt 思路：一个管生成，一个管验证，合在一起形成一个完整的质量闭环。

从第一性原理出发

这个技巧的用法很简单：正常提需求，最后加一句“从第一性原理出发”。

它的作用不是让 AI 写得更长，而是打断 AI 的类比推理。当前大模型很多时候是在训练数据里找“看起来差不多”的现成方案，然后拼出一个表面合理的答案。而“从第一性原理出发”这句话，会强制它回到问题本身：这个问题到底应该怎么解？

作者举了自己维护 AIHOT 时的例子：某次 OpenAI 新闻推送失效，表面看是某个国产模型测试时改坏了抓取规则，修一下就行。但加上“从第一性原理”后，AI 继续往下挖，发现了流量路由层面的深层隐患——那个国产模型只是碰巧把表层点错，把底层已经存在的路由问题暴露了出来。如果只做表面修复，未来不同信源还会继续出问题，变成“缝缝补补的破船”。

这类思维方式的本质，是不要先问“别人是怎么做的”，而是问“这件事的本质是什么，从零开始应该怎么解”。亚里士多德两千多年前就提出过第一性原理；马斯克用同样的思路把 SpaceX 的火箭发射成本降低了 90%。

对抗式审查

第一性原理解决“方案是否对”，但不管“上线后是否稳”。对抗式审查解决的是后者：让 AI 站在“恶意用户会怎么搞崩这个系统”的角度，主动找漏洞。

作者用 Claude 的动态工作流开了近 40 个 Agent，对项目做了一次纯找 BUG 的对抗式审查，结果发现了多个真实隐患：

  • OOM 死循环：后台 worker 处理大任务时内存爆炸，被系统杀掉后自动重试，导致无限循环。
  • 未来时间污染：某信源因时区错误把文章发布时间写成“明天”，这篇文章会直接跳到信息流最前面，甚至被推送给用户、进入 RSS 和日报，污染整个系统。
  • HTML 清洗性能炸弹、翻译模块同类隐患、缓存穿透假阳性等。

这些 BUG 在正常开发时很难被想到，但当 AI 明确被告知“假设有人故意用极端数据搞崩系统”时，它会把入口到崩溃的全链路走一遍，把边界 case 提前暴露出来。

为什么这两个 Prompt 有用

作者现在每 2 到 3 周会对整个项目做一次全局性的“第一性原理 + 对抗式审查”，每次都能发现之前没注意到的技术债和潜在风险。他的体会是：这些问题如果不主动去找，就会一直潜伏，直到某天突然爆发。

更广义地说，这套思路不止于代码：

  • 写完一篇文章，可以让 AI 做对抗式审查，从逻辑漏洞、事实准确性、论证力度挑毛病；
  • 商业方案可以先过第一性原理，剥掉所有假设，质问核心逻辑是否成立；
  • 甚至人生决策也可以用：先用第一性原理想清楚自己要什么，再用对抗式审查找出自己思考中的盲点和下意识回避的风险。

来源

[1] 数字生命卡兹克. 分享2个Vibe Coding必备的超实用Prompt[EB/OL]. https://mp.weixin.qq.com/s/umPqTD_-IubbhXIgiS47eQ