更新：@今天的日期（MM/DD/YY）
问题背景
用一个简洁但可操作的问题陈述段落，描述该问题及其背后的动机，清晰阐明此功能旨在解决的核心问题或构建后所解锁的机会。 该功能的市场宣传语是什么？为什么我们现在要构建它？我们凭什么能凭借此功能胜出？ 该问题陈述必须足够详细且可操作，无需额外上下文即可独立传达所有关键要点，但请严格限制在最多3个简洁句子以内。 以最相关的客户角色作为开头（例如：“企业主需要……”），但切勿在概述段落中使用真实人名和公司名。
解决方案设计
在确定方向之前，先探索解决方案空间。 考虑多个候选方案，并从战略和体验两个角度进行评估。
确定哪些战略杠杆对该解决方案最为重要，并深入探讨它们：
- 优先选择能够通过规模经济最大化成本优势的功能，随着用户采用率或运营量的增加，降低单位成本。
- 选择能够放大网络效应的功能，随着参与者数量增加，提升用户价值。
- 支持能够创造反定位机会的功能，引入竞争对手无法轻易复制或会严重扰乱自身战略的能力或体验。
- 强调能够提高客户转换成本的功能，使用户难以或不愿离开该生态系统。
- 聚焦于能够强化品牌的功能，巩固其独特身份，并与用户建立持久的情感连接。
- 利用能够抓住锁定资源的功能，例如专有数据、独家合作伙伴关系或竞争对手难以获取或模仿的独特能力。
- 实施能够展现卓越流程或专有工作流的功能，从而在竞争对手面前建立可持续的运营优势。
在设计简单且令人愉悦的用户体验时，尝试在设计用户流程时运用以下一些原则：
- 简化到极致——移除不必要的步骤或功能，以提供直观、极简的体验。每个元素都必须有其存在的价值。
- 保持无缝连续性——以最小的认知负荷引导用户顺畅完成整个过程，不留下任何死胡同。
- 注重细节——排版、过渡、间距和文案都应体现出精心的工艺。在每个触点上平衡功能与美感，保持统一一致的品牌感觉。
- 令人愉悦的惊喜——添加微小但难忘的细节，使体验超越纯粹的功能性。
- 当不确定如何设计 SaaS 组件时，请参考 Linear 的设计或功能实现方式。
在讨论解决方案时，不要明确提及这些原则，只需在探索、决定并解释最佳解决方案时将其融入你的推理过程即可。
在探索解决方案空间并确定最佳策略后，提供一个简洁的说明，描述该功能的作用、它如何解决用户痛点以及如何为用户带来愉悦体验——行文紧凑，避免不必要的开场白。
- 详细说明用户与产品交互和体验的理想方式。重点放在界面设计、用户旅程的每个步骤，以及如何改善整体可用性和解决方案的简洁性。
- 展示我们期望在启动此功能后出现的真实使用场景叙述。
- 以真实用户在真实时刻中的表现作为锚点。例如：“当 Frank 在旧金山拜访不同的初创公司时，他使用[功能 X]记录投诉，并在[功能 Y]中跟踪要求……”
- 强调我们可以采用的独特策略或使此解决方案有别于市场替代方案并反制竞争对手的方面。
记住：最佳解决方案可以最大限度地提升 ICE 评分：影响、信心和努力。影响越大、信心越高、努力越小——解决方案就越优秀。
将解决方案说明拆分为聚焦且简洁的段落，用换行分隔——每个段落对应体验的一个方面。
验收标准
每个标准必须描述一个具体的、可测试的条件，并附有明确的预期结果。标准描述的是预期结果，而非实现方式。标准应符合 MECE 原则——相互独立且完全穷尽——覆盖完成工作所需的所有条件。
功能标准：
- [可观察的用户行为 → 预期的系统响应或结果]
边界情况与错误处理：
- [当输入无效、服务失败、数据缺失或用户遇到意外状态时会发生什么]
范围外：
- [此项工作明确不包含的内容——设定清晰的边界以防止过度构建]
<强验收标准示例>
- 当用户在搜索栏中输入时，结果在 300ms 防抖后实时更新，以排名列表形式显示产品名称、图片和价格。
- 用户可以导航到“设置 > 编辑个人资料”，更新名字、姓氏、电子邮件和电话号码。更改在保存后立即生效，并在整个应用中无需刷新即可反映。
- 如果保存请求失败（超时或 5xx 错误），显示内联错误提示：“出错了，请重试。”表单保留用户未保存的输入。
- 提交空搜索查询会返回默认结果列表，而不是错误或空状态。
- 这不包括批量编辑个人资料、CSV 导出或管理员级别的权限更改。 </强验收标准示例>