Skip to content

小助手 / LLM 接入约定

模型通道

  • 2026-08-13 起:对话与需求质检统一经业务中台(MUSE AV / museav.top)的 /api/chat 代理, 本后台不再持有任何 LLM key。鉴权用 STUDIO_TENANT_KEY(好易美的企业身份)。
  • 好处:LLM key 只在中台一份(换 key/换模型这边零改动)、模型口径中台统一下发、 每笔消耗按企业记到中台账本,好易美的 LLM 花费能和出图花费在一处对齐。
  • 模型:不在本后台指定,中台按自己的默认给(当前是 deepseek-v4-flash)。 想显式指定可传 deepseek-v4-pro;可用模型清单由中台 GET /api/chat 下发。
  • 旧口径(已废弃,别再照这个答):直连「需求审核中转」yuki-relay key + api.yuk15n0w.asia。 API Key 管理里那把 yuki-relay key 现在只剩余额巡检在用,不再是小美的通道。
  • 两者均为 reasoning 模型:思维链计入 completion tokens——max_tokens 建议 ≥3000;单次约 20 秒,调用端超时设 60 秒;支持 response_format: json_object(正文在 content,思维链在 reasoning_content,不要把 reasoning 当正文解析)。

知识库注入方式(防上下文爆炸)

本知识库 docs/kb/ 采用分层注入,协议详见 00-index.md。system prompt 组装顺序:

  1. 人设层persona-xiaomei.md 原文(小美的性格/语气/边界,常驻)。
  2. 用户画像:当前用户昵称/角色/业务组/决策分(运行时拼装)。
  3. L0 索引00-index.md(目录索引,<1k tokens,常驻)。
  4. L1 分篇:按用户问题匹配索引表 keywords,注入命中的 1-3 篇正文(单轮 ≤4k tokens)。
  5. 无命中时基于索引行回答并提示可追问,禁止全量注入所有分篇。

小助手架构设计(待实现)

用户身份关联与记忆

  • 小助手落地为 Pages Function(如 /api/assistant),不设白名单——走现有 _middleware.js JWT 鉴权,data.user 即当前对话用户(username/nickname/role/permissions),天然知道「你是谁」,无需额外登录。
  • 每轮对话把用户画像注入 system prompt:昵称、角色、业务组、决策分(从 admin_users 查)。
  • 按用户记忆:新表 assistant_memories(username, content, created_at) 存长期偏好/事实(模型判断值得记的写入);会话历史存 assistant_sessions / assistant_messages(按 username 隔离,只能看自己的)。

接口调用权限(查数据工具)

  • 给模型一组只读工具白名单,服务端执行时按调用者角色过滤(复用平台权限语义,操作员查不到管理员数据):
    • query_feedbacks:查需求池(状态/提出人/关键词)
    • my_decision_score:查自己的决策分与流水
    • usage_stats:功能使用频次(menu_usage 聚合)
    • my_generation_records:出图记录
    • api_key_balances:仅 admin 角色可调
  • 写操作原则上不开(改数据仍走页面),避免越权与误操作;放开需逐个评审。
    • 已评审通过的唯一例外:帮用户提需求。但小美自己不写库——它只疏导 + 吐一个 requirement-draft 草稿块,前端渲染成可改卡片,用户点「提交」才落库。 写的动作仍在用户手上,见 functions/api/_requirement-draft.js
  • 工具调用协议:deepseek-v4 系列的原生 function calling 未实测——先用已验证的 JSON mode 两段式兜底:第一段模型输出 {"action":"query_feedbacks","params":{...}},服务端执行后把结果拼进第二段生成回答;实测原生 tools 可用再切换。

前端渲染与流式(对话窗口)

  • Markdown 渲染必须做:模型输出天然带列表/粗体/代码块,纯文本直出必乱。方案:marked(轻量)+ DOMPurify 消毒后 v-html 渲染——模型输出会引用用户数据,不消毒就渲染等于开 XSS 口子
  • 人设提示词同时约束输出习惯:优先短段落和短列表,少用表格和多级标题,代码块只用于 key/路径类内容,保证窗口整洁。
  • 流式响应要做:deepseek-v4 是 reasoning 模型,首 token 前有 10-20s 思考期,非流式 = 用户盯 20 秒空窗。设计:
    • 链路:中转站 SSE(stream:true)→ Pages Function 透传 ReadableStream → 前端 fetch 逐块消费。
    • reasoning 阶段:SSE 先吐 reasoning_content 增量——前端显示为「小美思考中…」灰字(或仅做状态指示,不渲染全文),content 增量才是正文,逐字渲染。
    • markdown 增量渲染做节流(~100ms 重渲一次),避免每 token 重排。
    • 工具调用轮(JSON 两段式的第一段)不流式,只对最终回答段流式。

维护约定

  • 功能变更时:改对应分篇正文 + 同步 00-index.md 的摘要/keywords 行 + 更新分篇头部 updated 日期。
  • 新增模块:新建 NN-<id>.md(头部带 <!-- id | updated --> 注释)并在索引表加一行。
  • 旧的单文件 docs/system-guide.md 已废弃为指针,不要再往里写内容。

好易美(HYM)· 票务业务与后台知识库