Featured image of post 我用 Claude Code 给自己造了一个 Founder OS：155 个散落文件的重构实录
个人随想

我用 Claude Code 给自己造了一个 Founder OS：155 个散落文件的重构实录

独立开发者的想法散落在聊天记录、Word、桌面文件和 AI 对话里,越攒越乱。这篇文章记录我用一个下午把它们收进一套 Markdown First / Local First / Git Friendly 的个人知识库与项目管理系统——LynxOS:8 个目录的设计逻辑、为什么砍掉'想法'文件夹、7 条 AI 工作红线、以及让 Claude Code 能持续理解和操作这套系统的关键配置。最后附完整的目录结构和模板,可以直接抄。

English
新发布

起因:155 个文件教会我的事

先看一组数字:我的 WSL 家目录下,散落着 155 个 Markdown 文件。

不是 155 个笔记——是 155 个"很重要但不知道放哪"的文件。里面有 41 份行业调研(ERP 选型、VPS 迁移、大模型排名),有 30 份运维复盘(服务挂掉的凌晨写的),有 20 份个人文档(帮表弟填的高考志愿、自己的简历),还有十几个项目的手写交接单。

它们全都躺在 /home/li 根目录,和 500 多个其他文件混在一起。每次想找"上次那个 Lightsail 定价调研",我只能 ls | grep lightsail,然后祈祷我记得文件名。

这就是独立开发者的真实处境:想法的产生速度,远超想法的组织速度。每天冒出的新念头散落在聊天记录、Word、桌面文件夹、Claude Code 对话里,一个项目同时涉及研究、商业模式、营销、执行、实验、复盘——但没有任何一个工具能把这些串起来。

Notion?我的核心知识资产不想绑死在 SaaS 上。Obsidian?软件很好,但我的第二大脑其实在 Claude Code 的记忆库里(527 个记忆文件,跨会话存活),不在任何笔记软件里。

所以我决定造一个东西,暂命名 LynxOS:一个 Founder Knowledge Base + 项目管理系统 + AI Agent 工作区三合一的文件系统。这篇文章是完整的建造实录,目录结构、设计取舍、AI 规则、模板,全部可以直接抄。

核心原则:五条,缺一不可

设计之前先定宪法。这五条原则决定了后面所有取舍:

1. Markdown First —— 所有重要知识最终必须落地为 .md 文件。不能存在某个数据库里,不能存在于"只有某个软件才能读"的格式里。

2. Local First —— 本地文件是 source of truth。任何软件(Obsidian、VS Code、未来的什么工具)都只是这些文件的界面,换了软件文件还在。

3. Git Friendly —— 目录结构适合 Git 版本控制。不产生二进制数据库文件,文本 diff 可读,历史可回溯。

4. AI Friendly —— Claude Code 能搜索、阅读、分类、创建、修改、总结这些文件,能生成项目报告、做项目复盘。这系统不只是给我看的,也是给 AI 用的工作台。

5. Inbox First —— 任何突然产生的想法,都必须有一个"无脑入口"。产生想法的时候不应该纠结"这个放哪个文件夹"。

第五条是最容易被忽视、也最决定生死的一条。大多数笔记系统死于同一个原因:记录的摩擦太大。你在地铁上想到一个点子,打开笔记软件,面对十几层文件夹,想了 10 秒"这算商业想法还是技术想法",然后关掉软件去刷手机了。摩擦杀死记录。

目录结构:8 个桶

最终结构长这样:

1
2
3
4
5
6
7
8
9

LynxOS/
├── 00-Inbox/          # 无脑入口,允许一切烂想法
├── 01-Projects/       # 每个项目一个文件夹,README.md 是项目卡
├── 02-Marketing/      # 跨项目复用的营销方法论
├── 03-Research/       # 跨项目复用的调研报告
├── 04-SOP/            # 验证过的方法终点站
├── 05-Memory/         # 运维复盘与踩坑沉淀
├── 06-Archive/        # 死掉的想法和完结项目
└── 99-System/         # dashboard/规范/AI规则/模板

看起来平平无奇?魔鬼在取舍里。说说三个关键决策。

砍掉"Ideas"文件夹

最初的设计里有一个 02-Ideas/,专门放"值得记录但还没成项目"的想法。砍掉它,是因为想明白了一件事:

Inbox 和 Ideas 是两个放想法的地方,而两个放想法的地方等于每个都要纠结一次。

正确的做法是:想法只有一个人口(Inbox),整理后直接变成项目文件夹,用状态而非位置区分阶段。一个新想法被判定"有点意思",就从 Inbox 移出,在 01-Projects/ 建一个文件夹,项目卡上写 status: Idea——注意,这时候它还没有代码,没有排期,只有一张卡。等它变成真的项目,把 status 改成 Research、Planned、Active。阶段是卡片上的一个字段,不是文件夹结构。

这样"想法 → 项目"是同一条流水线,不存在"想法什么时候升级成项目"这个分类难题。

项目默认只有一张卡,不预建全家桶

常见的项目管理模板长这样:每个项目下预建 research/ marketing/ execution/ experiments/ assets/ 全套子目录。看着专业,实际上是空文件夹的心理负担——多数项目用不到全部子目录,一堆空文件夹躺在那里,每次打开都在提醒你"还有五个方面你没做"。

我的做法:新项目只有一个 README.md(项目卡),模板里写清楚"何时加哪个子目录"——真的要跑实验了,再建 experiments/;真的要做营销了,再建 marketing/。目录是长出来的,不是铺出来的。

项目卡本身也极简,只有这几块:一句话定位、状态与下一步(只一个动作)、背景、核心判断(商业模式假设/关键风险/差异化)、资源指针(代码仓在哪、相关研究在哪)、决策记录表。15 行以内能填完。

营销知识单独一个桶,分清"这次用的"和"下次还能用的"

这是最容易混的两个东西:

  • 项目专属策略:“LinuxDo 公益站这次投 Google Ads 用了什么关键词、什么落地页” → 放 01-Projects/linuxdo/marketing/
  • 可复用方法论:“Google Ads 冷启动的通用打法” → 放 02-Marketing/Google-Ads/cold-start.md

前者是这次战役的记录,后者是沉淀下来的商业能力。混在一起的后果是:下次做新项目,想复用上次的经验,却发现在上一个项目的文件夹深处,根本想不起来。分开放,02-Marketing/ 就是你的"营销兵器库",按渠道分子目录(Google-Ads/ Telegram/ SEO/),新项目开打前先翻一遍。

生命周期:想法怎么变成能力

整套系统围绕一条流水线运转:

1
2

Idea → Inbox → Research → Decision → Project → Strategy →
Execution → Experiment → Review → SOP

一个想法走完全程,终点不是"项目结束",而是 SOP(标准操作程序)——一个被实验验证过有效的方法,从具体项目中提炼出来,写成可重复执行的步骤,放进 04-SOP/。

比如"Telegram 频道冷启动"这个方法:第一次在项目 A 里尝试,记录实验假设、执行过程、真实数据;验证有效后,提炼成 SOP(适用场景、步骤、关键参数、预期 CAC、踩坑清单);下次项目 B 要做 TG 推广,直接打开 SOP 照着跑。

这就是"可重复的商业能力"和"一次性努力"的区别。项目的生死不可控,但方法论的复利可控。SOP 库越厚,每个新项目的冷启动越快——这是这套系统里唯一只增不减的资产。

AI 规则:给 Claude Code 立法

这套系统能不能长期活着,一半取决于我,一半取决于 AI 会不会把它搞乱。Claude Code 会热心地帮你"整理",如果不加约束,它可能把一个简单想法拆成十几个文件,或者为了目录整洁把你的原始想法重写成人话——原始想法的混乱本身就是信息。

所以 99-System/AI-RULES.md 是整个系统里最重要的文件。两部分:

可以做的:整理 Inbox(移动前列清单等确认)、识别重复(合并前列差异让你裁决)、用模板建项目卡、补充项目结构(只在推进到该阶段时)、分析研究、协助生成营销策略和实验方案(标注推测)、分析实验结果、提炼 SOP(确认后入库)、更新 dashboard。

八条红线:

  1. 不要随意删除原始想法——再烂的想法也只归档不删除
  2. 不要覆盖重要资料——改写前列 diff
  3. 不要为了"整洁"过度重构——结构稳定性优先于美观
  4. 不要制造没有实际价值的 Markdown——没内容就留空,不填占位符
  5. 不要把一个简单想法拆成十几个文件
  6. 不要未经确认修改已完成的商业结论
  7. 不要假装完成没执行过的实验——result 只能来自真实数据
  8. 不要把推测写成事实——推测必须显式标注

第 7、8 条看着多余,其实是 AI 时代知识库最容易烂掉的地方:如果哪天你发现自己 SOP 库里的"验证数据"是 AI 编的,这个库就失去信用了,而失去信用的知识库不如没有。红线本质上是在保护知识库的信用。

另外还有一条批量门禁:涉及 5 个以上文件的移动/重命名/删除,必须先输出完整清单等确认。这次迁移 145 个文件,AI 先生成了完整清单、我对账(它第一次列了 139 个,漏了 15 个,复查才补齐——AI 的批量操作必须有核对机制)、确认后才执行。

实战:一个下午收编 155 个文件

系统建好只是开始,存量才是硬仗。我的迁移分五批:

批次去向数量内容
A01-Projects/(12 个项目卡)36各项目的交接单/计划/验收
B03-Research/46ERP、VPS 选型、模型排名等调研
C05-Memory/30运维复盘、审计报告、服务清单
D06-Archive/personal/20高考志愿、简历、考研文档
E06-Archive/ops/15一次性提交稿、todo

几个实战细节:

先对账再动手。 迁移清单生成后,用脚本核对"根目录实际文件数 vs 清单覆盖数",发现 15 个漏网之鱼(AI 生成的清单声称覆盖全部,实际没有)。没有这步对账,这 15 个文件就永远丢在根目录的噪声里了。

有意识地留例外。 三个文件留在原地不动:AGENTS.md 是 AI harness 的配置文件,被每个会话读取,移动会破坏注入;另两个用途不明,先辨认再说。“全部搬干净"不是目标,“每个文件都在该在的地方"才是。

原名迁移不重命名。 虽然命名规范要求小写+连字符,但历史文件保留原名——重命名 145 个文件制造 145 个断链风险(记忆库、外部脚本可能引用原路径),不值得。规范只约束新建文件。

每批一个 commit。 迁移全部用 Git 记录,任何一步搞砸了都能回滚。最后推到 GitHub 私库——知识库是资产,资产要异地备份。

迁移完成后,根目录的 md 文件从 155 降到 3,12 张项目卡让所有项目的状态一眼可见。原来"想找上次那个调研"是 ls | grep,现在是打开 dashboard,或者直接问 Claude Code:“哪些项目是 Active 状态,每个的下一步是什么?”

dashboard:一页看全局

99-System/dashboard.md 是整个系统的入口,纯 Markdown,九个区块:Active Projects(表格:项目+下一步)、Paused、Completed、Inbox 数量、需要关注(Next 超过 14 天没动的项目)、最近更新的研究、实验、最近完结、SOP 库。

它不追求漂亮,追求的是:每次打开 Claude Code,说一句"更新 dashboard”,AI 扫一遍项目卡就能重绘全局。想看项目详情,顺着卡片上的指针跳;想看某个项目为什么停了,卡片的状态和决策记录写着。

为什么这套系统能活 3-5 年

大部分笔记系统死于三个原因:记录摩擦太大(Inbox 解决)、结构太重想法配不上(薄项目卡解决)、AI 把库改乱(红线解决)。但长期存活的真正底气是另外三点:

它寄生在你已有的工作流上,不新增工具。 我不需要"打开笔记软件"这个动作——Claude Code 就是界面,VS Code 就是界面,grep 就是搜索。系统只是把我本来就在产生的文件收进结构里。

它是给 AI 的工作台,不只是给人的笔记本。 frontmatter 里的 status 字段、统一的项目卡结构、grep 友好的命名规范——这些约定让 Claude Code 能可靠地定位、读取、更新任何信息。“整理 Inbox"“总结 lynxact 的营销策略"“哪些营销方法经过实验验证"这些指令都能落地,因为结构是机器可读的。未来接 RAG、接自动化工作流,接口都是现成的。

资产属性随时间递增。 项目会死(我的房产平台 Lynxhouse 就刚判了 NO-GO),但它的复盘和教训进了 Memory 桶,验证过的方法进了 SOP 桶——项目的尸体变成系统的肥料。跑过的每一步都在给 SOP 库和 Memory 库充值,这两样只增不减。

番外：接 Obsidian，踩了一个真实的坑

系统建好的当晚,我把 Obsidian 也接上了——毕竟之前说过"任何软件都只是这些文件的界面”,得验证一下这句话。

结果踩了一个坑:把 Obsidian 的 vault 直接指向 WSL 里的 \\wsl.localhost\Ubuntu\home\li\LynxOS,打不开,报 EISDIR illegal operation on a directory。原因是 Obsidian 的文件监听机制(chokidar)不支持网络路径——能读文件,但没法"盯着"它。

解法很朴素:把 LynxOS 从 WSL 家目录挪到 Windows 文件系统(C:\Users\li\Documents\LynxOS),WSL 这边走 /mnt/c 照样读写,git 一个字节没变——182 个文件跨文件系统挪完后 mode 从 100644 变成了 100755,设 git config core.fileMode false 就干净了。

接上之后,画风是这样的:我在 Obsidian 里打开 dashboard 看"哪些项目还活着、下一步是什么”,顺手在项目卡上改两笔;Claude Code 在终端里跑批量整理、补模板、迁移文件。两头改的是同一份文件,git 记录一切,谁改的、什么时候改的,一清二楚。

这大概就是"Local First"最具体的回报:界面坏了换个姿势(换个软件、换个路径),文件纹丝不动。当初坚持 Markdown First、不绑死在任何软件上,在这一刻兑现了。

Obsidian 的使用教程见下一篇:Obsidian + Claude Code:人机共驾工作流。

你可以直接抄的最小版

不需要一次建全。最小可用的版本是:

1
2

mkdir -p LynxOS/{00-Inbox,01-Projects,04-SOP,06-Archive,99-System}
cd LynxOS && git init

再加三个文件:README.md(目录说明)、99-System/AI-RULES.md(抄上面的八条红线)、一张项目卡模板。够了。02-Marketing 和 03-Research 等你有第一批可复用方法论和调研再加,05-Memory 等你有第一次复盘再加。

先让想法有地方落,再让方法有地方存,最后让 AI 有规矩可守。 顺序反了,就会得到一个漂亮但空转的目录树——我见过太多这样的"数字花园”。

至于我的 155 个文件?它们现在各就各位,连同 13 张项目卡、一个 dashboard、和一条从想法到 SOP 的流水线,安静地躺在一个 Git 仓库里,等着下一个想法进来。