【Codex】Part 13 — AI-Native Software Development

第十三章 AI Native 软件开发

AI Native 开发不是“让 AI 写完所有代码”，而是把智能体（Agent）纳入工程流程：人定义目标、边界和验收标准，Agent 执行可委托的工作，测试与审查为结果提供可核查证据。

本章讨论如何把 Codex 从一次性代码助手变成可配置、可复用、可验证的工程能力。重点不是预测未来，而是建立今天可以落地的工作方法。

13.1 从代码补全到代理化开发

AI 编程工具的变化可以概括为四层能力。它们不是互相替代的“时代”，而是可以同时使用的不同工作方式。

13.1.1 代码补全（Code Completion）

代码补全根据当前文件和光标附近的上下文生成代码片段。它适合样板代码和局部实现，但通常仍由开发者逐段选择、修改和组合。

例如，视觉算法工程师可以让工具补全 COCO 标注解析、图像归一化或数据增强函数。开发者仍要确认类别映射、坐标格式和边界条件是否正确。

13.1.2 代理式编码（Agentic Coding）

编码智能体可以搜索仓库、读取多个文件、修改代码、运行命令并检查结果。任务单位由“补全一个函数”扩展为“完成一个可验证的改动”。

例如，修复 YOLO 训练中类别索引越界时，Codex 可以追踪数据加载器、标注检查和训练入口，修改实现后运行相关测试。它是否完成任务，取决于错误能否稳定复现并在修复后消失，而不是代码是否看起来合理。

13.1.3 异步委托（Asynchronous Delegation）

对于边界清晰的长任务，可以先写明结果、约束和验证方式，再让 Codex 持续推进。用户可以在同一对话中补充信息、调整约束或查看状态；任务不会因此获得更大的文件、网络或命令权限。

例如，让 Codex 整理一次目标检测实验时，应明确基线权重、数据划分、唯一变量、评估命令和交付物。仅启动训练不算完成；至少要留下可复现命令、运行状态和正式评估结果。

同步委托：交给别人做，然后站着等结果。
异步委托：交给别人做，自己先去干别的，结果回来再处理。

13.1.4 多智能体协作（Multi-Agent Collaboration）

Codex 可以把独立工作委托给子代理（Subagent），再由主线程汇总结果。它适合代码搜索、测试、日志分析和多模块审查等可并行任务。

例如，一次分割模型上线审查可以拆成三部分：

• 一个子代理核对训练和验证数据是否泄漏；
• 一个子代理检查平均交并比（mean Intersection over Union，mIoU）、类别 IoU 和边界指标的实现；
• 一个子代理检查导出、量化和设备端算子兼容性。

并行写同一批文件容易产生冲突。写密集型任务应划清目录边界，必要时使用 Git 工作树（Git Worktree）隔离修改。

13.2 AI Native 的核心闭环

AI Native 的重点不是“AI 参与了多少”，而是需求能否转化为可验证交付。一个稳健的闭环包含七步：

一次任务至少应回答四个问题。下表中的平均精度均值（mean Average Precision，mAP）和小目标平均精度（A P S AP_SAPS​）只是示例指标：

若任务复杂或方案仍有分歧，先进入计划模式（Plan Mode）；若结果和完成条件已经清晰，可直接执行。高风险变更仍应在实施前保留人工决策点。

13.3 把信息放在正确的位置

提示词、AGENTS.md、Skills、MCP 和配置文件解决的是不同问题。混在一起会造成上下文膨胀，也会让权限边界变得含糊。

13.3.1AGENTS.md：持久项目约定

AGENTS.md是面向 Agent 的开放格式说明文件。Codex 启动任务时会组合全局、仓库和子目录规则；越靠近当前工作目录的规则优先级越高。

它应保持简短、准确并可执行。下面只展示结构，实际使用时必须换成当前仓库已经验证的路径和命令：

# Experiment rules - Baseline: `configs/yolo11n_coco.yaml` - Keep `data/coco.yaml` and the validation split unchanged. - Change one declared variable per experiment. - Evaluation command: `<verified project command>`. - Report COCO AP (IoU 0.50:0.95), AP_S, latency, command, checkpoint, and result path. - Do not overwrite existing runs or weights.

这里保存的是长期规则。某次实验的学习率、假设和 GPU 选择仍应写在任务提示中。

13.3.2 Skill：可复用的任务方法

技能（Skill）是一个包含SKILL.md的目录，还可以包含脚本、参考资料和资源。Codex 先读取技能名称与描述，任务匹配后再加载完整指令，这种方式称为渐进式披露（Progressive Disclosure）。

适合封装为 Skill 的视觉流程包括：

• 检查 YOLO 数据集中的空标签、孤立标签和损坏图像；
• 按固定指标审查分类模型的混淆矩阵；
• 导出分割模型并执行设备端回归测试；
• 汇总训练日志、权重、命令和评估结果。

Skill 不是“永远正确的文档”。数据布局、CLI 参数或设备环境变化后，它同样可能过时。每个 Skill 都应有明确范围、输入输出、测试样例和维护责任。

13.3.3 MCP：连接外部上下文

模型上下文协议（Model Context Protocol，MCP）是连接 Agent 与外部工具或数据源的开放标准。代码库之外的 Issue、文档、监控指标或实验平台状态适合通过 MCP 获取，而不是反复复制进提示词。

接入外部系统也意味着新增权限。只配置实际需要的服务，并为写操作、生产环境和敏感数据设置更严格的审批与访问边界。

13.3.4 定时任务：稳定后再自动化

定时任务可以按计划在后台执行，并可调用 Skill。在该功能对账户或工作区可用时，可通过 ChatGPT Web 或桌面应用创建和管理；CLI 与 IDE 扩展不提供 Scheduled 管理界面。Web 任务不能直接访问本机目录；桌面应用中的本地任务要求机器保持开机、应用运行且项目路径可用。Git 仓库可选择在主工作区或独立工作树中运行。

一个合适的例子是每天汇总训练状态：读取日志与结果文件，报告进度、最新指标、异常和产物路径。自动修改训练配置或重启生产服务则需要更严格的权限和人工确认。

13.4 四种常用 Agent 工作流

13.4.1 Explore → Plan → Execute → Verify

适合复杂功能、陌生仓库和大范围重构。对数据库迁移、公开 API、训练数据变更等高风险操作，计划应先经过人工确认。

13.4.2 Review → Repair → Validate

适合代码审查、测试修复和文档事实核查。循环应由完成条件和风险决定，而不是机械限定固定次数；同一阻塞原因反复出现时，应停止盲目重试并升级处理。

13.4.3 Manager → Workers → Integrate

适合边界清晰、可独立推进的子任务。主代理必须说明拆分方式、共享事实、等待条件和汇总格式。多代理会增加 Token 消耗与协调成本，不应为了“看起来先进”而使用。

13.4.4 Monitor → Diagnose → Report

适合训练监控、CI 失败归因和例行检查。安全的默认行为是先读取状态、诊断原因并报告；只有在操作可逆、边界明确且权限允许时，才自动修复。

对于长时间训练，RUNNING不是充分证据。报告至少应包含进程或任务标识、日志位置、最新进度、最新指标、异常状态和产物路径；能可靠估算时再给出预计完成时间。

13.5 视觉算法工程师的日常如何变化

Agent 可以接管大量机械执行，但不会自动替团队决定什么才是正确实验。

三个常见例子：

1. 目标检测（Object Detection）：不要只要求“提高 mAP”。应声明基线和唯一变量，同时查看 COCO AP（IoU 0.50:0.95）、不同尺度 AP、逐类召回率、速度和错误样本。
2. 图像分类（Image Classification）：总体 Top-1 准确率（Top-1 Accuracy）提升可能掩盖少数类退化。让 Agent 同时输出混淆矩阵（Confusion Matrix）、逐类召回率和高置信错误样本。
3. 语义分割（Semantic Segmentation）：mIoU 相近不代表边界质量相同。除类别 IoU 外，可按项目需要检查边界指标、细小区域和实际部署图像。

开发者的核心能力因此从“快速写出代码”扩展为：问题建模、实验设计、上下文组织、代码审查、评估设计、安全判断和结果负责。

13.6 一次可复现的 YOLO/COCO 委托

下面是一份比“帮我优化 YOLO”更可靠的任务描述：

目标： 分析当前模型在 COCO val2017 小目标上的漏检，并实现一个最小改动进行验证。 上下文： - 基线配置：`configs/yolo11n_coco.yaml` - 基线权重：`weights/baseline.pt` - 数据配置：`data/coco.yaml` - 评估入口：`<填写当前仓库已验证的命令>` 约束： - 保持训练集、验证集、输入尺寸和预处理不变。 - 本轮只允许修改一个已声明变量。 - 不覆盖已有权重和结果目录。 - 不把短跑指标当作最终结论。 完成条件： - 说明假设与代码差异。 - 单元测试和静态检查通过。 - 记录完整训练、评估命令及环境信息。 - 输出 COCO AP（IoU 0.50:0.95）、$AP_S$、逐类召回率和推理延迟。 - 给出权重、日志、结果表和失败样本路径。 - 未达到门槛时保留结果，但不推广该方案。

这个提示把活动改写成了结果，把“跑一次实验”改写成了“提供可以复核的证据”。Codex 可以帮助执行流程，但模型是否值得采用，仍由预先声明的门槛决定。

13.7 团队落地：先稳定，再规模化

不必按某个工具顺序完成转型。更稳妥的方式是按工程成熟度推进：

团队应度量真实结果，而不是统计生成了多少行代码。可观察指标包括：

• 一次通过率与人工返工次数；
• 从任务创建到通过验收的周期；
• 回归缺陷和回滚次数；
• 人工审查时间与 Agent 运行成本；
• 实验复现率和产物完整率；
• 不同任务类型的成功率。

这些指标用于改进工作流，不应用来鼓励跳过验证或制造表面产出。

13.8 安全与质量边界

13.8.1 权限不等于能力

沙箱（Sandbox）决定 Agent 能访问哪些资源，审批策略（Approval Policy）决定哪些操作需要人工允许。给出长期目标、启动子代理或创建定时任务，都不会自动扩大权限。

默认从最小权限开始。只有在任务确实需要、目标仓库可信且风险清楚时，才扩大文件、命令或网络访问范围。

13.8.2 测试通过不等于正确

测试只能证明被覆盖的行为。视觉算法还要检查数据泄漏、评估实现、指标切片、模型来源、预处理一致性和设备端表现。高风险改动需要人工审查，不能仅凭 Agent 自评或绿色 CI 合并。

13.8.3 文档和 Skill 也会过时

AGENTS.md、Skill、脚本与代码一样需要版本管理。修改架构、命令、数据布局或部署环境时，应同步检查相关说明；不再可靠的 Skill 应禁用、修订或移除。

13.8.4 并行不一定更快

子代理适合独立、读密集的任务。多个 Agent 同时修改同一目录，会增加冲突和汇总成本。先拆清接口，再决定是否并行。

13.9 来自 OpenAI 实践的可核查事实

OpenAI 的 Codex 最佳实践文档指出，其内部所有 Pull Request 都会经过 Codex 审查。这说明 AI 审查可以成为工程流水线的一部分，但不意味着代码由 Codex 全自动生成，也不取消人工对合并结果的责任。

更值得复用的不是某个夸张生产力数字，而是以下方法：

• 给任务提供目标、上下文、约束和完成条件；
• 用AGENTS.md保存持久规则；
• 用 Skill 封装已经稳定的重复流程；
• 用 MCP 获取仓库外的实时上下文；
• 要求测试、验证和差异审查；
• 只把可靠流程交给定时任务；
• 对并行写任务使用清晰边界或独立工作树。

本章要点

• AI Native 开发的核心是可验证委托，不是无人负责的自动生成。
• Codex 同时支持交互式工作、长任务、定时任务和子代理工作流；应按任务形态选择，而不是把它们理解成线性替代关系。
• 提示词描述本次任务，AGENTS.md保存持久约定，Skill 封装重复方法，MCP 连接外部系统，配置文件管理运行边界。
• 视觉算法任务应固定基线、声明唯一变量、设置验收门槛，并保留命令、日志、指标和模型产物。
• 人仍然负责需求、架构、实验设计、风险判断和最终验收。
• 先把流程人工跑稳，再考虑并行化和自动化。

参考资料

• Codex best practices
• Custom instructions with AGENTS.md
• Build skills
• Subagents
• Long-running work
• Scheduled tasks
• Sandbox and permissions