第一版：一个会聊天的网页
最初的想法朴素到不能再朴素：浏览任何网页时，旁边能有一个「问问这一页」的助手。第一版就是这么个东西——一段精心打磨的提示词，加上十来家大模型的接口，用户填自己的密钥，把页面正文丢给模型聊天。一个星期就做了出来，自己用得挺开心。
问题很快出现：网页稍微复杂一点，整页内容塞给模型又贵又不稳，答案质量完全随页面质量起伏。更要命的是，我们说不清它到底帮用户完成了什么事——「分析这个页面」不是一件事，只是一个动作。
第二版：场景清晰了，产品才清晰
转折来自把它交到真实使用者手里：投标书的供应商想从几十页公告里找出资质要求和开标时间；跨境电商卖家想批量汇总竞品评论、比出价格梯度；从 1688 拿货的采购想一眼对齐几家供货商的参数表。同一个「网页分析」，在三种人手里是完全不同的三件事。
于是第二版按场景重做：先把页面里的导航、脚本、广告清洗掉，留下干净的正文快照；超长页面转成文件再交给模型；提取出来的数据可以一键导成表格。通用助手收窄成了几个具体场景，反而第一次有人愿意天天用它。
第三版：从「回答问题」到「完成任务」
第二版用久了，新的胃口出现了：能不能让助手自己动手——自己滚动页面、自己点开详情、自己把几家的数据凑齐？一旦让它动手，可靠性就成了生死线：一步点错，后面的分析全是垃圾。
第三版为此换上了状态机：把任务拆成规划、行动、校验的循环，每一步都显示在侧边栏里，正在操作哪个元素一目了然；关键结论必须带引用，点一下就能跳回网页原文核对；工具连续失败就降级成「基于当前信息的分析」并如实相告；单个任务的消耗设了熔断上限。顺带补上了会话持久化——侧边栏关掉再打开，任务从上次的进度接着跑。为了让它可持续地服务下去，计费也改成了智能点：简单问答和带搜索的复杂任务扣不同的点数，用户花得明白，我们跑得也安心。
架构是长出来的，不是设计出来的
复盘这三次重写，推动架构演进的从来不是模型能力的更新，而是场景的逐渐清晰：第一版回答「能不能做到」，第二版回答「为谁做、做什么」，第三版才回答「怎么做得可靠、怎么持续」。每一次我们都不是先画好了宏伟蓝图，而是旧架构在更清晰的场景面前撑不住了，被迫重写。
如果你也在做一个 AI 应用，我们的建议是：别急着设计完美的架构。先想清楚你替谁完成哪件具体的事，把场景切得足够窄，让真实的用法把架构逼出来——它会长成你业务本来的样子。模型每年都在换，场景长出来的骨架不会。