product-development

产品开发

以这条循环作为产品开发的基准：

倾听客户
→ 定义问题
→ 发明解决方案
→ 完善解决方案
→ 测试并迭代

循环表达的是一套连贯判断，不是必须按顺序走完的瀑布流程。测试、新证据和实现中的发现可以让工作回到任何较早阶段。其他产品方法只是在当前环节存在具体未知时可以选择的工具，不增加新的主流程，也不把不同公司的完整制度拼接起来。

收到反馈或新的实现、使用证据时，先判断它改变了什么。已约定行为未被实现且要求仍清楚时，由实现过程修正。对客户想取得的结果理解不足时，回到倾听和问题定义。实现符合原方案但体验或价值仍不足时，重新检查方案及其假设。依据不足以区分时，先取得能够区分这些原因的最小证据，再决定进入哪个环节。只展开受影响的判断，保留仍有效的决定。

产品观

客户持续追求更好的结果，却未必能够说出理想产品的形态。倾听客户是理解其现实、愿望和判断，不是让客户替团队设计功能。产品团队负责代表客户解释这些材料，结合技术与环境中正在出现的新可能，提出一个比现状更接近理想的具体产品。真实选择、使用行为和结果负责检验这项定义。

这里的“客户”按产品实际关系理解，可以是直接使用者、购买者、操作者或会受到产品影响的人。先确定谁的结果决定产品价值，不把最容易接触到的意见自动当作客户现实。

个人定制产品

为当前用户本人定制软件时，明确用户同时承担的委托人、使用者和产品决定者角色。用户已确认的目标、使用习惯、偏好与边界作为产品依据。团队负责解释、提出方案和实现，可以用证据提出不同做法并说明影响，改变这些要求前与用户形成新决定。面向一般市场的推测和通用最佳实践不能自行取代个人要求。

用户表达中区分明确要求、探索中的想法、举例和团队推断。含义会改变产品时，用具体情景核对，保留尚未确定的部分。用户的纠正先用于修正团队理解，再判断是否真的发生了需求变化。

与客户共同形成决定

产品定义早期需要通过对话补足客户现实时，优先使用开放问题，让客户描述具体经历、愿望、判断和不能接受的结果。此时没有形成可靠的整体理解或真正不同的产品路线，就不要把零散概念提前压成选项，也不要让客户在看不到全局时替团队决定架构。

证据已经足以形成少量本质不同的路线时，先说明当前问题全景、各路线处于哪个共同层级、会改变什么以及团队的当前倾向，再请当前用户或明确的产品责任人决定只有他们能够决定的价值取舍。候选必须比较同一维度上的真实选择。整体架构、数据表达和局部策略等不同层级的概念不能伪装成互斥选项。

客户提供现实、反应和结果证据。当前用户或明确的产品责任人决定会实质改变客户价值、整体体验、目标范围、成本、长期维护、权限、外部影响或严重后果的取舍。可从产品、代码或环境取得的事实由团队主动调查。普通、可逆且不改变上述结果的实现细节由团队自行判断并连续推进。

推进粒度服从风险、依赖、可逆性和客户影响。避免用一份一次性总计划掩盖尚未设计的内容，也不把反对 one-shot 变成固定阶段、固定模板或逐项请示。复杂工作只在有助于理解和控制时保留整体方向、当前已展开部分和下一处关键决定。简单任务与不需要客户介入的细节由团队自行拆解、实施和验证。

核对共同理解

新产品、重要体验变化或需求存在多种实质解释时，读取 与用户核对产品理解。由团队把当前理解表达为可走查的使用情景、具体实例或原型，让用户能指出差异；把确认后的结果带入实现与验收。已有决定足以支撑局部工作时直接沿用。

说明涉及陌生机制、复杂关系或重要取舍，用户需要理解其后果才能判断时，使用 teach-and-explain。先提供足以参与当前决定的背景和具体结果，再讨论选择。用户反馈跟不上时，先恢复受影响的共同理解，无关且已明确的工作继续。

运行循环

选择下一份证据

进入一轮产品判断前，先确定当前要决定什么、哪项未知会改变这个决定，以及最低成本的可靠证据来自哪里。用户交互用于了解具体经历、真实使用、偏好和只有产品责任人能决定的价值取舍；外部研究用于核验成熟方法、同类产品、市场、标准、环境变化和其他可追溯事实；本地原型、代码调查或运行实验用于判断实际行为、技术可行性和集成限制。几种来源可以按依赖组合，但不能用用户意见代替可查事实，也不能让实现局限自行改写产品目标。

多轮材料已经不足以可靠说明当前目的、行动、结果和边界时，先使用 workflow-state-distiller 恢复当前状态。只看眼前现象不足以理解形成原因、未来目标或成熟参照时，使用 xy-axis-thinking。外部候选和经验需要多来源核验时使用 deep-research；实验方式按当前最可能改变决定的未知选择。取得证据后，更新受影响的产品决定、假设和验证依据，说明仍然有效的部分，再决定继续了解客户、重写问题、调整方案、做下一项实验或交给实现。