这批 Obsidian 笔记里，有一组内容看起来和 SEO、建站、冷启动不太一样。
它们在讲 AI 编程、Skill、Hermes、OpenClaw、Discord、Claude Code、AI 原生公司、知识库和工作流。
但我整理完以后发现，这组内容其实是所有建站和内容工作的底层。
因为一个人想长期做项目，最缺的不是灵感。
最缺的是一个不会因为聊天窗口关闭就失忆的工作系统。
聊天不是工作流
我以前很容易把 AI 当成聊天框。
想到什么就问，卡住了就问，问完继续干。
这当然有用，但它有一个致命问题：
上下文会散。
今天在一个窗口里讨论的判断，明天换个窗口就丢了；今天让 AI 修过的坑，下次又踩；今天总结的经验，没有进入文档、脚本、模板或 Skill，就等于没有沉淀。
所以 Agent 工作流的第一原则应该是：
聊天只是交互界面，文件才是长期记忆。
这也是为什么我现在更愿意用 Obsidian、GitHub、HOCweb、Skill 和博客来承接输出。
它们比聊天窗口慢一点，但能留下来。
Skill 是把经验变成默认动作
“我写了半年 skill，直到上周才意识到自己从一开始就搞错了方向”这类笔记给我很大提醒。
Skill 不应该是把一大堆废话塞给 AI。
好的 Skill 应该做三件事：
- 触发场景清楚：什么时候该用它。
- 工作流清楚：第一步、第二步、第三步怎么做。
- 质量门清楚：做到什么程度才算完成。
它不是知识百科。
它更像一个会被 Agent 读取的 SOP。
比如今天新整理出来的 Obsidian 工作流，就应该变成一个 Skill：
本地笔记不是直接发博客，而是先变成知识点，再变成 evidence digest，再交给写作 Skill，最后进入博客 MDX 和构建检查。
这就是经验变成默认动作。
Agent 要有角色，不要一锅粥
Discord + Hermes + OpenClaw 那组笔记，核心不是“用 Discord 很酷”。
核心是角色分工。
一个能跑项目的 Agent 系统，至少要分清：
- 谁接收人的需求；
- 谁做市场和浏览器观察；
- 谁写代码；
- 谁验证结果；
- 谁更新文档；
- 谁决定是否发布；
- 谁在失败后修改流程。
如果所有 Agent 都能随便发言、随便决策、随便改代码，最后就会变成一锅粥。
更好的结构是：
- Hermes 做入口、判断、状态和质量门；
- OpenClaw 做云端浏览器、运行时、市场和独立验证；
- Claude Code 做实现、测试和构建；
- Codex 做维护者和本地收口，不进入日常生产循环；
- 人只批准凭据、域名、付费、法律和敏感发布。
这套分工看起来麻烦，但它能减少混乱。
因为每个角色都知道自己不该做什么。
固定入口比多渠道热闹更重要
我之前会纠结 Telegram、Discord、本地、VPS、网页控制台到底用哪个。
现在的判断更简单：
日常只要一个入口。
入口可以是 Telegram，也可以是 Discord，但必须有一个地方负责收口。
否则事情会散在很多地方：
- 一个想法在 Telegram；
- 一个决策在 Discord；
- 一段代码在 Claude Code；
- 一个 bug 在 Codex；
- 一篇文章在 Obsidian；
- 一个部署记录在 VPS；
- 最后谁也不知道项目状态。
所以 HOCweb 里“Hermes 是唯一日常入口”这个规则很重要。
不是因为 Hermes 神奇。
而是因为项目需要一个地方记录状态。
AI 原生公司，本质是可读、可查、可反馈
AI 原生公司的笔记让我想到一个很朴素的判断：
未来很多公司不是因为用了多少 AI 工具而变强，而是因为它们的工作过程能被 AI 读懂。
如果客户反馈只在人的脑子里，AI 用不了。
如果会议结论只在聊天记录里，AI 用不了。
如果项目状态没有文件，AI 用不了。
如果失败复盘没有沉淀成检查表，AI 下次还是会犯。
所以 AI 原生不是“买几个模型账号”。
而是让公司变成：
- 可记录；
- 可检索；
- 可复用；
- 可验证；
- 可自动化；
- 可复盘。
对我个人来说也是一样。
我的小项目、博客、技能、VPS、Agent、Obsidian，都应该朝这个方向走。
Claude Code 适合做执行，不适合替我决定方向
AI 编程笔记里有一个反复出现的坑：让 AI 直接写完整项目。
这样很容易失败。
因为 AI 不知道我真正要取舍什么，不知道哪些功能现在不该做，也不知道这个项目的商业优先级。
更好的方式是：
人给清楚的 build brief。
Claude Code 做实现。
OpenClaw 或浏览器验证做独立检查。
Hermes 或人做最终判断。
这和公司里的角色分工很像。
工程师可以提出方案，但不应该独自决定业务方向；产品可以定义目标，但不能假装代码自动正确；测试可以发现问题，但不应该替代上线判断。
Agent 也一样。
Obsidian 应该变成燃料，不是仓库
这次全库整理让我意识到，Obsidian 最大的问题不是笔记少，而是笔记太容易堆成仓库。
仓库很有安全感。
但项目不会因为仓库变大而自动前进。
所以 Obsidian 以后应该承担三个角色：
- 临时收集原料。
- 定期整理成知识点。
- 进入 Skill、文章、SOP、检查表或项目任务。
只有第三步发生，笔记才真的被吸收了。
否则只是换了一个地方收藏网页。
今天把 90 篇笔记重新整理成文章，就是一次强制吸收。
我的个人 AI 工作系统应该长这样
整理完这组笔记，我希望未来的工作流是：
- Obsidian 收集材料。
- Obsidian workflow skill 把材料变成知识点和 evidence digest。
- khazix-writer 把 digest 写成可发布文章。
- shipany-blog 承接公开内容。
- HOCweb 承接项目任务和运行状态。
- Hermes 作为日常入口和决策记录者。
- OpenClaw 做云端观察和验证。
- Claude Code 做实现。
- GitHub private repos 保存每次变更。
- 每次提交必须写更新说明和敏感数据检查。
这不是为了仪式感。
是为了减少我反复从零开始的次数。
最后
AI Agent 最大的误区，是把它想象成一个更聪明的聊天对象。
但我现在更愿意把它看成一套工作系统里的不同岗位。
聊天只是入口。
真正重要的是：任务有没有落到文件，判断有没有留下，失败有没有变成检查项，经验有没有变成 Skill，代码有没有验证，发布有没有记录。
如果这些都没有，AI 再聪明，也只是陪我聊了一场。
如果这些都有，哪怕每一步都很朴素，系统也会一点点变强。
这才是我现在最想搭的东西。
