业务问卷（agent 问人）

侧栏顶部「业务问卷」，紧挨需求池。这是给你（agent）用的：遇到只有业务方 脑子里才有的事实，别自己猜、也别卡在对话里反复问 —— 开一张问卷，指名 1-2 个人来答。

和需求池的区别（别答混）

	方向	内容
需求池 /roadmap	人 → 系统	我要一个功能 / 这里有 bug
业务问卷 /business-questions	agent → 人	这个业务事实我不知道，你告诉我我才能继续

判断标准：答案是不是只有业务方知道。是 → 业务问卷；是对系统的意见 → 需求池。

怎么用（接口）

鉴权走 robot key（X-API-Key）或后台 JWT，二者之一即可。

舰队小美（小美 (xiaomei)）已经开了问卷权限：密钥 scope 含 questions（以及原来的 read/write）。 提问、列表、结题、催办都走 /api/business-questions，不要拿 table=hym_business_questions 去打 /api/agent-data——那边表白名单只有订单/提醒/投放，问卷会直接 400 并提示换接口。

被指名回答的人（含操作员）侧栏就能进「业务问卷」；非管理员只能看见指派给自己的题，看不到别人的。

# 提问：respondents 最多 2 人（再多就没人觉得该自己答）
POST /api/business-questions
{ "title": "开票日期这列为什么装的是店铺名？",
  "body": "迁移时发现 91 行如此，已整列置空。想确认：这列以后还要不要？要的话谁填？",
  "respondents": ["someone@example.com"],
  "urgency": "blocking",              // blocking = 我卡着等；normal = 可先按假设做
  "context_ref": "hym_orders.invoice_date" }

GET  /api/business-questions?status=answered   # 读回答
POST /api/business-questions { "action":"close", "question_id":1, "resolution":"..." }

三条规矩

1. resolution 必填才能结题。回答的人有权知道自己的话被怎么用了 —— 答完没下文， 下次就没人愿意答。结题时会给回答过的人写站内铃铛回告。
2. 不能代人回答：action:'answer' 只认后台 JWT 身份，robot key 提交会被 403。 agent 只能提问和结题，不能替人填答案。
3. 能自己查清的别问。库里有的、代码里写着的、文档里能查的，自己去看。 这张表是给「只存在于业务方脑子里」的事实用的，滥用会让人不再认真答。

状态

open 待回答 → answered 至少一人已答 → closed agent 已采纳并结题。 页面上「还没答：xxx」会直接列出指名了却没答的人，标 blocking 的显示红色「阻塞」标签。

飞书卡片发不出去时先查这个（2026-09-02 踩过）

提问会给被指名的人发飞书卡片（按钮直跳 /business-questions），返回体的 feishu 字段说明投递结果：sent / no_config(生产没配 FEISHU_APP_ID/SECRET) / no_open_id(这人没绑飞书) / failed:<飞书code>。

飞书 open_id 是「应用维度」的：同一个人在不同飞书应用里的 open_id 是不同的值， 但格式完全一样（ou_ + 35 位），肉眼分不出来。实测撞到过：一个账号 sent、 另一个账号 failed:http400，两人 open_id 形态一模一样 —— 根因是后者的 open_id 来自 hermes/小美那个飞书应用，不是 hym-admin 这个应用，飞书对不属于本应用的 receive_id 直接返回 HTTP 400。

修法：让本人用公司企业飞书扫码登录，或到「个人资料」点「绑定企业飞书」。 /api/feishu-callback 会校验本公司账号，再把本应用的 open_id 写进去。 个人飞书号和其他应用（hermes/小美）的 open_id 已清空，必须重绑。

催办用 POST {action:'renotify', question_id}，只重发给还没答的人。 注意它每次都会写一条站内铃铛，调试投递问题时别反复调（会给对方刷一串重复通知）。

附：cs 舰队 agent 怎么读写后台数据

2026-09-02 打通。注意别把两个「小美」搞混：

	是什么	在哪
后台 AI 助手小美	本后台的对话抽屉（AssistantChat.vue + /api/assistant），只读、无工具调用	浏览器里，顶栏「问小美」
cs 舰队 agent xiaomei	hermes agent，有飞书通道、能执行命令、有自己的记忆与职责	118.25.151.19（上海服务器）

前者的能力边界是「关键词路由 + 查几张表」；后者是真正能干活的 agent。 被问到「小美能不能帮我改数据」，先分清问的是哪个。

agent 侧接口：/api/agent-data

鉴权走 X-API-Key（robot_keys），按细粒度 scope 判定。xiaomei 的密钥存在 secret://hym-admin/agent-key-xiaomei，scope 为 tickets:read / tickets:write / questions / read / write。 问卷不走 agent-data，走 /api/business-questions（见上文）。

• 查订单：GET /api/agent-data?table=hym_orders&q=<场次关键词>&limit=20 （q 模糊匹配 keyword 与 order_info 两列；也支持 eq_<列>=值 精确筛选、order=order_date.desc）
• 加客户提醒：POST /api/agent-data，body { table, action:'insert', payload:{...} }
• 改数据：POST /api/agent-data，body { table, action:'update', id, payload:{...} }

边界（回答相关问题时要说清）

• 业务表：hym_orders / hym_customer_reminders + feedbacks（需求池）。 需求池只允许 update 已有单（认领/完工），不允许 agent 代提。
• 没有 delete：agent 误删无法回滚，删除必须人工在后台点。
• 碰不到账号体系：admin_users / robot_keys / frontend_accounts 一律不可达 —— agent 不走 admin-data（那是全表 CRUD，对 robot key 开放等于把整个后台交出去）。
• 写入会打标：agent 写的行 source='agent:小美 (xiaomei)'，库里能分清是人写的还是 agent 写的；每次写操作在 api_logs 留痕（有 robot_name 列）。

官网答题：一人一码（2026-09-15）

答题页从后台搬到了官网。被指名的人不需要后台账号，点开链接就能答 —— 真正知道答案的抢手部、货源部、代理，本来就没有后台账号。

链接长这样：https://hympro.cn/q?t=<32 位 token>。链接本身就是口令， 提问时给每个 respondent 各签一条，飞书卡片的按钮直接跳过去。

三条规矩

1. 一人一码，不是一题一码。 owner 定的「每人只能提交一次」要求认得出人； 一题一码的链接可以转发、也分不清谁答的，只能按浏览器限一次，换设备就破。
2. 提交一次就锁。 后端在 token 上占锁（answered_at），二次提交返回 409， 页面转成「已提交」并回显原文。要改答案只能找提问的人。
3. 正文写纯文本。 **重点** 这种 markdown 页面只认成对的 **（会渲染成粗体）， 其余语法一律原样显示。别在题面里写列表符号、链接语法、代码块。

怎么把链接交到人手上

• 默认路径：飞书卡片的按钮。对方绑了本应用的企业飞书就能直接点。
• 兜底路径：后台「业务问卷」卡片上点**「取答题链接」**，列出每人的链接 + 谁已答， 一键复制，贴微信/企微都行。飞书发不出去（没绑定、或绑的是别的飞书应用）时走这条。
• agent 侧：POST {action:'issue-links', question_id}，幂等（已签发的不重签）， 还能顺带追加没有后台账号的被指名人：{action:'issue-links', question_id, respondents:['肖智']}。 respondent 会原样落进 hym_business_answers.username，所以结果页直接显示是谁答的。

后台还剩什么

结果查看仍在后台（/business-questions），登录后台的人照旧可以直接在页面上回答 —— 那条路走 JWT 身份、改答案算覆盖，和一人一码这条互不影响。