核对时间:2026-09-17(Session 036/037) 核对方法:全仓库 grep 网络调用点 → 逐个反查调用方 → 再看它支撑了哪些 用户能感知的行为。复核命令见文末,可重跑。
老接口 = {VITE_API}(//qingpu-data-api.metamaker.cn)。
| 功能 | 接口 | 备注 |
|---|---|---|
| 对话(SSE) | POST {VITE_CHAT_API}/api/chat |
|
| 问答记录(历史)写入 + 读取 | DMS 栏目 1889 | 一问一答一条;title = 问题文本 |
| 点赞/点踩/取消 | DMS 1889 的 c_feedback_* |
|
| 删除会话 | DMS(清 1889 记录 + 1887 旧行) | |
| 政策卡片与协议内容 | 随 /api/chat 下发 |
|
| 惠企政策库数据 | 静态 json policies_public.v1.json |
⚠️ 1887 助手会话的写入范围(2026-09-23 时的准)
- 仍然写,但只有一处:回答正常完成(
totalResponse)时写一次,见useBusinessAssistantChat.ts的void upsertDmsSession(...);有源码级断言钉着「活跃调用点只有 1 处、且在 totalResponse 内」 (verify-dms-payload-fields.mjs第 4 节)。中断/报错的轮次不写。- 新建会话、改名不再同步(2026-09-18 的决定只废了这两条),所以前端会话列表仍是纯本地为主, 登录后另按
c_credit_code拉远端会话合并(读侧会排除c_is_login="0"的访客行)。- 建行策略:2026-09-18 曾是「访客且本轮没有企业信息就不建行」,2026-09-23 由用户推翻—— 只要对话就建行;那种情况下行里放
c_ip/c_is_login="0"/ 时间戳 / 标题与四个必填运营位,c_credit_code留空(不写访客标签)。- 停用的调用点(
updateSessionInfo/syncSessionTitleToServer)按约定注释保留在useBusinessAssistantChat.ts。
用户看到什么:右上角账号区。未登录显示「青浦区区内企业登录」(可点,跳一网通办), 登录后显示企业名 + 首字母头像 + 退出登录,还会飘一个气泡「识别到您为我们区内企业,推荐登录」。
怎么走到老接口:
| 入口 | 接口 |
|---|---|
| 从一网通办带 ?access_token= 跳回来 | POST /enterprise/login 换 credit_code + authToken |
| 带 ?credit_code= 跳回来 | GET /fta_ent_policy/enterprise_info 直接拉企业信息 |
这个身份一共被 5 处依赖(所以它不只是"显示个名字"):
isEnterpriseLoggedIn)ba_chat_history;访客 → ba_temp_chat_historyc_credit_code = 企业信用代码,未登录则 访客_<访客id>⚠️ 前端只用企业信息的
name与credit_code两个字段(其余 19 个字段零引用)—— 所以真要用 DMS 的企业信息(栏目 1888)替换它,成本很低。
用户要求删掉统计埋点的老接口。已删除:
BusinessAssistant.vue(页面浏览)、BusinessRecord.vue(反馈统计)src/network/api/assistant-statistics.ts(连同 VITE_ASSISTANT_STATISTICS_BASE_URL 这个已无人用的 env)getOrCreateAssistantVisitorId),因为 DMS 记录访客归属
(访客_<id>)在用它 —— 已搬进 src/network/api/dms/chat-sessions-dms.ts。
localStorage 的 key 字符串保持原样(assistant_statistics_visitor_id):
改了会让已存在的访客全部换新 id,同一浏览器在 DMS 里就变成两个访客了。触发:点输入框的麦克风 实际只依赖 1 个接口:
wss://qingpu-data-api.metamaker.cn/common/asr_hub
?project=qingpu&engine=aliyun_dashscope&is_long_connection=true&heartbeat=true
(移动端多一个 &max_sentence_silence=5000)
host 取自 VITE_ASR;引擎是 aliyun_dashscope(阿里云百炼),不是讯飞
鉴权不需要调接口:token 硬编码在 asr/index.ts 里
(JWT iss: human-large-screen,exp 2034-12-29)—— 所以 ASR 没有 DMS 那种每天换 token 的问题
调用方还硬编码传了一个 appKey(new ASR("<key>", {audio:true,video:false})),
但它在当前分支用不到(只在讯飞分支的 gen_auth 里用)
未启用的讯飞分支(index.html 硬编码 globalThis.isXF = false,走不到):
POST {VITE_XF_ASR}/api/human_asr/v2/asr/gen_auth 取鉴权
wss://{VITE_XF_ASR}/api/human_asr/v2/asr?Authorization=...
与对话协议无关,历次迁移没碰它。
连接:wss://<host>/common/asr_hub?project=qingpu&engine=aliyun_dashscope&is_long_connection=true&heartbeat=true
| 步骤 | 内容 |
|---|---|
| 1. 握手 | 客户端发一帧 JSON 文本:{"card_id": <id>}(注意:不是上面 XF 分支那套 business/data 参数) |
| 2. 上行 | 二进制帧,裸 PCM:格式声明为 audio/L16;rate=16000、encoding: raw,按 CHUNK_LENGTH 切片、CHECK_INTERVAL 定时发(new Int8Array(data) 直接 send) |
| 3. 下行 | JSON:{"data": {"result": {…}}},关键字段 text(识别文本)、pgs("apd" 等分段标识)、command("start" / "stop")、is_sentence、is_quit、ls、ws |
| 4. 收尾 | 非讯飞分支用 {"command": "close"};讯飞分支用 {"data": {"status": 2}} |
要实现自建网关,照这张表实现即可——前端不用改,只要把
VITE_ASR指向新地址。 引擎侧可以接你自己的阿里云百炼 / 讯飞 / 本地模型。
POST /common/qp_signed_url
取 OSS 签名 → 直传 OSS/api/chat 只收 {thread_id, question},附件传不上去,
上传入口整块被注释(BusinessAssistantMobileInputShell.vue 里有说明)useBusinessAssistantUpload.ts 里的),
等后端定了附件契约才能接上{VITE_MODEL_SERVER}/v1/policiesfetchPolicyList 里前面两档(惠企政策库 262 条 / 本轮卡片兜底)几乎总能命中,
第三档基本走不到openid 换 token —— 只在 test 构建VITE_USE_KNOWLEDGE_API === false 时执行,四份 env 里只有 .env.test 是 falsePOST {VITE_DMS_API}/file/uploadFile(→ http://121.43.55.7:10081/dms/file/uploadFile,
经 /dms-api 代理)。multipart/form-data,五个字段都必填:
file / type(0 图·1 音·2 视·3 文件)/ columnId(1889) / contentId(0) / paraName(c_question)。
返回 {"code":200,"content":"/static/photo/1889-c_question-<uuid>.png"} —— 相对路径,
它随聊天请求体的 pictures / files 发给后端(见 api-chat.md 的多模态节)
{VITE_DMS_API}/static/photo/… 实测 200(buildDmsFileDisplayUrl() 干这个)harness/tools/verify-dms-file-upload.mjsPOST {VITE_UPLOAD_SIGN_URL}/common/qp_signed_url
取签名 → 直传 OSS → 得到绝对地址。2026-09-23 用户要求改用 DMS 存储,代码整段注释保留
(useBusinessAssistantUpload.ts),VITE_UPLOAD_SIGN_URL 这个 env 也一并未用main.ts),写 DMS 前会 await 一次(内部缓存 + 并发去重)GET {VITE_IP_API}/proxy/verify/getIPByBrowser → 纯文本 IP
(响应头 Content-Type 标的是 application/json,但正文就是裸 IP —— 按 text 读,别 JSON.parse)http://121.43.55.7:10011,页面是 HTTPS ——
接口带 Access-Control-Allow-Origin: *(跨域没问题),但混合内容会被浏览器拦掉。
dev 见 vite.config.ts 的 /ip-api/;生产需要 nginx 把 /ip-api/ 转发到
http://121.43.55.7:10011/(去掉前缀)c_ip 存这个 IP;访客身份(1889 的 c_credit_code)用 访客_<IP>访客_<浏览器随机 id>,只是归属不稳定(见 src/utils/client-ip.ts)| 位置 | 原本支撑的功能 | 处置 |
|---|---|---|
src/network/api/card/index.js(getMediaList / giveFeedback / appendHistory) |
卡片媒体信息、点赞点踩的旧接口版落库、追加服务端历史 | ✅ 2026-09-18 整文件删除(连同 useBusinessAssistantChat.ts 里那个未使用的 import cardAPI) |
src/network/api/assistant-statistics.ts |
使用统计埋点 | ✅ 2026-09-18 整文件删除(访客 id 那部分已搬进 DMS 模块,见第二节) |
PolicyListUpdatedMatch.vue |
旧协议 <policy-list-updated> 卡片列表 |
⚠️ 保留:仍被 BusinessRecord 挂载,老会话的历史内容里可能还有这种块,删了那些卡片列表就渲染不出来 |
删除的代码都在 git 历史里(
git log --diff-filter=D --name-only可查)。 上面「保留」那条不是遗漏 —— 它虽对新协议无效,但对旧历史仍然有效。
# 1. 列出所有网络调用点
grep -rn "fetch(\|new WebSocket\|new EventSource\|axios" src/ index.html \
--include=*.ts --include=*.vue --include=*.js --include=*.html
# 2. 对每个点反查调用方(以 card/index.js 为例)
grep -rn "getMediaList\|giveFeedback\|appendHistory\|network/api/card" src/ \
--include=*.ts --include=*.vue --include=*.js | grep -v "^src/network/api/card/index.js"
判据:出现在第 1 步 ≠ 还在用。必须做第 2 步——没有调用方的就是死代码。
第二节每条的「触发条件」也是这么查的(例如第 5 条要看 fetchPolicyList 前面两档 return
才能判断它几乎走不到)。