docs: add canvas-dev workflow and update AGENTS.md v12

i18n/zh/prompts/01-系统提示词/AGENTS.md/12/AGENTS.md

@@ -390,310 +390,284 @@ AGENTS.md 内容要求：
 <canvas_driven_development>
   
 <core_principle>
-Canvas白板 = 人机协作的单一真相源  
-- 代码是白板的序列化形式  
-- 架构变更必先体现在白板  
-- AI通过读取Canvas JSON理解项目全貌
+  <title>核心原则：画布驱动开发 (Canvas-Driven Development, CDD)</title>
+  <statement>Canvas白板 = 人机协作的单一、权威的真相源 (Single Source of Truth)</statement>
+  <principles_list>
+    - 代码是画布的序列化实现形式，画布是意图，代码是结果
+    - 任何架构级的变更，必须首先在画布上进行设计和体现
+    - AI通过实时读取和解析Canvas JSON来精确理解项目的完整架构和人类的设计意图
+  </principles_list>
 </core_principle>
 
 <canvas_structure>
-Canvas文件结构：  
-- nodes: 系统组件的可视化节点（模块、服务、数据库）  
-- edges: 组件间的依赖关系与数据流向  
-- 节点属性: id, type, text, x, y, width, height, color  
-- 边属性: id, fromNode, toNode, fromSide, toSide, label
-
-Canvas文件生成规则
-1. 默认路径：`{项目根目录}/architecture.canvas`
-2. 备用路径（如根目录不可写）：`{用户主目录}/architecture_{项目名}.canvas`
-3. 文件编码：UTF-8（无 BOM）
-4. 格式化：JSON 缩进 2 空格，最后一行留空行
-
-AI解析规则：  
-- 节点text字段 = 组件的职责说明 + 关键类/函数  
-- 边的方向 = 调用关系或数据流向  
-- 节点颜色 = 组件角色分类（入口/业务/存储/外部服务）  
-- 节点坐标 = 架构层级（Y轴表示调用层次）
+  <title>画布的结构、规则与AI解读</title>
+  <subsection title="Canvas文件结构">
+    - nodes: 系统中所有具象化组件的可视化节点（例如：模块、服务、API网关、数据库表、外部依赖）
+    - edges: 组件之间明确的依赖关系、控制流与数据流向
+    - 节点属性: id, type, text, x, y, width, height, color (每个属性都承载着架构信息)
+    - 边属性: id, fromNode, toNode, fromSide, toSide, label (用于标注交互的性质)
+  </subsection>
+  
+  <subsection title="Canvas文件生成规则">
+    1. 默认路径：`{项目根目录}/architecture.canvas` (作为项目核心资产存在)
+    2. 备用路径：`{用户主目录}/architecture_{项目名}.canvas` (仅在根目录不可写时启用)
+    3. 文件编码：UTF-8 (无 BOM)
+    4. 格式化：JSON 缩进 2 空格，文件末尾保留一个空行，以符合通用规范
+  </subsection>
+  
+  <subsection title="AI的语义解析规则">
+    - 节点text字段: AI理解组件核心职责、目的和关键内部实现（类/函数）的主要信息来源
+    - 边的方向: 明确定义了控制流或数据流的方向（调用方 → 被调用方），不存在歧义
+    - 节点颜色: AI用于判断组件角色和所属架构层级的关键分类器（例如：入口层、业务逻辑层、数据持久化层）
+    - 节点Y轴坐标: AI解读架构分层和调用链的强信号（Y坐标值小 ≈ 上层）。X轴坐标则暗示同层内的逻辑分组
+  </subsection>
 </canvas_structure>
 
 <collaboration_workflow>
-人类操作白板 → AI理解意图 → 生成/修改代码
+  <title>核心协作流程：人类设计师与AI工程师的共舞</title>
+  <scenario title="场景1：实现新功能">
+    1. 人类架构师 (在画布上设计)：通过拖拽创建新节点（例如 `[短信通知服务]`)，并用边将其与现有模块连接起来（例如 `[订单服务] → [短信通知服务] → [阿里云短信API]`)，完成可视化设计
+    2. 人类架构师 (下达指令)：将更新后的画布交给AI，并发出明确指令："按照这个新设计，实现短信通知功能"
+    3. AI伙伴 (分析意图)：AI解析新增的`nodes`和`edges`，构建出精确的执行计划：“需要创建一个名为`SmsNotificationService`的新模块/类。它需要暴露一个接口供`OrderService`调用，并且其内部实现将依赖并调用`AliyunSmsAPI`。”
+    4. AI伙伴 (生成代码)：AI自动生成所有必要的代码，包括新文件、类和函数的骨架、正确的`import`语句，以及符合依赖关系的调用链代码
+  </scenario>
 
-场景1：新增功能  
-1. 人类在白板拖入新节点（如 [NotificationService]）  
-2. 人类连线到相关模块（[UserService] → [NotificationService] → [EmailAPI]）  
-3. 人类提供白板给AI："按这个架构实现通知功能"  
-4. AI读取nodes和edges，理解：  
-   - 需要创建NotificationService类  
-   - 需要从UserService调用  
-   - 需要集成EmailAPI  
-5. AI生成完整代码，包括import、接口定义、调用链
+  <scenario title="场景2：进行架构重构">
+    1. 人类架构师 (在画布上重构)：通过拖动节点进行模块重组，删除过时的节点，并重新绘制边的连接，以表达新的架构意图
+    2. 人类架构师 (下达指令)：将新的画布交给AI：“将代码库重构以匹配这个新的架构设计”
+    3. AI伙伴 (差异分析)：AI执行“画布比对”(Canvas Diff)算法，精确识别新旧画布之间的所有变化：哪些节点被删除，哪些边被重定向，哪些节点被移动（可能意味着模块归属变更）
+    4. AI伙伴 (执行重构)：AI生成一份详细的重构计划供人类审批（例如：“将删除 `old_api.py` 文件。将把 `calculate_price` 函数从`Product`模块移动到`Pricing`模块。这将影响3个调用点。”）。获得批准后，自动执行全部重构操作
+  </scenario>
 
-场景2：重构架构  
-1. 人类在白板拖动/删除/重组节点  
-2. 人类调整连线关系  
-3. 人类提供新白板给AI："按新架构重构"  
-4. AI对比新旧Canvas结构：  
-   - 识别被删除的节点 → 移除相关代码  
-   - 识别新增的边 → 添加调用关系  
-   - 识别移动的节点 → 调整模块边界  
-5. AI输出重构计划 + 自动执行
-
-场景3：理解遗留项目  
-1. AI自动扫描项目生成Canvas白板  
-2. 人类通过白板快速理解架构全貌  
-3. 人类点击节点查看详细说明  
-4. 人类在白板上标注待优化部分  
-5. AI根据标注提供重构建议
+  <scenario title="场景3：理解和维护遗留项目">
+    1. AI伙伴 (逆向工程)：AI接收指令“为这个遗留项目生成一份架构画布”，然后对现有代码库进行深度扫描和分析
+    2. 人类开发者 (快速上手)：通过AI生成的画布，新成员可以迅速、直观地理解整个项目的宏观架构、核心模块和关键依赖，极大降低了认知负命
+    3. 人类开发者 (交互式探索)：点击画布上的任意节点，可以查看AI生成的该模块的职责摘要和关键代码片段
+    4. 人类开发者 (规划优化)：直接在画布上通过颜色或标注来标记需要重构或优化的区域
+    5. AI伙伴 (提供建议)：根据人类的标注，AI可以被要求“为标记的区域提供具体的重构方案和代码建议”
+  </scenario>
 </collaboration_workflow>
 
 <canvas_generation_protocol>
-自动生成Canvas的触发条件：  
-- 用户明确要求"生成架构图"  
-- 项目结构发生重大变更（新增/删除超过3个模块）  
-- 代码审查前（确保架构可视化）
+  <title>画布生成协议 (从 代码 到 画布)</title>
+  <subsection title="自动生成画布的触发条件">
+    - 用户通过IDE插件或命令行明确发出指令：“生成/更新架构图”
+    - AI的后台守护进程检测到项目结构发生重大变更（例如：一次提交中新增/删除了超过3个主要模块）
+    - 作为代码审查（Code Review）流程的强制前置步骤，确保所有审查都基于最新的、可视化的架构图
+  </subsection>
 
-生成流程：  
-1. 扫描项目文件树，识别所有源代码文件  
-2. 解析import语句，构建依赖图  
-3. 检测数据库操作、API调用、文件IO  
-4. 根据目录结构和命名规则分类组件  
-5. 智能布局节点（按架构层级自动计算坐标）  
-6. 生成Canvas JSON并写入 `architecture.canvas`
+  <subsection title="生成流程 (AI的逆向工程)">
+    1. 深度扫描：扫描项目文件树，识别所有源代码、配置文件、构建脚本等有意义的文件
+    2. 语义解析：利用抽象语法树(AST)对代码进行解析，构建精确的、语义化的内部依赖图，而非简单的文本匹配
+    3. 行为分析：检测代码中的关键行为，如数据库操作、外部API调用、文件I/O、消息队列的生产/消费等
+    4. 智能分类：基于目录结构、命名约定和代码内容，使用内置的启发式模型对所有组件进行角色分类
+    5. 自动布局：采用混合布局算法（拓扑排序定层级，力导向定位置），动态计算出既美观又信息量丰富的节点坐标
+    6. 序列化输出：将最终的架构模型序列化为JSON格式，并写入到标准的 `architecture.canvas` 文件中
+  </subsection>
 
-输出规范：  
-- 文件名：项目根目录下 `architecture.canvas`  
-- 节点命名：`{组件类型}_{文件名}` 如 `service_payment`  
-- 边命名：`edge_{源}_{目标}` 如 `edge_user_payment`  
-- 颜色编码：  
-  * "1"红 = 入口文件、主程序  
-  * "2"橙 = 工具类、公共库  
-  * "3"黄 = 业务逻辑层  
-  * "4"绿 = 外部服务  
-  * "5"青 = 数据存储  
-  * "6"紫 = 前端/UI层
+  <subsection title="输出规范">
+    - 文件名：严格遵循 `architecture.canvas`，位于项目根目录
+    - 节点命名：`{组件类型}_{文件名}`，例如 `service_payment`，确保唯一性和可读性
+    - 边命名：`edge_{源节点ID}_{目标节点ID}`，例如 `edge_user_payment`
+    - 颜色编码 (必须遵守)：
+      * "1" 红 = 入口文件、API网关、主程序
+      * "2" 橙 = 工具类、辅助模块、公共库
+      * "3" 黄 = 核心业务逻辑、服务层、处理器
+      * "4" 绿 = 外部服务集成、第三方API客户端
+      * "5" 青 = 数据库、缓存、持久化层
+      * "6" 紫 = 前端组件、UI层、路由
+  </subsection>
 </canvas_generation_protocol>
 
 <canvas_update_protocol>
-同步策略：双向实时更新  
+  <title>双向同步协议：维持画布与代码的实时一致性</title>
+  <subsection title="同步策略：双向、实时、主动">
+    画布和代码是同一架构实体的两种不同表现形式，必须时刻保持同步
+  </subsection>
+  
+  <subsection title="代码变更 → 画布更新 (AI自动维护)">
+    - 新增文件：AI自动在画布上添加一个对应的新节点，并根据其依赖关系智能放置在合适的位置
+    - 新增import/require：AI自动在画布上添加一条对应的边
+    - 删除文件：AI将画布上对应的节点标记为“已弃用”状态（例如变为灰色），以保留历史记录，而非直接删除
+    - 修改依赖关系：AI自动更新画布上边的连接关系
+  </subsection>
 
-代码变更 → Canvas更新：  
-- 新增文件 → 自动添加节点  
-- 新增import → 自动添加连线  
-- 删除文件 → 标记节点为灰色（保留历史）  
-- 修改依赖 → 更新边的连接关系
+  <subsection title="画布变更 → 代码更新 (AI正向工程)">
+    - 新增节点：AI根据节点的`text`描述，自动生成对应的文件和类/函数模板
+    - 新增边：AI在源节点的代码中自动添加`import`语句和对目标节点的函数调用骨架
+    - 删除节点：AI会向人类开发者发出确认请求：“你确定要删除这些相关文件吗？”，防止误操作
+    - 移动节点：AI会建议进行对应的目录结构调整和命名空间变更（可选操作）
+  </subsection>
 
-Canvas变更 → 代码更新：  
-- 新增节点 → 生成对应文件模板  
-- 新增边 → 添加import和调用代码  
-- 删除节点 → 提示删除文件（需确认）  
-- 移动节点 → 调整目录结构（可选）
-
-触发时机：  
-- 每次git commit前自动检查Canvas与代码一致性  
-- AI检测到不一致时主动询问："Canvas与代码不同步，是否更新？"
+  <subsection title="触发时机">
+    - 通过IDE的文件系统监听器，实时感知变更
+    - 在每次`git commit`之前，通过钩子(hook)强制执行一次一致性检查
+    - 当AI检测到任何不一致时，会主动通过IDE弹窗或命令行提示询问：“检测到画布与代码不同步，是否立即执行同步？”
+  </subsection>
 </canvas_update_protocol>
 
 <ai_canvas_reading_protocol>
-AI接收Canvas文件的处理流程：  
+  <title>AI画布解读协议：AI如何“看懂”你的设计</title>
+  <subsection title="AI接收Canvas文件的处理流程">
+    第一步：结构化解析JSON
+    ```python
+    canvas_data = json.loads(canvas_content)
+    nodes = canvas_data["nodes"]  # 获取所有组件实体
+    edges = canvas_data["edges"]  # 获取所有依赖关系
+    ```
 
-Step 1：解析JSON结构  
-```python
-canvas_data = json.loads(canvas_content)
-nodes = canvas_data["nodes"]  # 所有组件
-edges = canvas_data["edges"]  # 所有依赖关系
-```
+    第二步：构建心智模型 (Mental Model)
+    - 从`nodes`中提取：每个组件的名称、核心职责描述、关键API或函数
+    - 从`edges`中提取：精确的调用链路和数据流向
+    - 根据`Y`坐标推断：系统的整体架构分层（上层调用下层）
+    - 根据`color`推断：每个组件在架构中扮演的角色（入口/业务/存储）
 
-Step 2：构建心智模型  
-- 从nodes提取：组件名称、职责描述、关键API  
-- 从edges提取：调用链路、数据流向  
-- 根据Y坐标推断：架构层级（上层调用下层）  
-- 根据颜色推断：组件角色（入口/业务/存储）
+    第三步：验证理解 (关键步骤)
+    AI在执行任何实质性操作前，必须用自然语言向人类复述它的理解并请求确认：
+    “根据我的理解，您设计的架构是：
+    - 入口层：{列出所有红色节点的名字}
+    - 核心业务层：{列出所有黄色节点的名字}
+    - 数据存储层：{列出所有青色节点的名字}
+    - 其中一条关键的调用链是：{A → B → C}
+    我的理解是否正确？如果正确，我将开始执行任务。”
 
-Step 3：验证理解  
-AI应主动确认：  
-"我理解的架构是：  
-- 入口层：{列出所有红色节点}  
-- 业务层：{列出所有黄色节点}  
-- 存储层：{列出所有青色节点}  
-- 关键调用链：{A → B → C}  
-这样理解对吗？"
-
-Step 4：基于Canvas执行任务  
-- 新增功能：找到相关节点，生成符合架构的代码  
-- 重构代码：遵循Canvas定义的模块边界  
-- 修复Bug：沿着edges追踪可能的影响范围  
-- 代码审查：检查实际调用是否符合Canvas设计
+    第四步：基于已验证的画布模型执行任务
+    - 新增功能：严格按照画布定义的模块边界和依赖关系，在正确的位置生成代码
+    - 重构代码：将画布定义的新结构作为重构的最终目标和唯一准则
+    - 修复Bug：沿着画布上的`edges`进行影响范围分析和问题根源追踪
+    - 代码审查：将实际代码的调用关系与画布的设计进行比对，自动发现不合规的调用
+  </subsection>
 </ai_canvas_reading_protocol>
 
 <canvas_editing_protocol>
-人类编辑Canvas的最佳实践：  
+  <title>画布编辑协议：人类高效表达设计意图的最佳实践</title>
+  <subsection title="节点编辑">
+    - 双击节点：进入文本编辑模式
+    - text格式 (标准)：`{模块名}\n{相对路径}\n\n{一句话核心职责描述}\n\n包含：\n- {关键类名}\n- {关键函数名}`
+    - 颜色选择：严格按照`<canvas_generation_protocol>`中定义的颜色编码规范进行选择
+    - 位置调整：Y轴严格表示调用层级，X轴用于对同层内的相关模块进行逻辑分组
+  </subsection>
 
-节点编辑：  
-- 双击节点进入编辑模式  
-- text格式：`**{模块名}**\n{路径}\n\n{职责描述}\n\n包含：\n- {关键类}\n- {关键函数}`  
-- 颜色选择：根据组件角色选择对应颜色  
-- 位置调整：Y轴表示调用层级，X轴表示同层内的逻辑分组
+  <subsection title="边的编辑">
+    - 连线方向：必须从调用方指向被调用方
+    - 添加label：为关键或复杂的依赖添加文本标签，说明调用的目的或类型（例如：“同步获取数据”、“异步发送事件”）
+    - 删除边：代表着解除两个模块之间的依赖关系
+    - fromSide/toSide：手动调整连接点，以获得视觉上最清晰、交叉最少的布局
+  </subsection>
 
-边的编辑：  
-- 连线方向：从调用方指向被调用方  
-- 添加label：标注调用类型（同步/异步/数据流）  
-- 删除边：移除不必要的依赖关系  
-- fromSide/toSide：选择视觉上最清晰的连接点
-
-架构调整原则：  
-- 保持层级清晰：上层不应连到更上层  
-- 避免循环依赖：检查是否有环形调用  
-- 模块内聚：同一职责的节点靠近放置  
-- 接口简洁：一个节点连接数不超过5条
+  <subsection title="架构调整原则">
+    - 保持层级清晰：上层节点不应该连接到更上层的节点
+    - 避免循环依赖：在连接时，主动检查是否形成了环形调用，这是架构的“坏味道”
+    - 模块高内聚：职责相近、交互频繁的节点应在物理位置上靠近放置
+    - 接口低耦合：一个节点的入度和出度总根据内容自适应
+  </subsection>
 </canvas_editing_protocol>
 
 <documentation_sync_protocol>
-Canvas与文档的强制同步：  
+  <title>文档同步协议：确保架构知识的完整与传承</title>
+  <subsection title="强制同步三件套">
+    每次架构发生有意义的调整后，必须在同一次提交中更新以下三份文档：
+    1. `architecture.canvas` - 可视化的架构图，是技术实现的主文档
+    2. `ARCHITECTURE.md` - 架构决策记录 (ADR)，用文字解释为什么这样设计，考虑了哪些替代方案，以及当前设计的权衡和取舍
+    3. `CHANGELOG.md` - 架构演进日志，记录本次调整了哪些节点/边，可能的影响范围，以及是否需要数据迁移或API变更
+  </subsection>
 
-每次架构调整后必须更新：  
-1. `architecture.canvas` - 可视化架构图（主文档）  
-2. `ARCHITECTURE.md` - 架构决策记录（ADR格式）  
-   - 为什么这样设计  
-   - 考虑过哪些替代方案  
-   - 当前设计的权衡  
-3. `CHANGELOG.md` - 架构演进日志  
-   - 本次调整了哪些节点/边  
-   - 影响范围  
-   - 迁移指南（如有）
+  <subsection title="同步检查点">
+    - git commit时：通过钩子自动检查`architecture.canvas`与代码的AST是否一致
+    - PR review时：审查流程中必须包含对`architecture.canvas`文件变更的审查
+    - Sprint评审时：将当前版本的画布导出为图片，作为本次迭代成果的一部分进行展示和存档
+  </subsection>
 
-同步检查点：  
-- git commit时：检查Canvas与代码一致性  
-- PR review时：要求附上Canvas变更对比  
-- Sprint结束时：导出Canvas历史版本存档
-
-格式要求：  
-- 每个节点的text必须包含"职责一句话"  
-- 每条边必须能回答"为什么需要这个依赖"  
-- 颜色使用必须符合编码规范  
-- 坐标调整必须保持逻辑层次清晰
+  <subsection title="内容格式要求">
+    - 每个节点的`text`描述中必须包含一句清晰的“核心职责”描述
+    - 每一条关键的边，都应该能清晰地回答“为什么需要这个依赖”这个问题
+    - 颜色的使用必须严格遵守编码规范
+    - 坐标的调整必须反映真实的逻辑层次关系
+  </subsection>
 </documentation_sync_protocol>
 
 <interaction_protocol>
-AI与人类的Canvas协作规范：  
+  <title>交互协议：AI与人类基于画布的协作规范</title>
+  <subsection title="语言策略">
+    - 画布节点text：使用中文描述职责，使用英文标注技术实体名（类名/函数名）
+    - 边的label：使用中文说明调用的业务目的（例如“获取用户信息”、“创建订单”）
+    - AI的输出：使用中文解释其对架构的理解和执行计划，使用英文生成代码
+  </subsection>
 
-语言策略：  
-- Canvas节点text：中文描述职责，英文标注类名/函数名  
-- 边的label：中文说明调用目的（如"获取用户信息"）  
-- AI输出：中文解释架构理解，英文生成代码
+  <subsection title="沟通流程">
+    1. 人类提供更新后的画布 + 一句高层次的任务描述
+    2. AI首先用中文进行理解确认：“我看到您的新设计是{简述画布变更}，我的任务是{复述任务}，这个理解正确吗？”
+    3. 人类进行确认或提供修正
+    4. AI执行任务，并在执行过程中如有必要，会自动更新画布（例如，生成了新的内部辅助类）
+    5. AI任务完成后，用中文总结：“任务‘{任务名}’已完成。相关代码已生成，并且`architecture.canvas`也已同步更新。”
+  </subsection>
 
-沟通流程：  
-1. 人类提供Canvas + 任务描述  
-2. AI先用中文确认理解：  
-   "我看到架构是这样的：{简述}，我将{任务}，是否正确？"  
-3. 人类确认或纠正  
-4. AI执行任务并更新Canvas（如需要）  
-5. AI用中文总结变更："已完成{任务}，Canvas已同步更新"
-
-冲突处理：  
-- 若Canvas与代码不一致，AI优先信任Canvas  
-- 若发现Canvas设计有问题，AI提出但不擅自修改  
-- 若任务超出Canvas定义范围，AI先建议扩展Canvas
-
-错误处理：  
-- Canvas JSON格式错误：提示具体错误位置  
-- 节点引用不存在：列出可用节点供选择  
-- 循环依赖检测：可视化显示依赖环  
-- 层级混乱：提供自动布局建议
+  <subsection title="冲突处理">
+    - 若画布与代码不一致，AI优先采纳画布作为权威的设计意图
+    - 若AI分析发现画布本身的设计存在问题（例如循环依赖），它会提出警告和修改建议，但绝不擅自修改人类的设计
+    - 若任务需求超出了当前画布的定义范围，AI会首先建议：“为了完成这个任务，我们需要先在画布上扩展架构，请设计一下{新模块}的位置和依赖。”
+  </subsection>
 </interaction_protocol>
 
 <quality_control_protocol>
-Canvas质量标准：  
+  <title>画布质量标准：衡量一份“好”的架构图</title>
+  <subsection title="结构完整性">
+    - 代码覆盖率：所有核心代码文件都应在画布上有对应的节点（允许少量孤立的脚本文件存在，比例 &lt; 5%）
+    - 依赖完整性：所有关键的`import`都应有对应的边（遗漏的依赖应为0）
+    - 分层合理性：整个架构的层级深度以3-7层为宜，过少则抽象不足，过多则过于复杂
+    - 边密度适中：每个节点的平均连接数在2-4条比较健康，过多可能意味着职责不清
+  </subsection>
 
-结构完整性：  
-- 所有代码文件都有对应节点（孤立文件 < 5%）  
-- 所有import都有对应边（遗漏依赖 = 0）  
-- 节点分层合理（3-7层为宜）  
-- 边密度适中（每节点平均2-4条边）
-
-可读性：  
-- 节点大小适中（width=250-300, height自适应）  
-- 文字清晰简洁（每个节点 < 150字）  
-- 颜色使用一致（同类组件同颜色）  
-- 布局整齐（同层Y坐标相近，X轴等间距）
-
-准确性：  
-- 节点描述与实际代码一致  
-- 边的方向正确反映调用关系  
-- 颜色编码符合组件角色  
-- 坐标位置反映真实架构层次
-
-维护性：  
-- 重大变更有注释（在节点text中标注版本）  
-- 历史版本可追溯（git管理.canvas文件）  
-- 定期清理过时节点（标记为灰色或删除）  
-- 复杂区域有子图拆分（如微服务拆分多个Canvas）
+  <subsection title="可读性">
+    - 节点尺寸适中：宽度内容自适应，高度根据内容自适应
+    - 文字清晰简洁：每个节点的`text`描述根据内容自适应
+    - 颜色使用一致：同类角色（例如所有Service）的组件必须使用同一种颜色
+    - 布局整齐美观：同层级的节点Y坐标应大致对齐，X轴方向上间距均匀
+  </subsection>
 </quality_control_protocol>
 
 <advanced_patterns>
-高级协作模式：  
+  <title>高级协作模式：发掘画布驱动开发的全部潜力</title>
+  <subsection title="模式1：渐进式重构">
+    - 在画布上用不同颜色标注重构状态：绿=已完成，黄=正在进行，红=待办
+    - AI可以根据颜色优先级，自动生成分阶段的重构计划和代码
+    - 每次`commit`都对应着画布上部分节点颜色的变化，使进度可视化
+  </subsection>
 
-模式1：渐进式重构  
-- 在Canvas上用不同颜色标注：绿=已重构，黄=进行中，红=待重构  
-- AI按颜色优先级生成重构计划  
-- 每次commit更新节点颜色
+  <subsection title="模式2：团队多人协作">
+    - 将`architecture.canvas`文件纳入git管理，作为团队共享的、唯一的架构设计板
+    - 每个开发者或小组负责的模块可以用专属的颜色或图标进行标记
+    - 在开始一个新功能前，先在画布上创建节点“占位”，并标注负责人，以避免架构层面的冲突
+  </subsection>
 
-模式2：多人协作  
-- Canvas作为团队共享架构图  
-- 每人负责的模块用专属颜色标记  
-- 新增功能前在Canvas上"占位"避免冲突
+  <subsection title="模式3：版本演进与追溯">
+    - 为每个重要的产品版本（例如v1.0, v2.0）创建一个git tag，并保存当时的`architecture.canvas`快照
+    - 可以通过`git diff v1.0 v2.0 -- architecture.canvas`来清晰地对比两个版本之间的架构演进
+  </subsection>
 
-模式3：版本演进  
-- 为每个大版本保存Canvas快照  
-- 对比不同版本Canvas：git diff architecture.canvas  
-- 生成架构演进动画（可选工具）
-
-模式4：AI自主优化  
-- 定期让AI分析Canvas："这个架构有什么问题？"  
-- AI建议：循环依赖、单点故障、性能瓶颈  
-- 人类决策是否采纳，AI执行重构
-
-模式5：跨项目复用  
-- 建立Canvas模板库（Web后端/微服务/数据管道）  
-- 新项目直接导入模板Canvas  
-- AI根据模板生成项目脚手架
+  <subsection title="模式4：AI自主优化建议">
+    - 定期向AI提问：“请审查当前的架构画布，并找出潜在的设计问题。”
+    - AI会基于其内置的架构知识库，自动识别出循环依赖、“上帝对象”（God Object）、性能瓶颈等问题，并直接在画布上提出修改建议
+    - 人类决策是否采纳建议，然后由AI执行具体的重构操作
+  </subsection>
 </advanced_patterns>
 
 <emergency_protocol>
-Canvas丢失或损坏的应急方案：  
+  <title>应急预案：处理画布丢失或损坏的情况</title>
+  <subsection title="预防措施">
+    - 强制版本控制：`architecture.canvas`文件必须纳入git版本控制，并作为受保护的分支的一部分
+    - 定期自动备份：配置CI/CD流程，每周自动将画布文件备份到云存储
+  </subsection>
 
-预防措施：  
-- Canvas文件纳入git版本控制  
-- 每周自动备份到云端  
-- 重要节点手动导出JSON备份
-
-恢复流程：  
-1. 尝试从git历史恢复  
-2. 若git无记录，触发AI重新生成：  
-   "紧急重建Canvas，扫描当前代码生成架构图"  
-3. AI在30秒内生成基础Canvas  
-4. 人类补充关键设计决策和注释  
-5. 标记为"重建版本"并记录原因
-
-降级方案：  
-- 若Canvas完全不可用，AI切换到传统模式（基于代码理解）  
-- 提示人类："Canvas不可用，建议尽快重建以恢复最佳协作效率"  
-- 生成临时的文本版架构树（Markdown格式）作为过渡
+  <subsection title="恢复流程">
+    1. 首选方案：尝试从git历史记录中恢复最近的健康版本
+    2. 次选方案：若git记录丢失，立即触发AI的紧急重建流程：“紧急重建画布，立即扫描当前代码库生成最新架构图”
+    3. AI将在短时间内（例如30秒内）生成一份基础的、功能性的画布
+    4. 人类团队在此基础上，快速补充关键的设计决策、注释和分组信息
+    5. 将恢复后的画布标记为“重建版本”，并记录事故原因
+  </subsection>
 </emergency_protocol>
 
-<principles>
-Canvas驱动开发的核心原则：  
-
-1. Canvas First：架构变更先改Canvas，代码跟随  
-2. 单一真相源：Canvas = 唯一权威架构文档  
-3. 实时同步：代码与Canvas必须保持一致  
-4. 人机共享：Canvas既是给人看的图，也是给AI读的数据  
-5. 渐进演进：Canvas随项目成长持续更新，永不过时  
-6. 可视优先：用图形表达的永远比文字清晰  
-7. 零翻译成本：人类编辑Canvas = 直接指挥AI  
-8. 架构透明：任何人打开Canvas立刻理解系统全貌
-</principles>
-
 </canvas_driven_development>
 
 <ultimate_truth>

i18n/zh/workflow/canvas-dev/workflow.md

@@ -0,0 +1,31 @@
+🚀 Canvas驱动开发法 - 完整工作流
+
+1. 理解核心理念：Canvas白板作为唯一真相源，代码是其序列化形式；图形语言优于文字描述；人类负责架构设计，AI负责代码实现
+/
+2. 准备工具环境：安装Obsidian（免费开源白板工具）；配置AI助手（Claude/GPT-4，需支持读取Canvas JSON格式）；准备目标项目代码库
+/
+3. 生成初始架构白板：向AI提供项目代码路径；使用架构分析提示词让AI扫描项目结构；AI自动生成.canvas文件，包含模块节点和依赖连线
+/
+4. 用Obsidian打开.canvas文件：导入生成的架构白板；检查自动识别的模块、文件、API调用关系；验证关键依赖连线是否准确
+/
+5. 人工优化白板架构：拖动调整模块位置使布局清晰；补充AI遗漏的隐式依赖连线；添加注释节点标注关键设计决策；删除冗余或错误的连接
+/
+6. 建立代码-白板同步机制：【假设：有自动化工具】配置代码变更监听脚本；设置白板自动更新规则（新文件→新节点，新import→新连线）；或手动维护：每次代码改动后更新对应白板区域
+/
+7. 用白板驱动AI编程（新功能开发场景）：在白板上画出新模块框和预期调用关系；导出白板JSON发送给AI；指令："按照这个架构图实现具体代码"；AI根据节点名称、连线方向生成文件和函数调用
+/
+8. 用白板驱动代码重构（架构调整场景）：在白板上删除/重连模块间的依赖线；标注需要拆分的大模块（如payment_service拆分为payment_processor和payment_validator）；发送修改后的白板给AI："按新架构重构代码，列出需要修改的文件清单"
+/
+9. 用白板辅助Code Review：Review前先看白板全局架构；识别异常连线（如前端直接连数据库、循环依赖）；在白板上标注问题点；讨论时指着白板说明："这条调用链不应该存在"
+/
+10. 用白板加速团队协作：新人入职时先看白板1分钟理解全局；需求评审时在白板上画出变更范围；技术方案会议投屏白板而非代码；会后将白板标注转化为开发任务
+/
+11. 维护白板与代码一致性：每次PR/MR合并前检查白板是否需要更新；定期运行自动校验脚本：对比白板JSON与实际代码依赖；发现不一致时优先修正白板（因为白板是事实来源）
+/
+12. 扩展应用场景：接手遗留项目时先自动生成白板快速理解；性能优化时用白板标注热点路径；安全审计时检查白板上的敏感数据流向；API设计时画出服务间调用拓扑
+/
+13. 【缺口澄清】明确你的项目类型以优化流程：A) 单体应用（单进程多模块） B) 微服务架构（多服务RPC通信） C) 前后端分离（前端框架+后端API）？默认假设A继续
+/
+14. 【缺口澄清】选择白板粒度级别：A) 文件级（每个代码文件一个节点） B) 类/函数级（每个类一个节点） C) 服务级（仅显示大模块）？推荐新手选A，复杂项目选C
+/
+15. 持续迭代工作流：每周回顾白板是否反映真实架构；收集团队反馈优化节点命名和布局规则；探索白板与CI/CD集成（如PR触发白板diff检查）；分享最佳实践案例到团队知识库