我给自己的 AI 系统打了 6 分：一个人造「个人 AI 操作系统」的冷静复盘

我花三个月搭了一套 87 个 MCP 工具 + 249 个知识文件的 AI 协作系统。然后我想再造一个操作系统来管理它。然后我让 AI 给这个想法打分。它打了 6 分。

先交代背景：我已经有什么了

我是一个 00 后程序员，白天在腾讯写代码，晚上在做自己的 AI 产品和内容。过去三个月，我搭了一套个人 AI 协作基础设施，叫 ThirdSpace。

简单说，它是这样的：

一个 Obsidian 知识库（我叫它 Vault），里面有 249 个 Markdown 文件，15 个主题分类，统一的元数据规范。所有我的笔记、文章、反思、工作日志、产品文档都在这里。
87 个 MCP 工具，用 Python 写的，通过 MCP 协议让 Claude Code 直接调用。涵盖知识管理、深度反思、内容创作、视频分析、飞书推送、角色切换等等。
20 个 Skill 模块，每个 Skill 是一组 Prompt + 脚本 + 参考资料的集合，定义了一种特定的工作方式。
5 个 AI 角色（营销、产品、技术、商业、运营），切换角色后 AI 会加载不同的知识背景和工具集。
4 个 macOS 定时任务，每天早上推战略简报、晚上推反思提醒。
Git 钩子，每次提交代码自动写入工作日志。

这套系统跑了三个月，确实提升了我的效率。用它写文章、做反思、管理产品 roadmap、追踪创作数据，体感是”一个人干了小半个团队的活”。

但最近我开始觉得不够了。

我想造什么：MoonOS

我给新系统取名叫 MoonOS。一句话定位：管理我所有 AI 基础设施的操作系统。

具体来说，我希望它能做到：

统一管理所有上下文——AI 的指令文件、场景上下文、用户画像，在一个地方 CRUD
统一管理所有 Skill——注册表，让 AI 能自己查到”我有什么能力可以用”
工作流可执行化——现在的工作流是 Markdown 文档，AI 读了能理解但不能自动跑。我想把它变成 Pipeline（JSON/YAML），AI 能一键执行
可视化 Dashboard——看到系统全貌，知道哪些管线在跑、哪些 Skill 用得多
最关键的：AI 能基于 MoonOS 自主工作——它能读取 Pipeline 定义，按步骤调用工具，遇到分支自己做判断

架构层次是这样的：

你（人类）
  ↓ 通过 MoonOS Dashboard 管理
MoonOS（大脑中枢）
  ↓ Registry + Pipeline Engine + Scheduler
AI（Claude Code / 其他）
  ↓ 读 Registry → 选 Skill → 跑 Pipeline
ThirdSpace MCP（手脚）
  ↓ 87 个纯 IO 工具
Vault（灵魂）
  ↓ 249+ 知识文件

Vault 是灵魂，ThirdSpace 是手脚，MoonOS 是前额叶皮层。

听起来很美对吧？

我为什么想这样做

表面原因：东西太多了管不过来

87 个工具、20 个 Skill、5+ 个配置文件、4 个定时任务、3 个 CLAUDE.md 文件。散落在文件系统各处。哪天我换台电脑，光配置环境就得半天。

但说实话，这个理由站不住。Obsidian 插件 + 一个 Raycast 脚本就能解决 80% 的管理需求。

真实原因：AI 不知道自己有什么能力

这才是核心痛点。

每次我想让 AI 执行一个工作流——比如”帮我发一篇小红书内容”——我得口头告诉它：“先调 draft_content 写草稿，再调 diagnose_hook 诊断开头质量，分数够了调 md2img_export 生成配图，最后调 publish_reminder 设提醒。”

流程在我脑子里，不在系统里。

AI 不知道 skills/harness-architect/ 这个目录的存在。它不知道有一个叫”营销发布流”的工作流。它甚至不知道自己能干什么——除非我告诉它。

这意味着什么？意味着我虽然有 87 个工具，但 AI 的有效能力取决于我这个 session 里记得让它用哪些工具。我的记忆力，成了系统的瓶颈。

更深层的原因：想从”人驱动 AI”变成”AI 驱动系统”

旧范式：我下指令 → AI 执行 → 我检查结果。新范式：我定义管线 → AI 自主调度 → 我只看结果和异常。

这不是效率优化，是控制权的重新分配。我想把”怎么做”从大脑卸载到系统，AI 变成系统的操作员，而不是我的打字员。

好处：如果做成了

1. 编排知识不再丢失

现在每次 session 结束，AI 关于”怎么做这件事”的知识就消失了。下次 session 得重新教。

Pipeline as Data 把工作流固化为可执行结构。AI 换了也能用，session 换了也能用，我不在也能跑。

2. AI 能自己选工具

Skill Registry 让 AI 从”被告知用什么”变成”自己查到能用什么”。这是从”人类选择工具”到”AI 选择工具”的拐点。

3. 系统自进化

有了 Registry + Pipeline，一个递归出现了：AI 发现我重复执行某个 3 步操作 → 自动注册为新 Pipeline → 下次直接调用。系统的能力随使用自动增长。

4. 知识飞轮加速

Vault 数据增长 → AI 有更多上下文 → Pipeline 执行质量提升
→ 更多产出存入 Vault → 数据继续增长

这个飞轮现在存在，但靠我手动驱动。MoonOS 把驱动力从我的注意力迁移到系统的自动编排上。

坏处：我必须直面的

1. 复杂度会爆炸

ThirdSpace 已经是 4,648 行 Python。MoonOS 保守估计再加 5,000-8,000 行——还有一个 Web 前端。

我是一个人。 没有团队、没有 QA、没有 DevOps。每多一层抽象，维护成本是指数增长。

2. 为 3 条工作流造了一个引擎

反问自己：现在有多少条工作流需要被自动编排？

翻了一下，真正成型的 workflow 只有 3 条——营销发布、产品规格、周复盘。为 3 条工作流建一个 Pipeline Engine，投入产出比极低。

更残酷的对比：在 CLAUDE.md 里写清楚流程步骤，让 AI 按步骤执行，效果已经达到 Pipeline Engine 的 80%。剩下 20% 的自动化，值得我花两个月开发吗？

3. 建设基础设施不是产出

我的灵犀（Obsidian AI Chat 插件）在 MVP 阶段，短视频内容刚起步。这些是面向用户的产品，能带来收入和影响力。

MoonOS 是面向我自己的基础设施，它最好的结果是”让我以后做事更快”——但前提是我先花两个月做它。这两个月我本可以让灵犀产生 10 个付费用户、拍 10 条视频、写 8 篇文章。

你选择了”让以后更高效”，放弃了”现在就产出”。

4. AI 还没聪明到那个程度

Pipeline Engine 的前提假设是”AI 足够聪明，能自主编排复杂工作流”。

现实是：

AI 在多步骤任务中容易丢失上下文
自动化后 prompt 退化的风险很高
Pipeline 中一步失败，后续步骤的容错处理比想象中复杂 3 倍

我可能在为 2027 年的 AI 能力建 2026 年的基础设施。太早了。

5. 锁定效应加倍

MoonOS 建成后，我的所有工作流绑定在 ThirdSpace + MoonOS 两套系统上。MCP 协议变了、Claude Code 架构变了、Obsidian 迁了——我得改两套。风险翻倍。

苛刻的自我评分

我让 AI 以完全旁观的架构评审者视角，从五个维度给 MoonOS 打分：

维度	评分	核心判断
问题定义	7/10	痛点真实，但 4 个需求打包在一起，缺乏优先级拆分
架构设计	6/10	分层合理，但 Registry 维护成本被低估、Pipeline Engine 过重、Dashboard 太早
可行性	5/10	一个人 + 业余时间 + 同时维护多个产品，数学上不成立
差异化	8/10	市面上没有完全一样的东西，已有生产可用的 vault + 工具集做基础
投入产出比	4/10	80 分系统推到 95 分的工程量 ≥ 从 0 到 80，而且那 15 分在当前 AI 水平下存疑

综合：6/10。

不是坏想法，但在当前阶段是一个时机不对的想法。

这个评分让我冷静了很多。

竞品扫描：别人在怎么做这件事

既然”个人 AI 操作系统”是个方向，那看看别人走到哪了。

PAI（Personal AI Infrastructure）

Daniel Miessler 的 PAI 是目前最接近 MoonOS 愿景的开源项目。

核心设计：

TELOS 目标系统：用 10 个 Markdown 文件定义你的人生方向——MISSION.md, GOALS.md, BELIEFS.md, CHALLENGES.md……让 AI 深度理解你是谁、你要什么
三层记忆：CAPTURE（实时记录）→ SYNTHESIS（知识沉淀）→ APPLICATION（历史档案）
Packs/Bundles：能力以 Pack 为单位组装，类似我的 Skill 概念
通用算法框架：所有任务遵循”观察→思考→规划→构建→执行→验证→学习”
16 条设计原则：其中”Code before prompts”（能写脚本解决的别用 AI）、“CLI-first”（先做命令行再考虑图形界面）、“Scaffolding over model selection”（架构比选哪个模型重要）——这几条我深以为然

PAI 做对了什么：

CLI-first——没急着做 Dashboard，先把核心跑通
用户/系统分离——升级不破坏你的数据
社区驱动——Packs 可以被别人贡献，不是一个人死扛
通用算法框架——所有任务用同一个认知模型，AI 理解成本低

PAI 的问题：

过于通用，缺乏领域深度——它不知道”写小红书”和”做产品规格”需要完全不同的工具链
TELOS 系统太重——10 个文件定义人生方向，99% 的人填不完第 3 个
没有跟任何具体知识管理工具深度集成——它有自己的文件结构，但跟 Obsidian、Notion 是割裂的

OpenClaw

OpenClaw 走的是另一个方向——“具有主动执行能力的个人 AI 操作系统”。

核心设计：

四级缓存体系：从 HBM 到远端存储，动态迁移不活跃上下文
系统级执行：不只是对话，而是直接操作文件系统、执行 Shell 命令
多渠道接入：WhatsApp、Telegram、飞书统一入口
多智能体隔离：不同任务独立上下文，互不污染

OpenClaw 做对了什么：

认识到上下文管理是 AI 的核心瓶颈——四级缓存很有工程品味
多渠道接入——不绑定单一客户端
会话隔离——这个看似简单的功能，在实际使用中价值巨大

OpenClaw 的问题：

偏底层——更像是 AI 的运行时环境，不是面向具体场景的解决方案
知识管理几乎没有——跟我的 Vault 体系比，差了整个数据层

三者的定位差异

                    领域深度
                      ↑
                      │
            MoonOS ●  │
           （规划中）   │
                      │      ● PAI
                      │     （已开源）
          ● OpenClaw  │
          （已开源）    │
                      │
  ──────────────────────────────── → 通用性

OpenClaw：通用 + 浅 → AI 运行时环境
PAI：通用 + 中等深度 → 个人 AI 基础设施框架
MoonOS：专用 + 深 → 内容创作者的 AI 操作系统

但说实话，我最大的竞争对手不是它们，而是”不做 MoonOS、继续用 ThirdSpace + CLAUDE.md 手动编排”这个选项。 因为我的系统在这个领域已经比大多数人的强 10 倍了。

几个值得在这里展开的思考

思考一：个人 AI OS 这个赛道到底成不成立？

先说结论：成立，但窗口期可能只有 1-2 年。

为什么成立——因为 AI 的核心瓶颈正在从”模型能力”转向”上下文和编排”。GPT-4 和 Claude 的智能已经够用了，但它们不知道你是谁、你在做什么、你有什么工具。谁能把这些信息结构化地喂给 AI，谁就能把 AI 从”通用聊天机器人”变成”你的私人参谋”。

为什么窗口期只有 1-2 年——因为 AI 公司自己在做这件事。ChatGPT 的 Memory、Claude 的 Project Knowledge、Gemini 的个人化——它们都在试图让 AI “记住你”。当平台级的个人化做到 80 分，个人搭建的 OS 就只剩下 20% 的差异化空间。

所以现在做个人 AI OS 的逻辑是：在平台还没做好之前，自己先跑出一套方法论，把个人上下文结构化的经验积累到不可替代的程度。

思考二：“工具做脏活，AI 做智能”在 OS 层还成立吗？

我之前写过一篇文章，核心观点是”MCP 工具只做 IO，所有需要理解的事交给 AI”。这个原则在工具层完全成立。

但 MoonOS 是更上面一层——它不是工具，它是工具的管理者。在这一层，同样的原则能套用吗？

答案是：部分成立，但边界变了。

在 MoonOS 层面：

Registry 扫描、文件同步、配置管理 → 确定性操作 → MoonOS 代码干
选择哪个 Skill、决定 Pipeline 执行路径、判断步骤间的分支条件 → 需要理解 → AI 干
Pipeline 定义本身 → 灰色地带 → 应该是人定义、AI 可以建议优化

所以 MoonOS 的核心架构原则应该是：MoonOS 做注册和调度，AI 做决策和生成，人做定义和审批。 三者的边界要比工具层更清晰地画出来，因为 OS 层的错误代价比工具层高得多——一个工具搞错了重来就行，Pipeline 调度搞错了可能连锁反应。

思考三：一个人做 OS 和一个团队做 OS 的根本区别

不是人力问题，是反馈循环的速度问题。

一个人做 OS：

写代码 → 自己测 → 自己发现问题 → 自己改
反馈循环 = 1 个人的认知盲区

一个团队做 OS：

写代码 → 别人测 → 别人发现你看不到的问题 → 讨论后改
反馈循环 = 多人的认知互补

PAI 走了社区路线（Packs 可以被别人贡献），所以它能进化。我如果走纯自用路线，系统会越来越适配我自己，但也越来越只适配我自己。

这带来一个选择：MoonOS 到底是做成”我的私人系统”还是”一个可复用的框架”？

前者简单但天花板低，后者复杂但有产品化可能。我目前的判断是先做前者，等跑通了再决定要不要产品化。 过早考虑通用性会让架构变重。

思考四：最诚实的问题——这是不是在逃避？

造基础设施是有快感的。你在搭系统的时候感觉自己在”建设”，有进步感、有掌控感、有技术挑战的乐趣。

但面向用户的产品不一样。灵犀需要做用户访谈、处理 edge case、写文档、做市场推广——这些事没有搭系统爽，但这些才是产出。

“我在优化基础设施”有时候是”我不想面对市场的不确定性”的体面说法。

我不确定自己有没有这个问题。但我觉得值得写出来，算是对自己的一个提醒。

最后，我决定怎么做

不做完整的 MoonOS。做一个 MoonOS Lite：

完整 MoonOS	MoonOS Lite
Web Dashboard	❌ 不做
Pipeline Engine	❌ 不做
Skill Registry (JSON)	✅ 自动扫描 skills/ 生成
MoonOS MCP 工具	✅ 3-5 个核心工具
结构化 YAML Workflow	✅ 把 3 条 workflow 写成 YAML
Context 自动同步	✅ 增强现有脚本
配置统一管理	❌ 不做

核心思路变了：不造 Pipeline Engine，让 AI 自己当 executor。

# workflows/marketing-publish.yaml
name: 营销内容发布
trigger: manual
steps:
  - tool: draft_content
    params: { platform: "$platform", style: "$style" }
    output: draft
  - tool: diagnose_hook
    params: { content: "$draft.content" }
    output: diagnosis
  - tool: md2img_export
    params: { content: "$draft.content", export_format: "xhs" }
    condition: "$diagnosis.score >= 7"
  - tool: save_draft_content
  - tool: publish_reminder
    params: { platform: "$platform" }

AI 读 YAML → 理解步骤 → 逐步调用工具。不需要 executor——AI 本身就是 executor。

在 CLAUDE.md 里加一句：“当我说’执行 XX 工作流’时，读取 workflows/ 目录下对应的 YAML 文件，按步骤执行。”

先用一周验证。如果这个零代码方案解决了 70% 的问题，完整 MoonOS 就不值得做。如果暴露了明确的不足，我就知道该写什么代码。

工作量：3-5 天，不是 2 个月。

写在最后

这篇文章的写作过程本身就很有意思——我用 AI 分析了我想给 AI 造的操作系统，然后 AI 告诉我这个操作系统的投入产出比是 4/10。

如果我无视这个判断、强行开搞，那我拥有 AI 的意义是什么？

但如果我完全听从这个判断、放弃这个方向，那我跟一个执行器有什么区别？

真正的答案在中间：听进去批评，拿走有用的部分（先做 Lite 版验证），保留自己的判断（这个方向长期是对的）。

不要为了优化基础设施而忘了基础设施是为产出服务的。Vault 是我的灵魂没错，但灵魂需要作品来证明自己。

三个月后回来看这篇文章。如果那时候 MoonOS 在跑了，说明穷人版验证通过了，需求是真的。如果那时候灵犀有了 50 个付费用户而 MoonOS 还没动——那说明我终于学会了先做产品再做系统。

哪个结果都不错。

我是 MoonlitClear，00 后程序员，正在从技术人向 AI + 内容创作者转型。 这是我「一个人的 AI 基础设施」系列的第四篇。 前三篇：工具做脏活 AI 做智能｜一个人的 AI 协作基础设施该怎么建｜一篇文章的旅程