为什么AI出现这么久了,你公司的工作效率一点没变?

01 / 从我们的模式说起

产品交了，谁来用？课上完了，谁来做？

举个例子：我们做企业AI服务，采用的是「AI培训＋产品交付」。只交产品，员工可能不知道该放在哪一步用，遇到异常也不敢判断；只做培训，课上会了，回到公司也可能没有合适的工具、数据入口和维护的人。所以，培训要拿真实工作来练，产品要跟着使用反馈改。培训和产品交付，得围绕同一项工作一起做。工具有了、人也学了，事情就能顺利推进吗？

02 / 从步骤问到经验

凭什么让销售主管交出那套话术？

FDE（Forward Deployed Engineer）是贴近客户一线的工程角色。以Palantir的FDSE岗位为例，工作从客户痛点延伸到原型、数据集成和反馈迭代。[1] 但走进业务，不代表别人会把经验全盘托出。拿销售话术来说，表格能记下「客户嫌贵时怎么答」，更难拿到的却是：什么时候别急着报价，哪句话只适合熟客。你想把这些判断做进AI，他有理由先问：经验给谁用？贡献怎么算？我被替代了怎么办？出错找谁？在谈数据采集之前，先回答他为什么值得参与。

03 / 换个座位看项目

员工怕白交经验，老板怕白花投入

老板也有自己的账：培训花了钱，骨干学会AI后离职怎么办？懂业务的人走了，留下的产品谁维护？员工关心经验怎么被使用，老板关心投入能否留下来，一线同事还会看这套东西有没有让自己多填一遍表。同一个项目，各方计算的收益与代价并不一样。把这些顾虑都归成「不愿意拥抱AI」，问题只会藏得更深。点开下面这张提案，换个座位看一遍。

04 / 参与的理由要具体

分享之后，他能得到什么？

对销售主管来说，一个值得参与的结果，可能是少回答新人重复的问题，带团队时不用每次从头讲，经验贡献也能被看见。但这些好处不能只停留在口头。先和企业约定：哪些资料可用、谁能访问、内容由谁确认、贡献如何记录，发现错误又怎样修正。资料访问的约定，也要落实到工具权限里。[3] 采集经验本身也占时间，不能把额外工作悄悄推给最熟业务的人。分享的用途、回报和责任，要在开始前谈清楚。具体安排，需要企业和参与者共同确认。

05 / 模型之外的工作

流程走不通，先看谁能拍板

做着做着，你可能发现：卡住项目的，是销售和运营对「有效客户」的定义不同；是没人负责更新资料；是产品已经省了时间，旧报表却还要求再填一次。这些问题会牵动岗位分工、汇报关系，甚至考核口径。我们的FDE服务要识别卡点，并找到有权推动改变的人；技术团队不能替企业单方面改考核。需要把问题分清：哪些改产品，哪些改流程，哪些必须由管理者做决定。不分清责任，模型再聪明，也会被塞进一套走不通的工作里。

06 / 为什么老板要亲自下场

有人要为那些承诺负责

这也是我们选择让老板亲自参与FDE的原因。早期项目里，服务方负责人要亲眼看见客户怎样工作，判断该承诺什么、投入多少、先解决哪一段。遇到顾虑，要能听出原因，再和客户的负责人、业务骨干一起商量试点。先从一个任务做起：约定范围，带着产品练，按反馈继续改。[2]听懂顾虑、协调分工，再把承诺做成可验收的结果。这既考验技术与判断，也考验沟通与分寸。00后的身份不会自动带来信任，信任得靠这些具体的事建立。

07 / 亲自做，然后交得出去

项目不能一直等老板来救场

亲自做，是为了把交付方法沉淀下来。培训时让员工用自己的任务练，试用时把不会用、不好用和不愿用分开记录，再分别补教学、改产品、谈协作。对老板担心的人才流动，也不能许诺「培训后就不会走」。可以做的是逐步留下可维护的工具、清晰的操作方法和多人能接手的能力，让项目少依赖某一个人。最后要能把工作交给团队，把异常交给明确的负责人。下面四个问题，值得在下次AI项目开工前，一起填一遍。

NEXT / 下一期

当AI能替你操作，权限该给多大？

会写话术之后，下一步可能是替你发消息、改客户记录。能力加上权限，才会变成真实动作。下一期，我们聊聊哪些权限可以先给AI，哪些动作值得留给人确认。

欢迎关注一帧万象。也欢迎留言：你更担心AI不好用，还是团队不愿用？

一帧万象

AI时代，把交付做稳。

参考资料与延伸阅读

[1] Palantir｜Forward Deployed Software Engineer — US Government

[2] Anthropic｜Building effective agents

[3] OpenAI｜A practical guide to building agents