最近和几个做AI应用的朋友聊天发现一个挺有意思的现象大家手头的工具越来越强模型能力日新月异但真正要把一个想法落地从“跑通Demo”到“稳定服务”中间要填的坑、要做的脏活累活似乎一点没少。一个朋友想用大模型做个简单的信息抽取服务模型调用、结果解析都很快搞定但接下来呢怎么处理模型偶尔的“幻觉”输出怎么设计重试和降级策略怎么管理不同版本提示词的迭代怎么把单次调用封装成可监控、可运维的服务这些问题让他感觉技术栈的复杂度不降反增。这让我开始思考一个更底层的问题我们总在谈论AI带来的效率革命和成本下降但技术本身带来的“摩擦”真的会消失吗或者说AI在消除旧摩擦的同时是否也在制造新的、更隐蔽的摩擦这个问题远比讨论某个模型又刷新了榜单更有现实意义。它关乎我们如何评估一个AI项目的真实成本如何规划技术路线以及如何避免在技术浪潮中陷入“为AI而AI”的无效内卷。1. 从“一键生成”到“系统工程”被低估的隐性摩擦当我们谈论AI的经济影响时最容易看到的是直接的生产力提升写代码更快了画图更省事了分析报告自动生成了。这给人一种错觉仿佛技术的“摩擦力”正在急剧降低通往自动化的道路一片坦途。然而真实世界的工程实践给出的答案要复杂得多。1.1 显性成本下降隐性成本浮现以内容生成为例。过去制作一份市场分析报告需要分析师收集数据、整理信息、形成观点、撰写成文。现在一个大模型可以在几分钟内生成一份结构完整、数据翔实的初稿。这里的“显性摩擦”——人工收集和撰写的时间——确实大幅降低了。但新的“隐性摩擦”随之而来验证与校准摩擦模型生成的内容其事实准确性、数据时效性、逻辑严谨性都需要人工复核和校准。这个过程可能比从头写更耗时因为你不仅要判断对错还要理解模型产生错误或偏差的原因。风格与一致性摩擦如何让AI生成的内容符合品牌调性、固定格式或特定知识体系这需要设计复杂的提示词工程Prompt Engineering、构建高质量的知识库RAG甚至微调模型。维护这套“控制体系”本身就成了新的技术债务。流程集成摩擦生成的报告如何自动进入OA系统、知识库或发布流程这涉及到API集成、权限校验、格式转换等一系列传统软件开发问题AI并没有让它们变得更简单。核心变化在于工作的重心从“执行创造”部分转向了“定义问题、控制质量、集成流程”。旧摩擦是体力与时间的摩擦新摩擦是认知与系统复杂性的摩擦。后者往往更隐蔽也更难量化。1.2 “AI幻觉”不是Bug而是系统性摩擦的典型代表“AI幻觉”Hallucination常被当作模型不完善的技术问题。但从经济视角看它是新技术引入的、必须被管理和计价的系统性摩擦成本。处理幻觉不是一次性的技术攻克而是一个持续的运营过程预防成本设计更精准的提示词、采用检索增强生成RAG提供准确上下文、使用思维链Chain-of-Thought引导推理。每一项都需要投入专门的设计和调试精力。检测成本建立输出验证机制可能是基于规则检查关键数据、基于模型用另一个模型交叉验证或基于人工抽查。这增加了流程环节和计算开销。补救成本当发现幻觉时如何重试、如何降级例如回退到规则引擎、如何记录错误以供模型迭代学习这些都需要额外的工程设计和资源。一个健康的AI项目预算必须为“管理幻觉”这项摩擦成本预留比例。忽略它项目就会在看似美好的Demo后陷入无休止的修补和信任危机。1.3 工具链的碎片化与选择摩擦开源模型的繁荣如Llama、Qwen、DeepSeek和云服务的多样化带来了巨大的选择空间但也带来了巨大的“选择摩擦”和“集成摩擦”。开发者面临的不再是“用不用AI”而是模型选型摩擦是选用巨型的闭源模型GPT-4、Claude追求效果还是用中小型开源模型追求可控性与成本如何在效果、速度、成本、隐私之间权衡部署环境摩擦本地部署端侧/服务器、私有云、公有云API每种选择都对应着完全不同的运维复杂度、安全责任和成本结构。框架与工具摩擦用LangChain、LlamaIndex来构建应用还是直接用SDK调用用Spring AI集成到Java生态还是自己封装每个框架都有学习成本、局限性且生态在快速变化。这种碎片化意味着技术决策的成本大大增加。团队需要持续学习、评估和迁移这部分精力投入无法直接产生业务价值却是保证技术栈不过时的必要摩擦。2. 摩擦不会消失只会转移和演化那么技术摩擦会随着AI发展而消失吗历史经验告诉我们不会。它只会从一层转移到另一层从一种形式演化为另一种形式。2.1 从“人-机器”摩擦到“人-智能体”协作摩擦过去我们和软件协作摩擦主要在于理解和操作复杂的界面与流程。现在我们开始与AI智能体AI Agent协作。摩擦的性质发生了根本变化目标对齐摩擦如何用自然语言清晰、无歧义地定义任务如何让智能体理解模糊的、隐含的上下文和意图这需要人类提升“与AI沟通”的能力这是一种新的认知摩擦。任务分解与规划摩擦智能体可以执行复杂任务但如何将宏观目标分解为可执行的步骤链Chain of Actions这个规划逻辑本身就需要精心设计或者依赖另一个AI来规划。我们可能陷入“为了自动化而设计自动化”的循环。状态管理与追溯摩擦当多个智能体协作或一个智能体执行长链条任务时如何监控其状态、理解其决策逻辑、在出错时进行干预这比查看软件日志要复杂得多因为决策过程可能是不透明的。项目里提到的“AI小镇”AI Town这类多智能体模拟环境其价值不仅在于演示更在于让我们在一个受控环境中研究和度量这种新型协作摩擦从而找到降低摩擦的设计模式。2.2 从“功能开发”摩擦到“提示工程与评估”摩擦传统软件开发摩擦集中在编写、调试、测试代码。AI应用开发特别是基于大模型的应用摩擦中心发生了偏移提示词开发与维护摩擦提示词Prompt成了新的“代码”。但它难以版本控制差异细微但影响巨大、难以调试效果不好是数据问题、模型问题还是提示词问题、难以复用场景稍变就可能失效。维护一套高效、稳定的提示词库成为核心资产和核心成本。评估体系构建摩擦如何评估AI应用的效果准确率、相关性、流畅度、安全性、偏见程度……需要建立一套多维度的、自动化的评估体系。设计评估指标、制造测试用例、搭建评估流水线这些本身都是沉重的工程负担。迭代与持续学习摩擦模型在更新业务需求在变化如何让AI应用持续改进是定期用新数据微调还是优化提示词或是引入RAG更新知识库这个过程缺乏标准化的工程实践充满了试错。这意味着AI时代工程师的核心技能正在从“编写确定性逻辑”向“设计概率性交互”和“构建评估反馈循环”迁移。后者带来的摩擦目前看来更为抽象和难以驾驭。2.3 基础设施摩擦从“算力稀缺”到“复杂度稀缺”早期AI的摩擦是算力稀缺买不到GPU训不动大模型。现在随着云服务和开源模型的普及算力获取的摩擦在降低虽然成本依然存在。但基础设施的复杂度摩擦在急剧上升。部署与运维摩擦如何在Kubernetes上高效部署和扩缩容一个模型服务如何监控其GPU利用率、响应延迟、错误率如何实现A/B测试不同模型版本如何管理模型的血缘关系和依赖这些问题需要成熟的MLOps能力而这对于许多团队来说是全新的领域。成本优化摩擦推理成本成为持续支出。如何通过模型量化、蒸馏、缓存、动态批处理等技术优化成本如何根据流量预测自动调整资源这需要深厚的系统优化知识和持续的调优努力。安全与合规摩擦数据隐私数据如何进出模型、模型安全防止提示词注入、越狱、输出合规内容过滤……每一个环节都引入了新的技术组件和审计要求。现在阻碍一个AI想法落地的往往不是没有模型可用而是被这套复杂的基础设施需求“劝退”。摩擦点从“有没有”变成了“怎么管得好、用得省”。3. 应对新摩擦从被动接受到主动管理既然摩擦不会消失那么理性的态度就不是幻想其消亡而是学会识别、度量和管理它将其纳入技术经济学的考量。3.1 建立“摩擦成本”的评估框架在启动一个AI项目前除了评估功能价值应有意识地评估其全生命周期的摩擦成本。可以建立一个简单的清单摩擦维度具体问题应对策略举例开发摩擦提示词是否稳定、可复用评估体系是否建立建立提示词模版库搭建自动化评估流水线。质量摩擦如何处理幻觉、偏见、不一致性设计RAG流程制定人工复核规则实现输出验证层。集成摩擦如何与现有业务系统对接数据如何流转设计清晰的API契约使用中间件处理格式转换。运维摩擦如何部署、监控、扩缩容、更新模型采用成熟的MLOps平台或方案建立监控告警体系。协作摩擦人与AI、AI与AI之间如何有效协作明确任务边界设计可解释的交互日志设定人工审核点。通过这个清单可以在项目早期识别高风险摩擦点并分配资源进行针对性建设避免后期陷入被动。3.2 追求“摩擦均衡点”而非零摩擦不同的应用场景对摩擦的容忍度不同。追求绝对的“零摩擦”往往不经济目标是找到成本、速度、质量、可控性之间的均衡点。内部辅助工具可以容忍较高的幻觉率追求极低的开发摩擦。直接使用ChatGPT界面或简单API封装可能就是最优解。面向客户的产品功能必须严格控制质量摩擦和一致性摩擦。需要投入大量精力在RAG、提示词工程、输出验证和人工审核流程上。核心决策系统对可解释性和可控性要求极高可能需要放弃一些端到端的“黑箱”魔法采用更传统但可控的规则引擎与AI结合的方式。技术选型的核心就是选择承受哪种摩擦并管理好它。用大模型处理所有问题可能会在质量摩擦和成本摩擦上失控完全拒绝AI则会在效率摩擦上落后。3.3 投资于“降低摩擦”的基础设施和抽象层历史上每一次技术进步都伴随着新抽象层的出现来封装底层的复杂性例如数据库封装了数据存储的复杂性云服务封装了基础设施的复杂性。AI时代也不例外。未来的竞争力可能体现在谁能更好地构建或利用这些“减摩层”应用开发框架如LangChain、LlamaIndex它们试图抽象化与模型、工具、记忆模块交互的复杂性。虽然它们自身也有学习成本和迭代摩擦但方向是降低整体摩擦。评估与监控平台专门用于评估模型输出、监控生产环境表现、管理实验对比的平台将直接降低质量摩擦和迭代摩擦。智能体编排引擎帮助开发者可视化地设计、调试、部署和管理AI智能体的工作流降低协作摩擦和状态管理摩擦。模型即服务MaaS与精调平台提供一站式的模型选择、微调、部署和运维降低从模型到应用的最后一公里摩擦。对于大多数业务团队策略应该是在核心业务逻辑上直面摩擦、深入优化在通用基础设施上积极采用成熟的第三方服务或平台避免重复造轮子。4. 结论摩擦是进步的刻度也是价值的筛子回到最初的问题AI时代技术摩擦会消失吗答案是否定的。它从显性的、体力的摩擦演变为隐性的、认知的和系统的摩擦。我们告别了手动收集数据的繁琐却迎来了管理数据质量、对抗模型幻觉、集成复杂系统的挑战。这种摩擦的演化恰恰是技术深入骨髓、重塑行业的标志。它意味着AI不再是一个外挂的“神奇工具”而是开始与业务流程、组织架构、成本结构深度耦合。能够系统性地识别、度量并管理这些新摩擦的组织和个人才能将AI的技术潜力稳健、可持续地转化为真正的经济价值。因此面对AI我们或许应该少一些“一键替代一切”的浪漫想象多一些对“摩擦转移”的冷静洞察。下一次当你看到一个炫酷的AI演示时不妨多问一句“演示之外那些看不见的摩擦都被藏到哪里去了我们又该如何为它们定价和付费”这个问题可能比技术本身更能决定你在AI经济中的位置。