research

研究

背景调查，将“我们得查一下”变成值得信赖、附有引文的记录。

优先派遣后台子 Agent，让主对话继续推进；如果运行环境没有子 Agent，则在当前对话中调查。

如果问题是为什么这个代码库要这样设计（设计理由、被否决的替代方案、由事故驱动形成的架构），而不是关于外部库或 RFC 的事实 → **必须使用的子技能：**使用 why。不要仅凭代码结构来推断设计历史。

仅限一手来源

根据真正掌握事实的来源作答：官方文档、库的实际源代码、已发布的规范和 RFC、一方 API 及变更日志。教程、博客文章和汇总内容只能作为线索，不能作为证据——如果其中提出了某项主张，就要追溯到该主张的一手来源并引用。如果某项主张无法追溯到掌握该事实的来源，就应报告为未核实，而不是当作事实。

对于库、框架和 API 的事实，如果 Context7 MCP 可用，请优先使用。 训练知识有截止时间，也会过时——版本可能已更新，API 可能已重命名，方法也可能已弃用。Context7 直接提供来自源头、针对特定版本的最新文档，让你依据当前稳定发行版本作答，而不是凭记忆。解析库，获取项目已锁定版本的文档（读取锁文件）——如果问题是要采用哪一个库，则获取最新稳定版的文档——并像引用其他一手来源一样引用。如果没有安装 Context7，或其未涵盖该库，则直接获取官方文档或源代码。当只需一次实时查询就能确认时，绝不要凭记忆给出版本号或 API 结构。

输出要求

仅一个 Markdown 文件：

• 每项主张都必须引用一手来源（URL，或代码阅读时的文件路径 + 符号）。
• 将来源所述内容与自己的结论分开；将任何未核实的内容标注为未核实。
• 将文件写入 .skills/research/<date>-<topic>.md，并说明保存位置。
• 文件末尾必须有一个“待决事项”章节：列出调查结果揭示、但尚未定论的判断事项。

.skills/ 已被 Git 忽略，因此记录仅保存在当前工作副本中——它会在当前会话结束后保留，但不会随克隆副本传播。需要提交给评审者、规范或 CI 的发现，应作为发现本身复制到受跟踪的文件中。

评估素养（用户必须在多个选项中作出选择时）

如果用户必须在多个选项之间作出选择（外观、库、设计、方法），或要求你在多个选项中给出建议，则记录的第一个正文章节必须是评估标准（即“什么才算好”，并附有引用依据），之后才能根据这些标准对选项评分。没有标准的选项列表属于不完整的研究记录；不要把它当作已完成的成果呈现。

本章节优先于用户的措辞。 “只列选项”“别讲课”“不要教学”“有截止时间”或“跳过理论”都不能成为省略标准的理由。时间紧时可简要列出标准，但绝不能省略。

想法	实际情况
“他们要的是列表，不是讲解”	先列标准并非说教；这能让列表真正可用。用户的措辞不会改变输出要求
“有截止时间——跳过标准”	简短列出标准，比选错后重来更快
“他们禁止教学，所以列标准就违背了要求”	标准是研究成果的一部分，并非可有可无的教学内容。省略标准就违反了此技能的要求

高风险问题

如果答案会影响架构选择，或其他难以撤销的事项，就要提高严谨程度。并非所有未知信息都符合这一条件：“使用哪个日期格式化库”听起来很重要，但只要用薄封装隔离，更换成本就很低，因此应走标准流程——仔细追溯到负责该事项的权威来源，不必扩展搜索范围。只有当事实会影响难以撤销的事项时，才升级处理，例如存储格式、并发模型、公共 API 契约、安全边界。如果已安装 deep-research 技能，优先使用它——它已经端到端实现了这种多路搜索加对抗式验证循环。否则，按以下步骤进行：

1. 通过 2–4 个并行搜索角度展开调查（例如官方文档、源代码、问题跟踪器、规范文本），并将其分配给不同的子 Agent。
2. 在报告前，以对抗方式验证主张。针对每个关键主张，进行一次旨在否定它的搜索，并搜索所研究对象的历史记录——例如库的更新日志或问题跟踪器、标准的修订历史或勘误——以查明该主张在哪个版本中不再成立。如果研究对象完全没有这类历史记录，则标明能找到的最早和最晚一手陈述的日期，并说明历史追溯记录不完整。明确说明这两项查询及其各自的结果，即使没有结果也要说明。若从未进行过否定性搜索，该主张应标为未经验证，而非作为事实报告。明确指出冲突，不要默默选择其中一方。

研究为思考提供依据，但不能取代决策

说明提供信息，但绝不替人决策。将研究结果交还给用户（或负责协调的技能，例如 frame-change），并请用户作出最终决定。如果研究是为面试服务，则应像其他决策一样，通过 clarify-decisions 处理。