product-question

product-question

将代码库调查结果转化为通俗易懂的产品说明，可直接粘贴到电子邮件、Teams、Slack 或产品文档中。

决策树

用户在问什么？

• 产品人员、PM、利益相关者、支持负责人或非工程师询问应用的行为 使用此技能。检查代码，然后用可直接分享的产品语言作答。

• 用户询问“……时会发生什么”“为什么应用会执行 X”“此功能如何运作”或“用户会看到什么” 使用此技能。先追踪实际行为、规则和例外，再作答。

• 用户需要一份有代码依据、可转发、粘贴或引用的应用行为说明 使用此技能。让最终答复润色到可以直接分享。仅仅泛泛地要求改写或分享文案，并不足以触发此技能。

• 用户询问实现细节、修复、评审或代码更改 除非用户还需要面向产品的说明，否则不要继续使用此技能。切换到合适的编码或评审工作流。

• 问题范围很广，代码库也很大 只有在无法推断目标功能、页面、客户操作或工作流时，才提出一个简短的范围确认问题。

• 无法从现有文件中验证行为 说明检查了什么、哪些内容仍不确定，以及哪些证据可以得出结论。不要猜测。

快速参考

情况	操作
需要查找行为	阅读 references/discovery.md
需要确定最终答复的形式	阅读 references/answer-contract.md，或从 templates/product-answer.md 开始
需要避免常见陷阱	阅读 references/gotchas.md
需要快速给出范围较窄的答复	搜索用户提到的功能词、路由、标签、配置键、测试和面向用户的文案
需要回答范围较广的工作流问题	追踪入口、决策规则、数据状态、用户可见结果和例外
需要验证此技能包	在技能目录中运行 python3 scripts/validate.py .
需要进行打包和评测检查	在技能目录中运行 python3 scripts/test_skill.py .

默认工作流

1. 将产品问题具体化：功能、页面、工作流、用户操作、账户状态或业务规则。只有在有助于明确范围时才重述问题。
2. 有已知的归属文件时，从这些文件入手；否则，搜索面向用户的词语，例如标签、路由名称、按钮文案、配置名称、事件名称、测试名称和文档。选择最简短且可靠的调查路径。
3. 阅读定义实际行为的文件，而不只是文件名看起来相关的文件。
4. 从用户操作或系统事件追踪到结果。记录输入、决策规则、状态变化以及用户可见的消息。
5. 检查测试、固定数据、功能标志、权限、租户或账户条件，以及环境特定分支，寻找例外情况。
6. 区分观察到的行为和推断。重要结论应有直接证据支持。
7. 面向产品读者撰写答复：默认先说明结果，并使用通俗易懂的语言。只有在适合读者或用户有要求时，才加入简明的技术术语或代码，并解释其产品含义。
8. 只有在能帮助收件人建立信任、又不必阅读代码时，才添加简短的“可信度”或“已检查”说明。

可直接分享的回答标准

最终回复应像是写给产品渠道的内容，而不是开发者的工作笔记。

以下可选结构或许有帮助；请根据问题和受众进行组合、删减或调整顺序：

1. 简短回答——用一两句话直接回答问题。
2. 这对用户意味着什么——说明用户可见的行为、决策或限制。
3. 规则与例外——说明会改变答案的权限、功能开关、账户状态、时间安排、数据条件或边缘情况。
4. 依据——用简短的“已检查”一行列出文件或相关区域，而不是贴出代码。
5. 置信度——仅在依据不完整、结论来自推断或受环境影响时使用。

请做到：

• 可直接分享
• 表述直白
• 具体说明行为
• 对不确定性保持诚实
• 少提文件名和技术术语
• 谨慎使用代码块：仅在有助于说明行为或满足请求时使用，不要把调查过程一股脑贴出来

证据规则

优先提供与产品相关的证据，而非技术清单：

• 更好：“应用只有在加载了有效订阅后才会显示取消选项。”
• 不够实用：“SubscriptionActions 组件会在 useSubscriptionQuery 返回后有条件地渲染 CancelButton。”

仅当文件名有助于增强可信度或便于核实答案时才提及。可使用简短的已检查行，例如：

Checked: subscription settings screen, billing API route, and subscription status tests.

如果某项结论依赖推断，请明确说明：

Confidence: high for the web flow; I did not find mobile-specific handling in the available code.

即使可直接分享的回答使用简洁引用而非技术附录，重要结论仍应能追溯到已检查的文件、测试或配置。代码只能说明当前检出版本的行为，不能证明未经核实的部署或外部服务当前的行为。

来源与维护

将以代码为依据的行为和对不确定性的诚实说明作为稳定原则。如果本地指导不足、过时，或与外部依赖的行为相冲突，请查阅适用于已安装版本的官方文档或可信一手来源；不要例行浏览，也不要用服务提供方的文档取代应用本身的证据。说明核实范围的限制，并提出附带示例或回归用例、且有来源依据的技能修正方案。仅在维护工作属于当前任务范围时编辑规范技能；切勿悄悄更新已安装的副本。

语气规范

• 不要把“我检查了代码库”当作填充语。开门见山地给出答案。
• 不要过度解释框架、服务、钩子、归约器、迁移或 API。
• 将技术机制与产品意义联系起来；保留有助于读者理解的简洁技术细节。
• 优先使用短段落，而非冗长的项目符号列表；除非问题本身适合比较。
• 让用户可以直接转发回复，无需删改内部分析内容。

阅读指南

需求	阅读
调查流程、搜索目标和置信度标签	references/discovery.md
可直接分享的回答结构与示例	references/answer-contract.md
常见失败模式与恢复方法	references/gotchas.md
可复制的最终回答模板	templates/product-answer.md

易错点

1. 不要混淆实现方式与产品行为。产品读者通常关心会发生什么、谁能看到，以及哪些因素会改变结果。
2. 不要让答案显得比证据更确定。依据猜测作出的产品决策代价高昂。
3. 不要在正文中罗列文件路径。除非用户要求提供技术追溯信息，否则请使用简短的证据说明行。
4. 不要只依据测试或 UI 文案作答。测试可能描述预期行为；UI 文案可能省略隐藏规则。
5. 不要让流程说明掩盖答案。第一句话应直接回答问题。