gavindiaz/vibe-coding-cn
1
0
Fork 0
mirror of https://github.com/tradecatlabs/vibe-coding-cn.git synced 2026-08-13 10:58:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: assets - retire canvas workflow and document repo sources

Browse Source
This commit is contained in:
tukuaiai
2026-04-28 19:14:25 +08:00
parent 7dd36d6dd3
commit f7d1828dcd
28 changed files with 77 additions and 1988 deletions
Download Patch File Download Diff File Expand all files Collapse all files
assets/documents/guides/playbook/README.md
-1
View File
@@ -4,7 +4,6 @@
## 🎨 AI 协作范式
- [Canvas白板驱动开发](./图形化AI协作-Canvas白板驱动开发.md) - 图形是第一公民，代码是白板的序列化形式
- [AI蜂群协作](./AI蜂群协作-tmux多Agent协作系统.md) - 基于 tmux 的多 AI Agent 协作系统
## 📖 工具教程
assets/documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md
-194
View File
@@ -1,194 +0,0 @@
# 🚀 Canvas白板驱动开发法
## 从文字到图形：编程协作的新范式
### 💡 核心发现
传统开发流程：
```
写代码 → 口头沟通 → 脑补架构 → 代码失控 → 重构崩溃
```
**新方法**：
```
代码 ⇄ Canvas白板 ⇄ AI ⇄ 人类
↓
单一事实来源
```
---
### 🎯 这套方法解决了什么？
**痛点1：AI看不懂你的项目结构**
- ❌ 以前：反复解释"这个文件干什么的"
- ✅ 现在：AI直接看白板，秒懂整体架构
**痛点2：人类记不住复杂依赖**
- ❌ 以前：改A文件忘了B依赖它，炸了
- ✅ 现在：白板连线清晰，牵一发动全身一目了然
**痛点3：团队协作靠嘴说**
- ❌ 以前："数据流怎么走的？""呃...让我翻翻代码"
- ✅ 现在：指着白板讲，新人5分钟看懂
---
### 🔥 工作流演示
#### Step 1：写代码时自动更新白板
```python
# 你写了新文件 payment_service.py
class PaymentService:
def process(self):
db.save() # ← AI检测到数据库写入
stripe.charge() # ← AI检测到外部API调用
```
**白板自动生成：**
```
[PaymentService] ──写入──> [数据库]
│
└──调用──> [Stripe API]
```
#### Step 2：人类和AI共同编辑白板
**你在白板上拖拽**：
- 把 `UserService` 连线到 `PaymentService`
- AI立刻理解："哦，用户模块会调用支付"
**AI读懂意图后生成代码**：
```python
# user_service.py
from payment_service import PaymentService
def create_order(user):
payment = PaymentService()
payment.process(user.card) # ← AI自动加这行
```
#### Step 3：白板成为开发中枢
| 操作 | 传统方式 | Canvas方式 |
|------|----------|------------|
| 要求AI重构 | "把支付逻辑拆出来" | 在白板拖出新节点，AI自动拆分代码 |
| Code Review | 逐行读代码 | 看白板连线："这条调用链合理吗？" |
| 需求变更 | 到处改代码 | 白板删条线，AI同步删除所有相关调用 |
---
### 🌟 关键创新点
#### 1. 图形是第一公民，代码是衍生物
传统思维：代码 → 文档（过期） → 架构图（更过期）
新思维：**Canvas白板 = 唯一真相源**，代码只是它的序列化形式
#### 2. 人类和AI的共享工作区
- 人类：擅长高层设计，在白板拖拽模块
- AI：擅长细节实现，根据白板连线生成代码
- 协作方式：**都编辑同一个白板**，而不是来回传递文本
#### 3. 实时双向同步
```
代码变化 ──自动扫描──> 更新白板
白板编辑 ──AI解析──> 生成/修改代码
```
---
### 🎨 使用场景
#### 场景1：给AI派活
传统：
> "帮我写个用户注册功能，要连数据库，发邮件，记日志"
Canvas方式：
1. 在白板画3个框：`RegisterAPI` → `Database` / `EmailService` / `Logger`
2. 告诉AI："按这个图实现"
3. AI一次性写对所有文件和调用关系
#### 场景2：Code Review
传统：一行行看代码，看晕了
Canvas方式：
1. 看白板："咦，为什么前端直接连数据库？"
2. 拖动节点调整架构
3. AI自动重构代码
#### 场景3：接手他人项目
传统：看3天代码还没懂
Canvas方式：
1. 运行自动生成工具 → 1分钟得到架构白板
2. 点开感兴趣的模块看详情
3. 直接在白板上画出要改的部分，AI帮你定位代码位置
---
### 🚀 立即开始
#### 工具链
- **白板**：Obsidian Canvas（免费开源）
- **自动生成**：提示词驱动（见下方）
- **AI协作**：Claude / GPT-4（能读取Canvas JSON）
#### 5分钟体验流程
```bash
# 1. 在你的项目运行自动分析
[用提示词让AI生成架构白板]
# 2. 用Obsidian打开生成的 .canvas 文件
# 3. 尝试拖动模块或添加连线
# 4. 把修改后的白板发给AI："按照这个新架构重构代码"
```
---
### 💬 这是编程的未来吗？
我认为是的，原因：
1. **图形语言是人类大脑的母语**
- 你能瞬间理解地铁线路图
- 但看不懂等效的换乘文字说明
2. **AI已经足够聪明去"看懂"图**
- Canvas就是结构化的图形数据
- AI解析JSON比解析你的自然语言描述准确10倍
3. **代码生成已经商品化，架构设计才是稀缺能力**
- 未来程序员的工作：设计白板架构
- AI的工作：把白板翻译成代码
---
### 📌 金句总结
> "当代码变成白板上的方块，编程就从打字变成了搭积木。"
> "最好的文档不是Markdown，是能直接驱动AI工作的架构图。"
> "AI看懂你的图，比看懂你的话，容易一万倍。"
---
### 🔗 相关资源
- [Canvas白板生成提示词](https://docs.google.com/spreadsheets/d/1Ifk_dLF25ULSxcfGem1hXzJsi7_RBUNAki8SBCuvkJA/edit?gid=1777853069#gid=1777853069&range=A1) - 自动生成架构白板的完整提示词
- [白板驱动开发系统提示词（在线提示词库入口）](../../../prompt/README.md) - 系统提示词已迁移到云端表格
- [Obsidian Canvas 官方文档](https://obsidian.md/canvas)
- [胶水编程](../../principles/fundamentals/胶水编程.md) - 能抄不写，能连不造
- [通用项目架构模板](../../principles/fundamentals/通用项目架构模板.md) - 标准化目录结构
assets/documents/workflow/AGENTS.md
-5
View File
@@ -19,11 +19,6 @@ assets/documents/workflow/
│ ├── .kiro/ # Kiro 集成配置
│ ├── workflow_engine/ # 轻量状态机引擎（state + hook）
│ └── workflow-orchestrator/ # 编排技能文档与规范
└── canvas-dev/ # Canvas 白板驱动开发工作流
├── README.md
├── prompts/
├── templates/
└── examples/
```
## 操作规范
assets/documents/workflow/README.md
-1
View File
@@ -16,7 +16,6 @@ assets/documents/workflow/
| 工作流 | 说明 |
|--------|------|
| [auto-dev-loop](./auto-dev-loop/) | 基于状态机+Hook的五步AI Agent闭环开发流程 |
| [canvas-dev](./canvas-dev/) | Canvas白板驱动开发工作流（AI架构总师） |
## 添加新工作流
assets/documents/workflow/canvas-dev/Obsidian Canvas AI驱动的项目架构洞察与生成引擎.md
-1
View File
File diff suppressed because one or more lines are too long
assets/documents/workflow/canvas-dev/README.md
-56
View File
@@ -1,56 +0,0 @@
# 🎨 Canvas白板驱动开发工作流
> 图形是第一公民，代码是白板的序列化形式
## 核心理念
```
传统开发：代码 → 口头沟通 → 脑补架构 → 代码失控
Canvas方式：代码 ⇄ 白板 ⇄ AI ⇄ 人类（白板为单一真相源）
```
| 痛点 | 解法 |
|:---|:---|
| 🤖 AI看不懂项目结构 | ✅ AI直接读白板JSON，秒懂架构 |
| 🧠 人类记不住复杂依赖 | ✅ 连线清晰，牵一发动全身一目了然 |
| 💬 团队协作靠嘴说 | ✅ 指着白板讲，新人5分钟看懂 |
## 文件结构
```
canvas-dev/
├── README.md # 本文件 - 工作流概述
├── workflow.md # 完整工作流步骤（线性流程）
├── prompts/
│ ├── 01-架构分析.md # 从代码生成白板的提示词
│ ├── 02-白板驱动编码.md # 根据白板生成代码的提示词
│ └── 03-白板同步检查.md # 校验白板与代码一致性
├── templates/
│ ├── project.canvas # Obsidian Canvas 项目模板
│ └── module.canvas # 单模块白板模板
└── examples/
└── demo-project.canvas # 示例项目白板
```
## 快速开始
### 1. 准备工具
- [Obsidian](https://obsidian.md/) - 免费开源白板工具
- AI助手（Claude/GPT-4，需支持读取Canvas JSON）
### 2. 生成项目架构白板
```bash
# 将项目代码路径提供给AI，使用架构分析提示词
# AI自动生成 .canvas 文件
```
### 3. 用白板驱动开发
- 在白板上画出新模块和依赖关系
- 导出白板JSON发送给AI
- AI根据白板生成/修改代码
## 相关文档
- [Canvas白板驱动开发详解](../../guides/playbook/图形化AI协作-Canvas白板驱动开发.md)
- [白板驱动开发系统提示词（在线提示词库入口）](../../../prompt/README.md)
- [胶水编程](../../principles/fundamentals/胶水编程.md)
assets/documents/workflow/canvas-dev/examples/demo-project.canvas
-281
View File
@@ -1,281 +0,0 @@
{
"nodes": [
{
"id": "title",
"type": "text",
"x": -100,
"y": -350,
"width": 400,
"height": 60,
"text": "# 📦 电商系统架构白板\n\n演示项目 - 用户、商品、订单管理"
},
{
"id": "group-frontend",
"type": "group",
"x": -600,
"y": -250,
"width": 250,
"height": 500,
"label": "🖥️ 前端"
},
{
"id": "group-api",
"type": "group",
"x": -300,
"y": -250,
"width": 250,
"height": 500,
"label": "🌐 API网关"
},
{
"id": "group-service",
"type": "group",
"x": 0,
"y": -250,
"width": 300,
"height": 500,
"label": "⚙️ 业务服务"
},
{
"id": "group-infra",
"type": "group",
"x": 350,
"y": -250,
"width": 300,
"height": 500,
"label": "🔧 基础设施"
},
{
"id": "fe-web",
"type": "text",
"x": -580,
"y": -200,
"width": 210,
"height": 80,
"text": "# Web App\n\nReact + TypeScript"
},
{
"id": "fe-mobile",
"type": "text",
"x": -580,
"y": -100,
"width": 210,
"height": 80,
"text": "# Mobile App\n\nReact Native"
},
{
"id": "api-gateway",
"type": "text",
"x": -280,
"y": -200,
"width": 210,
"height": 100,
"text": "# API Gateway\n\n- 路由分发\n- 认证鉴权\n- 限流熔断"
},
{
"id": "svc-user",
"type": "text",
"x": 20,
"y": -200,
"width": 260,
"height": 100,
"text": "# UserService\n\n- 用户注册/登录\n- 个人信息管理\n- 权限校验"
},
{
"id": "svc-product",
"type": "text",
"x": 20,
"y": -80,
"width": 260,
"height": 100,
"text": "# ProductService\n\n- 商品CRUD\n- 库存管理\n- 分类搜索"
},
{
"id": "svc-order",
"type": "text",
"x": 20,
"y": 40,
"width": 260,
"height": 100,
"text": "# OrderService\n\n- 下单流程\n- 订单状态机\n- 退款处理"
},
{
"id": "svc-payment",
"type": "text",
"x": 20,
"y": 160,
"width": 260,
"height": 80,
"text": "# PaymentService\n\n- 支付网关对接\n- 账单管理"
},
{
"id": "infra-db",
"type": "text",
"x": 370,
"y": -200,
"width": 260,
"height": 80,
"text": "# PostgreSQL\n\n主数据库",
"color": "4"
},
{
"id": "infra-cache",
"type": "text",
"x": 370,
"y": -100,
"width": 260,
"height": 80,
"text": "# Redis\n\n缓存 + 会话",
"color": "1"
},
{
"id": "infra-mq",
"type": "text",
"x": 370,
"y": 0,
"width": 260,
"height": 80,
"text": "# RabbitMQ\n\n异步消息队列",
"color": "2"
},
{
"id": "infra-es",
"type": "text",
"x": 370,
"y": 100,
"width": 260,
"height": 80,
"text": "# Elasticsearch\n\n商品搜索引擎",
"color": "5"
},
{
"id": "external-stripe",
"type": "text",
"x": 370,
"y": 200,
"width": 260,
"height": 60,
"text": "# Stripe API\n\n外部支付服务",
"color": "6"
}
],
"edges": [
{
"id": "e-web-gw",
"fromNode": "fe-web",
"toNode": "api-gateway",
"fromSide": "right",
"toSide": "left",
"label": "HTTP"
},
{
"id": "e-mobile-gw",
"fromNode": "fe-mobile",
"toNode": "api-gateway",
"fromSide": "right",
"toSide": "left",
"label": "HTTP"
},
{
"id": "e-gw-user",
"fromNode": "api-gateway",
"toNode": "svc-user",
"fromSide": "right",
"toSide": "left",
"label": "/users/*"
},
{
"id": "e-gw-product",
"fromNode": "api-gateway",
"toNode": "svc-product",
"fromSide": "right",
"toSide": "left",
"label": "/products/*"
},
{
"id": "e-gw-order",
"fromNode": "api-gateway",
"toNode": "svc-order",
"fromSide": "right",
"toSide": "left",
"label": "/orders/*"
},
{
"id": "e-order-user",
"fromNode": "svc-order",
"toNode": "svc-user",
"fromSide": "top",
"toSide": "bottom",
"label": "校验用户"
},
{
"id": "e-order-product",
"fromNode": "svc-order",
"toNode": "svc-product",
"fromSide": "top",
"toSide": "bottom",
"label": "扣减库存"
},
{
"id": "e-order-payment",
"fromNode": "svc-order",
"toNode": "svc-payment",
"fromSide": "bottom",
"toSide": "top",
"label": "发起支付"
},
{
"id": "e-user-db",
"fromNode": "svc-user",
"toNode": "infra-db",
"fromSide": "right",
"toSide": "left"
},
{
"id": "e-product-db",
"fromNode": "svc-product",
"toNode": "infra-db",
"fromSide": "right",
"toSide": "left"
},
{
"id": "e-order-db",
"fromNode": "svc-order",
"toNode": "infra-db",
"fromSide": "right",
"toSide": "left"
},
{
"id": "e-user-cache",
"fromNode": "svc-user",
"toNode": "infra-cache",
"fromSide": "right",
"toSide": "left",
"label": "会话"
},
{
"id": "e-product-es",
"fromNode": "svc-product",
"toNode": "infra-es",
"fromSide": "right",
"toSide": "left",
"label": "搜索"
},
{
"id": "e-order-mq",
"fromNode": "svc-order",
"toNode": "infra-mq",
"fromSide": "right",
"toSide": "left",
"label": "订单事件"
},
{
"id": "e-payment-stripe",
"fromNode": "svc-payment",
"toNode": "external-stripe",
"fromSide": "right",
"toSide": "left",
"label": "支付请求"
}
]
}
assets/documents/workflow/canvas-dev/prompts/01-架构分析.md
-85
View File
@@ -1,85 +0,0 @@
# 01-架构分析提示词
> 从现有代码自动生成 Obsidian Canvas 架构白板
## 使用场景
- 接手新项目，快速理解架构
- 为现有项目建立可视化文档
- 准备 Code Review 或技术分享
## 提示词
```markdown
你是一个代码架构分析专家。请分析以下项目结构，生成 Obsidian Canvas 格式的架构白板。
## 输入
项目路径：{PROJECT_PATH}
分析粒度：{GRANULARITY} (file/class/service)
## 输出要求
生成符合 Obsidian Canvas JSON 格式的 .canvas 文件，包含：
1. **节点 (nodes)**：
- 每个模块/文件/类作为一个节点
- 节点包含：id, type, x, y, width, height, text
- 按功能分区布局（如：API层左侧，数据层右侧）
2. **连线 (edges)**：
- 表示模块间的依赖/调用关系
- 包含：id, fromNode, toNode, fromSide, toSide, label
- label 标注关系类型（调用/继承/依赖/数据流）
3. **分组 (groups)**：
- 按功能域分组（如：用户模块、支付模块）
- 用颜色区分不同层级
## Canvas JSON 结构示例
```json
{
"nodes": [
{
"id": "node1",
"type": "text",
"x": 0,
"y": 0,
"width": 200,
"height": 100,
"text": "# UserService\n- createUser()\n- getUser()"
}
],
"edges": [
{
"id": "edge1",
"fromNode": "node1",
"toNode": "node2",
"fromSide": "right",
"toSide": "left",
"label": "调用"
}
]
}
```
## 分析步骤
1. 扫描项目目录结构
2. 识别入口文件和核心模块
3. 分析 import/require 语句提取依赖关系
4. 识别数据库操作、API调用、外部服务
5. 按调用层级布局节点位置
6. 生成完整的 .canvas JSON
```
## 使用示例
```
请分析 /home/user/my-project 项目，生成文件级别的架构白板。
重点关注：
- API 路由和处理函数
- 数据库模型和操作
- 外部服务调用
```
## 输出文件
生成的 `.canvas` 文件可直接用 Obsidian 打开查看和编辑。
assets/documents/workflow/canvas-dev/prompts/02-白板驱动编码.md
-88
View File
@@ -1,88 +0,0 @@
# 02-白板驱动编码提示词
> 根据 Canvas 白板架构图生成/修改代码
## 使用场景
- 新功能开发：先画白板，再生成代码
- 架构重构：修改白板连线，AI同步重构代码
- 模块拆分：在白板拆分节点，AI生成新文件
## 提示词
```markdown
你是一个根据架构白板生成代码的专家。请根据以下 Obsidian Canvas 白板 JSON，生成对应的代码实现。
## 输入
Canvas JSON：
```json
{CANVAS_JSON}
```
技术栈：{TECH_STACK}
目标目录：{TARGET_DIR}
## 解析规则
1. **节点 → 文件/类**
- 节点 text 中的标题 → 文件名/类名
- 节点 text 中的列表项 → 方法/函数
- 节点颜色/分组 → 模块归属
2. **连线 → 依赖关系**
- fromNode → toNode = import/调用关系
- edge label 决定关系类型：
- "调用" → 函数调用
- "继承" → class extends
- "依赖" → import
- "数据流" → 参数传递
3. **分组 → 目录结构**
- 同一分组的节点放在同一目录
- 分组名称 → 目录名
## 输出要求
1. 生成完整的文件结构
2. 每个文件包含：
- 正确的 import 语句（根据连线）
- 类/函数定义（根据节点内容）
- 调用关系实现（根据连线方向）
3. 添加必要的类型注解和注释
4. 遵循技术栈的最佳实践
## 输出格式
```
文件：{文件路径}
```{语言}
{代码内容}
```
```
## 使用示例
```
根据以下白板生成 Python FastAPI 项目代码：
{粘贴 .canvas 文件内容}
技术栈：Python 3.11 + FastAPI + SQLAlchemy
目标目录：/home/user/my-api
```
## 增量更新模式
当白板有修改时，使用以下提示词：
```markdown
白板已更新，请对比新旧版本，只修改变化的部分：
旧白板：{OLD_CANVAS_JSON}
新白板：{NEW_CANVAS_JSON}
输出：
1. 需要新增的文件
2. 需要修改的文件（只输出 diff）
3. 需要删除的文件
```
assets/documents/workflow/canvas-dev/prompts/03-白板同步检查.md
-147
View File
@@ -1,147 +0,0 @@
# 03-白板同步检查提示词
> 校验白板与实际代码的一致性
## 使用场景
- PR/MR 合并前检查白板是否需要更新
- 定期审计架构文档准确性
- 发现代码中的隐式依赖
## 提示词
```markdown
你是一个代码与架构一致性检查专家。请对比以下白板和代码，找出不一致之处。
## 输入
Canvas 白板 JSON：
```json
{CANVAS_JSON}
```
项目代码路径：{PROJECT_PATH}
## 检查项
1. **节点完整性**
- 白板中的节点是否都有对应的代码文件/类？
- 代码中是否有白板未记录的重要模块？
2. **连线准确性**
- 白板连线是否反映真实的 import/调用关系？
- 代码中是否有白板未标注的依赖？
3. **分组正确性**
- 白板分组是否与目录结构一致？
- 是否有跨分组的异常依赖？
## 输出格式
### 🔴 严重不一致（必须修复）
| 类型 | 白板 | 代码 | 建议 |
|:---|:---|:---|:---|
| 缺失节点 | - | UserService.py | 添加到白板 |
| 错误连线 | A→B | A不调用B | 删除连线 |
### 🟡 轻微不一致（建议修复）
| 类型 | 白板 | 代码 | 建议 |
|:---|:---|:---|:---|
| 命名不一致 | user_service | UserService | 统一命名 |
### 🟢 一致性良好
- 节点覆盖率：{X}%
- 连线准确率：{Y}%
### 📋 修复建议
1. {具体修复步骤}
2. {具体修复步骤}
```
## 自动化脚本（可选）
```python
#!/usr/bin/env python3
"""
canvas_sync_check.py - 白板与代码一致性检查脚本
用法：python canvas_sync_check.py project.canvas /path/to/project
"""
import json
import ast
import os
from pathlib import Path
def load_canvas(canvas_path):
with open(canvas_path) as f:
return json.load(f)
def extract_imports(py_file):
"""提取 Python 文件的 import 关系"""
with open(py_file) as f:
tree = ast.parse(f.read())
imports = []
for node in ast.walk(tree):
if isinstance(node, ast.Import):
for alias in node.names:
imports.append(alias.name)
elif isinstance(node, ast.ImportFrom):
if node.module:
imports.append(node.module)
return imports
def check_consistency(canvas, project_path):
"""对比白板节点与实际文件"""
canvas_nodes = {n['text'].split('\n')[0].strip('# ')
for n in canvas.get('nodes', [])}
actual_files = set()
for py_file in Path(project_path).rglob('*.py'):
actual_files.add(py_file.stem)
missing_in_canvas = actual_files - canvas_nodes
missing_in_code = canvas_nodes - actual_files
return {
'missing_in_canvas': missing_in_canvas,
'missing_in_code': missing_in_code,
'coverage': len(canvas_nodes & actual_files) / len(actual_files) * 100
}
if __name__ == '__main__':
import sys
if len(sys.argv) != 3:
print("用法: python canvas_sync_check.py <canvas_file> <project_path>")
sys.exit(1)
canvas = load_canvas(sys.argv[1])
result = check_consistency(canvas, sys.argv[2])
print(f"覆盖率: {result['coverage']:.1f}%")
if result['missing_in_canvas']:
print(f"白板缺失: {result['missing_in_canvas']}")
if result['missing_in_code']:
print(f"代码缺失: {result['missing_in_code']}")
```
## CI/CD 集成
```yaml
# .github/workflows/canvas-check.yml
name: Canvas Sync Check
on:
pull_request:
paths:
- '**.py'
- '**.canvas'
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check canvas consistency
run: python scripts/canvas_sync_check.py docs/architecture.canvas src/
```
assets/documents/workflow/canvas-dev/templates/module.canvas
-61
View File
@@ -1,61 +0,0 @@
{
"nodes": [
{
"id": "module-main",
"type": "text",
"x": 0,
"y": 0,
"width": 280,
"height": 150,
"text": "# ModuleName\n\n## 职责\n- 功能描述1\n- 功能描述2\n\n## 公开接口\n- method1()\n- method2()"
},
{
"id": "module-dep1",
"type": "text",
"x": -350,
"y": 0,
"width": 200,
"height": 100,
"text": "# 依赖模块1\n\n被本模块调用",
"color": "3"
},
{
"id": "module-dep2",
"type": "text",
"x": 350,
"y": 0,
"width": 200,
"height": 100,
"text": "# 下游模块\n\n调用本模块",
"color": "5"
},
{
"id": "note-design",
"type": "text",
"x": 0,
"y": 200,
"width": 280,
"height": 100,
"text": "## 📝 设计决策\n\n- 为什么这样设计？\n- 有哪些权衡？",
"color": "6"
}
],
"edges": [
{
"id": "edge-dep1",
"fromNode": "module-main",
"toNode": "module-dep1",
"fromSide": "left",
"toSide": "right",
"label": "调用"
},
{
"id": "edge-dep2",
"fromNode": "module-dep2",
"toNode": "module-main",
"fromSide": "left",
"toSide": "right",
"label": "调用"
}
]
}
assets/documents/workflow/canvas-dev/templates/project.canvas
-159
View File
@@ -1,159 +0,0 @@
{
"nodes": [
{
"id": "group-api",
"type": "group",
"x": -400,
"y": -200,
"width": 300,
"height": 400,
"label": "🌐 API 层"
},
{
"id": "group-service",
"type": "group",
"x": 0,
"y": -200,
"width": 300,
"height": 400,
"label": "⚙️ 服务层"
},
{
"id": "group-data",
"type": "group",
"x": 400,
"y": -200,
"width": 300,
"height": 400,
"label": "💾 数据层"
},
{
"id": "node-api-user",
"type": "text",
"x": -380,
"y": -150,
"width": 260,
"height": 120,
"text": "# UserAPI\n\n- POST /users\n- GET /users/{id}\n- PUT /users/{id}\n- DELETE /users/{id}"
},
{
"id": "node-api-order",
"type": "text",
"x": -380,
"y": 0,
"width": 260,
"height": 120,
"text": "# OrderAPI\n\n- POST /orders\n- GET /orders/{id}\n- GET /orders/user/{user_id}"
},
{
"id": "node-service-user",
"type": "text",
"x": 20,
"y": -150,
"width": 260,
"height": 120,
"text": "# UserService\n\n- create_user()\n- get_user()\n- update_user()\n- delete_user()"
},
{
"id": "node-service-order",
"type": "text",
"x": 20,
"y": 0,
"width": 260,
"height": 120,
"text": "# OrderService\n\n- create_order()\n- get_order()\n- get_user_orders()"
},
{
"id": "node-model-user",
"type": "text",
"x": 420,
"y": -150,
"width": 260,
"height": 120,
"text": "# User Model\n\n- id: int\n- name: str\n- email: str\n- created_at: datetime"
},
{
"id": "node-model-order",
"type": "text",
"x": 420,
"y": 0,
"width": 260,
"height": 120,
"text": "# Order Model\n\n- id: int\n- user_id: int (FK)\n- total: decimal\n- status: str"
},
{
"id": "node-db",
"type": "text",
"x": 420,
"y": 150,
"width": 260,
"height": 80,
"text": "# Database\n\nPostgreSQL",
"color": "4"
}
],
"edges": [
{
"id": "edge-api-user-service",
"fromNode": "node-api-user",
"toNode": "node-service-user",
"fromSide": "right",
"toSide": "left",
"label": "调用"
},
{
"id": "edge-api-order-service",
"fromNode": "node-api-order",
"toNode": "node-service-order",
"fromSide": "right",
"toSide": "left",
"label": "调用"
},
{
"id": "edge-service-user-model",
"fromNode": "node-service-user",
"toNode": "node-model-user",
"fromSide": "right",
"toSide": "left",
"label": "操作"
},
{
"id": "edge-service-order-model",
"fromNode": "node-service-order",
"toNode": "node-model-order",
"fromSide": "right",
"toSide": "left",
"label": "操作"
},
{
"id": "edge-order-user-dep",
"fromNode": "node-service-order",
"toNode": "node-service-user",
"fromSide": "top",
"toSide": "bottom",
"label": "依赖"
},
{
"id": "edge-model-user-db",
"fromNode": "node-model-user",
"toNode": "node-db",
"fromSide": "bottom",
"toSide": "top"
},
{
"id": "edge-model-order-db",
"fromNode": "node-model-order",
"toNode": "node-db",
"fromSide": "bottom",
"toSide": "top"
},
{
"id": "edge-order-user-fk",
"fromNode": "node-model-order",
"toNode": "node-model-user",
"fromSide": "top",
"toSide": "bottom",
"label": "FK: user_id"
}
]
}
assets/documents/workflow/canvas-dev/workflow.md
-31
View File
@@ -1,31 +0,0 @@
🚀 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检查）；分享最佳实践案例到团队知识库