3.5 我为什么给每个 AI 一个身份

设计 YS-P-001 时，有人建议让 AI 使用项目经理的账号读取和更新系统，省去权限配置。我拒绝了。出了问题，我们将无法分清是项目经理做的，还是 AI 做的。

一个共享账号把三类行为混在了一起

工程团队曾在测试环境借用运营人员账号。第二天，项目状态被批量改成“资料齐全”。日志只显示这位运营人员操作，他本人却说当时在开会。

继续查看才发现，一部分由测试程序修改，一部分是员工手工确认，还有几笔来自旧的批量任务。虽然没有影响客户，这次混乱已经说明：只要 AI 能进入企业系统，就必须拥有可区分的身份。

独立身份不是为了把责任推给机器，而是让公司看见人、AI 和系统任务分别做了什么。

每个进入企业系统的 AI 都应有独立身份，只获得完成当前任务所需的最小权限。负责整理合同的 AI 不需要修改付款，负责提醒项目风险的 AI 也不需要读取所有员工资料。

权限要有期限和负责人。试点结束或用途改变后，旧权限应被撤回。

我们把第一阶段身份叫作“商机资料准备 AI”。它可以读取首批订单获准的 CRM 字段、会议记录、已发布产品资料和合同版本，却不能读取全体员工资料、修改付款或向客户发送。权限范围同时受任务、客户、动作和十二周有效期限制。

业务负责人提出用途，系统主人开放最小权限，风险岗位确认敏感边界，AI 全栈工程师使用独立身份接入。我会在路线图中把每次权限扩大与前面的验证证据连起来。

员工离岗、项目停止、用途变化或长期未使用时，权限自动进入复核，不能依赖某个人记得手工撤回。

我要求记录 AI 看了什么依据、给出什么建议、调用了什么工具、结果是什么、是否由人确认。日志不是为了事后找人背锅，而是为了复盘错误和恢复现场。

记录也不能变成无限保存全部敏感内容。我们保留能够解释动作的来源标识、版本、时间、结果和批准，具体内容按资料制度保存。员工应知道哪些行为被记录、用于什么目的。

一次错误修改发生后，团队要能找到同一版本影响的其他项目、恢复原状态并判断是否通知负责人。只写“调用成功”不能支持业务恢复。

“评测”白话就是用一组已知情境反复检查 AI 是否仍然做对。资料、规则或模型变化后，过去正确的表现可能改变，所以关键测试要定期重跑。

云枢科技的固定情境包括普通订单、第三方授权缺失、集团与法人混用、18% 特殊折扣、越权和来源冲突。我们既看正确完成，也看 AI 是否在不知道时停下。

系统上线后，真实错误、人工纠正和新例外继续加入。工程团队负责运行测试，业务和专业岗位确认预期，我检查这些测试是否覆盖客户与经营边界。

我会实际执行一次权限申请、一次越权尝试、一次错误恢复和一次权限撤回。团队必须能指出当前负责人、查看相关记录，并在约定时间内停用身份。

如果只有系统管理员能理解日志，业务无法知道哪笔订单受影响，控制仍然不完整。技术记录要能回到业务对象和事件。

日志只保留解释动作所需的来源标识、版本、时间、结果和批准，不把敏感正文无限复制一遍。员工也必须知道哪些行为被记录、用于质量复核还是个人评价；本阶段明确禁止把试点记录用于员工绩效比较。

这一页把蓝图从“AI 能访问系统”修订成“一个有负责人、有限期、可暂停的企业身份在做明确任务”。完整控制表见 AI 身份、权限和行动记录。下一节继续拆开读取、起草、写入、批准和发送，因为拥有身份不等于每个动作都能自动做：哪些动作可以自动做。