建这个网站的初衷非常明确：我需要一个能无缝同步、展示我 Obsidian 本地笔记的云端外脑，并且要完全掌握它的数据流向和排版主权。
在这个工程里，我几乎没手写什么代码。AI 是我的外包团队和执行器，而我负责系统架构、需求定义和边界约束。事实证明，“用自然语言指挥 AI 编程”远不像网上吹的那么神乎其神，它充满了混乱、耦合与失控。
1. 消除混沌：解耦本地与云端的环境污染
AI 写代码最大的问题，是它只对你当前的那句话负责，缺乏全局的系统观。
一开始，我让 AI 帮我配置 Obsidian 的本地环境，接着又让它写云端部署的 Git 脚本。结果两者一结合，Obsidian 自动生成的底层配置文件（.obsidian）和前端框架的编译产物直接在 Git 树里引发了毁灭性的冲突。本地笔记一多，甚至会导致推送到云端时频频报错。
在几万字的排错拉扯后我才意识到，不能指望外包（AI）帮你统筹全局。作为项目主导者，我必须自己划定物理隔离的边界——通过反复测试 .gitignore 的黑名单和“双 Vault（知识库）”策略，我像做切除手术一样，强行解耦了“本地写作环境”和“云端编译环境”，确保推送到服务器的每一行数据都是干净的纯文本。
2. 工程妥协：接受不完美，但要绝对控制权
在处理文章排版时，我深刻体会到了什么叫“历史包袱”。
我选定的前端主题（PaperMod）自带了一套极其顽固的底层样式。为了在我的每篇笔记底部加上一个严格左对齐的版权说明卡片，AI 给了我很多优雅的外部 CSS 引用方案，但每次都会被主题本身的设定挤得面目全非。
最后我拍板：放弃优雅。直接用最高优先级的内联 style 属性去暴力覆写它的 DOM 节点。从软件工程的角度看，这叫严重耦合，未来主题大更新可能会乱码。但从落地解决问题的角度看，这是在有限时间内，夺回页面绝对控制权的最优解。能跑通的烂代码，好过一直报错的优雅架构。
3. 数据管线：从本地文本到标准路由的映射
一键部署的网站往往忽略了数据结构。在 Obsidian 里，笔记按文件夹组织；但到了 Web 端，如果不做干预，中文文件名的笔记在浏览器里会变成一长串乱码 URL（像 %E4%B8... 这样），这对于强迫症和搜索引擎来说是毁灭性的。
我和 AI 花了很长时间去规范 Markdown 的 Front Matter（元数据）和 Slug（永久链接）策略。这不是在写前端页面，而是在定义数据接口。我规定了每篇笔记在推送到云端前，必须经过这套规范的处理。这就好比控制系统中的信号调理——把本地非标的笔记文本，转换成了云端路由系统能精准识别的标准化数据包。
总结
这份建站记录，本质上是一个闭环控制过程：输入自然语言指令 -> 观察 AI 的输出与报错 -> 调整系统边界条件 -> 再次输入。
比起学会了某句具体的 CSS 怎么写，这几天最大的收获，是验证了我能把一个“无缝发布 Obsidian 笔记”的非标需求，拆解为 AI 能听懂的工程约束，并最终拼装成一个稳定运行的自动化系统。这对跨专业的我来说，是一次必要的思维验证。
接下来的 Log 系列，我会把这个从本地到云端的过程中踩过的几个典型的坑，逐一归档。
Comments & Reactions