Project

MOSS 项目优化建议

基于对 docs/ 下 15 篇设计文档的通读，以下是落地层面的具体建议。日期：2026-07-21

一、节奏与策略

Phase 0 的全局地图（对象模型、域划分、8 层管线、分阶段路线图）已经画完，目的达到了。接下来最有价值的事不是继续完善 Phase 1 设计文档，而是拿真实数据跑一遍最粗糙的链路，让代码反过来修正设计。

具体做法：跳过"先写完整技术设计文档"，直接用 50 个真实文件手动跑 scan → parse → store → search 的链路，用代码验证假设，再回头补文档。文档跟着代码迭代，而不是代码等着文档画完。

不是两周写完 Phase 1 全部设计，而是两周后有一个东西你每天真的会打开用。哪怕它只有命令行、只能搜本地 Markdown 文件夹、结果丑得要命。"每天用"是检验设计是否成立的唯一标准，比任何 review checklist 都管用。

02-candidate-domains.md 里列了睡眠恢复质量、身份叙事与人生主题、精神实践等数十个候选域。这些是"也许有一天"的东西，但写进架构文档后会产生隐性约束--不自觉地为它们预留字段、考虑兼容性。建议把它变成纯粹的"灵感停车场"，不让它影响 Phase 1-3 的任何决策。

SQLite FTS5 默认按空格/标点切词，对中文基本无效。三个选项：

建议第一天就定下来，别等数据灌进去了再换。

Phase 1 本质上就是：扫文件 → 解析 → 存 SQLite → FTS5 索引 → 查询。不需要"原始归档层"和"标准化对象层"的严格分离，不需要"理解层"和"索引层"的边界。这些抽象在数据量到几千条、信息流到三四种之后才有意义。过早分层会让第一个可用版本推迟几个月。

先把"扫 → 存 → 搜"跑通，确认搜索本身有用了，再加摘要和打标。否则会同时调试"搜索不准"和"AI 标签不对"两个问题，分不清是哪个环节的锅。而且很可能跑起来之后发现，标题 + 全文搜索 + 手动加几个 tag 就已经解决 80% 的问题，AI 摘要的优先级会自然下降。

技术上扫一个文件夹里的 Markdown 最简单，但如果日常真正的"我明明存过这个东西但找不到"的痛来自浏览器书签或 Notion 里某个角落，那就先啃那个。MVP 的价值不是"能跑"，是"解决了我一个真实的烦躁"。

如果每加一条内容都要选"这属于哪个 Topic、哪个 Project、什么敏感度"，不会坚持用。最好的设计是：扔进去就行，分类全部后置（AI 自动打或者周末批量整理）。文档里"Feedback 是独立事件流"的设计暗含了这个思路--内容先进来，交互信号后面再补。把这个原则贯彻到入库环节。

文档反复讲数据怎么进来、怎么存、怎么理解，但没有回答：打开这个东西，第一眼看到什么？最常用的 3 秒操作是什么？是命令行 moss search "xxx"？是一个本地 web 页面？是 Raycast/Alfred 插件？交互形态会反过来约束技术选型，越早定越好。

MVP 定义是产品边界（做什么、不做什么），但没有拿真实数据试过。Notion 导出长什么样？书签 HTML 里有多少乱码？PDF 提取出来的文本质量如何？这些不跑一遍，SQLite schema 设计出来大概率要推翻。

一旦开始往里灌真实数据，没有备份就会焦虑。好消息是 SQLite 的备份极其简单：

sqlite3 moss.db ".backup ~/backups/moss-$(date +%Y%m%d).db"

加个 cron 或 launchd 每天跑一次，同步到 NAS 或 iCloud Drive 就够了。这不需要"设计"，十分钟能搞定，建议作为 Phase 1 的 Day 0 基础设施。

这个项目的愿景是对的，原则是好的（local-first、LLM 做感知代码做决策、原始与派生分离、反馈独立事件流）。现在需要的不是继续完善蓝图，而是用最小成本验证"这东西真的比 Spotlight + Notion 搜索好用"。

核心行动：两周内，一个 200 行的脚本，能扫指定文件夹、把内容塞进 SQLite FTS5、支持中文关键词搜索、返回结果。跑起来之后自然知道 schema 该怎么改、AI 摘要该插在哪个环节、对象模型哪些字段是多余的。