media-to-roadmap

/media-to-roadmap — 外部来源输入，去重后的路线图输出

只有一个目标：有人发布了关于 AI 编码、Agent 或开发者工作流的视频、播客、文章或帖子，而 Ane 想知道其中哪些内容值得采纳。输出是一份位于 agent-improvements/ 中的路线图文件，且已对照系统当前的实际功能完成检查。

存在的原因

这种模式至少已手动执行过六次：Karpathy/Forte 视频整理成了包含 14 项的登记表，Nate Herk/Cole Medin 播客整理成了包含 9 项的路线图，loops 视频（2026-06-21）整理成了监控循环构建计划，STORM 视频（2026-06-30）整理成了研究范围界定技能，而 Thariq 的上下文工程文章和 Isenberg 的图工程视频（2026-08-04）整理成了有序的采纳计划。流程始终相同；值得标准化的是关于不应实施什么的判断，因为来源总会夸大其词（STORM 所谓的“90 秒 = 48 个博士小时”就是典型案例）。

方法，按顺序执行

1. 获取来源 — 切勿凭记忆处理

路线图中的每项说法都必须追溯到已获取的内容。各类来源的获取方案（包括带 POT-token 后备方案的 YouTube 转录文本、文章、需要登录的 x.com 帖子串）见 references/fetch-patterns.md。通过 context-mode（ctx_fetch_and_index / ctx_execute）获取内容，避免原始转录文本留在对话中。如果无法获取来源，就停止并说明情况；不要根据训练数据还原内容。

2. 提取具体技术

列出来源实际提出的具体、可实施的说法，而不是主题。对每项说法，记录来源自身提供的证据，以及最有力的反对意见。经得起反对意见检验的说法可以进行分类；经不起检验的说法则直接列入不采纳清单，并以反对意见作为理由。

3. 清点现有内容

在对任何内容进行分类之前，先检查系统已经具备的功能。以下是各项检查面，按能最快得出答案的顺序排列：

1. 已安装的技能 — ~/.claude/skills/ 中的名称和描述。
2. Hooks — ~/.claude/settings.json。
3. 测试框架 — tests/run_tests.py 中的检查项名称。
4. 工作文件夹中的 scripts/ 和 ane_package/。
5. 常驻规则 — ~/.claude/CLAUDE.md 和项目的 CLAUDE.md。
6. 专用 Agent — agent-improvements/agent_registry.md。

如果某个想法已由系统实现，就将其作为验证结果记录在已在执行下，绝不重新提议为新工作。这一步去重正是该技能存在的全部意义；跳过它会导致待办列表出现重复条目，而待办清单测试正是为捕捉此问题而建立的。

4. 对每个经筛选保留的想法进行分类

每个想法都必须沿两个维度进行分类：

• 构建路线：复用 > 改进 > 重建。 优先扩展现有的 Hook、检查项、模块或技能，而非另建一套机制。明确指出要复用或改进的对象；若标记为“新建”，则必须说明为何现有内容都无法满足需求。
• 采纳环：采纳 / 试行 / 评估 / 暂缓（ThoughtWorks 雷达框架）：
  • 采纳 — 已证明契合度高、风险低，在指定的工作区块中实施。
  • 试行 — 前景可观；先在一个范围明确的工作流中试点，并在全系统使用前指定成功检查项。
  • 评估 — 值得了解；进行试验或列为观察项，不承诺构建。
  • 暂缓 — 目前不推进；必须说明理由，因为暂缓条目可避免下次扫描时重新争论同一问题。

5. 编写路线图

目标：agent-improvements/<slug>-YYYY-MM-DD.md，slug 取自来源。如果目标文件已存在，请遵循 mel_wiki/wiki/concepts/edit-preservation-protocol.md。必需章节按以下顺序排列：

1. 来源 — 内容/作者/出处/日期、使用的抓取方法、扫描日期。
2. 来源内容 — 提取出的主张，每条都附上证据和最有力的反对意见。
3. 已在实施 — 验证清单，每项都指出现有的应用场景。
4. 采纳 / 试行 / 评估 / 暂缓 — 分类后的想法，每项都写明实现路径和工作量估计。
5. 不要构建的内容 — 必填，并说明理由。此部分为空表示扫描失败，而不是所有内容都值得构建。
6. 警示信号 — 如果来源中的哪些情况之后出现在系统中，就表明这些建议已经过时。
7. 分阶段工作块 — 将采纳/试行的内容分组为可实施的工作时段，采用先规范、再清理的方式。

如有请求，还要在 agent-improvements/handoffs/ 中编写后续交接文档，让新的会话无需了解本次会话的上下文即可构建第 1 个工作块。

硬性规则

• 建议应针对其所面向的模型代际。 在前沿代际模型上演示的技术，并不自动适用于 Sonnet 级别的专用提示词；应说明来源使用了哪一代模型，以及该技术能否迁移。
• 未经两项检查，不得使用第三方编排平台。 IPPF 设备不允许管理员权限，SRHR 数据绝不能进入非企业级工具。任何需要安装或使用外部服务的想法，在离开“评估”阶段前，都必须通过无管理员权限检查和敏感数据检查。
• 认可前先剔除炒作。 每项认可都要明确指出最有力的反对意见（默认质疑）。如果复述来源自身的基准测试主张，却不提出该反对意见，即属于质量不合格。
• 系统相关数字必须计算，不可凭记忆填写。 路线图中提到的检查项、技能或钩子数量，必须在同一轮中计算得出，否则就替换为可生成该数字的命令。

相关但不重复

相邻项目	区别
video-content-analysis	通过转录 + 同意流程处理 MEL 研究视频文件（FGD、网络研讨会）；此技能读取已发布的外部内容
/system-audit、/grade-system	从系统内部进行检查；此技能摄取外部输入，并将发现的问题转交给系统处理
/improve-system	从内部 QA 日志和会话历史中挖掘信息；此技能是对应的外部信号渠道
evidence-synthesis	正式的学术 REA；此技能处理的是技术领域的灰色文献观察内容
linkedin-field-note	扫描结论可作为现场笔记的素材，但撰写文章属于该技能的职责