specsfy-specialist-technical-research

技术调研

适用场景

• 当架构、库或方案的决策取决于某个尚无人通过一手来源确认的技术事实时，触发。
• 在做出难以撤销的决策前比较备选方案，或验证对某项依赖行为的假设在当前版本中是否仍然成立时，也触发。
• 不要为了给已经确定的选择寻找理由而再次确认——这是确认偏误，不是调研。
• 当调研结果将直接支撑可记录在 ADR 中的结构性决策时，与 $specsfy-specialist-software-architecture 配合使用。

流程

1. 明确具体问题、该问题将支撑的决策、范围，以及所需的新近程度（需要了解当前行为，还是历史信息已足够？）。
2. 预先确定哪些证据能够证实或证伪每个备选方案——否则，任何结果看起来都像是在证实最初的假设。
3. 按以下优先顺序选择证据：规范／标准、带版本号的官方文档、官方源代码和变更日志、在目标环境中可复现的实验，最后才考虑二手来源。
4. 核实版本、发布日期，以及其是否适用于项目中实际观察到的环境——针对其他版本记录的行为，不能作为当前使用版本的证据。
5. 对所有影响决策的关键论断，至少用第二个独立来源交叉验证；如果文档无法解答疑问，则进行受控实验。
6. 明确区分已确认的事实、推断（可能但未经确认）、风险，以及仍缺乏证据的空白。
7. 综合结论时，在具体论断附近附上来源直达链接，并说明其对当前决策的具体影响。

准则

• 当存在可访问的一手来源时，不要将论坛片段、个人博客或通用 AI 回答作为 API 行为的权威依据——可以把它们当作寻找一手来源的线索，但不要在最终结论中引用。
• 在论断附近引用来源的具体页面和章节，而不是文档首页的通用链接。
• 总结时保留决策所需的上下文；避免大段照搬，以免只是把阅读工作推迟到之后。
• 对行为可能随版本变化的来源，记录其版本和日期——否则，结论会在无人察觉的情况下失效。
• 当两个来源相互冲突时，明确说明冲突，不要默默选用其中一个而不解释其优先理由。
• 不要在项目规范来源之外另建一个 research.md；调研应编入索引，并存放在项目使用方的规范所指定的位置。
• 将技术供应商发布的基准测试视为有利益倾向的证据——它可以作为起点，但如果没有独立复现，绝不能作为最终结论。

反模式

• 已经做出决定后才开始调研，只寻找支持决定的证据——第 1 步中提出的问题就已经带有偏见（问“为什么 X 更好”，而不是问“X 还是 Y，以及依据什么标准”）。
• 只说“文档中写道”，却不提供链接或版本——行为改变后，就无法重新核实该论断。
• 将供应商的营销基准测试照搬过来，仿佛它是对项目环境进行的中立测量。
• 面对多个相互冲突的来源，只选择支持最初偏好的那个来回答问题，却不记录存在冲突。

验证

• 支持决策的每项结论都有直接且可追溯的证据 （链接 + 版本 + 日期），而非仅凭记忆断言。
• 使用的来源与使用方项目的实际版本和运行时相符，而非通用或过时的版本。
• 执行的实验可由他人复现，且不会影响生产环境或真实数据。
• 最终总结明确说明了信息缺口和残余不确定性，不会掩盖这些问题，或得出超出证据支持范围、过于肯定的结论。
• 不得将未经多方验证的假设作为事实呈现——禁止使用暗示确定性、但缺少相应证据的措辞。

相关技能

• $specsfy-specialist-domain-modeling 使用外部来源对齐概念，但不会取代已验证的领域词汇。
• $specsfy-specialist-prototyping 将技术不确定性转化为一次性实验，并明确假设和停止标准。
• $specsfy-specialist-software-architecture 适用于研究为可记录在 ADR 中的结构性决策提供依据的情况。
• $specsfy-specialist-laravel-package-manager 适用于需要通过研究确认 Laravel Composer 包的文档、版本或安装方式的情况。
• $specsfy-specialist-debugging 适用于所谓的“研究”实际上是在调查观察到的行为为何与文档不符的情况——此时目标是诊断根本原因，而非比较替代方案。

阅读 references/standards.md，了解来源层级、证据评估矩阵和总结格式。