快的那个跑了三分钟，产出的草稿我一份都没法用。慢的那个跑了将近二十七分钟，四份全部产出，然后在不到一秒内重复了已完成的任务，没有向模型再发任何请求。

这个差别成了 PatchPitch 0.3.0 的一次发布验收测试。PatchPitch 是我做的开源工具，把开发事实转成面向 Telegram、X、DEV 和 GitHub 的公告草稿。10 月 24 日发布。走到这一步，靠的不是看模型有没有返回一段文字。

上一篇文章里，我在 Windows 上跑了无头工作流，在工作室里检查结果。命令行工具本身已经能用。为了这次发布，我想看的是在干净的 Linux runner 上、在代码检出目录之外、stdin 关闭的情况下会发生什么，以及模型出错时还有哪些东西是可用的。

一套事实，四种写作任务

完成一次发布，就多出一个小项目：把它讲清楚。事实是同一套，但 Telegram 更新、X 帖子、DEV 文章和 GitHub 说明需要的上下文量不一样。

PatchPitch 从选定的事实和一个 JSON 或 TOML 任务文件开始。Ollama 提供本地模型，命令行工具准备草稿并保存证据。想检查或编辑结果时可以用工作室，但生成过程不需要它的 Web 服务器，也不需要浏览器。

我在意的部分是生成之后留下来的东西：原始响应、失败的尝试、输入快照，以及我可编辑的发布文件。如果某个目标失败，我可以单独检查它，不用把另外三个一起丢掉。如果我编辑了某份草稿，重跑任务会保留这次编辑。

小模型先跑完，然后整场失败

Linux 环境我用的是 GitHub Actions，因为当时我的 Windows 机器既没有 WSL/Docker，也没有在跑的 Ollama。runner 把 PatchPitch 装进一个全新环境，并从代码检出目录之外调用已安装的命令行工具。

我也用 gemma3:4b 试了同一场任务。它跑了 183.374 秒，发出四次模型请求，以退出码 4 结束。四个目标都尝试了，没有一个产出被接受的输出。

我保留了这次失败的运行和它的证据。把那些检查放宽，工作流会变绿，但我拿到的仍然是错误的语言、缺失的信息和一份没法用的 X 草稿。

这个结果描述的是一个模型上的一场任务。它不能证明所有 4B 模型都会失败。它意味着我不能把这套配置说成是通过那套配置的更便宜等价物。

通过的那次，DEV 请求花了八分钟

换成 gemma4:12b，Linux 任务在 1599.653 秒内完成，即 26 分 40 秒。记录的环境是 Ubuntu 24.04、Python 3.12.15 和 Ollama 0.40.10。

五次请求产出了四份被接受的草稿。校验和会话导出也通过了。完整的 Actions 运行记录下了这次实验；这些耗时是那台 CPU runner 上的观察值，不是速度承诺。

DEV 请求暴露了一个实际的配置细节：497.921 秒超过了常规的 420 秒超时。通过的那套配置显式用了 600 秒。从一个准备好的检出目录出发，Ollama 在跑、gemma4:12b 已安装的情况下，复现命令是：

  • PATCHPITCH_MODEL=gemma4:12b
  • PATCHPITCH_TIMEOUT=600
  • python -m patchpitch run --job examples/headless/all-four.toml --out-root artifacts/campaigns --json

这个例子复现的是原始实验的输入。最终发布用的事实单独放在 examples/headless/release.toml 里。现场证据早于最终的版本标签；最终发布没有改动推理和校验行为。

然后是让人愉快地无聊的部分。重复已完成的运行花了 0.352 秒。显式恢复花了 0.329 秒。所有任务文件保持逐字节一致，两个操作都没有再发模型请求。

二十七分钟是很长的等待，不该被误触发。在这里，保住已完成的工作比从提示词里省下几个词更重要。

丢了一次响应，不该多出一篇文章

DEV 适配器要处理的是另一种失败。假设 DEV 保存了我的草稿，但响应没有回到 PatchPitch。再发一次创建请求，可能就多出一份重复。

还有一个额外的麻烦：已拥有文章的响应可能省略 AI 披露字段。旧的恢复逻辑把字段缺失当成 fully_autonomous。一份以 some_ai 或 no_ai 发出的草稿，即使内容已经正确保存，也可能在核对时失败。

现在回执会保留发出的文章载荷原文。恢复时检查已拥有的草稿和它可观察到的内容，然后把期望的披露值显式发给同一份草稿。字段缺失不再变成一个凭空编出来的值。回归测试覆盖了这些恢复路径，包括披露字段被省略的情况。

生成和投递仍然是分开的命令。适配器以 published=false 保存草稿，并保护已经发布的文章。这样在公开发布之前，我有地方检查 DEV 上的实际渲染效果。

六个标签、一份明确的写作要求，以及一次可检查的发布

对 X，我定了一条产品规则：正好六个相关话题标签。PatchPitch 从带日期的观察里挑出它们，检查话题和受众匹配度，并在请求正文之前为它们和链接预留空间。通过的那条 Linux 帖子用了 #DevTools #LocalAI #LLM #Ollama #OpenSource #Automation。

这份目录支持的是话题选择，不能证明触达提升。失败的 4B 方案之所以有用，恰恰因为它显示了现有证据在哪里用尽。

这篇文章我用 PatchPitch 配了一份 Quillgrain 编辑要求：第一人称单数、一个具体实验、短段落、失败保留在故事里。然后我编辑了模型草稿，修正了它对早先演示的表述，补上了结果表格和来源链接。要求把我的偏好写明确，编辑仍然决定哪一段值得留下。Linux 验收样本本身用的是 clear 预设。

最新的主干 CI 通过了基础测试套件、固定版本的 Quillgrain 集成任务和打包检查。Quillgrain 跑了 21 个测试，没有跳过。wheel 和源码包都构建成功，wheel 的命令行工具在无 UI 依赖的干净环境里通过了检查。

PatchPitch 0.3.0 在 GitHub 上，带归档、校验和与源码提交。无头指南覆盖安装和任务配置。它还没上 PyPI。

现在我可以把一套维护好的事实交给命令行工具，让它准备草稿，然后回来同时看结果和结果背后的证据。更小模型的验收，以及带声音和控件的 DEV 内嵌视频，还在待办里。

如果你在无人值守的情况下跑本地模型，哪种失败让你花的时间更多：一个被拒绝的响应，还是一个看起来有效、直到你真正去用才发现不对的响应？