夜雨聆风
2015年，Stripe的CEO在公开信中写下："我们将公司卖给了AWS。"这句话看似疯狂，但揭示了一个事实——云原生架构改变了软件的基础假设：企业不再需要自建机房，而是租用计算能力。
同样的话正在AI时代重演。GPT-4、Claude 3.5、DeepSeek R1——这些大模型展现出的推理能力，正在动摇产品架构的根基：以前我们构建产品的第一性假设，可能不再成立。
传统产品架构的第一性假设：确定性
过去四十年，软件架构建立在一条铁律上：输入确定 → 输出确定。
你点一下支付按钮，后台调用100%会扣款成功；你发一条消息，接收方100%能收到。这不是技术细节，而是整个软件行业的第一性假设——计算机是确定性的，代码写什么，就执行什么。
这个假设构建了整个现代软件的基石：
SaaS时代，我们把这个假设发挥到了极致：微服务把"大功能"拆成"小功能单元"，每个单元独立部署、独立伸缩。AWS DynamoDB提供99.99%的可用性SLA——确定性变成了可售卖的商品。
但AI打破了这个假设。
为什么确定性如此重要？
一个真实的例子：某银行的核心交易系统，每天处理2000万笔交易。每一笔交易的背后都是确定性的——不管调用多少次，结果必须一致。这套系统的架构设计里，每一个组件都在"消除不确定性"：
数据库用Oracle RAC，主备切换毫秒级完成 网络用专线+冗余链路，丢包率控制在0.001%以下 应用服务器用K8s副本+健康检查，挂一台秒级拉起新实例 MQ用Kafka，消息至少投递一次，绝不丢
这套架构的投入成本以亿计，但支撑了银行的立身之本——信任。用户相信钱存进去还在，转出去能到账。
确定性不是技术细节，是业务的前提。
但大模型出现后，这个前提被打破了。你问同一个问题，GPT-4可能今天答A，明天答B。这不是Bug，是大模型的"特性"——概率性生成。
AI时代的第一性变化：LLM核心
大模型出现后，产品架构迎来有史以来最大的范式转移：从"编程"到"推理"。
一个很小的例子：
传统SaaS客服：用户问"订单到哪了"→后端查表→返回物流单号
AI原生客服：用户问"我的货什么时候到"→LLM理解用户意图→查表+理解物流状态→用用户能听懂的语言解释
这不是"加了AI的客服"，而是客服这个工种的本质变了——从"查数据"变成"理解人"。
三个被重新定义的"常识"
常识一："用户会操作软件"
过去二十年，我们默认用户会学操作、学流程、学交互。产品经理花大力气做的是降低学习成本——更短的上手教程、更明显的按钮、更清晰的菜单。
但AI原生产品改变了这个常识。用户不用学操作，只需要说一句话。Notion的AI助手可以"帮我写一个项目启动模板"，不需要用户去菜单里找模板、复制、粘贴、新建。
这是交互范式的彻底迁移——从"人学操作"变成"系统理解人"。当用户可以用自然语言操作产品时，"易用性"的定义完全变了。
常识二："把规则写成代码"
传统SaaS的业务规则在代码里：审批流、校验逻辑、状态机。改一条规则需要改代码、发版、回归测试。
AI时代的业务规则可以写在Prompt里。角色的定义、行为约束、业务例外处理——这些曾经需要写几百行if-else的逻辑，现在可以用Prompt来表达。
Stripe的首席产品官说的："我们发现，把规则放在Prompt里比放在代码里更容易维护。"这句话在2025年听起来刺耳，但2026年正在变成事实。
常识三："数据是资产"
这是SaaS时代最重要的认知之一。但在大模型时代，这个常识需要升级：从"数据"升级到"上下文"。
同样的CRM数据，放在传统SaaS里你可以做BI报表、做自动化营销。放在AI原生产品里，你可以让AI"理解"你的客户——知道这个客户什么时候该跟进、什么价格可以谈、什么问题是客户最在乎的。
数据还是那些数据，但因为有了LLM，数据变成了"可以理解上下文"。这是本质的区别。
贝索斯说："在亚马逊，我们不看竞争对手在做什么，只看客户需要什么，然后问——这种需求的前提假设是什么？"AI时代，这句话有了新的含义：你产品的前提假设是不是"确定性"？
架构重构的四个关键变化
变化一：从控制流到意图流
传统架构是"控制流"：代码决定流程，用户配合流程。
用户注册 → 验证邮箱 → 设置密码 → 绑定手机 → 引导页 → 完成用户必须按这个流程走，因为在代码层面，下一步依赖上一步的结果。这是传统软件的典型特征——交互路径在设计阶段就固定了。
一个传统ERP的采购审批流程：
采购员提交 → 主管审批 → 财务复核 → 总经理批准 → 生成采购单每一步都有明确的触发条件和数据依赖。如果采购金额小于5000，可以跳过总经理——这个规则写在代码里，叫"流程引擎"。
AI原生架构是"意图流"：用户表达意图，AI理解意图后自己规划路径。
用户说"帮我搞定入职" → LLM理解：需要账号、权限、门禁、工位、系统账号 → 自动规划并执行所有步骤这是架构层面最根本的变化：不再是人适应系统，而是系统理解人。
一个真实的对比：
这不是"更友好的界面"，而是架构重设计。以前你需要一个工作流引擎来定义流程，现在你需要一个意图理解层来"翻译"用户需求。
变化二：从API到自然语言接口
Stripe重构了支付——用标准化的HTTP接口代替了各家银行的混乱接口。Stripe CEO说："我们卖的是支付接口，不是银行关系。"
AI正在重新定义"接口"的含义：
过去十年，我们做ToB产品，接口设计是基本功。API要版本管理、要有文档、要做限流和熔断。这些技能仍然重要，但它们变成了"基础设施"，而不是"竞争力"。
真正的竞争力现在是：你的产品能理解多少种用户意图，能用自然语言交互到哪种程度。
最关键的变化在"用户接口"这一层。一个ToB产品，过去需要培训用户怎么操作，现在只需要用户说一句话。
一个新的例子是Notion的Custom Agents。Ivan Zhao在发布会上说："不能被Agent用的产品没有未来。"这句话的意思是：当Agent可以操作你的产品时，用户就不需要学你的界面了。
未来十年的产品设计，不是"更好的UI"，而是"更懂你的AI"。
变化三：从数据资产到上下文资产
传统SaaS的核心资产是"数据"——你有多少客户数据、业务数据。
AI时代的核心资产是"上下文"——你有多少可以让AI理解你的上下文。
数据资产：沉睡在数据库里的记录 上下文资产：，可以让AI"理解"你的业务、角色、规则的prompt和知识库一个简单的区分：
上下文资产的本质是：把企业know-how从代码里解放出来，变成AI能理解的表述。这才是知识库平台（Knowledge Base）真正的价值——不是存文档，而是让AI能"懂"你的业务。
用友的教训：用数据≠用上下文
用友是中国最大的企业软件公司之一，积累了20年的企业数据。用友副总裁在2024年的一场演讲中说："我们发现有数据，但不知道怎么让AI用起来。"
这是一个普遍问题。数据≠上下文。数据存在表里，但AI不知道这些表代表什么、业务逻辑是什么、哪些字段是关键的。
上下文需要"表达"出来——不是存进去，而是让AI能理解。这需要：
- 角色Prompt
：AI扮演什么角色 - 业务规则Prompt
：什么能做、什么不能做 - 知识库
：企业特有的知识文档 - 对话历史
：同用户的上下文记忆
把这些"表达"出来，才是AI可以用的"上下文资产"。
变化四：从确定性保障到概率性管理
传统架构解决"不确定性"的方式是——消除它。
网络不稳定？冗余+重试 数据可能丢？事务+回滚 服务可能挂？熔断+降级
AI时代的架构思维变了：不确定性是特性，不是Bug。
Prompt输出可能不稳定——用"评估+反馈闭环"来管理 模型可能"幻觉"——用RAG+知识库约束来降低概率 推理可能超时——用异步+流式输出来处理
这不是降低要求，而是换一种方式来保障质量。
传统架构：确定性 → 消除不确定性 → 保障质量 AI原生架构：概率性 → 管理不确定性 → 保障质量
一个形象的比喻：
霰弹枪不是更差，而是不同的质量保障方式。你需要"多发覆盖"（多次生成），然后"选中最好的"（评估+选择）。
架构落地的五个关键要素
阿里云《AI原生应用架构白皮书》提出了11个关键工程要素，核心是这五个：
1. 模型选型：不是越大越好
模型能力的边际效益是递减的。企业场景要的是"够用"+"稳定"+"便宜"，不是"最强"。
一个实际的选型决策：
- 意图识别用小模型
：用户的意图通常是简单的"查订单"、"开发票"、"看进度"，小模型足够 - 复杂推理用中模型
：需要理解业务逻辑、跨系统查询的，用中模型 - 代码生成用大模型
：写SQL、生成代码片段、分析报表，需要强推理能力
成本差异巨大：小模型1美元/百万tokens，大模型60美元/百万tokens。选对模型是成本控制的第一关。
2. 上下文工程：让AI"懂你"
上下文（Context）是AI应用的核心战场。企业级上下文包括：
- 角色设定
：AI扮演什么角色 - 业务规则
：什么能做、什么不能做 - 知识库
：企业特有的知识 - 历史对话
：同用户上下文记忆
上下文工程不是在Prompt里写一堆指令，而是把企业know-how结构化地灌输给AI。
一个反面例子：
你是一个企业SaaS助手，帮助用户处理订单相关问题。这是一个"无效Prompt"。AI知道自己是"助手"，但不知道扮演什么角色、有什么权限、懂什么业务。
一个有效Prompt：
你是XX公司的ERP助手，专门帮助财务人员处理订单和报销。 - 你可以查订单、导出报表、创建报销单 - 你不能修改价格、不能删除数据、不能跨部门操作 - 订单金额>10万需要主管审批，你会提醒用户 - 报销类型限于差旅、交通、商务招待 ...好的Prompt不是"更详细"，而是"更有边界"——告诉AI什么不能做，比告诉它什么能做更重要。
3. Agent编排：多智能体协作
单Agent的能力有边界，复杂场景需要多Agent协作：
Anthropic的Harness是这个思想的典型产品——把Agent从"宠物"变成"牲口"，规模化生产。
Sequential Agent的例子（智能客服）：
Agent1 意图识别 → 意图=查订单 → Agent2 查订单系统 → Agent3 整理结果 → 输出 意图=开发票 → Agent2 查税率 → Agent3 生成发票 → 输出 意图=投诉 → Agent2 记录投诉 → Agent3 升级处理 → 输出Parallel Agent的例子（深度研究）：
Agent1 研究Agent → Agent2 搜索全网资料 Agent3 搜索企业知识库 Agent4 搜索竞品动态 → Agent5 合并整理 → 输出报告4. 评估体系：AI的"测试"怎么写
传统软件有单元测试、集成测试。AI应用需要新的测试方式：
- 输出质量评估
：回答是否准确、是否有用 - 意图识别评估
：是否理解对了用户需求 - 流程效率评估
：路径是否最优
评估的核心是：定义什么是"正确答案"，然���自动化检测。
一个实用做法：先让人标注100个"标准答案"，然后让AI生成，对比差异。
5.反馈闭环：让AI自己变好
数据飞轮 = 用户反馈 → 模型改进 → 效果提升 → 更多用户
用户纠错 → 标注数据 → 微调/改进Prompt → 效果提升这是AI产品和传统SaaS最大的区别：用户使用本身就是数据，用户纠错本身就是训练。
一个实际的数据飞轮：
用户问："我上个月订单总额多少？" AI答："50万"（实际是45万） 用户纠错："不对，是45万" AI记录："45万，来源：用户纠错" 数据积累：100条纠错 → 改进Prompt → 准确率提升
传统软件的正确率靠测试，AI软件的正确率靠反馈。
三句话总结
- 第一性假设变了
：从"确定性执行"变成"概率性推理"，整个产品架构的前提不再成立 - 架构重心变了
：从"功能封装"变成"上下文理解"，企业know-how要重新结构化 - 质量保障变了
：从"消除不确定性"变成"管理不确定性"，用评估+反馈闭环代替测试+监控
AI时代的产品架构，不是"云原生+SaaS+AI"，而是重新回答第一性问题——如果用户不用学操作、_if-else可以写成Prompt、接口是自然语言，你的产品架构应该长什么样？
- 推荐阅读 -
Vibe Coding 的边界：什么时候该放手，什么时候该回归