From 2a864905e07df06bfd480cd3b759c3758d0f7a91 Mon Sep 17 00:00:00 2001
From: yoma <yingwaizhiying@gmail.com>
Date: Sun, 5 Jul 2026 20:03:26 +0800
Subject: [PATCH] Add EdgeEver origin story blog post

---
 .../src/content/blog/why-build-edgeever.md    | 149 ++++++++++++++++++
 .../src/content/blog_en/why-build-edgeever.md | 149 ++++++++++++++++++
 2 files changed, 298 insertions(+)
 create mode 100644 apps/site/src/content/blog/why-build-edgeever.md
 create mode 100644 apps/site/src/content/blog_en/why-build-edgeever.md

diff --git a/apps/site/src/content/blog/why-build-edgeever.md b/apps/site/src/content/blog/why-build-edgeever.md
new file mode 100644
index 00000000..e6c1c40b
--- /dev/null
+++ b/apps/site/src/content/blog/why-build-edgeever.md
@@ -0,0 +1,149 @@
+---
+draft: false
+title: "为什么我要做 EdgeEver"
+snippet: "从印象笔记的三栏体验、数据开放、AI Agent 与自托管成本，聊聊 EdgeEver 诞生的原因。"
+image: {
+    src: "/opengraph.jpg",
+    alt: "EdgeEver 开源自托管笔记工作区"
+}
+publishDate: "2026-07-05 20:10"
+category: "Story"
+author: "EdgeEver Team"
+tags: [story, evernote, self-hosted, mcp, open-source]
+---
+
+做 EdgeEver，不是因为世界上缺一个笔记应用。
+
+恰恰相反，笔记应用太多了。轻量的、重型的、协作优先的、Markdown 优先的、白板式的、数据库式的，每一种都有自己的拥护者。但长期使用笔记软件的人心里大概都知道：真正难替代的并不是某个功能，而是一套已经长进肌肉记忆里的工作流。
+
+对我来说，这套工作流很接近经典印象笔记：左边是笔记本树，中间是笔记列表，右边是正在写的内容。打开、搜索、归类、移动、继续编辑，所有动作都应该足够直接。它不需要每一步都显得很酷，它需要稳定、清楚、快，并且让我放心把多年积累的内容放进去。
+
+但这几年，我越来越难从现有产品里得到这种放心。
+
+---
+
+### 我想要的是一个可靠的个人知识库
+
+很多人并不是要一个越来越庞大的效率平台。我们只是想要一个可靠的个人知识库：
+
+- 能快速记录和整理日常资料
+- 能按熟悉的笔记本层级管理内容
+- 能保存图片、附件、富文本和长文
+- 能在电脑和手机上都顺手使用
+- 能在需要时把数据拿出来
+
+这些需求并不花哨，但它们很基础。基础能力一旦不稳定，笔记软件就会从工具变成负担。
+
+我曾经喜欢印象笔记的原因，也正是因为它在很长一段时间里把这些基础能力做得足够好。三栏布局、笔记本、搜索、跨设备同步，这些东西构成了一种朴素但高效的个人资料管理方式。
+
+问题是，随着产品越来越复杂，我想要的那部分体验反而被包在了越来越厚的外壳里。
+
+---
+
+### 臃肿、封闭和迁移焦虑
+
+对个人用户来说，笔记软件最可怕的事情不是少一个按钮，而是数据被困住。
+
+当一个产品变得越来越重，商业化和附加功能越来越多，性能、内存占用和日常响应速度开始让人分心时，你自然会开始想：如果有一天我想离开，我能不能体面地把自己的内容带走？
+
+这个问题并不总是有舒服的答案。
+
+笔记里通常有多年资料、图片、附件、剪藏、碎片想法和未完成的计划。它们不是一批普通文件，而是一个人的知识轨迹。迁移如果依赖不稳定的第三方插件，或者只能导出到不够开放、不够容易二次处理的格式，用户就会一直处在一种隐形的焦虑里。
+
+更进一步，AI Agent 正在成为新的工作入口。今天我们已经可以让 Codex、Claude Code、Cursor、Antigravity 这类工具帮我们写代码、整理资料、处理重复任务。那笔记系统也应该能被这些工具安全、清晰地访问。
+
+如果我的知识库不能通过 API 或 MCP 被授权读取、整理、归档、打标签，它就很难进入下一代工作流。
+
+---
+
+### 轻量替代品很好，但我仍然想要三栏体验
+
+我也看过一些更轻量、更开放的笔记产品。它们通常很干净，也更接近开发者喜欢的形态。
+
+但对我来说，还有一个缺口：经典印象笔记式的三栏体验依然很重要。
+
+三栏不是怀旧。它是一种高效的信息密度：
+
+- 左侧让我知道内容放在哪里
+- 中间让我快速扫过一组笔记
+- 右侧让我立即进入编辑状态
+
+这种布局尤其适合长期积累的资料库。它不强迫我先进入某个复杂空间，也不要求我为了管理内容先设计一套系统。它更像一个工作台：打开就能用，东西都在手边。
+
+所以 EdgeEver 一开始就不是想做一个“全新范式”的笔记软件。它想填补的是一个更具体的空白：保留熟悉、直接的三栏笔记体验，同时把底层数据、部署方式和 Agent 能力打开。
+
+---
+
+### 为什么选择 Cloudflare-native 自托管
+
+我希望 EdgeEver 是普通个人也能长期使用的自托管产品。
+
+传统自托管常常意味着服务器、数据库、对象存储、备份、运维和账单。对很多人来说，这些门槛会把“拥有自己的数据”变成一句好听但很难坚持的话。
+
+Cloudflare 的 D1、R2、Workers 和 Pages 给了一个很适合个人知识库的组合：
+
+- D1 存储结构化数据和笔记内容
+- R2 存储图片与附件
+- Workers 提供 API
+- 静态前端可以部署在边缘网络上
+
+在个人使用规模下，这套组合有机会做到接近零成本。更重要的是，它不需要用户长期维护一台服务器。你 Fork 仓库、配置资源、部署，之后同步上游更新再重新部署，就能持续使用。
+
+这就是 EdgeEver 想表达的一个价值：自托管不应该只属于愿意长期运维服务器的人。
+
+---
+
+### 开放数据是底线，不是卖点
+
+EdgeEver 的内容模型从一开始就尽量保持清楚：
+
+```text
+content_json      TipTap/ProseMirror 文档，编辑器权威格式
+content_markdown  API、Agent、导入导出使用
+content_text      搜索、摘要和索引使用
+```
+
+这样做并不是为了显得技术上复杂，而是为了避免把所有场景都塞进一种格式里。
+
+编辑器需要结构化文档，API 和迁移需要 Markdown，搜索需要纯文本。每一种形态都有自己的用途。数据越清楚，未来迁移、备份、自动化和二次开发就越轻松。
+
+我希望用户使用 EdgeEver 时，有一种非常明确的安全感：这些内容是你的。你可以通过 REST API 读取它，可以通过 MCP 交给 Agent 整理它，也可以在需要时把它迁移出去。
+
+---
+
+### MCP 让笔记重新变成可行动的知识
+
+AI Agent 友好是 EdgeEver 很重要的一部分。
+
+过去，笔记软件更多是在帮我们“保存信息”。但现在，仅仅保存已经不够了。我们还希望工具能帮我们：
+
+- 总结一批随机记录的想法
+- 给旧笔记自动补标签
+- 从长期记录里整理项目脉络
+- 根据笔记内容生成待办、文档或方案
+- 在迁移资料时自动清洗格式和层级
+
+这些事情如果只能靠复制粘贴，就很快会变得笨重。MCP 的意义在于，用户可以明确授权 AI Agent 访问自己的 EdgeEver 实例，让它在边界清楚的前提下读取和整理笔记。
+
+这也是我想做 EdgeEver 的原因之一：笔记不应该只是沉睡的资料仓库，它应该能进入自动化工作流，变成可以被调用、被组织、被重新使用的知识。
+
+---
+
+### EdgeEver 想成为什么
+
+EdgeEver 不想成为一个包办一切的超级应用。
+
+它更像一个开放、轻量、可长期拥有的个人笔记底座：
+
+- 保留经典三栏体验
+- 支持富文本、图片、嵌套笔记本和历史版本
+- 可以部署在 Cloudflare 上
+- 数据模型清晰，支持 REST API、OpenAPI 和 MCP
+- 对个人用户尽量低成本
+- 对 AI Agent 足够友好
+
+如果你怀念印象笔记早期那种直接、稳定、可依赖的工作台，又希望今天的笔记系统能够开放、自托管、能接入 AI Agent，那么 EdgeEver 就是在为这个交叉点而做。
+
+我做它，是因为我想要这样一个工具：熟悉但不封闭，轻量但不简陋，个人可拥有，又能面向未来的自动化工作流。
+
+这就是 EdgeEver 的起点。
diff --git a/apps/site/src/content/blog_en/why-build-edgeever.md b/apps/site/src/content/blog_en/why-build-edgeever.md
new file mode 100644
index 00000000..49a288f6
--- /dev/null
+++ b/apps/site/src/content/blog_en/why-build-edgeever.md
@@ -0,0 +1,149 @@
+---
+draft: false
+title: "Why I Built EdgeEver"
+snippet: "A founder-style note on classic Evernote workflows, open data, AI agents, and why EdgeEver exists."
+image: {
+    src: "/opengraph.jpg",
+    alt: "EdgeEver open-source self-hosted notes workspace"
+}
+publishDate: "2026-07-05 20:10"
+category: "Story"
+author: "EdgeEver Team"
+tags: [story, evernote, self-hosted, mcp, open-source]
+---
+
+I did not build EdgeEver because the world needs yet another notes app.
+
+There are already plenty of them: lightweight notes, heavy knowledge bases, Markdown-first tools, collaborative workspaces, whiteboards, databases, and everything in between. But anyone who has used a notes app for years knows that the hard thing to replace is not a single feature. It is the workflow that has already become muscle memory.
+
+For me, that workflow is close to classic Evernote: a notebook tree on the left, a note list in the middle, and the editor on the right. Open, search, organize, move, keep writing. Every action should feel direct. It does not need to look clever at every step. It needs to be stable, clear, fast, and trustworthy enough for years of personal knowledge.
+
+Over time, I found it harder to get that feeling from existing products.
+
+---
+
+### I Wanted A Reliable Personal Knowledge Base
+
+Many people are not asking for an ever-expanding productivity platform. We simply want a reliable personal knowledge base:
+
+- Fast capture and organization
+- Familiar notebook hierarchy
+- Rich text, images, attachments, and long-form notes
+- A good experience on both desktop and mobile
+- A clear way to get our data back when needed
+
+These needs are not flashy, but they are fundamental. When the fundamentals stop feeling reliable, a notes app stops being a tool and starts becoming overhead.
+
+The reason I liked Evernote in the first place was that it handled these basics well for a long time. The three-pane layout, notebooks, search, and sync created a simple but efficient way to manage personal information.
+
+But as products grow more complex, the part I actually want can end up buried under more and more layers.
+
+---
+
+### Bloat, Lock-In, And Migration Anxiety
+
+For an individual user, the scariest thing about a notes app is not the lack of a button. It is trapped data.
+
+When a product becomes heavier, adds more commercial layers, and starts making performance, memory use, or everyday responsiveness feel distracting, you naturally begin to ask: if I ever want to leave, can I take my content with me cleanly?
+
+That question does not always have a comfortable answer.
+
+Notes often contain years of material: images, attachments, web clips, fragments of thought, and unfinished plans. They are not just files. They are a personal knowledge trail. If migration depends on fragile third-party plugins, or exports into formats that are not open or easy to process, users live with a quiet kind of anxiety.
+
+AI agents are also becoming a new entry point for work. Tools like Codex, Claude Code, Cursor, and Antigravity can already help us write code, organize material, and handle repetitive tasks. A notes system should be able to participate in that workflow safely and clearly.
+
+If my knowledge base cannot be accessed through an API or MCP with explicit authorization, it has a hard time joining the next generation of workflows.
+
+---
+
+### Lightweight Alternatives Are Good, But I Still Want Three Panes
+
+I have also looked at lighter, more open note-taking products. Many of them are clean and developer-friendly.
+
+But for me, one gap remains: the classic Evernote-style three-pane experience still matters.
+
+Three panes are not nostalgia. They are efficient information density:
+
+- The left side shows where things live
+- The middle lets me scan a group of notes quickly
+- The right side puts me directly into editing
+
+This layout works especially well for long-lived personal archives. It does not force me into a complex space first, and it does not ask me to design a whole system before managing content. It feels like a workbench: open it, and everything is within reach.
+
+So EdgeEver is not trying to invent a brand-new paradigm. It is trying to fill a more specific gap: keep the familiar, direct three-pane notes experience while opening up the data model, deployment model, and agent interface.
+
+---
+
+### Why Cloudflare-Native Self-Hosting
+
+I want EdgeEver to be a self-hosted product that ordinary individuals can actually keep using.
+
+Traditional self-hosting often means servers, databases, object storage, backups, maintenance, and bills. For many people, that turns "own your data" into something that sounds good but is difficult to sustain.
+
+Cloudflare D1, R2, Workers, and Pages offer a very practical combination for a personal knowledge base:
+
+- D1 stores structured data and note content
+- R2 stores images and attachments
+- Workers provide the API
+- The static frontend can run on the edge
+
+At personal scale, this stack can be close to zero cost. More importantly, users do not need to maintain a server. Fork the repository, configure resources, deploy, then sync upstream updates and redeploy when needed.
+
+That is one of the values EdgeEver is trying to express: self-hosting should not only belong to people who want to operate servers long term.
+
+---
+
+### Open Data Is The Baseline
+
+EdgeEver keeps its content model explicit:
+
+```text
+content_json      TipTap/ProseMirror document, the editor source of truth
+content_markdown  API, agent, import, and export format
+content_text      Search, excerpts, and indexing
+```
+
+This is not about making the system look technically fancy. It is about not forcing every use case into one format.
+
+The editor needs a structured document. APIs and migration workflows need Markdown. Search needs plain text. Each representation has a job. The clearer the data model is, the easier backup, migration, automation, and extension become.
+
+I want EdgeEver users to have a simple sense of safety: this content is yours. You can read it through the REST API, let an agent organize it through MCP, or move it elsewhere when needed.
+
+---
+
+### MCP Makes Notes Actionable Again
+
+Being AI-agent-friendly is a core part of EdgeEver.
+
+In the past, notes apps mainly helped us save information. But saving is no longer enough. We also want tools to help us:
+
+- Summarize scattered ideas
+- Add tags to older notes
+- Reconstruct project context from long-term notes
+- Generate todos, docs, or plans from existing material
+- Clean up hierarchy and formatting during migration
+
+If all of this depends on copy and paste, it gets clumsy fast. MCP matters because users can explicitly authorize an AI agent to access their EdgeEver instance, so it can read and organize notes within clear boundaries.
+
+That is another reason I wanted to build EdgeEver: notes should not be a sleeping archive. They should be callable, organizable, and reusable knowledge.
+
+---
+
+### What EdgeEver Wants To Be
+
+EdgeEver is not trying to become an all-in-one super app.
+
+It is meant to be an open, lightweight, long-lived personal notes foundation:
+
+- Classic three-pane workflow
+- Rich text, images, nested notebooks, and revision history
+- Cloudflare-native deployment
+- Clear data model with REST API, OpenAPI, and MCP
+- Low cost for individual users
+- Friendly to AI agents
+
+If you miss the direct, dependable workbench feeling of earlier Evernote, but want a modern notes system that is open, self-hosted, and ready for AI agents, EdgeEver is built for that intersection.
+
+I built it because I wanted a tool that feels familiar without being closed, lightweight without being shallow, personally owned while still ready for future automation workflows.
+
+That is where EdgeEver begins.