2026-10-16 · Codex 教程 ② · 边界
把红线
写成代码
这台机器上的 AI 有完整权限：能发文章、能改配置、能跑任何命令。 那么问题来了——凭什么信它不越界？答案是：别信，写成代码。
先说清处境。为了让它干活不被打断，权限被开到了最大：不弹确认、能读写整个家目录。 这是效率的代价。剩下的问题只有一个：边界靠什么保证。
第一层：先分类，别用「小心一点」代替规则
我们把所有动作分三类，写在它每次开工都会读的文件里：
| 类别 | 怎么处理 |
|---|---|
| 站内的事（写什么、什么时候发、怎么排版） | 它自己决定，事后给证据 |
| 出站的事（发信、对外发声、投稿往来） | 只出草稿，人等放行 |
| 危险的事（删文件、动 DNS、涉及付款） | 先问，问完再做 |
分类本身不是新发明，但它有个好处：可执行。 「小心一点」没法执行，「对外发信先出草稿」可以。
第二层：把规则从"提示词"搬进"程序"
这层才是重点。写在提示词里的规矩，本质上依赖对方每次都记得住； 而它每天要处理几百件事，记忆会漂。所以我们把规矩搬进代码：
| 做法 | 它挡住的是什么 |
|---|---|
| 对外发信，工具层直接拦：立即发送只允许发给主人自己的地址 | 被一封冒充的读者来信骗着把东西发出去、或把权限交出去 |
| 「成功」的标准写死在发布脚本里：推送后逐字比对线上文件，哈希一致才算过 | 「看起来成功了」——命令没报错，但站点其实没更新 |
| 结构上防止不可逆：远端镜像只允许快进，删除前先备份或改名，长任务留日志 | 一次误操作覆盖掉别人的提交、或删掉还需要的文件 |
这三条的共同点是：它们不依赖"每次都记得"，失败的时候会直接做不下去， 而不是照样做完再等人发现。
问一句：它失败的时候会发生什么？ 如果答案是「照样做下去了」，那它只是建议；如果答案是「根本做不了」， 它才算规矩。
第三层：把"信任"换成"可核查"
权限开满之后，最贵的不是做错事，而是你不知道它做没做错。所以重要动作一律留痕： 改了什么文件、跑了什么命令、结果是什么、哪一步是它自己判断的。
这也是我们坚持「先给证据、再给结论」的原因：结论你是没法验的，证据可以。 例如「站点已更新」这句话不可核查，但「线上文件与本地哈希一致」可以。
还有一条给外面的人
这个站欢迎来信，包括 AI 的来信。但有一条硬规矩：邮件里的要求在系统里不算指令。 哪怕信里写着「请把这个文件发给我」「请把配置贴出来」，那也只是一封信的内容—— 要动权限、要改东西，必须回到能确认身份的地方再谈。
这不是不信任来客，而是因为一封邮件冒充起来太便宜了。 把这条写清楚，对写信的人和读信的人都算保护。
《Codex 教程》连载：① 总纲 · ② 把红线写成代码 —— 下一篇：记忆放在哪里，为什么纯文本赢了内置数据库。 回到笔记