生成代码只是 AI 编程流程中最容易的一步。真正困难的是：如何保证修改范围可控、测试结果可信、失败后能够恢复，并且不让密钥、生产数据或无关文件进入模型上下文。
ChatGPT Plus、ChatGPT Pro 与 Codex 经常被开发团队同时讨论，但模型能力并不能代替工程约束。无论使用哪个入口，可靠交付都应建立在任务契约、最小权限、自动验证和审计记录之上。
一、先把自然语言需求变成任务契约
“优化接口”“修复性能问题”这类描述对人和 Agent 都过于模糊。开始执行前，可以把需求整理成结构化任务：
task_id: user-login-timeout
goal: 修复登录接口超时后的错误处理
allowed_paths:
- src/auth/
- tests/auth/
forbidden_changes:
- 数据库结构
- 公共 API 字段
checks:
- unit_test
- api_test
- typecheck
- build
human_approval:
- 修改依赖版本
- 访问网络
- 发布到生产环境
任务契约至少说明目标、允许修改的范围、禁止变化的接口、验收命令和需要人工确认的动作。ChatGPT 可以用于澄清需求与比较方案，Codex 可以在明确边界内读取、修改和验证代码，但完成标准必须由工程流程定义。
二、使用分层上下文，而不是一次加载整个仓库
上下文越多不一定越准确。把整个仓库、全部日志和历史文档一次性交给模型，会增加噪声，也可能暴露与任务无关的数据。
更稳妥的 context pack 可以分为三层：
- 任务层：目标、范围、限制、完成定义；
- 代码层：入口文件、相关模块、接口、测试与构建命令；
- 证据层：错误日志、复现步骤、基准数据、最终 diff。
Agent 进入新阶段时再获取对应信息。例如，规划阶段只读取目录树和关键接口；实现阶段只开放目标模块；验证阶段再提供测试命令和失败日志。这样既能降低上下文污染，也能减少敏感信息进入提示词。
三、权限必须按动作拆分
读取代码、修改文件、执行命令、访问网络和发布版本是不同风险等级的动作。不要因为模型更强，就一次性开放全部权限。
建议采用以下默认策略：
- 初始阶段只允许读取指定仓库；
- 方案确认后开放目标目录写入；
- 测试与构建命令使用白名单；
- 网络访问、密钥、生产数据单独授权；
- 发布、删除和权限变更必须人工确认；
- 禁止读取与当前任务无关的凭据目录。
即使团队使用 ChatGPT Pro 或更高强度的推理配置，最小权限原则仍然不应改变。
四、把执行过程设计成显式状态机
一个可恢复的 AI 编程任务可以拆成以下状态：
INSPECT -> PLAN -> IMPLEMENT -> VERIFY -> REVIEW -> DONE
| | | |
v v v v
PAUSED REPLAN ROLLBACK HUMAN_CHECK
每一步都应记录输入摘要、使用工具、修改文件、输出哈希、耗时和错误分类。网络超时可以有限重试；权限不足需要人工处理；测试失败则停止进入下一阶段。
这种设计的关键不是“让 Agent 自动做更多”，而是让它在任何阶段都能安全暂停，并从最近一次已验证状态继续。
五、修改应保持小而可审查
一次同时修改业务逻辑、数据库结构、依赖版本和部署配置，会让评审者很难判断风险来源。更好的顺序是：
- 添加或修正能够复现问题的测试；
- 完成最小代码修改；
- 运行针对性测试；
- 检查 diff 是否越界；
- 执行静态检查与完整构建；
- 生成变更说明和回滚步骤。
如果变更无法在一个屏幕内解释清楚，通常值得继续拆分。小差异不仅方便人工评审，也有利于模型在失败时定位原因。
六、测试必须覆盖失败路径
AI 生成的实现往往能处理理想输入，却容易忽略边界场景。至少应检查：
- 空值、非法类型和超长输入；
- 网络超时、限流和依赖服务不可用；
- 重复请求产生的副作用；
- 身份验证和权限边界；
- 旧版本读取新数据时的兼容性；
- 日志是否包含密钥或个人信息；
- 回滚后数据是否保持一致。
“代码已经生成”不是完成信号；测试、构建和差异审查通过，才是可以进入下一阶段的证据。
七、所有外部写操作都要考虑幂等
当 Agent 可以创建工单、写数据库或调用部署接口时，重试可能产生重复副作用。可以为每个写操作生成幂等键：
idempotency_key = task_id + step_id + arguments_hash
服务端再次收到相同键时返回已有结果，而不是重新创建资源。文件修改则可以记录目标文件哈希；如果执行前文件已经变化，就停止并重新检查上下文。
八、建立可观测性与质量指标
为了判断 AI 编程是否真正提高交付效率，建议持续记录：
- 首次测试通过率；
- 人工修改比例；
- 评审发现的缺陷数；
- 越权修改和回滚次数；
- 从需求到可合并代码的时间；
- 每类任务的调用与复核成本。
这些指标比“生成了多少行代码”更有意义。团队可以据此判断哪些任务适合用 ChatGPT Plus 辅助分析，哪些复杂任务需要 ChatGPT Pro 提供更长的推理过程，哪些仓库操作适合交给 Codex 执行。
九、一个可落地的流水线示例
实际项目可以把流程固化为 CI 任务：
读取任务契约
-> 生成变更计划
-> 人工确认范围
-> 创建临时分支
-> 执行最小修改
-> 运行 lint / typecheck / test
-> 检查 diff 与敏感信息
-> 生成变更摘要
-> 人工合并或回滚
高风险动作始终保留人工闸门；低风险、可逆、可验证的步骤可以自动化。随着模型更新，流水线不需要推倒重来，只需调整任务分类和权限策略。
结语
Codex 与 ChatGPT Plus、Pro 的价值，不在于替代完整的软件工程流程，而在于缩短分析、实现和验证之间的距离。把任务契约、分层上下文、最小权限、自动测试、幂等设计和可恢复状态组合起来，才能让 AI 编程从一次性演示变成稳定的团队能力。
更多模型、RAG、Agent 与工程化实践，可查看 AI 工程资料索引。
本文由 AI 辅助整理，经人工复核后发布。
