整体工作流

NeuroStack 的目标不是再做一个“写文章工具”，而是把个人知识库变成 AI 可以长期协作的工作台。

整个流程可以理解为两层：第一层是一个稳定的公开 Wiki 基础设施，第二层是一个告诉 AI 如何写入这个 Wiki 的 skill。基础设施负责把文件变成网页，skill 负责让 AI 知道什么时候该保存、保存到哪里、写成什么样、发布前要检查什么。

先搭好 Wiki 基础设施

NeuroStack 使用 Astro 和 Starlight 把 Markdown 文件渲染成网页，再用 Vercel 托管到 chenzeqing.cn。

这意味着一篇文章的源头就是一个普通 Markdown 文件。它不是存在某个复杂后台里，也不依赖特殊编辑器。只要文件进入仓库，构建通过，Vercel 就能把它变成公开网页。

发布链路是：

Markdown 文章
  -> Git 仓库
  -> GitHub Actions 构建检查
  -> Vercel 部署
  -> chenzeqing.cn 上的网页

这套链路的价值在于稳定和可追溯。每次新增文章都会留下 Git 记录；如果构建失败，文章不会直接进入线上站点；如果线上出现问题，也能回到具体的 commit 查看发生了什么。

再给 AI 一份操作说明

只有基础设施还不够。AI 需要知道这个知识库的规则，否则它可能会把文章放错目录、标题写得太长、内容写得像宣传稿，或者忘记发布前检查。

所以 NeuroStack 另外维护了一个全局 skill：

~/.codex/skills/personal-wiki-publish/

这个 skill 相当于一份给 AI 的工作说明。它告诉 AI：

• 什么内容值得保存到 Wiki。
• 普通文章应该写 Markdown。
• 应该优先放进现有分类，不合适时再新建分类。
• 标题要短，正文要直接，默认使用中文。
• 发布前必须运行构建检查。
• 只有用户明确要求发布时，才提交、推送并等待线上部署完成。

对用户来说，这就像给 AI 配了一位熟悉家里书架规则的整理员。你不需要每次都重复“文件放哪里、格式怎么写、怎么上线”。只要告诉 AI “这段内容保存到笔记里”，AI 就会按 skill 的规则完成后续工作。

为什么 Skill 能让 AI 直接发布文章

AI 本身会读写文件、运行命令、查看构建结果。Skill 的作用不是替代这些能力，而是把这些能力限制在正确流程里。

没有 skill 时，AI 只能根据当前对话临时判断。它也许能写一篇文章，但不一定符合这个仓库的长期约定。

有 skill 后，AI 会先读取固定规则，再执行固定流程：

判断内容是否值得保存
  -> 选择合适分类
  -> 写 Markdown 和 frontmatter
  -> 检查链接、标题和公开边界
  -> 运行 npm run build
  -> 用户要求发布时提交并推送
  -> 等待 GitHub Actions 和 Vercel 完成
  -> 检查线上页面

这就是“AI 可以直接发布到 Wiki”的原因：不是因为 AI 绕过了工程流程，而是因为 Wiki 的工程流程足够清晰，skill 又把这套流程写成了 AI 每次都能遵循的操作规则。

用户实际看到的体验

理想使用方式很简单：

“把这段经验保存到 Wiki 里。”

AI 接下来应该做的是：

1. 判断这段内容属于哪个知识主题、其他，还是需要新分类。
2. 用短标题和清晰描述写成 Markdown。
3. 避免把临时聊天语气、重复背景和敏感信息写进公开页面。
4. 本地构建验证。
5. 如果用户要求发布，就推送并确认线上可访问。

用户不需要关心 Astro、GitHub Actions、Vercel token、frontmatter 或目录配置。那些是基础设施和 skill 共同承担的部分。

这套方式适合什么

它适合沉淀长期可复用的内容，例如：

• 主题经验复盘。
• 技术选型记录。
• 工具使用经验。
• 工作流说明。
• 复杂页面或图解入口。

它不适合直接保存私密信息。仓库虽然是 private，但部署到 Vercel 的页面是公开的。任何准备进入 Wiki 的内容，都应该默认按公开内容处理。

核心价值

NeuroStack 把“保存知识”拆成了两件事：

• Wiki 基础设施保证内容能稳定上线。
• Skill 保证 AI 每次都按同一套规则写作和发布。

这样一来，个人知识库不再依赖某一次对话里的临时记忆，而是变成一套可重复、可检查、可长期维护的系统。