结论

你现在采用的更像是**“AI 增强的人类开发流程”**：把传统的产品经理、架构师、开发、测试、Reviewer 等角色，分别交给不同模型，但任务仍然沿着“需求 → 设计 → 开发 → 测试 → 审查”的人工组织方式依次流转。

真正的 AI 原生开发，不是让多个 AI 扮演不同的人，而是重新设计整个生产系统：

人负责定义目标、边界、优先级和验收标准；仓库负责保存上下文和规则；Agent 负责探索、实施和修复；测试、CI、评估和独立审查负责闭环验证。

OpenAI 将这种变化概括为“人类引导、Agent 执行”：工程师的主要工作不再是亲自写代码，而是设计环境、明确意图、提供工具并建立反馈回路。其重点不是“代码必须全部由 AI 写”，而是工程纪律从具体编码转移到了脚手架、约束和控制系统。

一、人类原生与 AI 原生的根本区别

维度	人类原生开发	AI 原生开发
基本组织单位	人、岗位、部门	目标、任务、验收条件
工作分配	固定角色接力	根据风险和任务状态动态路由
上下文位置	人脑、会议、聊天、外部文档	仓库内可检索、可版本控制的资料
开发方式	人写代码，工具辅助	Agent 在隔离环境中端到端执行
质量控制	人工测试、人工 Review	测试、lint、类型、E2E、评估、独立审查共同闭环
协作方式	串行交接，等待上一角色完成	依赖明确后并行执行
项目管理	管理人和开发会话	管理任务状态、风险和异常
经验积累	人记住“以后注意”	错误沉淀为测试、规则、文档、Skill 或工具
优化目标	每个人产出多少	每分钟人类注意力产生多少可靠结果

因此，“产品 Agent → 开发 Agent → 测试 Agent → Review Agent”仍然可能是人类组织结构的复制。AI 原生更关注的是：任务当前需要什么能力、下一步状态是什么、如何自动判断完成，而不是它对应传统公司的哪个岗位。

二、AI 原生开发的核心闭环

业务目标
   ↓
结构化任务契约
   ↓
风险与复杂度路由
   ↓
独立工作区 / Worktree
   ↓
Agent 探索、规划、实现
   ↓
自动测试 + UI 验证 + 独立审查
   ↓
通过则 PR / 发布；失败则继续修复
   ↓
线上反馈、缺陷和人工意见
   ↓
更新测试、规则、文档、工具和 Skill

关键是最后一环：同一种错误第二次出现时，不应该依靠你再次提醒模型，而应该让系统本身更不容易犯错。

例如：

• Agent 不知道怎么启动项目：补充 bootstrap 脚本和文档。
• Agent 总是破坏某层依赖：增加架构 lint。
• Agent 总是漏掉某种边界条件：增加自动化测试。
• Agent 经常误解业务规则：更新产品规范和示例。
• Agent Review 抓不到某类缺陷：将真实缺陷转化为回归测试或评估集。

OpenAI 的实践是把 AGENTS.md 当成目录，而不是把所有规则塞进去；详细架构、产品规范、执行计划和技术债都放在仓库内，并通过 CI 检查资料是否过期。其原则是：Agent 运行时无法访问的信息，实际上就等于不存在。

三、对你现在流程最重要的改造

1. 项目按产品或代码库划分，不按角色或 Lane 划分

对你而言，通常应该是：

一个软件产品或一个主要代码库，对应一个 Codex Project；Mini Lane A、Standard Lane A、Lane C 是任务执行策略，不是三个独立项目。

只有以下情况才适合拆成不同 Project：

• 完全不同的代码库和业务目标；
• 不同权限、密钥或安全边界；
• 上下文长期互不相关；
• 技术栈、部署环境和规范完全不同。

否则，拆成三个 Project 会造成架构规则、历史决策和业务上下文重复，后续容易漂移。更合理的是在同一仓库里维护不同 Lane 的执行政策。

2. 不要固定所有任务都走“编排 → 开发 → 审查”

你目前的“Terra 编排 → Luna Max 开发 → Terra/Sora 审查”可以保留，但它应该是Standard Lane 的一种策略，而不是所有任务的默认流程。

按你目前的命名，可以这样调整：

Lane	适用任务	AI 原生执行方式
Mini Lane A	局部、可逆、影响范围小、验收明确	一个 Agent 直接探索、修改、测试、自审；验证通过即可提交，不单独安排规划 Agent
Standard Lane A	跨多个文件或模块，但边界清楚	Agent 先生成简短计划，再实施；新上下文 Reviewer 根据任务契约、Diff 和测试结果独立审查
Lane C	架构调整、数据库迁移、权限、安全、支付、不可逆修改、需求高度模糊	两个独立方案或探索分支，形成 ADR/技术决策；分阶段实施，必须有回滚方案和人工决策门

这里最关键的是：**模型不应该永久绑定岗位，而应该根据任务风险动态调用。**同一个强模型可以完成规划、编码和修复；Reviewer 的独立性主要来自“新上下文、不同审查目标和明确检查表”，而不只是换一个模型名称。

3. 从“监督会话”改为“监督任务状态”

人类原生的操作是：

打开三个会话
→ 给每个 Agent 分配事情
→ 不断查看进度
→ 手动转发上下文
→ 发现停住后重新提醒

AI 原生的操作是：

建立一个任务
→ 系统创建独立工作区
→ Agent 自动执行和重试
→ 测试和 Reviewer 给出反馈
→ Agent 自动修复
→ 只有需要判断时才交给人

OpenAI 的 Symphony 实践就是把 Issue Tracker 变成 Agent 的控制面：任务对应独立工作区，任务状态决定 Agent 是否执行、暂停或继续，人的注意力集中在结果和例外，而不是同时盯着多个会话。

你现在不必立刻建设 Symphony 级别的自动化，但设计方向应该是：任务是持久对象，会话只是临时执行实例。

四、一个适合你的仓库结构

可以逐步改造成：

project/
├─ AGENTS.md
├─ ARCHITECTURE.md
├─ WORKFLOW.md
├─ docs/
│  ├─ product/
│  │  ├─ product-principles.md
│  │  └─ feature-specs/
│  ├─ architecture/
│  │  ├─ modules.md
│  │  └─ dependency-rules.md
│  ├─ decisions/
│  │  └─ ADR-0001-xxx.md
│  ├─ plans/
│  │  ├─ active/
│  │  └─ completed/
│  ├─ runbooks/
│  └─ known-issues.md
├─ skills/
│  ├─ implement-feature/
│  ├─ investigate-bug/
│  ├─ review-change/
│  └─ release/
├─ scripts/
│  ├─ bootstrap
│  ├─ verify
│  ├─ smoke
│  └─ e2e
├─ tests/
└─ src/

其中：

• AGENTS.md：只写入口、关键命令、核心禁区以及资料索引，不写成长篇百科。
• ARCHITECTURE.md：模块边界、依赖方向和核心不变量。
• WORKFLOW.md：Mini A、Standard A、Lane C 的路由条件、执行步骤、停止条件和人工审批规则。
• docs/product/：业务规则和用户行为，而不只是技术说明。
• docs/decisions/：为什么这样设计，避免 Agent 反复推翻历史决定。
• scripts/verify：一个命令执行格式、lint、类型检查、单测和必要的集成测试。
• skills/：可重复执行的具体流程，而不是每次重新写长 Prompt。

架构约束最好尽量机械执行，而不是只写在说明中。例如限制模块依赖方向、文件大小、日志格式、Schema 命名和敏感操作。OpenAI 的实践同样强调“强制不变量，而不是微观管理实现方式”，通过自定义 lint 和结构测试防止高速开发导致架构漂移。

五、任务应该从“需求描述”升级为“任务契约”

一个 AI 原生任务至少包含：

## Outcome
用户或业务最终应该得到什么结果。

## Current behavior
当前行为、错误现象、截图、日志或复现路径。

## Acceptance criteria
可以客观判断完成的条件。

## Constraints
不能破坏什么，必须兼容什么。

## Non-goals
本任务明确不处理什么。

## Risk
Mini A / Standard A / Lane C，以及判定原因。

## Verification
必须执行的测试、页面操作、接口检查或数据核对。

## Required evidence
测试结果、截图、录屏、日志、迁移报告或性能数据。

## Escalation conditions
什么情况下必须停止并交给人判断。

人不需要把技术步骤全部写清楚。你主要填写 Outcome、业务约束和验收标准；Agent 可以在探索代码后补充技术计划、验证命令和风险分析。

六、你应该优化的不是 Token，而是“可靠结果 / 人类注意力”

建议长期观察以下指标：

指标	说明
无人工干预完成率	任务从开始到 PR 是否需要你中途提醒
首次验收通过率	第一次交付是否满足验收条件
人工处理分钟数	每个已合并任务消耗你多少时间
返工次数	Agent 因误解、测试失败或 Review 被打回多少次
逃逸缺陷率	合并后才暴露的问题比例
单个有效变更成本	模型成本与最终被接受成果的关系
重复错误率	同类错误是否不断出现
自动验证覆盖率	有多少验收标准可以由系统自动判断

OpenAI 在扩大并行 Agent 数量后发现，真正的瓶颈变成了人类注意力和会话切换，而不是 Agent 产能本身。

七、你的合理迁移顺序

不要一开始就建设庞大的多 Agent 自动调度系统。对你当前阶段，优先级应当是：

1. 先让仓库可被 Agent 理解：补齐 AGENTS.md、架构、业务规则、启动和验证命令。
2. 建立一键验证：至少做到 Agent 修改后能自动运行 lint、类型、单测和 Smoke Test。
3. 建立任务契约和 Lane 路由：不同风险走不同流程，不再所有任务都三段式接力。
4. 使用独立 Worktree 和新上下文 Review：允许多个任务并行，同时避免 Reviewer 被实现过程影响。Codex 当前已支持通过独立 worktree 让多个 Agent 在同一仓库并行工作。
5. 再做 Issue 驱动和自动重试：等前面的成功率稳定后，再让 Agent 自动读取任务、更新状态、修复 CI 和创建后续任务。
6. 最后才考虑低风险自动合并和自我改进：将运行轨迹、人工反馈和线上缺陷转化为可重复运行的评估与规则。OpenAI 的 Agent 改进闭环也是将 traces、反馈和 evals 转化为下一轮 harness 修改，而不是让反馈停留在聊天记录里。

对你最直接的结论是：项目按产品或代码库建立，Lane 按任务风险建立；不要建立一套固定的 AI“公司岗位”，而要建立一个能够读取目标、选择流程、独立执行、自动验证、失败后自我加固的工程系统。这才是从“AI 帮人开发”走向“人管理 AI 软件生产系统”。