1. 从 vibe coding 到 harness × SDDAI全栈开发的思路转变先说个现象。这两年“AI全栈开发”这个概念被炒得火热好像只要对着聊天框说几句话一个能上线的产品就能自己从屏幕里长出来。我见过不少团队和个人开发者拿着 Cursor、Copilot 一类工具猛写一通前两周确实爽需求一描述代码就出来了界面也有了接口也能通了。但等到了第三周、第四周问题开始集中爆发改一个按钮样式AI 把整个页面布局重构了加一个筛选条件AI 顺手把数据库表结构也改了更离谱的是AI 开始一本正经地调用一个根本不存在的第三方库编译报错后它又煞有其事地“修复”了三轮最后你发现它只是在错误信息外面包了一层 try-catch。这不是工具不行是工作方法出了问题。你在用“vibe coding”的方式做“生产级全栈开发”这俩根本不是一个物种。所谓 vibe coding靠的是感觉和氛围让 AI 自由发挥、想到哪写到哪适合做原型、做 demo、做一次性脚本。但全栈应用是要上线的、要给真实用户用的它需要状态管理、权限控制、数据一致性、异常兜底、可观测性这些东西恰恰是自由发挥最容易翻车的地方。我这一年多做了十几个 AI 辅助开发的项目从内部工具到对外交付的 SaaS 都有踩了无数坑之后最终沉淀下来一套可复制的工作流。核心就一句话别让 AI 当“程序员”让它当“施工队”你当“设计师 监理”。落到具体操作上就是热词里反复出现的那个组合——harness × SDD。harness 是“约束装置”SDD 是规格驱动开发Spec-Driven Development。合起来理解就是把 AI 放在一条有轨道的路上让它跑得快但不允许它脱轨。什么叫有轨道就是你在让 AI 写代码之前先把需求拆成一份足够细致的规格说明书里面写清楚功能边界、数据字段、接口协议、异常处理策略甚至页面交互的反馈状态。AI 的任务不是“思考这个功能怎么做”,而是“照着规格把代码翻译出来”。这样一来AI 的不可预测性被极大地压缩它的优势——快、不知疲倦、擅长模式匹配——被保留它的劣势——幻觉、自作主张、遗忘上下文——被挡在栅栏之外。这套方法不是银弹但它确实把我项目的返工率从 70% 降到了 20% 以内。下面我把整套流程掰开揉碎讲一遍包括需求拆解、规格设计、技术栈选型、实操步骤、部署排查全是实际跑过的方案。1.1 为什么“随性编码”走不远Vibe coding 的字面意思是“跟着感觉编码”这个词最早用来形容一种很放松的 AI 辅助编程状态你不太关心代码具体怎么写的AI 生成什么你就接受什么跑通了就算赢。这种模式在写小工具、画原型的时候特别爽因为试错成本低推倒重来也就几分钟的事。但全栈应用有个本质区别它是有状态的长期系统。今天你图省事让 AI 直接改了一个函数入参明天另一个模块还在用旧签名调用它运行时直接炸。后天你让 AI 加了张表但迁移脚本没跟上测试环境好的生产环境查数据全是空。这些问题在 vibe coding 模式下几乎必然发生因为你没有给 AI 一个“全局约束”它每次只看到局部上下文当然只会做局部最优解。另外一个很少有人提的问题vibe coding 会让你的代码库“人格分裂”。AI 每次生成代码的风格、命名单词、模块划分逻辑都不稳定这周生成的服务层用 UserService下周生成同一个业务的服务层叫 MemberManager混在一起之后别说 AI 自己人看都头大。代码库一旦失去一致性AI 后续修改的准确率会断崖式下降因为它读不懂自己之前的“笔迹”了。所以我的结论是vibe coding 适合“做饭”不适合“开餐厅”。开餐厅要有菜谱、有备料标准、有出餐流程对应到开发上就是 SDD。1.2 把AI装进“轨道”harness 与规格驱动开发Harness 这个词原意是马具、挽具引申为“约束装置”。在 AI 开发里harness 指的是你为 AI 设定的一套边界和工作协议包括但不限于可用的技术栈清单、项目目录结构、命名规范、禁止修改的文件列表、提交信息的格式、测试通过才能交付的硬性要求。SDD 则是把这套边界进一步落到文本层面每个功能模块开工之前先写一份规格文档Spec这份文档是 AI 和人类之间的“合同”。AI 照着合同施工你按合同验收。合同没写的内容AI 不得自行发挥合同写清楚的AI 必须严格执行。我在实际项目里用的流程是这样的需求澄清把业务方的话翻译成功能列表每条功能必须带上“触发条件、输入、输出、异常情况”四个要素。规格编写针对每条功能写清楚接口定义、数据结构、UI 状态、边界处理。这一步不涉及技术实现细节但数据层面的字段名、类型、约束必须写死。上下文打包把规格文档、项目 README、目录树、关键模块的代码摘要打包成一个上下文文件作为 AI 的唯一工作依据。分步施工一次只让 AI 做一个规格单元做完立刻跑测试测试不过就回到上一步禁止在一个对话里堆积多个任务。人工审查与验收AI 交付代码后人必须做一次 Code Review重点检查安全、权限、资源释放、硬编码等 AI 容易忽略的环节。这套流程跑下来的感觉像是把一个天才但散漫的实习生放在一个流程严密的公司里。他依然比你快十倍但每一步产出都是可控的出了问题也能准确定位是哪一环节的责任而不是像 vibe coding 那样整锅粥都是糊的。1.3 这套方法适合谁、不适合谁先泼盆冷水如果你是完全不会写代码的小白harness × SDD 帮不了你太多。因为规格设计本身是技术活不懂数据建模、不懂接口设计你写出来的规格可能比代码还难懂。AI 全栈开发的前置条件是你至少要能读懂代码、会跑测试、能判断 AI 生成的方案靠不靠谱。那这套方法适合谁适合有三类人第一类有传统开发经验、刚开始用 AI 提效的工程师。他们最痛苦的就是“AI 写的代码不敢用”这套流程给了他们一个放权给 AI 的安全框架。第二类独立开发者或者小团队负责人一个人要干前端、后端、运维的活用 AI 把脏活累活顶掉自己专注在架构和产品上。第三类产品经理或者业务人员出身、已经会写点代码的“准技术人”他们不追求代码艺术只追求功能稳定上线规格驱动刚好补上他们最缺的“结构化思维”。不适合谁只想快速搞个 demo 去演示的直接 vibe coding 更高效没必要上全套流程。还有一个群体要特别提醒完全依赖 AI、不自己读代码的人。这种用法不管什么方法论都救不了你因为你连验收的能力都没有AI 早晚把你带到沟里。2. 项目启动前的关键准备需求与规格设计AI 全栈开发最反常识的一个点是写代码的时间被压缩得很少但写需求的时间反而变长了。传统开发里很多需求细节是在编码过程中才逐渐明确的人可以边写边想。但 AI 没有“边写边想”的能力或者说它的“想”太跳跃你给的需求越模糊它发挥的空间越大跑偏的概率越高。我在项目里养成了一个习惯把所有需求先写成用户故事和验收标准的组合。用户故事描述用户想做什么验收标准用“Given...When...Then”的结构描述系统应该怎样响应。比如一个登录功能验收标准至少要有这几条给定未注册的邮箱当用户提交登录表单时系统提示“该邮箱未注册”且不发送任何验证码。给定密码错误当用户连续输入 5 次错误密码时系统锁定该账户 15 分钟并提示锁定原因。给定验证码有效期当验证码超过 10 分钟未使用时系统判定过期并允许用户重新获取。你可能觉得这些细节“不用说都知道”但恰恰是这些没被写进规格的“默认常识”AI 十有八九会搞错。它会默认密码可以无限次尝试默认验证码永不失效默认所有邮箱发验证码之前都不用检查是否注册。这不是 AI 蠢而是它训练数据里的“常规做法”就是宽松的你的应用如果碰巧在一个必须严格的安全场景下这就是事故。2.1 需求拆解的颗粒度规格驱动开发的一个核心难题一个需求拆到多细才合适拆太粗AI 的自由度太大生成结果不可控拆太细写规格的时间可能比写代码还长失去 AI 的效率优势。我的经验是按“可独立测试的单元”来拆。一个功能如果跑完测试就能确认它做对了不需要依赖其他功能的完成那它就是一个合格的规格单元。以“用户注册”为例可以拆成注册表单 UI 与前端校验邮箱格式、密码强度、确认密码一致性注册接口与数据落库唯一性约束、密码加密存储邮箱验证码发送与校验发送频率限制、过期策略、验证状态流转注册成功后的会话初始化与跳转每个单元大概是一个文件或两三个文件能搞定的体量AI 在一个上下文窗口内可以轻松处理不会因为“太久远忘了之前的约定”而出错。这也方便你在某个单元质量不行的时候单独重做这一个单元而不是整个模块推倒重来。2.2 写一份能让AI“看懂”的规格文件规格文件是给 AI 看的“施工图纸”所以它必须是一种“AI 友好”的格式。我实践下来纯 Markdown 的规格文件效果最好因为几乎所有 AI 编程工具都能直接读取 Markdown而且 Markdown 天然支持表格和代码块非常适合描述数据结构与接口。一份完整的规格文件我通常会包含以下区块功能概述用两三句话说明这个模块做什么、不做什么。重点是“不做什么”凡是你不允许 AI 自由发挥的必须写进这个区块。技术约束列出必须使用的语言、框架、包管理工具、代码风格。比如“React 18 TypeScript组件使用函数式写法禁止使用任何 UI 组件库以外的样式方案”。数据模型用表格列出每个字段名、类型、长度、是否必填、默认值、约束。这张表要精确到让 AI“没有选择余地”。接口定义每个接口的路径、请求方法、请求体字段、响应体字段、错误码定义。最好把示例 JSON 请求和响应也写进去。页面与交互页面上的元素、跳转逻辑、加载态、空态、错误态的文案与展示方式。验收标准就是前面说的 Given/When/Then 列表。这是 AI 自我检查的依据也是你验收的依据。边界与例外明确写出哪些情况 AI 需要额外处理比如网络超时、文件过大、并发冲突、未登录用户访问等。这份文件写完之后你先自己通读一遍想象你是一个什么都不知道的实习生能不能只看这份文件就把功能做出来。如果中间有你需要“猜”的地方说明规格还没写到位先补全再开工。2.3 技术栈选型的取舍AI 全栈开发的技术栈选型和传统开发有个很大的不同优先选 AI 训练数据里出现频率最高的组合。因为 AI 的生成能力本质上是在模仿它见过的模式见过的越多生成的质量越高、越稳定。冷门框架不是不能用但 AI 对它“印象不深”生成的代码常常带着旧版本的写法或者虚构出框架里根本不存在的 API。以我常用的组合为例前端Next.js 或 React TypeScript Tailwind CSS。这三件套在训练数据里海量存在AI 生成的质量非常高而且 Tailwind 可以直接避免 AI 写出“不知所云的样式类名”。后端Node.jsNestJS 或 Fastify或者 PythonFastAPI。我个人更倾向 FastAPI因为 Pydantic 的数据校验声明式风格跟规格文档的契合度极高AI 很容易从字段定义推演出正确的请求模型。数据库PostgreSQL。它对 JSON、全文检索、地理数据的支持都很好AI 生成的 SQL 和 ORM 映射也熟练。ORMPrismaTypeScript 生态或者 SQLAlchemyPython 生态。Prisma 的 schema 文件本身就是一种“机器可读”的规格AI 改模型的时候不容易出错。部署Vercel前端、Docker 云主机后端与数据库。Vercel 对 Next.js 的优化是 AI 训练数据里最常见的部署方式踩坑少。这个组合不是“最先进”的但它是AI 生成准确率最高的组合。在 AI 辅助开发这个语境下可预测性比炫技重要得多。3. 实操从0到1跑通一个AI全栈项目理论说够了来走一遍真实项目。我带大家做一个“文档问答助手”用户上传 PDF、Word、TXT 文档AI 解析内容并写入向量库用户在聊天界面提问AI 基于文档内容回答并标注答案来源页码。这是个非常典型的 RAG检索增强生成全栈应用麻雀虽小五脏俱全涉及文件上传、异步任务、向量检索、流式对话、前端状态管理很适合展示 AI 全栈开发的工作流。3.1 场景定义与规格落地第一步先写规格。我不直接打开 Cursor 敲代码而是打开一个 Markdown 文件把需求拆分并写成规格。这份文件的复杂度根据团队规模来定我给自己做个人项目时会简化一些但关键字段表和接口定义一定不会省。拆解之后这个“文档问答助手”的规格单元如下用户系统注册、登录、JWT 会话、上传额度控制免费用户 10 个文档付费用户 200 个。文档上传支持 PDF/DOCX/TXT单个文件不超过 20MB上传后后台解析解析进度分“等待中、解析中、完成、失败”四种状态。向量化与检索文档解析后切块每块不超过 500 字符重叠 50 字符用 Embedding 模型向量化存入 PostgreSQL pgvector问答时从向量库检索 top-5 相关片段拼进 Prompt。对话界面左侧文档列表右侧聊天面板提问后流式显示回答每条答案下方列出引用的文档片段及页码。回答质量回答必须基于检索到的文档内容检索不到相关内容时明确告知“当前文档中没有找到相关信息”禁止编造。写到这里规格里已经出现了“500 字符、top-5、重叠 50 字符”这种具体参数。这些参数可能不是最优的但它们的价值在于把 AI 的自由度锁死在一个既定的试验范围内。之后想调参改的是规格文件而不是让 AI 在代码里“自由优化”——它所谓的优化经常是一顿乱改然后回滚。3.2 用AI生成后端API与数据模型规格写好后开始进入施工环节。以 FastAPI 为例我把项目根目录的 README 和 specs/docs-assistant.md规格文件作为上下文让 AI 依次生成数据模型和核心 API。第一步是数据模型。我会给 AI 一段提示词模板请严格按照 specs/docs-assistant.md 中的数据模型定义生成 SQLAlchemy 模型文件。字段名、类型、约束条件必须与规格完全一致不得自行新增字段或修改字段含义。生成后请附上对应的 Alembic 迁移脚本。这里有个细节我让 AI“字段名、类型、约束必须与规格完全一致”而不是说“帮我设计用户表”。因为一旦让 AI 参与设计它就会开始加一些自己觉得“有用”的字段比如用户表额外加一个 nickname昵称文档表多加一个 tags标签。不是说这些字段一定有害而是这种“游离于规格之外”的改动累加起来会让系统变得不可控。规格驱动开发的精神就是一切改动必须经过规格变更流程而不是由着 AI 临场发挥。生成完之后两个工作必须立刻做一个是编译 启动测试。任何模型文件生成后先跑一遍alembic upgrade head确认数据库迁移能顺利执行。另一个是人肉审一遍模型关系。AI 在处理多对多关系的时候经常连续犯两个低级错误要么忘记建关联表要么关联表建立后外键没有索引。第二个错误在数据量小的时候毫无感觉数据量上来后一次关联查询直接把你慢到超时。3.3 用AI生成前端页面与交互后端骨架搭好后我来写前端部分。这次我用 Next.js 14 的 App Router页面结构和交互逻辑拆成三个部分上传页、文档列表页、对话页。前端开发中我特别强调一个原则先让 AI 实现完整的交互状态再填业务逻辑。很多 vibe coding 翻车案例都是跳过了交互状态直接让 AI 写“功能”。结果就是点击上传按钮之后用户完全不知道发生了什么没有 loading、没有进度、没有成功失败提示界面跟死了一样。所以我在给 AI 的提示里会明确列出要实现的交互状态请实现上传组件的完整状态机包括idle初始态、uploading上传中显示进度条、parsing解析中显示旋转图标和文案“文档解析中约需 1 分钟”、success上传成功显示绿色勾、error上传失败显示具体错误文案。所有状态切换必须有对应的视觉反馈。这里有个很有意思的现象当 AI 被要求“先把状态机写好”它写出来的代码质量会高一个档次因为状态的穷举本身就是在帮它建立边界意识它知道在什么节点该做什么判断在错误分支上也会表现得更稳健。反过来如果你直接说“做一个文件上传组件”AI 大概率只在 onSubmit 里 fetch 一下就完了异常处理全靠浏览器默认行为。另一个前端实操经验让 AI 用 Tailwind 的原子类去写样式但结构上抽成小组件。比如上传按钮、文档卡片、消息气泡各归各的文件。如果让 AI“顺便”把样式也全部写在一起很快你的组件文件就会膨胀到 500 行以上既难读AI 后续修改时也容易出现“改 A 组件不小心动了 B 组件样式”的问题。3.4 AI Agent的编排与集成这里再单独讲一下“AI Agent”。我在项目里用 Agent 的场景是把整个问答流程拆成一个可编排的流水线。接收用户提问后Agent 做这几件事判断是否涉及文档内容检索用 LLM 做一个意图分类。涉及检索就调用检索工具从向量库拉回相关片段。把片段和用户问题拼成 Prompt请求 LLM 生成回答。在回答的流式输出过程中把引用的片段和页码包装成结构化数据一并推给前端。用 FastAPI 实现这个流程我用的是 LangGraph或者用比较轻量的自研状态机。这一步之所以值得写成“Agent 编排”而不是“在路由里写死逻辑”关键在于每一步之间都有状态和数据的中转而 Agent 框架帮你把这些中转的胶水代码管起来维护成本低很多。我对 Agent 编排的核心建议是能用普通函数写的逻辑绝不交给 Agent 框架。很多人一听“Agent 开发”就恨不得把整个后端都塞进一个 loop 里让 LLM 自己决定该干嘛这是灾难的起点。LLM 的推理是会抖动的同样的输入今天走 A 分支明天走 B 分支后端逻辑一旦引入这种不确定性监控和排障的难度直接乘以 10。正确的做法是把确定性逻辑写死比如文件格式判断、字符数检查、状态流转只把真正需要语义理解的环节交给 LLM比如意图分类、答案生成。该硬的地方硬该软的地方软这才是“Agent 全栈”的正确打开方式。4. 让AI代码能上生产审查、测试与部署AI 生成的代码跑通本地只是万里长征走完了第一步。真正考验功力的是怎么让这套代码能在生产环境稳定运行。因为 AI 生成代码的“完成度”很高但“健壮性”经常是缺位的。它对边界情况极端输入、并发冲突、第三方服务超时、数据库连接池耗尽的处理往往非常粗暴甚至根本不处理。4.1 人工审查的检查清单每次 AI 交付代码后我不会直接 merge而是按一张固定清单做 Code Review。这套清单是我从十几个生产事故里总结出来的每条背后都有血泪教训权限校验接口有没有做登录校验资源操作有没有校验归属权比如用户只能删自己的文档AI 最常犯的错是“登录后才能调用”写对了但“只能操作自己的资源”漏了。结果是任何登录用户都能通过改 URL 里的 ID 删别人的文档。资源释放文件句柄有没有关闭数据库连接有没有归还连接池AI 经常在异常分支里忘了关闭文件流Windows 上开发还好Linux 生产环境你有 100 个用户各上传一次大文件文件句柄就被吃光了。输入校验是不是只校验了前端传来的数据后端有没有做二次校验长度有没有限制文件类型有没有用 MIME type 之外的魔数文件头字符做二次确认硬编码API 密钥、数据库密码、内部服务地址有没有出现在代码里AI 非常喜欢把配置直接写死在环境变量文件里而且这个文件还经常被它顺手提交到 git 仓库。错误处理第三方服务挂了怎么办AI 是不是只在 catch 里打了行日志就继续往下跑前端会不会看到 500 之后永远停在 loading 转圈这五条是底线级别的检查项不通过就不允许合入主干。4.2 测试策略让AI自己写测试传统开发里测试是保证质量的最后一道防线。AI 全栈开发里测试的作用更核心——它是你“敢于把代码交给 AI 改”的底气来源。我的做法是每个规格单元交付的时候要求 AI 同时交付一组测试用例。测试用例必须覆盖规格里写的所有验收标准另外至少包含 2~3 个异常路径的用例。我会在提示词里直接要求请为这个模块编写单元测试覆盖以下场景[列出验收标准中的正常与异常场景]。测试应当使用 pytest数据库操作使用内存型 SQLite 或测试容器。测试必须能够在 CI 环境中稳定运行不依赖外部网络服务。有一个重要的提醒不要让 AI 自己评估“测试是否通过”。AI 觉得“测试通过了能跑了”和实际 CI 里的绿灯完全是两码事。它经常在测试文件里自己 mock 掉关键逻辑然后断言 mock 对象被调用了这种测试毫无价值。你必须保证测试是独立运行的而且至少有一个端到端级别的测试是真正走完整个业务流程的。我在项目里常年保留一个“冒烟测试”文件里面就一条用例启动整个应用注册用户、上传文档、发起问答、在流式输出里拿到第一个 chunk、确认回答里包含预期的关键词。这条用例不走任何 mock所有组件真实协作。它保证了每次迭代之后系统不是“看起来散了架”。4.3 部署与运维注意点AI 生成的代码部署上最容易踩的坑集中在两个地方一个是环境变量的管理另一个是构建缓存与版本一致性问题。环境变量的管理我推荐直接上 Docker .env.example的方式。你让 AI 生成一个.env.example模板里面把所有需要的变量名放进去并附上注释说明用途。生产环境的真实值通过部署平台的 Secrets 管理Vercel 的 Environment Variables 或者云主机的 systemd EnvironmentFile注入不落到代码仓库里。这一步做好了AI 把密钥硬编码进代码的冲动就少了一半因为“它知道有地方可以放配置”。构建缓存的问题在 Next.js 项目里特别突出。AI 经常会升级依赖包但node_modules和.next目录里的旧缓存会掩盖问题。我遇到过最诡异的一次本地npm run build一切正常部署到服务器上构建却报了一个莫名其妙的类型错误。查了两个小时最后发现是服务器上的 Node.js 版本比本地低了两个大版本AI 的代码用了新版语法。从那以后我的所有项目都必须带.nvmrc锁定 Node 版本Dockerfile 里也写死 node 镜像的 tag彻底切断“版本漂移”的隐患。部署完成后监控和日志是最后一环。我要求 AI 在每个后端路由的模块里import 一个Logger 实例并且关键操作用户注册、文档上传、问答请求都必须打一条结构化日志包含请求 ID、用户 ID、耗时。这不难实现但价值极大。AI 全栈项目最怕的就是“黑盒上线”出了问题连日志都找不到那 AI 帮你省下来的时间会在排障环节加倍还回去。5. 常见问题与排查技巧实录下面整理一下我在 AI 全栈开发中反复踩到的坑。每一个问题我都给出现象、原因和排查方法希望能帮你少走弯路。5.1 AI“幻觉”出根本不存在的库或API这是新手上路第一坑AI 一本正经地引用了from fastapi_extra_tools import SmartRouter然后你pip install了一下发现 PyPI 上根本没这个包。或者更隐蔽的情况它推荐的包是存在的但版本对不上它用了新版本的 API 接口但你装的旧版本没有这个方法。我的解决方法有两个。一是在规格文件的技术约束里写死“允许使用的依赖清单”AI 只能从清单里选超出清单的 import 一律不允许。二是让 AI 在生成代码后附带一份 requirements.txt / package.json然后你在独立环境里从零安装、编译、跑冒烟测试。如果冒烟测试过不了直接回到上一个节点告知 AI“编译失败请检查依赖是否真实存在、版本是否正确”而不是自己手工去修——你一旦开始手工修AI 的上下文就乱了后面的生成结果会越来越跑偏。还有一种“幻觉”是生成器级的AI 会凭空捏造一个函数返回结构比如明明接口文档里写的是{ code: 0, data: { list: [] } }AI 生成的代码里却取的是response.data.items。这种情况我在 OpenAPI 驱动的类型生成场景下遇到最多。解法是在规格里明确要求“根据 OpenAI Schema 生成 TypeScript 类型”而不是让 AI 自己看代码推断。5.2 上下文丢失导致的约束失效AI 的上下文窗口再大也是有边界的。你让它在同一个对话里连续做五个规格单元大概率在做到第三个的时候它已经忘了第一个单元里的命名约定和字段定义。你发现它把userId改成了ownerId把status的枚举值从pending/success/failed改成了waiting/completed/error。这种问题靠“同一个对话里反复提醒”是没用的AI 的注意力只会越来越分散。我的做法是一个规格单元开一个新对话每个新对话只加载对应的规格文件和必要的上下文。如果发现 AI 在单元内部出现约定漂移把规格文件重新发给它并明确指出“请以规格文件为准你刚才生成的代码里哪些字段与规格不一致请列出并修正”。另外我在项目里维护了一个AGENTS.md或者叫CLAUDE.md文件放在项目根目录里面写清楚整个项目的全局约定目录结构、命名风格、前端组件划分原则、后端分层规范、环境变量命名规则。每次新开对话我都让 AI 先读这个文件再动手。它相当于一个“长期战备记忆”专治上下文丢失。5.3 数据库迁移与数据一致性问题AI 全栈项目迭代速度快数据库表结构几乎每周都在变。AI 生成的迁移脚本经常出问题改字段类型的时候没写数据转换逻辑删字段的时候没考虑有没有下游还在引用加唯一约束之前没先处理脏数据。我的经验是生产环境的数据库迁移必须走“手写审查 灰度执行”的流程绝不能直接让 AI 在本地跑个alembic upgrade head然后 push。我会要求 AI 完成以下操作首先生成迁移脚本的 diff第二明确每个变更对已有数据的影响第三在 staging 环境先执行一遍验证数据没有任何异常后再部署到生产。一个很实用的技巧每次迁移之前先把生产数据库的当前 schema 导出一个 SQL 快照部署后做一次对拍看看除了预期的迁移之外有没有 AI“顺手”改掉的地方。这种事情真的发生过AI 不仅在迁移里改了表结构还顺手改了某个索引的名字结果线上某个查询走了全表扫描慢查询直接把数据库 CPU 打满。5.4 多智能体协作的混乱问题当项目大到一定程度你会开始尝试“多 Agent 协作”一个 Agent 写前端一个 Agent 写后端一个 Agent 写测试。听起来很美好实际操作起来两个 Agent 经常会“互相打架”——后端 Agent 定义了接口返回结构前端 Agent 不知道按自己的理解调用了不存在的字段。多智能体项目里最容易出问题的就是“接口契约”的同步。我的解法是接口定义不依赖 Agent 之间的沟通而是依赖一份 Contract 文件。后端 Agent 每个接口写完后必须更新contract.yaml前端 Agent 开工之前先读这份 Contract 文件所有的请求调用都用它来生成类型定义和 mock 数据。这个做法的本质是把“Agent 间的口头约定”变成“机器可读的合同”谁违反合同谁负责修。有了这条多 Agent 协作才不会变成多个“野生流派”之间的混战。5.5 回答不准确与调试手段最后说一下 RAG 类的 AI 应用最容易翻车的地方。你做文档问答助手最尴尬的时刻就是用户问了一个文档里明明白白写了的答案但 AI 回答得驴唇不对马嘴。十次里有九次问题不在大模型而在“检索环节”——向量化时文档没切好、Embedding 模型不合适、检索结果 top-k 太小、或者提问被无关文档带偏了。排查这个问题我通常会打开一个 Debug 模式在对话界面的开发者工具里把“被检索到的文档片段”展示出来人工检查召回的内容到底相不相关。如果片段里根本没有答案那要么是文档解析出错比如 PDF 提取出来是乱码要么是切块切得太碎把答案劈成了两半要么是 Embedding 模型不适合当前语言场景中文场景用开源的 BGE 系列通常比一些英文模型好不少。如果片段里有答案但 AI 回答错了那问题就在 Prompt 引导或大模型本身可以直接换更强的模型或者重写 system prompt。整个排查链条走下来你会发现 AI 应用跟传统应用的调试方式没有本质区别都是先定位出错环节再针对性地调整。不要把 AI 当成一个神奇的黑盒子把它当成系统中的一个普通组件。你的系统设计越好组件间的边界越清晰AI 出问题时的排查范围就越小。6. 几个值得坚持的长期习惯最后分享几个我在大量 AI 全栈开发实践中沉淀下来的长期习惯这些习惯不一定能立刻体现在代码里但对项目的长期健康影响很大。第一个习惯是定期做“规格回填”。当你在 AI 生成的代码上做了人工修改花几分钟把改动同步回规格文档。因为 AI 后续的每次修改都会以规格为准如果规格和实际代码不一致AI 就会“迷惑”甚至根据过时的规格把已经修正的代码改坏。规格文件的价值在于它是“最新真相”不在现场维护它它就会变成一堆过时的废纸。第二个习惯是给 AI 的每一次生成设定“时间盒”。我发现一个规律让 AI 在同一个上下文里反复修改同一个文件前面两轮通常有效第三轮开始它就会陷入“原地打转”改了 A 又改回 A甚至引入新的 bug。所以我给 AI 设定一个规则同一个文件如果连续修改超过三轮还没有通过测试就新开对话、重新加载上下文、清空历史把它当成第一次来写。这个习惯帮我避免了很多“AI 越修越糟”的困境。第三个习惯是保持“人审”的肌肉记忆。AI 全栈开发最大的危险不是 AI 能力不足而是开发者因为过度信任 AI 而放弃了自己的判断力。我见过有人把 AI 生成的代码直接推到生产连本地跑都没跑过。这种“信任”是拿生产环境在赌。我自己的规矩是AI 写接口我审完才合入主干AI 写测试我跑完觉得有意义才接受AI 写部署配置我会先看一遍端口、域名、环境变量有没有错位。AI 是效率工具它没法替你做最终决策。7. 结尾的小感触做了一年多 AI 全栈开发我的一个强烈感触是技术从来不是瓶颈流程和组织方式才是。你用 vibe coding 的方式AI 就给你一个“原型级”的质量你用 harness × SDD 的方式AI 才能给你“生产级”的回报。工具一样人一样唯独工作方式变了结果天差地别。最后补一句大实话AI 全栈开发的门槛比很多人想象的低但天花板也比很多人想象的高。低在于你不需要背太多框架 APIAI 帮你记着高在于你需要更强的系统思维——拆解需求、定义规格、设计数据流转、把关边界条件这些能力不但没被 AI 替代反而成了 AI 时代工程师的核心竞争力。能把“给 AI 写规格”这件事做扎实的人未来无论工具怎么更迭都会是那个掌握主动权的人。