Agent 交回一篇文章时，作者需要回答几个具体问题：它改了什么，依据在哪里，运行过什么检查，以及读者接下来会看到什么。本文给出一套适用于 Markdown 技术博客的验收顺序，并提供可下载的检查清单和模板。
下面的命令和字段对应本站。用于其他项目时，需要替换为那个项目已经约定的工具；文中的输出示例不是一次真实发布记录。
第一步：先看差异，再看成稿
先让 Agent 用一句话说明本次目标，例如“补充本地预览步骤，并纠正旧版部署命令”。随后阅读差异，确认修改范围确实围绕这个目标。
在 Git 项目中，可以用下面的命令查看范围与具体变化：
git diff --stat
git diff -- src/content/blog/这两个命令只查看已经受 Git 跟踪的文件差异。新增文章还需要结合 git status --short 检查，不能因为差异为空就认为没有新文件。
如果是一次正文修改，却同时改变了发布时间、推荐位置和系列名称，就需要逐项解释这些额外变化的原因。
第二步：给关键结论找到对应依据
来源清单只说明文章引用了哪些资料，不会自动证明每一句话。验收时可以逐条问：
- 这是一项官方说明、实际观察，还是作者的推断？
- 来源是否支持这条具体结论，其版本与时间是否适用？
- 如果声称“已经测试”，是否有对应的命令、环境与输出？
- 如果只是示例，是否明确标注了示例身份？
例如，“构建成功，所以网站已经上线”省略了部署和公网验证两个环节。更准确的记录应分开写明本地构建、上传结果和正式域名的检查结果。
Google 的内容指南强调内容对实际读者的帮助及其可信依据。对于实践文章，写清楚你做过什么、没有验证什么，会比没有条件的结论更有用。
第三步：检查内容状态是否改变了网站行为
Astro Content Collections允许项目为内容定义结构化约束。在本站，这些字段还会决定哪些文章进入公开页面、首页和 RSS。
| 编辑动作 | 验收重点 |
|---|---|
| 新建文章 | 是否仍是草稿，计划日期是否正确，标题与摘要是否已经填完 |
| 实质更新 | 修订日期与说明是否对应真实变化 |
| 调整系列 | 章节顺序是否唯一，公开目录是否只引用已发布内容 |
| 移动旧文章 | 历史地址是否仍可访问，跳转是否直达最终地址 |
| 增加推荐入口 | 与正文是否相关，目标页面是否存在 |
具体修订方式可以参考修改一篇旧文章时，应该留下什么。模板里的 draft: true 是起稿状态；日期、正文和依据都需要按实际情况填写，不能直接把模板改成公开文章。
第四步：运行检查，再走一遍读者路径
本站在本地使用以下命令：
pnpm build
pnpm test
pnpm maintain构建负责生成页面并检查链接、历史地址和资源预算；测试覆盖内容规则与发布相关逻辑；维护清单提醒需要复查的内容。它们各自回答不同的问题。
CI 暂时不能运行时，可以继续执行这些本地检查，并如实写明“本地通过，远程检查未执行”。不要为了得到一个成功状态而删除失败的检查。
最后，在手机宽度打开文章，实际操作目录、代码复制、表格滚动，以及文末的系列或资料入口。页面能返回内容，并不意味着这些操作都已经验证。
第五步：用一份简短记录交接
下面是一种交付格式，不代表本文对应的任务已经上线：
目标：本次要解决什么问题
改动：修改了哪些文件和结论
依据：原始资料或实际验证记录
检查：命令、环境与结果
待办：未解决的问题及其影响
发布：未发布，或附实际版本与可访问地址有了这份记录，后续 Agent 可以接着处理具体问题。它也能帮助作者判断是否需要进一步复核，而不是重新猜测上一次任务做到哪里。
完整清单、默认草稿模板和可复制的验收提示词，放在Agent 内容运营资料包中。它们是工作起点，需要适配自己的项目，不能替代对事实和发布决定的判断。