define-product

定义产品

梳理用户心中设想的产品含义，然后将其保留在仓库中唯一且最新的应用定位说明里，明确应用是什么以及为何重要。粗略的方向可以开启对话，但无法补足缺失的产品含义。

要求提供方向种子

从现有的产品定义开始，或至少从用户想要探索的某个粗略受众、情境、问题、预期改变或大致解决方案方向开始。如果这些都不存在，请指出缺少的信息并停止，不要挖掘个人痕迹、凭空制造机会或创建 PRODUCT.md。

像“将网页转换成 Markdown”这样宽泛的解决方案，足以开启访谈，但不能作为证据，用来推断未说明的用户、问题、工作流或成功衡量标准。

阅读当前上下文

如果根目录中存在 PRODUCT.md，请阅读。也请阅读 GLOSSARY.md，并在存在时阅读 docs/decisions/README.md 中的相关主题。

区分以下信息来源：

• 用户明确陈述的内容提供了预期的产品含义。
• 在用户确认变更之前，当前的 PRODUCT.md 提供了现有的预期含义。
• 代码能证明当前行为，但不能证明预期含义。
• 仓库证据和权威外部来源提供的是事实，而非产品选择。

只核实那些可能改变下一个问题或最终定义的事实。当现有含义、新请求与当前行为不一致时，应清楚说明差异，并询问应以哪种含义为准。在用户明确选择之前，保留当前文件不变。

梳理产品含义

将以下方面作为检查最终定义的参考，而不是要求用户逐项填写的问卷：

• 一句话应用定义；
• 主要用户及其使用情境；
• 用户面临的问题，以及他们目前的替代做法；
• 应用承诺为用户带来的改变；
• 反复发生的核心循环；
• 全应用范围的能力和产品边界；
• 体验原则；
• 可观察的成功信号；
• 重要假设和未知事项。

当用户、情境、问题或当前替代做法不明确时，应从一个具体的使用场景开始。询问是谁在做什么、遇到了什么，以及他们现在会怎么做。每轮提出 1 到 3 个密切相关的问题；如果一个回答会决定下一个问题，就只问这一个，然后等待回答。

在梳理用户可能已有的想法时，提出开放式问题。不要在这些问题中推荐答案或提供带有引导性的选项。如果回答仍然宽泛，就追问具体情境或可观察的改变，不要把“所有人”“容易”或“快速”等词转化为既定的产品含义。

将当前的问题与承诺带来的改变分开。应询问哪些方面应该变得不同，而不是把当前问题的反面当作用户已确认的目标。

每次用户回答后，只复述新明确的内容，然后转向下一个重要的缺口。在最终草稿完成之前，将所有缺失方面的完整列表留在内部；用户已经提供过的含义，不要再次询问。

处理用户尚未做出的选择

当用户表示尚未决定某项产品选择时，询问他们是想暂时将其留为未知，还是一起做出决定。只有在用户请求帮助做出选择后，才提供选项和建议。

当具体使用场景有助于澄清尚未决定的选择时，先询问使用场景。在了解产品实际使用方式之前，不要把抽象的不确定性转化为选项之间的选择。

当用户授权你做出某项选择时，明确其范围：指出具体选择、相关标准和任何限制。然后说明所选答案及理由。笼统的“你来决定”并不意味着你有权决定无关的产品含义。

当用户授权你决定“其余事项”却没有设定这些限制时，指出仍需用户提供意见的核心含义，并从实际使用场景继续。除非用户明确指出委托决定的选择、标准和限制，否则不要承诺稍后补全该含义。

工作期间，将以下状态分别记录：

• 用户直接确认的含义；
• 在用户明确授权范围内做出的选择；
• 用户同意作为假设接受、但缺乏依据的看法；
• 用户选择暂时留为未知的重要事项；
• 尚未定案的 AI 提议。

沉默或信息缺失，并不意味着产品选择已定案、已授权、已作为假设接受或被推迟。只有在用户同意将某项内容保留为该状态后，才能将其记录为假设或未知。

判断定义何时已准备就绪

只要尚未回答的问题可能实质性地改变应用定义、用户及其使用情境、反复出现的问题及当前替代方案、承诺带来的改变、核心循环或长期边界，就继续访谈。只有当其他方面的答案会改变后续产品工作时，才询问相关内容；不要为了填满某个章节而凭空补充细节。

如果核心用户、情境、问题、当前替代方案、承诺带来的改变或核心循环仍是猜测，或仍有未经确认的缺口，就不要创建 PRODUCT.md。说明仍缺少哪些内容，并继续访谈。只有在用户接受某个较次要的缺口作为假设，或有意将其留为未知时，才可以保留该缺口。

写入文件前，完整展示一次产品方向。明确区分用户确认的内容、在授权范围内做出的决定，以及仍被接受的假设或有意保留的未知事项。请用户确认或修正该草案。

只有当一份详细的初始请求明确要求创建文件、每项重要的产品陈述都无需猜测即可写出，且不存在与之冲突的既有产品含义时，才可将其视为确认。在这种情况下，直接写入文件，不要重复提问或再次请求批准。

编写当前产品背景

仅创建或更新根目录下的 PRODUCT.md，并使用 product context format。在原处重写当前描述；不要追加历史记录、创建带日期的版本，或在当前前提旁保留过时的含义。

将已定案的授权选择放入其影响到的产品章节。保留该选择是经授权做出的，以及选择理由；这些信息应在写入前的草案和完成报告中清晰可见，而不是在 PRODUCT.md 中另设溯源章节。

文件内容仅限产品信息：

• 将应用级能力描述为稳定边界，而不是功能待办列表。
• 将体验原则描述为产品应维护的特质，而不是视觉系统或屏幕设计。
• 保留足以理解前提的理由，但不要加入营销说服内容、公司背景或销售行动号召。
• 将技术、架构、数据和文件结构、仓库机制、实现计划、单个屏幕、详细功能需求及工作单元验收标准留在其现有文档中。

不要创建工作单元规范，也不要将此技能用于构思或实现工作。

完成

当用户确认了完整的产品方向，且后续的 Agent 能够快速理解，不会把猜测误认为意图时，即可完成。报告更新后的 PRODUCT.md、已确定或更改的重要含义、在授权范围内做出的选择，以及已接受的假设或刻意保留的未知事项。