Hi!I'm KFC?KFC 是 Kong Fei Coco 的缩写。

重复但耗时不长，其实不一定要 AI 化。搭建 AI 也需要时间，后期还需要维护。更何况，AI 本来就抽走了太多执行层的工作：人总需要一些坐在工位上、却可以放松大脑的时刻。

很多时候不是「AI 做不对」，而是「怕 AI 做不对」。在 chatbot 阶段已经出现的置信度问题，在 agent 形态只会更严重。比如对外交付的数据和图表，尤其是向上交付时，很多时候即使可以用 AI，更多业务同学仍倾向于手动完成：一方面，业务同学很难理解模型机制，也就很难判断输出的正确性；另一方面，出错后背锅的还是自己。

对责任和可靠性要求越高，流程就要越死板。通用解法是：写一个足够详尽的需求，产出一个足够详细的任务框架，让 AI 写成固定脚本，再运行。所以，也可以选择一些上古方法，比如搭建几个写满公式的 Excel。古法工作没有什么不好：对于高确定性、经常需要回溯的业务，没有比这更好的方法。

责任是否重大的另一个伴随因素是：如果错误越容易被发现，场景就越适合 AI 化。用 AI 做 PPT 就比做数据分析更合适——审计数据分析结果是否正确的过程，堪比自己拉数；但 PPT 画错了，一眼就能看出来。

大多数业务同学进行 AI 化的核心问题，在于非常缺少对上下文的思考。AI 可以比喻成一个清北复交的实习生：刚来到组织里，虽然有聪明的头脑，但缺乏大量上下文信息。通常，组里会丢给新实习生一大堆 landing 文档让她自行阅读，再让她从简单的工作开始做，有问题再问；当天中午也可能带 intern 吃顿饭，熟悉人员与组织架构。

然而，即使组内有大量文档沉淀，新来的实习生仍无法避免在前两周问大量问题。因为我们很难量化一个新 intern 的初始“上下文”：她不会完全精确地转达此前做过什么实习；即使职能接近，也可能因为组织形式、数据基建与工作习惯不同，出现上下文难以复用的情况。

就像真实实习生来到组里之后，有的人能快速上手，有的人则可能要反复训练才能记住一些上下文；有的人能快速掌握组织风格，有的人则一直处于清澈而愚蠢的状态。所有 AI 产品在得到上下文输入之后，其理解力也会因过往经历与自身能力不同而不同。

业务部门的 AI 转型，应将上下文描述的难易程度作为判断是否使用 AI 的核心因素之一。分析类工作容易 AI 化，核心原因是原材料大多已经是文字：数据库、历史文档；沟通类工作则相对难以 AI 化，因为很难具体描述客户或老板喜欢什么样的风格与内容。简单来说，想象你现在带一个实习生：你会把什么工作交给她，什么工作自己做；又为什么决定自己做；给她布置任务时会怎么说？

再强大的大脑配合残疾的身体，破坏力都是有限的。数据基建能力、权限是否能够打通、运行载体是否稳定、电脑会不会过热，才是现实生活中常常限制 AI 化的重要因素。

不掏钱的 AI 都是好 AI。

特指数据管理非常严格的公司：很多 AI 没办法拉起你的数据或文档权限。请自行进行风险评估。

从套餐角度看，个人订阅套餐的额度往往远大于同价格下公司设置的 API 计费。让公司给你报销 20 美金吧。

如果不涉及非常专项的任务需求，比如代码、设计，那么在普通白领工作的范围内，同梯队的各大 AI 之间没有太明显的区别。

Sorry to tell you, but 有人的地方就有江湖。AI 再怎么发展，组织的本质还是：怎么把一堆碳基生物团结在一起。

不同老板对 AI 的期待当然不一样，但整体可以简单分为两类：一类想降本，一类想提效。

如果你负责相关任务，最好能让你的老板简单地理解这个事实：AI ≠ 许愿神灯。

当老板给你描述 AI 宏图时，建议快速判断：他想要的是降本，还是增效？降本，简单来说就是效率工具；提效，就是增量需求。当然，也可以一起做。