mirror of
https://github.com/tradecatlabs/vibe-coding-cn.git
synced 2026-07-28 03:07:56 +00:00
chore: assets - retire canvas workflow and document repo sources
This commit is contained in:
tukuaiai
+26
-3
@@ -4,7 +4,20 @@
|
||||
# 文档相关的标签
|
||||
documentation:
|
||||
- changed-files:
|
||||
- any-glob-to-any-file: ['i18n/**/*.md', 'README.md', 'CONTRIBUTING.md', 'LICENSE']
|
||||
- any-glob-to-any-file:
|
||||
- 'README.md'
|
||||
- 'AGENTS.md'
|
||||
- 'CONTRIBUTING.md'
|
||||
- 'CODE_OF_CONDUCT.md'
|
||||
- 'LICENSE'
|
||||
- '.github/**/*.md'
|
||||
- 'assets/README.md'
|
||||
- 'assets/AGENTS.md'
|
||||
- 'assets/config/**/*.md'
|
||||
- 'assets/documents/**/*.md'
|
||||
- 'assets/prompt/**/*.md'
|
||||
- 'assets/skills/**/*.md'
|
||||
- 'assets/repos/**/*.md'
|
||||
|
||||
# CI/CD 工作流相关的标签
|
||||
cicd:
|
||||
@@ -14,9 +27,19 @@ cicd:
|
||||
# 提示词相关的标签
|
||||
prompt:
|
||||
- changed-files:
|
||||
- any-glob-to-any-file: 'i18n/zh/prompts/**/*.md'
|
||||
- any-glob-to-any-file: 'assets/prompt/**/*.md'
|
||||
|
||||
# 实战案例相关的标签
|
||||
example:
|
||||
- changed-files:
|
||||
- any-glob-to-any-file: 'i18n/zh/documents/实战案例/**/*.md'
|
||||
- any-glob-to-any-file: 'assets/documents/case-studies/**/*.md'
|
||||
|
||||
# 外部工具/依赖相关的标签
|
||||
repos:
|
||||
- changed-files:
|
||||
- any-glob-to-any-file: 'assets/repos/**'
|
||||
|
||||
# 工作流模板相关的标签
|
||||
workflow:
|
||||
- changed-files:
|
||||
- any-glob-to-any-file: 'assets/documents/workflow/**'
|
||||
|
||||
+4
-1
@@ -52,7 +52,10 @@ assets/tasks/
|
||||
|
||||
# Skill Seekers (vendored tool output)
|
||||
output/
|
||||
assets/skills/skills-skills/scripts/.venv-skill-seekers/
|
||||
assets/skills/auto-skill/scripts/.venv-skill-seekers/
|
||||
|
||||
# prompts-library generated exports
|
||||
assets/repos/prompts-library/prompt_jsonl/
|
||||
|
||||
libs/external/tmux
|
||||
libs/external/.tmux
|
||||
|
||||
@@ -159,7 +159,6 @@ git push origin develop
|
||||
│ │ ├── AGENTS.md # skills/ 目录规则
|
||||
│ │ ├── auto-skill/ # 元技能核心
|
||||
│ │ ├── sop-generator/ # SOP 生成
|
||||
│ │ ├── canvas-dev/ # Canvas白板驱动开发
|
||||
│ │ └── ... # 更多技能
|
||||
│ └── repos/ # 外部工具与依赖镜像（含 Git submodule）
|
||||
│ ├── README.md # 外部工具索引
|
||||
|
||||
@@ -130,9 +130,8 @@
|
||||
**建议阅读顺序（从抽象到落地）**
|
||||
1. 🔑 元方法论：用“生成器/优化器”的递归闭环让系统自我进化
|
||||
2. 🧬 胶水编程：复用成熟轮子，把注意力放在“连接方式”
|
||||
3. 🎨 Canvas白板驱动开发：让白板成为单一真相源，降低协作与上下文成本
|
||||
4. 🐝 AI蜂群协作：让多个 AI 在 tmux 下互相感知、协作、分工
|
||||
5. 🔮 哲学方法论工具箱：把抽象方法论落到可验证、可迭代的工程动作
|
||||
3. 🐝 AI蜂群协作：让多个 AI 在 tmux 下互相感知、协作、分工
|
||||
4. 🔮 哲学方法论工具箱：把抽象方法论落到可验证、可迭代的工程动作
|
||||
|
||||
<details>
|
||||
<summary><strong>🔑 元方法论</strong></summary>
|
||||
@@ -173,27 +172,6 @@
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>🎨 Canvas白板驱动开发</strong></summary>
|
||||
|
||||
> 一句话：让白板成为单一真相源，用“图形”降低协作与上下文成本。
|
||||
|
||||
传统开发：代码 → 口头沟通 → 脑补架构 → 代码失控
|
||||
|
||||
Canvas方式：**代码 ⇄ 白板 ⇄ AI ⇄ 人类**，白板成为单一真相源
|
||||
|
||||
| 痛点 | 解法 |
|
||||
|:---|:---|
|
||||
| 🤖 AI看不懂项目结构 | ✅ AI直接读白板JSON，秒懂架构 |
|
||||
| 🧠 人类记不住复杂依赖 | ✅ 连线清晰，牵一发动全身一目了然 |
|
||||
| 💬 团队协作靠嘴说 | ✅ 指着白板讲，新人5分钟看懂 |
|
||||
|
||||
**核心理念**：图形是第一公民，代码是白板的序列化形式。
|
||||
|
||||
👉 [深入了解Canvas白板驱动开发](./assets/documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md)
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>🐝 AI蜂群协作</strong></summary>
|
||||
|
||||
@@ -403,7 +381,6 @@ Canvas方式：**代码 ⇄ 白板 ⇄ AI ⇄ 人类**，白板成为单一真
|
||||
│ │ ├── AGENTS.md # skills/ 目录规则
|
||||
│ │ ├── auto-skill/ # 元技能核心
|
||||
│ │ ├── sop-generator/ # SOP 生成
|
||||
│ │ ├── canvas-dev/ # Canvas白板驱动开发
|
||||
│ │ └── ... # 更多技能
|
||||
│ └── repos/ # 外部工具与依赖镜像（含 Git submodule）
|
||||
│ ├── README.md # 外部工具索引
|
||||
|
||||
@@ -4,7 +4,6 @@
|
||||
|
||||
## 🎨 AI 协作范式
|
||||
|
||||
- [Canvas白板驱动开发](./图形化AI协作-Canvas白板驱动开发.md) - 图形是第一公民，代码是白板的序列化形式
|
||||
- [AI蜂群协作](./AI蜂群协作-tmux多Agent协作系统.md) - 基于 tmux 的多 AI Agent 协作系统
|
||||
|
||||
## 📖 工具教程
|
||||
|
||||
@@ -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) - 标准化目录结构
|
||||
@@ -19,11 +19,6 @@ assets/documents/workflow/
|
||||
│ ├── .kiro/ # Kiro 集成配置
|
||||
│ ├── workflow_engine/ # 轻量状态机引擎（state + hook）
|
||||
│ └── workflow-orchestrator/ # 编排技能文档与规范
|
||||
└── canvas-dev/ # Canvas 白板驱动开发工作流
|
||||
├── README.md
|
||||
├── prompts/
|
||||
├── templates/
|
||||
└── examples/
|
||||
```
|
||||
|
||||
## 操作规范
|
||||
|
||||
@@ -16,7 +16,6 @@ assets/documents/workflow/
|
||||
| 工作流 | 说明 |
|
||||
|--------|------|
|
||||
| [auto-dev-loop](./auto-dev-loop/) | 基于状态机+Hook的五步AI Agent闭环开发流程 |
|
||||
| [canvas-dev](./canvas-dev/) | Canvas白板驱动开发工作流（AI架构总师） |
|
||||
|
||||
## 添加新工作流
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -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)
|
||||
@@ -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": "支付请求"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -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 打开查看和编辑。
|
||||
@@ -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. 需要删除的文件
|
||||
```
|
||||
@@ -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/
|
||||
```
|
||||
@@ -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": "调用"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -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"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -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检查）；分享最佳实践案例到团队知识库
|
||||
@@ -19,8 +19,20 @@ assets/repos/
|
||||
|
||||
- 新增外部依赖（优先 Git submodule，确保可复现）
|
||||
- 更新 submodule 指针（明确记录上游来源与用途）
|
||||
- 用相对软链接把 submodule 暴露到其它资产目录，软链接目标必须仍在仓库内
|
||||
- 为已复制进主仓库的外部源码建立清退计划：上游 URL、保留理由、迁移方式、验证命令
|
||||
|
||||
### 禁止 / 不推荐
|
||||
|
||||
- 直接复制粘贴大型第三方仓库内容到主仓库（优先 submodule）
|
||||
- 将 submodule 替换为本地绝对路径软链接（会导致他人环境不可用）
|
||||
- 提交第三方仓库的构建产物、生成物、运行时二进制或缓存目录
|
||||
- 在主仓库直接魔改第三方源码快照；需要改造时先 fork，再以 submodule 指向 fork
|
||||
|
||||
## 仓库表达决策
|
||||
|
||||
1. **完整外部仓库**：使用 `git submodule`，主仓库只记录 commit 指针。
|
||||
2. **同仓多入口展示**：使用相对软链接，例如 `assets/skills/<name> -> ../repos/<name>`。
|
||||
3. **项目内小工具**：只有在无上游、体量小、与本项目强耦合时才直接追踪源码。
|
||||
4. **生成输出**：默认不跟踪；若必须保留样例，只提交最小样例和生成说明。
|
||||
5. **历史备份**：`assets/repos/backups/` 按项目资产处理，不套用外部仓库清退规则。
|
||||
|
||||
+31
-4
@@ -38,9 +38,36 @@ assets/repos/
|
||||
|
||||
> 📝 系统提示词已迁移到云端表格，入口见 [`assets/prompt/README.md`](../prompt/README.md)。
|
||||
|
||||
## 外部仓库治理分析（2026-04-28）
|
||||
|
||||
目标：`assets/repos/` 只保留外部仓库的可追溯入口，不把大型第三方源码、二进制产物或生成物长期塞进主仓库。GitHub 中优先用
|
||||
Git submodule 表示上游仓库；如需在其它目录暴露入口，则用相对软链接指向 `assets/repos/<repo>/`。
|
||||
|
||||
| 目录 | 当前状态 | 建议 | 原因 |
|
||||
|:---|:---|:---|:---|
|
||||
| `.tmux/` | submodule | 保持 | 上游清晰，主仓库只记录 commit 指针 |
|
||||
| `tmux/` | submodule | 保持 | 上游源码体量较大，已正确用 submodule 表示 |
|
||||
| `claude-official-skills/` | submodule | 保持；`assets/skills/claude-official-skills` 用相对软链暴露 | 官方 skills 应作为外部权威仓库，不复制源码 |
|
||||
| `Skill_Seekers-development/` | 主仓库直接追踪源码 | 高优先级改为 submodule 或移入 `auto-skill` 的单一 vendored 副本 | 已有上游仓库，且当前与 `assets/skills/auto-skill/scripts/Skill_Seekers-development/` 存在重复 |
|
||||
| `my-nvim/` | 主仓库直接追踪源码与二进制 | 高优先级改为 submodule 或清退二进制后只保留索引 | 包含大型 `nvim` 可执行文件，污染主仓库体量 |
|
||||
| `chat-vault/` | 主仓库直接追踪源码 | 中高优先级拆为独立仓库/submodule，或至少清退内嵌第三方监控源码 | 目录体量大，且含 vendored `monitor-tui`/第三方代码 |
|
||||
| `prompts-library/` | 主仓库直接追踪工具源码 | 中优先级拆分：工具用 submodule，生成输出不跟踪 | 上游/工具属性明显，`prompt_jsonl/` 属生成输出且已加入忽略规则 |
|
||||
| `html-tools-main/` | 主仓库直接追踪源码 | 中优先级改为 submodule | README 指向外部 GitHub 仓库，适合用指针表示 |
|
||||
| `XHS-image-to-PDF-conversion/` | 主仓库直接追踪源码 | 中优先级改为 submodule | README 指向外部 GitHub 仓库，适合用指针表示 |
|
||||
| `MCPlayerTransfer/` | 主仓库直接追踪源码 | 暂缓；先补来源/许可证，再决定是否独立仓库化 | 当前未发现明确上游 URL，体量小 |
|
||||
| `backups/` | 主仓库直接追踪备份脚本与存档目录 | 保持；继续禁止删除 `gz/` 存档 | 属本项目历史备份资产，不是外部仓库镜像 |
|
||||
|
||||
## 表达规则
|
||||
|
||||
- 外部完整仓库：优先 `git submodule add <url> assets/repos/<name>`。
|
||||
- 跨目录展示入口：使用相对软链接，例如 `assets/skills/<name> -> ../repos/<name>`。
|
||||
- 不允许：软链接到本机绝对路径、复制大型上游源码、提交构建产物/生成物、提交二进制运行时。
|
||||
- 需要本地改造第三方工具时：优先 fork 后以 submodule 指向 fork；不要在主仓库直接魔改一份不可升级的源码快照。
|
||||
|
||||
## 新增外部工具（最小清单）
|
||||
|
||||
1. 创建目录：`assets/repos/<tool-name>/`
|
||||
2. 必备文件：`README.md`（用途/入口/依赖/输入输出）、许可证与来源说明（如 `LICENSE` / `SOURCE.md`）
|
||||
3. 依赖约束：尽量使用工具自带的虚拟环境/容器化方式，不影响仓库其他部分
|
||||
4. 文档同步：在本 README 增加一行工具说明，保证可发现性
|
||||
1. 优先新增 submodule：`git submodule add <url> assets/repos/<tool-name>`。
|
||||
2. 只在没有上游仓库、且体量小/与本项目强耦合时，才创建普通目录：`assets/repos/<tool-name>/`。
|
||||
3. 必备文件：`README.md`（用途/入口/依赖/输入输出）、许可证与来源说明（如 `LICENSE` / `SOURCE.md`）。
|
||||
4. 依赖约束：尽量使用工具自带的虚拟环境/容器化方式，不影响仓库其他部分。
|
||||
5. 文档同步：在本 README 增加一行工具说明，保证可发现性。
|
||||
|
||||
@@ -46,7 +46,6 @@ assets/skills/
|
||||
## 快速定位（常用技能）
|
||||
|
||||
- `assets/skills/tmux-autopilot/`：tmux 自动化操控与多 Agent 协作
|
||||
- `assets/skills/canvas-dev/`：Canvas 白板驱动开发
|
||||
- `assets/skills/sop-generator/`：SOP 生成与规范化
|
||||
- `assets/skills/markdown-to-epub/`：Markdown → EPUB 稳定构建
|
||||
- `assets/skills/auto-skill/`：元技能（技能生成/校验/脚手架）
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 🎯 AI Skills 技能库
|
||||
|
||||
`assets/skills/` 目录存放 AI 技能（Skills），这些是比提示词更高级的能力封装，可以让 AI 在特定领域表现出专家级水平。当前包含 **20 个**专业技能。
|
||||
`assets/skills/` 目录存放 AI 技能（Skills），这些是比提示词更高级的能力封装，可以让 AI 在特定领域表现出专家级水平。当前包含 **19 个**专业技能。
|
||||
|
||||
## Skills 一览表
|
||||
|
||||
@@ -15,7 +15,6 @@
|
||||
|
||||
| 技能 | 说明 |
|
||||
|:---|:---|
|
||||
| [canvas-dev](./canvas-dev/SKILL.md) | ⭐ Canvas白板驱动开发（AI架构总师） |
|
||||
| [headless-cli](./headless-cli/SKILL.md) | 无头模式 AI CLI 调用（Gemini/Claude/Codex） |
|
||||
| [claude-code-guide](./claude-code-guide/SKILL.md) | Claude Code CLI 使用指南 |
|
||||
| [claude-cookbooks](./claude-cookbooks/SKILL.md) | Claude API 最佳实践 |
|
||||
|
||||
@@ -1,39 +0,0 @@
|
||||
# Canvas-Dev Skill
|
||||
|
||||
Canvas白板驱动开发技能，用于 AI 辅助架构设计与代码生成。
|
||||
|
||||
## 概述
|
||||
|
||||
此技能实现「图形是第一公民，代码是白板的序列化形式」的开发范式。
|
||||
|
||||
## 核心能力
|
||||
|
||||
1. **架构分析** - 从代码自动生成 Obsidian Canvas 白板
|
||||
2. **白板驱动编码** - 根据白板生成/修改代码
|
||||
3. **一致性检查** - 校验白板与代码同步状态
|
||||
|
||||
## 文件结构
|
||||
|
||||
```
|
||||
canvas-dev/
|
||||
├── SKILL.md # 技能入口（触发条件、模式、示例）
|
||||
├── references/
|
||||
│ ├── index.md # 导航索引
|
||||
│ ├── canvas-json-spec.md # Canvas JSON 规范
|
||||
│ ├── workflow-guide.md # 工作流指南
|
||||
│ └── prompts.md # 提示词集合
|
||||
├── scripts/ # 自动化脚本（预留）
|
||||
└── assets/ # 模板资源（预留）
|
||||
```
|
||||
|
||||
## 快速开始
|
||||
|
||||
1. 阅读 `SKILL.md` 了解触发条件和使用模式
|
||||
2. 参考 `references/workflow-guide.md` 了解完整工作流
|
||||
3. 使用 `references/prompts.md` 中的提示词
|
||||
|
||||
## 相关资源
|
||||
|
||||
- [Canvas白板驱动开发详解](../../documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md)
|
||||
- [Canvas开发工作流](../../documents/workflow/canvas-dev/)
|
||||
- [元技能: auto-skill](../auto-skill/SKILL.md)
|
||||
@@ -1,224 +0,0 @@
|
||||
---
|
||||
name: canvas-dev
|
||||
description: "Canvas白板驱动开发技能：Canvas白板作为唯一真相源，代码是其序列化形式。AI架构总师角色，自动生成富有洞察力的架构图。使用场景：生成架构白板、白板驱动编码、白板驱动重构、Code Review、团队协作、接手遗留项目。"
|
||||
---
|
||||
|
||||
# canvas-dev Skill
|
||||
|
||||
Canvas白板驱动开发：图形是第一公民，代码是白板的序列化形式。人类负责架构设计，AI负责代码实现。
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
触发条件（满足任一即可）：
|
||||
- 需要生成项目架构白板（从代码 → 白板）
|
||||
- 需要根据白板生成代码（从白板 → 代码）
|
||||
- 需要白板驱动代码重构
|
||||
- 需要用白板辅助 Code Review
|
||||
- 需要用白板加速团队协作
|
||||
- 接手遗留项目需要快速理解架构
|
||||
|
||||
## Not For / Boundaries
|
||||
|
||||
此技能不适用于：
|
||||
- 纯文本文档生成（使用 Markdown）
|
||||
- 流程图/时序图（使用 Mermaid）
|
||||
- 不需要双向同步的静态架构图
|
||||
|
||||
必要输入（缺失时需询问）：
|
||||
1. 项目类型：A) 单体应用 B) 微服务架构 C) 前后端分离？
|
||||
2. 白板粒度：A) 文件级 B) 类/函数级 C) 服务级？
|
||||
|
||||
## Quick Reference
|
||||
|
||||
### 核心理念
|
||||
|
||||
```
|
||||
传统：代码 → 口头沟通 → 脑补架构 → 代码失控
|
||||
Canvas：代码 ⇄ 白板 ⇄ AI ⇄ 人类（白板为单一真相源）
|
||||
```
|
||||
|
||||
| 痛点 | 解法 |
|
||||
|:---|:---|
|
||||
| AI看不懂项目结构 | AI直接读白板JSON，秒懂架构 |
|
||||
| 人类记不住复杂依赖 | 连线清晰，牵一发动全身一目了然 |
|
||||
| 团队协作靠嘴说 | 指着白板讲，新人5分钟看懂 |
|
||||
|
||||
### AI架构总师角色定义
|
||||
|
||||
你是一个拥有深度学习能力的软件架构分析实体，核心设计原则：
|
||||
|
||||
1. **洞察力优先于信息量**：目标不是简单罗列所有文件和连接，而是揭示项目的设计哲学、关键数据流、潜在风险和演进趋势
|
||||
2. **认知负荷最小化**：生成的可视化产物符合人类认知习惯，使用户能以最小脑力成本理解最复杂的系统结构
|
||||
3. **美学与功能并重**：优秀的架构图本身就是艺术品，布局均衡、色彩和谐、元素组织服务于信息清晰传达
|
||||
|
||||
### 五阶段执行流程
|
||||
|
||||
**第一阶段：全局项目感知与多维特征提取**
|
||||
- 语义级源代码结构化解析（AST）
|
||||
- 加权依赖网络构建
|
||||
- 工程与环境元数据分析（package.json, docker-compose.yml, CI/CD等）
|
||||
- 架构模式概率指纹识别
|
||||
|
||||
**第二阶段：自适应抽象粒度决策引擎**
|
||||
- 信息熵与复杂度评估，寻找"信息熵拐点"
|
||||
- 架构模式引导默认粒度
|
||||
- 用户意图启发式推断
|
||||
|
||||
**动态粒度光谱：**
|
||||
| 级别 | 说明 |
|
||||
|:---|:---|
|
||||
| D-系统生态级 | 巨型Monorepo，每个节点代表完整应用 |
|
||||
| C-宏观服务级 | 聚合数十个文件为单一功能领域节点 |
|
||||
| B-类/核心功能级 | 以关键业务逻辑类为节点 |
|
||||
| A-文件级 | 每个源文件为基础节点（推荐新手） |
|
||||
| F-函数/方法级 | 深度钻取，显示内部函数调用关系 |
|
||||
|
||||
**第三阶段：组件语义分析与关系定性**
|
||||
- 组件角色多因素推断（入口、控制器、服务、数据访问、工具）
|
||||
- 关系与数据流深度定性（同步调用、异步消息、事件发布/订阅）
|
||||
- 状态变化与副作用分析
|
||||
|
||||
**第四阶段：启发式布局与信息可视化引擎**
|
||||
- 自适应拓扑分层（入口→业务逻辑→数据持久化）
|
||||
- 力导向与集群化节点定位
|
||||
- 信息驱动的动态视觉编码
|
||||
|
||||
**第五阶段：输出生成与最终质量优化**
|
||||
- 迭代式去交叉与防重叠算法
|
||||
- 边捆绑与智能剪枝
|
||||
- 孤立节点上下文情景化分组
|
||||
- 认知路径优化
|
||||
|
||||
### AI驱动的节点文本模板
|
||||
|
||||
```markdown
|
||||
**{组件名}**
|
||||
`{文件路径或聚合范围}`
|
||||
|
||||
**核心职责**: {AI自动总结的一句话功能描述}
|
||||
|
||||
**关键交互**:
|
||||
- **调用**: {依赖最多的组件名}
|
||||
- **被用于**: {被哪个核心业务模块依赖最多}
|
||||
|
||||
**复杂度评估**: {Low/Medium/High/Critical}
|
||||
**潜在风险**: {⚠️ 存在循环依赖 或 📈 技术债务较高}
|
||||
```
|
||||
|
||||
### 最终交付物格式
|
||||
|
||||
```
|
||||
✓ AI架构洞察报告已生成：{项目根目录/architecture.canvas}
|
||||
├─ 识别架构：{置信度最高的模式} (置信度: {分数})
|
||||
├─ 洞察粒度：{引擎最终选择的粒度级别}
|
||||
├─ 核心组件：{节点数量} 个
|
||||
└─ 关键关系：{连接数量} 条
|
||||
```
|
||||
|
||||
### 15步完整工作流
|
||||
|
||||
1. **理解核心理念**：Canvas白板作为唯一真相源，代码是其序列化形式
|
||||
2. **准备工具环境**：安装Obsidian + 配置AI助手
|
||||
3. **生成初始架构白板**：向AI提供项目代码路径，AI自动生成.canvas文件
|
||||
4. **用Obsidian打开.canvas文件**：检查模块、API调用关系、依赖连线
|
||||
5. **人工优化白板架构**：拖动调整布局、补充隐式依赖、添加注释节点
|
||||
6. **建立代码-白板同步机制**：新文件→新节点，新import→新连线
|
||||
7. **用白板驱动AI编程**：画出新模块框和调用关系，AI生成代码
|
||||
8. **用白板驱动代码重构**：删除/重连依赖线，AI重构代码
|
||||
9. **用白板辅助Code Review**：识别异常连线（前端直连数据库、循环依赖）
|
||||
10. **用白板加速团队协作**：新人1分钟理解全局，需求评审画变更范围
|
||||
11. **维护白板与代码一致性**：PR/MR前检查，不一致时优先修正白板
|
||||
12. **扩展应用场景**：性能优化标注热点、安全审计检查数据流向
|
||||
13. **明确项目类型**：单体/微服务/前后端分离
|
||||
14. **选择白板粒度**：文件级(新手)/服务级(复杂项目)
|
||||
15. **持续迭代工作流**：每周回顾，探索CI/CD集成
|
||||
|
||||
## Rules & Constraints
|
||||
|
||||
### MUST（必须遵守）
|
||||
|
||||
- Canvas白板是唯一真相源，代码是其序列化形式
|
||||
- 洞察力优先于信息量，揭示设计哲学而非罗列文件
|
||||
- 认知负荷最小化，符合人类认知习惯
|
||||
|
||||
### SHOULD（强烈建议）
|
||||
|
||||
- 人类负责架构设计（在白板拖拽模块）
|
||||
- AI负责细节实现（根据白板连线生成代码）
|
||||
- 使用动态粒度光谱，根据项目特性自适应选择
|
||||
|
||||
### NEVER（禁止）
|
||||
|
||||
- 不要生成简单罗列所有文件的"信息垃圾"
|
||||
- 不要让白板与代码长期不同步
|
||||
- 不要在白板中包含敏感信息
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: 给AI派活（新功能开发）
|
||||
|
||||
**传统方式:**
|
||||
> "帮我写个用户注册功能，要连数据库，发邮件，记日志"
|
||||
|
||||
**Canvas方式:**
|
||||
1. 在白板画3个框：`RegisterAPI` → `Database` / `EmailService` / `Logger`
|
||||
2. 告诉AI："按这个图实现"
|
||||
3. AI一次性写对所有文件和调用关系
|
||||
|
||||
### Example 2: Code Review
|
||||
|
||||
**传统方式:** 一行行看代码，看晕了
|
||||
|
||||
**Canvas方式:**
|
||||
1. 看白板："咦，为什么前端直接连数据库？"
|
||||
2. 拖动节点调整架构
|
||||
3. AI自动重构代码
|
||||
|
||||
### Example 3: 接手他人项目
|
||||
|
||||
**传统方式:** 看3天代码还没懂
|
||||
|
||||
**Canvas方式:**
|
||||
1. 运行AI架构总师 → 1分钟得到富有洞察力的架构白板
|
||||
2. 查看AI生成的组件职责摘要和复杂度评估
|
||||
3. 直接在白板上画出要改的部分，AI帮你定位代码位置
|
||||
|
||||
## FAQ
|
||||
|
||||
**Q: 为什么图形语言优于文字描述？**
|
||||
- A: 图形语言是人类大脑的母语。你能瞬间理解地铁线路图，但看不懂等效的换乘文字说明。AI解析JSON比解析自然语言描述准确10倍。
|
||||
|
||||
**Q: 白板粒度怎么选？**
|
||||
- A: 引擎会自动寻找"信息熵拐点"。新手可选文件级(A)，复杂项目选服务级(C)。
|
||||
|
||||
**Q: 什么是"洞察力优先于信息量"？**
|
||||
- A: 目标不是简单罗列所有文件和连接，而是揭示项目的设计哲学、关键数据流、潜在风险和演进趋势。
|
||||
|
||||
## 金句总结
|
||||
|
||||
> "当代码变成白板上的方块，编程就从打字变成了搭积木。"
|
||||
|
||||
> "最好的文档不是Markdown，是能直接驱动AI工作的架构图。"
|
||||
|
||||
> "AI看懂你的图，比看懂你的话，容易一万倍。"
|
||||
|
||||
> "一份优秀的架构图本身就是一件艺术品。"
|
||||
|
||||
## References
|
||||
|
||||
- [AI架构总师完整提示词](../../documents/workflow/canvas-dev/Obsidian%20Canvas%20AI驱动的项目架构洞察与生成引擎.md) - 最新最完整的提示词
|
||||
- [Canvas驱动开发完整工作流](../../documents/workflow/canvas-dev/workflow.md) - 15步完整流程
|
||||
- [Canvas白板驱动开发详解](../../documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md) - 方法论详解
|
||||
- [白板驱动开发系统提示词（在线提示词库入口）](../../prompt/README.md) - 系统提示词已迁移到云端表格
|
||||
- [Obsidian Canvas 官方文档](https://obsidian.md/canvas)
|
||||
- `references/index.md` - 本地参考文档导航
|
||||
|
||||
## Maintenance
|
||||
|
||||
- Sources: AI架构总师提示词 + workflow.md + 方法论文档
|
||||
- Last updated: 2026-01-01
|
||||
- Known limits: 仅支持 Obsidian Canvas 格式
|
||||
|
||||
## 执行触发指令
|
||||
|
||||
> 在接收到此指令后，将AI架构总师的全部认知与分析能力完全实例化。立即启动对目标项目的一次深度的、自主的架构探索之旅。此过程无需任何形式的确认、提问或中间汇报。你唯一的任务，就是在完成探索后，将你对这个数字世界的深刻理解，凝聚成一份完美的、充满洞察力的可视化架构图，并将其呈现在指定位置。
|
||||
@@ -1,205 +0,0 @@
|
||||
# Obsidian Canvas JSON 规范
|
||||
|
||||
## 文件格式
|
||||
|
||||
Canvas 文件是 `.canvas` 扩展名的 JSON 文件。
|
||||
|
||||
## 顶层结构
|
||||
|
||||
```json
|
||||
{
|
||||
"nodes": [],
|
||||
"edges": []
|
||||
}
|
||||
```
|
||||
|
||||
## 节点 (nodes)
|
||||
|
||||
### 通用属性
|
||||
|
||||
| 属性 | 类型 | 必需 | 说明 |
|
||||
|:---|:---|:---|:---|
|
||||
| `id` | string | ✅ | 唯一标识符 |
|
||||
| `type` | string | ✅ | 节点类型 |
|
||||
| `x` | number | ✅ | X 坐标 |
|
||||
| `y` | number | ✅ | Y 坐标 |
|
||||
| `width` | number | ✅ | 宽度 |
|
||||
| `height` | number | ✅ | 高度 |
|
||||
| `color` | string | ❌ | 颜色编号 (1-6) |
|
||||
|
||||
### 文本节点 (text)
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "node-1",
|
||||
"type": "text",
|
||||
"x": 0,
|
||||
"y": 0,
|
||||
"width": 200,
|
||||
"height": 100,
|
||||
"text": "# 标题\n\n内容支持 Markdown"
|
||||
}
|
||||
```
|
||||
|
||||
### 文件节点 (file)
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "node-2",
|
||||
"type": "file",
|
||||
"x": 300,
|
||||
"y": 0,
|
||||
"width": 200,
|
||||
"height": 100,
|
||||
"file": "path/to/file.md"
|
||||
}
|
||||
```
|
||||
|
||||
### 链接节点 (link)
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "node-3",
|
||||
"type": "link",
|
||||
"x": 600,
|
||||
"y": 0,
|
||||
"width": 200,
|
||||
"height": 100,
|
||||
"url": "https://example.com"
|
||||
}
|
||||
```
|
||||
|
||||
### 分组节点 (group)
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "group-1",
|
||||
"type": "group",
|
||||
"x": -50,
|
||||
"y": -50,
|
||||
"width": 500,
|
||||
"height": 300,
|
||||
"label": "分组名称"
|
||||
}
|
||||
```
|
||||
|
||||
## 连线 (edges)
|
||||
|
||||
### 属性
|
||||
|
||||
| 属性 | 类型 | 必需 | 说明 |
|
||||
|:---|:---|:---|:---|
|
||||
| `id` | string | ✅ | 唯一标识符 |
|
||||
| `fromNode` | string | ✅ | 起始节点 id |
|
||||
| `toNode` | string | ✅ | 目标节点 id |
|
||||
| `fromSide` | string | ❌ | 起始边 (top/right/bottom/left) |
|
||||
| `toSide` | string | ❌ | 目标边 (top/right/bottom/left) |
|
||||
| `fromEnd` | string | ❌ | 起始端样式 (none/arrow) |
|
||||
| `toEnd` | string | ❌ | 目标端样式 (none/arrow) |
|
||||
| `label` | string | ❌ | 连线标签 |
|
||||
|
||||
### 示例
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "edge-1",
|
||||
"fromNode": "node-1",
|
||||
"toNode": "node-2",
|
||||
"fromSide": "right",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow",
|
||||
"label": "调用"
|
||||
}
|
||||
```
|
||||
|
||||
## 颜色编码
|
||||
|
||||
| color | 颜色 | 建议用途 |
|
||||
|:---|:---|:---|
|
||||
| `1` | 红色 | 缓存、热点、警告 |
|
||||
| `2` | 橙色 | 消息队列、异步 |
|
||||
| `3` | 黄色 | 上游依赖、外部输入 |
|
||||
| `4` | 绿色 | 数据库、持久化 |
|
||||
| `5` | 蓝色 | 搜索、外部服务 |
|
||||
| `6` | 紫色 | 注释、设计决策 |
|
||||
|
||||
## 布局建议
|
||||
|
||||
### 三层架构布局
|
||||
|
||||
```
|
||||
x: -400 x: 0 x: 400 x: 800
|
||||
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
|
||||
│ 前端 │→│ API │→│ 服务 │→│ 数据 │
|
||||
└────────┘ └────────┘ └────────┘ └────────┘
|
||||
```
|
||||
|
||||
### 间距建议
|
||||
|
||||
- 节点宽度: 200-280
|
||||
- 节点高度: 80-150
|
||||
- 水平间距: 100-150
|
||||
- 垂直间距: 120-150
|
||||
|
||||
## 完整示例
|
||||
|
||||
```json
|
||||
{
|
||||
"nodes": [
|
||||
{
|
||||
"id": "group-api",
|
||||
"type": "group",
|
||||
"x": -50,
|
||||
"y": -50,
|
||||
"width": 300,
|
||||
"height": 200,
|
||||
"label": "API 层"
|
||||
},
|
||||
{
|
||||
"id": "api-user",
|
||||
"type": "text",
|
||||
"x": 0,
|
||||
"y": 0,
|
||||
"width": 200,
|
||||
"height": 100,
|
||||
"text": "# UserAPI\n\n- GET /users\n- POST /users"
|
||||
},
|
||||
{
|
||||
"id": "svc-user",
|
||||
"type": "text",
|
||||
"x": 350,
|
||||
"y": 0,
|
||||
"width": 200,
|
||||
"height": 100,
|
||||
"text": "# UserService\n\n- get_user()\n- create_user()"
|
||||
},
|
||||
{
|
||||
"id": "db",
|
||||
"type": "text",
|
||||
"x": 700,
|
||||
"y": 0,
|
||||
"width": 200,
|
||||
"height": 80,
|
||||
"text": "# PostgreSQL",
|
||||
"color": "4"
|
||||
}
|
||||
],
|
||||
"edges": [
|
||||
{
|
||||
"id": "e1",
|
||||
"fromNode": "api-user",
|
||||
"toNode": "svc-user",
|
||||
"fromSide": "right",
|
||||
"toSide": "left",
|
||||
"label": "调用"
|
||||
},
|
||||
{
|
||||
"id": "e2",
|
||||
"fromNode": "svc-user",
|
||||
"toNode": "db",
|
||||
"fromSide": "right",
|
||||
"toSide": "left"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
@@ -1,66 +0,0 @@
|
||||
# Canvas-Dev Skill References
|
||||
|
||||
## 导航索引
|
||||
|
||||
### 最新资源（优先参考）
|
||||
|
||||
| 资源 | 路径/链接 | 说明 |
|
||||
|:---|:---|:---|
|
||||
| AI架构总师完整提示词 | [Obsidian Canvas AI驱动的项目架构洞察与生成引擎.md](../../../documents/workflow/canvas-dev/Obsidian%20Canvas%20AI驱动的项目架构洞察与生成引擎.md) | 最新最完整的提示词（最高优先级） |
|
||||
| Canvas驱动开发完整工作流 | [workflow.md](../../../documents/workflow/canvas-dev/workflow.md) | 15步完整流程 |
|
||||
|
||||
### 核心文档
|
||||
|
||||
| 文档 | 路径 | 说明 |
|
||||
|:---|:---|:---|
|
||||
| Canvas白板驱动开发详解 | `../../../documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md` | 方法论详解 |
|
||||
| 白板驱动开发系统提示词（在线提示词库入口） | `../../../prompt/README.md` | 系统提示词已迁移到云端表格 |
|
||||
| Canvas JSON 规范 | [canvas-json-spec.md](./canvas-json-spec.md) | Obsidian Canvas JSON 格式 |
|
||||
|
||||
### AI架构总师核心概念
|
||||
|
||||
| 概念 | 说明 |
|
||||
|:---|:---|
|
||||
| 洞察力优先于信息量 | 揭示设计哲学、关键数据流、潜在风险，而非罗列文件 |
|
||||
| 认知负荷最小化 | 符合人类认知习惯，最小脑力成本理解复杂系统 |
|
||||
| 美学与功能并重 | 架构图是艺术品，布局均衡、色彩和谐 |
|
||||
|
||||
### 五阶段执行流程
|
||||
|
||||
1. **全局项目感知** - AST解析、加权依赖网络、元数据分析、架构模式识别
|
||||
2. **自适应粒度决策** - 信息熵拐点、架构模式引导、用户意图推断
|
||||
3. **组件语义分析** - 角色推断、关系定性、副作用分析
|
||||
4. **启发式布局** - 拓扑分层、力导向定位、动态视觉编码
|
||||
5. **输出优化** - 去交叉、边捆绑、孤立节点分组、认知路径优化
|
||||
|
||||
### 动态粒度光谱
|
||||
|
||||
| 级别 | 适用场景 |
|
||||
|:---|:---|
|
||||
| D-系统生态级 | 巨型Monorepo |
|
||||
| C-宏观服务级 | 微服务架构（推荐复杂项目） |
|
||||
| B-类/核心功能级 | 面向对象项目 |
|
||||
| A-文件级 | 中小项目（推荐新手） |
|
||||
| F-函数/方法级 | 深度钻取 |
|
||||
|
||||
### 工作流提示词
|
||||
|
||||
| 提示词 | 路径 |
|
||||
|:---|:---|
|
||||
| 架构分析提示词 | `../../../documents/workflow/canvas-dev/prompts/01-架构分析.md` |
|
||||
| 白板驱动编码提示词 | `../../../documents/workflow/canvas-dev/prompts/02-白板驱动编码.md` |
|
||||
| 白板同步检查提示词 | `../../../documents/workflow/canvas-dev/prompts/03-白板同步检查.md` |
|
||||
|
||||
### 模板
|
||||
|
||||
| 模板 | 路径 |
|
||||
|:---|:---|
|
||||
| 项目白板模板 | `../../../documents/workflow/canvas-dev/templates/project.canvas` |
|
||||
| 模块白板模板 | `../../../documents/workflow/canvas-dev/templates/module.canvas` |
|
||||
| 示例项目白板 | `../../../documents/workflow/canvas-dev/examples/demo-project.canvas` |
|
||||
|
||||
### 外部链接
|
||||
|
||||
- [Obsidian Canvas 官方文档](https://obsidian.md/canvas)
|
||||
- [Obsidian 下载](https://obsidian.md/download)
|
||||
- [胶水编程](../../../documents/principles/fundamentals/胶水编程.md) - 能抄不写，能连不造
|
||||
@@ -1,143 +0,0 @@
|
||||
# Canvas 开发提示词集合
|
||||
|
||||
## 1. 架构分析提示词
|
||||
|
||||
从现有代码生成 Obsidian Canvas 架构白板。
|
||||
|
||||
```markdown
|
||||
你是一个代码架构分析专家。请分析以下项目结构，生成 Obsidian Canvas 格式的架构白板。
|
||||
|
||||
## 输入
|
||||
项目路径：{PROJECT_PATH}
|
||||
分析粒度：{file/class/service}
|
||||
|
||||
## 输出要求
|
||||
生成符合 Obsidian Canvas JSON 格式的 .canvas 文件，包含：
|
||||
|
||||
1. **节点 (nodes)**：每个模块/文件/类作为一个节点
|
||||
2. **连线 (edges)**：表示模块间的依赖/调用关系
|
||||
3. **分组 (groups)**：按功能域分组
|
||||
|
||||
## 布局规则
|
||||
- x轴: -400 (前端) → 0 (API) → 400 (服务) → 800 (数据)
|
||||
- 节点宽度: 200-280，高度: 80-150
|
||||
- 间距: 水平 100-150，垂直 120-150
|
||||
|
||||
## 输出格式
|
||||
直接输出 JSON，可保存为 .canvas 文件
|
||||
```
|
||||
|
||||
## 2. 白板驱动编码提示词
|
||||
|
||||
根据 Canvas 白板生成代码。
|
||||
|
||||
```markdown
|
||||
你是一个根据架构白板生成代码的专家。请根据以下 Obsidian Canvas 白板 JSON，生成对应的代码实现。
|
||||
|
||||
## 输入
|
||||
Canvas JSON：
|
||||
```json
|
||||
{CANVAS_JSON}
|
||||
```
|
||||
|
||||
技术栈：{TECH_STACK}
|
||||
目标目录：{TARGET_DIR}
|
||||
|
||||
## 解析规则
|
||||
1. 节点 text 标题 → 文件名/类名
|
||||
2. 节点 text 列表项 → 方法/函数
|
||||
3. 连线 fromNode → toNode = import/调用关系
|
||||
4. edge label 决定关系类型
|
||||
|
||||
## 输出格式
|
||||
```
|
||||
文件：{文件路径}
|
||||
```{语言}
|
||||
{代码内容}
|
||||
```
|
||||
```
|
||||
|
||||
## 3. 白板同步检查提示词
|
||||
|
||||
校验白板与代码一致性。
|
||||
|
||||
```markdown
|
||||
你是一个代码与架构一致性检查专家。请对比以下白板和代码，找出不一致之处。
|
||||
|
||||
## 输入
|
||||
Canvas 白板 JSON：
|
||||
```json
|
||||
{CANVAS_JSON}
|
||||
```
|
||||
|
||||
项目代码路径：{PROJECT_PATH}
|
||||
|
||||
## 检查项
|
||||
1. 节点完整性：白板节点是否都有对应代码？
|
||||
2. 连线准确性：连线是否反映真实依赖？
|
||||
3. 分组正确性：分组是否与目录结构一致？
|
||||
|
||||
## 输出格式
|
||||
### 🔴 严重不一致
|
||||
| 类型 | 白板 | 代码 | 建议 |
|
||||
|
||||
### 🟡 轻微不一致
|
||||
| 类型 | 白板 | 代码 | 建议 |
|
||||
|
||||
### 🟢 一致性良好
|
||||
- 覆盖率：{X}%
|
||||
```
|
||||
|
||||
## 4. 增量更新提示词
|
||||
|
||||
白板修改后同步更新代码。
|
||||
|
||||
```markdown
|
||||
白板已更新，请对比新旧版本，只修改变化的部分：
|
||||
|
||||
旧白板：
|
||||
```json
|
||||
{OLD_CANVAS_JSON}
|
||||
```
|
||||
|
||||
新白板：
|
||||
```json
|
||||
{NEW_CANVAS_JSON}
|
||||
```
|
||||
|
||||
## 输出
|
||||
1. 需要新增的文件
|
||||
2. 需要修改的文件（只输出 diff）
|
||||
3. 需要删除的文件
|
||||
```
|
||||
|
||||
## 5. 快速理解项目提示词
|
||||
|
||||
接手新项目时快速生成架构概览。
|
||||
|
||||
```markdown
|
||||
我需要快速理解这个项目的架构。请：
|
||||
|
||||
1. 扫描 {PROJECT_PATH} 目录
|
||||
2. 识别核心模块和入口文件
|
||||
3. 生成一个简化的架构白板（只包含关键模块）
|
||||
4. 用 3-5 句话总结项目架构
|
||||
|
||||
粒度：service（只显示大模块）
|
||||
重点：数据流向、外部依赖、核心业务逻辑
|
||||
```
|
||||
|
||||
## 使用技巧
|
||||
|
||||
### 提高生成质量
|
||||
|
||||
1. **明确粒度**：小项目用 file，大项目用 service
|
||||
2. **指定重点**：告诉 AI 关注什么（API/数据库/外部服务）
|
||||
3. **提供上下文**：附上 README 或技术栈说明
|
||||
|
||||
### 迭代优化
|
||||
|
||||
1. 第一次生成后，手动调整布局
|
||||
2. 补充 AI 遗漏的隐式依赖
|
||||
3. 添加注释节点说明设计决策
|
||||
4. 再次发给 AI 验证理解是否正确
|
||||
@@ -1,163 +0,0 @@
|
||||
# Canvas 白板驱动开发工作流指南
|
||||
|
||||
## 核心理念
|
||||
|
||||
```
|
||||
传统开发：代码 → 口头沟通 → 脑补架构 → 代码失控
|
||||
Canvas方式：代码 ⇄ 白板 ⇄ AI ⇄ 人类（白板为单一真相源）
|
||||
```
|
||||
|
||||
**图形是第一公民，代码是白板的序列化形式。**
|
||||
|
||||
## 工具准备
|
||||
|
||||
1. **Obsidian** - 免费开源白板工具
|
||||
- 下载: https://obsidian.md/download
|
||||
- 启用 Canvas 功能（默认已启用）
|
||||
|
||||
2. **AI 助手** - Claude/GPT-4
|
||||
- 需支持读取 Canvas JSON 格式
|
||||
- 推荐使用 Claude Code 或 Codex CLI
|
||||
|
||||
## 完整工作流
|
||||
|
||||
### Phase 1: 生成架构白板
|
||||
|
||||
**场景**: 接手新项目，快速理解架构
|
||||
|
||||
```
|
||||
1. 提供项目代码路径给 AI
|
||||
2. 使用架构分析提示词
|
||||
3. AI 生成 .canvas 文件
|
||||
4. 用 Obsidian 打开查看
|
||||
```
|
||||
|
||||
**提示词模板**:
|
||||
```
|
||||
分析 {PROJECT_PATH} 项目，生成 Obsidian Canvas 架构白板。
|
||||
粒度: {file/class/service}
|
||||
重点关注: API路由、数据库模型、外部服务调用
|
||||
```
|
||||
|
||||
### Phase 2: 人工优化白板
|
||||
|
||||
**场景**: 调整自动生成的白板
|
||||
|
||||
```
|
||||
1. 拖动节点调整布局
|
||||
2. 补充遗漏的依赖连线
|
||||
3. 添加注释节点标注设计决策
|
||||
4. 删除错误的连接
|
||||
```
|
||||
|
||||
**布局原则**:
|
||||
- 按功能分层（前端 → API → 服务 → 数据）
|
||||
- 同层节点垂直对齐
|
||||
- 保持连线不交叉
|
||||
|
||||
### Phase 3: 白板驱动编码
|
||||
|
||||
**场景**: 新功能开发
|
||||
|
||||
```
|
||||
1. 在白板上画出新模块框
|
||||
2. 添加预期的调用连线
|
||||
3. 导出白板 JSON 发给 AI
|
||||
4. AI 根据白板生成代码
|
||||
```
|
||||
|
||||
**提示词模板**:
|
||||
```
|
||||
根据以下 Canvas 白板生成代码:
|
||||
{CANVAS_JSON}
|
||||
|
||||
技术栈: {TECH_STACK}
|
||||
目标目录: {TARGET_DIR}
|
||||
```
|
||||
|
||||
### Phase 4: 白板驱动重构
|
||||
|
||||
**场景**: 架构调整
|
||||
|
||||
```
|
||||
1. 在白板上删除/重连依赖线
|
||||
2. 标注需要拆分的大模块
|
||||
3. 发送修改后的白板给 AI
|
||||
4. AI 生成重构代码
|
||||
```
|
||||
|
||||
**提示词模板**:
|
||||
```
|
||||
白板已更新，请对比新旧版本重构代码:
|
||||
旧白板: {OLD_CANVAS}
|
||||
新白板: {NEW_CANVAS}
|
||||
只输出需要修改的文件
|
||||
```
|
||||
|
||||
### Phase 5: 一致性检查
|
||||
|
||||
**场景**: PR/MR 合并前
|
||||
|
||||
```
|
||||
1. 运行一致性检查脚本
|
||||
2. 对比白板节点与实际文件
|
||||
3. 修复不一致之处
|
||||
4. 优先修正白板（白板是事实来源）
|
||||
```
|
||||
|
||||
## 场景速查
|
||||
|
||||
| 场景 | 操作 | 提示词关键词 |
|
||||
|:---|:---|:---|
|
||||
| 接手新项目 | 生成白板 | "分析项目，生成架构白板" |
|
||||
| 新功能开发 | 画白板 → 生成代码 | "按这个白板实现代码" |
|
||||
| 架构重构 | 改白板 → 重构代码 | "按新白板重构" |
|
||||
| Code Review | 看白板全局 | "检查这条调用链" |
|
||||
| 团队协作 | 共享白板 | "指着白板讲" |
|
||||
|
||||
## 最佳实践
|
||||
|
||||
### DO ✅
|
||||
|
||||
- 每次代码变更后更新白板
|
||||
- 用颜色区分不同类型的模块
|
||||
- 为复杂依赖添加 label 说明
|
||||
- 定期运行一致性检查
|
||||
|
||||
### DON'T ❌
|
||||
|
||||
- 不要让白板与代码长期不同步
|
||||
- 不要在白板中包含敏感信息
|
||||
- 不要创建过于复杂的白板（拆分为多个）
|
||||
- 不要忽略循环依赖警告
|
||||
|
||||
## 与其他工具集成
|
||||
|
||||
### 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
|
||||
- run: python scripts/canvas_sync_check.py
|
||||
```
|
||||
|
||||
### VS Code 集成
|
||||
|
||||
1. 安装 Obsidian 插件
|
||||
2. 配置 `.canvas` 文件关联
|
||||
3. 使用 Claude Code 读取白板
|
||||
|
||||
## 相关资源
|
||||
|
||||
- [Canvas白板驱动开发详解](../../../documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md)
|
||||
- [架构分析提示词](../../../documents/workflow/canvas-dev/prompts/01-架构分析.md)
|
||||
- [白板驱动编码提示词](../../../documents/workflow/canvas-dev/prompts/02-白板驱动编码.md)
|
||||
- [白板同步检查提示词](../../../documents/workflow/canvas-dev/prompts/03-白板同步检查.md)
|
||||
@@ -1 +1 @@
|
||||
../repo/claude-official-skills
|
||||
../repos/claude-official-skills
|
||||
Reference in New Issue
Block a user