1. 一个让很多人不舒服的判断
“80%的应用会消失，花哨的AI工作流只会生产垃圾，工程思维才是超能力。”这句话出自OpenClaw创始人之口，在圈子里传开之后，我身边做AI产品的朋友分成了两派：一派觉得这是危言耸听，另一派默默把这句话截图存进了备忘录。我属于后者。
先把话说清楚，这篇文章不是来贩卖焦虑的。我想做的事情很具体：把这句话拆开，看看它到底在说什么，为什么一个做AI工具的人会说出“80%的应用会消失”这种砸自己饭碗的话，以及“工程思维”这四个字落到日常开发里究竟长什么样。如果你正在做AI应用、正在搭工作流、正在纠结要不要再叠一层Agent，这篇内容应该能帮你省下不少试错成本。
核心关键词我先摆出来：AI工作流、工程思维、应用消失、垃圾生产、可靠性。这几个词贯穿全文，也是我接下来要反复拆解的对象。
这句话之所以扎人，是因为它同时否定了两件事：一是大量AI应用的存续价值，二是很多人引以为傲的“工作流编排能力”。但如果你真的在一线做过交付，你会发现这个判断并不激进，甚至有点保守。我见过太多项目，演示的时候行云流水，一上真实数据就原形毕露。问题不在于模型不够强，而在于整个系统没有工程约束。
2. 为什么80%的AI应用会消失
2.1 演示态和交付态之间的鸿沟
大部分AI应用死在一个地方：它们只活在演示环境里。演示环境的特征是输入干净、边界清晰、用户配合、失败可容忍。你拿一段精心挑选的文本喂进去，模型输出一段漂亮的结果，台下鼓掌。但真实环境是什么样？输入格式千奇百怪，用户会输入半句话、会粘贴一整篇乱码、会在不该换行的地方换行、会在你以为他要填数字的地方填一段情绪宣泄。
我做过一个内容摘要类的小工具，演示时准确率看着有九成。上线第一周，失败率直接飙到四成。排查下来发现，问题根本不在模型，而在于输入预处理几乎为零。用户从各种地方复制文本，带进来一堆不可见字符、全角半角混排、嵌套的HTML标签。模型没崩，是整条链路没有做清洗和校验。
这就是演示态和交付态的区别。演示态假设世界是干净的，交付态必须假设世界是脏的。80%的应用消失，消失的就是那些只解决了“干净世界”里问题的应用。它们不是被模型淘汰的，是被真实世界的脏数据淘汰的。
2.2 套壳应用的护城河到底有多浅
再说一类注定消失的应用：纯套壳。所谓纯套壳，就是底层能力完全依赖外部模型，自己只做了一层界面和提示词封装。这类应用在早期能跑出来，是因为信息差——很多人不知道怎么调用模型，你帮他封装好了。但信息差是会消失的。
我判断一个AI应用能不能活，会问一个问题：如果把底层模型换成一个能力相当的开源版本，这个应用还剩多少价值？如果答案是“几乎不剩”，那它的护城河就是零。提示词可以被复制，界面可以被模仿，交互流程可以被照抄。真正抄不走的是什么？是你积累的领域数据、是你对特定场景的理解、是你为了处理边界情况写下的那几千行看起来毫不性感的工程代码。
提示：判断自己的项目是否属于“会消失的80%”，最直接的方法就是做一次“换模型测试”。把底层模型替换掉，看核心功能是否还能成立。如果替换后整个产品逻辑崩塌，说明你的价值建立在别人的能力之上，而不是自己的工程积累之上。
2.3 被高估的“能力”和被低估的“约束”
行业里有个普遍的错觉：模型能力越强，应用就越容易做。实际情况恰恰相反。模型能力越强，用户对输出质量的预期就越高，对错误的容忍度就越低。以前模型偶尔答错，用户觉得“AI嘛，正常”。现在模型答错一次，用户直接卸载。
能力提升带来的是约束的收紧，不是放松。而大部分应用开发者把精力全押在“怎么用上更强的能力”，却忽略了“怎么建立更硬的约束”。约束包括什么？输出格式的强校验、关键字段的兜底逻辑、失败时的降级方案、超时和重试机制、成本上限控制。这些东西不酷，但它们是应用能活下来的骨架。
我个人的经验是，一个AI应用里，真正决定生死的代码往往不是调用模型那几十行，而是围绕它的几百行校验、清洗、重试和兜底逻辑。这部分代码没人愿意写，写了也没人愿意看，但它就是护城河本身。
3. 花哨的AI工作流为什么在生产垃圾
3.1 工作流编排的“复杂度陷阱”
现在市面上有一堆工作流编排工具，拖拖拽拽就能连出一条看起来非常高级的链路：输入进来，先过一个分类节点，再分三条支路，每条支路各自调用不同的模型，最后汇总再让一个模型做总结。流程图铺满整个屏幕，发给客户看，客户觉得钱花得值。
但这条链路跑起来是什么样？我实测过一个类似的五节点工作流，单次调用的延迟是简单链路的六到八倍，成本是四到五倍，而输出质量的提升——说实话，在大部分场景下感知不到。更麻烦的是，节点越多，出错概率是乘法关系而不是加法关系。假设每个节点的成功率是95%，五个节点串起来，整体成功率就掉到77%。十个节点呢？59%。你辛辛苦苦搭的复杂链路，一半以上的请求会在某个环节挂掉。
这就是复杂度陷阱：你以为你在提升质量，实际上你在指数级放大失败概率。花哨的工作流生产垃圾，不是因为每个节点做得不好，而是因为节点之间的衔接、状态传递、错误处理没有做好，导致整条链路变成一个不稳定的放大器。
3.2 多Agent协作的幻觉
比工作流更花哨的是多Agent协作。让一个Agent负责规划，一个负责执行，一个负责审查，再来一个负责总结。听起来像一支团队，实际上更像一场传话游戏。信息在Agent之间传递时会被不断改写、丢失、扭曲。第一个Agent理解的任务，传到第三个Agent那里可能已经面目全非。
我做过一个对比实验。同一个任务，方案A是单次调用加一段结构化的提示词，方案B是四个Agent串行协作。结果方案A在准确率上略胜，在延迟上快了一个数量级，在成本上便宜了将近二十倍。方案B唯一的优势是“看起来更智能”，但这个优势对用户来说毫无意义，用户只关心结果对不对、快不快、贵不贵。
多Agent不是不能用，而是要用在对的地方。它适合那种任务本身可以清晰拆分成独立子任务、且子任务之间不需要频繁交换上下文的场景。如果任务本身是连贯的、需要全局视野的，硬拆成多Agent只会让信息在传递中损耗殆尽。
3.3 提示词堆砌与“垃圾进垃圾出”
还有一种常见的花哨：提示词越写越长。我见过一份系统提示词写了三千多字，里面塞满了各种规则、示例、约束、人格设定。写的人觉得这样模型就能“理解”需求了。但实际情况是，提示词越长，模型对其中每一条的注意力就越分散。你写了三十条规则，模型可能只牢牢记住前五条，后面的全凭运气。
更关键的是，长提示词里往往藏着自相矛盾的指令。比如前面说“回答要简洁”，后面又说“要详细解释每一步”。模型面对矛盾指令时，行为会变得不可预测。你以为你在精细控制，实际上你在制造混乱。
注意：提示词不是越长越好，而是越“无歧义”越好。我自己的习惯是，每加一条规则，就问自己：这条规则和已有的规则会不会冲突？如果会，宁可删掉一条，也不要让模型去猜。
垃圾进垃圾出的道理在这里体现得淋漓尽致。如果你的输入本身没有经过清洗和结构化，如果你的提示词本身充满矛盾和冗余，那么无论底层模型多强，输出都只能是垃圾。工作流再花哨，也只是把垃圾从一端搬运到另一端，中间可能还多转了几手。
4. 工程思维到底是一种什么能力
4.1 把不确定性关进笼子
工程思维的核心，不是写出多聪明的代码，而是把不确定性关进笼子。AI系统天生是不确定的，同样的输入可能得到不同的输出。工程思维要做的，不是消灭这种不确定性——那不可能——而是给它划定边界，让不确定性在一个可控的范围内发生。
具体怎么做？举几个我日常在用的手段。第一，结构化输出。不要让模型自由发挥，而是要求它按固定的JSON格式返回，字段名、类型、取值范围全部约定好。第二，输出校验。拿到模型返回后，先过一遍校验逻辑，字段缺失、类型不对、超出范围，直接判定为失败，走降级路径。第三，幂等设计。同样的请求重复执行，结果应该一致，或者至少是可预期的。第四，超时和重试。给每次调用设定明确的超时时间，超时后按策略重试，重试次数用尽则返回兜底结果。
这些手段没有一个是“AI特有”的，它们全是传统软件工程里的老办法。但正是这些老办法，决定了AI应用能不能从演示走向生产。
4.2 可观测性比模型能力更重要
我见过太多团队，把预算全花在模型调用上，却舍不得花一点精力做日志和监控。结果线上出问题的时候，两眼一抹黑，不知道是输入的问题、提示词的问题、还是模型本身的问题。
工程思维要求你假设系统一定会出问题，然后提前准备好排查手段。我的做法是，每一次模型调用都记录完整的上下文：原始输入、经过清洗后的输入、实际发送的提示词、模型返回的原始内容、经过校验后的结果、耗时、token消耗。这些日志平时看着没用，一旦出问题，它们就是唯一的线索。
可观测性还包括指标监控。我会盯几个核心指标：调用成功率、平均延迟、P95延迟、单次成本、校验失败率。这些指标一旦出现异常波动，就能在用户投诉之前发现问题。说白了，模型能力决定你的上限，可观测性决定你的下限。而下限才是用户真正每天感受到的东西。
4.3 成本意识是工程思维的一部分
很多做AI应用的人没有成本意识，觉得调用一次模型才几分钱，无所谓。但当你有了真实用户量，成本会以你想象不到的速度膨胀。我算过一笔账：一个日活一万的应用，如果每个用户每天触发十次调用，每次调用平均消耗两千token，按主流模型的定价，一个月的成本是相当可观的数字。如果你的工作流是五节点链路，这个数字还要乘以五。
工程思维要求你在设计阶段就把成本算清楚。哪些环节可以用小模型？哪些结果可以缓存？哪些请求可以合并？哪些场景可以降级到规则引擎？这些问题不想清楚，产品跑得越好，亏得越多。
我自己的习惯是，给每个功能模块设定一个成本上限，超过上限就触发告警。同时，能缓存的绝不重复调用，能批量的绝不单条调用，能用规则解决的绝不交给模型。这不是抠门，这是让产品能持续活下去的基本功。
5. 从“会用AI”到“会做工程”的实操路径
5.1 第一步：把输入管道做扎实
如果你现在手上有一个AI应用，不管它现在跑得怎么样，我建议你做的第一件事是：把输入管道重新审视一遍。输入管道包括用户输入、外部数据接入、文件解析、格式转换这一整条链路。
具体要检查什么？第一，编码和字符集。确保所有输入都统一转成UTF-8，去掉不可见字符和零宽字符。第二，长度控制。给输入设定最大长度，超长的部分要么截断要么分段，不要让超长输入直接把模型上下文撑爆。第三，格式归一化。全角转半角、多余空白合并、换行统一。第四，敏感内容过滤。这一步既是合规要求，也是防止模型被恶意输入带偏。
这些操作听起来琐碎，但每一条都能显著降低后续环节的失败率。我做过统计，在输入管道上每投入一小时，后续排查问题的时间能省下至少三小时。这笔账怎么算都划算。
5.2 第二步：给输出加上硬约束
输出侧的核心原则是：不要相信模型的自由发挥。你需要用代码去约束它，而不是用祈祷去期待它。
我常用的做法是，在提示词里明确要求模型返回JSON，并给出严格的schema。然后在代码侧，用对应的校验库去验证返回结果。校验不通过怎么办？不要直接把错误结果透传给用户，而是走重试或者降级。重试时可以在提示词里追加一句“上次返回格式有误，请严格按照schema返回”，通常能解决大部分格式问题。
对于关键字段，还要做业务逻辑校验。比如模型返回了一个日期，你要检查这个日期是否在合理范围内；返回了一个金额，你要检查是否为正数、是否超出上限。这些校验逻辑写起来不复杂，但能拦住绝大多数“看起来对、实际上错”的输出。
5.3 第三步：建立失败兜底机制
任何AI系统都会有失败的时候，区别在于失败之后发生什么。没有兜底机制的系统，失败就是白屏、报错、用户流失。有兜底机制的系统，失败只是降级，用户可能根本感知不到。
兜底机制怎么设计？我的经验是分三层。第一层是重试，针对偶发性的超时或格式错误，重试一到两次通常能解决。第二层是降级，如果重试仍然失败，切换到更简单但更稳定的方案，比如用规则引擎返回一个保守结果，或者返回上一次的缓存结果。第三层是兜底文案，如果前两层都失败，给用户一个友好的提示，并引导他换一种方式操作。
这三层机制不需要很复杂，但必须在设计阶段就规划好。等到线上出问题再补，往往来不及。
5.4 第四步：用数据驱动迭代
工程思维不是一次性的，它是一个持续迭代的过程。而迭代的依据，必须是数据，不是感觉。
我会定期看几类数据：失败案例的分布，看看失败集中在哪些输入类型、哪些场景；用户反馈，特别是那些“结果不对”的反馈，逐条分析根因；成本分布，看看钱主要花在哪些环节，有没有优化空间；延迟分布，找出慢请求的共同特征。
基于这些数据，我会有针对性地做优化。比如发现某类输入失败率特别高，就专门为这类输入加预处理规则；发现某个环节成本占比过大，就研究能不能换更便宜的模型或者加缓存。这种数据驱动的迭代，比拍脑袋改提示词有效得多。
6. 常见问题与排查技巧实录
6.1 模型输出格式不稳定的排查思路
这是最高频的问题。模型有时候返回纯JSON，有时候在JSON外面裹一层解释文字，有时候字段名大小写不一致。排查思路是这样的：先看提示词里有没有明确要求“只返回JSON，不要任何额外文字”。如果没有，先加上。如果加了还是不稳定，就在代码侧做容错解析，用正则把JSON部分提取出来再解析。如果提取失败，就走重试。
我自己的经验是，格式问题八成出在提示词不够明确，两成出在模型本身的随机性。前者靠改提示词解决，后者靠代码容错解决。两者结合，格式稳定性能做到99%以上。
6.2 延迟突然飙升的定位方法
延迟飙升通常有几个原因：模型服务端波动、输入长度突增、工作流节点变多、并发量超过限流。排查顺序是：先看是不是所有请求都慢，还是只有部分慢。如果全部慢，大概率是服务端问题，等或者切换备用。如果部分慢，看这些慢请求的输入长度是不是特别大，或者是不是走了更复杂的链路。再看并发量，如果并发突然涨了，可能是限流导致的排队。
我一般会在日志里记录每个环节的耗时，这样一眼就能看出瓶颈在哪个节点。没有这个日志，排查延迟问题基本靠猜。
6.3 成本失控的常见原因
成本失控的原因就那么几个：缓存没做、重试没限制、工作流节点过多、用了大模型做小事。排查的时候，先看token消耗的分布，找出消耗最大的几个功能模块。然后逐个分析：这个模块能不能用更小的模型？能不能加缓存？能不能减少重试次数？能不能合并请求？
我见过一个案例，某个功能每次调用都重新处理一遍相同的系统提示词，而系统提示词有两千token。后来把系统提示词做了缓存，成本直接降了四成。这种优化不需要多高的技术，只需要你去看数据。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决手段 |
|---|---|---|---|
| 输出格式不稳定 | 提示词不明确、模型随机性 | 检查提示词约束、统计失败率 | 加schema约束、代码容错解析、重试 |
| 延迟突然飙升 | 服务端波动、输入过长、并发过高 | 分环节耗时日志、输入长度分布 | 切换备用、截断输入、限流排队 |
| 成本超预期 | 缓存缺失、重试无限制、节点过多 | token消耗分布、调用次数统计 | 加缓存、限制重试、精简链路 |
| 特定输入必失败 | 输入未清洗、边界情况未覆盖 | 失败案例聚类分析 | 加预处理规则、补充边界测试 |
| 结果时好时坏 | 提示词矛盾、上下文污染 | 审查提示词一致性、检查上下文传递 | 删矛盾规则、隔离上下文 |
提示：这张表建议打印出来贴在工位上。我自己的经验是，线上问题九成都能归到上面这几类里。遇到问题先查表，比从头分析快得多。
7. 我对“工程思维才是超能力”的理解
做了几年AI应用，我越来越觉得，这个领域最稀缺的不是会调模型的人，而是会用工程手段把模型能力稳定交付出去的人。模型能力是公开的，谁都能调用。但怎么让它在真实场景里稳定、可靠、低成本地跑起来，这是一门手艺，需要时间积累，需要踩坑，需要耐心。
OpenClaw创始人说80%的应用会消失，我理解他说的不是悲观，而是清醒。消失的是那些只靠信息差和花哨编排撑起来的应用，留下的是那些真正解决了工程问题的应用。花哨的工作流不是不能用，而是不能只有花哨。工程思维不是让你放弃创新，而是让你的创新能落地、能持续、能规模化。
我自己踩过最大的坑，就是早期太迷信“工作流编排”，觉得节点越多越智能。后来发现，真正让用户满意的，往往是那些看起来最朴素、最不花哨的实现。一个稳定的单次调用，配上一套扎实的输入清洗和输出校验，效果远好过一个五节点的华丽链路。
最后分享一个小技巧：每次你想给系统加一个节点、加一个Agent、加一层编排之前，先问自己一个问题——如果去掉这个节点，用一段更严格的提示词或者一段更扎实的校验代码来替代，能不能达到同样的效果？如果答案是能，那就别加。少即是多，在AI工程里尤其如此。
