20 多个真实业务课题跑下来，感受越来越清晰：Coze、Dify 这类低代码平台，真正用起来的仍是技术人员。直到 WorkBuddy 出现，没有技术背景的业务人员也能自己搭智能体，把 AI 用到内容生产和管理提效里。

项目做多了以后，有一个感受越来越明显：AI 工具本身已经越来越不是问题了。

前几年大家讲降低 AI 应用门槛，主要依靠的是 Coze、Dify 这类低代码 Workflow 平台。理论上不写代码，业务人员也可以自己搭应用。

但真的推广下来会发现，这类工具虽然叫“低代码”，本质上还是开发。你还是要理解节点是什么、变量怎么传、上下游输入输出是什么……

只是以前写代码，现在变成拖节点。所以最后真正大量使用它们的，还是技术人员，或者至少是具备一定技术思维的产品同学。

但 WorkBuddy 出来以后，这件事情发生了变化。

上一轮培训里，我们已经看到完全没有技术背景的业务人员开始自己搭智能体、配服务器和域名，并直接拿 WorkBuddy 解决真实业务问题。

到这一轮，已经过去1个多月了，这种情况更明显。

很多业务人员已经非常熟练地使用各种 Agent 做分析、处理数据、生成内容，甚至直接让 Coding Agent 帮自己做一个小工具。

而且我发现，WorkBuddy/CodeX/Agent 这个东西其实没那么需要教。你如果会带一个实习生，大概率就已经具备了使用 WorkBuddy 最基本的能力。

给目标、给背景、告诉它边界，让它先干一版，再检查、反馈、修改。

所以这一轮真正反复出现的问题，已经不是“AI 怎么用”了。

因为很多人都觉得自己已经很会用了，现在的问题是：一个想法真正变成 AI 项目以后，中间那些原来被工具和技术挡住的问题，全部开始冒出来了。

这篇就总结几个陪跑过程中我们反复遇到的问题。

功能 ≠ 业务场景

这是非常常见的第一类问题。很多人上来会说：

• 我要一个看板。
• 我要一个聊天窗口。
• 我要一个智能体。
• 我要一个 AI 销售助手。

但这些其实都不是业务场景，它们只是最后希望看到的一个产品形态。

真正的业务场景至少还要继续往下问：

• 这件事情发生在哪个业务环节？
• 原来是怎么处理的？
• 现在卡在哪里
• 最后要产生什么结果？

比如：“我要一个投放看板。”

和：“投放负责人每天面对多个渠道的数据，需要快速找到异常渠道、判断可能原因，并据此调整投放策略。”

完全是两件事情。

前者容易直接进入页面怎么设计、展示哪些指标，要不要加一个 AI 对话框这种细节 UI 问题；

后者会逼着你确认数据从哪来、口径是否一致、判断原因的标准是什么、判断以后采取什么动作、怎么确认动作有效。

上一轮陪跑里，我们就反复遇到类似情况，所以当时一直要求大家按照业务背景 → 目标 → 现状流程 → 差距与问题 → 具体需求 → AI 方案去表达，而不是一上来就讲自己想做什么。

这轮还是一样，AI 项目的第一步，是把我想要什么功能还原成业务场景、把展示需求还原成业务问题，功能是解决方案的形态，场景才是项目真正要解决的问题。

懂业务，不懂实现

这是这次特别有意思的一类问题。

很多业务负责人最开始的状态其实都是：我很懂业务，我知道我要什么，只是不知道 AI 怎么实现。

这个判断本身没有问题，做了十年销售的人是比我们懂销售的，做内容、运营、产品的人，也比外部顾问更懂自己的领域。

但项目往下走的时候，问题会逐渐变成：我知道我要一个结果，但我好像没有认真想过，这个结果到底是怎么判断出来的。

有一个案例特别经典，真的特别经典，我后面可能会说很多遍。

一位同学以前做销售，有一次客户让他推荐产品，他说公司有规定不能直接推荐，客户反而觉得他很靠谱，最后在他这里下了单。

于是他想把大量销售聊天记录交给 AI，让 AI 找出来：到底是哪一句话，让客户突然决定购买？

这里就很经典了，我觉得这里有个规律，但我不知道规律是什么，我让模型给我总结规律，而我也去相信这个规律…

听起来特别像一个非常适合大模型的问题。

但继续往下问：怎么确定就是这一句话造成成交？如果客户前面已经沟通了二十分钟呢？如果其他销售说了类似的话，客户却没有成交呢？

到最后会发现：不仅仅是 AI 不知道答案，业务自己也不知道成交到底为什么发生。但是他们希望 AI 告诉他为什么。

他的经典就在于：业务有明确希望，但说不出中间的判断逻辑。

这种情况我们碰到了很多次。

有团队说：AI 已经帮我写了一版评价规则，但我自己也不知道这套评价到底好不好。

有团队说：我已经把产品立项评估的 workflow 跑通了，但是业务反馈结果不能用，讨论半天发现到底什么叫一个“值得立项的好产品”，这套规则本身就不稳定。

这里面，会做业务和把业务变成了 AI 可以执行的能力之间还有很大的 Gap。

人平时处理这些事可以依靠经验、直觉和上下文判断，但是一旦想把这些事情交给 AI，就必须先把这些隐形的东西显性化。

所以这里又印证了我们听过很多遍的一句话：业务本身清楚，AI 很容易快速放大。业务本身混乱，AI 也会很快产出一堆看起来很完整的垃圾。

公司有数据 ≠ AI 能用

这个问题几乎每个数据类、知识问答类项目都会碰到。

我们问：数据有没有？

很多团队第一反应都是：有啊、公司肯定有。

真正开始做的时候会发现：公司有数据，和项目能使用这些数据，完全不是一回事。

陪跑过程中大概会碰到几种情况。

第一种：压根没有。

业务人员脑子里觉得公司应该有，真正去找才发现根本没人长期沉淀。

尤其是很多所谓的“业务经验”，其实一直存在人的脑子里、聊天记录里或者零散文档里，从来没有按照后续应用需要整理过。

第二种是：有，但不知道或者拿不到

数据分散在不同团队、不同系统、不同人的表格里面。

甚至大家都知道“公司有”，但没人知道到底该找谁，怎么申请，用哪个版本。

第三种是：拿到了，但是不能直接用。

比如知识库项目。

有团队的业务路径已经比较清楚，相关知识也有，但是知识并不是按照梳理的 SOP 调用方式和 AI 使用方式组织好的，需要进行治理，让 AI 可以准确的调用正确的答案。

第四种是：数据和知识都拿到了，但是治理不出来。

因为治理的前提是业务自己知道应该按照什么规则分、什么重要、哪些变量和结果有关。

如果这些本身都没有答案，那数据其实只是存了很多暂时用不上的东西。

项目真正需要的数据基础，需要这些数据和知识能定义、能获取、能计算、能解释、能持续维护。

这也是为什么 AI 项目越往真实业务走，会发现 AI 占整个项目的比例越来越小，业务建模、数据治理和规则治理的比例越来越大。

AI 不准确，怎么办？

这也是大家特别喜欢问的问题：AI 不准怎么办？

最容易想到的是：换模型、改 Prompt、加知识库、继续调。

这些当然都可能有用，但正确的做法应该是先看看给 AI 处理的节点内容有多少，这里大概率是你交给 AI 的这一步本身就太大了。

比如你直接要求一个 AI 节点：根据这个客户所有的信息，判断他现在处于什么状态、为什么、下一步应该采取什么动作，并生成一段可以直接发送的话术。

这里其实至少包含：信息提取、状态判断、规则匹配、知识检索、动作选择、内容生成。

其中任何一个环节出错，最后的答案都会出错，甚至这种情况下我们自己也不知道什么答案是能让我们满意的。

这个时候如果盯着输出改提示词就会特别痛苦。

所以这个时候我们应该看：这件事情还能不能继续拆？

把复杂判断拆成多个边界更明确的节点，每一个节点都只让 AI 做它相对擅长，而且结果可以被检查的事情，这样你才能知道到底哪一步错了，针对那一步单独做优化。

其实有时候我们讲 AI 准确率，其实也不一定是模型的问题，依然还是我们的 SOP 拆解问题，有没有把每一个 AI 节点收敛到模型真正能稳定处理的范围。

另外还有一个问题，调到最后 AI 还是会有处理不了的情况，这套业务流程还能不能正常运行。

前面讨论的是怎么提高 AI 的能力边界，这个问题讨论的是能力边界之外怎么办？

因为无论模型再强，概率性系统都意味着它一定会犯错。

所以我们要解决AI 错了以后的发现、确认、记录和优化的问题。

这样我们就需要有 AI 初步处理 → 人工确认 → 结果执行 → 错误记录 → 反馈优化的流程。

这样即使模型会犯错，整套业务流程依然可控。

Demo 好了，然后呢？

这里是很多项目特别容易跑偏的地方，我们一直在强调“快速做 MVP”，但很多人理解成我做出一个界面，跑通 workflow，Agent 可以回答我问题了，就认为 Demo 完成，项目成立。

但这里其实混淆了好几件事。

Demo 验证的是关键能力可行性，一些关键技术、核心功能，都需要提前进行验证，这是必要的步骤。

Mvp 验证的是最小业务闭环，证明我们前面设计的这条业务路径，在我们预设的环境下用 AI 实现以后能不能产生我们想要的业务结果。

这里我们要做的最小验证是指把验证业务价值所需要的链路缩到最短。

比如一个用户风险预警项目，如果只是数据进去、AI 给出风险评价，只能证明模型有一定的识别能力。

真正的业务验证还需要在风险用户识别出来后，业务人员评估这个判断结果和判断过程，按照建议采取干预工作，观察用户行为变化，最后观察业务指标变化。

这里更接近一个最小业务闭环，这也是上一轮我们为什么一直强调：宁愿先人工复制粘贴，也要先证明这个能力真的有用。

先验证核心能力，再工程化、产品化。

很多人真的很喜欢一开始就考虑企微怎么接，怎么做权限控制，怎么做界面设计，这些都重要，但是如果最核心的业务假设最后都不成立了，前面的工程化工作就全部白做了。

所以这个阶段最重要的是用最低成本，尽快拿到最关键的业务证据。

有价值 ≠ 值得用 AI

这也是陪跑项目做多以后很明显的一个感受，虽然大家都叫 “AI 项目”，但实际难度不太一样。

有些项目特别适合快速做 MVP，特点是人的工作过程基本已经存在。

业务本身知道怎么做，只是希望 AI 帮助提高效率、提高标准化程度或者扩大服务规模。

这种项目特别适合先把 SOP 梳理出来、再做一个轻量 MVP、拿真实样本验证、然后逐渐扩大。

还有一类明显更难，比如业务经营分析、产品立项洞察，这些问题难的地方在于业务本身就还没有稳定的解释框架。

如果连有哪些变量、变量之间是什么关系、怎么判断有效都没有想清楚，那其实应该先做业务研究，这里 AI 反而不是重点。

还有一些问题再往下问，很快就会掉进管理、战略和商业模式。

比如这里面有一个 AI+ 健康创业型项目，创业项目一旦要求证明业务价值，就必须继续回答：

谁会买？为什么买？为什么持续付费？

结果项目团队自己也发现继续讨论下去已经不是 AI 的问题了，重点在商业模式本身还没有想清楚。

所以做 AI 项目得知道什么时候还不应该进入 AI 实现阶段。

此时最正确的处理方式是：先 pass 回业务研究，再想想清楚。

超级 FDE ≠ 组织能力

这一点也是这次很有意思的地方，我们上次陪跑只约了队长，这次陪跑把团队所有成员都拉上了，感受又不一样。

个体 AI 能力强，和团队能不能把一个 AI 项目跑通，其实是两件事情。

很多业务人员现在已经具备了自己做一个局部 AI 能力的能力，但是自己这一小部分流程要服务于公司的大指标的时候是不够的，如果不串起来，那局部效率提升和最终业务价值之间依然隔着很远，所以必然要面临和其他团队或者人员的流程进行对接。

就比如我们之前做的一个视频处理工作流，素材洞察、脚本生成、视频生成就是三个人的独立板块，上下游都要互相问对方：你要什么，我有什么？以及我有什么，你需要什么？

听起来特别简单，但现实里很多跨部门问题恰恰就是这两句话没有对齐。

互相可能都在用自己的标准要求对方，最后每一段看起来都完成了自己的工作，每一段都独立做到了 90 分，但是整个业务链路没有真正跑通，最后的结果可能就是 60 分。

所以这一轮我们把整个团队一起拉进来以后，一个很有价值的事情就是：大家开始真正看到上下游之间的信息差，对齐了双方的评价标准。

你看看，这件事还是和 AI 没啥关系，但是却是 AI 项目真正落地的必要条件。

一个个会用 AI 的超级个体当然有价值，但真正要把这些能力变成组织能力，还需要把这些局部节点串成一条完整的业务价值链中。

结语

最后，回过头来看，以前做 AI 项目，大家觉得最难的是技术。

现在 Agent、Coding Agent、AI 表格这些工具不断成熟以后，“做出第一版”的门槛正在快速下降。

于是过去很多走不出来的问题，现在终于有机会在前面就暴露出来。

然后业务人员就开始悟了。

有业务同学在陪跑的时候说了：原来很多时候是业务自以为了解业务，实际上做不出来可能是业务本身就没理清楚业务逻辑。

还有业务同学第一次上手搭 workflow 感慨：现在我终于理解产研了，工作流这东西太复杂了，怪不得程序员都掉头发。

有一个场景我印象还蛮深的，我们陪一个小组搞到凌晨 2 点，几个纯业务背景的人终于把自己的 Workflow 跑通以后，现场直接高兴的跳起来了。

其实站在我们的角度看，那个 Workflow 其实并不复杂，甚至第一反应会觉得这有啥好庆祝的。

但转念一想，又觉得这件事其实挺了不起的，因为这不仅仅是“学会了几个节点怎么连”。

这是业务专家们第一次经历了把脑子里的业务想法，一层一层拆开变成结构化的 SOP+ 数据，并用低代码作为承载做出来、跑通它。

其中一个同学当时感慨：“是我们之前想简单了，但是跑通的那一刻是我今年最开心的时候，怪不得程序员天天熬夜。”

那个 Workflow 本身可能很简单，但跑通它的那一刻，意味着业务专家真正拿到了 AI 时代的一张入场券。

他知道了“我想要一个结果”和“我能把这个结果做出来”，中间到底隔着什么，就能带着问题在实践中找到最终的答案。