AI应用是"长"出来的，不是"搭"出来的
2026年5月27日
我见过太多人一上来就想"设计"一个AI应用。
他们画架构图，列功能清单，然后按照传统软件工程的思路去实现：前端、后端、数据库、API接口。几个月后，一个看似完整的系统诞生了——然后呢？then it's dead on arrival.
这不是AI应用的玩法。
01. 从一个真实的例子说起
看看Cursor怎么起来的。
它不是先有架构再搭功能的。最初只是一个极简的编辑器加一个代码补全模型。用户在真实场景里用了，反馈来了，问题出现了，才一点一点加上agents、Composer、多文件编辑、WebSearch……
功能是长出来的，不是plan出来的。
Anthropic做Articulate也是。第一个版本只有一个PDF阅读功能。用户说我需要提取表格、生成摘要、回答文档问题——好，一个一个加。每个功能都是被需求"拱"出来的。
这叫什么？这叫需求驱动演化，或者说得更直白一点：生长型开发。
02. 为什么传统思路不行
传统软件工程建立在两个假设上：
- 需求是可预测的：你能在写代码之前想清楚用户要什么。
- 变化是可控的：后期改需求的成本是可接受的。
这两个假设在AI时代都不成立。
用户的prompt是模糊的、多义的、上下文中才能理解的。你不可能在第一天就列出所有功能。用户自己都不知道自己想要什么——他们用着用着才知道。
而且AI应用的核心能力是非 deterministic的。同样一个功能，这次输出好，下次输出可能差。你怎么用单元测试去覆盖？所以传统软件的"需求→设计→实现→测试"流程根本不适用。
03. 正确的做法是什么
最小可行产品 → 真实用户 → 快速迭代 → 循环往复。
MVP不是功能最少的意思，是反馈回路最短的意思。你要把产品放到真实用户手里，用真实的prompt去测试，然后根据反馈快速调整。
具体操作上，有几个信号：
- 用户开始绕开你设计的功能：说明他们有更迫切的需求你没发现。
- 同一个问题出现三次：说明这是个common case，做固化。
- 输出质量波动：说明prompt不够稳定，需要加few-shot examples或者调整temperature。
这些都是"生长"的信号。
04. 另一个角度来看
换个词来概括这种思路：Organic Architecture —— 有机架构。
传统建筑是自上而下的设计图，有明确的承重墙和结构。有机建筑不一样，像珊瑚礁一样，一点点长出来，最后形成复杂的生态系统，但没有任何单一的"设计图"。
现在MCP生态就是这个道理。没有统一的API规范，没有中心化的注册表，各家自己长，长着长着发现——哎，我们接上了。
这就是AI应用最迷人的地方：不是你在构建它，是它在与你共同演化。
回到开头那个问题：怎么做一个好的AI应用？
答案是，别把它当成"项目"来做。，把它当成一棵植物来种。
浇水，晒太阳，等待，然后根据它生长的方向去扶持。
别着急设计，先去用。
本文共 938 字