免费模型与服务器接入生产架构前的审查清单

免费模型和免费服务器正在成为许多团队尝试 AI 编程的默认入口。MonkeyCode 等平台提供的免费模型调用与免费服务器，让"先跑起来"看起来毫无成本。但可用性声明不等于设计——速度带来的只是更快的未经验证草稿，而不是更接近生产的代码。本文基于一份名为《File the Next Change Before Run》的路径审查实践，梳理在把免费资源接入真实系统之前，必须先完成的约束梳理、数据流走查与失败域划分。

速度不是进度

当模型在几秒内给出回复时，几乎所有人都会感到一种"前进"的错觉。原文对此的表述很直接：那种速度只是一个更快的未经验证草稿。

真正的工作发生在草稿与宿主系统之间的接缝上。这个接缝有自己的约束、数据流和失败域。你需要在跨越之前，先命名下一处改动——也就是把"下一次改什么"写进契约，而不是让模型替你决定。

免费模型不会知道你的爆炸半径有多大，免费服务器也不会继承你的生产信任。把这两件事当成设计前提，是把免费资源用好的第一步。

先约束，后舒适

起点应该是那个你无法移动的盒子。仓库里通常藏着密钥、许可证和用户数据，这些内容都不应该搭上提示词的便车。

免费模型通道只负责写文本，不负责合并代码。你发送的上下文应当是能回答单个问题的最小集合，而应用权限始终留在你控制的宿主上。

免费服务器是一张租来的工作台，不是你的工厂车间。你不知道它的邻居是谁、生命周期多长、离开后磁盘上还剩什么。上面每一个文件都应当被当作公开草稿纸对待。

这里有一个容易被忽略的纪律：在规划之前先去产品页面确认当前限制。配额、硬件和时长都是会变的，如果页面与你的记忆冲突，以页面为准。

这套审查默认两件事：你能读懂 diff 并拒绝它，你能在自己管理的机器上运行测试。任何一条不成立，就应该在这里停下。

最小上下文原则（Minimal Context） 源自安全工程中的"最小权限原则"，其思路是：发送给外部系统的信息，应恰好足以回答当前这一个问题，多一个字节都是风险。在 AI 编程场景中，这条原则尤其重要——提示词一旦离开本地，内容就进入了第三方模型的推理路径、缓存乃至日志。因此，契约里不仅要写"我要问什么"，还要写"我允许包含哪些文件、禁止包含哪些路径"。这与传统代码审查中的"diff 最小化"是同一种审慎：把变更面缩小到你愿意为它负责的范围，剩下的留给下一次改动。

走一遍数据流

可以把跨系统协作想象成一个需要穿越繁忙城市的包裹：标签是你在本地写好的契约，卡车是模型调用，码头是服务器。

契约在你自己的机器上先写好，列明问题、允许的文件、禁止的路径，以及你打算保留的下一处改动。它离开本地时是纯文本——这个出口动作仍然算数，即便供应商再慷慨。在文本移动之前，先剥离 token、密钥和客户数据行。

模型返回的是草稿，不是裁决。把草稿和契约一起存到磁盘上，像对待一封来自谨慎陌生人的邮件那样做 diff。

只有受限的检查才允许前往免费服务器。这个检查是一条带超时和测试夹具的命令，它不能执行迁移，也不能打开生产路径。结果以日志和退出码的形式返回，你在自己已经信任的宿主上阅读它们。租来的服务器没有投票权。

命名一起崩溃的域

失败域是那些会一起崩溃的东西的集合。免费定价不会替你画出这个集合，你必须自己在运行开始前画好。

• 提示词域：发出去的提示词本身。一个糟糕的提示词可能泄露密钥或私有路径，爆炸半径是这把密钥能触及的所有系统。
• 草稿域：你可能接受的补丁。一个自信的补丁可以反转检查或移除守卫，爆炸半径是跳过审查后的下一次合并。
• 免费服务器域：你借来的共享工作台。它可能保留文件、日志或写了一半的环境变量，爆炸半径是你复制到那块磁盘上的所有内容。
• 应用宿主域：你仍然拥有的那台主机。它可以改变真实用户的状态，因此必须刻意留在免费回路之外。

如果两个域共享同一份凭证，那它们本质上就是一个域。在庆祝绿色日志之前先把它们拆开。草稿纸上的绿色日志不是发布。

失败域（Failure Domain） 是分布式系统与可靠性工程中的经典概念，指一组因共享资源或依赖而会以相关方式同时失效的组件集合。它最初用于描述数据中心里的机架、电源、网络分区——同一机架断电时，其上的所有机器会一起宕机。其核心洞见是：评估风险时应按"会一起倒的东西"分组，而非按组件类别分组。在本篇文章中，这个概念被从物理基础设施迁移到了 AI 编程工作流：提示词、草稿、服务器、宿主这四类对象虽然形态不同，但如果共享同一份凭证或同一块磁盘，就会构成同一个失败域。判断方法很简单——问一句"如果这里出事，哪些东西会跟着一起脏"，能一起崩溃的，就应该在架构上被隔离开。

一份 shell 可以拒绝的契约

原文给出了一段名为 review_path.py 的脚本作为"带标签的提案"，明确声明它不是真实的供应商客户端，也没有声称任何实际调用。它的逻辑包含几个值得借鉴的检查点：

1. 从磁盘读取一份小契约，要求包含 question、allowed_files、forbidden_paths、failure_domains、next_change、check_cmd 六个字段。
2. 用正则检测形如 api_key: xxx、token=xxx 的秘密泄露模式。
3. 如果 check_cmd 里出现 "apply" 字样，标记为疑似执行应用操作。
4. 失败域少于三个时拒绝通过。

配套的契约示例把一个测试问题收缩到单个文件范围，明确列出禁止路径 .env、secrets/、prod.tfvars，并把 next_change 写成一句可执行的句子："Add a test that the helper refuses a fourth attempt."

在你自己管理的机器上运行审查——被拒绝的 ticket 意味着你还没准备好复制文件，干净的 ticket 允许运行夹具，而不是部署。如果脚本以退出码 2 结束，应该去修契约，而不是走侧信道讨价还价：侧信道不是你的架构记录。

退出码（Exit Code） 是 UNIX 进程结束时返回给调用者的整数状态码，0 表示成功，非零表示不同类型的失败。它是 shell 脚本、CI 流水线和自动化工具判断"上一步是否该继续"的核心信号。本篇文章用退出码 2 来表示"契约本身有问题，需要修改契约而不是绕过审查"，这是一个有意的设计：把人的判断变成机器可读的信号，从而让审查可以在无人值守的情况下自我执行。理解这一点很关键——契约不是一张表单，而是可以被 shell 拒绝的提案。当退出码说话时，它的语气比任何人工评审都更不容协商，这恰恰是让纪律落地的机制。

下一处改动写在哪里

下一处改动是契约里的一句话。在示例中，这句话是"第四次尝试的测试"。它必须在模型被允许发言之前写好。

日志返回之后，你要么修改这句话，要么保留它。不要让模型悄悄替换它——你的变更笔记就是架构的记忆。

原文还给出两条值得跟进的改进方向：一是对允许文件做哈希，让 ticket 明确记录"我打算发送的是哪些字节"，后续运行如果字节变动就应当失败；二是给 ticket 盖上一个结束时间戳，免费服务器会话应当在该时间过期，如果无法声明结束时间，草稿纸就变成了家。

有一条边界必须守住：不要给这张 ticket 加自动应用步骤。一旦 ticket 能合并代码，四个域就会塌缩成一个——而这个塌缩正是这套审查存在的意义所在。

谁应该离开这条路径

脚本捕捉的是形状，不是作者的意图。一个没带关键词的密钥仍然可以溜出去，一个看起来无聊的检查仍然可能是错的。它不测量你打算租的免费选项，也不证明隔离、在线时间或数据删除。当前的供应商条款需要你自己去读。

以下场景应当直接绕开这条路径：

• 生产环境的应用操作
• 持有活跃密钥的仓库
• 你无法拒绝一段流畅补丁的情况
• 检查需要私有客户数据时
• 失败域涉及安全硬件时
• 团队需要你无法控制的审计记录时

这套实践是一个可以展示给审查者的本地习惯，不是一个合规产品，也不应该假装是。

收尾

把变更笔记先归档在自己的机器上，反复运行本地审查直到 ticket 干净，然后再花一次免费模型调用来回答你早就写好的那个问题。如果免费服务器仍然是合适的试验台，就只使用那张 ticket。在复制文件之前，先读一遍当前的 MonkeyCode 计划说明，用你的约束而不是口号来做决定。