你的首个项目
本指南将带你通过民宿管理系统中的“房间预订及积分下单”需求进行实战，快速上手 TocoAI 的核心流程，了解其中的AI时代建模驱动开发的思路。
业务背景: 会员将房型和数量加入购物车后一次性下单。系统需验证房源：房源充足确认支付生成预约支付成功的订单，扣减积分并记录消费详情。
项目准备
前提条件
- 已安装并配置 TocoAI 插件：IntelliJ IDEA 插件，或 VS Code 扩展。
选择项目模式
当你首次在非 Toco 项目中打开 TocoAI 对话面板时，会看到项目模式选择界面：
- DSL-Spec 模式：以建模驱动开发（MDD）为核心，适合从零开始的 Java 后端项目，提供标准化的设计→代码全流程
- Vibe 模式：直接与 AI 对话协作，灵活支持多语言和技术栈，适合在已有代码库中快速编码
注意： 模式选定后无法切换（DSL-Spec 在 Toco 项目创建成功后固定，Vibe 选定后即固定）。如需使用建模功能请选择 DSL-Spec。
新建 Toco 项目
Toco 独特的 建模驱动开发 (MDD) 能力仅限在 Toco Project 中使用。目前支持 Java Spring 体系，更多语言持续更新中。
注：在普通项目中，Toco 仍可作为传统 AI Coding 助手 使用。
VS Code 中新建 Toco 项目 方式：新建窗口（File ➔ New Window 菜单）➔ 点击 TocoAI 图标 ➔ 创建项目。
输入需求文档
在 Agent Chat 窗口中，通过附件输入需求文档。
分析与建模
需求分析
当需求涉及全新项目、跨模块流程，或需要先统一关键业务规则和系统边界时，System Analyst 会梳理业务目标、系统入口、关键规则、状态变化和主要流程，形成可 Review 的需求分析。这不是每个任务的必经步骤；如果现有上下文已经足够、交付目标清晰，可以直接进入后续建模、待办或规划。在本例中，你可以查看分析结果并提出修改，确认后的结论将作为后续环节共同使用的需求依据。
业务知识沉淀
长期业务知识与 DSL Spec 中的结构化设计信息互补，不重复记录具体模型细节，只保留可跨需求复用的关键业务信息，例如全局背景、统一术语、关键规则和核心状态机。它由 Agent 流程随着需求与实现推进自动维护；你可以查看沉淀结果并确认接受，让后续会话持续复用这些上下文。
领域建模
AI 架构师 (Domain Architect) 会自动生成需求的 领域模型（包含 ER 图、值对象、聚合对象等）。
- 本例核心： 聚合对象包含“订单信息”（包含订单主表
booking_order、订单项表order_item等）。 - 灵活修改： 你可以通过对话要求 Toco 修改，或直接在可视化编辑器中手动调整。
小贴士：随时查看设计模型 点击对话框中的 Toco 图标，即可随时进入查看或编辑所有模块的领域模型、服务模型等。
需求拆解
Toco Agent 会把已确认的需求整理为可以独立规划、开发、联调和验收的待办任务。待办可以是 API、定时任务、消息、回调或基础能力等执行单元。
- 每个待办都会说明业务目标、关键规则、完成结果和所属业务场景。
- 优先级表示建议实施顺序，复杂度表示实现风险和工作量，两者分别判断。
- 你可以在加入工作台前 Review 和调整待办，也可以稍后通过工作台继续管理。
规划与开发
开启独立会话执行待办
从工作台中选择一个待办并开启 独立会话。如果待办列表已经关闭，可以通过右下角的待办入口重新打开列表，再选择需要执行的待办。独立会话会携带该待办已经确认的目标、规则和上下文，让后续规划专注于当前执行单元。
注：相关性较强的多个待办也可以在同一会话中处理，但不建议一次加入过多复杂任务。保持上下文聚焦有助于提升会话质量。
设计方案规划
Planner Agent 会结合当前需求上下文、项目知识、现有设计和代码，形成可 Review 的实施级规划，明确规划目标、当前状态、影响范围、关键依赖、风险、后续承接方和执行事项。确认后的规划将作为设计、开发和测试继续协作的共同上下文。
服务设计
确认无误后，Designer Agent 基于规划，完成相关服务建模：
- 读模型 (Read Model)：
- Toco-DTO（服务传输对象）：基于外键扩展的多表聚合形成的数据结构。例如：在“房型详情DTO”中组装该房型下的订单项列表（通过外键
room_type_id进行对象扩展）。
- 读方案：基于DTO作为返回值，面向对象的查询方式，支持高效的跨表检索。例如：
- 可根据 ID、编码、总房间数等条件筛选房型：
id in #roomTypeIdListANDroom_type_code in #roomTypeCodeInANDtotal_quantity >= #totalQuantityBiggerThanEqual - 并同步获取该房型在特定日期范围内的有效订单明细：
filter orderItemList:order_item_status in #orderItemListOrderItemStatusIn AND order.check_in_date >= checkInDateBiggerThanEqual AND order.check_out_date <= checkOutDateLessThanEqual
- 可根据 ID、编码、总房间数等条件筛选房型：
- 读方案是高效的读建模表达：将同时确认返回值、查询方式、组装数据方式、入参、对应Service/API。
- Toco-DTO（服务传输对象）：基于外键扩展的多表聚合形成的数据结构。例如：在“房型详情DTO”中组装该房型下的订单项列表（通过外键
- 写模型 (Write Model)：用于定义面向聚合对象的业务变更与事务逻辑。例如：在“下单”流程中，通过写方案同步执行创建订单及其明细（写方案1）、扣减积分并记录消费详情（写方案2）等操作。
- 【写方案1】创建订单及其明细：描述同时创建两张表（
booking_order,order_item）的记录。
- 【写方案2】扣减积分并记录消费详情：描述更新
member的积分同时创建对应的points_transaction记录。
- 【写方案1】创建订单及其明细：描述同时创建两张表（
- 写方案是高效的写服务建模表达：将同时确认入参，对应Service/API，定位业务对象和变更方式。
代码生成：80/20 原则
Toco 内置 M2C (Model To Code) 引擎，将代码分为两部分：
- 结构性代码 (约 80%)： 由引擎根据上述所有建模信息直接生成。遵循 DDD 和 CQRS 规范，架构标准且 100% 准确，无需人工 Review。
- 胶水代码 (约 20%)： 由 Developer Agent 编写剩余的业务逻辑。你仅需 Review 这部分“胶水代码”（如：预订的房型数量是否可用、积分是否充足的判断、生日优惠逻辑等）。
技术知识沉淀
技术知识沉淀通常在 Developer Agent 完成开发后进行。Agent 流程会基于本轮已经实现并确认的技术事实，沉淀可长期复用的共享框架、集成约束和技术规范，而不是记录尚未落地的方案设想。你可以查看知识结果中的索引、概览和具体能力说明，确认无误后接受这些产物，供后续规划、开发和测试复用。
测试与验证
单元测试
Tester Agent： 基于接口契约和业务规则设计并执行接口级 Mock 单元测试，生成测试代码以及必要的测试数据和断言。测试会尽量覆盖真实业务逻辑，同时 Mock 数据库和第三方服务等外部依赖，因此无需连接真实数据库或调用真实第三方服务。发现生产代码或业务逻辑问题时，Tester Agent 会保留失败证据并交回规划和开发环节处理。当前支持接口级 Mock 测试，后续将补充集成测试能力。