AI全栈开发实战：从RAG到Agent的生产级落地路径与踩坑指南

最近帮几个团队评审AI应用架构，发现一个特别普遍的问题：大家把AI全栈开发当成普通全栈开发来做，设计接口、写CRUD、接个大模型API、页面套壳，Demo一跑通就以为完事了，结果一上生产就崩。崩的地方不是并发，不是数据库索引，而是模型输出不稳定、Token成本失控、评估体系缺失这些传统开发里根本不存在的变量。

做AI全栈和做传统全栈，底层思维方式完全不同。传统全栈面对的是确定性系统，输入输出可预期；AI全栈面对的是概率性系统，同样的Prompt今天和明天可能返回不一样的结果。这篇文章不聊空泛的概念，直接拆解我这几年代团队落地AI应用的完整实践路径，从技术选型到RAG落地，从Agent编排到测试评估，再到生产环境里真正烧钱踩坑的地方。适合正在做AI应用开发、准备从传统后端转向AI方向、或者团队里需要一个人来扛AI全栈的读者。

1. 先想清楚：AI全栈开发到底在开发什么

1.1 从确定性系统到概率性系统

传统Web应用的核心是信息处理：用户提交数据、后端校验、落库、查出来渲染页面。每一步都有明确预期，数据库返回多少行、接口返回什么字段，都是可以断言的。测试好写，问题好定位，整个系统像一条流水线。

AI应用不是这样。大模型本身是个概率系统，同样的输入、同样的参数，每次输出都可能不同。温度调到0也不是完全确定，只是概率分布更集中。这意味着你做AI全栈开发时，面对的每一个用户请求都可能产生意料之外的输出。模型可能答非所问，可能编造不存在的事实，可能突然拒绝回答，甚至可能因为Prompt里一句含糊的表达就完全跑偏。

我见过很多团队在这个问题上栽跟头。他们用传统思维设计AI产品，认为只要把模型API接进来、把知识库喂进去，产品就成立了。结果上线后发现，用户问法稍微变一下，答案质量就剧烈波动。这不是模型不够聪明，而是工程上没有针对概率性输出做兜底设计。

AI全栈真正的复杂度，不在"调用模型"这一步，而在"如何让概率性输出变得可控可用"。你需要设计合理的Prompt结构、建立上下文管理机制、做输出校验和兜底、通过评估体系持续观测质量波动。这些工作才是AI全栈的核心工作量。

1.2 一个AI应用的最小闭环

我建模的时候习惯先画一张闭环图，把AI应用的完整链路画出来再动手写代码，这样能避免只见树木不见森林。一个标准的AI应用闭环包含这几个环节：

业务定义：明确这个应用到底解决什么问题，目标用户是谁，成功指标是什么。 数据准备：收集、清洗、切分、向量化业务数据，建立知识库。这是RAG类应用的地基。 上下文工程：设计Prompt模板、构建上下文窗口内容，决定模型能"看到"什么。 模型调用：通过网关统一调用，配置模型参数和fallback策略，而不是在业务代码里直接写死某个厂商的SDK。 应用逻辑：包括Agent编排、工具调用、状态流转、业务规则兜底。这是传统后端开发者的主场。 评估与观测：建立评测集，持续打分，追踪线上trace，监控成本和延迟。 迭代反馈：根据线上反馈和评估结果，调整Prompt、补充知识、优化Agent行为。

这七个环节里，第一项业务定义和最后两项评估、观测，是很多从传统开发转过来的团队最容易忽略的部分。他们擅长第二到第五项，因为那是标准的软件工程范畴，但往往做完第五项就上线了，没有评估闭环，结果质量全靠运气。

传统全栈和AI全栈的分工差异，用一张表能看得很清楚：

为什么会这样？因为模型作为一个外部依赖，行为不像数据库那么稳定可控，你必须围绕它建立新的工程治理体系。这是AI全栈和传统全栈最根本的区别。

2. 技术选型：模型网关、Agent框架与数据基础设施

2.1 模型网关：LiteLLM Proxy的工程价值与最佳实践

很多团队在项目初期直接在前端或后端业务代码里调用模型SDK，比如在Python代码里写import openai，在Java里直接引入某个厂商的SDK。短期看没什么问题，但做大了就发现几个痛点：模型换厂牌要改代码；多个模型Key散落各处，没法统一管理；没有统一的成本统计；没有故障转移能力。这时候就需要一个模型网关。

LiteLLM Proxy是当前一个非常成熟的开源方案，它以OpenAI兼容格式对外提供服务，背后可以代理各家模型平台，包括OpenAI、Anthropic以及国内多家厂商的模型服务。它的核心价值就是把模型调用收口，让应用层只认一个base_url。

我在项目中落地LiteLLM的基本配置大致是这样：

model_list: - model_name: chat-main litellm_params: model: openai/gpt-4o api_key: os.environ["OPENAI_API_KEY"] - model_name: chat-main litellm_params: model: deepseek/deepseek-chat api_key: os.environ["DEEPSEEK_API_KEY"] - model_name: chat-main litellm_params: model: qwen/qwen-turbo-latest api_key: os.environ["DASHSCOPE_API_KEY"] litellm_settings: drop_params: true set_verbose: false general_settings: master_key: sk-your-master-key database_url: postgresql://user:pass@localhost:5432/litellm

几个关键点展开说。

第一，多个模型共用同一个model_name，比如chat-main，LiteLLM会自动做负载均衡。这不是简单随机，它会根据每个模型的历史调用延迟和失败情况动态调整权重，某个模型超时率升高就自动少分流量过去。这个机制在实战场上救过我很多次，上游模型抖动时，用户基本无感。

第二，fallback配置。不同平台的服务都会有单点故障的时候，我在配置里会给关键模型指定fallbacks参数，主模型挂了自动切换备用模型。配置方式是在litellm_settings里针对某个model_name单独指定：

model_list: - model_name: chat-main litellm_params: model: openai/gpt-4o api_key: os.environ["OPENAI_API_KEY"] model_info: supports_function_calling: true - model_name: chat-fallback litellm_params: model: qwen/qwen-turbo-latest api_key: os.environ["DASHSCOPE_API_KEY"]

然后在代码里用chat-main作为主模型，做一层重试和切换逻辑。注意不同模型的function calling支持程度和输出格式不完全一致，切换时要确认兼容性，不然Agent应用会拿到格式错误的结构化输出。

第三，开启database_url之后，LiteLLM会记录每次请求的Token消耗、模型名、响应时间，这能解决AI应用成本归因的问题。我在公司内部搭了一套成本面板，每个业务线每个月消耗多少Token、对应多少费用，一查就有。没有这一步，AI应用的成本就是一个黑盒，财务月底来问的时候只能干瞪眼。

最佳实践方面，我的建议是：应用层永远不要直接维护多家厂商的SDK，统一走OpenAI兼容接口；网关独立部署，和应用服务解耦；生产环境必须开启成本日志和预算告警。

2.2 Agent框架怎么选：LangChain/LangGraph、Spring AI还是自研

Agent框架是另外一个容易让人纠结的点。LangChain铺得很大，生态全但抽象多，有些场景反而被框架拖累。我在初期项目里直接用了LangChain，遇到过一次很被动的局面：业务需要自定义工具的重试和错误处理逻辑，但在LangChain高层的AgentExecutor里改这部分很别扭，后来不得不用LangGraph自己搭状态图才解决。

我的选择建议很简单，按团队基础和场景复杂度来：

如果团队是Python，且业务逻辑相对简单，比如只有一个工具调用，不需要多轮规划，直接用原生代码写函数调用，别上大框架。一个while循环加上tools参数就够了，没必要引入几百个依赖。

如果业务确实需要多步规划、多工具协作、有复杂状态流转，用LangGraph。它比LangChain更接近工程化，把Agent的每一步显式建模成图的节点和边，状态管理也清晰，适合需要精细控制的业务。代价是要花一段时间理解它的State、Node、Edge机制。

如果团队是Java背景，Spring AI值得认真考虑。它对Java开发者友好，很多概念和Spring Boot一脉相承，团队上手快。尤其适合企业内部系统集成，和现有的Spring生态无缝结合。Java团队硬写Python服务，后续维护成本很高。

如果业务很垂直、对行为有严格控制要求，自研一个简单的Agent编排引擎也是合理选择。我自己在服务一个金融客户时，因为对工具调用有严格的白名单和审计要求，最终选择了自研状态机。核心逻辑写下来其实没多少行，但可控性提升了一个量级。

我的判断标准是：不要为了用框架而用框架，Agent的编排逻辑本质上是业务逻辑，应该由业务团队掌控，而不是由框架的抽象机制摆布。框架的价值在于解决通用问题，当你的业务需要在通用逻辑之外做大量定制时，就该考虑是不是要自己来了。

2.3 数据与算力基础设施：向量库、推理引擎和部署方式

在这轮AI应用开发里，基础设施层面的变化主要来自数据侧和算力侧。

数据侧最明显的增量是向量数据库。选型时不要盲目追求功能多的，先看自己的场景。我整理过一个表格，直接列出来给大家参考：

数据量小于100万条向量的场景，pgvector完全能顶住，不必为了向量数据库单独引入一个中间件。我在实际项目里，很多场景用pgvector就解决了，部署简单，备份和事务都沿用原来的体系。数据量上来，或需要复杂的过滤条件和高并发，再考虑独立向量库。

算力侧则是推理引擎的选型。如果走API路线，基本不需要管部署，直接通过LiteLLM网关接入即可。如果需要私有化部署，现在基本会考虑vLLM，它对主流开源模型支持好，吞吐量高，而且直接提供OpenAI兼容的接口。一个典型的部署命令：

vllm serve Qwen/Qwen2.5-14B-Instruct \ --served-model-name my-qwen \ --port 8000 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 2

量化方面，AWQ和GPTQ是当前比较成熟的选择，能把参数量打下来不少，显存占用低很多。GPU资源紧张的团队，先量化再部署，推理速度通常有提升。更激进的方案是把小模型部署到CPU，配合量化跑一些简单分类任务，成本能压得很低。

3. 落地一条AI业务链路：从RAG到Agent再到部署

3.1 RAG的工程细节：切分、召回与重排序

RAG是现在AI应用里最常用的知识注入方式，很多团队一开始就做RAG，但做出来的召回质量差别很大。差别主要不在Embedding模型选谁，而在工程细节。

文档切分是第一关。很多初学的人直接用固定chunk_size切分，比如512个字符一段，不做重叠。这样很容易把一段完整的内容从中间切断，导致语义不完整，召回时老是丢关键信息。我建议的切分策略是语义边界优先，固定长度兜底。用LangChain或LlamaIndex里的递归切分器，按段落、句子层级逐级切，同时设置重叠区域：

from langchain_text_splitters import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=128, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""], keep_separator=True, ) chunks = splitter.split_text(document)

chunk_overlap设为chunk_size的四分之一比较合适。过小起不到上下文衔接作用，过大则产生大量冗余向量，浪费存储和检索成本。对中文文档，看分隔符的优先级，把"。"、"！"、"？"放在比较靠前的位置，让切分尽量落在语义完整的句子边界。

召回环节，单靠Embedding相似度往往不够。Embedding模型擅长捕捉语义相似度，但对关键词精确匹配和否定表达这类信息不太敏感。我现在的标准做法是双路召回加Rerank：一路用向量相似度召回，一路用BM25关键词召回，两路结果合并后用Cross-Encoder模型重排序，把最相关的Top K排到前面。Rerank模型读的是query和doc的完整句子对，相关性判断比单纯的向量计算准确得多。

Embedding模型本身的人也要注意。上线后如果想换一个Embedding模型，必须把知识库里的所有向量重新生成一遍，否则新旧向量不在同一个空间里，召回准确率直接崩。这个坑我踩过一次，上线前跑了几十万条向量，换模型后没注意老向量，结果线上召回质量下降明显。

3.2 Agent编排的核心循环：从ReAct到可维护的状态机

Agent和普通ChatBot的区别在于能不能使用工具。ChatBot只能基于模型内部知识回答问题，Agent能查数据库、调API、发邮件，通过多步推理完成一个相对复杂的任务。这背后最基础的实现就是ReAct模式：思考、调用工具、观察结果、再思考。

一个最简Agent循环用原生代码可以这样写：

def run_agent(user_message, llm, tools, max_steps=8): messages = [{"role": "user", "content": user_message}] for step in range(max_steps): response = llm.chat( messages=messages, tools=tools, tool_choice="auto", ) if not response.tool_calls: return response.content messages.append(response.message) for tool_call in response.tool_calls: result = execute_tool(tool_call.function.name, tool_call.function.arguments) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result, }) raise RuntimeError("Agent reached max steps")

这个循环虽然简单，但它抓住了Agent的最核心机制：把工具调用结果作为新的上下文喂回给模型，让模型基于真实工具结果继续推理。很多Agent框架做的事情本质上就是这个循环，只不过加上了更多的状态管理、记忆和编排能力。

实际开发里需要特别留意几个问题。

max_steps必须设置，而且不能太大。没有步数限制的Agent就是个失控的循环，它会不断调用工具、不断失败重试，把Token消耗放大好几倍。我在项目里默认设8步，超出就终止并返回兜底文案。

工具调用必须有清晰的错误返回。工具内部报异常时，不要把堆栈抛给模型，而是捕获后返回一段结构化的错误描述，比如{"error": "USER_NOT_FOUND", "message": "用户ID不存在"}，好的Agent会根据错误信息自我修正一次，但如果错误信息是诡异的堆栈，模型大概率会乱来。

工具参数校验要严格。模型生成的JSON参数偶尔会不合法，要么是字段缺失，要么是类型错误。建议在execute_tool阶段做一次JSON Schema校验，非法参数直接返回校验错误给模型重新生成，别让脏数据进入业务系统。

再往后就是多Agent协作和复杂状态流了。这个阶段我一般用LangGraph来管理，把每个Agent步骤定义成图中的节点，节点间通过State共享数据，路由逻辑显式化。虽然多写了一些样板代码，但整个流程可读性强，测试也好写，出了问题能定位到具体节点。

3.3 模型部署的两种路径：托管API与私有化推理

模型调用是走托管API还是私有化部署，是每个团队都要做的选择。我的判断依据是数据敏感度、调用量、以及成本结构。

数据敏感度是第一位的。客户数据必须留在内网，那就不用纠结，直接私有化部署。目前开源模型的能力已经足够支撑大量业务场景，Qwen系列、DeepSeek系列这些模型，在很多垂直任务上并不逊色于闭源API。

调用量大的场景也适合私有化。按量付费API在调用量大到一定程度以后，成本会超过GPU服务器折旧。我算过一个典型case：一个日请求量百万级别的应用，如果大部分请求走中等规模的开源模型，两个月左右的API费用可能就够买一台能承载这个负载的GPU服务器了。这里还没算数据出网带来的额外延迟问题。

私有化部署的工程要点主要是：模型加载、并发配置、显存管理。vLLM的--gpu-memory-utilization参数建议设在0.85到0.95之间，太低浪费显存，太高容易OOM。--max-model-len决定最大输入长度，直接影响显存占用，不要盲目设大。能开到32K就开32K，不需要长上下文任务的场景开到16K就够用，省下的显存能换更高的并发。

托管API路径也有它的优势：几乎没有运维负担，模型版本迭代不用自己管，开箱即用。适合快速验证产品、调用量不太大的阶段。我见过不少团队在早期用API把产品跑起来，等用户量和成本上来了，再迁移到私有化部署，这个节奏我认为是合理的。

不管哪条路径，应用层都不要直接连模型服务，统一走LiteLLM网关。这样切换API模型到私有化模型时，只需要改网关配置，应用代码一行都不用动。

4. AI应用怎么测试与评估：没有标准答案的验收难题

4.1 为什么传统的测试思维在AI这里失效

传统软件开发里，测试有一套成熟的方法论。写个单元测试，断言输入输出，跑CI，回归测试，一套流程下来质量心里有底。但到了AI应用这里，传统的断言体系直接失效。

你没办法断言"用户问'发票怎么开'，模型返回的内容是否合格"，因为合格的答案不是唯一的，模型每次生成的答案也不完全一样。你可能可以断言返回结果里包含"发票"两个字，但这种断言太弱了，根本保证不了答案质量。更麻烦的是，你怎么定义"相关性"？怎么定义"回答正确"？这些在传统测试里根本无法直接表达。

所以我建议团队做AI应用测试时，观念要转个弯：不要把AI测试当作传统测试一样追求"通过/不通过"，而是把它当作持续的质量评估系统来搭建。核心是建设评测集，定义评分维度，用工具化手段持续打分，监控质量趋势，而不是纠结单次对错。

4.2 LLM as Judge：用评估维度把主观质量变成可量化指标

LLM as Judge，就是用另一个大模型来评估目标模型的输出质量。这个概念听起来有点递归，但在工程上是有效的，因为它解决了"谁来打分"的问题。人工打分太慢、太贵，无法规模化；规则匹配做不到语义层面的判断；LLM Judge能在很大程度上接近人的判断。

我在实际项目中用LLM as Judge的方式是设计一个评分Prompt，让Judge模型按维度打分：

judge_prompt = """ 你是AI应用质量评估员。请对以下模型回答进行评估，输出0到5分。 评估维度： 1. 相关性：模型回答是否针对用户问题，有没有答非所问。 2. 忠实度：模型回答是否基于提供的知识库上下文，有没有编造内容。 3. 完整性：模型回答是否覆盖了问题涉及的关键信息点。 用户问题：{question} 知识库上下文：{context} 模型回答：{response} 请直接输出JSON，格式如下： {"relevance": 0-5, "faithfulness": 0-5, "completeness": 0-5, "reason": "简要说明"} """

打分结果可以汇总成质量报告，比如按日维度统计平均分、最低分、各个维度的分布。当某个维度的分数持续下降时，大概率是知识库出问题了、Prompt被改坏了，或者模型服务端悄悄换了版本。

LLM as Judge也有自己的坑。Judge模型倾向于给更长、更详细的答案打高分，即使答案冗长且不直接；它对数字和事实的校验能力有限，如果回答里出现编造的数据，Judge不一定能识别出来。所以在事实类场景，我会叠加规则校验，比如从回复里抽取日期、金额等信息和知识库做精确比对，必要时对接外部分类模型双重复核。

每次大版本改动后，我会抽出一批用户问题做一次人工抽查，把人工评分和LLM Judge评分做一个校准，防止Judge的评价标准和业务目标漂移。评测集不是一次性的，它是一个持续维护的资产，每发现一个线上badcase，就补充到评测集里。

4.3 分层的AI测试策略和工具链

和传统软件测试一样，AI应用也需要分层测试，只是每层的内容要针对AI的特殊性做调整。

组件测试里一个实用的做法是用录制的LLM响应来跑回归。真实调用模型既慢又贵还不可控，我在测试环境把不同场景的LLM响应固化成JSON文件，单元测试里直接读这些录制文件，快速验证Agent编排逻辑是否正确。只有端到端测试才调用真实模型。

工具链上我现在常用的组合是：pytest写单元和集成测试，Langfuse记录线上trace和评估分数，配合LiteLLM的成本日志做质量与成本的关联分析。如果团队想快速搭建评估体系，可以试试PromptFoo或Traceloop，这些都是成熟的开源方案，比从零开发省事很多。

这里要特别说一句，AI应用团队的测试工程师角色很重要。这位工程师不只是写脚本，更要定义评估标准、设计评测集、分析badcase模式。产品迭代过程中的质量问题，很多都需要测试工程师做根源分析，是Prompt问题、知识库问题、还是模型问题，然后再推动修复。

5. 生产环境里真正烧钱和踩坑的地方

5.1 Token消耗失控的四个典型场景与对策

AI应用最大的隐藏成本不是服务器，是Token。很多团队等月底账单出来才意识到问题，那时候已经晚了。我总结了几个最典型的Token浪费场景。

第一个是System Prompt过长。有些团队为了追求稳定，把几百条规则全部塞进System Prompt，每次请求都把这些内容原样传给模型。假设System Prompt有3000 Token，一天一百万次请求，光System Prompt就是30亿Token的消耗。对策是精简System Prompt，只保留真正影响全局的规则，业务细节放到工具描述或知识库里按需加载。

第二个是Agent递归调用失控。Agent在循环里不断调用工具、拿到结果再问模型，每一步都会重复传递历史上下文。步骤一多，Token呈指数级增长。对策是严格控制max_steps，及时清理中间过程，只保留和当前任务高相关的历史记录。

第三个是重试机制太粗暴。线上模型偶尔会超时或报错，直接重试没问题，但重试时如果不加退避、不考虑成本，往往会在模型服务抖动时疯狂重试，造成大额消耗。对策是重试加指数退避和熔断，连续失败几次就停止请求，切换到fallback模型。

第四个是日志全量记录。为了调试方便，把每次request和response完整打进日志，长期积累下来，日志存储成本也不小。对策是线上只记录关键字段，比如模型名、Token数、延迟、响应状态，完整请求内容只在小流量环境记录。

这里给一个成本估算的实例。假设一个Agent应用，每轮任务调用5次模型，每次请求输入3000 Token、输出500 Token。一个用户一天执行10个任务，那就是50次模型调用。如果1000个用户，按当前中等规模API模型的大致价格计算，一天的成本可能在两百元左右，一个月就是六千元左右。这个量级还不算大，但如果Prompt没有优化、Agent有失控循环，这个数字翻五倍十倍非常快。

5.2 延迟、成本与体验的平衡

AI应用的用户体验很大程度取决于响应速度。一个要等30秒才出结果的页面，再聪明也没有用。

延迟优化有几个实用手段。首当其冲是Streaming输出，不要让用户等整个响应结束，而是把Token一段一段吐出来，用户第一句话可能两三秒就出现了，体感会好很多。如果你用的框架不支持Streaming，建议尽快换。

其次是模型分级。不是所有请求都需要最强的模型，简单的意图识别、文本分类，用一个轻量小模型就能完成，响应快成本低。大模型只处理真正复杂的任务。比如客服场景，先让小模型判断用户情绪和问题类型，一般的售前咨询直接小模型回答，难的问题才转大模型。

再次是语义缓存。很多用户问的问题高度重复，比如"怎么退货""客服电话多少"。传统做法是缓存接口响应，但AI应用没法直接缓存，因为问法千变万化。语义缓存可以解决这个问题：把用户问题做向量化，和缓存里的历史问题比对，相似度超过阈值直接返回上一次的答案。这个方案能省掉大量重复的模型调用，在公司内部客服类应用上效果特别明显。

5.3 可观测性与内容安全护栏

传统应用的可观测性关注请求量、错误率、延迟。AI应用在此基础上要增加Token消耗、模型输出质量、Agent运行轨迹这些新维度。我在项目里用Langfuse记录每一次LLM调用的输入输出、耗时的Token数、Agent每一步的工具调用。出了问题，按用户会话ID一查，整条链路一目了然，这在调试Agent应用时几乎是刚需。

具体做法是给每个会话分配一个trace_id，从用户请求入口贯穿到每一次LLM调用和工具调用，Langfuse自动把这些信息关联成一条trace。生产环境的告警我设置了三个核心指标：Token消耗日环比突增、端到端请求延迟P99超过阈值、用户反馈负面率上升。这三个指标基本能覆盖AI应用主要的线上风险。

内容安全方面，这个是绕不开的话题。AI应用面向用户，输出内容必须可控合规。我建议在架构上做三道护栏：输入端做Prompt注入检测，防止用户通过恶意Prompt让模型执行非预期指令；输出端做敏感内容过滤，屏蔽风险词汇和违规内容；数据侧做脱敏，用户隐私字段在进入模型前替换为占位符。这些护栏和模型能力无关，而是工程上必须做的安全措施，也是保障产品长期健康运行的基础。不做好这一步，应用上线后随时可能因为内容问题翻车，到时候再补成本就高了。

6. 一些个人经验和最后的建议

AI全栈开发做到现在，我觉得最重要的不是掌握了多少框架，而是建立了一套适应概率性系统的工程思维。

先写数据流图再写代码。AI应用的数据流向远比传统应用复杂，模型调用、知识检索、工具执行、结果回填，每个环节都有数据转换。画清楚数据流再动手，能省掉后面大量的返工成本。我从一开始就吃过这个亏，上来直接写代码，写到一半发现知识库和Agent的数据结构不匹配，全部重构。

Prompt一定要纳入版本管理。很多团队用文档管理Prompt，但文档和代码是脱节的。我把Prompt模板放到Git仓库里，和代码一起管理，每次改动都留历史记录。Prompt变更导致的质量波动，可以通过评测集快速定位。没有版本管理的Prompt，线上出问题都不知道改了什么。

评测集是团队的公共资产。每发现一个线上badcase，就补进评测集，持续沉淀。评测集扩到一定规模后，做Agent的代码重构、模型升级、Prompt优化都敢动手，因为跑一遍评测集就知道改动有没有破坏原有的能力。后来我就养成了习惯：任何一个新功能上线，先写评测用例再写功能代码。

成本账本要每周看一次。不是月底，是每周。Token消耗是非常灵敏的质量指标，某一天消耗突然翻倍，往往意味着Agent跑出了一个失控的循环，或者Prompt被改出了bug。每周看一眼Token趋势，很多问题能在早期就发现，省下的钱远超花在这几分钟上的时间成本。

AI辅助编程提效明显，但人要对代码负责。我团队里现在大量使用AI辅助写代码，效率提升非常明显，但每一段AI生成的代码都必须经过人工审查。AI能帮你写框架代码、写测试用例、解释复杂逻辑，但它不了解你的业务上下文，生成的长链路模板代码容易引入隐蔽的逻辑错误。AI是很好的结对编程搭子，但最终签字负责的仍然是人。

最后想说的是，AI全栈开发还在快速演进，框架和工具隔几个月可能就换一批，但底层的工程问题不会变：如何让概率性系统稳定可用，如何把模型能力转化成可度量的业务价值，如何控制成本和安全风险。把这些核心问题想清楚了，选型就顺其自然。哪怕今天用的框架明天就过时了，这些思维方式也依然有效。