用Claude自动生成新员工IT开通清单

简而言之： Claude能在几秒内把一份岗位定义、一张权限清单和一组市场特定要求，变成一份完整的新员工IT开通清单，并在任何一项发生变化时重新生成。它做不到的是创建账号、审批权限、注册设备——那是身份系统、审批流程，以及Intune或Apple Business Manager的事。把清单当作规格说明，而不是自动化本身。

任何招过二十人以上的公司，某处都躺着一份新员工IT清单。它通常是两年前离职的某个人写的，上面列着一个邮箱账号、一台笔记本、一个去年春天就被替换掉的VPN客户端，以及靠近末尾的一行字："加入相关群组"。没人负责它，没人给它做版本管理，而它被翻出来的第一次，往往是某个周一早上——新人已经站在前台了。

有意思的地方在于，清单本身并不是真正的问题。多数公司大致知道一个新人需要什么。他们缺的是一种办法：让这份知识在十几个岗位、三个国家、以及一个每季度都在变的应用清单之间保持最新，并且能在需要时，为特定的人生成正确的那一版。这是一个"生成"问题，而这恰好是语言模型擅长的事。

为什么入职清单永远是过期的

它们描述工具，而不是岗位。 一份写着"安装CRM"的清单，是在只有一套CRM、所有人用法相同的年代写的。一旦销售、支持和财务需要对同一个系统拥有不同权限，以工具为形状的清单就不再回答真正要紧的那个问题：这个具体的人，应该被允许做什么。

它们只被写过一次，从不做版本管理。 单点登录上线、报销系统换代、终端安全代理被新的替换掉——每一件事都改变了"正确答案"，但没有一件触发过对这份文档的编辑。直到某个新人第三天还拿不到一个显而易见的权限，才有人注意到。

它们默认只有一个市场。 围绕新加坡办公室搭起来的清单，到了上海会悄无声息地失效：采购周期不同、网络可达性不同、适用的隐私法规也不同。团队通常是在第一次为本土市场之外的人办入职时，以最糟糕的方式发现这一点。

它们止步于交接。 多数清单在笔记本交付时就结束了。它们对九十天后试用期结束、权限应当复核这件事只字不提，对反向流程更是完全空白。

没有人拥有它们。 入职这件事夹在HR、IT和用人经理之间，实际上意味着它落在最没法说"不"的那个人身上。文档会腐化，因为维护它不在任何人的考核目标里。

搭一个"识岗位"的清单生成器

让这件事成立的转变很小但很实在：不要再维护清单，改为维护"清单是从什么推导出来的"那些输入。清单本身变成一次性的输出，需要时重新生成即可。

喂给Claude真正要紧的那几项输入

一个有用的生成器需要六样东西，而输出的质量，几乎完全取决于你把它们写得有多诚实。

岗位，用"它做什么"来描述。 不是职位名称，而是它接触哪些系统、做哪些决定。"会处理客户支付数据"这一句告诉模型的东西，是职位名称永远给不了的。

法律实体与市场。 谁雇佣这个人、他坐在哪个办公室、他的数据和设备适用哪个国家的规则。就是这一个字段，把一份通用清单变成了一组真正不同的清单。

设备标准。 这个岗位配什么硬件、由谁供货、本地采购要多久，以及它是公司自有设备还是纳管的个人设备。最后这个区分，几乎会改变后面每一步。

权限映射表。 哪些群组、许可证和应用角色对应哪种职能。这份东西如果存在，通常存在某个人脑子里或某张表格里——把它写下来，是整件事里价值最高的一个小时。

审批规则。 什么可以自动授予、什么需要经理、什么需要数据责任人。模型应该标出这些，而绝不应该替你裁定。

时间线。 第一天之前必须成立的事、第一天当天发生的事，以及第三十天和第九十天的节点。

实操上，把这些做成一小组参考文档，而不是每次对话都粘贴一遍。Claude的Projects功能正是为此设计的——一个该项目内所有对话都能看到的持久上下文——这样岗位矩阵和权限映射表就只住在一个地方，也只需更新一次。具体功能请以Anthropic当前文档为准，因为消费级产品、团队版和API之间的可用能力并不相同。

一种人们真的会照着做的输出格式

让清单按"责任人"而不是按"系统"分组。HR做HR的部分，IT做IT的部分，用人经理做自己的部分，每一组都能原样交给不同的人，无需再编辑。每一组内部按截止时间排序，而不是按重要性——真正要执行的人需要知道的是"什么卡住了第一天"，而不是"什么在概念上最重要"。

每一行都要求四个字段：责任人、系统、必须先完成的前置条件，以及一个可观察的完成判据。"开通邮箱"不是一个清单项。"新加坡租户内已建立邮箱、已分配许可证、已收到测试邮件——IT负责，前置条件为HR档案完成"才是，因为你看一眼就知道它有没有发生。

当你希望输出流向别处时，明确要求一种机器可读的格式。Markdown能干净地粘进多数知识库；CSV能导入工单系统或项目工具。真正的纪律在于：在提示词里把格式固定下来并保持稳定，这样输出就能和上个月那一版做差异对比，变化一目了然。

最后，明确要求模型对不确定的地方做标注，而不是自行填补。它拿不准的条目，应该以一个"提给指定责任人的开放问题"的形式出现。一份悄悄编造出审批环节的生成清单，比一份坦承"我不知道"的清单更糟。

一个真实示例：新加坡的销售 vs 上海的工程师

两个人，同一家公司，同一个入职日期，过了前三行就几乎没有任何共同点。

新加坡的销售需要一台公司配发的Windows笔记本，本地有现货，可以预先注册后再发出，让它在首次登录时自行完成配置。身份这块很直接：企业租户内的一个账号、授予标准办公套件的群组成员身份，以及一个按其负责区域而非全局只读来限定的CRM角色。因为他会接触客户联系数据，清单上应当有一条真正带完成记录的《个人数据保护法》培训项，而不是欢迎邮件里的一句话。手机套餐挂在本地实体下。第一天就能开通，是因为这条链路上没有长周期环节。

上海工程师的清单几乎立刻就分岔了。设备采购是一个有自己周期的本地流程，所以触发日期要往前挪好几周。网络访问是一个设计问题而不是一个勾选框，因为境内办公室对境外协作服务的可达性确实是变量，需要验证而不是假设。适用的隐私法规是《个人信息保护法》，这改变了需要做哪些培训、公司必须能拿出什么证据。内部沟通可能跑在与公司其他部分不同的平台上，这意味着多一个账号，也多一步离职清理。而这位工程师需要生产环境权限——那是两份清单上都绝不该自动授予的那一项。

这个练习的重点不是"模型知道这些差异"——它之所以知道，只是因为你把它们写进了实体与市场这两项输入里。重点是：一旦这些输入存在，为其中任何一个人生成正确的清单就几乎不花成本，而且随着底层事实变化，两份清单都会跟着保持正确。

AI生成清单 vs 静态模板 vs 自动化开通

初始投入 — 静态模板在第一个人身上胜出，此后永远落败。生成方案的成本是花一个下午把权限映射表写下来。自动化开通则是一个有预算的项目，以周计。
半年后的准确度 — 生成方案明显胜出。模板在写下来的那天是准的，之后无声地腐化。生成器的陈旧程度只取决于它的输入，而输入小到真的会有人去更新。
应对非典型岗位 — 生成方案完胜。一个权限受限的外包、一个回聘的老员工、一个市场里只有一名员工的国家经理——这些正是模板覆盖不了、而规则型开通系统需要提变更申请才能处理的情况。
第一天的速度 — 自动化开通胜出，而且差距不小。清单告诉人要做什么；零接触注册直接把它做了。随着人数增长，这才是最要紧的那道差距。
可审计性 — 自动化开通胜出，生成方案次之。开通系统产生日志。生成的清单产生一份带日期、可归档的产物。一个被九个人编辑过的wiki页面，产生的是争论。
出错的代价 — 三者之中，生成方案错了最安全，因为在行动之前有人会读它。一条授权过度的自动化开通规则，是在无人察觉的情况下、成规模地出错——这也正是下文那些审批闸口比自动化本身更重要的原因。

诚实的结论是：这三者并不是竞争关系。生成的清单是规格说明，自动化开通是实现。那些跳过权限映射直接上自动化的公司，最后往往自动化了一组从来没人真正同意过的权限决策。

AI做不了的那部分：审批、设备注册，以及风险更大的那一半

审批是一道控制措施，不是一个步骤。 如果某个清单项授予的是客户数据、财务系统或生产基础设施的权限，就必须有一个具名的人来批准，并且这次批准要有记录。模型可以识别出哪些条目需要审批、应该由谁来批。它绝不能成为做出这个决定的东西，而任何生成的清单都不应被直接接进一个会真正授予权限的系统。

真正的自动化在设备注册这一层。 Windows Autopilot把设备登记到你的租户，让首次登录的用户自动拿到配置、策略和应用，IT完全不必碰这台机器。Apple Business Manager的自动设备注册为Mac、iPhone和iPad提供等价能力，Android Enterprise则为安卓硬件提供零接触路径。三者都要求设备在开箱前就已登记——通常由经销商完成，或通过其硬件标识——这正是为什么采购这件事应该在入职日前好几周就出现在清单上。各平台的具体要求不同且会随时间变化，在据此做设计之前，请以厂商当前文档为准。

真相之源是身份系统，不是那份文档。 一条写着"加入销售群组"的清单，描述的是你的目录服务本来就知道的状态。你越能把权限决策下沉到"按岗位授予的群组"里，清单需要承载的就越少，权限也就越可能是真的正确，而不只是被记录过。

离职是风险更大的那一半，得到的关注却少得多。 漏掉一个入职项，制造的是第一天的不便。漏掉一个离职项，制造的是一个属于已经不在职的人的活账号，而它可以存活好几年。用完全相同的输入、在同一时间生成离职清单，并和入职清单存放在一起——模型可以从同一份岗位描述里同时产出两份，这就消除了"没有离职清单"最常见的那个借口。

把这件事做对：身份、设备注册，以及何时该让IT介入

这底下还压着一个容易被忽略的数据问题，因为这些内容感觉上只是行政事务。一段抽象描述岗位的提示词是无害的。一段包含具名个人、入职日期、薪资档位或私人联系方式的提示词，则是一次涉及个人信息的处理活动，要落到适用的法规之下——香港《个人资料（私隐）条例》、新加坡PDPA，或中国《个人信息保护法》。实操规则很简单：从岗位生成清单，而不是从人。如果确实需要一份带姓名的版本，就在本地把姓名替换进已经生成好的模板里，根本不必把这个人的信息送给模型。如果你用的是API而不是消费级产品，请复核适用于你账号的数据处理条款，两者并不相同。

另一半是清单所指向的那些东西。零接触注册、基于群组的权限授予、以及一条设备合规基线，才是把一份生成清单变成真实工作流的东西，而把它们配置对，是一个配置项目，不是一段提示词。Brocent的移动设备与BYOD管理服务覆盖的正是这一层——注册配置文件、合规策略，以及"公司设备"和"纳管的个人设备"之间的区别。我们的AI+支持服务帮你设计提示词、参考文档和复核环节，让输出不只是快，而是可信；托管IT支持则在流程定义好之后，负责跑通入职—调岗—离职这整条链路。如果底层流程还没被写下来，我们那篇用ChatGPT和Notion自动生成SOP的指南是正确的第一步，因为从一个没有文档的流程生成清单，产出的只是一个听起来很笃定的猜测。Brocent自2007年在北京创立以来一直在亚洲提供托管IT服务，总部位于新加坡，并自2016年起设有香港办公室。

常见问题

它会真的去创建账号吗？

不会，也不该。模型产出的是一份规格说明——什么应该存在、每一项归谁、"完成"长什么样。创建账号、分配许可证、授予群组成员身份，发生在你的身份系统里，理想情况下由基于岗位的群组驱动，而不是靠手工。把语言模型直接接到账号开通API上，技术上做得到，也恰恰因为它诱人而是个坏主意：它移除了那个本来会发现错误的人。

怎么让每个岗位的权限保持正确？

靠维护权限映射表，这是唯一值得真正投入精力的产物。写下每种职能对应哪些群组、许可证和应用角色，在系统新增或替换时复核它，并把它当作清单据以生成的输入。如果你的目录服务已经通过基于岗位的群组授权，这份映射表基本上就是对现有群组行为的描述——顺带也是一个很好的机会，去发现其中某些群组的权限比任何人预期的都大。

离职呢——那不是风险更大的一半吗？

是的，而且通常是被忽略的那一半。在生成入职清单的同时，用同一份岗位描述生成离职清单，并把两者放在一起。它应当覆盖账号停用（而非删除）、会话与令牌吊销、设备回收与擦除、邮箱委派，以及任何只存在于某一个办公室的市场特定系统。要防的失效模式并不是"忘了停用主账号"——而是那个没人记得还连着的第三方工具。

它能处理不同市场的设备与合规要求吗？

只能处理到你告诉它的程度。模型对主要法规有通用认知，但它不知道你的法律实体、你本地的采购现实，也不知道你的哪些系统从哪个办公室能访问。把这些写进"市场"这项输入并保持更新，同时要求输出标注每一条是由哪条市场规则推导出来的，这样错误的假设是可见的，而不是被埋起来的。

一定要用Intune，还是任何MDM都行？

任何能为你的设备组合提供零接触注册的现代MDM都可以。如果你本来就在用Microsoft 365，Intune是自然的选择，因为身份、设备和应用三层在同一个平台上。要紧的不是产品，而是能力：设备在发出之前就已登记、配置在首次登录时自动下发，以及一条访问策略真的可以依赖的合规基线。

岗位矩阵应该放在哪里？

放在一个有版本、可读、且有具名负责人的地方。代码仓库、一个有真实历史记录的wiki页面、或一个启用了版本控制的文档库，都可以。行不通的是共享盘上一张没有归属的表格，因为这套方法的全部价值都建立在"输入是最新的"之上——而一个没人维护的输入，会比它取代掉的那份模板更快地变错。

从哪里开始

挑一个你招得最频繁的岗位，把它的六项输入写下来——岗位、实体、设备、权限、审批、时间线。这就是全部投入。生成清单，然后逐行对照你上一次为这个岗位办入职时"实际发生了什么"，并留意两个方向上的缺口：模型漏掉了什么，以及你的真实流程做了哪些从来没人写下来的事。第二份清单通常更有意思。输入理顺之后，先别做别的，用同一份描述生成离职清单——那是你日后会庆幸自己有的一份。如果你更希望把清单、设备注册和权限模型一起设计好，欢迎联系我们。