我第一次认真考虑自己做博客，不是因为有了宏大的产品愿景，而是因为一个用了多年的教育邮箱失效了。
那天，我在公司电脑上打开 Notion，页面提示账号权益异常。我不知道家里的登录状态还能维持多久，只能赶回去，把笔记一批批导出。
笔记没有丢，但这次仓促的迁移暴露了一个问题：文字是我写的，钥匙却不完全在我手里。
我熟悉 Notion，也用过 NotionNext。它们足够好，“自己再做一套”听起来近乎自找麻烦。但日积月累的摩擦同样真实：页面偶尔跳回顶部；块结构擅长整理，却会切断连续写作；公开页能读，却不是我愿意久读的样子。
于是，我开始做 Cursor Blinking Blog。
问题起初很小：如果一个博客只服务好一个用户——我自己——它应该是什么样子？后来，我陆续补上 Notion、Markdown 和 EPUB 导入。那批匆忙导出的笔记，终于有了搬回来的路。
我没有访谈提纲，也没有用户画像。我只记录长期使用暴露的摩擦。我既写，也读；刚在后台改完一句话，几分钟后又回到前台，试着像第一次看到它那样读一遍。
*图 1：现在的首页没有推荐瀑布流，打开后首先看到的仍然是文章。*
一个无法被演示说服的用户
样本只有一个，无法支撑统计。但这个用户无法被演示说服。
按钮每天多点一次，几天后我就会厌烦；设置藏得太深，下次阅读时仍要亲手把它翻出来。长期使用会拆穿那些“看起来不错”的设计。
使用时，我不断切换身份。
作为读者，我想迅速找到文章。正文要安静，久读不能累；字体和布局要在需要时触手可及，在阅读时退到视线之外。
作为作者，我想尽快进入正文，不想每次先填一排元数据。我必须看见保存状态，也要在发布前检查文章最终如何呈现。
两种身份经常争夺界面。读者希望系统隐身，作者要求系统说清保存、版本和发布状态。设计的任务是让它们共享一条路径，却不互相打扰。
这个循环也成了我的设计方法：使用暴露摩擦，摩擦触发修改，修改再回到真实使用中接受检验。
首页的任务，是把我送进正文
早期，我也把首页想成一个标准的“产品首页”：封面图、精选内容、分类入口、推荐区，再加一段能力介绍。仿佛少一个模块，就不像认真做过产品。
真实动作却简单得多：打开网址，扫过标题，进入想读的文章。那些证明网站“内容丰富”的模块，只会延长这条路径。
于是，我把首页收成一份紧凑的文章索引。标题主导浏览；日期、摘要和少量分类标签辅助判断；留白分组，细线建立秩序。整行都能点击，键盘也能完成同样的动作。
首页不必留住我。它应该尽快把我送进正文。
移动端沿用同一条路径。我没有把桌面卡片挤成一叠迷你卡片，也没有新增底部导航。屏幕变窄后，日期先让位，标题、摘要和触控空间留下来。
*图 2：屏幕变窄了，找文章这件事没有变。*
以前，我用模块数量判断首页是否“完整”。现在，我只问：能否不经解释就进入一篇文章？
Dieter Rams 的 “Less, but better” 恰好概括了这个取舍：“少”不是做空首页，而是不让无关内容堵在文章门口。
设置越多，界面越要安静
最初，我只想让正文宽一点、字体耐看一点、手机上别太挤。可一旦认真对待阅读偏好，设置就会不断增加：白天和夜晚需要不同对比度，长文需要合适的布局和导航，代码与 Mermaid 图也需要各自的控制。
这些需求都真实存在。问题在于，如果同时摊开它们，阅读页就会变成一台调试中的仪器。
我没有删除需求，只重新安排它们出现的时机。
文章首屏只突出标题、基础信息和正文。目录帮助定位长文，设置入口留在导航中，阅读偏好保存在当前浏览器里。文章仍从上到下连续展开；只有当我主动寻找时，控制项才出现。
*图 3：文章首屏先建立标题与正文关系，不让工具抢在内容前面。*
正文内部遵循同一原则。标题、段落、引用、代码、图片、表格和图表保留各自的边界，但首先服务于同一篇文章，而不是彼此争夺注意力。
*图 4：正文组件保留辨识度，同时服从统一的阅读宽度和垂直节奏。*
让控制项等到被需要
浏览设置先展示常用的外观和排版选项，把阅读助手、代码块和 Mermaid 图表等专项控制放到后面。阅读助手默认关闭，代码与图表的细项继续收起。工具都在，但不必排队向正文证明存在。
*图 5：面板集中收纳控制项；关闭后，正文重新成为唯一主角。*
阅读习惯很私人。我的目标不是把所有人塑造成同一种读者，而是把“可以调整”与“必须常驻”分开。
同一篇文章可以切换标准、宽屏和阅读模式，也能独立调整字体、字重、字号和对齐方式。这些选择只影响当前浏览器里的呈现，不会改动正文，也不会生成文章版本。
手机空间更紧，容不下侧栏、目录、设置和正文同时登场。导航与设置因此退进抽屉和弹层，正文保留自然的纵向滚动。
*图 6：移动端优先保留连续阅读，控制界面按需出现。*
晚上再次打开长文时，字号、护眼模式和布局仍停在上次的位置。这比每次弹窗提醒“这里可以个性化”更有用。
真正消耗写作的，是正文之外的家务
编辑器最早借鉴了我熟悉的块编辑方式。我以为，只要文字能顺利写进去，最难的部分就完成了。
真实写作很快推翻了这个判断。我得确认内容是否保存、文章属于哪个库、Slug（公开链接地址）是否合适、何时发布；还得上传图片、调整结构、查看目录，并检查长文在前台有没有变形。正文没写两段，CMS 的家务已经排到门口。
让这些功能常驻，编辑器会很强，也会很吵。我没有删掉它们，而是按使用频率分层。
现在的编辑页分成三层：顶部工具栏显示字数、阅读时间和保存状态，并提供预览与“AI · 版本”入口；标题下方的折叠区收纳文章属性；其余空间交给正文画布。FlowDocument 承载正文，编辑、预览和发布读取同一份内容。
*图 7：默认进入编辑页时，正文面积远大于管理控件。*
把 CMS 家务折起来
库、Slug、摘要、封面、分类、标签、发布状态和定时发布时间都很重要，却不是每一分钟都重要。我通常只在归档、整理或发布前检查，所以属性区默认折叠，需要时再原地展开。
*图 8：属性留在当前文章中，需要时原地展开。*
我没有把属性搬到另一张表单页。我始终在处理“这一篇文章”，不用在正文编辑器和 CMS 表单之间往返。
保存必须让人看见
自动保存在后台运行，我能感知的只有“未保存”“自动保存中”“已保存”和“保存失败”。如果系统从不反馈，服务器或许心里有数，写作者仍然没底。
草稿保存和版本记录承担不同任务。短暂停笔后，系统自动保存当前工作稿；一段编辑结束，或进入 AI、发布、离开页面等明确节点时，系统再把修改封成可追溯的版本。前者防止今天白写，后者回答昨天改了什么。
预览也不复制临时文章。它直接读取编辑器内存中的当前正文，并复用公开端的正文渲染器。尚未保存或发布的修改因此可以立刻检查。预览不是公开页的逐像素副本，但正文结构、图片、代码、表格和图表无需再找“替身”。
*图 9：预览与编辑共享同一份当前正文，切换的只是查看方式。*
给内容留一条来回的路
导出 Markdown 给内容留了一条随时离开的路。它和闪递、编辑设置、后台设置一起收在“更多”菜单中：需要时能找到，平时不占正文空间。
能出去，也要能回来。后台既能接收单个 Markdown，也能接收包含相对图片的 ZIP。解包时，系统重新对齐中文目录和带空格的资源路径，并过滤 macOS 元数据——行李牌不是乘客，不该领到文章卡片。随后，正文和图片一起进入 FlowDocument 保存链路，不会只搬回文字，把插图留在旧目录。
*图 10：低频但重要的动作仍然能找到，却不会一直挤在正文旁边。*
桌面端可以同时容纳目录与画布，手机却很容易被工具栏挤满。因此，移动端把常用动作放到拇指附近；想专心输入时，还可以开启隐藏工具栏的“纯粹模式”。无论哪种模式，保存、预览和正文都留在同一条连续路径中。
*图 11：移动端编辑不是完整后台的机械缩放，而是保住最核心的写作动作。*
编辑器不必反复展示功能。它只需随时回答三个问题：我在改哪一篇？修改保存了吗？读者最终会看到什么？
AI 可以递建议，但不能夺过键盘
当博客逐渐长成个人内容工作台，AI 也进入了编辑页。但我不想增加一个脱离文章的通用聊天框，更不想让一句提示词直接覆盖全文。
AI 先给出候选，我比较后决定接受或拒绝。如果等待期间正文已经变化，旧建议不会挤进新版本。
这样，AI 更像一位拿着红笔站在旁边的编辑：可以提意见，不能趁我转身换掉原稿。至于它该记住什么、又该在哪里忘掉，留到下一篇展开。
长期使用还要继续检验这项设计。如果一条建议迫使我花更多时间核对，或让我分不清哪些话原本属于自己，那么模型再先进，也只是给编辑器添了一位忙碌的同事。
一个人使用，不等于一次性设计
为自己设计有一个优势：我无法靠演示掩盖问题。按钮再漂亮，只要每天多点一次，很快就会变得刺眼；设置藏得再合理，只要下次仍然找不到，最后受罪的还是我。
限制也很明确。我的设备、阅读习惯、写作方法和技术背景都不具代表性。这段经历不能证明产品适合所有博客作者，更不能取代多用户研究。
但长期自用会反复提醒我：哪些麻烦明天还会出现。对这个项目来说，这足以决定下一步先改什么。
Cursor Blinking Blog 已经不只是一个“显示文章”的网站。首页帮我找到内容，浏览页让我安静读完，编辑器和版本系统让我放心修改。它们连起来，才形成一条每天都会走的写作与阅读路径。
接下来，我更关心三个问题：阅读偏好能否长期保留？AI 建议能否让我少改一轮，而不是多审一轮？文章写完后，能否少搬运几次？
第一个问题只能交给时间；第二个会在下一篇展开；最后一个属于系列第三篇。经得起长期使用的设计，才会慢慢长成这个产品真正的样子。