nomi-intake-radar

Nomi 用户反馈雷达

目标：把「用户点了反馈按钮 / 匿名用量事件」变成「今天最该改的 1-2 件事」。抓取和算数字是脚本的活（scripts/intake-radar.mjs + scripts/lib/intake-radar/），这份技能只做判断——分诊、归因、写待办、汇报。这个分工和 feedback-radar.mjs（GitHub/B站/微信反馈）、model-radar.ts（供应商模型雷达）是同一条线：脚本确定性、不花额度；技能才调 LLM 判断。

入口

1. 跑 pnpm run intake:radar（如果本轮会话开始时的「每日雷达」步骤已经跑过，直接读它的输出，不用重跑）。
   • 失败会红着退出，终端明说「今天没查成」——这种情况不要把它读成「今天没有新反馈」，如实告诉用户抓取失败以及失败原因，不要往下分诊（没有新数据可分诊）。
2. 报告在仓库外的缓存目录：默认 %LOCALAPPDATA%\nomi-intake\reports\<UTC 时间>.md（每轮一份，同一天多跑不会互相覆盖；同名 .json 是给这份技能读的结构化版本），可能被 NOMI_INTAKE_CACHE 改过位置——脚本终端输出的最后几行会打印这一轮报告的实际路径，认那个，不要假设默认路径。
3. 读 .json 报告里的 triage.items（这次要分诊的就是它：还没记进待办的全部反馈，不只是这一轮新到的）、newFeedback（这一轮新到的）、delivery（送达：直达率、重复送达）、logTail（反馈包带没带上日志）、generationResults（成功/失败/取消分布，默认已排除自动化事件，被排除的条数在 excludedAutomated）、failureReasons（失败按原因排行，原因是分类码）、errorCodeRanking、spikes（突增）、launches/updateActions。这些数字都已经算好，不要重新数一遍，也不要在没重新验证的前提下怀疑脚本的算术。

先判断数据可不可信，再下结论

看到成功率、错误码分布、突增这类数字异常时，第一反应不是「这是个 bug」，而是「这个数字覆盖的是不是它看起来该覆盖的那个总体」。上报链路本身有缺口时，数字会系统性失真，而不是随机噪音——先查缺口，缺口没排除之前任何百分比结论都要加限定语。

已知的两个缺口（2026-09-29 查实，写进这里是为了不用每次都重新排查一遍；如果之后有人把它们接上了，删掉对应这条，别留着误导）：

• generation.completed 目前只覆盖「画布直生成」：唯一的上报点是 src/workbench/api/taskApi.ts 的 runWorkbenchTaskByVendor（渲染层，画布节点执行器 catalogTaskActions.ts 调它）。「制作流程」（ProductionRun，electron/productionRun/，多镜头批量调度）和「Agent 付费卡」触发的生成（electron/capabilityCore/mcpStdioServer.ts、appIntegration.ts 调 createProductionGenerationSubmission）整条链路里没有任何 telemetry 调用——不是成功事件漏报而失败事件正常报，是这两条路径的生成完全不出现在 generation.completed 里，无论成败。所以任何从这份数据算出来的生成成功率，只代表画布直生成这一条路径，不能说成"Nomi 的生成成功率"。看到这类数字要在汇报里加一句「样本只覆盖画布直生成，制作流程/Agent 生成不在里面」。这本身也是要挂私有待办的一条（数据上报问题，不是产品 bug），可以引用 electron/telemetry/telemetryOutbox.ts 的 recordTelemetryEvent——它是渲染层 IPC 和主进程都能直接调的唯一出口，ProductionRun 要补报点时不用建新链路，在它判定终态的地方直接调这个函数即可（接线本身不在这份技能的职责里，只在待办里写清楚"接到哪"）。
• 独立的 Agent 轨迹上报 2026-11-13 删了（客户端队列、接收端路由、雷达前缀一起删；从没有发布版本发过）。轨迹只作为一键反馈包里的附件到达（projectLaneTrajectory，用户手动提交时附最近 3 个回合的白名单投影）。报告里不再有「轨迹条数」。
• 定位读数（报告「定位读数」一节）：按补丁版的失败率、失败里上游 unknown / 本机规则 uncoded 的占比、上次没正常结束的启动占比、主进程停顿分布。只有 2026-11-13 之后的版本带这些格；老版本事件记成 x.y.? 或「不带细节」。unknown / uncoded 占比高 = 码还没覆盖到，分诊时记成「补码」类待办，不要去猜具体原因。

对生成结果按能力/版本/系统/日期看的时候同理：事件的 systemProps 只有 appMajor.appMinor，没有补丁号——报告里出现的"版本"是"0.22"这个粒度，不是完整版本号，不要在汇报里假装精确到补丁版本。

归类

每条新反馈归到四类之一，写进私有待办前先定这个类：

1. 真 bug——Nomi 自己的代码/设计导致用户做不成事，且可复现、可定位到具体模块。
2. 配置问题——用户自建/中转渠道、模型 id、参数等配置错误，Nomi 按预期拒绝或报错；但如果报错文案让用户摸不清"该怎么改"，这本身是体验问题，两类可以同时成立。
3. 体验问题——功能能用，但流程绕、提示不清楚、需要用户多想一步；包括"设计出来的保护性拦截"（比如为避免白扣费主动拒绝某个操作）用户仍然觉得困惑的情况——护栏本身没错，但用户体验到的是一次"卡住"，值得记。
4. 数据上报本身有问题——现象不是产品行为异常，是遥测/反馈链路本身漏报、误报、口径不一致（比如上面两个已知缺口这一类）。

一条反馈可以同时挂多个类（比如"真 bug + 体验问题"），不必只选一个。

归因到底层设计问题

不要满足于"这条反馈对应哪一行代码"。先查这个现象是不是已经被结构性归过因——读 docs/audit/2026-09-29-hot-modules-structure-review.md（四个热模块为什么扎堆）和它引用的 #897 结构簇（两台生成发动机 / 同一件事多处判断 / 跨边界约定没有共用定义 / 投影层自己下结论 / 失败不出声）。如果一条新反馈明显是这几类的又一个实例（尤其"画布直生成 vs ProductionRun 两台发动机"这条线——目前看到的很多生成类反馈最终都会落在这上面），在私有待办里点出它属于哪一簇，不要当成孤立新 bug 重新归因一遍；同一层 7 天内第三份根因合同要先出结构评审（R21），挂待办时可以提前标出"这可能是第 N 份"，帮后面派工的人少走一遍这个判断。

挂私有待办

• 私有待办是唯一真相源，这份技能只知道它叫"私有待办"，不在这份公开仓库的文件里写它的具体位置——运行这份技能的会话应该已经知道去哪读写它。
• 先搜私有待办里有没有已经登记的相关条目（按模块/症状关键词搜，不是按这条反馈的编号搜——同一个底层问题可能已经被换了个说法登记过）。有就把这条反馈的编号（NF-MMDD-NNNN）追加挂上去当新证据，不重复开条；没有就新记一条。
• 记完就出账：pnpm run intake:radar -- --triaged <编号…> --todo <待办号或说明>。不出账的话这一条每次开会话都还在「待分诊」里，这是有意的：看过不算处理过，只有记进待办才算。只是噪音不用记待办的也要出账，--todo 写明理由（比如「测试反馈，不用记」）。升级后第一次跑时缓存里已有的反馈会全部进账，对过账之后用 --triaged-through <日期> --todo <说明> 一次出完。
• 写进待办的只能是归纳后的问题描述：模块、现象、影响范围、属于哪个结构簇（如果查得到）。不许把用户反馈的原文摘要、留言原文、或反馈自带的附件内容（比如那份很大的 model-catalog.json 诊断快照）整段搬进待办——那些是本机缓存里的诊断数据，不是要长期保存的产品文档。要引用就用自己的话转述"用户反馈说 X 场景下 Y 不工作"，不逐字复制。

汇报给用户

大白话，今天最该动的 1-2 件事，不是把整份报告念一遍。格式：

• 这件事是什么（一句话，说人话不说术语）
• 为什么值得今天动它（新出现的 / 影响面大的 / 突增的 / 卡住付费路径的，优先级从这几条里选）
• 建议怎么处理（继续走正常修复流程 / 需要用户拍板 / 只是记录观察，不用现在动）

如果待分诊是 0、也没有突增，如实说"今天没有新东西"，不要为了有话说而重复讲已经报过的旧发现。「新增 0 条」不等于没事：待分诊不为 0 就还有反馈没人管。

隐私

原始反馈/事件只留在本机缓存目录（脚本已经保证不进仓库、不进任何提交）。这份技能自己的输出——包括私有待办里新增的条目——只能是归纳后的问题描述，不贴用户反馈原文、不贴附件内容、不贴账号 id、不贴任何价格/成本数字。跟"论文雷达""模型雷达"一样，这份技能的判断额度默认已授权，不用为了跑一次分诊再单独问用户。