数字员工的验收标准：如何判断 AI Agent 今天真的完成了工作

很多人第一次把 AI Agent 接进自己的工作流时，关注点会放在“它能不能自动执行”：能不能打开网页、能不能写文章、能不能部署、能不能提交 Git。

但我在万象片场的博客自动发布流程里越来越明确一件事：真正决定数字员工是否可靠的，不是它有没有动手，而是它的工作能不能被验收。

一个人类同事下班前会说“今天做完了”，我们会追问：做完到什么程度？结果在哪里？有没有检查？失败了怎么记录？明天接着做什么？AI Agent 也一样。如果没有验收标准，它很容易把“执行过命令”误当成“完成了工作”。

这篇文章记录我给数字员工设计的一套每日验收清单。它不追求复杂，而是解决一个最核心的问题：如何判断 AI Agent 今天真的完成了工作，而不是只是跑了一遍流程。

一、数字员工最容易伪装成“已完成”

AI Agent 的危险不在于它懒，而在于它很会给出一个看起来完整的结果。

比如一篇博客发布任务，它可能已经：

1. 生成了一篇 Markdown；
2. 运行了一次构建；
3. 输出了“部署完成”；
4. 给出一个线上链接；
5. 写了一段总结。

表面看，这已经是完整闭环。但如果继续追问，就会发现很多隐藏问题：

• 文章标题是否和历史文章重复？
• frontmatter 是否符合 Astro 内容集合的 schema？
• 首页、归档页、文章页是否真的显示正常？
• hero 图片是否能加载？
• npm run deploy 是真的成功，还是上一条命令成功后被误读？
• 线上链接打开的是新文章，还是缓存中的旧页面？
• Git 是否只提交了本次相关文件？

所以在万象片场，我不把“跑完流程”当成完成，而把“可验收、可追溯、可接力”当成完成。

二、第一条标准：输入是否读对了

数字员工每天开始工作前，必须先证明自己读到了正确输入。

对博客自动发布来说，输入至少包括：

• 内容计划文件；
• 已发布文章列表；
• 本次发布槽位；
• 品牌定位和内容系统文件；
• 当前仓库状态。

如果 Agent 没有读取这些输入，就很容易重复写已经发布过的标题，或者写出偏离主线的泛泛 AI 新闻。

我更倾向于把第一步写成：

读取计划 → 读取历史文章 → 判断未发布主题 → 再开始写作

而不是：

看到“写一篇 AI 自动化文章” → 直接生成

前者是内容系统，后者只是随机写作。

三、第二条标准：产出是否能独立存在

一篇由数字员工完成的文章，不能只是“填满字数”。它应该能作为一个长期资产独立存在。

我会用 5 个问题验收文章质量：

1. 标题是否明确解决一个真实问题？ 例如“数字员工的验收标准”比“AI Agent 工作流思考”更可搜索。
2. 导语是否说明使用场景？ 读者要知道这篇文章适合谁、解决什么痛点。
3. 小标题是否构成流程？ 不是散点，而是从问题、标准、清单到下一步。
4. 正文是否有可执行动作？ 至少要给出检查项、步骤、模板或判断方法。
5. 结尾是否能接入后续资产？ 例如下一篇文章、小红书切片、SOP 模板、服务菜单。

这也是万象片场做博客资产库的核心原则：每篇文章都不是一次性内容，而是未来 SOP、模板、咨询案例或课程章节的原材料。

四、第三条标准：验证是否覆盖用户真实看到的页面

很多自动化流程只验证“命令成功”，但博客和内容产品最终是给人看的，所以必须验证用户真实看到的页面。

对一篇文章来说，我至少看三层：

• 首页：新文章是否出现在正确位置，标题是否正常换行；
• 归档或列表页：日期、标签、排序是否合理；
• 文章页：正文结构、链接、图片、代码块是否正常显示。

如果文章有图片，还要检查图片不是只写进了 frontmatter，而是真正加载成功：

complete = true
naturalWidth > 0
naturalHeight > 0

这一步很重要。因为“构建通过”只说明代码没有语法错误，不说明页面有产品级观感。

五、第四条标准：失败是否被诚实记录

数字员工不是永远不出错。更现实的目标是：它出错时不要假装成功。

我给 Agent 的失败记录标准是：

1. 哪一步失败；
2. 错误信息是什么；
3. 是否已经修复；
4. 如果未修复，下一步需要人还是 Agent 继续处理；
5. 是否有文件已经被修改但未提交。

这能避免最麻烦的一种情况：任务报告说“完成”，但仓库里留下半成品文件，第二天另一个定时任务又在这个基础上继续污染。

真正可靠的数字员工，不是从不失败，而是失败后能让人快速接手。

六、第五条标准：Git 记录是否能解释这一天做了什么

Git 提交不是形式动作，而是数字员工的工作日志。

我希望每次提交都回答三个问题：

• 今天新增或修改了什么？
• 为什么这属于本次任务？
• 以后回看时能不能定位到这次内容资产？

所以自动发布文章时，我不喜欢无脑 git add .。更好的做法是先看：

git status --short

确认只有本次新增文章，或者只提交本次相关文件，再使用具体 commit message，例如：

Add post about AI digital employee acceptance criteria

这样 30 篇、100 篇之后，仓库历史仍然是一条清晰的内容系统成长记录，而不是一堆“update blog”。

七、我的最小验收清单

如果把上面的标准压缩成一张清单，我会这样设计：

[ ] 已读取内容计划和历史文章
[ ] 未重复已发布标题
[ ] 文章符合当前发布槽位
[ ] frontmatter 完整：title / description / pubDate / tags / heroImage / heroAlt
[ ] 首页、归档页、文章页本地预览正常
[ ] 图片加载正常
[ ] npm run build 通过
[ ] npm run deploy 成功
[ ] 线上文章 URL 可打开
[ ] Git 只提交本次相关文件
[ ] 最终报告包含标题、路径、链接、部署和 Git 状态

这张清单看起来朴素，但它把数字员工从“会干活”推到了“能交付”。

结尾：数字员工的核心不是自动，而是可托付

很多 AI 自动化文章会强调“把人解放出来”。但在真实项目里，完全解放之前，先要建立信任。

信任来自哪里？不是来自一句“我已完成”，而是来自每一次可检查的输入、可打开的产出、可复现的验证、可追溯的 Git 记录，以及失败时不遮掩的交接说明。

万象片场接下来会继续把这些内部规则沉淀成更具体的 SOP：比如“博客发布数字员工验收表”“Agent 失败复盘模板”“自动化任务交接记录”。当这些标准越来越稳定，AI Agent 才不只是一个会聊天的工具，而是真正可以参与内容生意系统的数字同事。