程序员最痛苦的时刻，不是 Bug 调不通，而是面对技术选型。
你打开了 50 个浏览器标签页：GitHub README、掘金对比文章、Stack Overflow 的问答、官方文档的某个子页面。三个小时之后，你的收藏夹增加了 20 条新书签，但你对“到底该选哪个框架”这个问题，依然没有答案。
更让人沮丧的是——下次换一个技术栈的选型，你得把这个过程再来一遍。
今天我要告诉你，这个循环可以被彻底打破。
1. 程序员技术调研的三层地狱
在讲解法之前，先精准地定义痛苦。
程序员做技术调研，通常陷入三层地狱：
第一层：信息碎片化
官方文档告诉你“这个框架很快”，掘金的评测告诉你“实测坑很多”，GitHub 的 Issue 列表告诉你“这个 Bug 三年没修”。这三条信息之间的矛盾，没有任何东西帮你整合。
第二层：调研结果不可复用
你花了一个周末调研完了“Rust async runtime 选型”，写进了一个 Notion 页面。三个月后，你的同事问起同一个问题，你发现你自己都记不清当时的结论了。
第三层：缺口发现太晚
你以为调研已经够全面了，但 Code Review 的时候，资深同事问了一个问题——“你有没有看过它在高并发场景下的内存占用数据？”——你才意识到，这个维度你根本没有覆盖到。
这三层地狱的根源是同一个：你在用人脑做本该由机器做的事。
2. autoresearch 是什么？不是你想的那种“AI 搜索”
大多数人以为，用 AI 做技术调研，就是把问题扔进 ChatGPT，让它给你一段对比分析。
这是错的。那只是“一次性问答”，不是“研究”。
/autoresearch 命令（来自 claude-obsidian 工具）使用的是 Karpathy 风格的研究方式：运行多轮 Web 研究，进行缺口填补，并把带有来源支撑的概念页、实体页和综合页，全部归档进一个复利增长的 Obsidian wiki vault。
这是关键区别：它产出的不是一段文字，而是一批互相链接的结构化 wiki 页面。
autoresearch 的完整程序是这样运作的：
第一轮，广泛搜索：把问题分解成 3–5 个角度，每个角度运行 2–3 个查询，抓取每个角度的前 2–3 个结果；
第二轮，缺口填补：针对矛盾点和遗漏部分进行定向搜索；
第三轮，综合检验（可选）：如果仍有重大缺口，再进行一轮。
最后，归档阶段：产出综合页 + 来源页 + 实体页 + 概念页，全部交叉引用。
这就是与普通 AI 搜索的本质区别：它不只是在找答案，它在主动发现你没想到要问的问题。
3. 实战演示：以“Rust async runtime 选型”为例
我们用一个真实的技术选型场景，完整走一遍。
场景设定：
你在做一个高性能 Web 服务，需要在 tokio、async-std 和 smol 之间做出选择。
Step 1：启动 autoresearch
在 Claude Code 终端输入：
/autoresearch "Rust async runtime comparison: tokio vs async-std vs smol, production usage 2025"
你需要做的，只有这一行。
Step 2：观察它的三轮工作（2 分钟内完成）
Round 1 — 广泛搜索：
Agent 自动拆解出这几个角度：
- 性能基准对比（吞吐量、延迟、内存占用）
- 生态兼容性（与主流框架的集成度）
- 社区活跃度与维护状态
- 实际生产案例
Round 2 — 缺口填补：
Agent 发现了第一轮的盲区：“几乎所有的 benchmark 都是单核场景，多核调度的差异在哪里？” 它自动补充搜索了这个维度，这个问题是你在手动调研时极可能遗漏的。
Round 3 — 综合：
把所有来源里的矛盾点标注出来（例如某篇文章说 tokio 默认多线程调度更适合 CPU 密集型，另一篇说 smol 在 IO 密集型场景反而更轻量）。
Step 3：查看产出的 wiki 页面结构
完成后，你的 wiki/ 目录里多出了：
wiki/
├── entities/
│ ├── tokio.md ← 详细页：诞生背景、核心特性、生态
│ ├── async-std.md
│ └── smol.md
├── concepts/
│ ├── rust-async-runtime.md ← 概念解释页
│ └── work-stealing-scheduler.md ← 这个是 Round 2 补充发现的！
└── synthesis/
└── rust-async-runtime-comparison.md ← 最终对比综合页
Step 4：看综合页的结构（这才是最有价值的部分）
synthesis/rust-async-runtime-comparison.md 会包含：
## 核心结论
- tokio：生态最成熟，Axum/Actix 强依赖，多线程调度优秀
- async-std：API 更接近标准库，生态较小，社区活跃度下降
- smol：极简主义，内存占用最低，适合嵌入式/资源受限场景
## 矛盾点标注
[!contradiction] 关于多核调度效率：
来源A（benchmark.rs 测试）：tokio 在 16 核场景性能领先 23%
来源B（real-world-case-study.md）：实际 web 服务中差距不明显
## 推荐决策树
- 如果你在用 Axum/Tower 生态 → tokio（无需多想）
- 如果你在做嵌入式或 WASM → smol
- 如果你需要 std API 兼容 → async-std（但注意社区趋势）
## 来源引用
[[tokio]] [[async-std]] [[smol]] [[work-stealing-scheduler]]
一个单一来源可能触及 10–15 个 wiki 页面。而 autoresearch 会自动跨多个来源进行整合，所有交叉引用都是自动生成的。
4. 为什么调研结果“永久有效”？
这是最关键的一点，也是与传统调研方式的本质区别。
wiki 是产品，聊天只是界面。
当你下次面对新的选型问题时——比如“我在新项目里该不该继续用 tokio？”——你不需要重新调研。你只需要运行：
/wiki-query "tokio production considerations"
你提问，Claude 读取热缓存（最近上下文），扫描索引，钻入相关页面，合成出一个答案。
而这个答案，建立在你过去所有调研积累的基础上。你三个月前做的调研，今天依然在为你打工。
这套系统的强大之处在于它的复合特性：每添加一个文档，都在丰富一个随你成长的基础。到第 10 份文档时，它很有用。到第 100 份文档时，它就变成了一个真正的增强记忆，能实现单纯的 RAG 或人类记忆都无法实现的推理。
5. 进阶配置：让 autoresearch 专为程序员优化
autoresearch 命令是可配置的。编辑 skills/autoresearch/references/program.md 来控制优先搜索哪些来源（学术论文、官方文档、新闻）。默认程序适用于通用研究，你可以针对你的领域进行覆盖。医学研究者会添加“优先选择 PubMed”；商业分析师会添加“聚焦市场数据和文件”。
对于程序员，我推荐在 program.md 里添加如下配置：
## 研究优先级（程序员专属）
1. 优先读取：官方文档、官方 GitHub README
2. 次优先：知名技术博主的 benchmark 文章（附测试环境）
3. 参考：掘金/知乎技术社区（注意标注来源可信度）
4. 必须覆盖的维度：
- 性能数据（需有具体数字，拒绝模糊描述）
- 生态兼容性（与你当前技术栈的集成难度）
- 维护状态（最近 commit 日期、issue 响应速度）
- 已知缺陷（查阅 GitHub Issue 的 "known bug" 标签）
6. 你的调研不再是一次性消耗品
传统的技术调研，是你时间和精力的一次性消耗。
用了这套系统之后，每一次调研，都是你个人技术知识库的永久资产。
你积累得越多，下一次调研就越快。不只是因为 AI 更快，而是因为它会把新的调研结果，自动与你过去的所有技术判断进行交叉对比，告诉你：“你之前在某个项目里考虑过类似的取舍，结论是……”
这才是真正的知识复利。
程序员的时间，应该花在判断上，不是搜索上。
发表于 昨天 21:45
|
查看: 8|
回复: 0
