最近这段时间，我把自己的博客从一个“能发文章的静态站点”，一点点做成了一套更完整的内容系统。更准确地说，这是一个我和 AI 一起持续迭代出来的项目。
它表面上是一个 Astro 博客，但背后其实已经包含了内容同步、外部文章导入、Markdown 清洗、图片管理、自动化测试、CI/CD 和一整套发布流程。回头看，这个项目最有意思的地方已经不只是“页面长什么样”，而是它慢慢长成了一个真正能支撑持续写作的系统。
而在这个过程中，agent coding 给了我非常大的帮助。它不是简单帮我“写点代码”，而是实打实地参与了功能实现、交互打磨、内容修复、规则沉淀和自动化流程建设。
如果说这篇文章里我最想重点分享什么，其实不是某个页面样式，也不是某个小交互，而是这套围绕内容输入、AI 修复、CI 校验和自动发布搭起来的工作流。
这篇文章想分享四件事：我是怎么一步步把它搭起来的，它现在能做到什么，我是怎么把 AI 用进整个构建过程里的，以及这套工作流为什么让我越用越顺手。
顺便提一句，这套博客系统是完全开源的，仓库地址在这里：
https://github.com/yuanlehome/blog
这套博客系统最让我满意的，不只是最后呈现出来的页面，而是它背后已经形成了一条完整的内容生产流水线：写作、导入、AI 修复、校验、预览、部署，全部都能串起来。
一、为什么我要自己做这套博客系统¶
最开始的动机其实很简单，我想要一个足够轻、足够快、又足够可控的写作空间。
对我来说，博客不是一个单纯展示首页的地方，它更像一个长期积累知识、整理思考、沉淀技术笔记的仓库。如果只是用一个现成模板，当然很快就能上线，但写久了就会遇到几个问题：
- 内容入口太分散，本地 Markdown、Notion、微信公众号、知乎文章不好统一管理。
- 发布流程太依赖手工，一旦步骤变多，写作体验就会被流程拖慢。
- 模板能解决“展示”，但不一定解决“长期维护”和“持续扩展”。
- 技术博客对公式、代码块、Mermaid、图片、目录、评论这些细节要求很高。
所以后来我就不再把它当成一个“博客主题”，而是把它当成一个围绕写作和内容管理来设计的小系统。
二、我希望它最终解决什么问题¶
在真正动手之前，我给自己定了几个比较明确的目标：
- 写文章要足够顺手，本地直接写 Markdown 就能发布。
- 内容来源要统一，Notion、微信、知乎、Medium 甚至 PDF 都能进来。
- 构建过程要稳定，站点构建时尽量不依赖外部接口。
- 阅读体验要舒服，桌面端和移动端都要可用，代码、公式、图片、目录都要照顾到。
- 配置要集中，尽量不要把站点信息散落在很多文件里。
- 自动化要完整，最好把同步、导入、删除、部署、预览都接进 CI。
现在回头看，这几个目标基本都落到了代码里。
三、为什么这次我特别想强调 AI¶
如果只把这个项目写成“我做了一个 Astro 博客”，其实是不完整的。
因为这次真正让我效率明显提升的，不只是 Astro、脚本、CI 或者内容管线本身，而是我开始认真把 AI 当成一个可以协作的开发角色来使用。
我并不是让 AI 一把梭把整套系统“生成出来”。真正有效的方式恰恰相反：
- 我来定义目标、边界、验收标准和最终取舍。
- 我把任务拆成足够具体的小块，让 AI 先读仓库、读文档、读上下文。
- 让 AI 去处理高频试错、重复劳动、脏活累活和大量边角修复。
- 最后再由我结合测试、构建结果和实际体验来收口。
对我来说，AI 最有价值的地方不是“代替思考”，而是把很多原本会拖慢节奏的工作压缩掉，让我能把更多注意力放在架构、产品感受和系统边界上。
四、这套系统是怎么一步步长出来的¶
4.1 先把展示层搭稳¶
我选择了 Astro 作为底座。原因很直接：它很适合内容型站点，静态输出足够快，页面结构清晰，而且对 Markdown 内容站非常友好。
这一步里，我先把博客最基础的结构搭了起来：
- 首页、归档页、标签页、关于页这些基础路由。
- 基于内容集合的文章组织方式。
- 统一的
Layout、Header、Footer和文章详情页布局。 - 文章元信息、标签、上一篇/下一篇、相关文章、评论区这些基础能力。
同时，我把站点配置拆成了多个 YAML 文件，比如 site、home、nav、theme、layout、profile、components、typography。这样做的好处很明显：以后我想改站点名字、导航、主题、排版、首页文案，不需要满仓库找常量，改配置就够了。
这一阶段，AI 对我最大的帮助是把“想法”快速变成“可运行的第一版”。很多布局、组件拆分、配置收口这种事情，本来就适合先快速落一个版本，再慢慢收紧。我可以先让 agent 基于真实仓库结构给出最小实现，然后自己再决定哪些保留，哪些重做。
这一步做完后，博客已经“能看了”，但还远远不够。
4.2 把内容输入统一起来¶
我觉得这个项目真正开始像“系统”，是从内容入口统一开始的。
除了本地 Markdown，我又陆续补上了几条内容链路：
- Notion 数据库同步。
- 外部文章导入，支持知乎、微信公众号、Medium。
- PDF 导入，走 OCR 和 Markdown 转换流程。
它们最终都会落到同一个地方：src/content/blog/ 里的 Markdown 文件，以及 public/images/ 里的静态图片资源。
整个数据流大概是这样的：
Notion / 微信 / 知乎 / Medium / PDF / 本地 Markdown
↓
scripts 层
↓
src/content/blog + public/images
↓
Astro Runtime
↓
静态站点输出Notion / 微信 / 知乎 / Medium / PDF / 本地 Markdown
↓
scripts 层
↓
src/content/blog + public/images
↓
Astro Runtime
↓
静态站点输出这个设计有一个我自己很喜欢的点：运行时和脚本层是分开的。
站点本身只负责读取已经生成好的内容并渲染页面，不在构建阶段临时去请求外部平台。外部内容的获取、转换、清洗、下载图片这些事，全部放在 scripts/ 里先做完。这样做带来的收益很直接：
- 构建更稳定。
- 页面逻辑更干净。
- 问题更容易定位。
- 后面扩展新内容源时也更自然。
为了让导入结果更可用，我还补了一整套 Markdown 处理流程，比如语言检测、可选翻译、代码块语言补全、数学公式修正、列表和空行清洗、MDX 安全修复等。很多文章表面上“导进来了”，但真正要渲染稳定，往往还要处理不少脏数据，这部分也是这个项目里很花时间、但很值的一块。
而这恰恰也是 AI 发挥最大价值的地方。外部文章导入之后，经常会出现标题层级混乱、Pangu 空格缺失、公式格式不稳定、锚点失效、HTML 残留、图片引用不规范、中文和英文混排不自然等问题。很多问题并不难，但非常碎、非常耗时，也很适合让 AI 在明确规则下做逐项修复。
所以后来我甚至把这件事正式做进了仓库流程里，专门加了一个 copilot-fix-posts.yml 工作流，让 AI 按约束去修复导入文章。它不是一句模糊的“帮我润色一下”，而是非常工程化地要求它处理标题层级、Pangu、漏翻补翻、MDX 渲染、锚点修复、公式排版和 CI 校验。
4.3 把阅读体验做到顺手¶
当内容链路稳定之后，我就开始花更多精力打磨阅读体验。
现在文章页里我比较满意的部分包括：
- 自动目录和移动端目录入口。
- 阅读进度提示。
- 代码块复制。
- KaTeX 数学公式支持。
- Mermaid 图表支持。
- 图片点击放大、缩放、拖拽、移动端手势操作。
- 标签、分享按钮、相关文章、上一篇/下一篇。
- Giscus 评论区。
- 亮暗主题切换和主题持久化。
这里面有一些属于“好用”，也有一些属于“好玩”。
比如主题切换，我没有只做一个普通的明暗模式按钮，而是加了从按钮位置向外扩散的过渡效果；再比如文章图片预览，不只是简单弹层，而是把缩放、拖拽、滚动锁定、触控手势这些细节都补上了。它们不一定是博客的核心能力，但会让整个站点更有完成度。
这类交互细节也特别适合和 AI 配合。因为很多时候，难点不是“完全不会写”，而是边界条件太多，自己一个人来回试会很耗神。像图片预览、移动端 TOC、分享弹窗、主题切换状态同步这些功能，我更愿意把它们拆成很多可验证的小任务，让 AI 帮我快速试不同实现，再结合实际体验做收敛。
4.4 把工程化和自动化补齐¶
如果说前面几步解决的是“能不能用”和“好不好用”，那这一步解决的就是“能不能长期维护”。
我给这个项目补上了比较完整的工程化能力：
Vitest单元测试。Playwright端到端测试。astro check、格式检查、Markdown lint。- GitHub Actions 自动部署。
- 内容同步、外部导入、删除文章的工作流。
- 链接检查、部署后烟测、PR 预览站点。
这意味着现在很多原本需要手动做的事情，都可以通过脚本或者 workflow 来完成。
比如：
- 同步 Notion，可以自动生成内容并发起 PR。
- 导入外部文章，可以走统一脚本并保留图片和元信息。
- 删除文章，也可以通过工作流来做，避免手工误删。
- 每次提交后，站点构建、校验和测试都会跟上。
做到这里，我对它的感受已经不是“一个博客模板”，而更像是“我自己的内容工作台”。
也是在这一步，我开始更明确地把 AI 从“辅助问答工具”变成“流程里的执行者”。我不只让它写功能，也让它参与测试、修文、工作流设计和规则沉淀。这样项目越往后走，我和 AI 的协作方式反而越清晰，而不是越混乱。
五、构建完成后，现在这套博客是什么样子¶
如果从结果来看，这套博客现在已经具备了几个我很在意的特征。
第一，它是一个标准的静态站点，访问快，结构简单，部署轻量。
第二，它不是只有本地写作这一条路，而是支持多源内容进入同一套发布体系。
第三，它对技术内容很友好。代码、公式、图表、长文、目录、图片预览、评论、标签、分享，这些技术博客常见的需求都已经接住了。
第四，它不是“写完就算”，而是把同步、导入、构建、测试、部署都变成了可重复执行的流程。
第五，它不只是我一个人“手搓”的结果，而是我把 AI 真正纳入开发流程之后，一起迭代出来的产物。
如果只用一句话概括，我会说：它已经从“博客页面”变成了“AI 加持下的内容生产和发布系统”。
六、我最想重点介绍的，其实是这套工作流 / 流水线¶
如果只看页面，这个项目看起来像一个 Astro 静态博客；但如果从我真正每天怎么用它的角度看，它更像是一条围绕内容生产搭起来的流水线。
我现在的整体工作流，大概是这样的：
想法 / Notion / 外部链接 / PDF / 本地 Markdown
↓
scripts + GitHub Actions
↓
Markdown 清洗 / 图片本地化 / 元信息补齐 / AI 修文
↓
Pull Request
↓
validation.yml + pr-preview.yml + link-check.yml
↓
merge 到 main
↓
deploy.yml
↓
post-deploy-smoke-test.yml
↓
线上站点想法 / Notion / 外部链接 / PDF / 本地 Markdown
↓
scripts + GitHub Actions
↓
Markdown 清洗 / 图片本地化 / 元信息补齐 / AI 修文
↓
Pull Request
↓
validation.yml + pr-preview.yml + link-check.yml
↓
merge 到 main
↓
deploy.yml
↓
post-deploy-smoke-test.yml
↓
线上站点我很喜欢这条流水线的一个原因是，它把“写内容”和“发内容”从原来的手工动作，变成了一套可复用、可验证、可回放的流程。无论内容来自哪里，最后都会进入同一条发布链路。
6.1 原创内容的工作流¶
如果是我自己写的原创内容，最简单的一条路就是直接在本地写 Markdown，放进 src/content/blog/ 对应目录里。
这条路径通常会是这样：
- 先在本地起草文章，写 frontmatter、正文、标签和封面。
- 用
npm run dev本地预览版式、目录、代码块、公式和图片效果。 - 让 AI 帮我补结构、润色表达、检查标题层级、统一术语和补齐一些容易漏掉的细节。
- 再跑
npm run lint、npm run check这类校验，把问题尽量收在本地。 - 最后提交到仓库，进入 PR、校验、部署这条标准路径。
这条链路最重要的地方在于，它不是“写完就发”，而是天然带着预览、校验和收口步骤。这样文章质量会稳定很多。
6.2 Notion 到博客的同步流水线¶
如果内容是先写在 Notion 里的，我就不需要手工复制粘贴到仓库。
这里我搭了一条专门的同步链路：
- 先在 Notion 数据库里写内容，并把页面状态设成可发布。
- 通过
sync-notion.yml手动触发，或者等它每天定时执行。 - workflow 会运行
scripts/notion-sync.ts，把已发布页面转成 Markdown。 - 同步过程中会下载封面和正文图片，写入
public/images/notion/。 - Markdown 会再经过清洗、翻译、格式修正等处理。
- 如果有变更，workflow 会自动创建 PR，而不是直接往主分支硬推。
- PR 通过校验后自动合并，然后进入部署流程。
我很喜欢这种做法，因为它保留了 Notion 的写作体验，同时又保证了博客内容最终还是落在 Git 仓库里，有版本记录、有 diff、有 review，也有统一的发布出口。
6.3 外部文章导入的流水线¶
外部文章导入是这套系统里我花心思比较多的一块，因为这类内容的脏数据最多，也最容易把人拖进重复劳动里。
现在这条链路大概是这样：
- 手动运行
import-content.yml，或者本地执行npm run import:content -- --url=...。 - 脚本根据 URL 选择适配器，接入知乎、微信、Medium、PDF 或其他来源。
- 如果是 PDF，还会走 OCR、图片提取和 Markdown 转换流程。
- 导入过程中会补 frontmatter、下载图片、必要时抽首图做封面。
- 然后统一走 Markdown 处理管线，清理代码围栏、公式、列表、空行、语言和结构问题。
- 最终把内容落到
src/content/blog/，把资源落到public/images/。 - 如果有改动，再自动创建 PR，进入后续验证和部署。
这个设计让我最省心的一点是，不同来源虽然很乱，但在进入站点之前，都会被先收敛成同一种“博客制品”：Markdown + 本地图片 + 规范 frontmatter。后面的渲染层就不需要知道它原来来自哪里。
6.4 AI 在流水线里的位置¶
对我来说，AI 最有价值的时候，不是在最前面“凭空生成一个系统”，而是在流水线中间当一个高效率的修复层和实现层。
我现在大概会把 AI 放在两个位置：
第一类，是功能开发阶段。
- 我先定义目标、边界和验收标准。
- 让 AI 先读仓库、读文档、读已有实现。
- 再让它做一个具体而小的改动，比如分享弹窗、图片预览、目录交互、Mermaid 修复。
- 最后我再根据测试结果和实际体验收口。
第二类，是内容处理阶段。
- 导入文章之后，很多问题其实是重复性的脏活。
- 这时候 AI 很适合做标题层级修正、中英混排清理、公式格式调整、锚点修复、漏翻补翻、MDX 渲染修复。
- 我后来甚至把这件事正式做进了
copilot-fix-posts.yml，让 AI 不只是“帮我润色”，而是在明确约束下参与内容修文。
这也是为什么我会说，这个项目不是“AI 帮我写了个博客”，而是我把 AI 放进了一条真正可运行的工作流里。
6.5 验证、预览和发布的流水线¶
当内容或代码进入仓库之后，后面的流程我也尽量做成自动化。
这里最核心的几条 workflow 是：
validation.yml：负责check、lint、分层规则检查、单测、构建和 E2E。pr-preview.yml：给 PR 构建预览站点，并把预览链接评论回 PR。link-check.yml：在 PR、push 和定时任务里做死链检查。deploy.yml：主分支变更后自动构建并发布到 GitHub Pages。post-deploy-smoke-test.yml：部署完成后，再对线上页面做一轮烟测。
这条链路让我最安心的地方是，发布不再是“我感觉应该没问题了”。它变成了一套有门禁、有预览、有线上回查的流程。
尤其是 post-deploy-smoke-test.yml 这一层，我自己很喜欢。很多项目做到部署成功就结束了，但博客这种面向读者的内容站，真正重要的是“线上是不是正常”。所以我又补了一层部署后验证，确保首页、归档页、文章页、RSS、Sitemap 这些关键入口在线上确实可用。
6.6 删除和回收，也是流水线的一部分¶
除了写和发，删除文章这件事我也不想靠手工硬删。
所以仓库里还有 delete-article.yml 这条工作流，它会根据 slug 或路径删除文章，并且可选删除关联图片。这样做的好处是，连“删除”这件事也是有记录、可预览、可审计的，而不是直接在仓库里手动删文件。
6.7 为什么我会越来越喜欢这套流水线¶
因为它把博客这件事从“偶尔写篇文章”变成了“一个持续运转的系统”。
对我来说，这套工作流最重要的不是自动化本身，而是它带来的几个变化：
- 内容入口虽然很多，但最后都进入同一条标准链路。
- AI 不是漂浮在流程之外，而是被放进明确的位置里。
- 所有关键动作几乎都可以回放、复查、审计和迭代。
- 发布质量不靠记忆和经验，而是靠脚本、校验和 workflow 去兜底。
这也是为什么我现在回头看，会觉得自己真正搭起来的不是一个博客首页，而是一条属于自己的内容生产流水线。
七、我具体是怎么用 AI 来构建它的¶
这部分可能是我自己最想分享的。
过去大家经常会把 AI 用在“问个问题”或者“生成一段代码”上，但这次我更明显地感受到，真正高杠杆的用法，是把 AI 当成一个可以被约束、可以被验证、可以持续复用的 agent。
我大概会这样使用它：
7.1 先让 AI 建立真实上下文，而不是空想¶
我不会直接丢一句“帮我做个功能”。更有效的方式是先让它读仓库结构、读 README、读 docs/architecture.md、读 scripts/README.md、读 package.json，先理解项目边界再动手。
这样做的好处是，AI 给出的方案会更贴近现有仓库，而不是凭空起一个“看起来也能跑”的新体系。
7.2 把任务拆小，让 AI 做可验收的子问题¶
比如我不会一次性让 AI “重构整个博客”。我更倾向于拆成：
- 让它补一个文章分享弹窗。
- 让它修一个移动端 TOC 的滚动问题。
- 让它处理 Mermaid 渲染异常。
- 让它修导入文章里的标题锚点和 Pangu 空格。
这样每一步都可以单独 review、单独测试，也更容易发现问题到底出在哪。
7.3 让 AI 去处理高重复度的脏活¶
内容系统最烦的，往往不是写一个页面，而是后面的各种清理、对齐、补齐、修边角。
例如：
- 导入文章后的 Markdown 清洗。
- 中英混排、标题层级、公式格式、锚点统一。
- 图片路径和 frontmatter 的规范化。
- 大量小范围 UI 调整和回归修复。
这些工作单个看都不大，但总量非常可观。AI 在这里的价值非常明显，它能把很多重复劳动变成更稳定的流水线。
7.4 用规则约束 AI，而不是只靠感觉¶
这个项目里一个很重要的变化是，我开始把对 AI 的要求写成仓库规则。
比如仓库里后来加了 SKILL.md，明确要求 agent 先基于真实代码建立事实、遵守分层边界、做最小改动、跑 npm run check、npm run lint、npm run test、npm run test:e2e 这些质量门禁。
这件事的意义很大，因为它意味着 AI 不再只是一个“聊天对象”，而是开始被纳入一个有约束的工程流程里。
7.5 最终判断始终由我来做¶
这一点我觉得也很重要。
AI 能大幅提升速度，但架构边界、产品取舍、体验判断、哪些改动该保留、哪些实现只是“看起来能跑”，这些最终还是要我自己来负责。
所以更准确地说，这个项目不是“AI 帮我写了一个博客”，而是“我学会了如何把 AI 用成一个真正有产出的开发搭子”。
八、从 Git 历史里能看到，AI 已经成了流程的一部分¶
如果回头翻这个仓库的提交记录，其实能看到一条很清晰的线。
2026-01-26，仓库加入了copilot-fix-posts.yml，开始把 AI 用到导入文章修复这件事上。2026-01-27，又连续补了 prompt 细节和中英混排规则，说明我已经不满足于“能用”，而是在不断把 AI 的执行标准工程化。2026-02-12，这个 workflow 还在继续调整，说明它不是一次性尝试，而是真的被纳入日常流程。2026-03-03，仓库新增并更新了SKILL.md，开始从仓库层面约束 agent 怎么读文档、怎么做最小改动、怎么过 CI。
这条时间线对我来说很有意思。它说明 AI 在这个项目里并不是一个“锦上添花”的聊天工具，而是慢慢从临时帮手，变成了一个正式参与构建流程的角色。
再看后面的提交，也能感受到这种协作方式带来的节奏变化：图片预览、分享弹窗、主题切换、Mermaid、slug 去重、内容修复、锚点统一，这些功能和修复是以很多次小步迭代推进出来的。对我来说，这种高频、小步、可验证的迭代方式，正是 agent coding 最舒服的用法。
九、这次我最想分享的几个好用、好玩的点¶
9.1 把 AI 工作流显式写进仓库¶
这可能是这次项目里最让我有感的一点。
我不是只在本地开着一个聊天窗口写代码，而是把 AI 明确接进了仓库流程里：有专门的 Copilot 修文 workflow，也有专门约束 agent 行为的 SKILL.md。当这些东西进入版本库之后，AI 协作就从“个人习惯”变成了“项目能力”。
9.2 把运行时和内容获取彻底分开¶
这是我觉得最值得保留的一个决定。
很多内容站一开始为了快，直接在构建时拉数据，短期很省事，但后面会越来越难维护。我这套博客里，外部内容先通过脚本预处理成 Markdown 和本地图片，再交给站点渲染，这让整个系统边界很清楚。
9.3 用适配器思路接入不同内容源¶
知乎、微信、Medium、PDF 这些来源本身差异很大，但我尽量把它们收束到统一的导入流程里。这样以后如果还想接更多来源，心智负担会小很多。
9.4 配置集中化真的能减少很多摩擦¶
站点信息、首页配置、主题、布局、导航、排版都独立出来之后，维护体验会明显轻松。很多时候，一个项目越往后越不是“代码难不难写”，而是“改一个小地方要不要翻半天文件”。
9.5 把自动化做进内容工作流，而不只是做进代码工作流¶
这一点我自己很喜欢。CI 不只是跑测试、做部署，它也直接参与内容同步、文章导入、文章删除这些操作。对博客这种长期写作项目来说，这种自动化比单纯把页面做漂亮更重要。
9.6 一些偏交互的小细节很能提升完成度¶
比如主题切换转场、图片 lightbox、移动端目录、代码复制、分享弹窗，这些都不是“没有就不能用”的功能，但它们会让整个博客更像一个认真打磨过的产品，而不是简单套了个模板。
十、过程中踩过的几个坑¶
这个项目不是一路丝滑做下来的，过程中也踩了不少坑。
最明显的一类问题，是外部内容的格式并不可靠。很多文章导入之后，真正麻烦的不是“抓下来”，而是怎么让它稳定渲染：标题层级、代码围栏、数学公式、HTML 实体、图片路径、中文排版、锚点、MDX 兼容，这些地方都很容易出小问题。
第二类问题，是交互细节。像目录滚动、移动端适配、图片拖拽缩放、主题切换状态同步，这些功能看着不大，但很吃细节，一旦处理不好，体验会明显掉一截。
第三类问题，是系统一旦变完整，就需要更强的边界意识。脚本层、运行时、配置层、内容层如果混在一起，后面会非常难收拾。所以我后来越来越重视目录结构、职责分离和测试覆盖。
还有一个很现实的坑，是怎么避免自己把 AI 用成“看起来很快，实际上越写越乱”的工具。越到后面我越清楚，AI 不是放任它自由发挥就行，反而越需要清晰上下文、明确边界和严格验收。不然它确实可以帮你写很多东西，但也可能帮你把项目带偏。
十一、最后的感受¶
做完这个项目之后，我最大的感受是：博客系统真正难的地方，不是把页面写出来，而是把“内容如何进入系统、如何被处理、如何稳定发布”这条链路设计清楚。
页面只是最后呈现出来的那一层。真正让这件事变得长期可用的，是内容流、工程化、自动化，以及你怎么把 AI 合理地放进这个闭环里。
对我来说，这次构建更像一次很完整的系统设计练习。我一边在做一个博客，一边也在回答几个更底层的问题：什么样的结构更容易长期维护，什么样的边界更适合扩展，什么样的自动化才能真正帮人省时间，什么样的协作方式能让 AI 真正成为生产力，而不是噪音。
如果后面我还会继续迭代它，我大概率还是会沿着这条路往前走：让它保持静态站点的轻，同时慢慢长出更完整的内容能力，也继续把 AI 更自然地接进内容修复、功能开发和工程治理里。
如果你也在做自己的技术博客，我很推荐把它当成一个长期项目来做。更推荐的一点是，不要只把 AI 当成“问答工具”，而是试着把它纳入你的真实工作流里。因为当博客不只是一个页面集合，而是一套真正服务于表达和积累的系统；当 AI 也不只是一个聊天框，而是一个被约束、被验证、能稳定协作的 agent，整个构建过程真的会顺手很多，也有意思很多。
这套博客系统已经完全开源在 GitHub：
https://github.com/yuanlehome/blog
如果你也在做自己的博客系统、内容流水线，或者也在尝试把 AI agent 接进真实开发流程，欢迎直接参考这个仓库。
如果你在使用过程中发现问题，或者对工作流、内容导入、AI 修文、页面交互这些部分有新的想法，也欢迎提 issue 或者直接发 PR 一起交流。