你不需要什么「AI 调教专家」，你需要的是让运营团队学会用 API

你打开 LinkedIn，看到又一家中型物流公司在招“首席提示词工程师”（Lead Prompt Engineer），开价 £65k。他们想找个能把 ChatGPT 玩得转的人来搞定后台业务。与此同时，他们真正的运营经理正忙着把 PDF 供应商发票手动录入 Xero，因为那个新招来的 AI 专家压根不懂英国的增值税（VAT）规则。

老板觉得自己买到了一套 AI 解决方案。实际上，他只是买了一个非常昂贵的“翻译瓶颈”。

你不需要什么“AI 沟通师”。你需要的是让你现有的财务助理学会怎么把严格的 JSON 模式（schema）传给 API。AI 不是一个能随便挂在公司业务边上的独立部门。它是那些已经知道公司怎么赚钱的人手中的“倍增器”。

领域背景真空（The domain-context vacuum）

当你雇了一个只懂怎么给大模型写提示词、却不懂你底层业务逻辑的 AI 专家时，你就制造了一个运营黑洞，我管它叫“领域背景真空”。你请个提示词工程师来搞邮件自动化，他确实搭了一个很漂亮的集成系统来解析邮件。但他不知道，某个特定供应商的送货延迟会触发你服务等级协议（SLA）里的赔偿条款。

模型完美地提取了文字。但公司照样在赔钱。

英国政府最近发布的 英国劳动力 AI 技能 报告正好指出了这种瘫痪状态。中小企业知道，到 2030 年，提高生产力能带来 £400 billion 的机遇。但雇主们完全误解了“AI 技能”在实际操作中到底长啥样。他们以为 AI 是一门独立的底层技术学科，就像写 C++ 或管理服务器机架一样。

真不是。AI 是一个推理引擎。如果开车的人不认路，推理引擎一点用都没有。

当你雇一个专职的提示词工程师时，你其实是在逼你的业务专家花大把时间给这个新人解释公司的基础运作。然后这个 AI 专家再试着把这些乱七八糟的人类现实“翻译”成系统提示词。翻译过程中会丢掉很多关键信息。最后搞出来的自动化系统非常脆弱——在测试环境里跑得挺好，一旦真实客户发来个稍微特殊点的需求，立马歇菜。

解决办法不是雇更好的 AI 专家，而是教你现在的运营团队怎么用这些模型。

为什么外包的 AI 方案总失败

雇个专职 AI 专家来给业务“贴”自动化标签之所以会失败，是因为他们缺乏实战经验，看不出模型什么时候在一本正经地胡说八道（幻觉），从而导致致命错误。大多数中小企业的套路都一样：买个 ChatGPT Team 订阅，招个初级自动化爱好者，然后让他们用 Zapier 把 CRM 和财务软件连起来。

这种模式我见得太多了。新人搭了一个 Zapier 流程来解析供应商邮件。Zapier 触发 ChatGPT 提取供应商名称和发票金额。在 5 个测试 PDF 上跑得简直完美。

然后到了月底。

实际情况是这样的：AI 专家不知道“供应商 A”和“供应商 A (UK) Ltd”在 Xero 里是两个完全不同的实体，付款条件也完全不同。Zapier 的查找步骤没法做复杂的嵌套判断。所以，当你的 Xero 供应商有一个藏了两层深的自定义联系人字段时，自动化系统就会静默报错，填入空值（null）。

AI 专家会觉得是语言模型又不听话了。他们会花三天时间调温度参数（temperature），重写系统提示词。他们甚至试着在提示词里加全大写字母和感叹号。

真正的核心问题是会计逻辑，不是 AI 逻辑。

因为搭建系统的人不懂业务领域，他们根本没法调试。他们把结构性的数据失败当成了提示词错误。最后你得到的是一堆重复的联系人、缺失的税码，以及一场财务对账噩梦——你真正的会计得花一周时间才能理顺。

背景知识是没法外包的。如果拿 API 密钥的人连什么是红字发票（credit note）都不知道，那每个月 £25 的 API 订阅费也省不下一个 £35k 的人力。流行的建议告诉你需要更好的提示词工程。其实你真正需要的是更好的业务逻辑。

提升那些“懂规矩”的人

一个懂会计逻辑的运营经理，正通过 n8n 向 Claude 传输严谨的 JSON 架构。

构建稳健 AI 系统的唯一可靠方法，是培训你现有的业务专家自己去用工具。你的运营经理已经知道 Xero 的那些怪癖了。你的销售代表已经知道为什么 HubSpot 管道里的某个特定阶段至关重要。教他们模型的运作机制就行。

拿一个标准的应付账款流程来说。你收到一张格式混乱的供应商 PDF 发票。别找外部顾问去弄 Zapier 流程。直接教你的财务助理用 n8n。

他们设置一个 Webhook 触发器来接收邮件。通过 API 节点把 PDF 发给 Claude 3.5 Sonnet。因为财务助理清楚地知道哪些数据重要，他们会为输出定义一个严格的 JSON 模式。

Claude 提取数据并完美格式化。然后 n8n 工作流使用 HTTP Request 节点直接 PATCH（更新）Xero 的发票行项目。

当供应商发来的发票缺了采购订单号（PO number）时，财务助理知道该怎么办。他们在 n8n 里加一个条件路由：如果 PO 字段为空，工作流就给采购员发条 Slack 消息要代码。系统会暂停并等待人工回复，然后再录入 Xero。

这完全避开了“领域背景真空”。搭系统的人完全明白业务流程中哪里容易出错。

在内部搞定这些需要 2-3 周的专注投入。软件成本几乎可以忽略不计，但你团队投入的时间成本大约相当于 £6k 到 £12k 的内部资源。这只是 AI 专家薪水的一小部分。

当系统出故障时（肯定会出故障），搭系统的人就是那个知道怎么修账本的人。他们不需要给外部开发人员提 Jira 工单。他们只需打开 n8n 画布，看一眼 JSON 输出，发现漏掉的税码，然后更新一下模式就行了。

业务专家的瓶颈在哪里

如果输入数据在传给大语言模型之前需要大量的预处理，那么培训自己团队的方法就会遇到瓶颈。你需要知道无代码工具的极限在哪里。

如果你的发票是从老旧财务系统里扫出来的 TIFF 图片，你首先需要专门的光学字符识别（OCR）。直接把模糊的扫描件丢给视觉模型，错误率会从 1% 飙升到 12%。用 n8n 的运营经理很难搭出一个可靠的预处理流水线。他们会花好几周试着改提示词，但模型压根看不清那些像素。

对于需要本地微调模型的高度敏感客户数据也是如此。如果你的合规要求意味着不能把数据发给 OpenAI 或 Anthropic，你就得在自己的硬件上跑模型。这需要部署 Python 脚本、管理服务器基础设施和处理向量数据库。

你的会计干不了这个。你不能指望一个业务专家突然就懂了容器化部署。

在开始培训团队之前，先检查你的数据质量。如果你的数据是干净的、数字化的，且可以通过 API 访问，那就提升业务专家的技能。如果你的数据锁在纸质文件里、老旧的本地服务器里，或者需要复杂的数学转换，那你确实需要一个软件工程师。

要避免的三个错误

1. 1. 不要为了“提示词工程”而招聘：别在职位描述里写要求“ChatGPT 技能”或“提示词工程”。写提示词是一个独立的职业。它是一项基础的计算机素养，就像知道怎么用 Excel 的 lookup 函数一样。当你只为了提示词能力而雇人时，你就是把“领域背景真空”请进了公司。先看业务专长，再测试他们学习自动化的意愿。
2. 2. 不要把 AI 孤立起来：如果你的员工少于 200 人，别设什么“AI 主管”这种职位。一旦你让一个人专门负责 AI，公司里的其他人就不再尝试创新了。你的销售团队会等着“那个搞 AI 的家伙”给他们做工具。你的财务团队会完全无视这项技术。把责任分下去。给你的部门主管预算，让他们自己去做 API 实验。
3. 3. 不要从工具开始：在梳理流程之前，别买软件。不要仅仅因为某个 AI SaaS 平台在演示时看起来很酷，就每个月花 £500 去订阅。如果你的团队没法在白板上画出他们每天的精确工作流，任何语言模型都无法实现自动化。逼你的团队记录下每一次点击、每一个决策和每一个例外。逻辑理顺了，API 调用自然就水到渠成了。