数字员工不是聊天机器人：如何给 AI Agent 写一份可执行岗位说明书
这篇文章以万象片场的博客自动发布代理为例，拆解如何把 AI Agent 从会聊天的工具，设计成有边界、有输入、有流程、有验收标准的数字员工。
很多人第一次使用 AI Agent 时，会自然地把它当成一个更聪明的聊天机器人：告诉它一个目标，期待它自己理解上下文、自己决定步骤、自己交付结果。
但在真实项目里，这种方式很快会遇到问题。AI 可能写得不错，却不知道该写到哪里；可能执行了命令，却没有检查结果；可能完成了一次任务，却无法在下一次复用经验。它看起来很智能，但不像一个可靠的员工。
在「万象片场」的内容系统里，我越来越倾向于把 AI Agent 当成数字员工来设计。数字员工不是“什么都能聊”，而是有明确岗位、有输入来源、有操作边界、有验收标准，并且能在固定流程中稳定交付。
这篇文章就用博客自动发布代理为例，拆解一份可执行的 AI 数字员工岗位说明书应该怎么写。
一、先把“能力”改写成“岗位”
很多 AI 自动化需求一开始都是能力描述：
- 帮我写文章；
- 帮我运营博客；
- 帮我做内容；
- 帮我自动发布；
- 帮我检查网站。
这些说法没有错，但太宽泛。宽泛的任务会让 Agent 进入自由发挥模式，而自由发挥恰恰是生产系统里最危险的部分。
更可靠的方式，是把能力改写成岗位。例如：
你是万象片场的博客自动发布代理。每天早间槽负责读取内容计划，选择 AI 自动化 / 数字员工 / Agent 实战方向的未发布主题，写入 Astro 博客项目，完成本地预览、构建、部署、线上验证和 GitHub 同步。
这句话不是普通提示词，而是一份岗位定义。它同时回答了几个关键问题：
- 你是谁；
- 你负责哪个资产；
- 你在什么时间槽工作；
- 你服务哪个内容方向；
- 你必须交付到什么程度；
- 你不能只生成文本，而要完成发布闭环。
当岗位定义清楚以后，Agent 的表现会明显不同。它不再只是“回答问题”，而是在执行一个可验收的工作单元。
二、岗位说明书必须写清楚输入来源
一个数字员工如果不知道该读什么，就会依赖模型记忆或临场猜测。对内容生产来说，这很容易导致重复选题、错过规划、偏离品牌方向。
所以岗位说明书里必须写清楚输入来源。
以万象片场的博客代理为例，它每次启动前至少要读取三类信息：
- 内容计划文件：确认今天属于哪个槽位，优先主题队列是什么；
- 已有文章目录：确认哪些标题和主题已经发布，避免重复；
- 内容体系文件：确认品牌定位、平台分工和长期目标。
这一步看起来像准备工作，但它决定了自动化是否有连续性。
如果没有计划文件，Agent 可能每天写一篇看似正确、实际分散的文章；如果不读历史文章，它可能重复发布相似主题；如果不读内容体系，它可能把博客写成普通技术日记，而不是万象片场的主资产库。
数字员工的第一条规则是：不要让它凭感觉开始工作，要让它先读取生产系统里的事实。
三、给它边界：哪些能做，哪些不能做
真正的自动化不是无限授权，而是边界清晰。
在一个本地 Agent 工作流里，边界至少包括三类。
第一类是路径边界。例如博客项目只能操作：
/Users/william/projects/cloudflare-blog文章只能写到：
src/content/posts/如果任务明确说不要操作某个项目，就必须把它写进岗位边界。这样可以避免 Agent 因为文件名相似、项目相邻或历史上下文混杂，误动不相关资产。
第二类是动作边界。比如博客已经授权在预览和构建通过后自动部署，但公众号公开群发、账号改名、头像修改、投流付费等动作仍然需要人工确认。数字员工可以执行低风险、可回滚、流程明确的动作；高风险动作必须停下来等待授权。
第三类是内容边界。万象片场的博客不写泛泛 AI 新闻，不做热点搬运，而是写 AI 自动化、数字员工、Agent 实战、内容系统和变现实验。这个边界能保证长期积累出来的是同一个资产库，而不是一堆互不关联的文章。
边界不是限制创造力，而是保护生产系统。
四、把任务拆成可执行 SOP，而不是一句目标
如果只给 Agent 一个目标：“今天发一篇博客”，它可能会直接生成文章，然后认为任务完成。
但真实发布链路远不止写作。一个可执行 SOP 应该把任务拆成连续检查点：
读取计划
↓
读取已有文章
↓
选择未发布主题
↓
创建 Markdown 文件
↓
本地预览首页、归档页、文章页
↓
检查标题、摘要、封面图和图片加载
↓
运行 npm run build
↓
运行 npm run deploy
↓
线上浏览器验证
↓
Git add / commit / push
↓
输出简短发布报告这套 SOP 的价值在于，每一步都能被观察，也能在失败时停止。
例如本地预览发现文章页打不开，就不应该进入构建；构建失败，就不应该部署；部署成功但线上页面仍是旧缓存，就不能直接宣布发布完成；Git 工作区有不相关变更，就不能随手 git add .。
对数字员工来说，SOP 不是形式主义，而是让 AI 能稳定工作的轨道。
五、给它验收标准：结果必须能被用户看到
很多自动化任务最大的问题，是只验证“我做过了”，不验证“用户是否得到结果”。
博客发布的验收标准应该非常具体：
- 首页能看到新文章；
- 归档或列表排序正常；
- 文章页标题、摘要、正文和小标题完整；
- hero 图片在浏览器里成功加载；
- 线上 URL 能打开新内容；
- 构建和部署命令都成功；
- GitHub 已经同步对应变更。
这也是我为什么会把浏览器检查写进流程。npm run build 通过只能说明工程层面没有明显错误；浏览器能正常看到页面，才说明内容资产真正交付给用户。
如果未来万象片场继续扩展到小红书、微信公众号、YouTube 或轻产品页面，每一个数字员工都应该有类似验收标准。比如小红书切片代理要检查标题、封面、正文钩子和账号定位；工具站发布代理要检查公式测试、页面交互和免责声明；主站导航代理要检查跨站链接是否真实可见。
验收标准越具体，AI 的工作越不像“生成内容”，越像“交付资产”。
六、一份可复用的数字员工岗位模板
如果把上面的经验抽象出来，一份 AI 数字员工岗位说明书可以这样写：
角色：你是谁，服务哪个品牌或项目。
目标：你每次运行必须交付什么结果。
输入：你必须先读取哪些文件、页面、数据库或历史记录。
范围：你可以操作哪些目录、账号、平台和命令。
边界：哪些动作不能做，哪些情况必须停止。
流程：从检查到执行到验证的步骤顺序。
质量标准：怎样判断任务真正完成。
输出：最终报告应该包含哪些信息。
复盘：是否需要记录经验、更新计划或提醒优化。这份模板适合很多场景：博客发布、SEO 检查、资料整理、社媒切片、客户线索归档、工具站内容维护、自动化日报生成。
关键不在于让 Agent 一次做很多事，而在于让每个岗位足够清晰。一个清晰岗位反复运行十次，比一个模糊的万能 Agent 更接近真正可用的生产力。
七、下一步：从“一个代理”扩展成“一个片场”
万象片场现在的博客自动发布代理，只是数字员工体系里的第一个稳定岗位。它负责把长文资产持续沉淀到博客里，让 AI 自动化和内容系统的实践过程有地方被搜索、被引用、被复盘。
下一步更有价值的方向，是把不同岗位串起来：
- 博客代理负责完整文章和 SEO 资产；
- 小红书代理从文章里拆出一个钩子做短内容；
- 微信草稿代理把一周实践整理成深度复盘；
- 主站代理把成熟资产更新到入口导航；
- 复盘代理定期检查哪些主题可以沉淀成 SOP、模板或服务。
这才是“数字员工”真正有想象力的地方：不是让一个 AI 到处乱跑，而是让多个边界清楚的岗位协同，逐步组成一个可持续运转的内容片场。
对我来说，AI 自动化的核心问题已经不是“模型够不够聪明”，而是“我们有没有把工作设计得足够清楚”。当岗位、输入、边界、流程和验收标准都写明白，AI Agent 才有机会从聊天窗口走进真实生产线，成为万象片场每天都能交付内容资产的数字员工。