QUOTE
通讯录给数字员工一个名字，岗位说明书必须给组织一个 不能甩锅的答案。
周一上午九点十七分，公司通讯录里多了一位新同事。
姓名：小数同学。部门：销售运营。职位：数字员工。手机号：空。邮箱：有。头像：比全公司百分之八十的人都精神。
HR 问：“它算不算编制？”
IT 问：“它为什么要读 CRM？”
法务问：“它把客户报价发错了，告谁？”
业务负责人很淡定：“不用搞这么复杂，提示词已经写好了。”
坐在角落里的 FDE 听到这里，通常会放下咖啡。因为我们知道，提示词是自我介绍，不是岗位说明书。它能告诉 AI 怎么说话，却未必说明它能做什么、不能做什么、什么时候必须停，以及出了问题谁来把它从生产系统里拎出来。
这也是数字员工真正进入组织以后，第一个比模型能力更难的问题：谁来给它写岗位说明书？
本文看点
01
通讯录改变了什么
02
谁该写这份 JD
03
九格模板怎么落地
01
IDENTITY
通讯录不是花名册，是权限路由表
很多人把“数字员工进通讯录”理解成一种 拟人化包装：给机器人取个名字、配个头像、让大家更愿意和它聊天。
但已经确认的事实比包装更具体。关于钉钉的公开案例材料曾描述，数字员工可以 进入企业通讯录，取得相应职务权限，参与组织协同和业务流程。微软最新的 Agent 365 文档则更直接：专门的 Agent 用户身份可以有独立邮箱、OneDrive、Teams 协作能力，也可以出现在组织图和人员卡片里。
换句话说，它进入的不是一张合影，而是一套 身份、权限与审计系统。
当一个 Agent 只能回答问题时，它更像工具；当它可以读客户资料、改业务状态、发邮件、约会议、调用下游系统时，它就开始拥有“行动半径”。这个半径有多大，不由头像决定，而由它拿到的身份和权限决定。
所以，通讯录的真正含义不是“公司承认它像个人”，而是“公司允许它以一个 可识别的主体 进入工作流”。从这一步开始，岗位说明书就不能再是 HR 系统里的一段介绍文字。它必须能回答四件事：凭什么做、可以做到哪、做错怎么办、最后谁负责。
「数字员工有没有工位不重要。重要的是，它有没有权限，以及 权限后面有没有人。」
02
DEBATE
全网吵成了五个部门，而且每个部门都有一点道理
我把公开讨论、研究、产品文档和评论区翻了一遍，大致看到了 五派意见。
第一派：给它一个格子，才看得见“影子劳动力”
支持 AI 进入组织图的人，担心的是另一种风险：公司里已经跑着几十个 Agent，却没人知道它们分别替哪个团队干活、花了多少成本、碰了哪些数据、创造了多少产能。
它们不在人头预算里，不在外包清单里，也不在软件资产表里，最后就成了 影子劳动力。平时没人管，出事时全公司第一次知道它很能干。
这派的观点很务实：先让数字劳动力可见，才能做容量规划、成本核算和 责任分配。
第二派：别给它一个格子，给它一个人类 Owner
反对者也有一个很硬的理由：组织图不只是“谁坐哪里”，它还是一张 人类承诺图。上面的每条线都默认有人能被表扬、被纠正、被问责，必要时还能被请进会议室。
AI 做不到这些。它不会因为季度绩效不佳失眠，也不会在复盘会上主动承认“这次是我考虑不周”。它最多 生成一段语气诚恳的反思，然后继续按 Token 计费。
因此，公开讨论里有一句我很赞同的话：AI 不需要组织图里的一个格子，它需要一个对它负责的人。
第三派：别争组织图了，先画“工作图”
还有一派认为，问题不是 AI 应不应该塞进旧组织图，而是 旧组织图本来就看不见工作。
它能告诉你销售总监下面有三个经理，却不能告诉你一条线索怎样从市场进入 CRM，谁补充证据，谁判断优先级，谁发出第一封邮件，哪一步由 Agent 完成，哪一步必须由人签字。
所以，比“给 AI 画个框”更有价值的动作，是补一张 工作图（Work Chart）：把任务、决策节点、系统权限、人与 Agent 的交接和最终结果画出来。
组织图回答“谁向谁汇报”，工作图回答“这件事到底怎么穿过公司”。
第四派：岗位说明书不是文案，是配置文件
这派通常来自工程、安全和治理团队。他们不太关心数字员工的职位名叫“智能助手”还是“银河运营官”，只关心它能不能删除数据。
在人类岗位说明书里，“责任心强、善于沟通”还可以靠面试官意会；在数字员工的岗位说明书里，必须写成 可执行条件：允许读取哪些表，允许写入哪些字段，能不能对外发送，单次处理上限是多少，遇到冲突证据时交给谁，什么情况下立即停止。
说得再直白一点：给数字员工写 JD，不是在写一篇关于它的文章，而是在写一份能执行、审计和回滚的合同。
第五派：先别谈晋升，告诉我怎么开除它
这也是我最喜欢的一派。
数字员工不会因为拿不到晋升机会跳槽，但它会因为模型升级、知识过期、权限漂移、负责人离职，逐渐变成一个没人敢动的遗留系统。KPMG、NIST 和身份治理领域的公开框架都在强调 完整生命周期：入职、训练、评测、变更、监控，以及安全退役。
如果一个 Agent 只有“上线”按钮，没有撤权、停用、封存日志和通知下游的退役流程，它不是数字员工。它只是 遗留系统的幼年形态。
03
EVIDENCE
最反常识的研究：叫它“员工”，人类反而更容易少检查
如果故事停在这里，结论似乎应该是：赶紧给 AI 名分，赶紧纳入组织管理。
但一项来自 Boston University、BCG 等研究者的随机实验，给这股热情泼了 一杯很有价值的冷水。
研究者调查了 1，261 名 HR 与财务管理者。31％ 的受访者表示，所在组织已经把 AI 称为“队友或员工”；23％ 表示，公司已经把 AI 放进组织图或工作图。随后，研究者让管理者审核带有预设错误的同一批材料，只改变材料的来源标签：AI 工具、AI 员工或人类员工。
结果不是“所有人都会立刻变懒”。更准确的说法是：在已经把 AI 放进组织图的组织中，“AI 员工”这个框架产生了明显影响。与“AI 工具”相比，管理者的 审核表现下降 16％，发现的错误减少 18％；他们还把约 9 个百分点的责任从自己身上移走，并把约 8 个百分点转给“AI 系统”。
AI 还没晋升，人的警惕性先被降级了。
这件事很像办公室里出现了一位永远不请假的同事。大家下意识认为：既然它有名字、有职位、还有月度绩效，那它应该知道自己在做什么。可问题是，AI 可以承担任务，不能承担后果；可以出现在通讯录里，不能出现在责任主体的位置上。
「
当一个不能承担责任的系统被包装 成“同事”，组织最容易失去的不是亲切感，而是检查它的人。」
这也是为什么，岗位说明书的目标不应该是让数字员工更像人，而应该是让 人类责任更加清楚。
04
OWNERSHIP
所以谁来写？一名业务负责人牵头，六类角色共同会签
先给结论：数字员工的岗位说明书，不应该由 HR 单独写，也不能交给 IT 或供应商代写。它应该由 业务负责人作为岗位发起人和最终 Owner，FDE 负责把业务语言编译成生产规范，再由 HR、IT、安全、法务合规和运营审计共同会签。
为什么 业务负责人必须牵头？因为只有业务能定义“这个岗位为什么存在”“什么结果算完成”“错误的业务代价是什么”。如果这三件事答不出来，技术团队写出的只会是一份功能清单。
为什么需要 FDE？因为业务通常会说：“帮我把高价值线索筛出来。”FDE 必须继续追问：高价值由哪些证据构成？漏掉一个大客户和多报十个普通客户，代价一样吗？结果进入哪个系统？谁可以推翻？规则变了谁更新？
HR 负责岗位命名、组织关系、协作方式和员工沟通；IT 与安全团队把任务边界翻译成 身份、最小权限、日志和撤权；法务合规负责数据、人格、行业规定和对外行为的红线；运营与审计负责持续评测、异常处置和退役。
供应商当然可以提供模板，但不能成为最终责任人。模型也可以帮你起草岗位说明书，但不能批准自己的权限。最后签字的人，必须是人。
05
SPECIFICATION
一份能进生产的数字员工 JD，至少要有九格
人类 JD 爱写“积极主动”。数字员工 JD 最好写“缺少两个必要字段时停止执行，并通知销售运营负责人”。前者适合招聘网站，后者才能救生产环境。
我会把一份 数字员工岗位说明书拆成九格。
第一格：岗位使命
不要写“提高效率”，要写它替哪个角色，在什么流程节点，为谁交付什么可验收结果。例如：“在销售首次联系前，把原始线索整理为 带证据的优先级建议。”
第二格：任务边界
同时写“做什么”和“绝对不做什么”。可以补全信息，不代表可以编造信息；可以建议报价，不代表可以承诺报价；可以标记重复线索，不代表可以删除线索。
岗位说明书里最值钱的一栏，往往是 负面职责清单。
第三格：输入与证据
列出允许使用的数据源、版本、时效、质量要求和引用方式。结论必须能回到证据；证据冲突时，不允许用更自信的语气把冲突盖住。
第四格：工具与权限
把权限拆成“读、草拟、写入、批准、删除”五级，而不是简单写“可访问 CRM”。默认 最小权限，敏感权限按场景和时间发放。能用只读解决的，不要顺手给管理员。
第五格：决策权
明确它能自主执行什么、只能建议什么、必须由人批准什么。尤其要区分 生成答案、改变业务状态、对外作出承诺，这三件事的风险完全不同。
第六格：停止与升级条件
什么情况下必须闭嘴？数据缺失、证据冲突、置信不足、金额超限、客户投诉、系统异常、规则版本不明，都可以成为停止条件。写清升级给谁、多久响应、无人响应时如何降级。
第七格：绩效指标
不要只看处理量和响应速度。至少同时看业务结果、准确性、完整性、人工推翻率、高风险漏判率、异常升级质量、单次有效任务成本和返工时间。
数字员工不领工资，但 Token 账单 会准时去找财务；它不参加绩效面谈，但误删一条生产数据，会让很多人参加复盘。
第八格：人类责任人
岗位必须绑定业务 Owner、技术 Owner 和高风险动作的审批人。更关键的是，每一类可执行动作都要能追溯到 具体复核者。
“大家共同负责”听起来团结，翻译成生产语言，通常是 周五下午五点没人负责。
第九格：变更与退役
记录模型、提示词、知识库、工具和权限的版本；规定谁能变更、怎样回归测试、如何灰度、怎样回滚。退役时要撤销身份和权限、停止调度、封存日志、通知下游，并保留必要的审计证据。
数字员工可以没有年假，但 必须有离职流程。
06
EXAMPLE
举个例子：销售线索初筛数字员工，岗位说明书该怎么写
假设我们要上线一名“销售线索初筛数字员工”。一份还能用的迷你版 JD，大概应该长这样。
岗位目标：在销售首次联系前，根据客户画像、公开信息与历史规则，生成 带证据的优先级建议，减少无效核查时间。
允许做：读取获客来源、公司基本信息和历史互动；补全公开信息；生成评分理由；给销售提供下一步建议。
禁止做：不删除线索，不更改合同与报价，不自动向客户发送消息，不把推断写成事实，不使用未经批准的数据源。
权限：CRM 只读；允许写入“AI 建议”专用字段；不能修改客户主数据；对外发送权限为零。
停止条件：公司主体无法确认、来源互相冲突、涉及敏感个人信息、评分规则版本缺失、单次批量异常升高。
绩效：高价值线索漏判率、销售推翻率、证据完整率、单条有效建议成本、平均处理时长、异常升级命中率。
责任人：销售运营负责人对业务结果负责；数据产品负责人对规则和数据负责；安全负责人审批权限；FDE 维护评测与回滚机制。
退役：撤销 Agent 身份，冻结写入，保存审计日志，通知 CRM 下游流程，确认无残留任务后下线。
你会发现，这份说明书里没有“性格开朗、抗压能力强”。但它清楚地告诉组织：这名数字员工 可以干活，不能许愿；可以给线索打标签，不能替公司给客户打包票。
07
FDE VIEW
FDE 真正要做的，是把岗位说明书编译成生产系统
从 FDE 视角看，写完九格还不算结束。纸面职责必须继续变成 四条可以运行的链。
证据链：每个结论来自哪里，是否过期，能不能回到原文。
执行链：任务如何拆解，调用什么工具，何时停止，怎样重试。
流程链：谁触发，结果写回哪里，下一步由人还是系统继续。
责任链：谁授权，谁复核，谁维护，出事谁接管，怎样回滚。
这也是 FDE 在这件事里的位置。我们不是数字员工的“人力资源部”，也不替业务承担最终责任。我们更像 岗位说明书的编译器：把“帮我提高效率”翻译成任务、数据、权限、评测、异常和回滚，再确保这些定义真的进入系统，而不是停在会议纪要里。
真正上线前，我建议管理者只问 三个问题。
1
这个数字员工做错事时，哪一个具体的人必须解释？
2
它有哪些永远不能做的动作？
3
十分钟内，谁能让它停下来并撤销权限？
三个问题里只要有一个没人回答，就先 别急着给它发工牌。
∞
THE END
结语：数字员工可以没有劳动合同，但不能没有责任合同
数字员工进入通讯录，是一个很有意思的信号。它说明 AI 正从“员工主动使用的工具”，变成“组织主动分配任务的工作单元”。
但名字、头像、邮箱和组织关系，只解决了“怎么找到它”。岗位说明书要解决的是更难的问题：它为什么做、能做到哪、什么时候停、最后谁负责。
所以，“谁来写岗位说明书”的答案，不是 HR、IT、业务或 FDE 四选一。
业务负责人必须牵头，因为结果属于业务；FDE 必须参与，因为模糊职责要被翻译成可执行系统；HR、IT、安全、法务和审计必须会签，因为身份、权限、数据与责任缺一不可。
最后，请把 人类责任人的名字 写得比 Agent 的名字更清楚。
通讯录可以给数字员工一个体面的入职仪式，岗位说明书则要确保：出了问题，它不会成为全公司 最方便的背锅侠。
参考资料
1
Microsoft Learn：《Agent 365 Identity》《Microsoft Entra 如何支持 Agent 365》
2
Emma Wiles 等：《Putting AI on the Org Chart：Evidence on Oversight and Accountability》
3
MIT Initiative on the Digital Economy：《Adding AI to the Org Chart？Do It with Intention》
4
NIST：《AI Risk Management Framework Core》
5
KPMG：《Agents of Change：New Organizational Roles in the Age of AI》
6
中国金融电子化集团等：《大模型驱动的数字员工 3．0 建设应用白皮书》
7
科技部：《新一代人工智能伦理规范》
8
法治日报、云南人大网：《员工数字分身应用须守牢法律边界》
END
我是 AFN。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。
