不少企业已经买了 AI 工具。
员工可以让 AI 写文案、总结会议、生成代码；老板也看过演示，觉得效果不错。可过一段时间再问："它进了哪些日常流程？帮业务解决了什么问题？"答案往往不太具体。
问题不是工具不够强，而是工具能力和企业真实工作之间，还隔着一段落地工程。
AI 要进入企业，至少得回答几个问题：
- 它使用的资料从哪里来，是否可信、是否过期？
- 它能不能访问企业的系统和数据，权限怎么控制？
- 哪些步骤可以让 AI 执行，哪些必须由员工确认？
- AI 答错了怎么办？异常任务交给谁？
- 员工为什么愿意换一种方式工作？
- 怎么证明新流程比旧流程更好？
这也是我开始做 FDE 服务的原因：不只帮企业选工具，而是围绕具体业务场景，把咨询、技术定制、自动化、培训和持续陪跑串起来，让 AI 真正进入工作流程。
Codex 和 WorkBuddy 很重要，但它们不是完整的企业落地方案
Codex、WorkBuddy 这类工具提供了通用的 AI 能力。它们可以帮助用户读写文件、生成代码、处理资料、调用工具或执行任务，是很好的工作入口。
但企业真正遇到的问题，往往不是"有没有一个 AI 对话框"，而是：
- 公司的制度、产品信息和操作流程如何安全地交给 AI？
- AI 如何与现有的表格、CRM、ERP、飞书或钉钉协作？
- 如何保证不同员工拿到符合权限的资料？
- 如何把一个人有效的用法沉淀成团队共同使用的流程？
- 工具更新、资料变化之后，方案由谁维护？
所以，我不把 Codex 或 WorkBuddy 看成需要被替代的对象。它们可以是方案中的工具底座。FDE 的工作，是让工具适配企业的流程、资料、系统、权限和人员分工。
可以把区别粗略理解为：
| 角色 | 主要解决的问题 |
|---|---|
| Codex / WorkBuddy 等工具 | 提供通用模型能力、Agent 能力和操作入口 |
| 企业自己的业务团队 | 知道实际流程、规则、数据和责任边界 |
| FDE 服务 | 把通用工具与企业业务结合，做定制、验证、培训和交接 |
企业不一定要从零开发一个"自己的大模型"或"自己的 Agent 平台"。很多时候，在现有工具上补好上下文、接口、流程和验收，就能解决一个具体问题。
AI 落地难，先是技术问题
1. AI 会生成听起来正确、实际错误的答案
大模型根据上下文生成内容，不是企业制度的天然权威来源。资料缺失时，它可能补出一个看似合理的答案；规则冲突时，它也可能挑错依据。
因此，企业问答不能只检查"说得像不像"，还要检查：
- 答案是否能追溯到具体资料；
- 资料是否为当前有效版本；
- 没有依据时是否会明确表示不知道；
- 高风险问题是否会转交给员工；
- 错误是否会被记录并用于后续修正。
把文件一股脑上传，不等于完成了知识库。资料的来源、有效期、权限、负责人和冲突处理规则，都影响结果。
2. 同一个任务，输入细节不同，结果可能变化
在个人试用中，偶尔改改提示词、重新问一次，通常还能接受。但在企业流程里，输出可能影响客户回复、报价、审批或内部决策。只靠"员工自己多试几次"并不是稳定的交付方式。
需要为真实业务准备测试问题：常见输入、边界输入、缺资料的输入、容易混淆的输入。每次修改流程后，用同一批问题回归测试，观察准确性、完整性、耗时和人工修正量有没有变化。
3. 企业需要的不是"会回答"，还要"能按规则做事"
比如，AI 能生成一封客户回复，并不代表它就可以直接发出去。真实流程还涉及客户身份、订单状态、退款规则、审批权限、发送记录和异常处理。
涉及确定性计算、金额、库存、权限判断等环节时，不能把所有逻辑都交给自然语言模型。该用 API、数据库查询、规则或脚本的地方，就应该用确定性的方式处理；AI 更适合理解意图、整理内容、辅助判断和生成草稿。
4. 系统接入会带来新的边界和责任
一旦 AI 需要读取企业系统，就要讨论账号、权限、日志、敏感数据、接口稳定性和失败后的回退。能在个人电脑上演示，不代表就适合全公司部署。
因此，企业落地方案既要问"能不能做"，也要问"应该让它做到哪一步"。
组织问题同样不能绕开
即使技术方案可行，员工和组织也未必准备好了。
一线员工知道流程中的例外和真实卡点，但可能担心 AI 增加工作量，或担心用好了反而被要求承担更多任务。团队成员可能各自使用不同工具、不同版本的提示词，经验留在个人电脑里。管理层则需要明确：谁负责业务规则、谁提供资料、谁审批结果、谁处理异常、试点达到什么标准才继续扩大。
所以，FDE 服务不是做完一个工具就结束。通常需要反复和员工沟通，但每次沟通目的不同：
- 诊断阶段，听员工讲实际流程和例外情况；
- 原型阶段，让真实使用者拿真实任务试用；
- 迭代阶段，确认问题出在资料、工具、流程还是培训；
- 交接阶段，确认员工能独立使用，团队知道谁维护、谁处理异常。
这不是反复讲课，而是让方案逐步适配真实工作。培训是其中一环，不是全部。
用 AKA 把落地方案拆开
我用 AKA 作为企业 AI 落地的思考框架：
- A · Agent：由 AI 理解任务、生成内容或调用工具；
- K · Knowledge / Database：给它可信的企业知识、规则和业务数据；
- A · Automation：把稳定、可检查的步骤连接起来，形成可运行流程。
可以把它理解成三个连续问题：
谁来处理任务？
它依据什么资料和规则？
哪些步骤可以稳定地自动执行？
以"辅助处理售后工单"为例，流程可以先设计成这样：
收到工单
→ Agent 判断问题类型并提取关键信息
→ 从知识库检索有效的售后政策和产品说明
→ 查询业务系统中的订单状态
→ 生成回复草稿并附上依据
→ 高风险问题交由员工确认
→ 记录处理结果和用户反馈这里，知识库负责相对稳定的政策和说明，数据库或业务系统负责变化中的订单状态；自动化负责连接步骤；人工审核负责接住高风险和不确定情况。
这只是一个通用示例，不是所有企业都应照搬。具体方案要根据业务流程、系统条件和风险重新设计。
我提供的 FDE 服务，覆盖从诊断到使用
我做的不是单一工具销售，也不是只交付一份咨询报告。服务会按企业实际情况组合：
咨询与业务诊断
和负责人、一线员工一起梳理当前流程，找出重复、耗时、易错或等待时间长的环节，判断哪些问题适合 AI，哪些更适合改流程或用普通软件解决。
阶段产出可以包括：现状流程、痛点清单、资料与系统条件、风险边界、试点建议和验收指标。
AI 深度定制
在 Codex、WorkBuddy 或企业已有工具上，按业务场景定制知识库、Skill、Agent、小应用、接口流程或权限安排。优先组合现成能力，只有在标准工具确实覆盖不了时，才考虑额外开发。
目标不是堆技术名词，而是让方案能在企业现有环境里运行、检查和维护。
自动化流程
针对重复、规则清楚的步骤，设计触发条件、处理流程、人工审批点和异常回退方式。自动化不等于"全自动"：哪些步骤可自动跑、哪些必须有人确认，要根据出错成本来定。
培训与带练
围绕员工的真实任务做培训：先拆清楚操作，再针对具体问题答疑，最后让员工亲手完成任务。培训结果看能不能独立复做，而不是看 PPT 是否讲完。
陪跑与持续迭代
试点期间持续收集员工反馈和运行问题，调整资料、规则、自动化步骤和使用说明。试点有效，再讨论推广到更多场景或团队；效果不明确，就继续调整或停止，不默认扩成大项目。
项目怎么开始：先小范围验证，再决定是否扩大
一个常见的推进顺序是：
- 梳理现状：访谈业务负责人和一线员工，画出实际流程。
- 确定试点：选一个边界清楚的场景，确认参与人、周期、权限和基线。
- 搭建原型：组合 Agent、知识库、数据库、接口或自动化流程。
- 真实任务测试：记录准确性、处理时间、人工复核、异常和返工。
- 培训与验收：让员工实际使用，按事先约定的指标判断效果。
- 交接或扩展：有效就明确维护责任并逐步推广；不合适就调整或停止。
验收不一定只看"省了多少人"。也可以看处理时间、错误率、返工量、响应速度、员工采用率和人工复核成本。选什么指标，要回到客户最初想解决的问题。
什么样的企业适合开始？
如果你们有一个反复发生、影响明确的业务问题，有业务负责人愿意参与，也能安排员工和必要资料做小范围试点，就可以从一个场景开始。
如果还没有明确负责人、数据权限不清楚，或者期待一次部署就让全公司完全自动运行，最好先把目标和边界讨论清楚。
我做 FDE，核心是用 AKA 把企业的工具、知识和流程连接起来，再通过咨询、定制、培训和陪跑，让员工、团队和组织一起完成落地。
如果你正在评估企业 AI 落地，可以在掘金评论或私信我，简单说说行业、想改善的流程、现在最卡的一步。我们先判断这个问题适不适合 AI，再讨论是否值得做试点。