GPTUPCN｜ChatGPT Plus、Pro、Codex 中文技术站
中文 AI 工程、Codex 工作流与可验证开发实践持续更新。
很多团队把 AI 编程效果不稳定归因于模型能力，其实更常见的原因是：任务边界、仓库结构和验证条件没有被清楚地交给 Agent。无论使用 ChatGPT Plus、ChatGPT Pro 还是 Codex，真正决定交付质量的往往是上下文工程，而不是一次塞入尽可能多的文件。
本文给出一套可复用的 Context Pack 方法：用最少但足够的信息，让 Codex 快速理解任务，并且能够验证结果。
一、Context Pack 解决什么问题
AI Agent 进入陌生仓库时，通常会遇到四类不确定性：
- 不知道真正需要修改的范围；
- 不知道项目的启动、测试和构建方式；
- 不知道哪些行为属于兼容性约束；
- 不知道什么结果才算完成。
如果只是把整个仓库、长聊天记录和大量日志一次性塞入上下文，噪声会掩盖关键证据，也会增加错误关联。更有效的方法是先建立一个任务合同，再按需加载证据。
二、第一层：任务合同
任务合同最好控制在十行左右，并回答五个问题：
- 目标：最终需要改变什么；
- 非目标：明确哪些内容不动；
- 输入：可依赖的文件、接口和环境；
- 约束：兼容性、安全性和性能边界；
- 验收：用什么命令或现象判定完成。
例如：
goal: 修复上传接口在重复请求时创建多条记录的问题
non_goals:
- 不修改前端交互
- 不更换数据库
scope:
- src/api/upload.ts
- src/services/file-service.ts
constraints:
- 保持现有响应结构
- 不记录用户原始文件内容
validation:
- npm test -- upload
- npm run typecheck
这个结构同时适合 Codex、人工代码评审和后续复盘。
三、第二层：仓库地图
仓库地图不是完整目录树，而是与任务相关的导航：
request
-> src/api/upload.ts
-> src/services/file-service.ts
-> src/repositories/file-repository.ts
-> tests/upload.spec.ts
每个节点补充一句职责说明即可。这样 Agent 可以先形成调用链，再决定是否读取更深层文件。对于大型仓库，这比直接传入几十个文件更稳定。
四、第三层：证据包
高价值证据通常包括：
- 能复现问题的最短步骤；
- 失败测试或明确的错误日志；
- 相关接口契约；
- 最近一次正常版本与当前版本的差异；
- 安全或合规限制。
日志需要裁剪，只保留时间、请求标识、错误类型和关键调用栈。令牌、Cookie、API Key、用户内容等敏感信息必须先脱敏。
五、采用渐进式加载
Context Pack 不应该一次性固定。更合理的是三阶段加载：
阶段 A：定位
只提供任务合同、仓库地图和失败现象，让 Codex 判断最可能的修改点。
阶段 B：实现
根据定位结果补充相关文件、测试和接口定义，不加载无关模块。
阶段 C：验证
提供构建命令、测试命令和验收清单，要求逐项报告结果。
这种方式能减少上下文漂移，也更容易发现 Agent 的错误假设。
六、把“必须验证”写进上下文
一个可执行的任务至少应包含三层验证：
- 静态验证：格式化、Lint、类型检查；
- 行为验证：单元测试、集成测试或最短复现；
- 差异验证：确认只修改了授权范围，没有意外改变接口。
如果某项验证无法执行，Agent 应说明原因、影响和替代证据，而不是把“代码看起来正确”当作完成。
七、为 ChatGPT Plus、Pro 与 Codex 建立同一套工作流
不同套餐可能影响额度和使用频率，但工程流程应保持一致：
- 需求先结构化；
- 上下文按证据加载；
- 写操作限制范围；
- 高风险步骤保留人工确认；
- 结果必须通过自动化验证；
- 交付时记录修改、测试和已知限制。
这样即使模型或套餐变化，团队仍能复用稳定的开发协议。
八、可直接复用的模板
## 任务目标
一句话说明预期结果。
非目标
列出本次不处理的内容。
相关路径
只列最相关的入口、实现、测试。
已知证据
复现步骤、错误信息、接口契约。
安全约束
禁止暴露密钥、隐私和生产数据。
验证命令
格式化、类型检查、测试、构建。
完成定义
哪些条件全部满足后才算完成。
结语
高质量 AI 编程不是“提示词越长越好”，而是把目标、证据、边界和验证组织成可执行的协议。先做一个最小 Context Pack，再让 Agent 按需读取上下文，通常比一次性加载整个仓库更快、更稳，也更容易审计。
更多中文 AI 工程与 Codex 实践：访问 GPTUPCN。
本文为独立技术内容，与 OpenAI 无隶属或背书关系。
Top comments (0)