AI全栈开发实战：从vibe coding到SDD，构建稳定可靠的智能编程工作流

1. 从vibe coding到SDDAI全栈开发的模式进化这两年我几乎每天都在跟AI编码工具打交道从最早拿ChatGPT补几个函数到后来直接用Cursor搓整个项目再到现在的Agent式开发最大的感受是AI全栈开发这件事真正的瓶颈从来不是模型能力而是开发者的工作方式。前阵子有个词特别火叫vibe coding大意是你只负责描述需求、让AI一路写下去自己跟着感觉走。听起来很爽但实际做过的都知道小demo确实能冲一旦项目超过三五百行或者涉及数据库、权限、多个服务之间的交互vibe coding翻车概率几乎接近100%。AI会在一半的时候忘了最初的约束会把两个模块的接口写得对不上会为了修一个bug把另一个功能改坏而且你自己因为没深度参与根本不知道从哪儿排查。后来我逐渐转向一种更结构化的做法圈内管它叫SDD也就是Spec-Driven Development需求驱动开发。核心思想很简单先让AI帮你写清楚规格说明、接口定义、数据模型把这些当成“合同”再让AI基于合同写代码。这样即使中间换模型、换工具代码的主干还是稳的。今天这篇就把我这套从vibe coding到SDD的完整打法拆开讲包括工具链怎么搭、提示词怎么设计、Agent怎么控、测试怎么做以及一堆踩坑记录。不管你是刚接触AI编程的初学者还是已经在团队里推广AI开发落地的人这套方法论应该都能直接用上。1.1 vibe coding为什么容易翻车先聊聊vibe coding的典型翻车场景。我自己最早拿AI写过一个内部工具需求就是“从Excel读取数据做清洗生成报表”。看着简单吧但AI生成的代码在读取某些特殊格式的日期时直接报错我让它修复结果它把整个数据清洗逻辑重写了一遍原来的去重逻辑全没了。来回折腾了十几轮最后我自己动手半小时改完。这个例子特别典型暴露了vibe coding的三个核心问题第一缺少稳定的需求锚点。边聊边写AI的记忆窗口有限聊到后面它自己都忘了最初的目标约束代码逻辑自然容易漂移。第二没有接口契约约束。模块与模块之间靠AI“自觉”保持一致这在大型项目里是不现实的AI生成A模块时根本不知道B模块内部怎么实现。第三缺少可验证的验收标准。vibe coding通常没有明确的测试用例和验收清单AI说“改好了”但你没法快速确认“真的好”。所以后来我做AI全栈开发第一件事就是建立需求锚点即把用户故事、功能需求、非功能约束全部转成一份结构化的规格文档再让AI在这个规格的“包围”下写代码。1.2 SDD模式的核心流程SDD模式说起来也不复杂整个流程分四步需求拆解把产品需求拆成用户可以感知的功能点每个功能点写清楚输入、处理、输出。规格生成让AI根据功能点生成技术规格包括数据模型、API接口、页面结构、异常处理方案。代码生成基于规格文档让AI按模块逐个生成代码每完成一个模块就跑通对应测试。验证反馈执行测试用例收集失败信息反馈给AI修复修复后回归验证。你会发现这里的关键不是AI能不能写代码而是你有没有一套机制让AI的输出始终围绕规格展开。规格文档就是给AI套的“缰绳”没有它AI就是脱缰的野马。实际落地的时候我常用的做法是用Markdown写规格文档然后把它放在项目的/spec目录下每次让AI干活前先把规格文档的关键段落喂给它再给出当前任务。如果是用Cursor或者类似工具可以直接用spec/xxx.md的方式引用这样AI每次都能读到最新的需求锚点。1.3 模式对比vibe coding、SDD与纯人工编码我用一个表格直观展示这三者的差异方便你按场景选维度vibe codingSDD模式纯人工编码上手速度极快中等慢需求变更应对容易失控灵活改规格即可灵活但耗时代码可维护性低高高适合项目规模小demo中大型项目视团队能力对开发者要求低懂基本架构思维高现在我的习惯是小工具或者一次性脚本直接vibe coding但凡要上线、要维护、要多人协作的项目一律SDD。把时间花在写规格上看着是多了几步实际是在给后面的开发省大麻烦。2. 工具链选型与AI Infra基本盘聊完开发模式再说说工具链。AI全栈开发不是只有一个AI编程助手就完事它实际上是一条完整链路模型接入、上下文管理、代码生成、测试反馈、持续集成。这里每个环节都有对应的工具选型和配置要点我自己前后折腾过好几套方案踩了很多坑挑重点讲。2.1 模型接入层litellm proxy的作用先从模型接入说起。很多人的第一个问题是我到底该用哪个大模型答案不是固定的今天可能GPT效果最好明天可能Claude、Gemini或者国产模型追上来。你要做的是让团队能随时切换模型且切换成本几乎为零。这时候litellm proxy就派上用场了。它本质上是一个统一模型网关你在服务端配好各种模型的API Key和基础地址对外暴露一个标准的OpenAI兼容接口。这样你的AI应用、AI编程工具、Agent框架都只连litellm由它去路由到底层模型。我的配置习惯是项目根目录放一个litellm_config.yaml大致长这样model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: claude-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 --config litellm_config.yaml --port 4000之后再给AI编程工具或者自研应用配Base URL时统一填http://localhost:4000。这样底层模型随便换上层业务代码一行都不用改。这个做法的价值在于避免被单一模型绑死。模型这东西没有永远的王者今天你发现某个模型在代码生成上不行换个模型可能就好了而litellm帮你把这个切换过程压缩到改几行配置。2.2 后端集成Spring AI还是自研Client如果你做的是Java后端项目会面临一个选择用Spring AI还是自研一个简单的LLM ClientSpring AI的优势是跟Spring生态无缝集成它把ChatModel、EmbeddingModel、VectorStore都抽象成了Spring风格的Bean配置走application.yml跟你的业务代码放在同一个工程里。特别适合已经深度使用Spring Boot的团队省去自己封装HTTP请求、JSON解析、流式响应的工夫。但Spring AI也有个尴尬点迭代太快版本之间API变动不小你网上搜到的教程大概率已经过时。而且它封装的抽象程度比较高一旦你需要一些自定义的prompt逻辑或者复杂的函数调用流程反而会觉得被框架限制。我的建议是如果项目本身就是Spring Boot且AI调用只是业务里的一个环节比如做一个知识库问答、内容生成功能直接用Spring AI效率很高。但如果你做的是一款以Agent为核心的AI原生应用交互逻辑复杂工具调用频繁建议自己写一个轻量Client维护成本反而更低。简单的自研Client核心就两个能力调用模型接口、处理流式响应。剩下的业务逻辑都能自己控制。我在一个小微服务里自己封装过核心代码不到100行包括请求构造、重试机制、超时控制、流式解析够用且可控。2.3 AI Infra的上下文管理与可观测性最后一个绕不开的是AI Infra。这个概念听起来高大上落到具体问题就是三件事上下文管理、可观测性、成本控制。上下文管理是目前AI应用最容易出问题的一环。模型上下文窗口再大也是有限的你不能把整个项目的代码都塞进去。实际工程中要做分层系统提示词占少量token定义角色和全局规则。任务相关上下文动态选择只放当前任务最相关的代码、文档、数据。工具返回结果通过函数调用动态获取用完即丢。可观测性方面我推荐至少记录三份日志请求日志每次调用的模型、token数、耗时、输出日志模型返回内容便于回溯问题、质量日志用户反馈或自动评估的打分结果。有了这三份日志出问题时你才能快速定位是模型问题还是上下文问题。强烈建议团队从第一天就做这个埋点等出问题再补就来不及了。3. 提示词工程与上下文管理的实战细节提示词是AI全栈开发绕不开的底层能力。网上讨论提示词的很多但大多是教你怎么写“请帮我生成一个网站”这种一次性需求。真正做全栈开发的时候提示词要承担的任务比这复杂得多。3.1 提示词不是玄学是需求文档我发现很多开发者写提示词特别随意比如“帮我写个用户登录功能”AI吐出来的代码能用但很平庸而且经常跟项目现有的风格、结构不一致。原因很简单你把AI当成搜索引擎了但它其实是你的结对编程搭档你得把背景信息给它讲清楚。我写的提示词一般包含五个部分角色定义你是某项目的后端开发工程师熟悉现有代码结构。背景说明项目用了什么技术栈、遵循什么架构规范。任务描述要做什么功能、验收标准是什么。约束条件不要改哪些文件、不要引入哪些依赖。输出要求只输出核心代码还是包含解释是否附带测试用例。举个例子同样让AI写登录功能我会这么写角色你是本项目的后端工程师。 背景项目使用Spring Boot 3.x MyBatis-Plus统一返回Result对象异常由GlobalExceptionHandler处理。 任务实现基于密文密码校验的登录接口用户名为手机号密码需先经过前端RSA加密后端解密后校验。 约束不要修改已有的UserMapper和RedisConfig登录成功后颁发JWT token有效期7天。 输出提供Controller、Service、ServiceImpl代码以及对应的单元测试。你看这样AI生成的代码基本可以直接用不需要来回改。核心原因是信息密度高AI不需要猜你的意图。3.2 上下文窗口的预算分配策略上下文管理是另一个容易被忽略的问题。模型上下文窗口是有限的而且在长对话中越靠前的信息被模型“注意”到的权重越低。我遇到过很多次AI聊到后面突然不遵循最初的约束了检查发现是上下文已满早期信息被截断了。我的做法是“分配上下文预算”系统提示词占10%保持稳定不随对话增长。规格文档占20%作为核心参考每次对话都带上但只带与当前任务相关的片段。当前任务描述占10%清晰明确。代码上下文占30%只包含当前要改的文件和直接相关的依赖文件。历史对话占30%只保留最近几轮老的历史果断丢弃。注意这里不是让你手动删聊天记录而是利用工具和框架层面做裁剪。比如用SDD模式时规格文档放固定位置每次对话重新引用而历史聊天内容只保留最近几轮。这样即使对话很长关键约束也不会丢。3.3 RAG与记忆管理让AI记住项目全貌单个提示词能携带的信息终究有限当项目本身比较大时RAG检索增强生成就变得重要了。你可以把项目的技术文档、接口文档、数据字典、历史决策记录都建到向量数据库里AI在干活前先去检索相关知识自动补全上下文。我之前给一个中大型项目做过RAG实践把项目的README、数据库ER图、接口文档、编码规范文档全部切片嵌入存在本地向量库。AI编程工具通过插件自动检索每次生成代码前先看一遍相关规范和数据定义。效果非常明显生成的代码风格跟项目原有代码高度一致不再出现“外来的和尚乱念经”的情况。但RAG也不是银弹。检索到的内容可能不准确或者与当前任务无关反而干扰模型判断。我的经验是检索结果不要一股脑全塞进上下文而是让AI先判断检索结果的关联度决定用还是不用。这一点可以在提示词里明确要求AI“只使用与任务直接相关的参考信息忽略无关内容”。4. 工作流编排与Agent设计的工程化思考聊完提示词接下来是Agent。AI Agent是现在最火的词但很多人对Agent的理解还停留在“能让AI自己用工具”这个层面。实际上要把Agent落地到一个可用的全栈项目你需要考虑工作流编排、工具权限、失败恢复、成本控制等一系列问题。4.1 从单轮到多步Agent的基础架构先聊聊Agent与普通Chat的区别。普通Chat是一次性问答用户问一句AI答一句。Agent则是一个循环接收任务、拆解计划、调用工具、观察结果、调整下一步。这个过程就是ReAct模式Reasoning Acting推理和行动交替进行。在工程实现上一个Agent通常由几个模块组成规划器Planner负责把大任务拆成小步骤。执行器Executor负责具体执行某一步比如调用代码生成、执行Shell命令。工具集ToolsAgent可以调用的外部能力集合。记忆模块Memory短期记忆保存当前任务上下文长期记忆保存跨会话的经验。评估器Evaluator判断当前结果是否满足目标决定是继续还是终止。我用一个最简单的例子说明让Agent“实现一个用户注册接口”。它可能会先拆成查数据库表结构、设计接口参数、写Entity和Mapper、写Service逻辑、写Controller、写测试。每一步如果遇到问题它会调整方案或者要求更多信息。4.2 harness模式给Agent套上安全护栏Agent的能力越强失控的风险也越大。我给Agent做过几次“放养”式实验让它自己折腾一个任务结果它在一个错误的方向上反复尝试白白烧了几百次API调用。后来我学到了harness模式简单说就是给Agent搭一个“工作框架”在不剥夺Agent主动性的前提下把它的行为约束在安全边界内。具体来说harness包含三层控制流程控制定义Agent必须按照固定的步骤推进不能跳过关键节点。工具控制定义Agent可以调用哪些工具被禁止的操作直接不让调用。校验控制每一步的输出先过校验器不通过则不进入下一步。举个例子Agent要执行Shell命令改代码我的harness会要求所有Shell命令必须先打印出来经过人工确认或者通过安全策略匹配后才能执行。这样即使Agent的判断有误你也能在最后一道防线拦住它。这让我想到带孩子学骑车你不是放任他自己乱闯也不是一直扶着不让动而是给他划定一个安全的练习场地配上头盔护具再放手让他骑。Agent开发也是同理harness就是场地和护具。4.3 工具调用与权限边界设计Agent的能力边界本质上取决于它能调用哪些工具。工具给得多Agent能干的事多但风险也大。我的原则是最小权限原则每个Agent只配它完成任务所需的最少工具。比如一个文档总结Agent只需要“读取文件”和“写总结”两个工具一个代码开发Agent可以给它“读文件”、“写文件”、“执行测试”三个工具但不给它“执行部署”或者“修改生产环境数据库”的权限。这看起来是常识但在实际配置的时候很多人为了省事会一股脑把所有工具都给Agent结果出事只是时间问题。此外工具调用的参数也需要做校验。举个例子如果Agent有一个“执行任意SQL”的工具那它可能在误操作下删掉整张表。我在设计类似工具时会加入只读模式作为默认配置只有在特定标志位打开时才允许写操作。这些细节看似简单但能在关键时刻保住你的数据和系统。5. AI生成代码的测试策略与质量保障AI生成代码的效率确实高但质量保障容易被人忽视。我见过不少团队AI生成的代码merge上去就跑CICI过了就上线直到线上出了事故才回去排查。AI全栈开发的落地必须有完善的测试策略否则就是给自己埋雷。5.1 对AI生成的代码做代码审查先明确一个观念AI生成的代码和同事写的代码一样必须经过代码审查才能合入主干。你不能因为代码是AI写的就放松标准恰恰相反AI生成的代码更需要仔细审查因为它可能存在“看起来对、实际错”的隐蔽问题。我做AI代码审查时重点看几个方面边界条件AI经常忽略空值、超长字符串、并发访问这些边界场景。安全漏洞AI生成的代码可能存在SQL注入、越权访问、敏感信息泄露等隐患。性能问题AI可能写出循环嵌套查询数据库的代码在小数据量下没问题一旦数据量上来就爆。语义一致性AI可能实现了接口但业务语义跟需求里描述的不一致这是最容易忽略的。我的习惯是AI生成代码后要求它自己先写一轮自测用例然后我再抽查关键文件的review。不要全部交给AI审查AI审查自己的代码就像让作者给自己的书挑错效果有限。5.2 用AI测试AI自动化测试的落地实践AI代码要测试测试代码本身也可以用AI生成这是一个很正向的循环。现在很多AI编程工具已经支持一键生成单元测试但质量参差不齐。我的实践是先让AI生成测试骨架再人工补充关键断言。比如你实现了一个复杂的价格计算函数你可以让AI生成一组基础测试用例然后你手动加上几个关键边界测试零元订单、负数折扣、并发下单等。AI生成80%的测试框架人补齐20%的关键场景这是目前效率最高、质量也可控的组合。另外AI还能帮你做回归测试的筛选。当需求变更后你可以让AI分析现有测试用例标出哪些用例会受变更影响需要优先回归。这个功能在测试用例数量庞大时特别好用能省下不少排查时间。5.3 CI/CD流水线中的人工卡点最后聊CI/CD。在AI全栈开发的流水线里我建议至少设置三个卡点规范卡点代码格式化、静态检查必须通过。测试卡点单元测试覆盖率不达标不能合入。人工卡点关键模块的代码review必须由人完成不能只靠自动化。很多团队听到“AI开发”就觉得人不用管了全自动就好了。但以现在的工具成熟度来看完全无人值守还太激进。我的建议是“人机协同”AI干重活人管方向和关键决策。把AI当作一个效率极高的初级工程师你可以给它安排大量工作但关键节点的把关必须自己来。我实际跑过的一条流水线是这样的AI生成代码 → 自动跑静态检查和单元测试 → 生成PR → AI自动修复简单问题 → 人工审查关键模块 → 通过后合并 → AI自动生成发布说明。整个过程虽然最后还是人点了一下确认但实际花在等待和操作上的时间比传统方式缩短了70%以上。6. 常见问题排查与避坑技巧写了这么多实操最后把我在AI全栈开发中遇到的常见问题做个整理。这些都是真实踩过的坑每个问题后面附上我的排查思路和解决方案当成一个速查表用就行。6.1 让AI“记住”需求上下文丢失问题现象对话进行到一半AI突然不遵循最初的约束了开始自由发挥。原因上下文窗口被占满早期信息被挤出。另外也可能是因为你中途切换了话题AI把注意力全放到新话题上。排查思路先检查当前对话轮次和tokens消耗确认是不是超了窗口。再看你最新的指令是否明确要求AI继续遵循初始约束。解决方式核心信息写进系统提示词或单独的规格文档不让它只存在于对话历史中。对话里每隔几轮就提醒一次关键约束。如果上下文确实太长就开一个新对话把规格文档和当前进度重新贴进去而不是在一个对话里硬扛到底。6.2 Agent循环调用的死锁问题现象Agent在一个错误的方向上反复尝试明明前一步结果已经不对了它还是继续往下走。原因Agent缺乏“反思”机制没有停下来评估当前路径是否有效的环节。也可能是评估器设置的终止条件过于宽松。排查思路查看Agent的完整行为日志观察它是否在重复执行相同操作。重点看每一次工具调用的返回结果有没有被正确消费。解决方式在设计Agent时加一个“最大尝试次数”超过次数就终止并向用户求助。每次工具调用后都要有一个“结果评估”步骤。我发现一个很有效的做法是在提示词里明确写“如果你连续两次得到相同错误结果停下来换一种思路或者直接向用户说明情况。”6.3 API调用成本失控现象一个看似简单的任务AI来回调用几十次API月底账单吓人。原因Agent没有对成本进行感知大量调用集中在重复的无效请求上。比如说上下文里塞了大量无关信息每次调用都要消耗大量tokens。排查思路检查可观测性面板里各个模型的调用次数和tokens消耗定位到具体是哪个任务烧钱最厉害。解决方式给Agent设置调用预算上限超出后必须人工介入。在Agent的设计中增加“批处理”能力把能合并的请求合并减少往返次数。优先使用性价比更高的模型处理常规任务把贵模型留给复杂推理。最后就是做好上下文裁剪别把所有历史都塞进去每轮最多保留最近几条就好这一条就能省不少钱。6.4 模型幻觉导致的代码错误现象AI生成的代码引用了一个不存在的方法或依赖版本看起来像真的但一跑就报错。原因模型是根据概率生成文本不是真的在编译器里跑了一遍它可能“幻觉”出不存在的API。排查思路报错信息里如果出现“module not found”、“attribute error”大概率就是幻觉。另一种情况是API确实存在但版本不对AI用了新版本的API而你项目引入的是旧版本依赖。解决方式让AI在生成代码时先查一下项目的依赖文件确认版本再写代码。我建议把项目的pom.xml或requirements.txt内容作为上下文的一部分给AI让它知道当前环境的实际版本。另外在代码审查时对AI引用的一切API都保留“它可能搞错了”的怀疑态度查官方文档确认特别是你不太熟的库。6.5 提示词长度与成本平衡的实操笔记最后再说一个大家都关心的小细节提示词写太长每次都花不少tokens写太短AI又答非所问。怎么平衡我的经验是建立一套提示词模板库。把项目里高频使用的提示词模板固化下来比如“实现新接口”、“修复Bug”、“写单元测试”、“生成数据库迁移脚本”每个模板都包含角色、背景、任务、约束、输出要求五个部分。用时只需要替换模板里的具体任务描述其他部分保持不变。这样做有两个好处一是提示词质量稳定不会因为每次临时写而质量忽高忽低二是方便统计成本因为模板部分是固定的你只需要关注任务描述部分的token变化。另外一个省钱技巧是在对话中尽量使用“增量修改”而非“全量重写”。让AI只生成变更的部分而不是每次把整个文件重新生成一遍。我见过很多人让AI改一行代码AI把整个文件重写输出这直接导致token消耗暴涨。在提示词里明确写“只输出修改的函数保留原有代码结构”能有效控制成本。