Imported from hansqing9-collab/workbuddy-skill-external-research (
SKILL.md). Install upstream withnpx skills add hansqing9-collab/workbuddy-skill-external-research. Copyright stays with the author.
外部调研（先找轮子 · 再找参照系）
内核只有一句：任何「从零做」的决定，必须先证明外部确实没有现成的。 没搜过就说「没有」，是这套流程唯一要防的错误。
0. 两个入口，同一内核
| 入口 | 什么时候用 | 产出 | 读哪节 |
|---|---|---|---|
| A · 动手前先找轮子 | 用户说「我想做一个 X」、准备写代码/搭工具之前 | 一张方案对比表 + 一个明确结论（复用/二开/借鉴/自研） | §1–§6 |
| B · 卡住时破局调研 | 持续微调（调参/补词/改阈值）但指标不动；路线存疑，要外部验证 | 逐环节诊断表 + 不合理点分级 + 破局对策 | §7–§9 |
A 防的是「重复造轮子」，B 防的是「在错误姿势上磨到死」。 两者是同一件事：先用外部信息定位自己，再决定动手。 🔗 配套：一手源怎么取证（一手源优先级 / 一手二手区分 / 未验证项单列）见
research-verify-reportskill。
第一部分 · A 入口：动手前先找轮子
1. 什么时候必须跑
- 用户说「我想做一个 X」
- 「有没有现成的 / 有没有开源的 / 有没有人做过」
- 准备写代码、做产品、搭工具之前
- 用户描述了一个需求，但没说清要不要自研
2. 六个源，一个都不能少
| # | 源 | 找什么 | 去哪搜 |
|---|---|---|---|
| 1 | 包仓库 | 能直接装的库 | npm / PyPI / crates.io / Maven / Go |
| 2 | 代码托管 | 完整项目、可参考的实现 | GitHub Topics、awesome <topic>、Gitee |
| 3 | 产品市场 | 已商业化的成品 | Product Hunt、AlternativeTo、Futurepedia |
| 4 | 教程文章 | 别人踩过的坑、现成代码片段 | 官方文档、CSDN、掘金、知乎、Medium |
| 5 | 社区 | 真实评价、翻车记录 | Reddit、Hacker News、V2EX、少数派 |
| 6 | 技能/插件市场 | 现成能力，连代码都不用写 | WorkBuddy 推荐市场、SkillHub、ClawHub |
只搜一个源就下结论 ＝ 没搜。
3. 搜索词技巧（决定成败）
- 中英文各搜一遍。 英文覆盖率通常高一个量级。
awesome <topic>—— GitHub 上的清单仓库，最快的入口。alternative to <已知产品>—— 直接找到竞品矩阵。<需求> open source/<需求> github- GitHub 高级搜索：按 star 排序、限定语言、限定最近更新时间
- 搜不到就换词：换同义词、换英文、换更上位的概念
4. 评估六维（别只看 star）
| 维度 | 看什么 | 红线 |
|---|---|---|
| 成熟度 | star 数、release 次数、版本号 | 0.x 版本慎用 |
| 活跃度 | 最后一次 commit、issue 响应速度 | 一年没更新 ＝ 死项目 |
| 许可证 | MIT / Apache / GPL / 商业限制 | GPL 商用要警惕；无许可证 ＝ 不能用 |
| 适配度 | 技术栈、平台、语言是否对得上 | 平台不支持直接排除 |
| 依赖负担 | 依赖数量、体积 | 为小需求引入巨量依赖不值 |
| 文档与社区 | README 质量、有没有人答疑 | 只有代码没文档 ＝ 高成本 |
最容易被忽略、也最致命的是「活跃度」：一个 5 万 star 但两年没更新的项目，实际风险远高于一个 500 star 但每周都在提交的项目。
4.1 适配度要双向看：外部对得上 ≠ 集成得进去
§4 的「适配度」只量了外部（技术栈/平台/语言）。还必须读自己的代码，量集成成本 —— 否则会把「外面积木对得上」误判成「能直接装」。 动手前至少核这几项（读代码，不靠回忆）：
| 核什么 | 为什么致命 |
|---|---|
| 目标功能的入口挂在哪 | 已有回调/信号模式 → 接线几乎零成本；没有 → 要改造宿主 |
| 宿主生命周期约束 | 例：弹窗 12 秒自动关且无悬停暂停 → 用户根本点不到按钮。这类约束常是真正的难点，比倒计时本身难 |
| 已有 UI 与新 UI 的空间/语义冲突 | 托盘菜单已 7 项接近上限；整窗拖动 vs 按钮点击 |
| 状态持久化与恢复语义 | 宿主重启后新功能是丢还是续？ |
| 主题/多语言/无障碍是否要跟随 | 写死颜色会在多主题下翻车 |
判据：如果「难点」全在外部技术栈上 → 说明还没读自己的代码。成熟项目里，难点几乎总在宿主耦合处，不在新功能本身。
5. 四种结论（只能选一个）
| 结论 | 什么情况下 | 必须写清 |
|---|---|---|
| ① 直接用 | 成熟、适配、许可证没问题 | 用哪个、为什么不用自己写 |
| ② 二次开发 | 主体对，只缺你要的那块 | 改动量 + 上游同步成本 |
| ③ 借鉴思路自研 | 都不适配，但别人的架构有启发 | 抄设计，不抄代码 |
| ④ 从零自研 | 确实没有 | 搜了哪些源、为什么都不行 |
| ⛔ 否决某方案 | 依赖复杂 / 许可证不明 / 与内网离线冲突 | 写清理由留档 |
决策的真正依据不是「能不能自己写」，而是「写完之后的维护成本」。 自研成本 ＝ 开发 + 长期维护 + 踩坑；复用成本 ＝ 集成 + 妥协。两边都算出来再比。
6. 输出要求 + 反面清单
输出：
- 一张对比表：方案 / 类型 / 活跃度 / 许可证 / 适配度 / 一句话点评
- 一个明确结论（§5 四种之一）+ 理由
- 不要罗列一堆链接就完事 —— 用户要的是判断，不是搜索结果
反面清单（踩中任一条＝这次没做）：
- 只搜一个源 / 只搜中文
- 看到 star 高就推荐，不看最后更新时间
- 忽略许可证（尤其商用场景）
- 把「能用」说成「好用」
- 搜完不表态，把选择权推回给用户
- 明明有现成的，还顺着用户「我想自己做」往下走 —— 该拦就拦
第二部分 · B 入口：卡住时破局调研
7. 何时用 + 红线
何时用
- 系统持续微调（调参/补词/改阈值）但指标不见突破 —— 大概率撞上了「信息上限」，不是参数问题。
- 技术路线存疑，需要「行业/开源/学术是否有先例」来验证方向对不对。
- 用户要求「穷尽所有方法」「找开源案例」「发现不合理的地方」「对标行业做法」。
- 核心信号：用户在「磨」而不是在「换」 —— 磨参数 ＝ 死胡同信号，需要外部参照系来换姿势。
红线（务必先读）
- 外部数字仅作对标引用（政务侧/海关/海事公开 KPI 一律标注「非你的作品实测」），严禁改写为你的作品指标 —— 这是认知缴械高危区。
- 信息上限 ≠ 参数问题：若某通道命中率撞天花板（如单文本 45%），继续调参无用；破局 ＝ 加独立信息源/换任务定义/引真值标签，不是磨规则。
- 检索到的开源库要实测验证再采用（版本/许可证/依赖），不凭名字下结论 —— 直接复用 §4 评估六维。
- 输出文档标注每条外部素材的来源与日期，不编造出处。
8. 五步流程
8.1 全链路拆解（把系统拆到最细）
把目标系统按「通道 → 环节/信号」拆成最小单元，逐点记录现状：
- 例：风险评分引擎可拆成「输入标准化 / 分词词边界 / 家族匹配 / 别名伪装词 / 编码叠加 / 降权封顶 / 聚合分级」+ 若干异常信号 + 整体（评估/融合/分级）。
- 每个环节标注：做什么 / 技术支撑 / 预期效果 / 上限或已知缺陷（从回测报告、审计报告里挖，不靠回忆）。
8.2 分组穷尽外部调研（四维检索）
对每个环节/信号做检索，四维覆盖（每维至少 1 轮搜索，中英文词都要）：
| 维度 | 检索方向 | 找什么 |
|---|---|---|
| ① 官方同构实证 | 本领域官方/政务系统公开案例 | 「有没有官方系统在做同样的事？」（最强背书） |
| ② 开源工具 | record linkage / fuzzy matching / entity resolution / anomaly detection | 「有没有现成开源库可直接用？」（Splink/RapidFuzz/Dedupe/OpenRefine…） |
| ③ 学术方法 | 对应领域的论文/基准（如 RAG 冲突检测、D-S 证据理论） | 「学术界怎么定义和解决这个问题？」（冲突类型学/融合理论/无标签评估） |
| ④ 跨行业借鉴 | 反欺诈/反洗钱/航旅风控/银行供应链 | 「别的行业解决过类似难题吗？」（常是解题钥匙） |
检索词模板（可直接改）
- 中文官方：
集装箱 危险品 申报品名 不一致 订舱 舱单 报关 比对 系统、海关 报关单 舱单 品名 不一致 核查 布控 算法 - 开源：
record linkage entity resolution Python open source splink dedupe、risk score fusion Dempster-Shafer evidence theory - 无标签评估：
无标签数据 误报率 校准 主动学习 异常检测 评估、synthetic AUC unsupervised anomaly detection evaluation - 学术：
LLM inconsistency detection cross document contradiction multi-source conflict、chemical NER dictionary rule hybrid - 跨行业：
booking amendment anomaly detection last minute change risk fraud
8.3 逐环节诊断（每点三行）
- ✅ 合理（有官方同构或行业惯例佐证）→ 记入「弹药」
- ⚠️ 偏差（方向对但做法偏了，有官方更优做法）→ 记入「不合理点」，写换姿势对策
- ❌ 不合理/无用功 → 记入「不合理点」，建议砍掉或重构
判定技巧：当找到官方同构（如港口 VGM 差值信号 vs 自有密度阈值）时，官方做法往往更直接可解释 —— 优先学官方，而不是坚持自己绕路的做法。
8.4 不合理点分级（认知级 > 参数级 > 工程级）
| 级别 | 定义 | 对策方向 |
|---|---|---|
| 认知级（最高） | 方向/姿势错了（例：单文本该走语义识别却只做枚举回灌；该做 VGM 差值却做密度阈值） | 换姿势 —— 这是死胡同的真正来源 |
| 参数级 | 阈值/权重人工拍定、未用数据校准 | 用已有负样本/历史数据做扫参校准（P-R 曲线选业务平衡点） |
| 工程级 | 缺词法规则层/缺规格剥离等局部缺口 | 低成本补丁 |
8.5 输出文档（落盘）
[项目]/06_工作文档/[项目]-[主题]-外部调研诊断-YYYYMMDD.md，结构：
- 总体判断：架构方向是否站得住（列出官方同构实证清单）
- 逐环节诊断表：环节 / 现状 / 外部做法 / 判定 / 对策
- 不合理点汇总（按认知级/参数级/工程级 + 优先级排序）
- 新增弹药（可引用素材，每条标来源）
- 行动清单（按收益/成本排：P0/P1/P2）
- 一句话总结
9. 关键认知（B 入口的魂）
- 「磨规则」撞的是信息上限，破局靠「换数据/换姿势」 —— 先判断是上限还是参数，再决定花不花力气。判错了可能白干两周。
- 官方同构实证 ＝ 最强背书：你的每个信号几乎都能找到官方系统在做同样的事，这既证明方向对，又是弹药。
- 跨行业借鉴常是解题钥匙：反欺诈/航旅风控的「临近窗口高频变更＝风险」等通用规律，可直接迁移到本行业场景。
- 无标签困境有标准解法：合成异常回灌测试（把已知正样本注入大样本测能否捞出）＝ 闭卷代理指标，替代「无真值无法测召回」的尴尬。
- 开源库升级路线：单字段模糊匹配（RapidFuzz）→ 多字段概率链接（Splink，Fellegi-Sunter 模型）→ 冲突类型编码化（借鉴 FinBalance 23 类不一致代码）。
第三部分 · 共用部分
10. 本用户的优先级（别搞反）
现成工具 / 技能 / 产品能直接用 ＞ 有开源库可集成 ＞ 自己写代码
⚠️ 但理由不是「他不会写」 —— 他的定位是**「用现成大脑组装系统的人」（构建者，不是消费者）： 判断力用在选型、定标准、验收**上；能少写的代码就少写，把精力留给判断。 所以遇到他的需求，先问「有没有现成的软件/技能」，而不是「用哪个库」。
11. 三句不能被糊弄过去的话
- 凭印象说「这个没有现成的」→ 按 §2 六源跑一遍再说
- 只搜到一篇博客就下结论 → 那只证明「有人写过文章」，不证明「没有成品」
- 搜到星标低就排除 → 先看活跃度和许可证（§4）
附：案例参考（思路示例）
- 例：
<你的项目>/06_工作文档/<项目>-规则引擎外部调研诊断.md（某通道全点诊断，记录每环节现状/上限） - 例：
<你的项目>/06_工作文档/<项目>-单信号攻关方案.md（单信号深度方案） - 例：
<你的项目>/06_工作文档/<项目>-开源解法实证.md（搜到开源库后写的实证背书） - 关键实证思路：优先找官方同构（如港口 VGM 差值布控 / 智能选箱 / 舱单比对等公开做法）→ 学官方；再找开源库（如 Splink，英国司法部开源）直接复跑。把你的真实诊断文档路径替换上面占位即可。
v2.1（2026-09-20）：新增 §4.1「适配度要双向看」—— 评估集成成本必须读自己的代码，成熟项目里难点几乎总在宿主耦合处，不在新功能本身。
v2.0（2026-09-20）：由 external-research-breakthrough（卡住时破局调研）＋ 国际版 prior-art-scan（动手前先找轮子）合并而成，更名「外部调研」。