对 AI 辅助写作的一点小感想

Cover Photo 引自 Unsplash。

最近尝试了在 GPT + Codex 的辅助下写博文 —— 虽然这的确有点违背我写博客的初衷， 但是这至少让博客没有荒废不是吗。 最终的成品就是《macOS Photos 导入照片日期错误：最后竟是 12/24 小时制的问题》和《我做了一个自动化求职系统》两篇。先说我的评价：

  • 第一篇其实还不错，因为有更清晰的时间线和排障流程
  • 第二篇有点一言难尽

这其实能反映一点我对现阶段 AI 辅助写作的感受：先进 LLM 的上下文绝对比一般人类要长，但是这么长的上下文也会带来一些问题。

Pros：它真的…很全

这其实从第一篇博文里能很好地反映出来。我准备第一篇博文的完整流程其实是：

  1. 首先使用我过去的所有博文和推文内容蒸馏了一个 $clementine-perspective Skill，使用 Codex 配合 女娲.skill 完成。这一 Skill 用于调整后续模型写作时的行文逻辑和表达方式。
  2. 我是在与网页端 GPT 的 Chat 中一步步解决问题的。因此我在 Chat 最后提出了以下 prompt：

    给我一份完整的复盘报告，包含所有你搜索的资料及其来源。

  3. 将这份复盘报告交给本地 Codex 代理，然后再给出如下的 prompt：

    以上是一份完整的、关于一个我在 macOS 上已经遇到好几年的 bug 的排障复盘报告。你需要完整阅读其内容，并调用 $clementine-perspective 将其转化为一篇技术类博文。具体要求是：

    • 必须实际调用 $clementine-perspective，必须符合我的写作风格、表达方式等特征。
    • 博文内容体现 GPT 在搜索资料，尤其是提到一个有关时间日期设定页面的帮助，具体上下文可参考 @Mac iCloud 照片时间戳问题。
    • 尽可能完整地涵盖复盘报告的内容，仅删去一部分与核心问题完全无关的内容（如十一、十二部分）；但不一定要遵循其结构，可以考虑以第一人称视角参考上述对话来体现发现并解决问题的过程。
    • 博文标题自拟，需要同时考虑 SEO（帮助遇到类似问题的其他用户）、可读性，不能过长。
    • 注重严谨性，给出所有必要的引用资料。
  4. Codex 最终生成了完整的博文。

原文对应的内容是一个高度流程化、具有明确时间线的故障排除经历。GPT 在处理这种大量信息时表现得尤为突出 —— 如果让我亲自完成原文这么多的查证和引用，可能要花上一两天的时间。相反，行文结构和逻辑在这里却没有那么重要 —— 只要简单遵循我和 GPT 进行故障排除的时间序就好了。最后的博文的确很完整、很全面、 像论文一样引用各种资料， 呈现出的效果也不错。

Cons：它是不是有点…太全了？

但这恰恰也是第二篇文章我觉得不尽人意的地方 —— 普通人类的 context window 其实没有 GPT 那么长，因此让 GPT 进行泛化写作任务时，它往往写得毫无重点。

这一次我给 Codex 的 prompt 是：

所提供的 JobSeek 是一份完整的自动化求职工作目录，其中包含了已有批次和一个已经存在于 GitHub 上的 jobseek-template 模版目录。你需要先检查其结构、历史和相关规则文件。随后，我需要你调用 $clementine-perspective，以我的风格完成一篇博客文章，具体要求：

  • 必须实际调用 $clementine-perspective，必须符合我的写作风格、表达方式、行文逻辑等特征。
  • 浏览 @优化职业规划策略 相关内容作为行文参考。
  • 博文标题参考《我做了一个自动化求职系统》，可结合实际小幅度调整。
  • 博文内容体现 JobSeek 目录的设计、逻辑和已有成果，但不得包含任何个人隐私信息或具体岗位信息。
  • 博文可以提到并介绍 jobseek-template 模版。
  • 自行决定行文逻辑、文章架构，做到有吸引力、重点突出、不过分冗长。不得频繁换行、断行。
  • 注重严谨，如引用资料需标明出处。

可以看出，与第一篇最大的区别在于，这次我给了 GPT 充分的「行文逻辑自由」，也没有一个固定的框架或流程。这也是 GPT 恰恰表现最差的地方 —— AI 写出来的东西还是「AI 味太重」，让人读着像在看产品说明书，也很难抓住人的眼球。

所以…结论是？

我觉得我不会完全否定 AI 辅助写作。在第一篇的相关场景下，LLM 的效果其实很好 —— 完整全面的引证、绝不出错的格式、等等。但是就目前的模型能力边界而言，如果想要写「给人看的文章」，可能还是至少得为 AI 划定行文逻辑与框架，而非交给它天马行空地 乱写 发挥。