很多团队还在为员工提示词写得不够好而组织培训，一个反常的部门顺序却先冒了出来：在 OpenAI 内部，最早把日常工作大量交给 Agent 的除了编程，就是法务。法务对 AI 的早期采用，很难用技术熟练程度单独解释。
受访者给出的解释很实在。写代码早，是因为原本就有本地代码和命令行环境；法务早，是因为审核需要的合同、规章和过往案卷，老早就规整地放在模型可以直接打开的文档里。至于其他业务岗位迟迟没跑通，症结往往在输入端——干活需要的材料分散在各个系统，Agent 根本拿不到。访谈视频的 13–15 分钟谈的就是这件事。
这让我重新看待“AI 原生公司”这个说法。给员工配账号，再要求大家多用，能提高使用率；组织是否因此变得更能完成工作，还需要另一套检查。
我会先看一项真实任务：做完它需要哪些材料，Agent 实际能读到多少，哪些动作仍然要人搬运。任务卡住时，原因可能还没到员工会不会使用 AI 那一步。
人平时工作，手里拿到的往往比一份正式文档多。最新决定可能在聊天记录里，表格还没更新，客户刚补的条件在邮件附件里，负责人知道哪个版本已经作废。这些信息靠人与人之间的联系拼在一起。
换成 Agent，它通常只能根据被送进来的那一部分作判断。缺材料时，模型未必会清楚报告缺了什么。它还可能给出一份完整、流畅、却沿用旧条件的结果。
这样的输出会制造一种误会：工具已经接入，答案也生成了，所以工作环境已经准备好。实际上，员工下一步仍要找附件、对版本、问负责人，再把修正后的材料重新交过去。
员工与 AI 的对话更熟练了，整个任务的等待却可能没有减少。
因此，在把采用不足解释成员工“不愿改变”之前，需要先排查他们手上的条件。同一个工具、相同的培训，面对能直接访问的资料和分散在几个系统里的资料，完成任务的难度并不相同。
这也不意味着把所有数据都开放给 AI。材料能被找到，还要能判断是否有效、是否属于当前任务，以及当前员工是否有权使用。过期文档和未经授权的信息被接进来，只会把另一类问题带入工作流。
模型能力同样有影响。文件能读到，不保证它能理解；接口能调用，不保证它能完成一段复杂任务。访问条件需要与能力一起验证，不能用“都连上了”代替一次实际交付。
但访问条件改善后，组织仍然可能只有少数人用得好。
一个熟练员工会挑材料，知道什么结果不对，还懂得补充模型没看到的前提。最后那份结果包含了他的经验。换个同事照着同一句提示词操作，未必能重复成功。
这时，分享提示词只能传递流程的一小部分。选哪些材料、怎样确认版本、什么时候停止、结果由谁接受，往往还需要不断去问那个熟练的人。
个人会用 AI，不会自动变成团队可以重复使用的能力。
我更愿意用一个朴素的问题检查这种转变：下次同事做同样的工作，还需要把那个高手叫过来吗？
减少的是机械询问，保留下来的是需要经验的判断，说明流程开始能被复用。连选什么附件、去哪里取数都必须找原来的操作者，能力就仍然集中在他身上。
访谈整理的公开预览提到了财务人员开发应用、同事为同事制作工具。这提供了一个具体方向：把反复需要人工协助的步骤做成其他人也能使用的入口。
这个例子不要求每家公司都去开发一批内部应用。反复发生的任务，也可能只需要固定资料位置、明确有效版本，再把结果检查方式留在团队能找到的地方。
做法的大小要跟问题匹配。一次性的探索没有必要包装成系统；每周都会重复、而且总要找同一个人帮忙的工作，才更值得整理。
原来的操作者也不能就此退出。数据来源会变化，部门会调整口径，工具会失效。大家开始依赖一个入口以后，谁负责发现错误、谁维护规则，都需要有人承担。
否则，一次成功演示会变成另一套没人管理的内部工具。账号用得更多了，等待修复和核对结果的工作也跟着增加。
所以我觉得，“AI 原生”至少应该接受结果上的检验。材料能否在合法权限下获得；有效做法能否交给其他人使用；遇到异常时，是否仍有明确的人接手。聊天框里的活跃程度，回答不了这些问题。
OpenAI 的经验只能提供线索。它接近模型研发，有强烈的内部试用动力，工具与组织条件也不同于普通公司。部门采用的先后顺序，不能直接用来预测其他公司的转型路径。
下一次讨论采用率时，我会挑一项团队重复做的工作，从资料获取一路跟到结果被接受。记录等待发生在哪里、哪些步骤仍依赖某个人，再决定改信息接入、整理流程，还是补使用训练。