核心论点：AI 写 Dockerfile/K8s manifest 又快又好，写业务逻辑却经常翻车——这不是模型能力的差异，是任务类型的差异。理解"AI 擅长什么类型的问题"，比学会写 prompt 更重要。
一个现象：AI 写配置比写代码靠谱得多
如果你用过 AI 写 Dockerfile 和写业务逻辑，大概率有这种感觉：
- 让 AI “写一个多阶段构建的 Python Dockerfile”——一次过，直接能跑
- 让 AI “实现一个订单退款流程”——改了三四轮还有边界问题
这不是偶然。两类任务的底层结构完全不同。
参数化模板 vs 创造性逻辑
| 维度 | 参数化模板（适合 AI） | 创造性逻辑（需要人） |
|---|---|---|
| 任务特征 | 格式固定，参数变化 | 需求模糊，需要设计 |
| 最佳实践 | 有公认标准答案 | 依赖业务上下文 |
| 验证方式 | 语法校验 + dry-run 即可 | 需要业务逻辑测试 |
| 错误代价 | 配置错误→服务起不来（可快速发现） | 逻辑错误→错误计算（可能潜伏很久） |
| 典型场景 | Dockerfile、K8s manifest、监控规则、CI 配置、部署脚本 | 业务逻辑、异常处理、状态机、多实体交互 |
| AI 的完成质量 | 通常一次通过 | 经常需要多轮迭代修正 |
理解这个表格比背 20 条 prompt 技巧有用。因为当你遇到一个新任务时，你会先判断"这是参数化模板还是创造性逻辑"，然后决定要不要让 AI 做。
为什么 AI 写配置好
配置文件的三个特征，恰好是 AI 的优势区间：
特征一：格式固定
Dockerfile 的指令就那十几个（FROM、RUN、COPY、CMD……）、K8s manifest 的结构也是固定的（apiVersion、kind、metadata、spec）。AI 不需要"设计"，只需要"填充"。
我的项目： - FastAPI 服务，入口 src/main.py - Python 3.12 - 依赖在 requirements.txt 生成 Dockerfile，要求：slim 镜像、多阶段构建、非 root 用户。AI 输出的是一个模板填充结果——它读过成千上万个 Dockerfile，知道"Python 3.12"应该用python:3.12-slim、知道多阶段构建的第一阶段叫builder、知道非 root 用户要USER appuser。这些都是标准答案。
特征二：上下文独立
一个 Dockerfile 需要知道的上下文：项目语言版本、依赖文件位置、启动命令。就这些。不需要知道订单表有几个字段、缓存策略是 LRU 还是 TTL。
这意味着 AI 不会因为"不知道业务上下文"而写错。它需要的信息，你一句话就能说清楚。
特征三：验证成本低
docker build . # 能不能构建成功 kubectl --dry-run=client apply -f deploy.yaml # 语法对不对 curl http://localhost:8000/health # 服务能不能通这些验证都是秒级的，且不需要业务数据。AI 写错了，你在 CI 里 10 秒就能发现。不会像业务逻辑错误那样潜伏到生产环境。
为什么 AI 写业务代码容易翻车
业务代码的三个特征，恰好是 AI 的盲区：
盲区一：隐含假设
"实现一个退款功能"这句话在人看来包含很多隐含假设：退款只能退已支付的订单、退款金额不能超过实付金额、退款后要恢复库存、退款需要记录操作日志。AI 不知道这些——你没说，它就不做。它输出的"退款功能"可能只是一个 UPDATE 语句。
盲区二：上下文依赖链长
写一个服务端的函数，你需要知道：调用方的期望、依赖服务的接口、数据库的 schema、异常时上游怎么处理的。这些知识分布在 5~10 个文件中，AI 即使读完了全部文件，也很难同时理解这些文件之间的所有隐含约束。
盲区三：正确性难以自动验证
配置文件的验证是一行命令的事，业务代码的验证是全部测试用例的事。如果你的项目测试覆盖不全（大多数项目都是），那 AI 写的业务代码有没有 bug，上线之前没人知道。
所以：把任务拆成"模板部分"和"逻辑部分"
理解了这个边界之后，一个实用的策略：接到任务先问自己——这个任务里哪些是参数化模板、哪些是创造性逻辑？
任务：在 API 网关新增一个限流功能 参数化模板部分（让 AI 做）： - 生成 nginx/lua 限流配置格式 - 生成对应的 Prometheus 监控规则 - 生成部署 manifest（加 sidecar 或 middleware） 创造性逻辑部分（人做）： - 限流策略设计（按 IP？按用户？按 API？） - 限流阈值定多少（需要业务数据和压测） - 被限流时的降级行为（返回什么给用户）AI 做上半部分，人做下半部分。两个部分合起来，比一个人全做快得多，也比 AI 全做安全得多。
一条原则：用 AI 省查文档的时间，不省思考的时间
AI 最擅长的事：把"查文档→复制→改参数"这个流程压缩到一句话。
人不应该省的事：判断、设计、决策、验收。
让 AI 做："帮我写一个 Dockerfile" 你自己做："这个服务该 alpine 还是 slim？端口映射对吗？健康检查路径对吗？" 让 AI 做："生成订单查询 API" 你自己做："查询条件有哪些？分页怎么设计？权限怎么控制？"AI 省了写格式的时间，你省下时间去做格式之外的判断。这才是 AI 编码的正确姿势——不是替代你，而是让你把精力分配得更合理。
核心要点
- AI 写配置好不是因为模型强，是因为配置文件是参数化模板。格式固定、上下文独立、验证成本低——这三个特征决定了 AI 的高成功率。
- AI 写业务代码容易翻车不是因为代码难，是因为业务代码充满隐含假设。你不说出来，AI 就不可能知道。而所有隐含假设都说清楚，工作量约等于你自己写。
- 接到任务先拆解：哪些是模板部分（交 AI），哪些是逻辑部分（自己做）。模板部分 AI 做得又快又好，逻辑部分人做得更可靠。两者不冲突。
- 验证成本决定 AI 的安全边界。能秒级验证的任务（配置文件、格式化代码、正则），AI 犯错无伤大雅；需要长时间验证的任务（业务逻辑、状态机、数据一致性），AI 犯错成本高，人必须把关。
- "AI 编码"的正确姿势不是让 AI 替你做，而是让 AI 帮你做完模板部分，你集中精力做判断部分。省查文档的时间，不省思考的时间。
