给 Agent 写一句话岗位定义：把触发、范围、交付终点压进一句

2026-08-25

我给那个写公众号文章的 Agent 建岗位卡时，第一段「岗位名称」几秒钟就写完了，第二段「一句话岗位定义」卡了很久。

卡住的地方不是想不出话，是写出来的话每一句都对、每一句都没用。比如「负责协助我完成公众号文章的撰写工作」——这句谁看了都点头，可它一个真问题都没回答：我丢一个链接过去，它是直接开写还是先来问我要往哪个方向写？写完正文算完成，还是得把封面也出了？封面出完算完成，还是得落到盘上？

这些不是理论问题。它们是我第一次真正跑起来的时候，当场就会分歧的地方。而分歧的代价不对称：人接到一句含糊的岗位说明，会回过头来问你；这类自动往下跑的岗位不会问。我那张卡里的人工介入是分两类写的，一类是异常触发的介入条件，一类是每次必经的检查环节——两类都得由我事先写出来。我没写出来的位置，它不会自己停在那里等我，它会按自己的理解一路跑到终点，然后交给我一个看上去挺完整的东西。等我发现方向不对，前面那些工序已经全白做了。

所以这句话不是文档里的装饰段落，它是这个岗位后面所有分歧的第一道对齐。

三个成分：拿手指去点，点不到就是缺

我现在的自查方式很土：把自己写的那句话念一遍，用手指依次点出三处。

第一处，什么时候触发。 这个岗位在什么信号出现时开始动。信号得是外部可观察的东西，不能是「当我需要的时候」这类由我心里决定的状态。

第二处，处理到什么程度。 从触发到终点之间，它要经手哪几件事。这一处的检查方式是反着问：有没有哪件事我心里默认它会做、但这句话里没有？默认没写出来的，就是将来吵架的地方。

第三处，交付终点在哪。 这一处最容易缺，也最容易写假。判据是：终点必须是一个我事后能去看的东西，不能是一个状态形容词。 「完成文章」不是终点，因为「完成」没法验收——我没法回头去看一眼「完成」；「文章和封面已生成并保存到指定目录」是终点，因为我可以打开那个目录，东西在不在，一眼就知道。

三处点不全的，先别往下拆工序。工序是从这句话里长出来的，句子缺一块，长出来的工序就缺一段。

我那张卡上实际的那一句

写在岗位卡第二段的原话是这样：

当收到文章链接或主题时，自动分析素材、确认写作方向、完成文章和封面，并保存到指定目录及微信公众号草稿箱。

按上面三处拆开：

触发是「当收到文章链接或主题时」。这里并列了两种输入形态。链接和主题是两条不一样的路——给链接意味着有现成素材要读，给主题意味着素材得自己找。把两种都写进触发，等于承认这两种都算这个岗位的活。反过来说，别的形态就不算：这句话同时也在划「什么不触发」。

范围是「自动分析素材、确认写作方向、完成文章和封面」。这里有个值得停一下的地方：「确认写作方向」是范围里唯一一件需要人参与的事，它没有因为带着人的动作就被排除在这句之外。方向确认在我这套流程里是必经的检查环节之一，它属于这个岗位的职责范围，只不过执行时得停下来等我。范围里该不该出现人的动作，我的选择是该——把它藏起来，后面拆工序时就容易漏掉那个停顿。

交付终点是「保存到指定目录及微信公众号草稿箱」。两个落点，一个本地目录，一个草稿箱。

这句话写的是目标态，不是现状

最后那半句里有个落差，我一直没去抹平：草稿箱写入至今没有接通。

我这条线已经跑通的部分是：飞书上的收发、选题分析、方向确认、提纲确认、资料核验、正文撰写、封面生成、本地结构化保存。唯一没接通的就是往微信公众号草稿箱里写。所以真实的交付终点是「文章和封面已生成并保存」，不是「已进入草稿箱」。这句岗位定义，有一半的终点是空的。

发现之后我有两个选择：把那句话改短，改成跟现状一致；或者留着落差不动。

我留着不动。因为一句话岗位定义写的是这个岗位完整存在时应该管到哪里，它是目标态。现状归现状记——哪一环没接通，我记在另一份文档的已知问题里，那是专门放状态的地方。这两样东西的更新频率完全不同：目标态大半年也未必动一次，现状可能这周就变。混在一句话里，结果是两边都不准。

更实际的理由是：落差写在纸上，缺口才有人认领。 如果我当时手一抖把定义改成「保存到指定目录」，那条没接通的链路就从文档里消失了。文档从此自洽、完美、无懈可击，而那个功能永远不会有人再想起来做。定义和现状之间的那道缝，本身就是待办清单。

所以我给自己定的口径是：这句话对着目标写，允许它超出现状；但超出的部分必须在别处有一条对应的记录。 只允许超出，不允许无声地超出。

什么情况下这条不适用

一次性的活不适用。 这句话的全部价值在于被反复拿出来对齐——第二次跑、第三次跑、隔一个月再跑的时候，用它来判断有没有跑偏。只跑一次的事情，写它没有回报，直接把要做的写成清单更快。

交付终点不是文件时，得换个写法。 我这个岗位的终点恰好是落盘的东西，「去目录里看一眼」天然成立。如果你那个岗位的终点是一个对外动作——提交上去、发出去、同步过去——那么终点这一处不能写成动作本身，得写成这个动作的可回查证据。我这条线上正好有个现成的例子：草稿链路的成功判据被明文写成「拿到返回标识之后再去查一次草稿列表」，并且明确禁止把「接口已提交」当成「草稿已创建」上报。终点写成动作，验收的就是「我调了」；终点写成证据，验收的才是「它成了」。

别指望这一句把权限也压进去。 我这张卡里，「同步到草稿」和「公开发布」是两个不同的权限等级：审核通过之后同步草稿不需要再问我，但公开发布必须我点头。这个区分在那句岗位定义里完全看不出来——它只说到保存为止，公开发布压根不在这句里。这不是漏写，是我不想让它进来。一句话里压三个成分已经到顶了，再塞权限进去，句子会长到没人愿意读第二遍，而权限这种东西在岗位卡的兜底段落里分条列出来，才看得清哪条是异常触发、哪条是每次必经。

岗位边界还没摸清楚的时候，写出来的会是愿望而不是定义。 我起第二个岗位的时候，起点同样是先写岗位卡而不是先接工具，但那张卡目前也就到「岗位卡已写、正在往下拆工序」这一步。工序还没拆开之前，三个成分里最没底的就是「处理到什么程度」这一处，硬写只会写出一句好听的话。这种时候我的做法是先把触发和终点这两头钉住，中间那段等工序拆出来之后再回填。

这篇的判据来自我自己带 Agent 干活的实践，样本有限。它更像一份可以拿去验证的假设，而不是一份可以照抄的规范。