我很喜欢用 AI 帮忙写东西，但我越来越不把它当成“按一下按钮就能交稿”的机器。它更像一位速度很快、点子很多的协作者：可以帮我拆题、列提纲、发现遗漏，也可以把一段杂乱的笔记整理成顺畅的初稿。真正决定文章能不能发布的，仍然是我有没有把目标、上下文和复核标准说清楚。

一套稳定的工作流，重点不在于记住某个神奇提示词，而在于把每次协作拆成几个可重复的阶段。

先说清楚要交付什么

“帮我写一篇文章”太宽泛，模型可以给出一篇看起来完整、却不一定适合发布的文字。更好的起点是先定义交付物：

  • 文章写给谁，读者已经知道什么；
  • 文章要解决哪个具体问题；
  • 需要教程、复盘，还是观点整理；
  • 最终要落成什么格式，例如 Hexo Markdown；
  • 哪些内容必须由人确认，哪些内容可以让模型自由发挥。

我通常会先写一段任务说明，再让 AI 复述它理解的目标。如果复述已经偏了，越早纠正，后面返工越少。

把上下文切成可控的小块

上下文不是越多越好。把整个仓库、所有历史对话和一堆无关资料一次性塞进去，反而容易让重点消失。我更愿意按“项目背景、当前文件、明确约束、验收标准”四块提供信息。

例如写博客时，背景可以是 Hexo + Butterfly，当前文件是文章模板和内容规范，约束是不能泄露密钥、不能直接改主题源文件，验收标准是 front matter 完整、命令可复现、链接能生成。这样模型得到的是一张清晰的地图，而不是一间堆满纸张的房间。

如果任务变大，我会把它拆成“提纲—一节正文—校对—落盘”几步。每一步只解决一个问题，输出更容易检查，也方便我在中途调整方向。

让 AI 发散，再由人收敛

我会把创意阶段和定稿阶段分开。创意阶段可以让模型提供多个标题、段落顺序和例子；定稿阶段则给出明确的语气、篇幅和事实边界，并要求它标出需要我确认的地方。

这里有一个很重要的分工：AI 可以帮我组织表达，但不能替我承担事实责任。涉及版本号、命令参数、服务地址、法律条款或当前状态的内容，我会回到项目文件、官方文档或实际命令输出中核对。文章写得再流畅，事实错了仍然是错的。

我也会主动删掉那些“听起来正确”的空话。个人博客的价值不在于把常识重新包装一遍，而在于记录我真的做过什么、为什么这样做，以及哪里仍然有取舍。

把草稿变成可维护的 Markdown

当正文通过人工复核后，我才把它放进仓库。落盘时先写 front matter，再写正文，最后检查文件名、链接和代码块。对 Hexo 来说，这些元数据不是装饰，而是文章能否被归档、检索和持续修改的一部分。

我会逐项检查：

  1. 标题、日期、更新时间和描述是否完整；
  2. 分类是否属于现有栏目，标签是否足够简洁；
  3. 站内链接是否使用稳定的文章路径；
  4. 命令是否与仓库中的脚本名称一致；
  5. 示例是否可以被读者理解，而不依赖我的个人账号。

最后再运行仓库的内容检查和本地构建。这样，AI 参与的是写作过程，最终结果仍然接受项目本身的约束。

隐私边界要提前画出来

任何协作工具都不应该成为秘密的中转站。服务器密码、私钥、访问令牌、未公开的个人信息，都不应该粘贴进提示词，也不应该出现在文章、终端截图或提交记录里。需要描述部署时，只写环境变量名称和作用，用占位符表达路径。

如果一段日志里混有敏感内容，我会先脱敏，再把最小必要片段交给模型。能不提供的上下文就不提供；能用本地脚本验证的，就不让模型猜。

一个可复用的请求模板

我常用下面的结构开始一次写作协作：

目标：把这段经历整理成一篇给开发者看的中文技术随笔。
背景：项目使用 Hexo + Butterfly，文章会进入 source/_posts。
约束：不虚构命令，不泄露任何秘密，保留个人判断。
输出：先给提纲，再写正文；需要我确认的事实单独列出。
验收：front matter 完整，段落清楚，读者能照着复现关键步骤。

这段模板并不神奇，但它把“想写什么”和“怎样才算完成”放到了同一张纸上。

小结

AI 最适合放大已经存在的思考，而不是替代思考。把任务说清楚、把上下文切小、把事实留给人工核对，再把结果落成遵守仓库规范的 Markdown，创作速度和内容质量才会同时提高。

如果你想先了解文章如何稳定发布，可以阅读Hexo + Butterfly 的低风险发布流程；想把这套习惯延伸到更多个人项目，再看用检查、构建和部署守住可复现。