AI效率迷思：从90%跨越到100%的工程挑战

利用AI生成草稿、编写代码或制定计划，效率提升了5到10倍。许多人因此断言：AI已经完全接管了任务。然而，在最终交付时，人们意识到——快的是开头，慢的是结尾；节省的是体力，消耗的是脑力。在从0到90%（流程可行）的爆发性效率与从90%到100%（可上线并处理边界情况）的成本急剧上升之间，隐藏着一个吞噬所有收益的陷阱。

使用CodeBuddy搭建了一个“文章编写Agent团队”：scout负责选题，architect设计大纲，writer撰写初稿，reviewer审核，polisher润色。这五个角色各司其职，前三步进展神速——选题仅需2分钟，大纲3分钟，初稿8分钟，不到一刻钟便生成了一篇3000字的技术文章。

随后问题显现。reviewer在审核时能看到writer的完整思考路径（五个角色共享上下文，导致互相干扰，判断缺乏独立性）；每个角色积累的输入输出占满了上下文空间，导致后续角色可用空间缩减，polisher在润色时已出现信息丢失；prompt中设计的send_message互相通信——平台当时并未提供该API，通信机制纯属虚构。

初稿生成耗时13分钟。然而，在reviewer退回修改→writer重写→再审→再改的循环中进行了3轮，累计token消耗达到初稿的4倍以上，总耗时反而超过了人工直接撰写。之前节省的13分钟，随后在50多分钟里被补了回来。

这并非个例，而是一条普遍规律：

0到90%，依赖于大模型的泛化能力，能迅速实现流程贯通。90%到100%，则考验的是确定性、鲁棒性、边界控制及异常处理，难度呈指数级攀升。

第一，大模型的拟合能力极强。仅需少量示例或提示词，即可覆盖大多数常规场景。无论是写代码、翻译、绘制流程图、查询资料还是生成报告——这些任务的主路径，模型均能直接通过。

第二，工具链已基本成熟。RAG、函数调用、代码执行、搜索引擎、MCP工具链一经搭建，基础流程便能运行。搭建一条Agent研发流水线，从需求到代码，仅需两天即可产出Demo。

第三，早期用户的容忍度较高。初涉AI时，人们关注的是“能否实现”，而非“是否出错”。输出有瑕疵尚可接受，能运行即可。在这一阶段，AI显得无所不能。

90%覆盖的是常规路径。剩余的10%包含各种异常输入、歧义、格式错误、逻辑漏洞及边界情况。在真实系统中，10%的异常足以导致100%的失效——用户不会因为“大部分情况正确”就信任一个偶尔出错的系统。

相同的输入可能导致输出不稳定。多轮对话后记忆会出现错乱。规则之间可能互相冲突。Agent今天运行正常，明天换个上下文就开始胡言乱语。

这并非bug，而是大模型的本质特征——它是概率模型，而非确定性引擎。无法通过“优化prompt”来彻底消除这种不确定性。

用户可能会输入各种意想不到的内容。半角与全角字符混用、一个字段中包含三种格式、一个请求同时触发两条互斥规则。常规测试无法覆盖这些场景，AI遇到时往往会“创造性地”给出一个看似合理但完全错误的输出。

一个真实数据：在可观测性体系下追踪一次Agent任务执行，一次完整任务触发了8次LLM调用，消耗12,340 token——这仅仅是“正常运行”的情况。一旦触发反馈回路（reviewer退回、重试、再审），每增加一轮循环，调用量就翻倍。前述的文章写作团队，初稿生成消耗约3,000 token，但三轮退回修改累计消耗超过12,000 token——修正偏差的成本是生成初稿的4倍。

据Anthropic官方数据，Managed Agents相比标准提示循环，任务成功率提高了多达10个百分点。这10个百分点的差距并非模型变得更聪明，而是基础设施层面的失败被消除（会话断连恢复、沙箱兜底、长任务持久化）。换个角度看：标准循环中有10个百分点的失败率来自环境因素，与模型能力无关——这就是90%到100%工程成本的一个侧面。

将这些数据抽象为量级关系：

这并非精确测量——不同领域、不同项目差异巨大——但在多个实际项目中反复验证的趋势是：可靠性每提升一个数量级，投入大约上升一个数量级。后面那10%的工作量，远超前面90%的总和。

90%的可靠性只能做Demo。100%的可靠性才敢说“交给它不会出事故”。在企业级、金融、法律、医疗场景中，这道鸿沟几乎是不可逾越的天堑。没人愿意为“大部分情况正确”的系统背责。更现实的问题是：AI生成的合同条款出现纰漏，谁来赔偿？Agent自动审批流程出现差错，算谁的决策失误？责任链一旦模糊，系统能运行和敢使用就成了两码事。

效率陷阱的完整形态是——难，在于知晓前有沟壑；陷阱，在于误以为沟壑已过，实则尚未开始：

首先是0到90%带来了极强的效率幻觉。撰写初稿、制定方案、生成代码，速度提升数倍，人很容易据此判断——AI已经能完成工作。

随后90%到100%开始暴露可靠性黑洞。格式错误、逻辑遗漏边界、上下文混乱、前后矛盾、幻觉频发。每一个小问题都需要人工校验、修正、兜底、重跑。修正、调试、返工叠加在一起，往往超过原本人工直接做的时间（前述文章写作团队案例中，reviewer退回3轮，累计token消耗达到初稿的4倍以上，总耗时反而超过人工直接撰写）。

最终整体ROI被吞噬。单看“生成”环节，效率爆炸；看端到端交付，快的在前面，慢的在后面。

组织层面的隐蔽陷阱

组织层面还有一层更隐蔽的陷阱：管理层看到0到90%的效率提升，误以为可以大幅提升人效。一线发现90%到100%极难，不敢声张，只能硬扛。结果：指标好看，实际更累。

问题已摆在台面，接下来是：是否存在一种系统化的方式，能将90%到100%的成本降下来？

面对90%到100%的可靠性缺口，最自然的反应有三种：优化prompt、更换更强模型、增加更多测试。但这三条路各自都有结构性天花板。

更好的prompt → 不确定性是概率模型的本质。前文已述——大模型并非确定性引擎，而是概率模型。无论prompt写得多么精确、few-shot示例多么齐全，同一输入在不同上下文下仍可能产生不同输出。Prompt Engineering能提高平均质量，但无法消除概率性波动。将可靠性寄托在“将prompt调至完美”上，无异于用沙袋堵概率的洪水——每堵住一个漏点，旁边又会冒出两个。

更强的模型 → 能力提升但可靠性未根本改变。据Anthropic官方数据，同一模型在标准提示循环和Managed Agents环境下，任务成功率差距可达10个百分点——此差距源于基础设施层面失败的消除（会话断连恢复、工具执行沙箱兜底、长任务持久化保障），而非模型推理能力变强。换言之，模型升级解决的是“能否做到”的问题，而非“做到后能否稳定复现”的问题。GPT-4照样幻觉，Claude照样偶尔跑偏——更强的模型抬高了天花板，但地板未随之抬高。

更多测试 → 长尾场景写不完。用户会输入各种意想不到的内容——半角与全角混合、一个字段塞三种格式、一个请求同时触发两条互斥规则。长尾是无穷的，测试用例是有限的。靠穷举覆盖所有异常，与靠人工审核每一条Agent输出一样，都是不可持续的。

这三条路的共同点：都在试图让模型本身更可靠。但如果不确定性是概率模型的结构性特征，解法就不能仅在模型内部寻找——需在模型外部构建工程体系来兜底。

Harness Engineering切入的正是这个位置。它不优化模型本身，而是优化模型运行环境——将AI从“高效率的不稳定生成器”转变为可复用、可上线、出现问题有兜底保障的自动化单元。

具体对应方式：

这五个要素并非让AI更聪明，而是让AI更可控。它们组合在一起，归根结底做的是一件事：通过工程化手段将90%到100%的非线性成本曲线压平一些。

并非所有场景都需要跨越90%到100%这道悬崖。内部原型、一次性脚本、探索性分析——这些场景90%就够了，强行堆到99.9%反而是浪费。关键在于先判断具体场景需要几个9的可靠性，再决定投入多少工程量。

三个维度做决策：

判断自身所处阶段很简单：若不敢不盯着AI运行，则仍在90%以内。唯有当AI能在无人值守下持续产出可靠结果，才算真正跨过了那道坎。

Harness Engineering并非银弹，不会让这道坎消失。但对于需要持续运行、对可靠性有要求的系统，它提供了一套系统化方法：约束管住行为、反馈回路保证质量、可观测性让问题可追溯——层层叠加，每加一层，就能更放心地少盯一点。

从能用走向可用，中间隔着一道工程鸿沟；从可用走向可靠之间还有一座山，而大多数人在第一道沟前就停下了。认清这个成本结构，才能不陷入效率陷阱。前面90%的速度感是真的，后面10%的工程量也是真的——快的部分不能省去慢的部分，这才是AI工程化最该记住的一句话。

本文由本人构思并把控，借助AI辅助整理成文，仅代表个人观点，欢迎交流。