开源项目|不一样的思维导图

最近在参加公司的 Agent 比赛，尝试将一个想法用完整的 Vibe Coding 流程来实现，经过一些曲折，最后完成了，比传统Coding的效率的确提升了5倍左右，先介绍项目，最后再写开发总结。

1. 思维导图介绍

1.1 功能介绍

之前使用过市场上各种思维导图，虽然很多搭载了AI的功能，但是基本上都需要自己写提示词，其实使用思维导图往往是想整理思路，如果能将自己的思路再用提示词整理一遍，其实已经不需要思维导图了，所以开发脑图的目的是为了让使用者沉浸式思路，AI辅助续写。

基于以上思考，开发这块产品首先用户需要设置的东西要少，界面要简单，所以首页是这样的：

PC浏览器上：

手机端：

为了减少用户对功能的焦虑，toolbar 只提供常用的功能：

设置中的功能主要功能包括：

AI的通用设置
布局：支持思维导图，逻辑结构图，组织结构图，目录组织图，时间轴，鱼骨图
生成节点数
私有知识库
导入JSON等
导出JSON，图片等

1.2 模版列表

模版列表的目的是方便用户不需要关心提示词，比如读书笔记，在思维导图中是有一种通用的模式，充分利用大模型已有的知识，整理思考方式，当前功能后续会扩充更多的思考模版，目前支持：

读书笔记
第一性原理分析问题

1.3 提示词

对于知识整理，提示词比较重要，为了大家方便复现生成，所以生成过程中会展示提示词，比如《如何制造火箭？》

2. 总结

2.1 `Vibe Coding` 还是 `Spec Coding` 开发方式对比

Andrej Karpathy在2025年初提出的 "Vibe Coding" 概念，强调 "忘记代码存在，专注创意表达" 的开发模式，是一种直觉驱动的快速原型方法，通过自然语言与AI对话，以极高的速度将模糊想法转化为可运行代码。
"Spec Coding" 则是一种规范驱动的可控工程方法，强调在编码前通过结构化的文档明确需求和设计，再让AI在严格约束下生成代码。

以上两种编程方式各有利弊，对于团队协作和需要长期维护的系统，必须要有一套规范化的工程文件，比如 requirements.md、design.md、tasks.md，定义清楚功能边界，设计边界，任务边界等，所以 "Spec Coding" 是必须的。

对于创意探索和MVP验证，不在乎质量，只是为了做原型验证，"Vibe Coding" 能快速搭建工程。不过我个人用AI开发一些工具经验而言，无论什么项目，其实都可以从 "Vibe Coding"，当你完整探索了这个项目的边界的时候，再转向 "Spec Coding"，对于工程开发人员这个可能是比较自然的过程。

就像《黑客与画家》一书中描述程序员和画家的相似之处在于不断修改你工程，让其更丰富，除非重构型的项目，一般项目开始定义的功能拆解，AI可能比我们想的功能更丰富。

所以想使用 Vibe Coding 开发，不断探索边界，然后将边界框定好了以后，整理规范化的工程文件，对项目进行重构，进入 Spec Coding，这个也是我开发思维导图的方式。

2.2 `Code is cheap, show me the product`

之前一直说：Code is cheap, show me the talk，其实产品才是 AI 时代最应该关注的。

现在利用 CodeBuddy, Codex，TRAE 等编程工具，10分钟就可以实现一个完整的 Demo，但是要将这个 Demo 打造成一款伟大的产品却很难。

虽然做过很多小的demo，这个方面没有发言权，不过我觉得我会一直遵循精益求精的原则，不断是完善一个工具。

2.3 如何减少代码出错的概率

之前写过很多 Prompt 技巧，这里就不说了，这里总结项目减少出错可能在于框架的选择：

优先选择开源社区通用的框架，比如前端使用 vue + ant-design，首先模型已经有相关知识，出错的概率比较少，另一个组件比较丰富，复用的组件越多，使用的代码就越少，出错的概率就越小；
作为一个后端开发，个人经验是，如果能用前端实现的，就必要用到后端功能，即使必须要用后端，可以优先考虑 Supabase, FireBase 等 BaaS 框架解决后端问题；
不要将功能堆到一个文件中，单个文件不建议超过 500 行，如果超过就尝试将功能拆解出来，毕竟现在的大模型上下文太大，会遇到各种幻觉问题；
尽量写好 requirements.md、design.md，这样能定义功能边界，防止模型太过于发散导致重构的困难加大；
....