这两年做AI应用开发我最大的感受是会问AI要代码的人越来越多能把AI项目稳稳送上线的人却不多。我们团队从去年开始把精力从“让AI写代码”转向“怎么让AI写代码时不翻车”这中间踩了不少坑也沉淀出一套现在每迭代一个功能都会走的流程。今天这篇东西不是理论是我自己都在用的AI全栈开发实践覆盖从需求拆解、模型选型、Agent编码到测试部署的完整链路适合正在用AI做业务应用的开发者、带AI项目的技术负责人还有想从“能跑通Demo”进阶到“能交付生产级应用”的工程师。1. AI全栈开发的底层逻辑从vibe coding到harness × sdd1.1 vibe coding为什么会火又为什么会失控“Vibe coding”这个词形容的是一种很真实的开发状态你不再逐行手写代码而是把想法扔给AI让模型生成大段实现你负责review、改错、再让AI继续补。我最早做内部工具时也是这个节奏确实爽一个下午能顶过去两天。但项目一旦超过几千行问题就全冒出来了AI会为了满足你的一句话造出根本不需要的抽象会在不同文件里给出两种风格完全不一致的实现更麻烦的是它经常“自信地”写错边界条件而你review的时候根本看不出来。本质上vibe coding把“编程”变成了“提需求”但它最大的盲区是没有约束。人脑提需求是模糊的代码是精确的中间缺的那层东西就是我们常说的“工程约束”。没约束的情况下AI生成代码就是把不确定性放大了短期速度快长期维护成本爆炸。1.2 harness和sdd到底在约束什么热词里提到的“harness × sdd”我理解得很朴素harness是给AI套上的护栏sdd是Spec Driven Development也就是规范驱动开发。组合起来就是先定规范、再让AI干活而不是让AI先干活、事后靠人修。我在实操里对这两个词的理解是这样的harness代码必须经过的检查关卡包括编译、测试、静态检查、格式统一、依赖审计。AI生成的代码不能直接进主干必须像人写的代码一样被CI/CD拦一轮。sdd需求先转成可验证的规格说明。这里的规格不是产品经理那种泛泛的PRD而是包含输入、输出、边界条件、错误处理的具体描述AI照着spec写人照着spec审。这套组合的价值在于它把AI从“自由发挥”拉回到“按图施工”。AI不是不能创造但在工程语境里稳定比惊喜重要得多。我之前让AI实现一个列表分页功能没写spec时它给我搞出了五层抽象和三个设计模式写了spec之后它老老实实只写了50行业务代码。差别就是这么明显。1.3 最佳实践的核心矛盾速度与可控性所有AI全栈实践到最后都指向同一个矛盾AI迭代太快但工程质量不能降。你不可能让AI交付一堆无法维护的代码来换取上线速度也不可能完全关掉AI退回手写一切的低效模式。我的做法是给项目画一条“可控性基线”哪些环节可以完全放手让AI加速哪些环节必须人肉卡住。我的分配情况是这样的AI高度自治代码生成、单测用例生成、接口联调、文档补全、日志分析AI辅助决策技术选型、架构设计、依赖引入、性能优化人必须主导需求定义、spec编写、架构评审、发布决策、数据与安全策略这个分配不是拍脑袋拍出来的是踩过坑之后固化下来的。AI最擅长的不是做选择而是把已有选择执行到位选择本身需要的是上下文理解这恰恰是AI最容易出错的地方。后来的所有实践都是围绕这条基线展开的。2. 技术选型一套可落地的AI全栈工具链2.1 模型层不可绕过的统一网关接入AI能力第一件事不是选模型而是决定怎么管模型。团队里每个人的KEY不一样、供应商不一样、模型版本不一样很快会出现“我这代码没问题啊在你那就报错”的鬼故事。所以我会在正式写业务代码前先搭一层模型网关现在最顺手的是LiteLLM Proxy。LiteLLM Proxy解决的核心问题有两个。第一是统一入口所有模型请求都走一个OpenAI兼容的地址通常是本机4000端口团队不用关心底层是哪个厂商的模型代码里只需要写base_url和api_key。第二是成本与限流控制每个模型、每个key的调用量、令牌数、费用都能在dashboard上看清楚。我贴一段实际用的配置敏感信息用占位符替代model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: claude-sonnet litellm_params: model: anthropic/claude-sonnet-4-20250514 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这里有个经验配置里宁可先少接模型也不要一上来就接十个。每多一个模型意味着要多维护一份差异化的提示词和参数调优维护成本是线性上涨的。我通常只保留三个端口一个强推理复杂代码生成、一个便宜快速简单分类、抽取、一个本地小模型数据不出内网的高敏感场景。2.2 应用层框架Spring AI与LangChain怎么选到了应用层很多团队纠结用不用框架。我的判断标准很简单你的业务语言是什么。技术栈本来就是Java的优先看Spring AI因为它和Spring生态天然融合事务、配置、依赖注入都能直接复用技术栈偏Python的LangChain或LlamaIndex成熟度更高Agent相关组件更多。Spring AI这块我今年用了不少。它的优势在于把“模型调用”抽象成了类似数据库访问的编程模式你不需要关心HTTP细节只需要注入一个ChatClient。举个例子RestController public class CodeReviewController { private final ChatClient chatClient; public CodeReviewController(ChatClient chatClient) { this.chatClient chatClient; } PostMapping(/ai/review) public String review(RequestBody String code) { return chatClient.prompt() .system(你是一名资深代码评审专家只指出会导致bug、安全风险和性能问题的地方不要评价风格。) .user(code) .call() .content(); } }这个模式的好处是代码非常干净后续切换模型供应商时业务代码基本不动。但也有个坑Spring AI的版本迭代很快API变动频繁很多网上教程写的用法在当前版本已经被废弃了。我的建议是直接以官方文档为准不要照抄博客。如果你需要更复杂的Agent能力比如多工具调用、记忆管理、循环执行任务LangChain生态会更丰富但代价是抽象层厚出问题之后定位链路长。我个人做法是简单调用用框架复杂Agent自己基于模型网关写轻量编排反而可控。2.3 Agent与AI Coding工具如何嵌入开发流程现在的AI Agent已经从“聊天机器人”变成“数字员工”。在开发流程里Agent不是上来就接管整个项目而是先拆成一个个能独立验证的任务。我习惯用Agent做这几件事根据spec生成初始代码骨架把Issue描述转成可复现的bug报告批量补单元测试自动生成接口文档和变更日志在CI流程里做代码review辅助工具方面我目前主用Cursor和JetBrains AI Assistant但坦白说工具切换成本很低核心是工作流。我的AI Coding工作流永远是“上下文先行”新建会话时先把项目结构、技术栈、编码规范、相关文件路径丢进去再提任务。如果直接把一个需求甩给工具生成的代码大概率需要重写。这里还有一个容易被忽略的点AI编码工具的上下文窗口不是越大越好。很多人一股脑把所有文件都塞进去结果模型被无关内容干扰生成的代码反而更差。我一般控制在“关键文件不超过5个、总token不超过窗口三成”的范围内输出质量最稳。3. 核心实操一个AI全栈项目的完整落地流程3.1 第一步不是写代码是写Spec所有项目最值得花时间的环节是需求到spec的转换。我见过的AI项目翻车八成不是模型不行而是需求本身就模糊。AI不会主动追问“您的意思是A还是B”它会默认你的话是完整的然后给你一个看似合理实则偏掉的实现。我自己会先要求产品负责人或需求方用标准的spec模板描述功能模板只需要包含六个字段功能名称一句话说明这个功能是什么输入用户会提供什么包括类型、格式、取值范围输出系统需要返回什么包括结构、格式、成功/失败标准边界条件空输入、超长输入、并发请求、重复提交等依赖涉及哪些外部服务、数据表、文件验收标准可测试的具体条件例如“列表页在1000条数据时首屏响应小于500ms”拿一个常见场景举例我要做一个“AI生成商品描述”的功能spec中的一个模块可以长这样功能名称根据商品基本信息生成3个不同风格的营销文案 输入商品名称、品类、主打卖点、目标人群、语气偏好可选 输出JSON数组包含3条文案每条不超过80字 边界条件名称为空时返回错误码400卖点超过200字时截断处理目标人群缺失时默认“普通消费者” 依赖调用文案生成模型需经过模型网关统一鉴权 验收标准模型返回稳定JSON每条文案包含商品名和至少一个卖点格式错误时自动重试一次有了这个spec后面的提示词、代码、测试全部可以围绕它展开不会跑偏。这个过程看起来很繁琐但它正是从vibe coding升级到harness × sdd的关键一步先让思路显性化再让AI开工。3.2 AI编程阶段把生成任务拆到能验证的大小写spec之后我会把功能拆成若干“可验证的小任务”每个任务独立提交给AI工具。这里核心原则是一次只让AI做一个逻辑闭合的事情。比如“实现购物车”太大要拆成“实现购物车添加商品接口”“实现购物车列表查询”“实现库存扣减逻辑”等。举一个实际工作流的例子我让AI实现一个“通过API网关转发LLM请求并记录token用量”的模块会先把spec和已有工程结构发给Cursor然后给出一段类似这样的提示词你是本项目的后端工程师。请实现以下spec 1. 新增一个POST /v1/proxy/completions接口统一转发到内部LiteLLM网关 2. 请求体字段model、messages、temperature可选 3. 响应前先从LiteLLM响应头中读取x-ratelimit-remaining-tokens和x-ratelimit-remaining-requests 4. 将请求前后完整信息不含敏感内容写入audit_log表 5. 异常时返回统一错误格式{code: 500, message: ...} 请先阅读以下文件src/main/java/com/example/ApiGateway.java、src/main/resources/application.yaml 完成后请说明修改了哪些文件以及你如何处理超时与重试。这样做的效果非常明显AI生成的代码基本可以直接进review流程而不是推倒重来。此外每一轮AI生成后我都会立刻跑本地编译和单元测试发现问题就带着报错信息回传给AI让它继续修复。这个“生成-验证-修复”循环往复几轮后代码质量可以达到我手写八成左右的水平。3.3 测试环节AI应用该怎么验证才能放心发布AI应用测试和传统CRUD最大的区别是传统接口的断言是确定的AI输出是概率性的。你不能断言模型一定返回某个字符串但你可以断言返回结构、内容约束、耗时、安全合规性。我的测试体系分四层单元测试层验证业务逻辑、数据转换、异常处理不依赖真实模型用mock返回固定结果契约测试层验证模型网关的请求和响应结构防止模型供应商接口变动评测集层准备一个固定的输入集包含典型、边界、特殊场景对每次模型输出做规则校验回归测试层核心功能每次发布前全量运行防止新的变更让旧的AI能力退化评测集是我尤其想强调的一个环节。你光靠人看几条输出根本不知道模型整体是变好了还是变坏了。我会维护一个几百条输入数据的评测集每条数据标注期望行为然后用脚本跑分。比如给模型输出打三个维度正确性、格式合规、内容安全。跑完出一个评分表格对比不同模型版本、不同提示词版本之间的分数变化。这样每次调整提示词或换模型时不是凭感觉而是看数据。# 示例本地评测脚本执行结果简化输出 case_id correctness format safety 001 0.95 1.00 1.00 002 0.80 1.00 1.00 003 0.60 0.00 1.00 avg 0.78 0.67 1.00看到格式合规分数偏低就要检查是不是模型返回格式漂移了然后有针对性地在提示词中增加few-shot示例或者在后端强制用JSON模式解析并增加重试。3.4 部署与可观测AI Infra的最后一块拼图AI应用部署的复杂度和传统服务不在一个量级因为多了一个不确定的第三方依赖模型API。模型供应商可能宕机、限流、响应变慢也可能一夜之间调整版本策略。所以AI Infra层面我最重视三件事容错降级、成本监控、链路追踪。容错降级方面所有模型调用都要有超时控制我实践下来单次调用超时设为连接5秒、响应60秒比较合理并且要有失败切换机制。比如主模型超时后自动降级到备模型或者返回缓存结果。这里不需要多复杂的组件一个简单的策略模式就能搞定。链路追踪方面传统日志只记接口报错是不够的每个AI请求的关键信息必须记成结构化日志至少包含请求ID、用户ID脱敏、模型名、输入token数、输出token数、耗时、重试次数、成本估算。这样出问题的时候能快速回答“这个用户的回答为什么这么贵”“哪个模型供应商今天特别慢”。监控面板我一般用Grafana Prometheus这套组合因为团队熟悉、生态成熟。指标主要盯这几项调用成功率、平均耗时、P95耗时、token消耗速率、单日成本。成本失控是AI应用最容易爆的事情一定要在部署第一天就把计量打点接好不然月底看账单会非常惊喜。4. 常见问题与排查技巧实录4.1 上下文失控AI越改越乱代码越改越糟用AI编程最常见的现象是一开始很好改到后面AI开始“失忆”不是忽略前面定的约束就是重复引入已经被移除的代码。我排查下来主要原因有两个一是当前对话上下文太长重要信息被淹没二是工程代码量太大AI无法在新文件中定位旧逻辑。我的解法是“不要长期复用同一个会话”。每个子任务开新对话把必要信息重新编译一遍再喂给AI。宁可多花一点输入token也好过让AI在长上下文里自由发挥。另一个小技巧是在仓库里维护一个AGENTS.md文件里面写清楚项目结构、命名规范、常用命令、技术选型限制AI编码工具会自动读取它效果比每次口头叮嘱稳定得多。提示上下文清理不是越勤越好一个任务的开始阶段信息量最大这时候反而要把更多精力花在写清楚上下文上后面迭代重开会话时上下文可以适当精简。4.2 测试天天过功能却天天坏很多用AI写测试的团队会遇到这个魔幻场景单测覆盖率90%CI全绿但上线后业务方天天报bug。原因是AI生成的测试经常是“自己验证自己”它写一个add函数就会写一个测add的用例但不会覆盖“add被并发调用时会怎样”“add的输入是null时会怎样”这些真实世界才会出问题的地方。解决思路有两个。第一是写spec时就要覆盖边界条件和异常路径让AI按spec生成测试而不是让它自由发挥第二是要求所有测试用例中包含至少一个边界用例和一个失败路径用例。我甚至会专门写一个“负面清单”让AI生成测试时避坑比如“不要只测happy path”“不要用和实现一样的逻辑去推导断言结果”。4.3 成本失控小功能一天烧掉几百块另一个高频事故是成本失控而且往往发生在几乎没人调用的内部工具上。原因是很多人没有给模型调用设置上限和缓存。我经历过最夸张的一次一个定时任务里循环调用模型参数写错了导致每次循环都重发同一个请求一晚上跑了上万次第二天账单直接爆了。成本控制三板斧我现在是强制执行的所有模型调用必须经过网关统一计量设置日预算和调用量告警重复性请求做缓存相同的输入在短时间内直接返回缓存结果低价值场景用便宜模型比如简单分类和关键词提取坚决不用大模型。另外每次模型调用的token用量要实时记入结构化日志这样成本异常时能通过日志快速定位到具体是哪个功能、哪个用户在烧钱。4.4 数据与内容安全AI生成内容要过哪些关卡内容安全这块很多团队容易后知后觉。模型生成的内容不能直接出网必须要经过内容安全过滤和合规性检查。我目前的方案是在模型网关后挂一层检测服务对模型输出做多道检查涉政、违法违规、隐私数据泄露、PII识别检查不通过就拦截并返回兜底文案。这个只花钱调用一次检测模型但能挡住绝大多数风险。另一个容易被忽略的点是数据脱敏。在把数据发给外部模型之前先做脱敏处理比如把身份证号、手机号、姓名替换成占位符模型返回后再映射回去。这里的坑在于脱敏不能只做一次要在日志、监控、审计全链路保持一致。否则模型输出里带着脱敏前的真实数据一旦日志泄露就是事故。注意凡是涉及用户隐私的功能我建议先在内部统一评审口径哪些数据能发到模型侧、哪些绝不能出境。这个口径宁可严一点也不要事后补救。写在最后从工具使用者到工程负责人的距离如果只让我分享一条经验那就是别把AI全栈开发理解成“用AI把所有代码写完”。我今年最大的一次项目返工恰恰是因为前期太相信AI生成速度后面花了两周重构才把失控的代码捞回来。反过来那些严格按照spes、加护栏、上监控的模块后续几乎没有大面积返工。我现在的习惯是每个迭代跑完都花半小时复盘一份“AI协作问题单”记录这轮哪里AI帮了大忙、哪里AI让我走了弯路、下次怎么调优提示词或护栏。你会发现AI全栈开发的能力是迭代出来的不是买工具买出来的。最后再分享一个小技巧所有AI生成的代码合并前一定要让人看一遍diff不是逐行看而是看它有没有改动你没要求改的文件。AI经常“好心”顺手优化了别的地方而这些顺手改动往往是事故源头。把这个规则写进团队的Review检查表能拦住一大半莫名其妙的回归问题。
从Vibe Coding到Harness×SDD：AI全栈开发落地实践指南
这两年做AI应用开发我最大的感受是会问AI要代码的人越来越多能把AI项目稳稳送上线的人却不多。我们团队从去年开始把精力从“让AI写代码”转向“怎么让AI写代码时不翻车”这中间踩了不少坑也沉淀出一套现在每迭代一个功能都会走的流程。今天这篇东西不是理论是我自己都在用的AI全栈开发实践覆盖从需求拆解、模型选型、Agent编码到测试部署的完整链路适合正在用AI做业务应用的开发者、带AI项目的技术负责人还有想从“能跑通Demo”进阶到“能交付生产级应用”的工程师。1. AI全栈开发的底层逻辑从vibe coding到harness × sdd1.1 vibe coding为什么会火又为什么会失控“Vibe coding”这个词形容的是一种很真实的开发状态你不再逐行手写代码而是把想法扔给AI让模型生成大段实现你负责review、改错、再让AI继续补。我最早做内部工具时也是这个节奏确实爽一个下午能顶过去两天。但项目一旦超过几千行问题就全冒出来了AI会为了满足你的一句话造出根本不需要的抽象会在不同文件里给出两种风格完全不一致的实现更麻烦的是它经常“自信地”写错边界条件而你review的时候根本看不出来。本质上vibe coding把“编程”变成了“提需求”但它最大的盲区是没有约束。人脑提需求是模糊的代码是精确的中间缺的那层东西就是我们常说的“工程约束”。没约束的情况下AI生成代码就是把不确定性放大了短期速度快长期维护成本爆炸。1.2 harness和sdd到底在约束什么热词里提到的“harness × sdd”我理解得很朴素harness是给AI套上的护栏sdd是Spec Driven Development也就是规范驱动开发。组合起来就是先定规范、再让AI干活而不是让AI先干活、事后靠人修。我在实操里对这两个词的理解是这样的harness代码必须经过的检查关卡包括编译、测试、静态检查、格式统一、依赖审计。AI生成的代码不能直接进主干必须像人写的代码一样被CI/CD拦一轮。sdd需求先转成可验证的规格说明。这里的规格不是产品经理那种泛泛的PRD而是包含输入、输出、边界条件、错误处理的具体描述AI照着spec写人照着spec审。这套组合的价值在于它把AI从“自由发挥”拉回到“按图施工”。AI不是不能创造但在工程语境里稳定比惊喜重要得多。我之前让AI实现一个列表分页功能没写spec时它给我搞出了五层抽象和三个设计模式写了spec之后它老老实实只写了50行业务代码。差别就是这么明显。1.3 最佳实践的核心矛盾速度与可控性所有AI全栈实践到最后都指向同一个矛盾AI迭代太快但工程质量不能降。你不可能让AI交付一堆无法维护的代码来换取上线速度也不可能完全关掉AI退回手写一切的低效模式。我的做法是给项目画一条“可控性基线”哪些环节可以完全放手让AI加速哪些环节必须人肉卡住。我的分配情况是这样的AI高度自治代码生成、单测用例生成、接口联调、文档补全、日志分析AI辅助决策技术选型、架构设计、依赖引入、性能优化人必须主导需求定义、spec编写、架构评审、发布决策、数据与安全策略这个分配不是拍脑袋拍出来的是踩过坑之后固化下来的。AI最擅长的不是做选择而是把已有选择执行到位选择本身需要的是上下文理解这恰恰是AI最容易出错的地方。后来的所有实践都是围绕这条基线展开的。2. 技术选型一套可落地的AI全栈工具链2.1 模型层不可绕过的统一网关接入AI能力第一件事不是选模型而是决定怎么管模型。团队里每个人的KEY不一样、供应商不一样、模型版本不一样很快会出现“我这代码没问题啊在你那就报错”的鬼故事。所以我会在正式写业务代码前先搭一层模型网关现在最顺手的是LiteLLM Proxy。LiteLLM Proxy解决的核心问题有两个。第一是统一入口所有模型请求都走一个OpenAI兼容的地址通常是本机4000端口团队不用关心底层是哪个厂商的模型代码里只需要写base_url和api_key。第二是成本与限流控制每个模型、每个key的调用量、令牌数、费用都能在dashboard上看清楚。我贴一段实际用的配置敏感信息用占位符替代model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: claude-sonnet litellm_params: model: anthropic/claude-sonnet-4-20250514 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这里有个经验配置里宁可先少接模型也不要一上来就接十个。每多一个模型意味着要多维护一份差异化的提示词和参数调优维护成本是线性上涨的。我通常只保留三个端口一个强推理复杂代码生成、一个便宜快速简单分类、抽取、一个本地小模型数据不出内网的高敏感场景。2.2 应用层框架Spring AI与LangChain怎么选到了应用层很多团队纠结用不用框架。我的判断标准很简单你的业务语言是什么。技术栈本来就是Java的优先看Spring AI因为它和Spring生态天然融合事务、配置、依赖注入都能直接复用技术栈偏Python的LangChain或LlamaIndex成熟度更高Agent相关组件更多。Spring AI这块我今年用了不少。它的优势在于把“模型调用”抽象成了类似数据库访问的编程模式你不需要关心HTTP细节只需要注入一个ChatClient。举个例子RestController public class CodeReviewController { private final ChatClient chatClient; public CodeReviewController(ChatClient chatClient) { this.chatClient chatClient; } PostMapping(/ai/review) public String review(RequestBody String code) { return chatClient.prompt() .system(你是一名资深代码评审专家只指出会导致bug、安全风险和性能问题的地方不要评价风格。) .user(code) .call() .content(); } }这个模式的好处是代码非常干净后续切换模型供应商时业务代码基本不动。但也有个坑Spring AI的版本迭代很快API变动频繁很多网上教程写的用法在当前版本已经被废弃了。我的建议是直接以官方文档为准不要照抄博客。如果你需要更复杂的Agent能力比如多工具调用、记忆管理、循环执行任务LangChain生态会更丰富但代价是抽象层厚出问题之后定位链路长。我个人做法是简单调用用框架复杂Agent自己基于模型网关写轻量编排反而可控。2.3 Agent与AI Coding工具如何嵌入开发流程现在的AI Agent已经从“聊天机器人”变成“数字员工”。在开发流程里Agent不是上来就接管整个项目而是先拆成一个个能独立验证的任务。我习惯用Agent做这几件事根据spec生成初始代码骨架把Issue描述转成可复现的bug报告批量补单元测试自动生成接口文档和变更日志在CI流程里做代码review辅助工具方面我目前主用Cursor和JetBrains AI Assistant但坦白说工具切换成本很低核心是工作流。我的AI Coding工作流永远是“上下文先行”新建会话时先把项目结构、技术栈、编码规范、相关文件路径丢进去再提任务。如果直接把一个需求甩给工具生成的代码大概率需要重写。这里还有一个容易被忽略的点AI编码工具的上下文窗口不是越大越好。很多人一股脑把所有文件都塞进去结果模型被无关内容干扰生成的代码反而更差。我一般控制在“关键文件不超过5个、总token不超过窗口三成”的范围内输出质量最稳。3. 核心实操一个AI全栈项目的完整落地流程3.1 第一步不是写代码是写Spec所有项目最值得花时间的环节是需求到spec的转换。我见过的AI项目翻车八成不是模型不行而是需求本身就模糊。AI不会主动追问“您的意思是A还是B”它会默认你的话是完整的然后给你一个看似合理实则偏掉的实现。我自己会先要求产品负责人或需求方用标准的spec模板描述功能模板只需要包含六个字段功能名称一句话说明这个功能是什么输入用户会提供什么包括类型、格式、取值范围输出系统需要返回什么包括结构、格式、成功/失败标准边界条件空输入、超长输入、并发请求、重复提交等依赖涉及哪些外部服务、数据表、文件验收标准可测试的具体条件例如“列表页在1000条数据时首屏响应小于500ms”拿一个常见场景举例我要做一个“AI生成商品描述”的功能spec中的一个模块可以长这样功能名称根据商品基本信息生成3个不同风格的营销文案 输入商品名称、品类、主打卖点、目标人群、语气偏好可选 输出JSON数组包含3条文案每条不超过80字 边界条件名称为空时返回错误码400卖点超过200字时截断处理目标人群缺失时默认“普通消费者” 依赖调用文案生成模型需经过模型网关统一鉴权 验收标准模型返回稳定JSON每条文案包含商品名和至少一个卖点格式错误时自动重试一次有了这个spec后面的提示词、代码、测试全部可以围绕它展开不会跑偏。这个过程看起来很繁琐但它正是从vibe coding升级到harness × sdd的关键一步先让思路显性化再让AI开工。3.2 AI编程阶段把生成任务拆到能验证的大小写spec之后我会把功能拆成若干“可验证的小任务”每个任务独立提交给AI工具。这里核心原则是一次只让AI做一个逻辑闭合的事情。比如“实现购物车”太大要拆成“实现购物车添加商品接口”“实现购物车列表查询”“实现库存扣减逻辑”等。举一个实际工作流的例子我让AI实现一个“通过API网关转发LLM请求并记录token用量”的模块会先把spec和已有工程结构发给Cursor然后给出一段类似这样的提示词你是本项目的后端工程师。请实现以下spec 1. 新增一个POST /v1/proxy/completions接口统一转发到内部LiteLLM网关 2. 请求体字段model、messages、temperature可选 3. 响应前先从LiteLLM响应头中读取x-ratelimit-remaining-tokens和x-ratelimit-remaining-requests 4. 将请求前后完整信息不含敏感内容写入audit_log表 5. 异常时返回统一错误格式{code: 500, message: ...} 请先阅读以下文件src/main/java/com/example/ApiGateway.java、src/main/resources/application.yaml 完成后请说明修改了哪些文件以及你如何处理超时与重试。这样做的效果非常明显AI生成的代码基本可以直接进review流程而不是推倒重来。此外每一轮AI生成后我都会立刻跑本地编译和单元测试发现问题就带着报错信息回传给AI让它继续修复。这个“生成-验证-修复”循环往复几轮后代码质量可以达到我手写八成左右的水平。3.3 测试环节AI应用该怎么验证才能放心发布AI应用测试和传统CRUD最大的区别是传统接口的断言是确定的AI输出是概率性的。你不能断言模型一定返回某个字符串但你可以断言返回结构、内容约束、耗时、安全合规性。我的测试体系分四层单元测试层验证业务逻辑、数据转换、异常处理不依赖真实模型用mock返回固定结果契约测试层验证模型网关的请求和响应结构防止模型供应商接口变动评测集层准备一个固定的输入集包含典型、边界、特殊场景对每次模型输出做规则校验回归测试层核心功能每次发布前全量运行防止新的变更让旧的AI能力退化评测集是我尤其想强调的一个环节。你光靠人看几条输出根本不知道模型整体是变好了还是变坏了。我会维护一个几百条输入数据的评测集每条数据标注期望行为然后用脚本跑分。比如给模型输出打三个维度正确性、格式合规、内容安全。跑完出一个评分表格对比不同模型版本、不同提示词版本之间的分数变化。这样每次调整提示词或换模型时不是凭感觉而是看数据。# 示例本地评测脚本执行结果简化输出 case_id correctness format safety 001 0.95 1.00 1.00 002 0.80 1.00 1.00 003 0.60 0.00 1.00 avg 0.78 0.67 1.00看到格式合规分数偏低就要检查是不是模型返回格式漂移了然后有针对性地在提示词中增加few-shot示例或者在后端强制用JSON模式解析并增加重试。3.4 部署与可观测AI Infra的最后一块拼图AI应用部署的复杂度和传统服务不在一个量级因为多了一个不确定的第三方依赖模型API。模型供应商可能宕机、限流、响应变慢也可能一夜之间调整版本策略。所以AI Infra层面我最重视三件事容错降级、成本监控、链路追踪。容错降级方面所有模型调用都要有超时控制我实践下来单次调用超时设为连接5秒、响应60秒比较合理并且要有失败切换机制。比如主模型超时后自动降级到备模型或者返回缓存结果。这里不需要多复杂的组件一个简单的策略模式就能搞定。链路追踪方面传统日志只记接口报错是不够的每个AI请求的关键信息必须记成结构化日志至少包含请求ID、用户ID脱敏、模型名、输入token数、输出token数、耗时、重试次数、成本估算。这样出问题的时候能快速回答“这个用户的回答为什么这么贵”“哪个模型供应商今天特别慢”。监控面板我一般用Grafana Prometheus这套组合因为团队熟悉、生态成熟。指标主要盯这几项调用成功率、平均耗时、P95耗时、token消耗速率、单日成本。成本失控是AI应用最容易爆的事情一定要在部署第一天就把计量打点接好不然月底看账单会非常惊喜。4. 常见问题与排查技巧实录4.1 上下文失控AI越改越乱代码越改越糟用AI编程最常见的现象是一开始很好改到后面AI开始“失忆”不是忽略前面定的约束就是重复引入已经被移除的代码。我排查下来主要原因有两个一是当前对话上下文太长重要信息被淹没二是工程代码量太大AI无法在新文件中定位旧逻辑。我的解法是“不要长期复用同一个会话”。每个子任务开新对话把必要信息重新编译一遍再喂给AI。宁可多花一点输入token也好过让AI在长上下文里自由发挥。另一个小技巧是在仓库里维护一个AGENTS.md文件里面写清楚项目结构、命名规范、常用命令、技术选型限制AI编码工具会自动读取它效果比每次口头叮嘱稳定得多。提示上下文清理不是越勤越好一个任务的开始阶段信息量最大这时候反而要把更多精力花在写清楚上下文上后面迭代重开会话时上下文可以适当精简。4.2 测试天天过功能却天天坏很多用AI写测试的团队会遇到这个魔幻场景单测覆盖率90%CI全绿但上线后业务方天天报bug。原因是AI生成的测试经常是“自己验证自己”它写一个add函数就会写一个测add的用例但不会覆盖“add被并发调用时会怎样”“add的输入是null时会怎样”这些真实世界才会出问题的地方。解决思路有两个。第一是写spec时就要覆盖边界条件和异常路径让AI按spec生成测试而不是让它自由发挥第二是要求所有测试用例中包含至少一个边界用例和一个失败路径用例。我甚至会专门写一个“负面清单”让AI生成测试时避坑比如“不要只测happy path”“不要用和实现一样的逻辑去推导断言结果”。4.3 成本失控小功能一天烧掉几百块另一个高频事故是成本失控而且往往发生在几乎没人调用的内部工具上。原因是很多人没有给模型调用设置上限和缓存。我经历过最夸张的一次一个定时任务里循环调用模型参数写错了导致每次循环都重发同一个请求一晚上跑了上万次第二天账单直接爆了。成本控制三板斧我现在是强制执行的所有模型调用必须经过网关统一计量设置日预算和调用量告警重复性请求做缓存相同的输入在短时间内直接返回缓存结果低价值场景用便宜模型比如简单分类和关键词提取坚决不用大模型。另外每次模型调用的token用量要实时记入结构化日志这样成本异常时能通过日志快速定位到具体是哪个功能、哪个用户在烧钱。4.4 数据与内容安全AI生成内容要过哪些关卡内容安全这块很多团队容易后知后觉。模型生成的内容不能直接出网必须要经过内容安全过滤和合规性检查。我目前的方案是在模型网关后挂一层检测服务对模型输出做多道检查涉政、违法违规、隐私数据泄露、PII识别检查不通过就拦截并返回兜底文案。这个只花钱调用一次检测模型但能挡住绝大多数风险。另一个容易被忽略的点是数据脱敏。在把数据发给外部模型之前先做脱敏处理比如把身份证号、手机号、姓名替换成占位符模型返回后再映射回去。这里的坑在于脱敏不能只做一次要在日志、监控、审计全链路保持一致。否则模型输出里带着脱敏前的真实数据一旦日志泄露就是事故。注意凡是涉及用户隐私的功能我建议先在内部统一评审口径哪些数据能发到模型侧、哪些绝不能出境。这个口径宁可严一点也不要事后补救。写在最后从工具使用者到工程负责人的距离如果只让我分享一条经验那就是别把AI全栈开发理解成“用AI把所有代码写完”。我今年最大的一次项目返工恰恰是因为前期太相信AI生成速度后面花了两周重构才把失控的代码捞回来。反过来那些严格按照spes、加护栏、上监控的模块后续几乎没有大面积返工。我现在的习惯是每个迭代跑完都花半小时复盘一份“AI协作问题单”记录这轮哪里AI帮了大忙、哪里AI让我走了弯路、下次怎么调优提示词或护栏。你会发现AI全栈开发的能力是迭代出来的不是买工具买出来的。最后再分享一个小技巧所有AI生成的代码合并前一定要让人看一遍diff不是逐行看而是看它有没有改动你没要求改的文件。AI经常“好心”顺手优化了别的地方而这些顺手改动往往是事故源头。把这个规则写进团队的Review检查表能拦住一大半莫名其妙的回归问题。