31 lines
3.3 KiB
Markdown
31 lines
3.3 KiB
Markdown
🚀 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检查）；分享最佳实践案例到团队知识库 |