大家好，我是东哥。「Vibe Coding AI编程实战」系列第7篇，也是这个智能数据分析代理的收尾篇。
上一篇后端核心跑通了，今天做最后一步，前后端联调，再把整个项目踩过的坑总结成几条铁律。
联调铁律：让一方先”准”，另一方去适配
联调最容易翻车的地方，是前端和后端两边你都不确定对不对。
我的做法是：执行联调前先切Plan模式，让AI对比前端的接口和后端真实返回的字段，看看哪儿不匹配。关键是以后端真实字段为准，让前端去适配。因为后端我是上一阶段一个个测过的，字段是真实跑出来的，可信。
这一步很关键。如果你两边都不确定，AI会陷入自我怀疑，一会儿改前端一会儿改后端，反复debug找不到头。固定一方、适配另一方，是联调能一次过的前提。
阶段4：SSE流式、图表绑定、端到端测试
字段对齐后，阶段4主要做三件事：前端封装API服务层、实现SSE流式接收、把图表数据绑上去，最后端到端测试。
这一步出了几个典型坑。
第一个是SSE流式的”响应完整性”测试失败。SSE这种流式输出，后端得推一个特殊结束标识，前端收到才知道”流完了，别再监听了”。这个标识没对上，前端就一直傻等。让AI补上结束标识，很快搞定。
第二个是删除会话的接口出了问题，测试卡在清理那一步。把报错复制给AI，它自己改。
第三个坑最值得说。后端突然起不来了，8000端口访问不通。一查，AI自己又新建了一个虚拟环境装依赖，搞出两个重复的虚拟环境、多个8000端口。
AI不能完全交给它，得盯着服务状态
这是我想重点提醒的一条经验：AI不能完全甩手交给它。
碰到服务起不来，如果你不告诉它”现在有多余的虚拟环境”，它的第一反应是再建一个新的，越搞越乱。你得看它实际的输出，结合服务状态（端口、进程、虚拟环境）灵活判断，给它指个方向。
完全甩手交给AI，它会在你眼皮底下做一堆莫名其妙的事。你的角色是当那个”看仪表盘的人”，AI偏了就拽一把，写代码的事交给它就行。
“假测试通过”是最隐蔽的坑
联调里还有个特别隐蔽的坑：AI声称测试通过了，但其实根本没真测。
端到端测试报”通过”，我一查，AI压根没配大模型的API Key，它所谓的”测试”只验了UI框架和接口连接，没跑真实的LLM对话。这种”假通过”最坑人，你以为通了，上线一问就露馅。
后来我让它用真实API Key、跑完整的对话流程来测：提问→理解意图→生成SQL→查库→出图→回答，整条链路走完，才敢说”通过”。涉及外部服务的接口，一定得这么验，别信AI嘴上的”测试通过”。
还有个小坑：上下文记忆会”偷懒”
测试时还遇到个怪现象。同一个会话里问过的问题，再问一遍，AI直接从历史记录里找答案，压根没走NL2SQL流程，结果该出图的地方没出图，提示”暂无数据”。
原因很简单：上下文记忆把它惯坏了，它觉得”这题我刚才答过，直接复用”。解决办法也简单，新建一个会话再问，它就老老实实去查库了。这种小坑不影响大局，但不知道的话会怀疑系统坏了。
收尾经验：MCP按需接，Rules大道至简
项目跑通了，最后分享两条贯穿全程的经验。
第一条，MCP别盲目接。网上很多人吹”接一堆MCP自动干这干那”，千万别信。每个MCP都吃token、占上下文，全接上反而让AI搞不清项目整体架构。正确做法是按需接入，用LangChain才接LangChain的MCP，做任务管理才接Linear的MCP。而且要搭配Rules按文件类型触发：改.py文件才加载LangChain MCP，改前端就不加载，省token。
第二条，Rules要大道至简。别迷信Rules能解决一切，没事别瞎加规则，保持代码简洁。编写时别上网找通用模板，也别手写，把官方文档喂给AI，提你的需求，让它写。先跑出一个最简单的MVP，等AI反复在同一个地方犯错时，再针对性地迭代规则。第一次写别妄想覆盖所有场景。
范式总结
整个项目做下来，我维护的始终是文档，不是代码。需求文档、调研报告、Plan规划、字段规范，这些越来越准，AI照着写就越来越稳。
这套从需求到联调的完整流程，换个项目照样能用。下一篇，我们开新的坑。