一个需求从想法到代码提交，中间要经历多少人工环节？UC TeamSpace的开发者算过账：分析、规划、拆解、编码、验证—— senior developer也得耗掉大半天。他把这串流程塞给了6个AI代理，自己只负责点"批准"。
这套系统的野心很直白：让需求像快递包裹一样，在代理之间自动流转，人只当收件员。
从"口头指令"到"可追溯流水线"
开发者最初只是在Claude Code里写了个子代理uc-taskmanager。动机很个人：以前给完需求指令，开发完只剩代码，中间怎么分析的、改了什么决策，全没留痕。
他把流程切成阶段，每个阶段强制产出交付物。但很快发现新问题——CLI工具对大多数人门槛太高。于是有了UC TeamSpace：网页里填需求、审方案、点执行，代理自动跑，全程留档。
这套6-Agent SDD（规格驱动开发）流水线已经跑通：Specifier（规格化）→ Planner（规划）→ Scheduler（调度）→ Builder（构建）→ Verifier（验证）→ Committer（提交）。
开发者自嘲："我是想偷懒的人。但每次省下的时间，又拿去建下一个工具。什么时候能真懒？大概进棺材那天。"
REQ-133实录：30分钟超时限制的破局
这篇演示文档追踪了一个真实需求REQ-133的完整生命周期。需求本身很具体：执行超时目前只能在CliProfile层设30分钟默认值，无法给单个REQ配不同超时，也不能无限跑。大规模WORK比如KPI计算，30分钟根本跑不完，反复超时失败。
需求在Requirements Management界面创建，状态Draft。正文用结构化markdown写，直接喂给AI代理——需求质量决定生成质量，垃圾进垃圾出。
流程第一步是Specifier代理。它把自然语言需求转成详细技术规格，供人review。开发者透露这个代理已经写好，但还没集成进UC TeamSpace。
目前TeamSpace里的流程从Planner开始：读取需求、分析影响范围、拆解任务、输出执行计划。
Scheduler代理接着出场，把计划拆成可并行/串行的子任务，分配执行顺序。Builder代理写代码，Verifier跑测试验证，Committer最后打包提交git。
整个pipeline在网页端可视化，每个代理的输出、耗时、状态一目了然。人只在关键节点介入：审规格、批计划、验结果。
自动化开发的"最后一公里"在哪
演示文档留了明显的未完成态。Specifier代理还没接进网页端，意味着需求结构化目前仍靠人写markdown。开发者列出的roadmap包括：多REQ批量处理、WORK执行监控看板、失败自动重试与人工介入机制。
这套架构的假设很大胆：如果需求写得够清楚，AI代理能替代从设计到提交的大部分人工环节。但"够清楚"本身就是门槛——演示里的REQ-133是格式规整的技术需求，真实业务场景里模糊、冲突、反复变更的需求才是常态。
开发者没回避这个问题。他在文档底部放了反馈入口，标注"当前版本为MVP演示，生产环境使用需自行评估稳定性"。
一个细节值得玩味：6个代理里，只有Committer是"不可逆"操作——代码一旦push，回滚成本远高于前面任何阶段的修改。所以Verifier的输出被设计成强制阻断，测试不通过无法进入提交环节。
这套系统的真正价值，或许不在于省了多少时间，而在于把"开发过程"变成了可审计的数据资产。每个需求走过哪些代理、改过什么决策、卡在哪一步，全有记录。对于需要合规留痕的团队，这比自动化本身更值钱。
开发者最后问了个没回答的问题：当AI代理能处理从需求到代码的全流程，产品经理的"PRD写作能力"会不会变成新的技术壁垒？
热门跟贴