TocoAI协作开发流程建议

Name: TocoAI
Author: TocoAI

整体流程概览


┌─────────────────────────────────────────────────────────────┐
│                          项目启动                            │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│              阶段一：架构师主导系统建模                       │
│           （串行，必须完成后才能进入阶段二）                   │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│              阶段二：开发人员并行模块开发                     │
│           （并行，每人负责一个模块，互不干扰）                 │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                  阶段三：集成联调与上线                       │
└─────────────────────────────────────────────────────────────┘

阶段一：架构师主导系统建模

👤 负责人：架构师　⏱️ 执行方式：串行，全体成员参与 Review　✅ 完成标准：所有模块边界清晰、ER 设计评审通过、跨模块依赖关系明确

Step 1｜需求梳理与领域分析

输入：产品需求文档、PRD、原型图

架构师任务：

与产品、业务方对齐核心业务流程
识别系统中的核心域、支撑域、通用域
初步划分领域边界，确定系统涉及哪些业务模块

AI 辅助方式：

将 PRD 或原型图提供给 AI，让 DomainArchitect 辅助识别领域对象和模块边界
典型指令：“根据以下需求文档，帮我识别系统的核心领域和模块划分建议”

产出物：

领域划分草图
核心业务流程说明

Step 2｜模块划分与边界确认

架构师任务：

确定每个模块（Module）的职责边界，遵循高内聚低耦合原则
确定跨模块的公开 RPC 接口清单（哪些服务需要对外暴露）
为每个模块指定负责开发人员

AI 辅助方式：

使用 DomainArchitect 在 Toco 中创建模块结构
典型指令：“创建以下模块：member（会员）、order（订单）、room（房源）、payment（支付），并注释各模块的职责”

产出物：

模块清单及职责说明
跨模块 RPC 接口初步清单
模块负责人分配表

Step 3｜ER 设计与数据建模

架构师任务：

设计每个模块下的 Entity（数据表） 及其字段
定义 Entity 间的 Relation（外键关联关系）
确定索引策略（唯一索引、普通索引）
设计枚举（Enum） 和值对象（EO）

AI 辅助方式：

使用 DomainArchitect 完成 Toco 中的 Entity、Relation、Enum、EO 创建
典型指令：“在 member 模块下创建 member 表，包含以下字段：id、phone、password、status（枚举：ACTIVE/INACTIVE）、created_time，phone 字段需要唯一索引”

关键原则：

⚠️ ER 设计是整个项目的地基，后期修改成本极高，必须充分评审
一个 Entity 只能属于一个模块，禁止跨模块共享表
枚举和值对象尽量在此阶段完整定义

产出物：

完整 ER 图（含所有 Entity、字段、索引、关联关系）
Enum 清单
EO 清单

Step 4｜聚合设计与领域对象划分

架构师任务：

以聚合根为核心，将相关 Entity 组织为聚合对象（BO）
确定每个聚合的边界和不变性规则（如：订单总金额 = 各明细金额之和）
明确写操作的事务边界（一个写方案只能操作一个聚合内的数据）

AI 辅助方式：

DomainArchitect 辅助识别聚合边界，生成 BO 结构建议
典型指令：“order 模块中，order 表是聚合根，order_item 是其子实体，帮我设计这个聚合的 BO 结构和不变性规则”

产出物：

聚合划分说明文档
各聚合的业务不变性规则清单

Step 5｜建模评审与基线确认

所有团队成员参与，架构师主导评审：

模块边界是否清晰，无职责交叉
ER 设计是否覆盖所有业务场景
跨模块依赖是否合理，无循环依赖
聚合边界是否正确，事务范围是否合适
Enum 和 EO 是否完整
每个模块负责人是否清楚自己的边界

💡 评审通过后，ER 模型进入”基线”状态。后续原则上禁止架构级修改，如需变更需要重新走评审流程。

阶段二：开发人员并行模块开发

👤 负责人：各模块开发人员（并行）　⏱️ 执行方式：并行，模块间独立互不干扰　✅ 完成标准：本模块所有接口实现完毕、自测通过、文档更新

每位开发人员负责一个模块的完整开发，按以下步骤执行：

Step 6｜模块接口设计

开发人员任务：

理解本模块的业务需求和 ER 结构
分析需要提供哪些 HTTP API 接口
使用 TocoAI 进行接口分析，拆解出具体接口清单

AI 辅助方式：

提供模块需求给 TocoAI，自动分析接口列表
对接口分析结果逐一 Review，确认参数、返回值、分页方式等

建议：

接口数量 > 5 个时，先保存到工作台，再分批开会话执行
新开会话处理接口，每批不超过 5 个接口，复杂接口单独开会话

产出物：

接口清单（含 URI、参数、返回值说明）
已保存到工作台的待办任务列表

Step 7｜详细设计（DesignerAgent）

开发人员任务（每批接口开一个新会话）：

完成接口所需的 DTO、VO、QTO、BTO 等设计元素创建
设计读方案（ReadPlan） 和写方案（WritePlan）
确认服务层方法（RPC/SERVICE） 签名
如需暴露给其他模块调用，完成公开 RPC 接口定义

AI 辅助方式：

PlannerAgent 先输出详细规划，Review 后再进入 DesignerAgent 执行
典型指令：“根据以上接口规划，完成 member 模块的设计元素创建”

注意事项：

⚠️ 如果在此阶段发现需要新增 Entity 字段或修改表结构，必须通知架构师 Review
设计元素创建完成后必须触发代码重新生成

产出物：

本批次所有设计元素（DTO/VO/ReadPlan/WritePlan/API）
生成的框架代码

Step 8｜业务逻辑编码（DeveloperAgent）

开发人员任务：

在 Toco 生成的框架代码基础上补全业务逻辑
重点关注以下扩展点：

扩展点	位置	典型内容
业务不变性校验	BO.validateAggregate()	余额校验、状态流转合法性
自定义字段填充	Converter 的 Map 转换方法	计算字段、关联数据拼装
数据后处理	DataAssembler.postProcessData()	列表数据二次加工
接口核心逻辑	Controller 方法体	参数校验、服务调用、结果组装
服务层逻辑	BOService 方法体	写操作业务流程编排

产出物：

本批次接口完整可运行的业务代码
自测通过的接口

Step 9｜跨模块 RPC 对接

开发人员任务：

如果本模块需要调用其他模块的服务，通过 public_service 中的公开 RPC 接口订阅调用
如果本模块需要被其他模块调用，确认公开 RPC 接口已正确暴露
与相关模块负责人沟通，确认接口契约

注意事项：

严禁直接注入其他模块的 Service 类，只能通过 public_service 接口调用
如果依赖的模块尚未开发完成，可先 Mock 返回值，待对方完成后联调

产出物：

跨模块调用代码
RPC 接口联调记录

Step 10｜模块自测与收尾

开发人员任务：

完成本模块所有接口的功能自测
检查边界条件、异常场景、并发安全性
更新模块相关文档

自测 Checklist：

所有接口正常 Case 通过
参数校验异常场景处理正确
跨模块 RPC 调用正常
FULLY_LOCKED 代码未被手动修改
无硬编码的跨模块 Service 直接引用

阶段三：集成联调与上线

👤 负责人：架构师 + 全体开发人员　⏱️ 执行方式：串行，统一协调

Step 11｜集成联调

所有模块完成后，部署到集成测试环境
按业务流程进行端到端测试（如：注册 → 下单 → 支付 → 退款完整链路）
重点关注跨模块数据一致性和事务边界
发现问题由对应模块负责人修复

Step 12｜架构复查

架构师对最终代码进行架构层面的复查：

模块边界是否被遵守（无越界调用）
跨模块依赖是否都走了 public_service
ER 模型与最终代码是否一致
是否存在未经审批的 Entity 修改

Step 13｜上线发布

按标准发布流程执行，此处不展开

角色职责总结

角色	阶段一	阶段二	阶段三
架构师	主导建模、评审把关	审批 ER 变更请求、答疑	架构复查、协调联调
开发人员	参与评审、理解设计	独立负责一个模块的设计+编码	修复集成问题

协作关键原则

✅ 推荐做法	❌ 不建议做法
架构师统一维护 ER 模型	开发人员自行修改 Entity 字段且不通知架构师 Review
模块边界清晰，一人一模块	多人同时修改同一个模块
跨模块只走 public_service	直接注入其他模块的 Service
ER 变更需要架构师 Review	私下悄悄改表结构
接口设计完成再编码	边设计边改来改去
复杂接口单独开会话	一个会话塞入所有接口

💡 核心思想：架构是全局的，开发是局部的。架构师的建模质量决定了整个项目的天花板，开发人员的模块独立性决定了并行效率。上述 Step 1-5 由架构师主导，Step 6-10 由开发人员完成。Toco 平台结合公司流程（领域建模由架构师保证质量、业务代码由开发人员补全），可以比较自然地支撑这种协作模式。

当然，没有最好的流程，只有最适合组织和具体场景的流程，本文是建议，可以按照公司实际情况对流程做调整。