# 结论

建议采用 14 个逻辑角色、至少 10 个实际 Agent 席位：

• 施工：前端 3、后端 2、数据 1、发布 1
• 验收：自动验收 1、深验 2
• 调度治理：交付编排 1、架构风险 1
• 现有 一号/阿仁/波波/小冈/冈子 保留，但必须拆清权限与泳道；小冈 不得继续承担唯一验收、发布和热修单点职责。
• 同一仓库同时施工建议红线为 8 个 Agent；超过 8 个，新增产能会被合并冲突、环境争用和返工吞掉。依据是当前范围横跨 107 个 c 端页面、46 个 b 端页面、8 个 a 端模块、后端 API、数据、支付和部署，文件边界必须先于人力扩张。

材料没有提供仓库目录、技术栈、分支策略、页面文件分布和 API 清单，以下分区以“按实际目录映射”为前提，启动前必须由架构风险岗确认。

现有角色调整

• 一号：保留，归入 R3/R4；不得修改后端、数据和发布目录。
• 阿仁：保留，归入 R6；需要增加第二个后端施工席位，否则 API 仍是串行瓶颈。
• 波波：保留为 R2，专注架构、治理和高风险评审；不得承担大批量施工。
• 小冈：从“单点派工/验收/热修/文档”改为 R1，验收与发布权拆出。
• 冈子：转为 R9 或 R10 之一；只能固定一个深验方向，不能同时覆盖全部系统。
• 必须新增：至少一个独立自动验收席位、一个第二后端席位、一个发布工程席位、一个独立深验席位。

材料未涉及：现有 Agent 是否支持独立工作目录、独立凭据、CI 触发器和浏览器自动化。若不支持，以上席位只能作为逻辑角色，不能直接获得等比例并行产能。

② 每角色模型双配

模型选择遵循两个原则：

1. 高风险、跨模块、需要推理和审计的角色使用高质量主力模型。
2. 批量改写、检查、分类和快速反馈使用快速档模型。

以下是建议配置。模型能力差异仅依据材料给出的模型名称和常见角色定位推断；材料未提供正式基准、上下文限制、价格和稳定性数据，因此接入前必须做小样本评测。

模型使用硬规则

• 支付、生产、鉴权、数据迁移、删除和回滚操作：主力模型生成方案，R2/R10/R11 复核，刘总按 C 级拍板。
• 快速档模型不得独立提交支付、生产配置、数据库迁移和权限逻辑。
• 主力模型也不等于自动授权；模型等级不能替代审批等级。
• zhi-api 作为主通道，flu-svip 和 pidan 作为备用，但材料未涉及三者的限流、故障切换和模型版本锁定，需要刘总准备时一并确认。

③ 验收自动化架构

核心原则

施工 Agent 不验收自己的交付；自动验收先行，独立深验兜底，发布前必须有证据包。

验收责任矩阵

自动判据

每个交付单必须生成机器可读证据，至少包含：

1. 静态检查
2. tsc --noEmit 通过
3. lint、格式检查通过
4. 禁止的 Mock、TODO、临时接口、硬编码密钥扫描通过
5. 未处理错误和空 catch 扫描通过

1. 构建检查
2. 前端生产构建成功
3. 后端编译、启动和健康检查成功
4. 关键环境变量缺失时必须明确失败，不能静默使用默认值

1. 路由与页面检查
2. 目标路由可访问
3. 无白屏、JS 未捕获异常、资源 404
4. 页面主数据请求返回符合契约
5. 页面加载后无持续轮询或异常请求风暴

1. API 契约检查
2. 请求方法、路径、参数、状态码、响应结构与契约一致
3. 前后端类型可生成或比对
4. 未定义字段、字段类型漂移、必填字段缺失直接阻断

1. 冒烟检查
2. 登录、权限进入、核心查询、创建、编辑、提交、失败重试
3. c 端真实下单主链路
4. b 端关键管理链路
5. a 端模块入口和核心动作
6. 测试数据必须来自受控种子，不允许依赖个人本地状态

1. 数据检查
2. WIP-255 数据条数、主外键、状态分布、时间字段和关联关系符合预期
3. Mock 数量降至约定目标，理想状态为 0
4. 接口不能在生产或准生产继续返回明显 Mock 标识

1. 发布检查
2. 镜像或构建产物可追溯到 commit
3. 配置、迁移、备份、回滚脚本齐全
4. 部署后健康检查和核心冒烟通过

必须 Agent 深验的项目

以下项目不能只靠 tsc/build/smoke 判定：

• 下单业务语义：库存、价格、优惠、地址、订单状态和失败恢复。
• 微信支付：签名、金额、订单号幂等、回调验签、重复通知和超时处理。
• 权限：不同角色能看到什么、能操作什么、越权后端是否真正拒绝。
• 数据：WIP-255 的业务含义、跨表一致性和异常数据处理。
• 页面体验：空态、错误态、加载态、重复提交、移动端布局、关键操作反馈。
• API 边界：分页、排序、过滤、并发更新、幂等、事务和敏感字段泄漏。
• 生产发布：密钥注入、域名、HTTPS、日志、告警、回滚和数据库变更。
• Mock 清零真实性：不能仅删除字符串，必须确认页面已连接真实 API。

阻断规则

• 任一 tsc/build 失败：禁止进入深验完成态。
• 契约不一致：前后端交付单同时退回，不允许一方“先合”。
• 支付、权限、数据迁移任一深验失败：直接 C 级阻断。
• 自动验收通过但深验失败：以深验结论为准，自动验收规则必须补充。
• 验收结果必须绑定 commit、环境、测试数据版本和时间，否则视为无证据。

④ 并行度红线与 Git 分区

并行度红线

建议分三档：

• 绿色：6 个施工 Agent 并行

适合仓库尚未完成目录和接口冻结的阶段，冲突最低。

• 黄色：8 个施工 Agent 并行

需要目录边界、接口契约和独立工作树已经生效。

• 红色：超过 8 个施工 Agent 同时改同一仓库

不建议；除非按服务、包或仓库彻底隔离。依据是当前范围存在大量页面共享组件、公共类型、路由和接口文件，增加 Agent 不会线性增加交付量。

验收和发布 Agent 不计入“施工并行度”，但它们不能与施工 Agent 共用可写目录。

Git 分区

建议采用：主干保护 + 交付分支 + 独立 worktree + 领域所有权文件。

分支

• main：只接收验收通过的交付单，禁止直接写入。
• release/*：发布候选分支，由 R11 管理。
• work/<agent>/<ticket>：每个交付单一个分支。
• fix/<ticket>：热修专用，不混入新需求。

目录所有权

如果实际目录不同，必须按模块、服务、包重新映射；不能让两个 Agent 通过约定同时编辑同一个文件。

Git 纪律

• 公共组件、路由注册、全局类型、依赖清单、锁文件、环境模板属于高冲突文件，设为专人维护。
• 施工 Agent 提交前必须 rebase 目标分支并重新运行自动验收。
• 禁止多个 Agent 同时修改同一交付单。
• 禁止施工 Agent 直接合并到 main。
• 每个交付单必须有“文件边界、依赖交付单、验收命令、回滚方式”。
• 发生连续两次冲突或一次跨区误改，立即降低该 Agent 并行权限，不继续堆人。

⑤ 刘总准备清单

账号与模型

• zhi-api 主账号、API Key、余额、限额、并发额度。
• flu-svip 备用账号、API Key、切换方式。
• pidan 备用账号、API Key、切换方式。
• 明确模型实际可用名称、版本锁定策略和超时参数。
• 每个 Agent 的模型路由配置，不允许把密钥写入仓库。
• 成本预算、每日消耗上限和异常告警。

材料未涉及：三个通道的具体 API 协议、限流数、余额、模型可用性和故障切换机制，需要刘总补齐。

Agent 与沙箱

• 至少 10 个可独立运行的 Agent 席位，推荐 12 个以覆盖替补和故障。
• 每个席位独立工作目录或 Git worktree。
• 独立浏览器/设备模拟能力，至少覆盖桌面端和移动端。
• 独立终端、日志和任务上下文。
• Agent 之间的派工、回执、阻塞和升级通道。
• 自动验收 Agent 能访问构建环境、测试环境和证据存储。
• 发布 Agent 拥有部署权限，但生产写权限必须受 C 级审批保护。

材料未涉及：扣子沙箱和 OpenClaw 的最大席位数、并发限制、浏览器能力和持久化能力，需要先实测。

仓库与环境

• 仓库地址、默认分支、保护规则和提交权限。
• 测试、准生产、生产环境地址。
• CI/CD 权限、构建机、容器仓库和部署平台。
• 环境变量模板，不提供明文生产密钥给施工 Agent。
• 数据库连接、只读账号、迁移账号和备份恢复权限。
• 测试账号：c 端用户、b 端运营、a 端管理员、无权限用户、异常账号。
• 受控测试数据与 WIP-255 数据来源、版本和导入方式。
• 域名、HTTPS、对象存储、短信、邮件、微信开放平台和支付商户配置。

支付与生产

• 微信支付商户号、API 证书、私钥、回调地址和验签配置。
• 沙箱支付或可控金额测试方案。
• 支付订单号规则、幂等规则、退款和对账规则。
• 生产发布窗口、值班人、回滚负责人和故障升级联系人。
• 数据库备份、恢复演练和迁移回滚方案。
• 日志、错误追踪、监控和告警渠道。

材料未涉及：微信支付主体、商户资质、回调域名、退款政策和生产基础设施，不能假设已经具备。

验收基线

刘总必须确认并书面冻结：

• 107 个 c 端页面的页面清单和优先级。
• 46 个 b 端页面的页面清单和优先级。
• 8 个 a 端模块的模块边界。
• 下单流的业务状态机。
• API 契约唯一来源。
• WIP-255 的数据定义、验收数量和业务校验口径。
• Mock 清零的判定标准。
• 上线范围、暂不交付范围和 C 级红线。

没有这些基线，Agent 会把“页面完成”误判成“业务完成”。

⑥ 48 小时启动序列

0 至 2 小时：冻结规则与盘点

R1 建立交付单模板和看板；R2 盘点仓库目录、公共文件、服务边界和现有脚本；R8 盘点已有测试、构建、冒烟命令；R11 盘点部署和环境。

必须产出：

• 页面、模块、API、数据、支付、部署清单。
• Git 分区表和文件 Owner 表。
• 现有基线：构建是否通过、Mock 数量、API 缺口、页面可访问率。
• C 级事项清单。

若 2 小时内无法得到仓库和环境访问权，后续“极速推进”不成立，只能做方案工作。

2 至 6 小时：建立可验收骨架

• R8 固化 tsc、lint、build、启动健康检查和基础 smoke。
• R2 冻结 API 契约目录、错误码、鉴权约定和状态命名。
• R11 建立测试环境部署和 commit 可追溯机制。
• R7 建立 WIP-255 导入、校验和回滚脚本骨架。
• R1 将范围拆成独立交付单，每单限定文件边界和验收命令。

阶段门槛：

• 能从干净环境完成构建。
• 能启动前后端并执行最小健康检查。
• 自动验收能输出成功或失败证据。
• 未通过者不得开始大规模页面施工。

6 至 12 小时：打通一条真实业务链

优先级不是“先做最多页面”，而是先打通：

登录/权限 -> 商品或业务查询 -> 下单 -> 订单生成 -> 支付沙箱或支付占位 -> 状态回查

并行安排：

• R3：c 端主流程页面。
• R6：主流程 API 和状态机。
• R7：主流程种子数据。
• R9/R10：同步编写前后端深验用例。
• R8：为主流程接入自动冒烟。
• R11：测试环境部署。

12 小时门槛：

• 主流程可以在测试环境运行。
• 失败路径和重复提交至少有明确结果。
• API 契约、前端调用和测试数据一致。
• 支付真实生产接入仍必须保持 C 级隔离。

12 至 24 小时：六泳道并行扩张

启动不超过 8 个施工席位：

• 2 个 c 端施工。
• 1 个 b/a 端施工。
• 2 个后端领域施工。
• 1 个数据与 Mock 清零。
• 1 个自动化补测或热修席位。
• R2、R8、R9、R10、R11 持续工作，但不直接争抢施工文件。

每 4 小时形成一次交付批次；每批次都必须经过：

提交 -> 自动验收 -> 独立深验 -> 合并 -> 测试环境回归

禁止把 107 页、46 页或 8 模块作为单一大工单，必须拆成可独立验收的页面组、业务组或领域组。

24 至 36 小时：批量施工与缺口清零

• R3/R4 批量完成 c 端非核心页面，优先复用已验证组件。
• R5 完成 b/a 端骨架与真实 API 接入。
• R6 按领域补齐 API，禁止继续扩张未经契约定义的接口。
• R7 清理 Mock，建立残留扫描和数据一致性报告。
• R9/R10 按已合并批次持续深验，不积压到最后。
• R11 完成准生产部署、配置检查和回滚演练。

36 小时门槛：

• 核心主流程通过。
• 自动验收稳定运行。
• 高风险缺陷有明确 owner 和截止时间。
• 公共组件、路由、契约和数据库迁移没有无主变更。

36 至 44 小时：上线候选冻结

• 冻结新需求和非必要重构。
• 只允许三类变更：阻断缺陷修复、发布配置修复、验收规则修复。
• R8 生成全量自动验收报告。
• R9 完成页面与核心流程深验。
• R10 完成 API、权限、支付和数据深验。
• R11 完成部署、回滚、监控和告警检查。
• R2 汇总风险清单，标记 A/B/C。

44 至 48 小时：发布决策

发布前必须同时满足：

• 自动验收通过，证据绑定候选 commit。
• 核心 c 端下单链路通过。
• b/a 端核心权限和业务链路通过。
• API 契约无未豁免漂移。
• Mock 达到已冻结目标。
• 数据校验和备份完成。
• 支付、生产和迁移事项完成 C 级拍板。
• 有可执行回滚方案和明确值班人。

决策结果只有三种：

1. 发布：所有 C 级事项关闭，B 级事项有明确监控和回滚。
2. 带条件发布：仅允许非核心、非涉钱、非生产风险，且刘总明确批准。
3. 不发布：支付、权限、数据一致性、回滚或核心下单链路任一失败。

硬结论：48 小时内可以完成“可验收、可部署、核心链路闭环”的启动目标；材料未提供当前代码完成度、环境可用性和支付资质，因此不能据此承诺全量 107+46+8 页面及生产支付在 48 小时内完成。若刘总要求全量生产上线，必须先补齐材料未涉及的仓库基线、环境权限、支付资质和验收口径。