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

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

1. 思维导图介绍

体验地址： https://mind.su007.club/ 项目github地址： https://github.com/linkxzhou/SimpleMind

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，这样能定义功能边界，防止模型太过于发散导致重构的困难加大；
• ....