AI Native 这个词这两年出现的频率越来越高但真正动手从零搭一套以 AI 为核心的系统时大多数人还是会不自觉地退回老路先定数据库表结构再写后端接口最后把大模型当成一个“智能插件”塞进某个业务节点。这种做法本质上还是传统架构加了个 AI 外壳跑起来能演示但一旦业务逻辑变复杂、模型需要频繁替换、上下文越来越长系统就会变得极其脆弱。我过去一年参与了三个从零起步的 AI 原生项目踩过的坑从“提示词硬编码在业务代码里”到“换一个模型整个链路崩掉”都有这篇文章就把这些经验整理成一套可落地的架构思路适合正在规划 AI 产品、准备重构现有系统、或者单纯想搞清楚 AI Native 到底和传统架构差在哪里的开发者参考。1. 先搞清楚 AI Native 和“传统系统加个模型”的本质区别1.1 传统架构的思维惯性在哪里失效传统业务系统的核心假设是逻辑是确定的、可枚举的、可穷举测试的。你写一个订单状态机状态流转路径就那么多条测试用例覆盖完就敢上线。但 AI 原生系统面对的是概率性输出同一个输入可能得到不同结果模型版本一换行为就变上下文长度、温度参数、甚至调用时间都可能影响最终表现。这意味着传统那套“接口契约 单元测试 回归验证”的保障体系在 AI 系统里只能覆盖一部分剩下的必须靠新的架构手段来兜底。我见过最典型的反面案例是一个客服工单分类系统。团队把大模型调用写在一个 Service 方法里提示词直接拼字符串模型返回结果直接入库。上线第一周没问题第二周运营改了一版提示词分类准确率从 92% 掉到 67%排查了两天才发现是新提示词里少了一个关键约束条件。问题不在于提示词写错了而在于整个架构没有把“提示词”当成一等公民来管理它散落在代码里没有版本、没有测试、没有回滚机制。1.2 AI Native 架构的三个核心转变从我的实践来看AI Native 架构和传统架构的差异可以归纳为三个根本性转变。第一个转变是从“逻辑驱动”到“上下文驱动”。传统系统靠代码逻辑决定行为AI 系统靠上下文Context决定行为。上下文包括系统提示词、历史对话、检索到的知识、工具调用结果等等。架构设计的核心任务之一就是如何高效地组装、管理、压缩和传递上下文。这就像做菜传统架构是你写好菜谱每一步放什么AI 架构是你把食材和调料摆好让厨师模型自己决定怎么炒但食材的新鲜度、调料的配比、灶台的火候都得你来控制。第二个转变是从“接口契约”到“能力契约”。传统微服务之间靠 API 契约通信字段类型、必填项、返回结构都是确定的。AI 系统里模型和外部工具之间的交互是动态的模型可能决定调用哪个工具、传什么参数、什么时候停止。架构需要定义的是“能力边界”而不是“接口格式”——模型能做什么、不能做什么、做错了怎么兜底。第三个转变是从“部署即完成”到“持续演进”。传统系统上线后相对稳定AI 系统上线只是开始。模型会更新、提示词会迭代、用户输入分布会漂移、检索库会膨胀。架构必须内建可观测性、可评估性和可回滚性否则你根本不知道系统是在变好还是变坏。1.3 一个判断标准你的系统离 AI Native 有多远我通常用下面这张表来快速判断一个系统的 AI 原生程度。你可以对照自己的项目看看处在哪个阶段。维度传统加 AI 外壳过渡阶段AI Native提示词管理硬编码在代码里抽到配置文件独立版本管理 A/B 测试模型调用直接 SDK 调用简单封装统一网关 路由 降级上下文组装手动拼接字符串模板化动态编排 压缩策略输出处理直接解析 JSON加校验结构化输出 重试 兜底评估体系人工抽查少量自动化用例持续评估 回归集可观测性只看日志加耗时统计全链路追踪 Token 计量如果你的系统大部分落在第一列那基本还是传统架构加了个模型调用如果开始往第二列迁移说明有了 AI 原生的意识只有大部分落在第三列才算真正以 AI 为核心在构建系统。2. 上下文工程AI Native 架构真正的核心战场2.1 为什么说上下文比模型更重要很多人选型时花大量时间对比模型跑分但实际项目里上下文的质量对最终效果的影响往往比模型本身更大。我做过一个对比实验同一个任务用中等能力的模型配精心设计的上下文效果明显优于用最强模型配粗糙的上下文。原因很简单模型再强你给它的信息不完整、有噪声、格式混乱它也巧妇难为无米之炊。上下文工程要解决的问题包括哪些信息该放进上下文、以什么格式放、放多少、什么时候该压缩、什么时候该丢弃。这听起来像是个工程问题但实际做起来更像是在设计一套信息流系统。我习惯把上下文分成四层来管理。第一层是系统指令层定义模型的角色、行为边界、输出格式要求。这一层相对稳定但需要版本管理。第二层是任务上下文层包括当前用户输入、会话历史、相关业务数据。这一层变化最频繁也是 Token 消耗的大头。第三层是知识检索层从向量库或搜索引擎召回的文档片段。这一层的关键是召回质量和去重。第四层是工具结果层模型调用外部工具后返回的数据。这一层需要做截断和摘要否则很容易撑爆上下文窗口。2.2 上下文窗口管理的实操策略上下文窗口是有限资源怎么在有限窗口里塞进最有价值的信息是每个 AI 原生系统都要面对的问题。我总结了几条实操策略按优先级从高到低排列。策略一系统指令精简到极致。很多人的系统提示词写得像产品需求文档动辄两三千字。实测下来系统指令超过 800 字后边际收益急剧下降反而挤占了任务上下文的空间。我的做法是把系统指令控制在 500 字以内只保留角色定义、核心约束、输出格式三部分其他细节通过 Few-shot 示例来传达。策略二会话历史做滑动窗口加摘要。多轮对话场景下历史消息不能无限堆积。常见做法是保留最近 N 轮完整对话更早的对话用模型生成摘要。这里有个坑摘要本身也要消耗 Token而且摘要质量不稳定。我的经验是摘要触发阈值不要设得太低一般当历史 Token 超过窗口的 40% 时再触发摘要长度控制在原文的 15% 左右。策略三检索结果做重排序和截断。向量检索返回的 Top-K 结果里真正相关的可能只有前两三条。直接全部塞进上下文不仅浪费 Token还会引入噪声干扰模型判断。我通常会在检索后加一个轻量级重排序步骤可以用交叉编码器也可以简单用关键词匹配打分然后只保留得分最高的 3 到 5 条每条再做长度截断。策略四工具结果做结构化摘要。模型调用工具后返回的数据往往是原始 JSON 或长文本直接放回上下文很占空间。更好的做法是在工具层就做好摘要只返回模型决策所需的关键字段。比如查询订单接口不需要返回完整订单对象只返回订单号、状态、金额、时间四个字段就够了。2.3 上下文组装的代码结构长什么样下面这段伪代码展示了我常用的上下文组装逻辑核心思路是把各层上下文分开管理最后按优先级和 Token 预算组装。class ContextBuilder: def __init__(self, token_budget8000): self.token_budget token_budget self.layers [] def add_system_instruction(self, instruction: str, priority: int 100): self.layers.append({ type: system, content: instruction, priority: priority, compressible: False }) def add_conversation_history(self, messages: list, max_turns: int 10): recent messages[-max_turns:] older messages[:-max_turns] if older: summary self.summarize(older) self.layers.append({ type: history_summary, content: summary, priority: 60, compressible: True }) self.layers.append({ type: history_recent, content: recent, priority: 80, compressible: False }) def add_retrieval_results(self, docs: list, top_k: int 5): reranked self.rerank(docs)[:top_k] self.layers.append({ type: retrieval, content: reranked, priority: 70, compressible: True }) def build(self) - list: # 按优先级排序在 Token 预算内组装 sorted_layers sorted(self.layers, keylambda x: -x[priority]) result [] used_tokens 0 for layer in sorted_layers: layer_tokens self.count_tokens(layer[content]) if used_tokens layer_tokens self.token_budget: result.append(layer) used_tokens layer_tokens elif layer[compressible]: compressed self.compress(layer[content], self.token_budget - used_tokens) result.append({**layer, content: compressed}) used_tokens self.count_tokens(compressed) return result这段代码的关键设计点是每个上下文层都有优先级和可压缩标记组装时按优先级从高到低填充遇到预算不足时优先压缩可压缩层。这样能保证系统指令和最近对话永远不被裁掉而检索结果和历史摘要可以灵活伸缩。3. 模型网关别让业务代码直接碰模型 SDK3.1 直接调用 SDK 的五个致命问题项目初期为了快速验证直接在业务代码里调模型 SDK 是最省事的做法。但只要项目活过三个月下面这些问题一定会出现。第一模型切换成本极高。业务代码里到处是某个厂商 SDK 的调用方式想换个模型或者加个备用模型得改几十个文件。第二无法统一做限流和降级。每个调用点各自为政某个模型服务抖动时整个系统跟着雪崩。第三Token 计量和成本核算做不了。你不知道哪个业务模块消耗了多少 Token优化无从下手。第四提示词版本管理缺失。提示词散落在代码里改一版就得发一次版回滚更是噩梦。第五可观测性差。调用失败时你只能看到业务层的报错看不到模型返回的原始内容、耗时分布、Token 使用情况。3.2 模型网关该具备的六项能力一个合格的模型网关我认为至少要具备下面六项能力。这不是过度设计而是每个都在实际项目中救过命。能力一统一调用接口。不管底层是哪个厂商的模型上层业务只面对一套统一的请求和响应格式。这样切换模型只需要改网关配置业务代码零改动。能力二模型路由。根据任务类型、成本预算、延迟要求把请求路由到不同的模型。比如简单分类任务走小模型复杂推理走大模型敏感内容走专用审核模型。能力三限流与降级。对每个模型设置 QPS 上限和并发上限超限时要么排队要么降级到备用模型。降级策略要可配置比如主模型超时 3 秒就切备用模型备用也失败就返回兜底话术。能力四提示词管理。提示词从代码里抽出来存到配置中心或数据库支持版本、灰度、回滚。每次调用记录用了哪个版本的提示词方便问题追溯。能力五Token 计量与成本追踪。每次调用记录输入 Token、输出 Token、模型名称、业务标签汇总后可以按业务线、按用户、按时间段出成本报表。能力六全链路可观测。记录请求 ID、模型名称、提示词版本、耗时、Token 数、返回状态、错误信息。这些数据既要能实时看板展示也要能落库供后续分析。3.3 网关的降级策略怎么设计才靠谱降级策略设计不好要么该降的时候不降要么不该降的时候乱降。我踩过的坑是一开始只设了“主模型失败切备用”结果主模型没失败但响应特别慢用户等得骂人系统还在傻等。后来改成基于超时的降级但又遇到备用模型也慢的情况请求堆积越来越多。最终我采用的是一套组合策略用下面这张表来说明。触发条件降级动作恢复条件主模型连续 3 次调用失败切备用模型主模型连续 5 次成功主模型 P99 延迟超过 5 秒切备用模型主模型 P99 延迟低于 3 秒持续 1 分钟主模型限流触发请求排队超过 2 秒未处理则切备用主模型限流解除备用模型也失败返回兜底响应记录失败日志人工介入或定时重试所有模型都不可用熔断直接返回兜底健康检查通过后恢复这套策略的核心思想是降级不是二元的而是分层的。从主模型到备用模型到兜底响应每一层都有明确的触发和恢复条件。而且恢复条件要比触发条件更严格避免在临界点反复横跳。3.4 提示词版本管理的落地方式提示词版本管理听起来简单做起来有不少细节。我的做法是把提示词存成结构化数据每条提示词有唯一 ID、版本号、内容、适用模型、创建时间、状态草稿/灰度/正式/下线。调用时通过提示词 ID 加版本号来获取如果不指定版本号则取当前正式版本。灰度发布时可以配置流量比例比如新版本提示词先接 10% 流量观察核心指标准确率、用户满意度、Token 消耗没有明显下降再逐步放大。回滚就是切回上一个正式版本秒级生效。这里有个容易忽略的点提示词变更后之前缓存的模型响应可能不再适用。如果系统里有基于提示词哈希的缓存提示词版本变更时必须让缓存失效否则会出现新旧提示词混用导致的诡异问题。4. 输出可靠性让概率性输出变得可工程化4.1 结构化输出是可靠性的第一道防线模型输出不可控是 AI 系统最大的工程挑战之一。你让它返回 JSON它可能给你返回一段带解释的 JSON也可能字段名拼错还可能多返回几个你没定义的字段。如果业务代码直接解析分分钟抛异常。结构化输出的核心思路是不让模型自由发挥而是约束它按固定格式输出。目前主流做法有三种。第一种是提示词约束在系统指令里明确要求输出 JSON 并给出 Schema简单但不够可靠。第二种是模型厂商提供的结构化输出能力比如某些模型支持 JSON Mode 或 Function Calling可靠性高但绑定厂商。第三种是输出后处理用解析器容错解析失败则重试或走兜底。我的实践是三者结合优先用厂商的结构化输出能力同时提示词里也写清楚格式要求最后加一层容错解析。容错解析器要能处理常见问题比如 JSON 外面包了 Markdown 代码块、字段名大小写不一致、数值类型被写成字符串等。4.2 重试机制的设计要点模型输出不符合预期时重试是最直接的补救手段。但重试不能无脑重试否则可能陷入死循环或者放大成本。我设计重试机制时遵循几个原则。原则一区分可重试错误和不可重试错误。网络超时、限流、模型临时不可用属于可重试输入内容违规、Token 超限、Schema 定义错误属于不可重试重试多少次都一样。原则二重试要带修正信息。如果第一次输出格式不对重试时把错误信息反馈给模型比如“你上次返回的不是合法 JSON请只返回 JSON 不要有其他内容”。这样重试成功率会高很多。原则三重试次数和退避策略要合理。我一般设最多 2 次重试第一次立即重试第二次延迟 1 秒。超过 2 次还不成功说明问题不在偶发因素继续重试只是浪费 Token。原则四重试要记录。每次重试的原因、结果都要记录定期分析重试率高的场景从提示词或 Schema 设计上根治问题。4.3 兜底策略当模型彻底不靠谱时怎么办再好的架构也不能保证模型 100% 可靠所以兜底策略是必须的。兜底不是简单返回“系统繁忙”而是要根据业务场景设计有意义的降级响应。对于分类任务兜底可以返回“其他”类别并标记为待人工处理。对于生成任务兜底可以返回预置的模板话术。对于问答任务兜底可以返回“这个问题我暂时无法回答已为您转接人工”。关键是要让用户感知到系统在正常工作而不是崩了。兜底策略还要考虑数据一致性。如果模型调用是某个业务流程的一环兜底后业务流程怎么继续、数据怎么标记、后续怎么补偿这些都要提前设计好。我见过一个系统模型调用失败后直接返回空导致下游流程拿到空数据继续跑产生了一堆脏数据清理起来非常痛苦。5. 评估体系没有评估就没有迭代5.1 为什么 AI 系统的评估比传统系统难十倍传统系统的测试是确定性的输入 A 必然得到输出 B断言相等即可。AI 系统的输出是概率性的同一个输入可能得到语义相同但表述不同的多个输出你没法用等号来判断对错。更麻烦的是很多 AI 任务没有标准答案比如“写一段产品介绍”什么叫好什么叫不好本身就带有主观性。这就导致很多团队在 AI 项目上陷入一个困境上线靠 demo迭代靠感觉。产品经理说“我觉得这次改得不错”工程师说“我测了几个 case 没问题”然后上线然后被用户骂。根本原因是没有建立一套可量化、可复现、可持续的评估体系。5.2 构建评估集的实操方法评估体系的基础是评估集。评估集不是随便找几个例子而是要覆盖真实场景的分布。我构建评估集通常分四步走。第一步从真实日志中采样。系统上线后把用户真实输入按类型分层采样确保各类场景都有覆盖。冷启动阶段没有日志就靠产品经理和领域专家手工构造。第二步给每个样本标注期望输出。对于有标准答案的任务直接标注答案对于开放式任务标注评分标准或参考答案。标注工作最好由领域专家做工程师代劳容易偏离业务实际。第三步划分回归集和探索集。回归集是每次发版必须跑的用来确保没有退步探索集是定期跑的用来发现新的问题场景。回归集要稳定探索集可以动态更新。第四步持续扩充和修正。线上发现 bad case评估后加入评估集。评估集不是一成不变的它应该随着系统演进不断生长。5.3 自动化评估与人工评估的配合全自动评估省事但不够准全人工评估准但太贵。我的做法是分层配合。自动化评估负责跑量用规则匹配、关键词命中、语义相似度等指标快速筛选。比如分类任务直接比对标签抽取任务比对字段是否齐全生成任务用 BERTScore 或相似度模型打分。自动化评估的阈值可以设得宽松一些它的作用是快速发现明显问题而不是精确打分。人工评估负责校准定期从自动化评估结果中抽样由人工复核。人工评估的结果用来校准自动化评估的阈值也用来发现自动化指标覆盖不到的问题。我一般每周抽 50 到 100 条做人工评估这个量级既能发现问题成本也可控。两者配合的关键是建立反馈闭环人工评估发现的问题要能追溯到具体的提示词版本、模型版本、上下文组装逻辑然后针对性优化优化后再跑自动化评估验证。5.4 评估指标该怎么选不同任务类型的评估指标差异很大下面这张表是我常用的一些指标组合。任务类型核心指标辅助指标注意事项分类准确率、F1混淆矩阵注意类别不平衡抽取字段完整率、准确率格式合规率区分漏抽和错抽生成人工评分、相似度长度分布、重复率相似度高不等于质量好问答答案命中率引用准确率注意幻觉问题对话任务完成率轮次、满意度多轮场景要整体评估选指标时有个原则指标要能指导优化方向。如果一个指标涨了但你不知道该改什么那这个指标意义不大。比如“用户满意度”是个好指标但它太宏观涨了跌了都不知道原因。更好的做法是把它拆解成可操作的子指标比如“答案相关性”“格式规范性”“响应及时性”每个子指标都能对应到具体的架构环节。6. 可观测性AI 系统上线后你该盯什么6.1 传统监控指标在 AI 系统里的盲区传统系统监控 CPU、内存、QPS、错误率就够了但 AI 系统这些指标全绿也可能在“慢性死亡”。我遇到过模型响应时间正常、错误率为零但输出质量悄悄下降的情况原因是上游检索库更新了一批低质量文档模型被带偏了。这种问题传统监控完全发现不了。AI 系统的可观测性要额外关注几个维度Token 消耗趋势、提示词版本分布、模型输出长度分布、重试率、降级触发次数、评估指标变化。这些指标单独看可能都正常但组合起来能发现很多隐藏问题。6.2 全链路追踪该记录哪些字段每次模型调用都应该生成一条追踪记录包含下面这些字段。字段看着多但真出问题时少任何一个都可能让你多排查半天。{ trace_id: 唯一请求标识, timestamp: 调用时间, business_tag: 业务标签如 order_classify, model_name: 实际调用的模型, prompt_id: 提示词ID, prompt_version: 提示词版本, input_tokens: 输入Token数, output_tokens: 输出Token数, latency_ms: 总耗时, first_token_ms: 首Token耗时, status: 成功/失败/降级, retry_count: 重试次数, error_type: 错误类型, context_layers: 上下文各层Token占比, output_hash: 输出哈希用于去重和缓存 }这些字段落库后可以做很多分析。比如按 business_tag 看 Token 消耗排名找出成本大户按 prompt_version 看不同版本的评估指标差异按 context_layers 看上下文组装是否合理有没有某一层占比过高。6.3 告警规则怎么设才不扰民可观测性做不好会变成告警风暴做太好又可能漏报。我的经验是告警规则要分层不同层级的告警走不同通道。P0 级告警模型服务完全不可用、错误率超过 10%、降级触发超过阈值。这类告警直接打电话必须立即处理。P1 级告警P99 延迟超过阈值、Token 消耗突增 50%、重试率超过 5%。这类告警发到工作群当天处理。P2 级告警评估指标下降超过 5%、提示词版本分布异常、输出长度分布偏移。这类告警发邮件或日报按周处理。关键是要给告警设置合理的静默期和聚合规则。比如同一个模型 5 分钟内触发 10 次相同告警只发一次。否则运维同学会被淹没最后对所有告警都麻木了。7. 从零搭建 AI Native 系统的落地顺序7.1 第一阶段把模型调用收口不管系统多复杂第一步永远是建模型网关把所有模型调用收口到一处。这个阶段不用追求功能完备先实现统一接口、基础路由、Token 计量三件事。业务代码里所有直接调 SDK 的地方全部改成调网关。这一步做完后面所有优化才有抓手。我见过团队跳过这一步直接做上层功能结果做到一半发现模型调用散落各处想加个限流都加不了只能推倒重来。收口这件事越早做成本越低。7.2 第二阶段上下文工程和提示词管理网关建好后开始治理上下文和提示词。把硬编码的提示词抽出来建立版本管理。把上下文组装逻辑从业务代码里剥离做成独立的 ContextBuilder。这个阶段会动到不少业务代码但动完之后提示词迭代和上下文调优的效率会提升一个数量级。这个阶段有个实用技巧先做提示词版本管理再做上下文分层。因为提示词版本管理改动小、见效快能快速让团队感受到收益为后续更大的重构积累信任。7.3 第三阶段输出可靠性和评估体系前两个阶段解决的是“能跑”的问题这个阶段解决“跑得稳”的问题。加上结构化输出、重试、兜底建立评估集和自动化评估流程。这个阶段的关键是不要追求一步到位评估集从 20 条开始也行先跑起来再慢慢扩充。评估体系建立后你会发现之前很多“感觉”上的问题变得可量化了。比如“最近回答质量好像下降了”以前只能靠感觉现在可以看评估指标曲线是哪个维度降了、从哪个版本开始降的一目了然。7.4 第四阶段可观测性和持续优化最后一个阶段是把可观测性补齐建立告警和日报机制。这个阶段不是终点而是持续优化的起点。有了完整的可观测数据你可以做很多之前做不了的事按业务线优化成本、按场景优化提示词、按模型表现调整路由策略。整个落地顺序的核心逻辑是先收口再治理先能跑再跑稳先有数据再优化。反过来做比如先建可观测性再收口模型调用你会发现数据采集点散落各处根本没法统一。8. 几个容易踩的坑和我的应对建议8.1 过度依赖单一模型厂商项目初期为了快速上线只接一家模型厂商是合理的。但到了生产阶段一定要有备用方案。我经历过一次主模型服务区域故障整个系统瘫痪了四个小时就是因为没有备用模型。后来加了备用模型和自动降级虽然备用模型效果略差但至少系统可用。备用模型的选择要注意两点一是接口协议要能通过网关适配二是效果不能差太多否则降级后用户体验断崖式下跌。我一般会选一个同级别但不同厂商的模型做备用定期做效果对比确保降级后核心指标下降不超过 10%。8.2 忽视 Token 成本导致月底账单爆炸Token 成本在项目初期不明显因为量小。但用户量一上来成本增长是指数级的。我见过一个项目上线三个月后月 Token 成本从几百块涨到几万块就是因为没有做成本监控和优化。控制成本的手段有几个一是上下文压缩前面讲过的分层和摘要策略能省不少二是模型路由简单任务走小模型三是缓存相同或相似请求复用结果四是输出长度限制在提示词里明确要求简洁输出。这几个手段组合起来成本能降 50% 以上。8.3 评估集和线上场景脱节评估集如果只由工程师构造很容易偏向技术场景而忽略业务场景。我建议评估集的构建一定要有产品经理和领域专家参与他们更清楚真实用户会怎么用、哪些边界情况容易出问题。另外评估集要定期用线上真实数据更新。我一般每个月从线上日志里采样一批新数据人工标注后加入评估集。这样评估集才能跟上用户行为的变化不会越来越偏离实际。8.4 提示词改了但没通知下游提示词变更的影响范围往往被低估。改一个分类提示词可能影响下游的工单路由、报表统计、用户通知。如果变更前没有评估影响范围很容易引发连锁问题。我的做法是提示词变更走变更流程先评估影响范围再在测试环境验证然后灰度发布最后全量。变更记录要同步给相关方特别是下游依赖方。这个流程听起来重但比起出事后排查成本低得多。8.5 把 AI 系统当传统系统做容量规划传统系统容量规划看 QPS 和响应时间AI 系统还要看 Token 吞吐量和上下文长度分布。同样 QPS 下上下文长度翻倍Token 吞吐量就翻倍成本和延迟都会受影响。做容量规划时我一般按 Token 吞吐量来估算资源需求而不是 QPS。同时要预留缓冲因为用户输入长度分布可能突变比如某个营销活动导致大量长文本输入。缓冲系数我一般设 1.5 到 2 倍具体看业务波动性。9. 写在最后的一些个人体会AI Native 架构这件事技术选型只占三成剩下七成是工程习惯和团队协作方式的转变。我见过技术栈很先进但效果一般的项目也见过技术栈朴素但效果很好的项目差别往往在于团队有没有把提示词当代码管、有没有把评估当测试做、有没有把上下文当接口设计。如果让我给正在起步的团队一个建议我会说先把模型调用收口再把提示词管起来然后建一个哪怕只有 20 条样本的评估集。这三件事做完你就已经超过大多数团队了。剩下的路由、降级、可观测性都是在这三件事的基础上自然生长出来的。另外别追求一步到位。AI 原生架构是个演进过程不是一次重构就能完成的。我自己的项目也是跑了半年多才把各个模块补齐中间还推翻重来过两次。重要的是保持迭代每次解决一个具体问题积累下来就是一套适合自己的架构方案。