每次给朋友介绍 Petrichor，我都要先回答同一个问题：
“你这不就是个 Notion / Logseq / Obsidian / Halo / Typecho / WordPress 吗？”
是，又不是。一个工具的存在意义，从来不在于”功能差不多就够了”，而在于它把哪几件事真正缝合成了一个连贯的工作流。Petrichor 就是为这种”缝合”而生的。
一个长期没被解决的痛点
我有一个习惯：白天在 Notion 里写零散的笔记和草稿，到了某一天想把其中一段整理成博客发出去，就要：
- 在 Notion 里整理出”成稿”
- 复制到博客系统（Hexo / Halo / WordPress……）
- 因为格式不兼容（块引用 / Callout / 表格 / 代码块 / 数学公式），又手动修一遍 Markdown
- 发布
- 一个月之后想回头看自己写过什么，发现 Notion 和博客是两个独立的世界——博客上的文章被沉淀在数据库里，Notion 里的原始草稿散落在一堆 Page 中，再也对不上号
这不是某个工具的问题，这是”写作工具”和”发布工具”被人为分裂的结果。它们应该是同一件事的两个面。
我想要的是这样一个东西：
- 一个结构化的知识库（多级目录、标签、搜索），能存放从草稿到沉淀的所有内容
- 一个强到不输 Notion 的富文本编辑器，写起来不卡手
- 一个开关：勾上，它就是公开博客的一篇文章；不勾，它就是我私人的笔记
- AI 写作助手像 Cursor 之于代码那样自然地嵌在我写每一段文字的过程中
- 部署成本要够低，Vercel + Supabase 免费额度跑得动，不需要自己运维服务器
市面上没有一个工具能把这五件事干净地合在一起。所以我做了 Petrichor。
Petrichor 是什么
Petrichor，词源是”雨后泥土的香气”——一种留在记忆里的细微感受。我希望这个项目对它的用户来说，是同样的东西：让你写下的东西能沉淀下来，而不是消散在产品的更新换代里。
它是一个 个人 / 小团队级别的全栈知识库与博客平台，技术栈是 Next.js 16 + TypeScript + Supabase PostgreSQL + S3 兼容对象存储，目标部署环境是 Vercel——一键部署，零自建服务器。
它在做的事情可以拆成 3 层：
| 层 | 提供什么 |
|---|---|
| 写作层 | 基于 PlateJS 的富文本编辑器，支持 Markdown、代码块、数学公式、白板、思维导图、表格、媒体嵌入等几十种节点 |
| 沉淀层 | 多层级知识库目录树、文章标签、文章分享、AI 总结、LLM Wiki 智能问答 |
| 发布层 | 一键把私有文章设为公开，自动生成 SEO 元数据、RSS、Atom、sitemap，配套一个简洁的公开博客首页主题 |
我做的几个关键决定
决定 1：私有空间和公开空间共用同一份数据
很多博客系统的”草稿”和”已发布”是两个状态、两套表，导致编辑公开文章时会出现奇怪的同步问题。Petrichor 里没有”草稿”和”文章”的区别，所有内容统一是知识库节点，只是多了一个 is_public 开关。
这看似只是字段设计上的区别，实际带来的体验差异是巨大的：
- 你可以随时把一篇笔记开放成公开文章——不用复制，不用导出
- 也可以随时把一篇公开文章收回成私有——不用归档，不用迁移
- AI 总结、LLM Wiki 编译在索引时可以一视同仁，不会因为”草稿 / 文章”的状态拆分而需要做并集查询
决定 2：AI 写作助手必须在选区里工作
我不喜欢 ChatGPT 网页那种”开个独立聊天窗去问”的工作流——上下文断开了，要把段落复制过去再复制回来。
Petrichor 的 AI 写作有 6 种动作，全部直接作用于编辑器的当前选区：
- 续写 — 不需要选中任何文字，光标位置自然延续
- 改写 — 重写选中段落，保持语义但改变表达
- 扩展 — 把选中要点扩成完整段落
- 精简 — 长段落压缩成核心要点
- 翻译 — 中 / 英 / 日 / 韩 / 法 / 西 6 种语言
- 语气调整 — 专业 / 轻松 / 友好 / 简洁 / 学术 5 档
所有结果都是流式插入，写到一半你可以中断。写作是连续的，AI 也应该是连续的。
决定 3：API Key 由用户自己掏，平台不代付
很多 AI 产品的代付模式注定走向”涨价 → 降智 → 用户流失”的循环。Petrichor 选了一条更轴的路：
- 你自己注册 OpenAI / Gemini / DeepSeek / SiliconFlow / 任意 OpenAI 兼容服务的账号
- 把 API Key 填到后台
- Petrichor 用 AES-256-CBC + PBKDF2 加密后存入数据库（密钥由
PETRICHOR_ENCRYPT_KEY/PETRICHOR_ENCRYPT_SALT控制，连数据库管理员也读不出明文） - 你想换模型？随时切；想用某个新出的国产模型？只要它是 OpenAI 兼容协议，0 行代码 0 重启就能接入
这个设计的好处是：Petrichor 这个项目本身不依赖任何 AI 厂商的商业关系。用户的钱用户自己掏，平台不会随着某个厂商变天而集体失能。
决定 4：能用 SaaS 就不要自建
Petrichor 的依赖路径是这样的：
- 数据库 → Supabase（免费 500MB）
- CDN / 部署 / 边缘函数 → Vercel（个人版免费）
- 对象存储 → Bitiful / Cloudflare R2 / AWS S3（免费额度都够个人用）
- AI 调用 → 用户自带 Key
也就是说，一个个人用户从 0 上线 Petrichor 的真实成本是：$0/月。
如果你愿意付钱，也只是为了上量——Supabase 升级到 Pro 大概 $25/月，对应几十万行数据；其他都按用量计费。
Petrichor 适合谁
它不是一个 banger 产品，它只是一个把”写 → 沉淀 → 发布”做得连贯的小工具。它适合：
- 个人开发者 / 独立博主 — 你想自建一个有现代化编辑体验的博客，但不想被 Hexo / Halo 那种”先写 Markdown 再 git push”的工作流绑架
- 小团队 / 工作室 — 你们需要一个内部知识库 + 对外公开博客的双面平台，又不想 onboard Notion 那种重武器
- 重度 AI 写作用户 — 你已经买了一堆模型的 API，想要一个能把 AI 真正插进写作过程里的工具
- 稍微会折腾一点的人 — 一键部署虽然简单，但仍然需要你在 Vercel / Supabase 上点几下、把环境变量填对
它不适合：
- 完全不想自己管数据库的人——这种应该直接用 Notion / 飞书文档
- 需要多人实时协作编辑的团队——Petrichor 目前只支持单人编辑（评论 / suggestion 已经接入但还没暴露完整 UI）
- 想要复杂的工作流引擎（看板 / 状态机 / 自动化触发器）——这超出了项目的初衷
一句话总结
Petrichor 是一个让”写作”和”发布”重新成为一件事的工具。
如果你也觉得”在 Notion 里写完一段还要复制到博客重新排版”是一件极其荒唐的事，那这个项目大概值得你花十分钟试一下。
第一个版本会有缺陷、有别扭、有 bug，欢迎在 GitHub 上提 Issue 或 PR。这个东西本来就是为了我自己写得开心而做的——如果它能让你也写得开心一点，那就足够了。