从手动执行到自动运行：哪些决定仍要由人做

先确认输入能被明确选中#

自动化首先需要解决“这次检查哪篇”。手动时可以临时解释，定时运行时如果缺少规则，Agent 可能遍历整个目录，检查旧文或选错草稿。

可以准备一个待检查清单，每项记录文章路径与输入版本；也可以在文章变更后触发检查。无论哪种方式，都应说明哪些目录属于范围、草稿怎样处理、没有待检查对象时做什么。

空清单可以直接结束，不必为了产生报告而找一篇旧文重新检查。路径不存在或输入版本不匹配，要记录错误，不能自行换成名称相近的文件。

运行前还要能取得稳定输入。作者仍在修改的稿件，适合等一段时间没有变化再检查，或者明确检查当时的快照。否则报告生成时，文章可能已经是另一个版本。

自动流程也应写明读取范围和输出目录，使用专门权限。规则文件告诉 Agent 怎么做，调度器和实际工具负责限制它能做什么。

定时与事件触发，按工作节奏选#

如果文章修改频繁，变更事件触发比较及时，但一次保存可能产生多次事件，需要合并或去抖。如果更在意每天集中看一次报告，定时执行更容易管理，代价是等待下一轮。

也可以先选最简单的一种。例如每天固定时间检查待处理清单，时间与时区写清楚。没有必要一开始同时配置目录监听、提交事件和定时补扫。

选择频率要考虑任务持续时间。如果一次检查常常超过两轮之间的间隔，新一轮不能无条件启动同样的任务。先确认是否已有运行，再决定排队、合并，或跳过重复项。

临时手动检查也可能与自动任务重叠。两者应使用一致的任务标记与版本判断，避免同一篇文章生成两份互相矛盾的“最新报告”。

相同输入，避免产生重复动作#

定时执行、失败重试或重复事件，都可能让同一项工作运行多次。检查报告可以设计成可重复运行，但通知、写入外部系统或发布等动作，未必适合直接重放。

可以用文章路径、内容版本、检查规则版本，以及会影响结果的工具配置版本组成任务标记。已完成且条件未变的本地检查，可以复用；条件改变，就重新检查受影响部分。

内容版本可以使用哈希，但哈希本身只用于识别变化，不代表文章通过检查。规则与输入一样重要：文章没改，检查规则升级了，旧报告仍可能需要重跑。

实时外部资料还有时间因素。文章没变化，服务价格也可能更新，因此事实核实结果需要记录查询时间，并按资料性质约定有效期。不能永远以“文件没有改”为理由跳过外部核实。

重复执行时，把报告写到本次任务自己的位置，完成后再更新最新报告指向。若中途失败，不应把半份报告覆盖成最终版。是否采用临时文件、数据库状态或其他写入方式，按现有工具选择，不必先引入新平台。

一个小型运行约定#

可以先用下面的约定检查自己的方案是否完整。数字仅是示例，应按文章长度、服务限制和成本调整：

1
触发：每天 09:00，Asia/Shanghai 时区。
2
输入：明确列入待检查清单的文章及其版本。
3
范围：指定文章与适用规则，不扩展到其他内容目录。
4
输出：每次任务独立的检查报告和简要状态。
5

6
并发：同一输入版本最多运行一个任务。
7
重复输入：已有有效结果则复用，不重复通知。
8
本地检查：按当前规则执行并记录证据。
9
外部核实：包括重试在内，最多 5 次查询；单次查询仅对暂时性错误重试 1 次。
10
执行时长：超过 10 分钟则保存已有结果并报告未完成项。
11
费用：只使用已经授权且有预算上限的服务。
12

13
通知：发现新问题、状态有变化、发生阻塞或需要人工决定时发送。
14
发布：本流程只检查，不持有发布权限。

这段约定不会自己执行，需要落实到调度器、工具权限和程序逻辑里。也要确认运行环境是否支持超时停止、调用上限和费用限制；无法强制的限制应在交付中说明。

开始时可以先做一轮人工触发的完整检查，再试一次重复触发和一次查询失败。能按约定保存结果、避免重复通知后，再开长期调度。

把运行状态与文章状态分开#

调度器可能显示任务已结束，文章却还有问题。状态至少应能表达：等待、运行中、已交付、部分完成或失败。报告里的检查结果则使用通过、发现问题、未完成。

比如，正文和元数据检查完成，外部查询失败，可以记录“部分完成”，附上可用报告。如果全部检查结束并发现一个无依据的数字，执行是已交付，文章仍需要作者处理。

每次状态更新都应对应实际事件。任务开始前不能写运行成功，模型给出总结也不能替代文件写入确认。恢复时先检查输出是否存在、输入是否变化，以及已完成步骤的证据是否有效。

同样的故障持续出现时，应降低重试频率或暂停相关自动任务，报告具体原因。认证失效、规则文件丢失等问题，不会靠每天重复失败自行修复。

通知只保留需要看的变化#

“本轮仍然没有新任务”每天通知一次，很快就会被忽略。更有用的通知是：某篇新稿发现问题，之前未完成的核实有了结果，服务故障影响了检查，或者需要作者确认处理方式。

相同问题没有变化时，可以保留报告并避免重复提醒。新版本仍包含同一问题，应说明它在新版本中继续存在，而不是表现为另一条全新错误。

通知内容不必复制全文。给出文章、输入版本、主要问题、未完成项和报告位置，就能让作者决定下一步。日志里也只保留排错与复核所需的信息，不保存凭证或无关私人内容。

如果希望每次成功都通知，可以明确设置。默认的通知策略应围绕实际需要处理的变化，而不是证明自动化一直在忙。

人工确认要对应实际稿件#

自动检查通过后，作者仍需要判断观点是否准确表达、建议是否采纳，以及何时发布。检查报告提供证据，不能代替这些决定。

批准发布时，应对应具体的输入版本和检查报告。如果确认之后又修改了文章，就重新检查受影响的部分。不能把昨天对旧稿的批准，当成今天新稿的发布许可。

对这套文章检查流程，最直接的做法是不提供发布工具或凭证。作者阅读报告、修正问题、确认当前版本，再通过原有发布流程操作。以后确实需要加入自动写入或发布，必须重新定义范围、授权和失败后的处理方式。

只读自动检查也可能产生模型或查询费用。费用上限、运行次数和异常停止要有实际约束；提示词里的“尽量省钱”不能替代预算控制。

保留一个容易维护的日常流程#

整个系列从一篇文章开始：先明确检查目标，保存可复用规则，测试正常与异常输入，再接入确实缺少的工具，让 Agent 留下可核对的报告。任务有独立部分时才分工，输入与交付稳定后才自动触发。

这些步骤可以反复往回走。自动任务频繁误报时，可能要回到 Skill 的测试样例；查询失败时，回到 MCP 的调用验收；合并报告费劲时，回到单个 Agent 的执行方式。

我会定期看实际减少了多少重复解释、漏项和人工返工，而不是统计装了多少工具。规则、模型或服务变化后，复测受影响的样例，并保留停用入口。

一套值得留下来的工作流，应该让你能回答：它检查了哪一版文章、哪些结论有依据、哪里还没完成，以及下一步由谁处理。做到这些以后，自动运行才有清楚的意义。