1 · Bilingual Reader 2 · Design Notes 1. Bilingual SKILL.md 左右滑动可直接切换英文版与中文版；两种语言按段落自动对齐。英文中的蓝色虚线词语可点击查看解释。共标记 9 处。
Spin up a **background agent** to do the research, so you keep working while it reads .
1. Investigate the question against **primary sources** (official docs, source code, specs, first-party APIs), not a secondary write-up of them. Follow every claim back to the source that owns it.
2. Write the findings to a single Markdown file, citing each claim's source .
3. Save it where the repo already keeps such notes; match the existing convention , and if there is none, put it somewhere sensible and say where .
启动一个**后台智能体（background agent）**来完成研究，这样它阅读资料时，你仍可继续工作。
1. 对照**一手资料（primary sources）**研究问题（官方文档、源代码、规范、第一方 API），而不是这些资料的二手解读。把每项论断一路追溯到真正拥有该信息的源头。
2. 把研究结果写入一个 Markdown 文件，并为每项论断标注来源。
3. 把文件保存到仓库现有的此类笔记位置；遵循已有约定，如果没有约定，就放在合理的位置并说明具体路径。
Entry SHA-256: 985569f15739c713d6784887c3d186d4ef9ac85bec5ad9c068d25bf0739928e4
2. Why This Skill Is Clever 一句话核心机制
把“查资料”拆成一个可并行执行、逐项追溯一手来源、最终落盘为可审计 Markdown 工件的后台任务。
触发与边界
直接来源： frontmatter 把触发条件限定为研究主题、收集文档或 API 事实，以及委派阅读跑腿工作。它不是用来替代团队作决定，也没有要求安装或执行上游仓库中的任何命令。
解释： “后台智能体”是宿主框架能力，而不是通用 Markdown 标准。移植到不支持后台任务的环境时，可以保留证据约束与文件工件，但无法保证主线程继续工作。
信息架构 / 执行顺序
主智能体先把研究问题交给后台智能体，避免同步阅读阻塞当前工作。
后台智能体只把官方文档、源代码、规范和第一方 API 当作首选证据。
每项论断都追溯并绑定到拥有该事实的来源，而不是只在文末堆一组链接。
所有发现收敛到一个 Markdown 文件，减少结果散落。
文件先服从仓库既有笔记约定；没有约定时才自主选择合理位置并回报路径。
最巧妙的设计点
1. 并行不是目的，保持主线程推进才是
“keep working while it reads”
直接来源： 技能明确要求启动后台智能体。巧妙之处在于把高延迟的阅读任务从主工作流剥离，而不是笼统地说“多用智能体”。这样研究可以作为旁路输入，主线程继续处理不依赖结果的工作。
2. 来源资格与论断追溯是两道不同的门
“primary sources”
“Follow every claim back to the source that owns it.”
直接来源： 第一条规则既规定可接受的来源类型，又规定每项论断的追溯粒度。只满足前者仍可能把来源与结论错配；两者组合才形成可审计的证据链。
3. 强制单文件，让交接对象稳定
“a single Markdown file”
直接来源： 输出不是聊天里的临时回答，而是一个明确的仓库工件。单文件约束降低了发现和交接成本，也使后续评审、规划或实现可以指向同一个对象。
4. 先适配仓库，再创造结构
“match the existing convention”
直接来源： 技能要求先观察仓库如何存放此类笔记。它避免每次研究都发明新的 docs/、notes/ 或 research/ 目录，从而减少结构熵。
5. 自主权配套可发现性
“put it somewhere sensible and say where”
直接来源： 没有约定时，后台智能体无需卡住等待决定；但必须报告路径。这个小规则同时保留了自主执行和可追踪交付。
防失败机制与 trade-off
显式不变量（直接来源）：
证据优先来自官方文档、源代码、规范或第一方 API；
不使用这些材料的二手转述替代原始来源；
每项论断都要引用其来源；
每次只产出一个 Markdown 文件；
输出位置遵循现有约定，或明确说明自主选择的路径。
支持性上下文： 仓库的 docs/engineering/research.md 记录了两个未由短 SKILL.md 解决的风险：后台智能体可能再次委派导致重复任务，以及技能没有显式停止条件。它还指出“高可信”最终由模型判断，没有域名白名单或独立验证关卡。这些是伴随文档中的已知限制，并非所选原文新增的规则。
解释与取舍： 只有三步的短指令具有很强的可移植性，但把问题范围、停止条件、引用格式、来源冲突处理和最终验收都留给模型。并行能降低等待时间，却会提高资源消耗和递归委派风险。把文件写进仓库便于交接，也可能让时效性很短的研究结果变成陈旧上下文。
可迁移原则
把耗时 I/O 从决策主线拆出去。 仅当后续工作不立即依赖结果时并行化。同时定义来源层级和引用粒度。 “用权威来源”不够，还要让每项论断可追溯。为委派任务规定一个清晰工件。 文件数量、格式和落点越明确，越容易验收。先发现宿主约定，再创建新结构。 自主执行不应制造目录熵。自主选择必须附带回报。 允许智能体决定路径，但必须告诉调用者结果在哪里。
今日实践题
如果你把这个技能迁移到一个不支持后台智能体、但支持普通子进程的框架里，你会如何改写第一句，既保留“不中断主线”的目标，又避免声称框架拥有并不存在的能力？
Evidence note
本文的执行顺序、来源门槛、单文件输出和路径约定来自所选 SKILL.md。递归委派、停止条件、高可信判断和研究文件时效性来自伴随文档 docs/engineering/research.md，已明确标为支持性上下文。关于可移植性、资源成本和目录熵的讨论属于设计解释。
Source & provenance
Repository path skills/engineering/research/SKILL.md
Generated 2026-09-06 08:22 Asia/Shanghai
Upstream commit 3cca18b368ae95cdbdebbff572ccafa662551015