1. 先搞清楚：2025年的AI全栈开发到底在做什么
如果把时间拨回三年前，"全栈开发"这个词的含义还相当清晰：前端写页面，后端写接口，中间挂个数据库，能一个人把整套系统从头撸到尾，就可以自称全栈。但现在打开招聘网站或者技术社区，你会发现"AI全栈开发"已经变成了另一种完全不同的物种——它要求你懂大模型API、会写Agent、能搭RAG、还得处理流式响应、管理Token成本，甚至要会设计评估体系。很多人都被这个概念搞得很焦虑，觉得自己好像什么都不会了。
我个人的判断是：AI全栈开发并没有抛弃传统全栈的根基，它是在原有基础上长出了一个新层次。传统的前端、后端、数据库、部署这些能力依然值钱，但顶层多了一圈"模型能力整合"的活儿——怎么选模型、怎么接入、怎么让模型在业务里稳定干活、怎么控制成本、怎么做评测。把这个层次想明白，你就抓住了AI全栈开发的核心。
这篇文章不打算写那种"从零搭建一个AI应用"的流水账教程，而是想聊一聊我在实际项目中沉淀下来的一套打法。从Vibe Coding的快速试错，到Harness与SDD（Spec-Driven Development，规格驱动开发）这种偏工程化的协作方式，再到模型接入层、Agent编排、测试观测这些具体环节的落地经验。如果你正准备做一个AI原生的全栈项目，或者已经在做但总感觉哪里不对，这篇文章应该能帮你把思路理顺一些。
我一直强调一个观点：AI全栈开发者首先是工程师，其次才是"会用AI的人"。会写提示词、会在Cursor里让AI生成代码，这只是入门。真正拉开差距的，是你能不能把一个靠AI写出来的原型，折腾成能抗住真实流量、能排查问题、能持续迭代的工程系统。下面我按自己项目的推进顺序，把这条路上最关键的几块讲透。
2. 从Vibe Coding到Harness加SDD：我为什么转了方向
2.1 Vibe Coding的甜蜜期与崩溃点
先说一个大家可能都经历过的场景。今年上半年我接到一个内部工具的需求，要做一个用自然语言查询销售数据的功能。当时时间紧，我直接用Cursor开了个窗口，把需求往对话框里一贴，AI唰唰唰生成了几百行代码，页面有了、接口也有了、连假数据都给你塞好了。那一刻的感觉确实非常爽，我管这个阶段叫"Vibe Coding的甜蜜期"——你不需要关心实现细节，只要顺着感觉往下推，AI帮你把大部分脏活累活干完。
但这个甜蜜期不会持续太久。项目第三周开始加真实业务逻辑的时候，问题就来了。AI生成的代码里有不少它自己"脑补"的字段命名，和数据库对不上；有的函数它前后引用了两次但逻辑是冲突的；更致命的是，代码里没有任何测试，你根本不知道改了一个文件会不会炸掉另外三个。到第五周，那个项目已经变成了一堆互相缠绕的意大利面条，我宁可重写也不想继续在上面改了。
这就是Vibe Coding的崩溃点：它适合原型验证、适合一次性脚本、适合你完全清楚自己在干什么的场景。但只要是会持续迭代、多人协作、要上生产环境的项目，纯靠Vibe Coding往下堆，迟早会还债。债主上门的时候，利息高得吓人。
2.2 Harness和SDD到底在解决什么问题
后来我开始认真研究社区里那些做AI应用做得比较稳的团队是怎么协作的。发现他们提到最多的两个词，一个是Harness，一个是SDD。
Harness这个词可以理解成"给AI套上缰绳"。它强调的不是让AI自由发挥，而是通过规范、约束、结构化上下文，让AI在你划定的轨道里干活。比如规定好项目目录结构、统一命名规范、维护一份团队的编码约定文档、把关键依赖的版本写在约束文件里，这些看起来不起眼的东西，实际上是保证AI生成代码不跑偏的核心手段。
SDD（Spec-Driven Development）则更进一步，它是说在让AI写代码之前，先把规格写清楚。规格不是需求文档那种长篇大论，而是把某个模块的输入、输出、边界条件、异常处理、接口签名都定义得很具体。我现在的习惯是：如果要让AI实现一个函数，我先把函数签名、参数说明、返回值约定、几个典型用例写进规格文件，再让AI去填充实现。
这么做的收益非常明显。第一，AI不用猜需求，生成结果的准确率大幅提升；第二，规格本身是可以测试的，写完实现之后直接拿用例跑，干没干对一目了然；第三，团队成员之间沟通有了统一语言，不再出现"我让AI做的和你让AI做的不是一回事"这种尴尬。
2.3 我自己现在的工作流
如果你问我现在的开发节奏是什么样子，我可以给你一个具体的参考：
- 需求阶段：不用AI，或者只用AI做头脑风暴辅助。我自己先把业务逻辑彻底想清楚，画一张简陋的流程图，标注出核心数据流转。
- 设计阶段：把流程转成SDD规格，包括模块划分、接口定义、数据结构、错误码约定。这一步我会写得比较细，因为它是后面所有环节的锚点。
- 编码阶段：打开Cursor或Claude Code，把规格文件喂进去，让AI按规格实现。遇到规格里没定义清楚的地方，我不会让AI自己发挥，而是停下来补规格。
- 验证阶段：把规格里的用例跑一遍，再用真实数据做冒烟测试。这里强调一点，AI写的代码在你真正跑起来之前，都只能算"候选代码"。
这套流程走下来，Vibe Coding的爽感确实少了一点，但项目的可控性提升了不止一个级别。现在我做AI全栈项目，Vibe Coding和SDD不是二选一的关系——原型阶段我照样Vibe，一旦确认方向要正式开发，马上切到规格驱动的模式。节奏感很重要，别一上来就写规格把灵感磨没了，也别一路Vibe到底把项目拖进泥潭。
3. 模型接入层：别再把API密钥散落在业务代码里
3.1 为什么业务代码不能直接调模型API
很多人做AI应用的第一步，就是在业务代码里直接调OpenAI或其他厂商的API，然后API密钥写死在配置里。Demo阶段这么干没问题，但项目一复杂，这种搞法很快就会让你痛不欲生。
我见过最崩溃的一个案例：一个团队做了个多租户应用，每个租户可以配置自己的模型供应商，代码里直接new了十几个不同的客户端，分别对接不同厂商。后来要统一加一个重试机制，他们得在十几个文件里各改一遍；要统计每个租户的Token消耗，根本没法统计，因为调用散落得到处都是。最后实在忍不了，花了两周时间重构，把模型调用全部收敛到了一个统一网关后面。
这就引出我的一个核心建议：在业务代码和模型厂商之间，一定要隔一层。这一层可以是自己写的封装库，也可以直接用现成的代理网关方案。目前我接触到的主流做法里，LiteLLM Proxy算是比较省事的选择，它能统一OpenAI、Anthropic、Gemini、各种国产模型厂商的调用协议，对外暴露一个OpenAI兼容的接口，业务代码只需要学会一种调用方式就够了。
3.2 一个能用的LiteLLM Proxy配置长什么样
LiteLLM Proxy的部署方式比较灵活，可以用Docker跑，也可以嵌到现有服务里。我这边用一个简单的Docker Compose配置来说明：
version: "3.8" services: litellm: image: ghcr.io/berriai/litellm:main-latest ports: - "4000:4000" volumes: - ./config.yaml:/app/config.yaml environment: - LITELLM_MASTER_KEY=sk-your-master-key - OPENAI_API_KEY=${OPENAI_API_KEY} - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY} - DEEPSEEK_API_KEY=${DEEPSEEK_API_KEY}对应的config.yaml可以按模型供应商做路由配置：
model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: claude-3-5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: os.environ/ANTHROPIC_API_KEY - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY litellm_settings: drop_params: true set_verbose: false general_settings: master_key: sk-your-master-key这样配置完之后，业务代码里就不用再关心底层到底是哪家模型了。你只需要在配置里改一下model_name指向的目标，比如把gpt-4o-mini切到deepseek-chat，业务代码一行都不用动，成本可能就降下来了。这个灵活性在项目后期的价值非常大，尤其是当你发现某个模型在特定任务上效果不好，或者某家厂商涨价了，换模型的成本从"改全站代码"变成了"改一行配置"。
3.3 路由、限流和降级的实战注记
接入层从"能用"到"好用"，中间还隔着几个很实际的细节。第一个是路由策略。你可以按任务类型路由，比如情感分析类任务走便宜的小模型，复杂推理类任务走贵的大模型；也可以按租户路由，付费高的租户用更好的模型；还可以按模型健康度路由，某个模型接口报错率高了自动切到备胎。这些策略在LiteLLM里都能配，但你要想清楚自己的业务适合哪一种，不要为了用功能而用功能。
第二个是限流。模型厂商都有调用频率限制，如果不做客户端限流，流量一上来你就等着被429轰炸。我一般会在接入层做两层限流：一层是针对单一API Key的QPS控制，另一层是针对单个用户或者单个租户的配额控制。这样既能保护上游模型服务，也能防止某个用户把预算烧光。
第三个是降级。模型接口一定会出问题，不是今天就是明天。我的习惯是给关键链路配置降级方案：主模型挂了切备胎模型，备胎模型也挂了就返回缓存结果或者一个友好的兜底文案。这个降级逻辑一定提前写好，不要等线上事故发生了再临时加。我在生产环境里见过太多次"模型超时导致整个页面白屏"的案例，根因都是没有降级设计。
4. Agent编排：别让工具调用变成失控现场
4.1 Agent循环的核心构成
如果说模型接入层是AI应用的"骨架"，那Agent编排就是"中枢神经"。今年做的好几个项目里，最让我花时间的都不是模型效果本身，而是Agent怎么稳定地把活儿干完。很多人对Agent的理解是"给模型一个目标，它自己会想方设法完成"，这个描述没错，但到了工程实现层面，就没这么浪漫了。
一个标准的Agent循环通常包含四步：感知（接收用户输入或环境状态）、思考（让LLM决定下一步做什么）、行动（调用工具或执行代码）、观察（读取工具返回结果，决定是否继续循环）。这个循环说起来简单，但工程化之后你会发现，真正决定Agent好坏的不是模型聪明不聪明，而是你对这个循环的每个环节做了多少约束。
我常用的做法是把Agent循环的思考部分和行动部分拆成两层。思考层用大模型，负责理解意图、拆解计划；行动层走工具调用框架，每个工具都有严格的输入输出schema校验。这样即使模型产生了幻觉，在行动层也会被拦住，不会把一个不存在的工具昌出来执行。
4.2 Tool的设计哲学：给AI的工具要像给新同事的交接文档
Agent的能力边界，约等于它工具集的边界。所以工具设计是整个Agent项目里性价比最高的工作。我总结了几个原则，都是踩坑踩出来的。
第一，工具职责要单一。一个工具只做一件事，不要搞什么"万能工具"。工具太泛，模型反而不知道怎么用；工具拆得细，模型的选择正确率会明显提升。比如别设计一个"操作数据库工具"，要拆成"查询用户信息""更新订单状态""统计销售数据"这种细粒度的工具。
第二，工具的输入描述要写得极其清楚。模型是通过描述来理解工具的，描述里要写清楚参数的格式、单位、边界条件。比如一个查询天气的工具，参数描述不要只写"城市名"，要写"城市中文全称，如'北京市'，不接受拼音或缩写"。很多Agent跑偏的案例，根因都是工具描述写得模棱两可。
第三，工具的返回值要带结构化信息。不要只返回一段文本让模型自己解析，要返回结构化的JSON，并且明确标注执行成功还是失败。失败时最好给出失败原因码，让模型能据此决定是换一种方式重试还是直接向用户说明情况。
第四，一定要有安全护栏。Agent能调用的工具里，凡是涉及写操作或者敏感数据读取的，都要加权限校验和确认机制。你不能让Agent在用户一句话的引导下就把数据库表删了。这个底线必须守住。
4.3 上下文窗口的管理： Agent失忆的真正原因
另一个让人头大的问题是上下文管理。大模型的上下文窗口再大也是有限的，Agent一旦跑上十几轮，早期的重要信息很容易被挤掉，表现就是Agent开始"失忆"——用户明明告诉过它的偏好，它后面完全忘了。
我把上下文管理总结成一个"分层记忆"的模式。第一层是短期上下文，就是当前这一轮对话里模型能看到的内容，通常把最近的几轮消息和当前Agent状态放进去；第二层是工作记忆，也就是Agent在这次任务执行过程中产生的关键中间结果，用结构化摘要的方式保存下来；第三层是长期记忆，存用户的偏好、历史交互的提炼信息，存到向量数据库或者KV存储里，在需要的时候检索出来注入上下文。
这个分层模式的好处是，你不用把所有信息都塞进上下文窗口，让模型自己找重点。而是你自己决定哪些信息必须出现在上下文里，哪些信息按需检索。这么做不仅省Token，更重要的是提升了Agent的稳定性——它不会被成千上万的无关历史信息干扰判断。
另外说一个细节：每轮Agent循环结束时，让它输出一个"当前状态摘要"，几十个字就行，下一轮开头把这个摘要放回上下文。这个小技巧能极大缓解长任务的失忆问题，强烈推荐你用起来。
5. 应用层与前端：AI只是后端的新成员
5.1 业务逻辑和数据结构，依然得靠人想清楚
我见过不少被AI冲昏头脑的团队，觉得有了大模型啥都能干，业务逻辑也不用设计了，直接让模型理解需求自己输出结果。结果就是：模型输出飘忽不定，同一个问题今天一个答案明天一个答案，根本没法做产品承诺。
我的看法是，AI全栈开发里，业务逻辑不等于模型输出。模型应该只在"理解自然语言、生成文本、做语义匹配"这些它有优势的环节出现，其他环节——数据校验、状态流转、权限控制、金额计算——依然要用确定性代码来写。比如一个审批流系统，流程的状态机必须用代码写清楚，不能指望模型来判断"当前状态能不能流转到下一个状态"。
你在做AI全栈项目的时候，动工之前先用最原始的方法，把核心业务逻辑梳理清楚，分清楚哪些环节是"模型负责的"，哪些是"代码负责的"。这个划分越清晰，后面的开发越顺。
5.2 前端的AI交互范式：不是把文本框换成聊天框就完事了
前端在AI应用里的角色也变了。以前的前端是展示数据和收集指令，现在的AI前端要处理流式输出、处理中间状态、处理"模型在思考"这个动作。
不要以为AI前端就是加一个聊天窗口。很多场景下需要的是"局部AI化"——一个文档编辑器里嵌入一个AI助手让它帮你改写选中的段落，一个看板应用里加一个"用自然语言筛选数据"的输入框，一个表单里加一个AI验真的提示。直接推倒整个页面重做成对话式交互，往往不是最优解，因为用户在有明确目标时，传统表单的效率是高于自然语言的。
前端接入AI时，流式响应是绕不开的痛点。SSE（Server-Sent Events）是目前我比较推荐的方式，后端把模型生成的Token流不断推给前端，前端用ReadableStream逐段解析渲染。这里有一个经验：不要把每个Token都直接往DOM上append，那会导致页面频繁重排，性能差到没法用。更好的做法是维护一个缓冲区，定期（比如每50毫秒）把累积的文本一次性渲染到页面上，顺滑度会好很多。
5.3 错误处理和重试机制：AI应用前端的隐蔽工程
AI应用的前端错误处理比传统应用复杂得多。传统接口要么成功要么失败，AI接口则多了一堆中间态：连接中断、流式响应截断、模型返回了不合法格式、内容被安全策略拦截、限流超时。每一种情况都必须设计对应的用户提示和恢复策略。
我现在的习惯是前端封装一层统一的"AI调用客户端"，把SSE连接管理、超时重连、部分结果缓存、错误分类这些逻辑都收敛在一个模块里。页面组件只关心三个状态：流式输出中、输出完成、输出失败。这样业务页面代码干净，AI相关的复杂性被隔离在一个能被重点测试的模块里。
这里要特别说一个容易踩的坑：流式响应中途连接断了，用户已经看到了一部分输出，后端其实已经消耗了Token。如果你不做结果缓存，用户刷新页面就得重新生成一次、再花一遍Token，体验和成本都很糟。所以我建议后端对每次生成的完整结果做落地缓存，即使前端断线了，重新连接后可以直接从缓存里拿到完整结果，而不是重新调用模型。
6. 测试、观测与成本：上生产之前必须过的三道坎
6.1 评测不是"感觉还行"，是给模型建一套考试卷
AI应用的测试和传统软件测试有一个本质区别：传统软件的行为是确定性的，同一个输入必然得到同一个输出；AI应用的输出有随机性，同一个问题每次答案都可能不一样。这就导致"这次跑通了"不代表"下次也能跑通"，于是评测体系变得极其重要。
我做的第一件事永远是建立测试集。测试集不是随随便便找几条数据，而是按业务场景组织的一个"考试卷"：日常问题、边界问题、刁钻问题、错误输入，每个类别下至少准备二十条以上。然后定期把这个考试卷喂给模型，看它得多少分。版本升级之后分数有没有下降，功能修改之后有没有影响其他场景的通过率——这些都是靠测试集来回答的。
有过一次惨痛教训：某个版本对话框配置动了一处温度参数，让模型在常规问题上表现更好了，但几乎不处理涉及多条件约束的用户问题，我的测试集里这个类别的通过率从百分之七十多跌到了百分之三十以下，是靠跑测试集发现的。如果没有这层保障，这种退化了的需求逻辑可能就悄悄上线了。
在评测里还要区分两种能力：一种是模型本身的效果，另一种是你整套系统的效果。有时候模型输出是对的，但是你的检索器没找到正确的上下文，导致最终答案不对。这时候要能快速定位是哪一环出了问题，所以我建议在做评测的同时记录每一条请求的完整链路数据，这在下一节会详细说。
6.2 追踪每一次模型调用：没有踪可追，出了事只能抓瞎
传统应用出了问题，你可以查日志、查数据库、复现用户操作。AI应用出了问题，你往往要面对一个"对话黑盒"——用户的输入是什么，中间检索了什么，模型完整的Prompt是什么，模型返回的内容是什么，这些信息缺一环，排查就无从下手。
所以从项目第一天起，就要做全链路追踪。每条请求进来，给一个traceId，把这个请求涉及的所有环节——包括模型调用、工具调用、检索过程、Token消耗——都记录下来，关联到同一个traceId上。现在市面上有不少可观测性工具可以做这件事，比如Langfuse，或者一些商业APM产品都支持LLM追踪。
不要觉得这是上线前才需要做的事。我在开发阶段就启动追踪，好处是开发过程中每跑一个用例，都能直观看到"系统给模型喂了什么样的上下文"，很多质量问题不用等到上线就被你发现并修正了。另外，全链路数据还是评估成本的重要依据——哪个环节消耗了最多的Token，一目了然。
6.3 Token预算怎么算：从拍脑袋到精打细算
成本控制这块，很多团队的处理方式都很粗暴：反正模型调用便宜，用呗。等月底看到账单才傻眼。AI应用的Token成本是可以精确计算和控制的，关键在于你在每个环节做了多少浪费。
我给你一个简单的成本优化清单：第一，Prompt压缩。系统提示词、历史消息、检索回来的上下文文档，这些都是Token消耗大户。系统提示词尽量精简，检索回来的文档要做重排序只取最相关的部分，不要一股脑全塞进去。第二，缓存。完全相同的请求直接命中缓存，不要重复调模型。第三，模型分级。简单任务用便宜小模型，复杂任务才用贵的大模型，这个前面讲接入层时说过。第四，结果缓存。同一类问题，即使输入不完全一致，计算语义相似度后命中缓存也是一种可行方案。
再分享一个算账的例子。我曾经做一个客服问答助手，上线前估算每个会话平均消耗是1万Token，按当时的模型价格算，单个会话成本大概是几毛钱。但上线后实际跑下来每个会话消耗到了4万Token，一查发现主要是两个问题：历史消息没有做摘要，每轮对话都把原始历史全部塞进去；检索到的知识库文档每次都原封不动贴五篇，实际上只有两篇是相关的。做了两个优化之后，单会话Token消耗降到了1.5万左右，成本降了一半还多。这种数据不追踪永远不知道，追踪了全都是机会。
7. 实用经验清单：这些坑我替你踩过了
最后分享几个具体的、可以立刻用起来的经验，全部来自真实的项目经历。
第一，AI生成的代码也要做代码评审。我在前面说过要相信但验证，具体到代码上，就是AI生成的PR必须走和人类写的PR一样的评审流程，至少要有另一个人过目。AI写的代码里有一种很典型的问题——看着正确但实际上有隐藏假设，比如假设某个数组一定非空、假设某个值一定在字典里。评审单靠看很难发现，但有一个简单的办法：所有AI生成的代码，第一版都不要直接进主干，先在分支上把测试跑一遍再合。
第二，用规格文档约束AI，不要用对话约束AI。你可以跟Cursor聊十轮让AI微调代码，但下一次重新打开项目，它可能完全忘了之前的约定。所以我前面提到的SDD不只是流程，更是一种"持久化上下文"的手段——把约定写进仓库里的markdown文件，让AI每次启动时自动读取。我现在每个项目根目录都会放一个AGENTS.md或者docs/spec.md，里面写清楚项目结构、编码规范、常用命令、数据模型约定。这个文件是给AI看的，也是给未来接手的人看的，一举两得。
第三，模型选择不要跟风，按任务实测。市面上每月都有新模型，不要听别人说好用就直接切。我的习惯是每次接到新任务或者新模型发布时，跑同一套测试集，对比通过率和成本，决策依据就是数据。有的模型聊天体验很好但代码能力一般，有的模型推理很强但价格贵三倍，适合你的业务场景的才是最好的。
第四，流式输出时要处理"模型中途反悔"的情况。我们在Agent工具调用场景里经常遇到一个问题：模型先输出了一句话，接着又决定调用工具，前端已经把那句话渲染出来了，就会显得很突兀。我的处理方式是前端对模型输出做分片管理：已经渲染的文本标记为"已确认"，新的工具调用事件到来时，清空未确认区域、保留已确认区域。这个体验细节一开始很容易被忽略，但用户感知非常明显。
第五，一定要维护一份"AI工程的坑清单"。我现在有一个文档专门记录这个项目里所有踩过的坑和对应的规避方案，比如"温度参数超过0.7时JSON输出容易不合法""检索结果的顺序对答案质量影响极大""不要在同一进程里并发调用多个模型供应商的流式接口，会导致内存暴涨"。这种经验性的东西，靠大脑记不靠谱，写下来才是你自己的知识库。每次新人和我协作，我把这份坑清单发给他，团队的试错成本一下就降下来了。
回到最开始那句话：AI全栈开发不是会写提示词就行，也不是传统全栈那套东西被淘汰了。它更像是传统工程能力上面叠加了一层新能力——理解模型的边界、设计好模型与代码的协作方式、用工程手段控制不确定性和成本。把这几件事想明白、做扎实，你会发现AI应用开发并没有那么玄学，它只是一套需要重新适应的方法论。希望这篇文章里的经验和思路，能帮你少走一段弯路，把更多精力花在真正有价值的事情上。
