速读#
和 AI 一起写了半年代码后，我不再用“查找和样板可以交、理解不能交”这样简单的二分法。真正决定能否委托的是风险和验证能力：结果错了会影响什么，我有没有足够上下文判断修改范围，能否用测试、日志、文档或最小实验确认它有效，以及出错后能不能恢复。
两次教训都不是模型输出了明显的语法错误，而是代码当时能跑，我却没有理解它依赖的机制。一次是多阶段 Dockerfile，第二次要优化缓存时才发现自己改不动；另一次是 Cloudflare、Nginx 和 WordPress 之间没有正确传递 HTTPS 语义，直到重定向循环才暴露。AI 只是更快地产生了一个看似完成的结果，真正缺失的是我的验收标准。
最初的边界为什么不够用#
我一开始认为 AI 最适合查参数、解释报错和生成重复结构，新概念第一次接触时则应该完全自己写。这个原则能防止复制粘贴，却把问题说得太死。AI 也可以是很好的第一位讲解者：让它比较两个概念、生成一个十行实验、故意构造失败案例，都能加快理解；反过来，所谓“熟悉任务”只要涉及删除数据、认证、计费或线上发布，仍然不能因为做过几次就放心自动执行。
后来我把边界改成六个检查点：任务边界、提示上下文、验证、理解债、失败纠偏和风险权限。前两个决定 Agent 知道什么、允许改什么，后四个决定结果能否进入真实系统。它们不是提示词模板，而是我在接受一次 AI 修改前必须回答的问题。
| 检查点 | 我会问什么 | 不清楚时怎么做 |
|---|---|---|
| 任务边界 | 目标是什么，哪些文件和行为不能动 | 先缩小修改范围，不接受顺手重构 |
| 提示上下文 | 版本、现状、约束和错误证据是否给全 | 先读取配置与日志，不让模型靠猜补环境 |
| 验证 | 什么结果能证明修复成立 | 先写检查命令、测试或复现步骤，再改代码 |
| 理解债 | 下次修改时我必须理解哪些机制 | 让 AI 解释关键决策，并亲手做一个最小变化 |
| 失败纠偏 | 上一轮为什么失败，有什么新证据 | 停止连续打补丁，回到日志和因果链 |
| 风险权限 | 是否涉及数据、安全、费用或外部副作用 | 保留人工批准、备份和回滚，不扩大权限 |
第一次教训：Dockerfile 能构建，但我改不动#
容器化一个 Java 项目时，我让 AI 生成了多阶段 Dockerfile。镜像成功构建，容器也能启动，于是我把“能跑”当成完成。两天后想优化 Maven 依赖缓存，才发现自己不清楚 COPY --from=build 为什么能从另一个阶段取文件，也不理解先复制 pom.xml、再下载依赖为什么能减少源码变化造成的缓存失效。
问题不在多阶段构建太复杂，而在我只验证了最终容器，没有验证自己是否能够维护构建过程。后来我重新查看每一层的职责，用只改一行源码、只改 pom.xml 两种情况分别构建，观察哪些层命中缓存，才把概念补回来。这个小实验比让 AI 再写一段解释更有效，因为构建日志直接告诉我它的判断是否成立。
这次之后，我不再要求自己背下所有样板代码，也不坚持每个字符都能脱口而出；我至少要能说明关键阶段的输入、输出、缓存边界和失败后怎样定位。生成代码中的普通样板可以依赖测试，影响构建、安全、数据和运行方式的行则必须知道为什么存在。否则今天省掉的十分钟，很可能在下一次变更时连本带利还回去。
第二次教训：HTTPS 语义在代理链中丢了#
另一回，AI 给出的 Nginx 反向代理配置在本地 HTTP 环境下可以工作，上到 Cloudflare 和 WordPress 后却出现重定向循环。我当时把原因概括成“漏了 X-Forwarded-Proto”，现在看仍然太简单。真正的问题是访客使用 HTTPS，边缘或 Tunnel 到源站可能是另一段 HTTP，而 WordPress 必须通过一条可信的转发链知道最外层协议；Header 缺失、被 Nginx 用当前 $scheme 覆盖，或者 WordPress 没有信任它，都可能让后端不断要求跳转到 HTTPS。
因此正确检查不是机械补一行模板，而是沿请求逐跳确认：Cloudflare 使用什么 SSL 模式，Tunnel 或 Nginx 收到的 X-Forwarded-Proto 是什么，Nginx 转给上游的值是什么，WordPress 又根据哪个变量判断 HTTPS。只有受信代理可以提供转发头，应用不能无条件相信客户端自己伪造的同名 Header。那次故障暴露的是我没有画清请求链，只看到配置能启动就停止了验证。
这类问题也说明 AI 诊断应该输出“假设 + 证据”，而不是一个听起来最可能的结论。看到无限重定向时，我现在会要求列出 Cloudflare SSL 模式、应用 URL 配置、转发协议头和缓存等候选原因，并给出区分它们的观察方法；如果只拿第一条建议继续改配置，很容易在没有新证据的情况下叠出第二个错误。
我现在怎样完成一次 AI 修改#
开始前，我会先写一句可验收的目标，例如“外部 HTTPS 请求经过 Tunnel 和 Nginx 后，WordPress 生成 HTTPS 链接，直接 HTTP 请求不会形成循环”，再说明允许修改的文件和不能触碰的范围。随后让 AI 先读现有配置、版本和日志，列出假设与计划；高风险任务不直接进入执行，普通任务则可以生成最小 diff。
修改后不问“你确定完成了吗”，而是运行与风险相称的检查。代码走测试、类型检查和 diff，代理配置先做语法检查再用 curl -I 观察重定向链，systemd unit 可以用 systemd-analyze verify 并真实停止进程，数据库变更则先备份、在副本或测试数据上演练。自动检查覆盖不了的部分，我会抽样读取关键代码，并记录仍未解释的假设。
如果第一次失败，下一轮必须带回新的日志、状态或复现结果，不能只把“还是不行”交给 AI 继续猜。连续两三轮都在修改同一位置而没有缩小原因时，就停止生成，回到最小复现或官方文档。AI 最容易制造的浪费不是一次错误答案，而是围绕错误前提快速生成很多看似合理的补丁。
哪些工作可以多交，哪些必须收紧#
语法查询、已知模式下的重复结构、测试数据和文档初稿，通常可以多委托，因为结果便于检查，失败也容易回滚。故障诊断可以让 AI 帮忙整理日志、建立候选原因和建议检查顺序，但根因必须由证据收敛，不能由语言流畅度决定。第一次学习新概念时，我会让它辅助解释和设计实验，却保留亲手运行、修改和观察失败的过程。
涉及密钥、权限、数据库、删除、付费 API、对外发布和生产配置时，边界会明显收紧。AI 可以提出方案和生成草稿，但最终目标、影响范围、备份、批准与回滚由我确认；秘密也不会为了获得更完整回答就随意贴进会发送到外部服务的上下文。这里不是模型能力够不够的问题，而是谁承担不可逆后果的问题。
半年下来，AI 确实替我省掉了大量搜索和重复输入，也让我更快接触陌生代码。它同时放大了一个旧习惯：太早把“输出出现”当成“任务完成”。我现在保留的规则不是凡事自己写，而是每次委托都留下可检查的目标、最小改动、外部证据和恢复路径。能生成只是起点，能解释关键行为、验证结果并在失败时退回来，才算真正把这次加速接住。