思路
思路：
- 为什么要做个人博客网站
- 想要一个什么样的博客网站
- 做这个博客网站的思路
博客网站前端风格 figma make 与 codex 生成 导出 notion 数据，借鉴 notionnext 做博客网站的前后端 定义博客风格 设计规范，字体大小 4px规范、主题色 黑白紫及黑到白、紫到白上的浅色 开发原则 日志 架构文档 因为是小产品，所以没有针对性做测试用例， 然后就可以不停 vibecoding 一些具体的功能 为了少走弯路，很多功能直接模仿现有的编辑器，比如我主要 录制一个个使用片段，然后把这些片段作为测试用例，先模仿，然后在之后的使用中，不断迭代，把产品打造符合自己需求、符合自己使用习惯的产品 通用的东西沉淀下来 比如好用的模块，好的提示词，等等，比如日志，这次花费了两个小时，那么下次就是两分钟，不要重复你自己，也会让你在以后效率越来越高 第一版，大概消耗 多少 token，多少个问答，花费了多久 心得： 整个过程，没有 codereview，汇编语言 、 c++ 语言、自然语言，就像我以前开发安卓不需要知道汇编一样，以后开发我也不需要知道 c++ 等语言 写代码交给了ai，就像圣杯之战中一样，你不能以你自己都不知道的方式让圣杯帮你实现愿望，还是需要理清业务需求，制定规则，与 agent 交流反而，未来对程序员、产品经理、测试等要求都好变得多面 未来除了面向痛苦编程，会有很多产品是面向想要编程 人生是一个过程，多停下来享受片刻的宁静，少些焦虑
前言
为什么要自己做一个博客网站？
Notion + NotionNext 曾是我写博客的最优解。为了省点小钱，我在闲鱼上花几块钱买了个教育版邮箱对 Notion 进行升级，结果前几天在公司电脑上登录时，突然提示邮箱失效——心里一惊，晚上回家赶紧把家里电脑还在登录态的 Notion 里的所有笔记都导了出来。
细算下来，Notion 订阅费不算高，可加上 VPN、Codex、Claude、DeepSeek、Seedance、Figma、云盘、网易云、芒果、Bilibili、微信读书……零零总总，每个月开销着实不少。现在每月已经花花费 $200 订阅 Codex 了，作为一个开发者，不受挫一个博客网站说不过去了？
更何况，在别人的平台上写东西，你永远不知道明天会发生什么。算法一变、审核一严、甚至平台一关——你的内容说没就没。Notion 的使用也不是都和心意，比如大文件传不了，所见即所的得便利无与伦比，功能很多，但太多的反而是一种负担，浏览的时候也不纯粹。
事已至此，即刻行动。
想做一个什么样的博客？
市面上现成的方案太多了：WordPress 一键安装、Hugo / Hexo / Jekyll 等静态生成器，Github 上面的相关开源等，随便选一个半天就能上线。但它们的阅读和编辑体验，很难追上 Notion——而改变习惯，恰恰是最难的事。
我想要的博客，必须满足这几点：
1. 看着要舒服
我对视觉没有太高的追求，但起码要“看起来自然”——字体、间距、颜色、留白，每一个细节都该和谐不突兀。
2. 写起来要爽
写作体验不好，会让本来就不强的写作意愿进一步消减，便不易养成习惯坚持写。所以我需要一个与现有工作流无缝衔接的方案——我已经习惯在 Notion 里写东西，桌面端的功能和体验要尽量接近 Notion，手机端则要更纯粹、更专注。最底线的：能直接从 Notion 导出生成博客。
3. 简洁为上
不要花哨背景，不要复杂交互，不要各种社交嵌入。打开页面看到文章列表，点进去舒适阅读——仅此而已。编辑器也应当是“透明的”，让我忘记它的存在，只专注于写什么。
4. 小作坊，下猛料
在简洁之上，融入自己的一些想法：
- 支持多种导入：Markdown、Notion URL、Notion ZIP 导出包、电子书（顺便把微信读书的会员也省了）；
- 一键同步到掘金、知乎、小红书、公众号（如果想要让更多的人看到，一处编写，处处运行）；
- 后续还可以支持评论互动等，也可以支持方便收集一些比较喜欢的文章、图片。
- 加一点驱动力方面的功能，有了激励（阅读数、点赞数等）、才能获取内心的满足，才能不断循环下去。
5. AI 融合
自己的博客，天然适合结合 AI。可以预设喜欢的文字风格、阅读模式，生图、制表、流程图、PPT 模板，甚至需要用到什么新功能时，让 AI 现做。这种专属感和操控感，是任何其它平台无法替代的。
说白了，我想要的就是一个有趣的、纯粹的、好读的、好写的个人专属博客网站。
大体思路
既然已有 Notion 导出数据，又有过接入 NotionNext 的经验，我的第一步很自然：让 AI 基于 Notion 导出的数据设计数据结构。这个数据结构将成为“唯一真源”——导入要转成它，导出要基于它，展示即对它的呈现。
为了少走弯路，很多功能直接模仿现有的编辑器，现有基本功能，然后在之后的使用中，，把设计、功能、交互往自己喜欢的方向不断迭代，打造符合自己使用习惯的产品。
接着，进入 Vibe Coding 模式。
关于 Vibe Coding
这个概念由 Andrej Karpathy 提出，本质是“跟着感觉走，忘掉代码的存在”——用自然语言告诉 AI 你想要什么，让它生成、迭代代码。我的整个博客项目，就是这么做出来的。
整个过程，没有手写代码，没有 Code Review，从汇编，到高级语言（C++、Java、JavaScript 等），在到今天通过 AI 使用自然语言编程，没必要开历史倒车，在去琢磨什么数据结构、算法。就像我以前做安卓开发不需要知道汇编一样，以后的开发，我也可以不需要知道高级语言。
但很多人误解了 Vibe Coding，以为只是“让 AI 随便写”。其实不是。你需要清晰地知道要什么、边界在哪、验收标准是什么。AI 是演奏者，不是指挥家。
这就像《Fate/stay night》里的圣杯战争最后许愿的环节——你不能以自己都不清楚的方式让圣杯帮你实现愿望。就像你不能让 Ai 帮你把银行卡里面多出 100W 一样，你要清晰知道到达目的每个节点（粒度是 AI 能承受的）。
具体流程
一些准备工作
设备 mac设计工具 figma、make编码 vscode + codex 插件、codex app代码托管 codeup、codeup 流水线进行部署阿里云 ECS 服务器域名 notes.vectania.com（之前备案过的域名添加一个二级域名）设计风格
我比较喜欢 Figma Make 做出来的 UI 风格，多次对话修改后，我得到了这样的界面效果。
这里直接放上最终的 UI 效果，也便于读者知道这是什么样的博客网站，都有什么功能。
博客前台页面
博客后台页面
移动端页面
项目基础
先使用 Codex*gpt-5.5 编写一个 Demo ，基于 Notion 导出数据，参考 NotionNext 展示出文章的思路，和上面 Figma Make 下载后的项目的风格，编写对应的博客网站技术方案文档，然后按文档落地。第一版 Demo 就出来了。
各种规范
设计规范
为整个项目建立统一的 Design System。整体风格保持简洁、自然、克制，以内容优先。主题色仅使用黑、白、紫，以及它们不同透明度的颜色，或从黑→白、紫→白渐变中提取的颜色。这种配色方案有点类似于 Andorid Material You 的动态色彩方案，便于后续开发多主体色功能。
采用 4px Grid 设计规范，所有小于 4px 的尺寸视为特殊情况（如 1px 边框），所有大于 4px 的尺寸（间距、图标、按钮、卡片、圆角等）均使用 4 的倍数。
所有相同语义的组件必须保持统一，包括视觉样式、交互方式和状态反馈；按钮、Hover、高亮、Focus、Loading、鼠标样式等相似场景均应遵循一致的交互规则，确保整个项目具有统一的视觉语言和用户体验。
设计规范.md
# 设计规范 本文定义 Cursor Blinking Blog 长期有效的视觉与交互规则。阶段性页面方案可以更细，但落地时必须回到本文检查一致性。 本项目的视觉方向是“简约、克制、内容优先”。公开端服务阅读，后台服务长期内容生产；两者都应避免展示型官网气质、强装饰和一次性视觉效果。 ## 范围与优先级 - 适用于 `client` 下的公开博客、后台工作台、文章编辑器、文章管理、文章导入、统计、日志和全局反馈。- 本文记录稳定规则，不记录单个页面的临时样式；具体实现可更细，但不能与本文冲突。- 新界面优先复用现有主题变量、组件语义和交互模式。- 旧页面与本文冲突时，后续修改逐步收敛，不为单次小改动强行重写。 ## 核心原则 1. 内容优先：公开端让标题、正文、图片和目录成为主角；后台让表格、表单、编辑内容和关键操作成为主角。2. 主题收敛：页面以黑、白、紫为主题色，其他层次优先使用主题色透明度、黑白灰阶，或从黑白/紫白色阶中取色。3. 分层清楚：页面、区域、组件、状态要可辨，但不依赖厚阴影、大渐变或装饰背景。4. 密度有边界：后台可以高密度，不能牺牲可读性、点击热区和移动端可用性。5. 行为稳定：加载、拖拽、选中、保存、失败等状态必须可预期，不能造成布局跳动或误触。6. 语义一致：同一语义的组件和场景必须保持统一的视觉样式、交互方式和状态反馈，形成稳定的项目视觉语言。 ## 空间与形态 - 4px 是基础空间单位。按钮大小、控件高度、间距、padding、表格行高等大于 4px 的布局值，尽量落在 4px 倍数上。- 小于 4px 的值一般用于用户自定义细节、边框、分割线、焦点线、插入线、发丝阴影和光学微调，不按 4px 网格强约束。- 常用节奏：`4px` 细间距，`8px` 紧凑间距，`12px` 表单/标签内距，`16px` 默认内容内距，`24px` 区域内距，`32px+` 页面区块节奏。- 圆角默认克制：普通控件使用方角、`2px` 或 `4px`；弹层和菜单可使用小圆角；不要新增大圆角卡片风格。- 滚动条保持轻量，轨道透明，滑块使用边框色或浅灰；高密度横向表格可适当加粗以保证可操作性。- hover、拖拽和加载动画不能改变布局尺寸；动画位移优先使用 `4px` 或 `8px`。 ## 色彩 - 主题色为黑、白、紫。新增颜色优先来自 `--minimal-*`、`--admin-*` 等语义变量，不把十六进制颜色散落在组件中。- 背景、正文、弱文本、边框、hover、禁用和分割层次，优先使用黑/白的透明度或黑到白的灰阶过渡。- 强调、焦点、选中、拖拽、插入线、进度条、复选框、输入框焦点等交互反馈，优先使用紫色或紫色透明度。- 黑到白、紫到白只作为克制色阶来源：从色阶中取接近场景的单点色；默认不直接使用连续渐变，不新增多彩、强饱和或装饰性渐变。- 状态色必须稳定且少量使用：成功/发布、待处理/草稿/定时、失败/删除/危险可保留独立语义色，但不扩展成大面积色彩系统。- 分类、标签、库可见性等属性色优先使用主题色透明度区分；确需多色时只能使用低饱和浅色，并在同一页面内保持稳定。- 亮色和暗色主题必须同时可读；新增颜色必须确认两个主题下的对比度。- 夜间模式优先使用接近 OpenAI 风格的中性深灰分层，避免大面积纯黑背景和纯白选中块造成高反差断层；弹层、控件和选中态用灰阶层次表达。 ## 字体 - 公开端文章详情页的主标题、正文标题和正文统一使用无衬线字体；导航、元信息、列表页标题和后台界面也使用无衬线字体。- 代码、路径、slug、日志字段和技术标识使用等宽字体。- 字体大小不随视口线性缩放；使用固定字号或明确断点。- 字距默认 `0`，不要用负字距制造紧凑感。- 中文正文行高应偏舒展，后台表格和控件行高可更紧凑但必须易扫读。 ## 布局 - 后台采用稳定工作台结构：导航长期可达，内容区随任务决定宽度。- 公开端阅读页优先控制正文宽度，侧边目录只在宽屏承担辅助导航。- 公开端文章正文默认宽度与编辑器默认画布保持一致，使用 `768px` 作为桌面阅读基准，保证编辑态和阅读态尽量所见即所得。- 页面区块不要套娃卡片；外层用背景、留白和分割线分区，卡片只用于重复项、面板、弹层和确实需要框定的工具。- 固定格式区域必须有稳定尺寸或约束，例如表格列宽、媒体比例、地图高度、工具栏高度。- 列表、表格和媒体加载完成后不应推动周围内容大幅跳动。 ## 组件规则 - 按钮只表达命令。主要操作使用前景色反转，次要操作使用透明底加边框，危险操作只用于不可逆或高风险场景。- 同一语义组件必须遵循同一套交互规则。按钮、链接、图标按钮、列表行、表格行、标签、输入控件和菜单项等相似场景，应统一 hover、高亮、focus、active、disabled、loading、鼠标样式和状态反馈；除非语义确实不同，不得为局部页面单独创造另一套视觉和交互表达。- 同一组按钮或工具控件内，颜色、图标尺寸、图标线条粗细和图标视觉重量应尽量一致；不同图标库或自绘图形混用时，必须统一到相近的外框尺寸、对齐方式和留白，避免同一工具栏内出现轻重不一的视觉噪声。- 图标按钮必须有可理解的图标、`aria-label` 或 tooltip；工具类操作优先使用图标，不用冗长文字占位。- 输入控件标签放在控件上方，错误信息紧跟控件下方；输入框、复选框、进度条等基础控件优先使用主题色表达焦点、选中和进度状态。- 表格优先保证列宽、行高和横向滚动稳定；高密度数据库视图可以更紧凑，但必须提供清晰的 hover、选中、拖拽和空态反馈。- 行内编辑应原地完成，并提供明确的提交、取消和保存中状态；不能让编辑态改变整行布局。- 状态标签文案必须短且稳定，例如草稿、定时、已发布、已归档、已删除、失败。- 属性选择器用于分类、标签、状态、可见性等结构化字段；属性值过多时折叠计数，不撑破单元格。- 弹层和菜单用于短任务，不承载复杂页面；遮罩、标题、表单、结果和操作区层级必须清楚。- 除手机端侧边栏抽屉外，弹窗内容区域必须阻止鼠标、指针、触摸和滚动事件透传；可滚动弹窗必须限制滚动链，避免滚到边界后带动底层页面。- 全局加载反馈只表达路由或页面加载，不占布局高度，不作为装饰。 ## 公开博客规则 - 文章标题是首屏最高优先级，不被卡片、装饰背景、按钮或营销文案抢占。- 文章列表、归档、分类、标签和搜索结果的日期口径必须统一；默认展示发布日期，缺失时再回退到编辑时间或源数据日期。- 元信息应自然换行，不挤压正文；图标与文字只使用小间距。- 浏览设置统一收纳日夜间模式、布局模式、导航栏位置、用户主题色、字体和字号；默认主题色仍为紫色，其他主题色只作为用户浏览偏好，不改变品牌主色和正文基调。- 护眼模式属于浏览设置的阅读偏好，日间和夜间分别提供低刺激背景与文字色，优先影响首页列表和文章阅读，不改变文章结构、布局模式或品牌主题色；页面根节点、主题根、阅读主容器、正文容器和懒加载占位必须使用同一背景变量，避免长文快速滚动或目录跳转时短暂露出默认白底。- 公开端文章阅读方式统一为上下滚动；不提供左右翻页、按屏分页或页码式阅读入口，避免和浏览器横向手势、目录抽屉、复杂正文组件产生冲突。- 图片、视频、GIF 和多媒体块按真实内容比例展示，并提供稳定宽度、最大宽度和加载态。- 前台文章表格在窄屏优先按可读下限压缩列宽和字号，尽量露出更多列；仍不可完整展示时保留横向滚动，并在可滚动状态下显示明确滚动条提示。- 代码块、引用、提示、书签和折叠块使用边框或浅灰背景区分，不使用高饱和背景；前台移动端代码块正文可适当缩小字号和行高，优先保留横向滚动阅读效率。代码块默认折叠只能由浏览设置优先控制，或在浏览设置未开启时遵循 FlowDocument 数据源状态；不得仅因为代码块数量或代码行数明显超长而自动折叠。长代码块应按折叠状态和代码行数提供稳定高度估算，降低目录跳转和快速滚动时的布局修正。- 目录只能辅助阅读，不能遮挡正文；移动端优先折叠或置于正文前。长文目录跳转默认使用平滑滚动，并在跳转前预热目标附近重块；用户系统开启减少动态效果时可降级为瞬时跳转，保证可访问性和跳转后正文尽快可见。- 前台移动端顶部导航采用类似 CoordinatorLayout `scroll|enterAlways` 的 quick return：向正文深处滚动时按滚动距离逐步收起，任意位置反向滚动时按滚动距离重新露出，不要求回到页面顶部才显示。- 前台移动端侧边栏按抽屉弹层处理，打开时阻止底层页面滚动和事件透传；线条目录区域只承载触摸拖动预览，松手后跳转到选中标题；长目录拖动到可见区域顶部或底部时，由指示器列表自动滚动，避免滑选与普通滚动两种手势混淆。- 阅读进度与短线式目录指示器保留既有形态，包括条距、高度和轻量主题色，不按普通控件规则重做；阅读进度条固定在目录滚动区域顶部，不随短线指示器列表滚动；阅读进度条可作为轻量切换入口，双击或移动端双触用于在文字目录和短线目录指示器之间切换。- 备案、版权、Cookie 设置、语言切换和明暗切换等非正文信息统一收纳在页脚；页脚在内容流结束后自然出现，可使用黑/深灰背景栏与低权重小字号，不常驻占用首屏或侧边栏信息层级。 ## 后台工作台规则 - 页面标题区只放当前任务和必要操作，不放营销式说明。- 文章管理采用“库 -> 文章数据库”的工作流；库、文章、状态、分类、标签等结构化字段应保持同一套视觉语言。- 数据库视图以固定列、行内编辑、属性选择、批量选择、拖拽排序和横向滚动为基础能力。- 行 hover 操作、批量操作和危险操作必须分层展示，不能挤占核心数据列。- 导入、同步、发布、删除等长任务必须有等待态、结果态和失败态；失败信息要靠近触发任务的位置。- 统计和日志页面以排查与扫描为目标，避免装饰图形和冗长说明。 ## 编辑器规则 - 编辑即预览，编辑态和阅读态尽量共享排版规则。- 文本选择优先于块操作；拖拽排序、插入线、浮动工具栏不能遮挡正文或抢焦点。- 块间距遵守 4px 网格，正文段落保持稳定节奏。- 媒体块必须定义比例、最大宽度和加载态，避免加载后推动正文跳动。- 移动端隐藏非必要工具，发布、属性和更多设置可折叠或下沉，但核心编辑操作必须可达。 ## 响应式与可访问性 - 手机端优先保证无横向溢出、无文字重叠、无按钮挤压。- 表格在窄屏可以横向滚动或转为信息卡；不得把列压缩到不可读。- 交互热区在移动端应足够点击，常用操作不可只依赖 hover。- 动效必须尊重 `prefers-reduced-motion`；关闭动画后仍能理解状态变化。- 可交互元素应有键盘焦点、语义标签和禁用态。 ## 不推荐做法 - 不要引入大面积连续渐变、漂浮光效、装饰背景图或强展示型官网视觉。- 不要混用多套圆角、阴影、按钮和标签风格。- 不要为了“像 Notion”牺牲本项目自己的内容模型、状态表达和移动端可用性。- 不要新增一次性 spacing、颜色和字号；确实需要时先抽象为语义变量或局部规则。- 不要让加载、拖拽、hover、弹层开合造成内容跳动或误触。 ## 检查清单 - 大于 4px 的控件尺寸、间距和 padding 是否尽量遵守 4px 网格？- 是否复用了现有 `minimal` / `admin` 变量和组件语义？- 颜色是否收敛到黑、白、紫及其透明度/黑白灰阶/紫白取色，状态颜色是否必要且一致？- 表格、媒体、工具栏和弹层是否有稳定尺寸或约束？- 同一语义的按钮、hover、高亮、focus、loading、鼠标样式和状态反馈是否保持一致？- 同一组按钮内的颜色、图标大小、线条粗细、视觉重量和对齐方式是否一致？- 移动端是否无重叠、无不可读压缩、无关键操作丢失？- 危险操作、等待态、失败态和恢复路径是否明确？- 亮色、暗色、键盘操作和 reduced motion 是否可用？ 开发原则
大概意思就是规则优先，不要一直堆叠 if else，该暴露问题及时暴露，不要兜底，不要双路径，遵循 SOLID 原则，尽量分层、分模块、抽取公关类，日志统一输出但不要泄密不要影响性能，小修改时编译要快但不要出错等等。
开发原则.md
# 开发原则 1. **真实优先，显式失败** 不用静默 fallback 掩盖真实问题。默认值、降级、重试和错误提示都必须是有意设计；无法正确处理的状态应尽早暴露、记录并修正。 2. **简洁优先，及时收口** 功能完成后及时清理临时逻辑、重复分支和历史痕迹。代码应直接表达当前业务，不为想象中的未来堆叠复杂度；无关重构不夹带进功能改动。 3. **边界清晰，抽象有因** 分层、模块和抽象必须服务于稳定边界、复用和隔离复杂度。SOLID 是判断工具，不是形式要求；边界尚不稳定时先保持直观实现，避免空泛的 manager、helper 或中转层。 4. **单一路径，发版前不背兼容** 正式发版前不为旧数据长期保留双路径。优先通过迁移、清洗、导入修复或一次性转换收敛数据；确需临时兼容时，必须有明确删除条件。 5. **可读可观测，默认脱敏** 关键设计要能被后来者理解，必要时用简短注释说明原因和取舍。日志必须通过统一门面输出，级别清晰、可定位问题、默认脱敏；禁止散落 `console.log`，禁止输出凭据、token、密码或完整正文。 6. **命名稳定，语义明确** 文件夹、文件名、类名、函数名、变量名和接口名必须表达领域含义与职责边界。目录和文件使用项目既有风格，前端组件使用 `PascalCase`，普通函数和变量使用 `camelCase`，常量使用 `UPPER_SNAKE_CASE` 或既有语义变量格式；禁止使用含糊的 `data`、`temp`、`manager`、`helper` 等兜底命名，除非上下文已经足够明确。 7. **小步变更，可验证可回滚** 每次改动先明确影响范围和最小验证路径。数据库、导入、定时任务、外部同步等高风险能力必须可重复执行、可追踪、可回滚；提交前运行与风险匹配的类型检查、架构检查或关键自测。 8. **文档克制，跟随事实** 文档服务于协作和长期维护，不堆砌实现流水账。实现改变长期边界时同步更新原则或架构；专项方案只记录稳定取舍、风险和验收口径。文档与代码冲突时，要么修文档，要么修实现。 9. **文字清爽，中英留白** 文档、日志、注释、提交信息、页面内嵌文字和提示文案中，汉字与英文字母、汉字与数字之间默认保留空格，例如 `同步 3 篇文章`、`FlowDocument 渲染失败`。专有名词、代码标识、URL、路径、版本号和固定品牌写法保持原样。 10. **验证适度，优先热更新** 为提高开发效率，小改动优先依赖热更新、局部页面检查和最小必要验证，不默认做全量构建、全量自测或耗时回归。只有改动触及构建链路、共享逻辑、数据结构、权限、发布流程或高风险交互时，才扩大验证范围；发现异常时再逐级加深检查。 交付前必须评估运行态影响，确保用户能在当前约定地址直接验证。改动涉及客户端入口、全局样式、Next 配置、依赖、共享模型、服务端代码、构建产物或缓存时，应按需重启对应的客户端或服务端，并检查端口监听、页面/API 基本响应和明显编译错误；如果曾运行构建导致开发缓存失效，应清理或重建相关缓存，避免因旧进程、旧 `.next`、端口占用或缓存不一致让用户无法立即验证。 11. **自有模型，长期可控** 项目演进以数据库内容源、FlowDocument 和自有编辑管理能力为核心。外部来源只作为导入或同步边界存在；新增能力应增强自有内容系统，而不是重新绑定第三方运行时结构。 项目架构
整个项目分为服务端、客户端（前台、后台），部分共享的代码，典型的 web 应用架构。
文章的数据结构是一切的核心，导入、导出、展示、存储都是围绕它，本身跟 Notion 很像的分块的数据类型。
文章内容长度到了一定量级后，架构便是不可避免的了。类似 RecyclerView 一样只渲染当前窗口前后，各种块进行懒加载、缩略图加载等。
再补一个编辑器的架构，可以说编辑器的交互特别多，想类别 Notion 的交互体验，编辑器这块的工作量大概是其它的加在一起的十倍还要多。这个先实现了基础功能，等之后使用中在慢慢磨吧。
附件未导入：CursorBlinking 编辑器架构图.png
📌
这些架构图都是使用 Codex app 同过 Figma mcp 完成的，较粗糙，大致能理解用来跟 AI 沟通就够了，细节的部分就交给 AI 来做吧，架构图的价值不是把系统画得很复杂，而是让和 AI 协作时的边界变清楚，换句话说这是给 AI 看的。
Codex 配置
关于 Codex 配置，我单独整理了一篇教程 Codex 使用简明教程-让 AI 真正帮你干活，而不是陪你绕圈（其实是 AI 整理，我稍加修改）。最主要的就是在跟目录下设置 Agent ，告诉 Agent ，与我对话的时候，先做什么，做完了之后要做什么。下面是我的 Agent 配置。信息过少 Agent 回答不按规矩来，导致你后续纠偏任务重，或者不安你预期工作，反复兜圈子。信息过载很增大上下文、响应慢、而又限制模型使回答缺少创意。所以轻前置 + 重后置。
# Agent 工作约定 本文件适用于整个仓库。默认采用“轻前置 + 重后置”：开工前只看少量硬红线，避免方向性错误；完成后再按实际改动读取细则、验证并修正，避免每轮对话被规则文档淹没。 ## 工作流程 1. 开工前：读取本文件，判断任务类型和风险。简单问答、状态确认、纯评估不默认加载其他文档。2. 工作中：优先读代码事实和现有实现，沿用当前模块、命名、组件和数据流，不为了局部方便引入第二套路径。3. 交付前：按 `docs/Codex工作规则/交付校准与路由规则.md` 做后置校准；功能修改需要验收时，按 `docs/Codex工作规则/功能落地后自测和人工验收规则.md` 设计人工验收建议、补充或更新功能自测、确认运行态可直接验证；再根据实际触及范围补读相关文档、更新长期文档、运行最小必要验证。 如果文档和代码不一致，先判断代码是否已经成为新事实；是新事实就同步文档，不是新事实就修正实现。 ## 完成定义 - 代码、配置、脚本或文档结构变化，要说明实际改动范围和已运行的最小验证。- 用户可见功能、可复现 bug 或 UI 行为变化，要给出已验证 / 自测结果、人工验收建议、URL / 验收路径和剩余风险。- 未能运行应有验证或无法确认运行态时，要明确说明原因，不把静态检查描述成人工验收。- 交付前要确认没有违反前置硬红线；涉及本地记录、凭证、日志或外部服务时先脱敏。 ## 前置硬红线 - 客户端不能直接读写 SQLite；持久化写入必须经过服务端 API、迁移或明确的导入脚本。- 客户端前台只消费公开 payload；客户端后台只表达操作和临时状态，写入必须经过 admin API。- 服务端拥有事实、权限、校验、数据库写入和审计；HTTP 路由保持薄，业务逻辑进入 `server/src/modules`。- `shared` 只放跨端纯逻辑，不能访问数据库、文件系统、HTTP、DOM、cookie、localStorage 或环境变量。- FlowDocument 是正文唯一主协议；Markdown、HTML、外部平台格式和搜索索引都是导入边界、兼容输出或派生数据。- 日志和本地记录必须先脱敏；不要输出或写入 token、cookie、口令、私密正文、本机路径、私有远端或完整敏感 payload。 ## 按需读取入口 部分可复用流程已抽成 repo 级 Codex skills：`project-acceptance`、`project-commit-push`、`project-conversation-archive`、`project-ops-records`。skill 使用说明见 `docs/技术方案/Skill使用说明.md`。可用时可以用 skill 执行流程，但本文件、`docs/Codex工作规则/` 和本仓库架构文档仍是项目内最终约束；skill 不替代仓库硬红线和本地运维记录。 | 场景 | 读取文档 || --- | --- || 复杂、含糊、跨模块或高风险任务计划 | `PLANS.md` || 交付前校准、验证、文档更新判断 | `docs/Codex工作规则/交付校准与路由规则.md` || 开发原则、命名、验证、文档边界 | `docs/开发原则.md` || 功能修改后的人工验收建议、自测和运行态验证 | `docs/Codex工作规则/功能落地后自测和人工验收规则.md` || 提交、commit、push、提交所有未提交、排除本地杂项 | `docs/Codex工作规则/提交规则.md`；涉及远端、认证或凭证 helper 时同步读取 `docs/本地运维记录/代码提交与推送.md` || UI、移动端、阅读体验、弹窗、遮罩、布局、交互 | `docs/设计规范.md` || 服务端、客户端前台、客户端后台、shared 分层或数据流 | `docs/项目架构/项目架构.md`、`docs/项目架构/端侧分层架构.md` || 文章数据、数据库、公开 payload、后台 payload、搜索、导入、发布、同步 | `docs/项目架构/文章数据架构.md` || 编辑器、FlowDocument、事务、选区、拖拽、前台渲染协议 | `docs/项目架构/编辑器架构.md` || 对话归档、资源复制、session JSONL 摘要 | `docs/Codex工作规则/对话记录规则.md` || 服务器、Git、部署等反复使用的本地索引 | `docs/Codex工作规则/本地运维记录规则.md` | ## 本地记录 - 每次向用户交付最终回复前，按 `docs/Codex工作规则/对话记录规则.md` 把本轮可见对话归档到 `docs/对话记录/YYYYMMDD/`。- 用户添加的图片、视频、文档等资源，要同步复制到对应归档 Markdown 同名 `.assets/` 目录，记录里使用相对路径引用；图片资源要在资源行下方直接嵌入显示。- 连接服务器、推送代码、访问私有服务、部署脚本等反复使用的信息，按 `docs/Codex工作规则/本地运维记录规则.md` 记录到 `docs/本地运维记录/`。- `docs/对话记录/` 和 `docs/本地运维记录/` 是本地记录目录，默认不纳入 Git。 这是一个回答的 Agent 的回复结果
功能、体验、迭代
咋一看还挺有那么回事的，但实际体验一番，发现想做到 看着要舒服，其实是挺难一件事，举个例子，字体不对、间隔不对，护眼模式呢？
特别是把自己带入用户，早上、晚上使用它的场景，就会发现诸多问题，
优化犹如在盘行走，越靠近边缘，行驶约缓慢，但体验的优化是有终点的，就是能不能复合直觉，激励，目的是做到
如果是前面顺风顺水，那后面无疑泥水了，编辑器的优化为直接放弃了，并不是真的放弃，因为我发现一点一点调简直是浪费生命，所以我把问题转化为如何提炼规则，如果让ai 按我设想的帮我实现，如果一个项目要化一个月，那一定是前面三个周做轮子，后面一周把它做出来
做到能跑只是第一步，真正耗时间的是把它调到“自己愿意每天打开”的程度。这个博客后续的迭代基本围绕三件事：阅读舒服、写作顺手、数据路径可控。
开发总结
token 使用情况
从 2026-06-29 周一 00:00 到 2026-07-02 22:55:48（Asia/Shanghai）：
总计约 116,808,166 tokens。
会话日志部分是 112,657,323 tokens：input 111,602,902，output
449,368，reasoning output 170,870，cached input 102,246,784。cached input 是
input 的子集，不要额外相加。另有 4,150,843 tokens 只在运行日志里有总量记录，我
已补进总数。
代码行数
对话轮次
几点心得
Vibe Coding 不是“让 AI 随便写”。
说到开发方式，就不得不提 Vibe Coding。这个概念由 Andrej Karpathy 提出，本质是“跟着感觉走，忘掉代码的存在”，用自然语言告诉 AI 你想要什么，让它生成、迭代代码。
我的整个博客项目，就是这么做的。
整个过程，没有 codereview，汇编语言 、 高级语言（c++ java、js 等）、自然语言，就像我以前开发安卓不需要知道汇编一样，以后开发我也不需要知道高级语言
很多人误解了 Vibe Coding，以为就是想到什么让 AI 生成什么。其实不是。你需要清晰地知道要什么、边界在哪、验收标准是什么。AI 是加速器，不是决策者。
这就像《Fate/stay night》里的圣杯战争——你不能以自己都不知道的方式让圣杯帮你实现愿望。你需要清晰地知道你想要什么，才能让 AI 准确地帮你实现。
通用的东西要沉淀下来。
开发过程中，好用的提示词、代码模块、工作流都记录下来。这次花两小时解决的问题，记下来之后下次就只要两分钟。不要重复造轮子，更不要重复踩坑。don’t repeat your self
如果相似的事情第二遍和第一编花费时间一样多，那肯定是我有问题
问题比答案更重要
最重要的——享受过程。
做这个博客不是为了完成什么 KPI，也不是为了给谁看。就是自己想做一个东西，然后做了。中间遇到了不少麻烦，部署的时候各种连不上、内存不够，但解决这些问题本身也挺有意思的。
新的开发范式
现在越来越像这样：
产品想法 ↓需求拆解 ↓制定规则 ↓Agent 实现 ↓Review ↓继续迭代你会发现。
写代码已经不是最重要的一步了。
反而越来越重要的是：
- 产品设计
- 需求表达
- Prompt
- 架构
- 规则
- 验收标准
代码更多变成 AI 的输出。
可能之后对开发者的要求，从写代码，变成了快速理解、制定规则、多线并行、方案抉择、结果评估等能力。
新的开发范式
软件产品从面向需要（需求）开发想面向想要（美好）开发，未来会有越来越多的产品可能基于个人喜好或兴趣而被开发出来，释放创意，创造自由。就想我这个博客网站的产生一样。
最后
如果你也在考虑做一个自己的博客，我的建议是：别想太多，动手就行。 技术方案选什么都行，重要的是开始写、开始搭。过程中会遇到问题，解决了就好了。
人生是一个过程，多做点让自己开心的事。