AI提效，本质上是工程问题，而不是技术问题

今年，各公司纷纷将重心放在 AI 上。随着半年的“热火朝天”，AI 领域也开始出现了名词膨胀的现象，仿佛流畅说出各种高大上的概念，就代表对 AI 有了深入理解，以便升职加薪，或是吸引流量、贩卖焦虑。

本文，我想表达一个观点：AI 提效，本质上是工程问题，而不是技术问题。

一、模型真的有那么重要吗？

很多团队在推进 AI 项目时，仍把大量精力放在模型选型上。客观上讲，不同模型是有差距的，甚至相当大。然而，目前 AI 模型的演化速度如同摩尔定律一般，于是我经常问我自己几个问题：

• 我的场景真的需要追最先进的模型吗？
• 这么高的 token 成本，减去人力上的节约，真的有收益吗？
• 项目效果不好，跟模型关系大吗？
• 如果今天投入大量时间解决某个模型能力缺陷，半年后模型升级，这部分工作还剩多少价值？

正因为模型能力提升得太快，我们才更应该思考：什么东西是模型进步之后依然存在的？

二、技术问题 - 工程问题

什么是技术问题？

我理解的技术问题是：“能不能做到”。

• AI 能不能写代码？
• AI 能不能 Code Review？
• AI 能不能理解图片？
• AI 能不能分析日志？
• AI 能不能操控手机？

这是能力边界问题。随着大模型的快速发展，很多过去做不到的事情现在已经能轻易做到。对于绝大多数应用开发者来说，我们其实很少真正参与能力边界的突破。

对于大部分像我这样的人，我们能做的事情的本质不过是购买 token，然后不断进行“输入给大模型->大模型输出“这样**“输入->推理->输出“的循环，**中间的过程我们无能为力。模型内部如何实现、参数如何训练、能力如何涌现，这些事情通常由模型厂商负责。如果不是自部署模型，甚至加个 lora 都难以做到。

我们真正能产生价值的地方，往往在模型之外。

什么是工程问题？

我的理解是：“如何持续做到”。

• AI 如何获取代码上下文？
• AI 生成的结果如何验证？
• AI 出错后如何纠正？
• 如何形成反馈闭环？
• 如何衡量收益？

这些问题与模型能力关系不大，却决定了 AI 能否真正落地。

从这个角度来看，很多我们所谓的 AI 开发，并不是在创造新的 AI 能力，而是在通过工程手段组织信息、约束过程、提高可靠性，仍然在 “使用 AI” 的层面，和在浏览器对话框里用豆包相比，没有上升到质变的程度。

正是由于这是一件工程问题，才会产生 ”harness“ 的概念。究其本质，还是一句话能说明白的事情：大模型的输出不可控，因此我们要通过工程体系让它尽量可控。

三、harness

详细的内容不再赘述，我想再用简短的语言来祛魅 harness 这件事。

很多教程喜欢把 harness 说得很复杂，显得很高大上。当然，作为一个工程问题，它确实很复杂，但作为技术问题的话其实是很简易的。

• skill？提前注入的 prompt 而已，所谓 skill 能有调用工具、创建子 agent 的能力，那是 AI Agent 的那个外壳带给它的。

• mcp？大家都用 mcp 是因为它是大家都愿意用的统一的协议了，从原理上说用自定义的 http 有何不可？

• memory？还是在控制输入，把上下文中值得记录的东西记下来。

• RAG？依然是控制输入，加了个搜索的过程而已。

• Model Routing？不同的任务用不同的模型。

• Guardrails？控制输出，通过输入来控制输出或者直接检查输出结果

• 等等等等…..

我不是说这些技术不重要，它们都是解决工程问题过程中沉淀出来的优秀实践。我想表达的是，很多概念背后的核心思想并不复杂，不必因为新名词而产生距离感。

四、我们正在重复软件工程的发展历史

我觉得，AI 行业正在经历一个熟悉的过程，如同几十年前的软件行业。

最开始大家讨论的是技术问题：

• 能不能实现编译器？
• 能不能实现操作系统？
• 能不能实现数据库？

后来能力成熟，大家开始讨论工程问题：

• 如何协作开发？
• 如何管理代码？
• 如何持续交付？

于是有了 Git、CI/CD、DevOps 等等，这些东西并没有让计算机更聪明，而是在现有条件下通过工程手段提升生产效率。

如今，模型就像 CPU，我们正在建设的 Harness、Agent、MCP、Memory、RAG，就是围绕 CPU 构建出来的软件工程体系。

很多人希望自己在 AI 应用开发中造发动机，但实际上大多数人做的事情，更像是在修路、建收费站和设计交通规则。发动机当然重要，但对于绝大多数企业来说，发动机不是自己造的，OpenAI、Anthropic、Google、DeepSeek 才是造发动机的人，我们要做的事情，是让发动机能够真正跑起来，并且安全、稳定、高效地跑起来。