developer-docs-technical-research

开发者文档技术调研

在规划或编写开发者文档之前，使用此技能调研产品行为。它能将规格、代码、原型、工单、主题专家和实操测试转化为可追溯的调研笔记。

此技能改编自 Christopher Gales 和 Splunk Documentation Team 的 The Product Is Docs: Writing Technical Documentation in a Product Development Group 中的指导，尤其是第 13 章“技术写作者的调研”、第 16 章“技术验证”、第 19 章“与工程师合作”和第 22 章“与产品管理团队合作”。请勿在面向用户的输出中照搬书中的原文。来源：https://link.springer.com/book/10.1007/978-1-4842-7217-6

快速开始

1. 加载 guidelines.md，以选择最精简且实用的参考资料集。
2. 说明文档问题、受众、功能、发布背景和风险。
3. 根据代码、产品界面、规格、工单、主题专家、QA、支持团队和现有文档，绘制来源图。
4. 如果功能行为或对用户的影响尚不清楚，请使用 workflows/research-feature-docs.md。
5. 如果主要工作是从主题专家处提取事实，请使用 workflows/interview-doc-sources.md。
6. 返回已验证事实、假设、矛盾、来源负责人和待解决的问题。

默认输出

完成一轮文档调研后，请返回：

1. 调研简报 - 文档问题、受众、范围和所需决策。
2. 已验证事实 - 行为、限制、默认值、前提条件、权限、错误和示例，并附上来源。
3. 对用户的影响 - 读者可以执行或决定的事项，以及可能面临的风险或误解。
4. 来源图 - 每项重要事实的权威负责人或资料。
5. 矛盾与缺口 - 尚未解决的分歧、缺失的访问权限或未经测试的行为。
6. 建议的文档行动 - 制定计划、起草、延期、提交产品问题或请求审核。

目录

需求	从此处开始
理解技术调研概念	references/core/knowledge.md
制定功能调研计划	workflows/research-feature-docs.md
采访工程师、PM、QA、支持团队或现场团队	workflows/interview-doc-sources.md
根据任务或症状选择入口	guidelines.md

核心原则

• 调研面向用户的影响，而不只是实现方式。
• 如果可以使用产品、API、CLI、UI 或环境，请直接进行验证。
• 将明确的负责人和持久资料视为事实来源。
• 在不确定性消除之前，始终明确标示。
• 如果文档不得不解释本可避免的困惑，请提交产品或 UX 缺陷。