让 AI 写代码最可怕的不是它写错了

很多时候我们用 Cursor 或 Claude Code 刷刷刷地生成了几百行代码，运行起来没报错，就直接合入主分支了。但这种“盲跑”其实挺危险的，因为 AI 在实现功能时会自带一套隐含的逻辑假设（比如它默认输入数据永远不为空，或者默认某个 API 响应时间在 100ms 以内）。一旦环境变了，这些隐藏的坑会让你在深夜被 On-call 叫醒。

要解决这个问题，不能光靠增加提示词，得引入一套可靠性栈（Reliability Stack）来强迫 AI 把它的“潜台词”显性化。我最近尝试的一套实操流程是：在要求 AI 写具体实现之前，先强制它输出一个 ASSUMPTIONS.md 类似的逻辑文档。

具体实操步骤如下：

一、定义假设捕捉指令
不要直接说“帮我写个功能”，而是在 Prompt 里加入一个强制步骤。比如：

在编写具体代码前，请先列出该功能实现的所有前置假设。
格式要求：
- 外部依赖假设：(例如：假设数据库连接池足够大)
- 数据边界假设：(例如：假设用户输入的 ID 永远是 UUID 格式)
- 性能假设：(例如：假设单次请求处理的数据量不超过 100 条)

二、将假设转化为断言（Assertions）
这是最关键的一步。把 AI 列出的假设直接转化为代码中的 assert 或校验逻辑，而不是让它留在文档里。比如 AI 假设输入不为空，那就直接在函数入口加一行：

def process_user_data(data):
    # 强制将 AI 的隐含假设转化为显式检查
    assert data is not None, "AI Assumption Failure: data should not be None"
    # ... 业务逻辑

三、建立验证循环
当代码跑崩时，第一时间去对比它之前列出的假设清单。如果崩溃的原因正好是某个假设失效了，这说明 AI 的建模能力达到了上限，这时候需要人工介入重新定义边界，而不是简单地对 AI 说“代码错了，请修复”，因为那样它可能会用另一个错误的假设来覆盖之前的错误。

这种做法虽然在开发初期慢了一点，但它把 AI 从一个“黑盒生成器”变成了可审计的工程组件。