全部 · 2026-07-24

这篇文章把 OpenAI 从 GPT-4.1 到 GPT-5.6 的提示指南串起来，讲了一条挺实在的工程转向：以前是把八步工作流硬编码进系统提示词，现在模型能看懂更长上下文了，再死板规定路线反而拖后腿。GPT-5.6 的建议不是让人放弃控制，而是把约束从“规定每一步怎么走”挪到“定义交付成果、验证证据和权限边界”上。 作者在翻译系统里踩过坑，早期写了一大堆分段拆分、异常重试的防御代码，后来改成只给完成条件（比如无中文残留、Markdown 完整）、验证证据（Agent 自己跑正则检查脚本的输出）和权限边界（高风险操作必须人工审批），反而更稳。这个经验跟指南里的 lean-prompt 消融测试对得上：删一段指令，跑测试集，指标不跌才敢真删。 不过文章没给出具体项目的消融测试数据，也没说这套做法在哪些场景下会翻车。模型自主规划路线听着省事，但如果完成条件写得模糊，Agent 可能用更绕的方式达到表面合格的结果。另外，权限边界的配置成本不低，小团队能不能吃得消，正文没展开。

这篇文章的核心判断很直接：别等模型完美再上线，先靠运行环境的弹性兜底。美军2026年AI备忘录要求新模型公开发布后三十天内必须达到可部署状态，理由是等待的延迟本身比模型不够对齐的风险更大。文章没提具体模型名称或性能分数，重点全在部署护栏上——先限制智能体只能读不能写，在关键决策点挂起等人工确认，用执行凭证和旁路日志验证行为而不是听模型自我汇报，授权做成动态缩放随时能回滚。 我会先打个折。正文没披露这套方法在真实防务场景里的误判率、人工介入频率，也没说三十天部署目标是否已经实际执行过。它更像一套原则性框架，而不是有数据支撑的案例复盘。不过对企业团队来说，思路是可取的：把精力从追求模型满分转移到设计防御性运行环境上，让错误发生时影响范围可控、回退成本低。 还缺什么？缺具体工具链说明。文章提到沙盒、旁路审计、MCP反向通道，但没展开这些组件怎么拼在一起，也没给出可复用的开源方案或配置模板。如果团队想照着做，还得自己摸索工程细节。