Synapse Solo 发布：面向一人公司和个人开发者的轻量工程记忆产品

最近把之前持续迭代的工程记忆方案，整理成了一个新的衍生产品：

Synapse Solo

GitHub 地址：

https://github.com/LameGz/Synapse-Solo

这次它不再只是一个技术实验或者概念验证，而是一个可以直接 clone、可以运行 demo、可以接入项目的轻量工程记忆产品。

它的目标很明确：

面向一人公司、个人开发者、独立开发者，以及经常使用 Coding Agent 做全栈产品开发的人，提供一个轻量、本地、可解释的工程记忆方案。

---

一、为什么要做 Synapse Solo？

现在很多个人开发者已经开始用 Coding Agent 做项目。

比如 Claude Code、Codex、Cursor、Windsurf 这类工具，已经可以帮助我们完成大量编码工作。

但在真实项目里，一个很大的问题是：

Agent 会写代码，但它不一定能稳定记住项目。

尤其是一个人做全栈产品的时候，这个问题会更明显。

一个个人开发者往往不是只写某一块代码，而是同时在做：

• 前端页面；
• 后端接口；
• 数据库设计；
• 登录鉴权；
• 会员订阅；
• 支付回调；
• UI 组件；
• 部署运维；
• 文档；
• 测试。

今天你可能在做登录，明天去接支付，后天又要处理订阅激活后的通知。

这时候真正麻烦的不是“代码不会写”，而是：

项目上下文会断。

你过几天再打开项目，或者换一个新的 Agent 会话，经常要重新解释：

• 这个项目做到哪了；
• 登录接口是什么；
• 支付回调接在哪里；
• 用户套餐字段叫什么；
• 哪些模块之间有依赖；
• 哪些问题还没处理；
• 当前任务应该读哪些文件。

如果每次都让 Agent 重新读整个仓库，成本高，噪音也大。

如果只靠一个 summary.md，时间一长又会变成一个越来越乱的大文件。

这就是 Synapse Solo 想解决的问题。

---

二、一人公司和个人开发者真正需要什么？

我做这个产品时，一直有一个很明确的判断：

一人公司不需要一个很重的企业知识库。

个人开发者也不需要一上来就搞：

• 图数据库；
• 向量数据库；
• GraphRAG 平台；
• Web 知识后台；
• 多用户权限系统；
• 企业级知识管理流程。

这些东西对大团队可能有价值，但对一个人做产品来说，往往太重了。

一个人真正需要的是：

1. 项目状态不要丢

   今天做完的登录、支付、订阅，明天 Agent 还能知道。

2. 模块关系能看懂

   支付和用户账户有关，订阅和通知有关，这些关系应该被记录下来。

3. 上下文不要塞爆

   Agent 不应该每次都读完整仓库，而是读当前任务相关的上下文。

4. 记录方式要简单

   最好就是写一句自然语言，而不是手动维护复杂图结构。

5. 所有东西本地可控

   不依赖外部平台，不需要额外部署，直接放在项目里。

Synapse Solo 的定位就是围绕这些需求展开的。

---

三、Synapse Solo 是什么？

一句话介绍：

Synapse Solo 是一个面向一人公司和个人开发者的轻量工程记忆产品，它把自然语言开发记录转换成一个本地、可解释、可被 Coding Agent 按需读取的工程记忆图。

它的核心结构很简单：

Markdown 节点
+ 自动生成 MEMORY_MAP
+ 本地脚本
+ Agent 可读取上下文

它不是一个复杂平台，而是项目旁边的一层轻量工程记忆。

你可以把它理解成：

代码仓库之外，专门给 Coding Agent 看的项目记忆层。

代码仓库记录“代码是什么”。

Synapse Solo 记录：

• 项目状态；
• 模块边界；
• 模块之间的依赖；
• 最近开发进展；
• open issues；
• 哪些上下文应该一起读取。

这样 Agent 进入项目时，不需要从零理解，也不需要把整个仓库塞进上下文。

---

四、它怎么工作？

Synapse Solo 的使用方式尽量贴近个人开发者的真实工作流。

你不需要手动写复杂配置，也不需要手动画图。

你只需要写一条自然语言开发记录：

会员订阅接好了，支付回调 POST /api/v1/payments/callback 成功后更新用户套餐。

Synapse Solo 会把它整理成工程记忆节点，并推断相关模块关系：

feat_subscription
  ├── auto_linked -> mod_payment
  └── auto_linked -> mod_user-account

这里有两个关键概念：

1. Markdown 节点

每个模块或功能都会变成一个 Markdown 节点，例如：

meta/
├── mod_payment.md
├── mod_user-account.md
├── mod_notification.md
├── feat_subscription.md
└── feat_admin-notification.md

这些节点不是黑盒数据，而是普通 Markdown 文件，人可以直接读，Agent 也可以直接读。

2. MEMORY_MAP

Synapse Solo 会自动生成：

MEMORY_MAP.md
MEMORY_MAP.json

它们相当于项目记忆的索引。

Agent 可以先读 MEMORY_MAP，再决定当前任务应该加载哪些节点。

这样就避免了每次都全量读取仓库。

---

五、为什么是“图”，但又不是重型图谱？

这里的“图”不是那种复杂知识图谱平台。

Synapse Solo 的图非常轻：

节点 = Markdown 文件
边 = depends_on / auto_linked
索引 = MEMORY_MAP

它只关心工程开发里真正有用的关系：

• 这个功能依赖哪个模块；
• 这个模块会影响哪些功能；
• 当前任务应该读取哪些上下文；
• 哪些改动可能影响下游。

比如：

feat_admin-notification
  ├── auto_linked -> mod_notification
  ├── auto_linked -> mod_user-account
  └── auto_linked -> feat_subscription

这说明后台通知功能和通知模块、用户账户、订阅功能有关。

下次你让 Agent 修改订阅激活逻辑时，它就不应该只看订阅文件，而应该知道通知模块也可能受到影响。

这就是轻量图结构的价值。

---

六、一个典型的个人全栈开发场景

Synapse Solo 里自带了一个 solo-saas 示例。

它模拟的是一个个人开发者连续几天做 SaaS 产品：

Day 1: login
Day 2: subscription/payment
Day 3: admin notification after subscription activation

第一天做登录：

feat_login
  ├── auto_linked -> mod_auth-api
  └── auto_linked -> mod_design-system

第二天做订阅支付：

feat_subscription
  ├── auto_linked -> mod_payment
  └── auto_linked -> mod_user-account

第三天做后台通知：

feat_admin-notification
  ├── auto_linked -> mod_notification
  ├── auto_linked -> mod_user-account
  └── auto_linked -> feat_subscription

这其实就是个人开发者最常见的工作状态：

• 今天做 A；
• 明天做 B；
• 后天 B 又依赖 A；
• 下周再回来时，已经忘了一部分上下文；
• Agent 也不知道哪些模块有关。

Synapse Solo 的作用就是把这种连续开发链路记录下来。

---

七、现在这个产品已经做到什么程度？

这次发布的 Synapse Solo，已经不是一个单纯的 README 或概念说明。

它现在包含：

• 自然语言开发记录解析；
• Markdown 记忆节点；
• 自动生成 MEMORY_MAP.md；
• 自动生成 MEMORY_MAP.json；
• 机器建议边 auto_linked；
• 显式依赖 depends_on；
• Timeline 查询；
• Open Issues 查询；
• 初始化脚本；
• doctor 健康检查；
• solo SaaS 示例；
• 一键 demo；
• release check；
• 中文 README；
• 英文 README；
• 测试用例。

也就是说，它已经具备一个轻量开源产品的基本完整度：

能安装
能运行
有示例
有文档
有测试
有发布检查

从产品成熟度上看，我认为它已经从“技术实验”进入到了“可用产品雏形”的阶段。

---

八、怎么快速试一下？

1. 初始化一个项目

bash scripts/init.sh --project ./my-project --yes

执行后会生成：

my-project/
├── meta/mod_project.md
├── MEMORY_MAP.md
└── MEMORY_MAP.json

2. 运行内置 demo

bash scripts/demo_solo_saas.sh

这个 demo 会展示一个个人 SaaS 产品三天开发过程中的记忆图变化。

3. 记录一条开发进展

bash scripts/synapse_note.sh \
  --project examples/solo-saas \
  --text "后台通知接好了，会员订阅激活后发送 notification。" \
  --dry-run

4. 查询最近进展

bash scripts/query_timeline.sh --project examples/solo-saas --summary --limit 5

5. 查询还有什么没做完

bash scripts/query_timeline.sh --project examples/solo-saas --issues

6. 发布前检查

bash scripts/release_check.sh

---

九、它适合谁？

我觉得 Synapse Solo 比较适合：

• 一人公司；
• 独立开发者；
• 个人全栈开发者；
• Solo Builder；
• 经常使用 Coding Agent 写代码的人；
• 项目还没大到需要企业知识库，但又已经复杂到不能只靠脑子记的人。

尤其适合这种情况：

一个人同时做前端、后端、UI、支付、部署、文档和测试。

如果你经常在多个模块之间切换，又经常让 Agent 参与开发，那么 Synapse Solo 可以帮你把项目上下文稳定下来。

---

十、它不适合什么？

Synapse Solo 不是万能的。

如果你需要的是：

• 多团队协作知识库；
• 企业权限系统；
• 大规模文档搜索；
• 向量检索平台；
• 图数据库分析；
• Web 后台管理系统；

那它不是这个方向。

它更关注一个小而明确的场景：

个人开发者如何低成本维护工程上下文，让 Coding Agent 能长期参与项目开发。

---

十一、为什么我觉得它有价值？

现在 Coding Agent 的代码能力越来越强。

但真实项目里，决定 Agent 能不能持续帮上忙的，不只是“会不会写代码”，还有一个更基础的问题：

它能不能理解当前项目？

而项目理解不是一次性的。

一个项目会持续变化：

• 今天加了登录；
• 明天加了支付；
• 后天改了用户模型；
• 下周又要做通知；
• 再过几天还要回头修 bug。

如果没有一层稳定的工程记忆，Agent 每次都像重新入职。

Synapse Solo 想做的就是这层东西：

让 Agent 不再每次从零理解项目。

它不复杂，但足够实用。

---

十二、总结

Synapse Solo 是一个面向一人公司和个人开发者的轻量工程记忆产品。

它的目标不是做大平台，而是解决一个非常具体的问题：

一个人做全栈产品时，如何让 Coding Agent 稳定记住项目状态、模块依赖和最近进展？

它通过：

自然语言开发记录
+ Markdown 记忆节点
+ 自动生成 MEMORY_MAP
+ 机器建议关系
+ 本地脚本工作流

提供了一个轻量、可解释、可维护的方案。

目前它已经整理成一个可以直接运行的开源项目。

GitHub 地址：

https://github.com/LameGz/Synapse-Solo

如果你也是个人开发者，或者正在尝试用 Coding Agent 做完整产品，可以看看这个项目。

它不一定是最终答案，但我觉得它已经是一个比较成熟、可用、方向清晰的轻量工程记忆产品。