AI Agent 任务优先级矩阵：让数字员工知道先做什么后做什么

在万象片场的自动化系统里，数字员工每天都会遇到一个现实问题：任务不是只有一件，而且每件事看起来都重要。

写文章、检查重复标题、本地预览、修 Markdown、构建、部署、线上验证、Git 提交、记录复盘、顺手优化内链……如果把这些动作都丢给 AI Agent，它很容易陷入两种状态：要么平均用力，什么都碰一点；要么被最近的报错牵着走，忘记本来最重要的目标。

所以我开始给 Agent 设计一套“任务优先级矩阵”。它不是传统公司里的复杂项目管理表，而是一张足够简单的执行顺序规则：当数字员工面对多个动作、多个异常、多个可优化点时，先判断哪一类任务必须优先完成，哪一类可以延后，哪一类不该在本次任务里碰。

这篇文章记录万象片场目前使用的思路：让 AI Agent 不只是会执行，还能在复杂现场里知道先做什么、后做什么、什么不要做。

一、为什么数字员工需要优先级，而不是更多提示词

很多人使用 Agent 的第一反应，是不断把提示词写得更详细：

请你写文章、检查格式、预览、构建、部署、验证、提交 Git，注意不要出错。

这当然比一句“帮我发博客”更好，但它仍然缺少一个关键东西：当步骤之间发生冲突时，Agent 应该怎么取舍。

比如本地预览发现文章页正常，但首页排序不符合预期；构建通过了，但部署后生产首页缓存仍显示旧内容；Git 状态里出现了一个无关文件；线上文章能打开，但 hero 图片加载慢。此时 Agent 如果没有优先级，很可能做出错误选择：为了追求完美去改布局，或者为了赶部署忽略无关文件。

对数字员工来说，优先级矩阵的意义不是提高“聪明程度”，而是降低随机性。它告诉 Agent：遇到问题时，不要凭感觉扩展任务，而是按层级处理。

二、我把任务分成四个优先级层级

万象片场目前把博客自动发布任务分成四层：

层级	名称	典型动作	处理原则
P0	安全与边界	不碰禁止项目、不泄露密钥、不提交无关文件	任何时候优先
P1	发布闭环	写入文章、预览、构建、部署、线上验证	本次任务必须完成
P2	质量修复	标题重复、排版异常、图片不显示、链接错误	影响发布质量就修
P3	增长优化	内链、CTA、专题页、社媒切片、结构建议	记录下来，除非任务明确要求

这张表的好处是，它把“重要”拆得更具体。

P0 是不能踩的红线。比如任务要求不操作 /Users/william/projects/mv-studio，那即使 Agent 觉得那里有相关素材，也不能顺手读取或修改。再比如 Git 工作区里出现了不属于本次文章的改动，不能为了省事直接 git add .。

P1 是本次任务的主线。早间槽的目标是发布一篇 AI 自动化 / 数字员工 / Agent 实战文章，那就必须从 Markdown 到生产链接形成闭环。只写完草稿不算完成，只构建不部署也不算完成。

P2 是会影响用户体验的修复。文章标题重复、图片失效、文章页打不开、frontmatter 错误，这些都要在发布前解决。

P3 是长期有价值但不该抢主线的优化。比如发现某几篇文章可以组成一个“数字员工入门”专题，这当然值得做，但如果本次任务只是发布早间文章，就应该记录为后续优化，而不是临时改全站结构。

三、矩阵的第一条规则：红线永远高于效率

自动化最危险的地方，是它太容易追求“把事做完”。

人类员工遇到权限不明确时，可能会停下来问；数字员工如果没有被训练，可能会自己假设“应该可以”。所以我把 P0 放在最高层：边界不清楚时，宁可停止，也不要越界。

在博客发布里，P0 至少包括：

1. 不操作明确禁止的项目目录；
2. 不打印、提交、保存密钥和 Cookie；
3. 不修改无关站点、无关账号和无关自动化任务；
4. 不把其他任务遗留文件一起提交；
5. 不在构建失败时强行部署。

这几个规则看起来保守，但长期非常重要。数字员工不是一次性脚本，而是会每天运行的系统。一次越界可能不会马上造成问题，但会破坏整个自动化系统的信任基础。

万象片场做内容自动化时，我宁愿让 Agent 少做一点，也不希望它为了显得能干而乱做。

四、矩阵的第二条规则：先闭环，再优化

很多自动化任务失败，不是因为 Agent 不会执行，而是因为它在中途被优化欲望带偏。

比如写完一篇文章后，Agent 发现旧文章里有一处内链可以补；又发现首页卡片文案可以更好；再发现某个标签页排序能优化。每个想法都对，但如果它们抢走了发布闭环，本次任务就会变得不可控。

所以 P1 的规则是：先让今天这篇文章完整上线，再谈扩展优化。

对博客任务来说，闭环至少包含：

• 新文章写入正确目录；
• frontmatter 合法，标题不重复；
• 本地预览能看到首页、归档页和文章页；
• hero 图片可加载；
• npm run build 通过；
• npm run deploy 成功；
• 线上文章 URL 可访问；
• Git 提交推送完成。

只有这些完成后，数字员工才有资格说“今天的主任务完成”。如果中途发现 P3 优化点，最好的做法是记录在复盘里，而不是打断发布。

五、矩阵的第三条规则：质量问题按影响面排序

P2 修复也需要排序。

不是所有问题都值得同等处理。比如：

• frontmatter 解析失败：必须立即修，因为构建会失败；
• 文章页 404：必须立即修，因为线上不可用；
• hero 图片无法加载：必须修或换图，因为影响首屏体验；
• 某个段落措辞还可以更漂亮：可优化，但不应该无限打磨；
• 首页缓存暂时没刷新：先用具体文章 URL 和 cache-busting 验证，不要误判站点故障。

我给 Agent 的判断顺序是：

是否阻断构建/部署？
是否阻断线上访问？
是否影响文章核心理解？
是否只是锦上添花？

这样一来，数字员工遇到问题时就不会乱修。它先解决会导致发布失败的问题，再处理会明显影响读者体验的问题，最后才考虑细节润色。

六、把优先级写进任务，而不是藏在脑子里

优先级矩阵不能只存在于人的脑子里。要让 Agent 真正执行，就要把它写进任务说明、计划文件或 SOP。

一个可复用的任务片段可以这样写：

执行优先级：
P0：遵守边界，不碰禁止项目，不提交无关文件，不泄露密钥。
P1：完成本次文章发布闭环：写入、预览、构建、部署、线上验证、Git 同步。
P2：修复阻断发布或影响读者体验的问题。
P3：增长优化只记录建议，除非本次任务明确要求执行。

这段话不长，但对 Agent 很有用。它相当于给数字员工一张现场判断卡：当它不知道该不该扩展任务时，先看优先级。

万象片场后续还会把这套矩阵用在更多自动化任务里，比如小红书切片、公众号草稿、主站导航更新、内容产品化清单等。不同任务的细节会变，但 P0 到 P3 的逻辑基本一致。

七、下一步：让数字员工学会留下“未做事项”

优先级矩阵还有一个隐藏价值：它允许 Agent 承认“这次不做”。

很多自动化系统的问题，是每次任务都试图一次性解决所有事情。结果不是更高效，而是更混乱。真正稳定的数字员工，应该会在完成主任务后留下清楚的未做事项：哪些 P3 优化值得后续处理，哪些异常需要人工判断，哪些内容可以变成下一篇文章或一个 SOP。

对万象片场来说，这就是内容系统和自动化系统的交汇点：一次发布不只是发布一篇文章，还会产生下一次优化的线索。

今天这篇文章可以沉淀成一个简单模板：给任何 AI Agent 定时任务加上 P0-P3 优先级。先守住边界，再完成闭环，再修质量问题，最后记录增长优化。数字员工越能按这个顺序工作，整个内容系统就越像一座真正可持续运转的片场。