项目地址：https://github.com/AdvancingTitans/hotspot-research-skill/

过去几年，我们已经习惯了把很多东西工程化。

基础设施可以写成代码，文档可以写成代码，配置可以写成代码，工作流也可以写成代码。

但有一类东西，长期以来始终停留在人的经验里。

那就是研究过程。

如何理解一个热点？如何判断一个新技术是否值得关注？如何从海量信息中识别真正有价值的信号？这些能力往往来自长期积累，但很少被清晰记录，更难被复用。

这也是我开发 hotspot-research-skill 时真正想解决的问题。

它表面上是一个热点研究 Skill，但我越来越觉得，它更像一次实验：

研究过程本身，能不能像代码一样被组织、维护和持续演化？

⸻

信息已经不稀缺，稀缺的是判断过程

现在获取信息已经变得非常容易。

一个新产品发布，一个开源项目爆火，一个行业概念突然流行，我们很快就能让 AI 搜索、总结、归纳，然后生成一份看起来完整的报告。

但问题也出在这里。

报告越来越容易生成，判断却未必越来越可靠。

很多时候，我们保留下来的只是结论。

这个项目值得关注。

这个趋势可能会爆发。

这个方向短期被高估，但长期仍有价值。

但过一段时间再回头看，最关键的东西往往丢了：

当时为什么这样判断？

依据是什么？

哪些信息源可信？

哪些观点存在争议？

哪些结论只是推测？

真正容易消失的，不是答案，而是答案背后的研究路径。

⸻

我最初并不是想做一个自动摘要工具

hotspot-research-skill 最容易被理解成一个热点摘要工具。

但摘要并不是它真正想解决的问题。

如果只是摘要，普通联网搜索已经能做得不错。

真正的问题在于，热点研究天然伴随着大量噪声。

越新的东西，信息越不稳定。

越热的话题，观点越容易走向极端。

越早期的趋势，也越容易被叙事包装。

所以这个 Skill 的目标，并不是让 AI 更快生成报告，而是让 AI 不要太快形成结论。

它会要求研究过程先经过一系列前置步骤：

定义研究对象；

确认话题是否具备研究价值；

收集公开信息；

评估信源质量；

识别共识与分歧；

最后再进入写作阶段。

这看起来有些慢。

但研究里最危险的事情，从来不是没有结论，而是太早拥有结论。

⸻

Research as Code：把研究习惯显式化

如果用一句话概括这个 Skill 的设计思想，我会说：

把研究习惯显式化。

以前，研究方法存在于脑子里。

现在，它可以被写进 Skill。

什么样的话题值得展开研究；

什么情况下应该继续补充资料；

什么样的信息源可以支撑判断；

竞争格局应该分析到什么程度；

哪些地方必须保留不确定性。

这些问题看起来不像代码问题。

但一旦写进 Skill，它们就开始具备代码的特征。

可以复用。

可以调试。

可以重构。

可以版本管理。

甚至可以被不同的 Agent 执行。

这也是我理解的 Research as Code。

它不是把研究变成机械流程，而是把原本隐性的研究经验，转化成可执行、可维护、可迭代的规则系统。

⸻

一个好的 Skill，不应该只告诉模型写什么

很多 Prompt 的问题在于，它只描述结果。

「帮我写一份热点研究报告。」

「帮我分析这个行业趋势。」

「帮我总结这个开源项目。」

这些指令能得到答案，但很难保证过程稳定。

而 Skill 应该做得更深一些。

它不只是告诉模型最后要输出什么，还应该告诉模型：

在输出之前，应该如何判断、如何取舍、如何验证、如何组织证据。

hotspot-research-skill 的价值就在这里。

它把热点研究拆成了一个相对稳定的流程。

从话题发现，到信号确认；

从资料收集，到结构化分析；

从竞争格局，到关键洞察；

最后再进入长文报告和最终输出。

这让 AI 不再只是“写得像研究报告”，而是更接近“按照研究流程工作”。

⸻

这个 Skill 真正沉淀的，不是报告，而是持续演化的知识

随着使用次数越来越多，我逐渐意识到，hotspot-research-skill 最有价值的部分，并不是最终生成的那份研究报告。

报告只是结果。

真正重要的是，在研究过程中积累下来的那些结构化信息。

一个话题为什么值得研究；

它的起源是什么；

有哪些关键参与者；

目前形成了哪些共识；

存在哪些争议；

哪些判断已经得到验证；

哪些观点仍然需要持续观察。

这些东西如果只是停留在一次对话里，很快就会消失。

但如果能够被持续保存和组织，它们就会慢慢从一次性的输出，变成可以反复利用的知识资产。

过去很长一段时间，我也尝试过各种知识管理方式。

收藏夹、Notion、备忘录、Readwise……

但慢慢发现，它们更多是在保存内容。

而研究真正需要保存的，其实是过程。

所以后来，我逐渐形成了一套更加简单的方式。

研究完成之后，生成的 Markdown 文件会进入 Obsidian，通过 iCloud 在 Mac、iPhone 和 iPad 之间自动同步。

于是，研究不再停留在某一次 AI 对话里，而是进入自己的长期知识库。

这种感觉很像软件开发。

代码会进入 Git 仓库。

文档会进入 Docs。

而研究，也应该进入自己的 Repository。

以前做研究，更像一次性的消费行为。

看到热点。

获取信息。

形成结论。

然后结束。

几周以后，当新的信息出现，又重新开始。

很多认知，其实一直在重复建设。

但现在，这种方式正在发生变化。

今天研究 Agent。

下个月研究 MCP。

再过几个月研究 AI Coding。

它们看起来是不同的话题，但实际上彼此之间存在大量关联。

过去的研究结果，会成为未来研究的上下文。

新的信息，会不断修正旧的判断。

而旧的判断，也会帮助理解新的趋势。

于是，研究开始拥有连续性。

我越来越觉得，一个真正有价值的知识库，不应该只是内容仓库。

它更像一个持续演化的系统。

里面保存的，不只是最终答案。

还有形成答案的依据。

为什么当时会这样判断。

哪些观点后来被证伪。

哪些信号最终演化成了趋势。

哪些想法只是阶段性的误判。

这些东西，远比结论本身更加珍贵。

因为答案会过时。

热点会消失。

模型会更新。

但研究过程中积累下来的思考路径，却会不断沉淀下来。

也是在这个过程中，我开始越来越理解 Research as Code 的意义。

代码最大的价值，不是某一个版本。

而是它可以持续维护、不断迭代。

研究其实也应该如此。

一份研究报告，不应该是终点。

而应该像一次 Commit。

新的信息出现之后，可以继续补充。

新的案例出现之后，可以继续修正。

新的观点出现之后，可以继续重构。

于是，知识开始拥有版本。

认知开始拥有历史。

研究，也第一次真正具备了持续演化的能力。

所以现在，如果让我重新定义 hotspot-research-skill。

我不会把它理解成一个热点研究工具。

甚至不会把它理解成一个报告生成器。

对我来说，它更像是整个研究系统中的一个入口。

负责发现问题。

负责组织研究。

负责生成结构化结果。

而真正的沉淀，则发生在后面的知识库里。

从这个角度来看，Research as Code 并不意味着把研究变成代码。

它更像是在借鉴软件工程的思想：

让研究过程能够被保存、被维护、被修正，并随着时间不断演化。

而这，可能比生成一份更长的报告更加重要。

⸻

Skill 开发其实还有一个更难的问题

站在开发者角度，我认为 hotspot-research-skill 还有一个非常值得继续探索的方向：

如何让研究流程既稳定，又不过度僵硬。

流程太松，模型容易漂移。

流程太死，输出又会变成模板填空。

这中间的平衡非常微妙。

一个好的研究 Skill，应该有明确的骨架，但不能抹掉具体问题之间的差异。

研究 AI 产品、研究消费品牌、研究开源框架、研究宏观趋势，它们使用的资料类型、判断标准和分析方式都不一样。

所以未来更值得做的，并不是继续增加更多模板。

而是让 Skill 拥有更强的研究场景识别能力。

先判断自己面对的是什么问题，再选择合适的研究路径。

这会比单纯增加输出字数更有价值。

⸻

Research as Code 可能会改变知识管理

过去的知识管理，核心是保存内容。

收藏文章。

摘录笔记。

建立标签。

整理知识库。

但 AI 出现之后，内容本身正在变得越来越容易生成。

未来真正值得保存的，可能不只是内容，而是产生内容的方法。

知识库不应该只保存「我知道什么」。

还应该保存：

「我是如何知道的」。

这也是 Research as Code 对我最大的启发。

当研究过程被写成 Skill，知识管理就不再只是存放结果，而开始保存方法。

一个人长期积累下来的判断框架、信息筛选习惯、分析路径，都可以被显式记录，并被 Agent 重复执行。

这件事的意义，也许比单个 Skill 更大。

因为它意味着，我们不仅可以复用知识，还可以复用形成知识的过程。

⸻

最后

如果只把 hotspot-research-skill 理解成一个热点研究工具，我觉得有些可惜。

它更值得被理解成一次方法论实验。

当 AI 开始参与研究，我们能不能把研究过程本身变成一种可维护的资产？

这件事，现在它至少提供了一个方向：

未来的知识生产，不应该只追求更快生成答案，而应该更重视如何沉淀过程、保留依据、持续修正判断。

答案会过时。

热点会消失。

模型会更新。

但一套好的研究方法，却可以不断复用和演化。

这也是我继续维护这个 Skill 的原因。

它不是为了让 AI 多写一份报告。

而是为了让研究这件事，第一次真正拥有自己的“源代码”。