报告＂身份证＂对不上——App和服务器各说各话

1. 我们的链路：通话声音 → 服务器 → AI转文字 → AI分析 → 报告JSON。
2. 报告在服务器上生成好了，但App里看不到——还没有展示界面。
3. 这一集：做报告界面，然后发现两个致命Bug，最后全链路闭环验收。

好，开始。

报告生成在服务器上了，但用户打开App啥也看不到。顾问AI安排编程AI做三件事：

① 通话记录列表加按钮。 每条通话记录旁边加一个「📊 生成报告」按钮。点击 → 通知服务器"给我分析这通电话"。分析中按钮变灰显示「⏳ 分析中...」，分析完变「✅ 查看报告」。

② 报告详情页。 点「查看报告」→ 打开一个新页面，展示：报告标题、参与者、通话时长、AI评分、AI分析正文。

③ Markdown渲染。 AI分析正文是Markdown格式（一种带格式的纯文本：#是标题、**是加粗、-是列表）。得找个库把它渲染成好看的样子——编程AI选了一个叫Markwon的轻量库（比用浏览器内核轻量得多）。

编程AI一顿操作，界面做好了，编译通过，装上手机。

然后终端AI一验证，发现两个致命问题：

每通电话在服务器上都有一个编号（叫sessionId，你可以理解成这通电话的身份证号）。

问题是：App和服务器各发各的身份证。

• App自己编的号码长这样：session_6月11日_小红（人话格式）
• 服务器实际登记的号码长这样：call_1781097426153（机器格式）

App拿自己的号码去服务器查："给我分析session_6月11日_小红这通电话"——服务器一查，查无此号。

就像你去医院，挂号处给你编了个号"内科-张-今天"，但叫号系统里的编号是"20260611001"——你拿着前一个号，永远等不到叫号。

就算身份证对上了，还有个问题：App点了「生成报告」后，就再也不管了。

服务器辛辛苦苦分析完，把报告放在那儿，App既不问"好了吗"，也不去取。报告躺在服务器上，App看都不看一眼。

就像你在餐厅点了菜，然后站起来就走了——菜做好了也没人吃。

顾问AI开方子，两个问题一起修：

修身份证： 让服务器当"发号员"——App连上WebSocket后，服务器主动发一条消息告诉App："你这场通话的身份证号是 call_xxx"。App收到后存下来，以后查报告都用这个号。

修"只发不收"： 让App学会"盯梢"（专业叫轮询）——点了生成报告后，每5秒问一次服务器"好了吗？好了吗？"，最多问30次（2.5分钟）。好了就把报告拿回来存进本地数据库，下次直接看，不用再问。

修复后数据流变成了这样（这是整个系列的核心链路，值得记住）：

打电话 → App抓声音 → 推到服务器 → 服务器发"身份证"给App → 挂断 → 用户点「生成报告」→ 服务器分析（GPU转文字 + DeepSeek分析） → App每5秒"盯梢" → 拿到报告 → 存本地 → 「✅ 查看报告」 → 点开 → 报告详情页（Markwon渲染）

修好了，来一场真正的验收：这次不是数数字，而是真聊5分钟。

终端AI拿着两台手机，聊了8分43秒——内容是读一段科幻小说（AI与人在虚拟世界的对话）。43MB的声音文件，送到GPU转写。

转写结果：识别出4个说话人片段（小红的话很少，只有81KB——"xiaohong静音"，这个异常后面会变成大案子）。

然后DeepSeek分析，这次的结果让所有人眼前一亮：

虽然评分有点扎心（毕竟小红全程"没意思"），但——AI真的读懂了一通人话电话！它听出了"一个人在分享、一个人在冷漠"，还给了情感分析！

全链路闭环：通话 → PCM → GPU转写 → DeepSeek分析 → 报告JSON → 验证通过 🎉

这一集有两个收获。技术上的："身份证"必须统一发放——这个道理后来救了我们的命（第20集还有个类似的坑）。心理上的：DeepSeek给我们的对话打了2/10，还分析出"一个渴望共鸣、一个冷漠疏离"——AI比我们自己更懂我们的对话，这就是这个产品的意义所在。

验收虽然过了，但终端AI留了一堆"尾巴"：报告有时候白屏、有时候显示一堆乱码JSON、有时候卡死超时。三座大山压过来：

1. App连不上服务器（Android系统默认禁HTTP）
2. 旧数据捣乱（"身份证"对不上老记录）
3. 服务器"堵车"（分析跑的时候，接口全超时）

《白屏、404、超时三连——三个根因一次说清》。为什么App连不上服务器？为什么旧数据会捣乱？为什么服务器会"堵车"？以及一个改一个字母就解决的大Bug。下期再见