大家好，我是东哥。「Vibe Coding AI编程实战」系列第6篇。
上一篇我们把任务管理搭好了，Plan文档拆成的40个任务全同步到了Linear上，AI干一步就自动打个勾。今天正式开干后端——那个会查数据库、能出图、能回答业务的智能数据分析代理。
后端是整个项目最容易连环翻车的地方。不是AI写不出来，是模块一多，一个接口没对上，后面全跟着出错。我用的招就四个字：测试先行。
按阶段拆，一步一步来
整个后端我拆成了几个阶段：先搭前后端脚手架并启动验证，再做前端UI，最后啃后端核心——模型接入加NL2SQL。
前面2个阶段相对简单。脚手架就是建目录、装依赖、起服务、探一下健康检查接口，确认服务能跑再说。前端只告诉AI三栏布局（左边会话列表、中间问答、右边图表），让它自己”抽卡”生成页面，出来的样子还行。
真正难的是第3个阶段：后端要接上千问模型，还得让模型把人话变成SQL去查数据库。这两件事，任何一件没整明白，后面全得返工。
接模型前，先用MCP查官方文档
接千问这一步，我没让AI直接写。先接了一个docs-langchain的MCP——它能连到LangChain官方文档，让AI实时查最新规范。
查文档这步我用的是ask模式，只问不写代码。我问它：在LangChain框架下，怎么接入千问？怎么做NL2SQL？有哪些现成组件能用？
AI查完告诉我，LangChain有SQLDatabase和create_sql_agent这种现成组件能做NL2SQL。但查归查，能不能用、字段长什么样，还得自己测了才算数。
最小测试：拿到真实字段再说
这一步是整个流程最值钱的动作。
我让AI新建一个.py的小测试文件，用阿里云百炼的DashScope SDK接千问（现在最新是Qwen3.7），先调通最基础的对话，再开流式输出，最后试工具调用。每跑通一项，就把真实返回的字段记下来——流式输出吐的是哪几个字段、工具调用的参数藏在哪、结构化输出怎么强制返回JSON。
NL2SQL那部分也一样。我让AI先测LangChain的NL2SQL组件，拿到它真实的输入输出接口。测完发现，现成组件的编排方式和我想要的不完全合拍，最后我让它自研了一套编排：先理解意图、再生成SQL、用sqlglot做安全校验（禁删表、禁SELECT *、强制加LIMIT）、执行查库、生成图表配置、总结回答，全程SSE流式往外吐。
为什么要加一道sqlglot校验？因为SQL是AI生成的，万一它手一抖写个DROP TABLE删库，或者来个SELECT *把几百万行数据拉爆，后果不堪设想。加这层AST级的安全审查，等于给AI的SQL戴个枷锁，不安全的直接拦下。这种细节，你不测、不查文档，根本想不到。
测试字段追加到开发文档，再集成
两份测试拿到的真实字段规范，我没让它就这么过去。明确告诉AI：把这些字段规范追加到开发任务文档里，作为后续和前端对接的参数说明。
文档更新好，再让AI按这份带真实字段的规范去写集成代码。这一步基本一次过。为什么？因为AI手里有了真实返回样板，不用靠猜。
报错不可怕，定位才关键
集成过程也不是一帆风顺。健康检查接口对不上、Trae把后端服务起了多个、数据库查出来没数据——这些都遇到过。还碰到一个隐藏坑：Pydantic升级到v2后，BaseSettings被拆到独立包里，AI按老版本写就没装上，得手动补一个pydantic-settings依赖。这种版本变迁的坑，AI不一定知道，得你自己盯着报错信息把它揪出来。
数据库那个挺典型。API测试通过了，但一查数据是空的，因为建完表没插模拟数据。让AI补一段初始化脚本，插进去一百个客户、一千个订单，再测，查询结果就正常了。
这里有个核心经验：每个阶段都要拿到真实的输入输出。做到了这一点，后面前后端联调一旦出问题，你能立刻判断——后端接口我测过了是通的，那问题肯定在前端某几个参数上。排查范围从”整个项目”缩到”某两个模块之间”，debug就轻松了。
范式转变：从盯代码到盯文档
走到这儿，后端核心已经跑通。整个任务流程执行下来，我没敲一行代码，但改了好几次那份开发文档——每测通一个模块，就把真实字段追加进去。
这其实就是AI编程的范式：你维护的不是代码，是一份越来越准的文档。文档准了，AI照着写就八九不离十。
下一篇，拿着这份准文档，和前端正式联调。