链路完整性：多模块并行开发的隐形债务

并行开发有一个反直觉的陷阱：每个人/每个 agent 都完成了自己的任务，Review 通过、单测绿灯，却在验收时发现功能拼不起来。

这不是能力问题，也不是沟通问题，是需求拆解时没有把「连接点」算进去。

问题的本质：谁负责接缝？

把一个功能群拆成若干独立子任务派出去，每个子任务都有明确的输入和输出。但链路的「接缝」往往游离在任何一个子任务之外——没有人被要求对「A 的输出能不能接进 B 的入参」负责。

常见的断裂形式有这几种：

| 断裂模式 | 表现 | |----------|------| | 功能做了入口没有 | 子页面开发完，父页面没有跳转链接 | | Service 写了没调用 | 方法存在，但没有任何业务节点调用它 | | 数据流格式不一致 | A 产出的字段名和 B 期待的对不上 | | 权限/菜单缺失 | 功能可用，后台却看不到入口 |

每一条单独看都像「小疏忽」，但一次并行开发攒够六七条，就足以让整个模块无法交付。

三个节点插入协议

我总结出一个轻量的做法：在需求、派发、验收三个节点各插一个动作，把链路完整性从「事后检查」变成「过程内建」。

需求阶段：先画功能依赖图，再拆任务。

用户标签 ──→ 用户分群 ──→ 消息推送
消息模板 ──────────────────↗
优惠券模板 ──→ 用户领券 ──→ 下单选券 ──→ 支付核销
                                       ↓
                         退款 ──→ 退券

依赖图的作用不是画得多漂亮，而是让箭头上的每一条边都变成显式的集成任务。没有依赖图的拆解，集成工作会自动变成「大家各扫门前雪，中间的路没人扫」。

派发阶段：每个子任务的 prompt 必须带上下游信息。

// 不完整的派发
"开发用户分群功能"

// 完整的派发
"开发用户分群功能。
 上游依赖：用户标签表已存在（user_tag + user_tag_relation）
 下游消费方：消息推送需支持按分群推送（pushType=3）
 集成点：发送方法需支持 group_id 参数，
         调用 UserGroupService::getGroupUserIds() 获取用户列表"

这多出的三行，价值是让开发者/agent 在实现时就知道「我的输出要被谁消费，格式要长什么样」，而不是等对接时再来协商。

验收阶段：走完整链路，不走单功能。

验收的粒度应该是「从链路入口到链路出口」，而不是「这个 Service 方法存不存在」。如果链路任何一步断裂，补充集成代码是验收前的必要动作，不是后续 TODO。

对 AI Agent 并行开发的特殊意义

这个问题在人工团队里会被「随口沟通」部分消化——开发途中碰一面，发现不对齐，当场调整。Agent 没有这个机制，它只执行给定的 prompt，不会主动跨任务协商。

所以用多 agent 并行开发时，依赖协议必须更加前置和显式：依赖图要在派发前画好，每个 prompt 要把集成点写进去，验收要以链路为单位而不是以 agent 为单位。

不做这些，并行 agent 的产出物会像一组精工制作却互不适配的零件——每个都很好，合在一起没用。

一句话心法

功能拆解时，每一条「A 依赖 B」的箭头都是一个独立的任务，不把它分配给任何人就等于把它分配给了命运。