结论先行

这个团队目前不是“开发慢”，而是把一个高并发、低边界纪律、强外部依赖的系统，伪装成了工单列表。

继续用“人日”会掩盖真正问题：决策排队、验收串行、返工、环境与外部审核、依赖冲突。

正确目标不是“多少人日完成”，而是：

在给定并行度、自动化覆盖率、决策服务时间和外部时钟下，关键路径需要多少墙上时间。

材料显示，当前最大浪费不是编码，而是等待、错误交付和重复验证。

① 正确的工期度量单位

1. 主单位：墙上时间（Elapsed Calendar Time）

应以：

作为主度量。

理由：

2. 施工单位：Agent-Minute / Agent-Hour

用于衡量资源消耗，而不是预测交付日期。

建议拆成：

这样可以识别成本和浪费来源。

例如，某工单可能只消耗 30 分钟施工，但经历两轮返工、一个验收队列和一天决策等待，最终墙上时间仍可能超过 24 小时。

3. 交付单位：通过验收的“变更包”或“价值切片”

不应再把“页面数”“路由数”“表数量”作为主要工期单位。应按以下粒度计算：

材料未涉及目前工单的业务闭环通过率，因此不能判断 250+ 工单是否等价于 250 个有效交付单元。

4. 必须新增的四个指标

A. Lead Time

从工单进入系统到生产可用的时间。

B. Touch Time

agent 实际施工、验收、修复所花时间。

C. Queue Time

等待验收、等待拍板、等待环境、等待依赖的时间。

材料已经明确：等待老板拍板和串行验收是主要队列来源。

D. First-Pass Yield

首次交付通过率。

材料显示已有 9 起“自报完成但实测不实”，另有截断文件、双副本假交付、撞号、Git 冲突等事故。这说明单看施工速度没有意义；首次通过率低，速度越快，返工制造越快。

② 编码不是瓶颈时，真瓶颈排序与破解法

第一优先级：人类决策排队

证据

本质

老板不是“决策者”，而是当前系统的单点阻塞资源。

如果所有非技术、上线、产品和风险问题都等他拍板，一周交付不可能成立。

破解

建立决策分级和预授权：

决策类型默认规则
不涉及资金、合规、数据结构破坏agent 自动决策
可回滚、影响单个模块代理负责人批准
涉及支付、生产数据、用户隐私、不可逆迁移老板批准
需求存在多种可接受方案使用预设默认方案，不等待确认
超出预算或改变商业承诺老板批准

老板只保留红线事项，不再审核普通实现细节。

第二优先级：验收串行

证据

破解

建立分层验收流水线：

  1. 提交前自检：格式、类型、构建、路由、引用、数据库迁移检查。
  2. 自动冒烟测试：页面加载、接口连通、核心路径。
  3. 模块验收 agent 并行执行：前端、后端、数据、权限、存储分别验收。
  4. 风险验收 agent：只处理支付、权限、数据迁移、生产变更。
  5. 最终集成验收：只验收跨模块闭环，不重复检查已经通过的局部项。

验收 agent 不应是一个人，而应是验收池。

当前串行验收是明显的组织设计错误。

第三优先级：返工循环

证据

本质

团队把“写完代码”误当成“完成交付”，交付证据标准不统一。

破解

每个工单必须有机器可验证的完成契约：

禁止 agent 用自然语言自报“已完成”作为交付依据。

尤其针对材料中的双副本假交付和长行截断，应增加：

第四优先级：跨模块依赖和集成冲突

证据

破解

第五优先级：外部时钟

证据

材料明确提到：

这些都不受编码速度控制。

破解

如果微信审核或证书申请本身超过一周，材料没有提供具体时长，因此不能承诺一周生产全量可用。

③ 压到“一周全量交付”的组织改法

先说结论：

一周交付不是靠让 agent 更努力，而是靠把组织改成“多泳道并行、自动验收、默认决策、受控集成”的流水线。

但“全量”定义不清。项目有 107 个 C 端页面、46 个 B 端页面和 8 个后台模块，材料未说明当前剩余范围、哪些页面只是静态壳、哪些业务链路已完成，因此无法证明一周必然可行。

1. 任务拆分粒度

工单应从“页面施工单”改为三类：

A. 闭环交付单

例如：

这是最优先单位，因为它能直接验收业务价值。

B. 模块变更单

例如：

要求 30—90 分钟内可完成并验收。材料显示页面级施工实测为 20—60 分钟，因此这个粒度基本可行。

C. 集成变更单

只负责跨模块接线、环境配置、部署和回归，不再把所有工作混在页面工单中。

禁止拆成：

这类碎片会制造大量调度和验收开销。

2. 并行度设计

不要无限并发。建议按资源类型设置泳道：

初始可采用：

关键是并行独立任务，串行高冲突资源。

把数据库、生产环境和核心配置也无限并行，只会增加事故。

3. 一周节奏

第 0 天：冻结与预授权

第 1—2 天：并行施工

第 3—4 天：模块验收与集成

第 5 天：全链路回归

第 6—7 天：生产发布和缓冲

这不是材料中的既有事实，而是建议的组织方案。

4. 验收自动化必须成为硬门槛

没有以下结果，工单不得进入“完成”状态：

“自报完成”必须从流程中删除。材料已经证明它不可靠。

5. 决策预授权

老板提前批准：

只把以下事项升级给老板：

④ 人类老板最小必要参与及拍板压缩

最小必要参与：四类事项

老板不需要参与施工、普通验收和技术选型。只需要参与：

1. 目标和范围

2. 商业规则

3. 风险红线

4. 生产放行

材料没有说明老板每天可投入多少时间，因此无法给出确定的分钟数。原则上应从“持续被打断式审批”改为固定决策窗口+异常升级。

压缩拍板空窗的方法

A. 建立决策 SLA

例如：

如果没有超时默认值，所谓 SLA 只是愿望。

B. 批量决策包

不要每个问题单独问老板。每次提交必须包含：

老板只回答“批准/不批准/选 A 或 B”。

C. 固定两个拍板窗口

例如每日早晚各一次。

紧急问题仅限红线事项，其余进入下一窗口。

D. 代理决策人

材料未说明是否存在人类副手或业务负责人。如果没有，就由治理 agent 按老板预先写下的规则代理；涉及红线的事项仍必须升级。

E. 默认批准而非默认等待

对于可回滚、低风险、符合规范的变更，默认允许执行。

当前“等老板批准生产更新”的做法，如果没有风险分级，就是把老板变成发布系统的人工锁。

⑤ 材料没提到但必须利用的杠杆

以下是材料未明确涉及、但对一周交付影响可能比继续优化编码速度更大的杠杆。

1. 砍范围，而不是幻想全量

“全量交付”没有定义。应强制分为：

如果 107+46+8 个页面都被视为同等优先级，这是产品管理失败，不是工程问题。

2. 建立黄金路径，不验收所有可能性

先保证少数关键用户路径：

非黄金路径可延后。材料未提供用户核心路径清单，因此需要立即补齐。

3. 做“变更影响图”

将页面、接口、表、权限、存储和环境关联起来。

没有影响图，agent 会在局部正确、全局破坏中循环。

尤其项目已有 109 张表和 53 个路由域，单纯依靠 agent 记忆上下文不可靠。

4. 固定基线和禁止漂移

需求、接口、数据库和 UI 规范必须有版本号。

否则 agent 施工期间，方案持续变化，返工不是质量问题，而是需求漂移问题。

材料未说明当前是否存在版本化基线，这是必须核查的缺口。

5. 建立可观测性和自动回滚

一周交付如果没有：

那只是“一周把代码推上去”，不是一周交付。

6. 模型和 agent 路由优化

不要让所有任务都使用最强模型：

材料提供了不同 agent 的性能数据，但未提供成本、失败率和任务类型分布，因此不能判断最优路由，只能建议建立数据闭环。

7. 把事故模式产品化拦截

材料中的事故不是偶发小问题，而是流程设计缺陷：

如果这些拦截器不先上线，继续增加 agent 数量只会扩大返工规模。

8. 以“吞吐量和返工率”而不是工单数量考核

250+ 工单并不等于 250+ 交付。应看：

当前材料未提供这些完整数据，因此无法判断真实吞吐量。

最后一句不留情面的判断

这个团队目前最大的错误，是用人类组织的“人日”和工单数量，包装一个实际上由队列、依赖和审批控制的 AI 生产系统。

如果不改：

要实现一周交付，必须先做到四件事：

  1. 以墙上时间和关键路径度量；
  2. 验收并行化、证据自动化；
  3. 普通决策预授权，老板只管红线；
  4. 按业务闭环交付，严格砍掉非关键范围。

否则“一周全量交付”不是目标，而只是把未解决的问题从工期表转移到生产事故表。