为什么个人网站还需要编辑器
AboutQ 提供了一套固定的页面框架，但内容会不断变化：补一段项目反思、换一张图片，或者整理一篇新的探索文章。如果每次更新都要进入页面代码，写作就容易被布局和实现细节打断。
我希望自己能打开一个界面直接写，也能把整理、改写和生成初稿交给 AI，最后回到同一份内容上检查。于是，除了面向访客的阅读动线，网站还配有本地内容 Studio。
GUI：把写作和预览放在一起
Studio 采用三栏布局：左侧选择和管理条目，中间修改标题、摘要、状态与 Markdown 正文，右侧查看预览。写作者可以在详情预览和主页卡片预览之间切换，检查一段内容进入网站后如何呈现。修改需要主动保存，保存时会校验内容并保留历史快照。
页面的字体、间距和响应式由模板统一处理。编辑器负责内容、顺序、精选与已注册的视觉样式，让我可以集中精力写清楚项目，而不必为每篇文章重新排版。正文仍是 Markdown，个人资料与首页文案保存在站点配置中。
草稿、已发布和隐藏状态用于区分内容的准备程度。公开构建只读取已发布条目，首页作品精选另外设置。这样可以先把想法放进编辑器，再决定何时让它进入公开页面。
CLI：让 AI 也能使用这套内容框架
图形界面适合逐篇书写和看效果，命令行适合把明确的修改交给脚本或 AI 代理执行。AboutQ 为此提供内容 CLI：读取条目、查询内容规则、提交更新和执行校验，都有对应命令；结构化结果让调用方能够判断操作是否成功，以及哪里需要修正。
例如，我可以让 AI 先读取一篇作品的现有内容，根据我补充的材料生成修改稿，再通过 CLI 提交更新计划。写入命令默认只展示计划，显式加入 --apply 才会落盘。之后我回到 Studio 检查正文和卡片，调整措辞，再决定是否发布。
这里的 AI 协作依靠外部 AI 代理使用文件和 CLI，Studio 本身没有内置聊天窗口。生成初稿、整理已有材料和修改条目可以接入这条流程，生成后仍需核对项目事实与公开范围。
GUI 与 CUI / CLI 共用一份内容
我把它看作一次面向 AI 协作的界面设计尝试：GUI 给人提供可见的编辑与预览，CLI 给 AI 和脚本提供明确的操作入口。如果把对话视为 CUI，那么我向 AI 描述意图，AI 再借助 CLI 操作内容；对话入口在外部工具中，网站提供的是可被调用的内容能力。
这几个入口最终处理同一份 Markdown 和站点配置，并复用内容校验规则。人手动改过的文章可以继续交给 AI 整理，AI 更新后的内容也能回到 GUI 中查看，不需要维护两套稿件。
这套分工的价值在于衔接：用自然语言表达想改什么，用明确的命令落实修改，再通过页面预览判断结果是否合适。它是我在个人网站上的实践，还不能据此证明适用于所有内容工具。
保存、检查与发布分开
内容工具提供格式校验、写入冲突检测、可恢复归档和最近 20 个保存前快照，帮助发现错误或找回之前的内容。它们不能判断一段叙述是否准确，也不能替代对 AI 修改稿的阅读。
Studio 只在本机运行，保存只修改本地文件。公开网站提供构建后的静态页面，编辑器和写入接口不进入公开构建。写完、检查通过和发布到线上是不同动作，让内容整理可以在本地反复进行。