契约化多端架构：基于领域模型的Harness实践（中）
本文为《契约化多端架构：基于领域模型的Harness实践》系列第 2 篇（共 3 篇），分为（上）（中）（下）三篇，建议连续阅读。
05 完整工作流
说完领域模型，接下来讲完整工作流。
第一次接入项目时，先跑 /project-init：
/project-init .它会做下面几件事情：
探测项目类型（Roku / Next.js / Linux TV / ...）
根据
_DETECTION_HINTS扫描项目，生成 domain-mapping.json从 infrastructure-templates/ 读取对应类型的模板，生成项目专属规范
跑完这一步，Harness 才算真正"接入"了你的项目。
后续开发新需求时，直接从"需求输入"开始：
需求输入 → 需求拆分 → 红队验证 → 验收标准 → 初始化存档 → 方案设计 → 编码开发 → → 观测回收5.1 项目初始化：/project-init 流程
5.1.1 接入步骤
第一次接入项目时跑这个命令，让 AI 把通用领域模型映射到你的项目。
整个流程 5 步：
步骤
干什么
产出啥
环境准备
解析路径、判断单仓/Monorepo、读项目配置
项目上下文变量
MCP 配置
问你要不要配 MCP（连 TAPD、企微这些外部工具）
mcp.json（可选）
项目探测
扫描项目目录，识别项目类型，问你确认
项目类型 + 特定配置
领域映射
逐层确认 Page / API / UI Module 的映射关系
完整映射表（内存中）
生成文件
把前面收集的信息写成项目专属配置文件
.codebuddy/ 目录下的所有文件
领域映射这一步最关键，分三层确认：
层
AI干啥
你要确认啥
Page 层
根据_DETECTION_HINTS找到每个页面对应的实际文件
识别对了没？漏了没？
API 层
找到项目中实际的 API 调用代码，跟通用定义做匹配
接口路径对不对？
UI Module 层
找到项目中实际的 UI 组件，跟通用定义做匹配
组件路径对不对？
三层都确认完，AI 展示完整映射表，你点头后才进入"生成文件"这一步。
生成的文件清单：
文件
内容
config/domain-mapping.json
领域模型映射表
rules/domain-mapping.md
映射文件的可读版
rules/coding-standards.md
编码规范（从项目真实配置生成）
rules/test-standards.md
测试规范
patterns/idioms.md
代码模式库
如果项目没有 E2E 测试基础设施，还会生成测试骨架。
关键设计：每一步都要你确认才继续。因为领域模型映射一旦错了，后面所有 AI 生成的代码都会跟着错。
5.1.2 流程图
5.2 需求分析阶段
需求分析分 5 步：TAPD 拉取 → 需求拆分 → Figma 设计稿处理 → 红队验证 → 验收标准。
5.2.1 第一步：TAPD 拉取 + 父需求回溯 + Figma 链接扫描
AI 从 TAPD 拉取需求详情，如果 description 为空，会自动回溯父需求（tapd有可能是需求下story）
步骤
AI干啥
你要确认啥
解析输入
识别是 TAPD 短 ID / 完整链接 / 自然语言
-
拉取需求
调用 TAPD MCP，获取 name / description / parent_id等字段
-
父需求回溯
如果 description 为空，且 parent_id存在，自动拉取父需求
-
Figma 链接扫描
从 description 中提取 Figma / 蓝湖 / Axure 链接
Figma 链接对不对？
人员信息确认
展示需求详情（名称、描述、处理人、开发人员、测试人员）
人员信息对不对？
如果需求信息不足，AI 会问你 3 个问题：
需求信息不完整，需要补充几个关键点：
5.2.2 第二步：需求拆分
AI 把需求拆成一级任务、二级子任务，输出 working/breakdown.md。
步骤
AI干啥
你要确认啥
两级拆分
拆成一级任务（功能模块）+ 二级子任务（技术动作）
拆分结果对不对？
工时预估
每个一级任务预估工时（0.5h ~ 1 天）
工时合理不？
写入文件
按标准 Schema 写入 breakdown.md
确认无误？
拆分原则：
一级任务：用户可感知的完整功能单元（半天 ~ 1 天可完成）
二级任务：实现一级任务需要的具体代码动作（1 ~ 3 小时可完成）
5.2.3 第三步：Figma 设计稿处理（D2C 精简模式）
如果有 Figma 链接，AI 会调用 D2C Skill（精简模式），生成设计约束文档。
步骤
AI干啥
产出啥
结构梳理
get_design_context+ get_metadata获取组件层级
Figma 节点映射表
素材整理
get_variable_defs提取 Token 映射表
Token 映射表
存量排查
codebase_search查已有组件、图标、样式变量
存量复用清单
产出格式（追加到 breakdown.md 末尾）
5.2.4 第四步：红队验证
拆分完成后，AI 会自己当"对手"，找遗漏场景。
维度
检验目标
示例
数据边界
API 返回的所有可能数据状态
空数据、null、超大数据、网络超时
交互边界
用户可能的所有操作序列
快速连点、加载中操作、离线操作
环境边界
不同运行环境下的兼容性
SSR 兼容性、弱网环境、权限缺失
找完展示给你：【这里是我们linux-tv实际项目的演示图】
请选择下一步操作：
[1] 立即修复所有 P0/P1 问题
[2] 仅修复 P0 问题，P1/P2 标记为技术债
[3] 查看详细报告后再决定
选完后会更新 breakdown.md，把遗漏的场景补进去。
5.2.5 第五步：验收标准生成
拆分确认后，AI 基于 breakdown.md 生成 working/acceptance-criteria.md。
从三个维度推导用例：
维度
来源
产出
功能边界
breakdown.md 一级任务
每个功能 1 个 Happy Path 用例（P0）
数据边界
api-layer.json 的 errorHandling
每个错误码 1 个异常用例（P1）
交互边界
ui-modules.json 的 interactions
每个关键交互 1 个交互用例（P0/P1）
生成示例：
生成后展示给你确认，确认后才继续。
关键设计：每一步都要你确认才继续。因为需求拆分一旦错了，后面所有 AI 生成的代码都会跟着错。
5.2.6 流程图
5.3 方案设计流程
方案设计分 2 步：代码分析 → 方案规划。
5.3.1 第一步：代码分析（Reader）
编码前，AI 先让 code-analyzer（reader）上场，做情报收集。
reader 只干一件事：编码前只读情报收集。
步骤
AI干啥
产出啥
领域模型分析
读 domain-mapping.json、pages.json、api-layer.json
涉及哪些页面/API/组件
代码扫描
用 codebase_search找可复用组件、hooks、工具函数
可复用资产清单
惯用法识别
读 patterns/idioms.md，标注相关条目
相关惯用法列表
技术风险识别
扫描相关文件，找 SSR 兼容性陷阱、跨包依赖等
技术风险清单
产出格式（通过 send_message发给 planner）：
[READER_DONE] task_id=2.1关键设计：reader 不修改任何源码，只收集情报。情报报告会传给 planner，用来做方案。
5.3.2 第二步：方案规划（Planner）
reader 收集完情报后，AI 让 code-planner（planner）上场，出方案。
planner 只干一件事：基于情报产出 impl-plan-{taskId}.md，不修改源码。
步骤
AI干啥
产出啥
读取基础资料
读 breakdown.md、session-state.json、acceptance-criteria.md、adversary-report.md
任务上下文
加载记忆层
读 patterns/anti-patterns.md 和 patterns/idioms.md
禁止事项清单 + 惯用法参考
代码库探查
用 codebase_search找可复用组件、hooks、工具函数
可复用资产清单
Figma 设计约束解析（如有）
读 breakdown.md 末尾的"设计约束"章节，调用 D2C 精简模式获取详细结构
附录 A：Figma 设计约束
起草方案
按标准 Schema 逐节填写 impl-plan-{taskId}.md
完整实现方案
写入文件
把方案写成 working/impl-plan-{taskId}.md
方案文件
展示审批
展示方案摘要，等你审批
你的审批结论
方案文件标准Schema：这里不详细贴了，说白了就是详细描述代码开发的技术方案