sdd-full 3.2.0 → 4.2.0

package/skills/requirement-analysis/brainstorming/SKILL.md

@@ -1,166 +0,0 @@
-【claude code调用标识：brainstorming】【trae调用标识：brainstorming+头脑风暴】【流程场景：1.完整3阶段SDD流程、2.从零开始新项目、3.小型功能迭代】
-
----
-name: brainstorming
-description: "在任何创意工作之前必须使用此技能 - 创建功能、构建组件、添加功能或修改行为。在实现之前探索用户意图、需求和设计。"
----
-
-# 头脑风暴：将想法转化为设计
-
-通过自然的协作对话，帮助将想法转化为完整的设计和规范。
-
-首先了解当前项目上下文，然后一次一个问题地完善想法。一旦理解了要构建的内容，就展示设计并获得用户批准。
-
-<HARD-GATE>
-在展示设计并获得用户批准之前，不要调用任何实现技能、编写任何代码、搭建任何项目或采取任何实现行动。这适用于所有项目，无论其看似多么简单。
-</HARD-GATE>
-
-## 反模式："这太简单了，不需要设计"
-
-每个项目都需要经过这个过程。待办事项列表、单个功能实用程序、配置更改 - 所有这些都需要。"简单"项目是未经检验的假设导致最多浪费工作的地方。设计可以很短（对于真正简单的项目，几句话就够了），但你必须展示它并获得批准。
-
-## 检查清单
-
-你必须为以下每个项目创建任务并按顺序完成：
-
-1. **探索项目上下文** - 检查文件、文档、最近的提交
-2. **提供视觉 companion**（如果主题涉及视觉问题）- 这是单独的消息，不与澄清问题结合。请参阅下面的视觉 companion 部分。
-3. **提出澄清问题** - 一次一个，了解目的/约束/成功标准
-4. **提出2-3种方法** - 带有权衡和你的建议
-5. **展示设计** - 按复杂度分部分展示，每部分后获得用户批准
-6. **编写设计文档** - 保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并提交
-7. **规范审查循环** - 调度 spec-document-reviewer 子代理，使用精心设计的审查上下文（绝不是你的会话历史）；修复问题并重新调度，直到获得批准（最多3次迭代，然后提交给人类）
-8. **用户审查书面规范** - 请用户在继续之前审查规范文件
-9. **过渡到实现** - 调用 writing-plans 技能创建实现计划
-
-## 流程
-
-```dot
-digraph brainstorming {
-    "探索项目上下文" [shape=box];
-    "前方有视觉问题？" [shape=diamond];
-    "提供视觉 Companion\n(单独消息，无其他内容)" [shape=box];
-    "提出澄清问题" [shape=box];
-    "提出2-3种方法" [shape=box];
-    "展示设计部分" [shape=box];
-    "用户批准设计？" [shape=diamond];
-    "编写设计文档" [shape=box];
-    "规范审查循环" [shape=box];
-    "规范审查通过？" [shape=diamond];
-    "用户审查规范？" [shape=diamond];
-    "调用 writing-plans 技能" [shape=doublecircle];
-
-    "探索项目上下文" -> "前方有视觉问题？";
-    "前方有视觉问题？" -> "提供视觉 Companion\n(单独消息，无其他内容)" [label="是"];
-    "前方有视觉问题？" -> "提出澄清问题" [label="否"];
-    "提供视觉 Companion\n(单独消息，无其他内容)" -> "提出澄清问题";
-    "提出澄清问题" -> "提出2-3种方法";
-    "提出2-3种方法" -> "展示设计部分";
-    "展示设计部分" -> "用户批准设计？";
-    "用户批准设计？" -> "展示设计部分" [label="否，修改"];
-    "用户批准设计？" -> "编写设计文档" [label="是"];
-    "编写设计文档" -> "规范审查循环";
-    "规范审查循环" -> "规范审查通过？";
-    "规范审查通过？" -> "规范审查循环" [label="发现问题，\n修复并重新调度"];
-    "规范审查通过？" -> "用户审查规范？" [label="已批准"];
-    "用户审查规范？" -> "编写设计文档" [label="要求更改"];
-    "用户审查规范？" -> "调用 writing-plans 技能" [label="已批准"];
-}
-```
-
-**最终状态是调用 writing-plans。** 不要调用 frontend-design、mcp-builder 或任何其他实现技能。头脑风暴后你唯一应该调用的技能是 writing-plans。
-
-## 流程说明
-
-**理解想法：**
-
-- 首先检查当前项目状态（文件、文档、最近的提交）
-- 在提出详细问题之前，评估范围：如果请求描述了多个独立子系统（例如，"构建一个包含聊天、文件存储、计费和分析的平台"），立即标记这一点。不要在需要先分解的项目上花费时间完善细节。
-- 如果项目太大，无法用单个规范覆盖，帮助用户分解为子项目：独立部分是什么，它们如何关联，应该按什么顺序构建？然后通过正常的设计流程对第一个子项目进行头脑风暴。每个子项目都有自己的规范 → 计划 → 实现周期。
-- 对于范围适当的项目，一次一个问题地完善想法
-- 尽可能使用多项选择题，但开放式问题也可以
-- 每条消息只提一个问题 - 如果一个主题需要更多探索，将其分解为多个问题
-- 关注理解：目的、约束、成功标准
-
-**探索方法：**
-
-- 提出2-3种不同的方法，包括权衡
-- 以对话方式展示选项，包括你的建议和理由
-- 先提出你推荐的选项并解释原因
-
-**展示设计：**
-
-- 一旦你认为理解了要构建的内容，就展示设计
-- 根据复杂度调整每个部分：如果简单，几句话就够了；如果复杂，最多200-300字
-- 每部分后询问是否看起来正确
-- 涵盖：架构、组件、数据流、错误处理、测试
-- 准备在有不明白的地方回头澄清
-
-**设计隔离和清晰度：**
-
-- 将系统分解为更小的单元，每个单元有一个明确的目的，通过定义良好的接口进行通信，并且可以独立理解和测试
-- 对于每个单元，你应该能够回答：它做什么，如何使用它，它依赖什么？
-- 有人能在不阅读内部代码的情况下理解一个单元的作用吗？你能在不破坏消费者的情况下更改内部代码吗？如果不能，边界需要改进。
-- 更小、边界明确的单元也更容易使用 - 你对能一次保持在上下文中的代码推理得更好，当文件集中时，你的编辑更可靠。当文件变大时，这通常是它做得太多的信号。
-
-**在现有代码库中工作：**
-
-- 在提出更改之前探索当前结构。遵循现有模式。
-- 在现有代码存在影响工作的问题的地方（例如，文件变得太大、边界不明确、职责混乱），将有针对性的改进作为设计的一部分 - 就像优秀的开发人员改进他们正在工作的代码一样。
-- 不要提出无关的重构。保持专注于服务当前目标的内容。
-
-## 设计之后
-
-**文档：**
-
-- 将验证后的设计（规范）写入 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`
-  - （用户对规范位置的偏好覆盖此默认值）
-- 如果可用，使用 elements-of-style:writing-clearly-and-concisely 技能
-- 将设计文档提交到 git
-
-**规范审查循环：**
-编写规范文档后：
-
-1. 调度 spec-document-reviewer 子代理（参见 spec-document-reviewer-prompt.md）
-2. 如果发现问题：修复，重新调度，重复直到批准
-3. 如果循环超过3次迭代，提交给人类指导
-
-**用户审查关卡：**
-规范审查循环通过后，请用户在继续之前审查书面规范：
-
-> "规范已编写并提交到 `<path>`。请审查它，并让我知道在我们开始编写实现计划之前是否要进行任何更改。"
-
-等待用户的响应。如果他们要求更改，进行更改并重新运行规范审查循环。只有在用户批准后才能继续。
-
-**实现：**
-
-- 调用 writing-plans 技能创建详细的实现计划
-- 不要调用任何其他技能。writing-plans 是下一步。
-
-## 关键原则
-
-- **一次一个问题** - 不要用多个问题压倒用户
-- **首选多项选择题** - 在可能的情况下比开放式问题更容易回答
-- **严格遵循 YAGNI** - 从所有设计中删除不必要的功能
-- **探索替代方案** - 在确定之前始终提出2-3种方法
-- **增量验证** - 展示设计，在继续之前获得批准
-- **保持灵活** - 当有不明白的地方时回头澄清
-
-## 视觉 Companion
-
-一个基于浏览器的 companion，用于在头脑风暴期间显示模型、图表和视觉选项。作为工具提供 - 不是模式。接受 companion 意味着它可用于受益于视觉处理的问题；这并不意味着每个问题都通过浏览器进行。
-
-**提供 companion：** 当你预计即将提出的问题将涉及视觉内容（模型、布局、图表）时，一次提出请求获得同意：
-> "我们正在处理的一些内容可能更容易在网页浏览器中向您展示。我可以在我们进行过程中准备模型、图表、比较和其他视觉内容。此功能仍处于新状态，可能会消耗较多 tokens。想尝试一下吗？（需要打开本地 URL）"
-
-**此提议必须是单独的消息。** 不要将其与澄清问题、上下文摘要或任何其他内容结合。消息应只包含上述提议，别无其他。在继续之前等待用户的响应。如果他们拒绝，继续使用纯文本头脑风暴。
-
-**每个问题的决定：** 即使在用户接受后，也要为每个问题决定是使用浏览器还是终端。测试：**用户通过查看是否比阅读更能理解这一点？**
-
-- **使用浏览器** 处理视觉内容 - 模型、线框图、布局比较、架构图表、并排视觉设计
-- **使用终端** 处理文本内容 - 需求问题、概念选择、权衡列表、A/B/C/D 文本选项、范围决策
-
-关于 UI 主题的问题并不自动成为视觉问题。"在这种情况下，个性意味着什么？"是一个概念性问题 - 使用终端。"哪种向导布局更好？"是一个视觉问题 - 使用浏览器。
-
-如果他们同意使用 companion，请在继续之前阅读详细指南：
-`skills/brainstorming/visual-companion.md`

package/skills/requirement-analysis/competitive-brief/SKILL.md

@@ -1,121 +0,0 @@
-【claude code调用标识：competitive-brief】【trae调用标识：competitive-brief+竞品简报】【流程场景：2.从零开始新项目】
-
----
-name: competitive-brief
-description: Create concise competitive briefs that summarize competitor analysis, market positioning, and strategic insights for quick decision making.
----
-
-# Competitive Brief
-
-## 描述
-创建简洁的竞争简报，总结竞品分析、市场定位和战略洞察，支持快速决策。
-
-## 使用场景
-使用此技能当：
-- 需要快速了解竞争对手概况
-- 准备产品战略会议材料
-- 评估市场机会和威胁
-- 用户要求"做竞品简报"、"竞争分析"或"竞品对比"
-
-## 指令
-
-### Phase 1: 收集竞品信息
-- 识别主要竞争对手
-- 收集竞品的产品、定价、市场策略信息
-- 了解竞品的优势和劣势
-
-### Phase 2: 分析对比
-- 对比竞品与自身产品的差异
-- 识别市场空白和机会
-- 评估竞争威胁
-
-### Phase 3: 生成简报
-- 整理关键发现
-- 提出战略建议
-- 形成简洁的竞争简报
-
-## 竞争简报架构
-
-### 1. 竞品概览
-- 竞品名称和定位
-- 核心产品/服务
-- 目标市场
-
-### 2. 产品对比
-- 核心功能对比
-- 技术特点
-- 用户体验评价
-
-### 3. 市场策略
-- 定价策略
-- 营销渠道
-- 市场份额
-
-### 4. SWOT分析
-- 优势（Strengths）
-- 劣势（Weaknesses）
-- 机会（Opportunities）
-- 威胁（Threats）
-
-### 5. 战略建议
-- 差异化策略
-- 竞争应对措施
-- 市场机会
-
-## 质量标准
-
-### 信息准确性
-- 确保数据来源可靠
-- 最新的市场信息
-- 客观中立的分析
-
-### 简报简洁性
-- 突出重点，避免冗长
-- 使用图表和对比表
-- 结论清晰明确
-
-### 建议可行性
-- 建议具体可执行
-- 考虑资源和时间约束
-- 有明确的行动步骤
-
-## 示例：导航应用竞争简报
-
-### 1. 竞品概览
-| 竞品 | 定位 | 核心产品 |
-|------|------|----------|
-| 高德地图 | 综合地图服务 | 导航、POI搜索、实时路况 |
-| 百度地图 | 智能地图服务 | AI导航、AR实景 |
-| 美团导航 | 外卖专用导航 | 骑手路线规划 |
-
-### 2. 产品对比
-- 核心功能：实时导航、POI搜索、语音交互
-- 差异化功能：骑手专属路线、实时订单集成
-
-### 3. 市场策略
-- 定价：免费+增值服务
-- 渠道：应用商店、骑手端集成
-- 份额：高德约40%，百度约30%
-
-### 4. SWOT分析
-- **优势**：骑手专属功能、订单联动
-- **劣势**：用户基数小、功能单一
-- **机会**：骑手市场增长、专业化需求
-- **威胁**：巨头竞争、政策变化
-
-### 5. 战略建议
-- 专注骑手细分市场
-- 强化语音导航和实时路况
-- 与外卖平台深度合作
-
-## 实施指南
-
-**DO（始终）**
-- 保持简报简洁，一页纸原则
-- 使用对比表格和图表
-- 提供可操作的建议
-
-**DON'T（避免）**
-- 信息过载，重点不突出
-- 主观评价，缺乏数据支持
-- 建议过于笼统，无法执行

package/skills/requirement-analysis/market-research/SKILL.md

@@ -1,143 +0,0 @@
-【claude code调用标识：market-research】【trae调用标识：market-research+市场调研】【流程场景：2.从零开始新项目】
-
----
-name: market-research
-description: Conduct comprehensive market research including competitor analysis, target audience analysis, market trends, and industry insights.
----
-
-# Market Research
-
-## 描述
-进行全面的市场研究，包括竞品分析、目标用户分析、市场趋势和行业洞察。帮助产品团队做出数据驱动的决策。
-
-## 使用场景
-使用此技能当：
-- 启动新产品或进入新市场前需要了解竞争格局
-- 需要分析目标用户群体特征和需求
-- 了解行业趋势和市场机会
-- 用户要求"做市场调研"、"竞品分析"、"用户分析"或"市场分析"
-
-## 指令
-
-### Phase 1: 明确研究目标
-首先明确研究的核心目标：
-- 研究范围：产品/服务类型、目标市场、地域范围
-- 研究目的：了解竞争、发现机会、用户洞察等
-- 关键问题：需要回答哪些核心问题
-
-### Phase 2: 竞品分析
-收集并分析主要竞争对手信息：
-- 识别直接和间接竞争对手
-- 分析竞品的产品功能、定价策略、市场定位
-- 评估竞品的优势和劣势
-- 识别市场空白和机会
-
-### Phase 3: 用户分析
-深入了解目标用户：
-- 用户画像：年龄、性别、地域、收入、职业等
-- 用户需求：痛点、期望、使用场景
-- 用户行为：消费习惯、决策因素、渠道偏好
-
-### Phase 4: 市场趋势分析
-分析市场动态和趋势：
-- 市场规模和增长率
-- 技术发展趋势
-- 政策法规变化
-- 消费者行为变化
-
-### Phase 5: 输出研究报告
-综合所有信息，生成结构化的市场研究报告。
-
-## 市场研究报告架构
-
-### 1. 执行摘要
-- 研究背景和目的
-- 核心发现总结
-- 关键建议
-
-### 2. 市场概述
-- 市场定义和范围
-- 市场规模和增长预测
-- 市场驱动因素
-
-### 3. 竞品分析
-- 主要竞品列表
-- 竞品对比矩阵（功能、价格、市场份额）
-- SWOT分析
-
-### 4. 用户分析
-- 用户画像描述
-- 用户需求分析
-- 购买决策因素
-
-### 5. 市场趋势
-- 技术趋势
-- 消费者趋势
-- 行业挑战和机遇
-
-### 6. 战略建议
-- 市场进入策略
-- 差异化定位建议
-- 产品发展方向
-
-## 质量标准
-
-### 数据来源
-- 优先使用权威数据来源
-- 注明数据来源和时间
-- 交叉验证信息准确性
-
-### 分析深度
-- 避免表面描述，提供深入洞察
-- 使用数据支持结论
-- 识别潜在风险和机会
-
-### 报告结构
-- 逻辑清晰，层次分明
-- 使用图表辅助理解
-- 结论明确，建议可行
-
-## 示例：外卖导航应用市场研究
-
-### 1. 执行摘要
-**背景**：为外卖骑手设计的导航应用市场分析
-**核心发现**：骑手导航市场增长迅速，用户对实时路况和语音导航需求强烈
-**建议**：聚焦语音交互和实时路况功能
-
-### 2. 市场概述
-- 市场规模：预计2025年达XX亿元
-- 年增长率：XX%
-- 主要玩家：高德地图、百度地图、美团导航
-
-### 3. 竞品分析
-| 竞品 | 优势 | 劣势 |
-|------|------|------|
-| 高德地图 | 覆盖广、POI全 | 骑手功能不够专业 |
-| 美团导航 | 深度整合外卖业务 | 通用性不足 |
-
-### 4. 用户分析
-- 年龄：20-40岁为主
-- 核心需求：精准路线、实时路况、语音导航
-- 痛点：地图更新不及时、路线规划不合理
-
-### 5. 市场趋势
-- 实时导航需求增长
-- AI语音交互成为标配
-- 轻量化应用更受欢迎
-
-### 6. 战略建议
-- 专注骑手细分市场
-- 强化语音导航功能
-- 优化路线算法
-
-## 实施指南
-
-**DO（始终）**
-- 多渠道收集信息
-- 保持客观中立
-- 提供具体可操作的建议
-
-**DON'T（避免）**
-- 主观臆断，缺乏数据支持
-- 忽略潜在风险
-- 报告过于冗长，重点不突出

package/skills/requirement-analysis/prd-write/SKILL.md

@@ -1,111 +0,0 @@
-【claude code调用标识：prd-write】【trae调用标识：prd-write+PRD编写】【流程场景：1.完整3阶段SDD流程、2.从零开始新项目】
-
----
-name: prd-write
-description: Generate comprehensive Product Requirements Documents (PRDs) for software products and features. Includes executive summaries, user stories, technical specifications, and risk analysis.
----
-
-# PRD Writer
-
-## 描述
-生成高质量的产品需求文档（PRD），帮助将业务愿景转化为技术执行规范。覆盖从问题定义到实施方案的完整流程。
-
-## 使用场景
-使用此技能当：
-- 启动新产品或功能开发周期
-- 将模糊的想法转化为具体的技术规范
-- 为AI驱动的功能定义需求
-- 利益相关者需要项目范围的统一"事实来源"
-- 用户要求"写PRD"、"记录需求"或"规划功能"
-
-## 指令
-
-### Phase 1: 发现阶段（访谈）
-在编写PRD之前，必须询问用户以填补知识空白。不要假设上下文。
-询问：
-- 核心问题：我们为什么现在要构建这个？
-- 成功指标：我们如何知道它有效？
-- 约束条件：预算、技术栈或截止日期？
-- 提议的解决方案：1-2句话描述解决方案。
-- 成功标准：3-5个可衡量的KPI。
-
-### Phase 2: 分析与范围界定
-综合用户输入，识别依赖关系和隐藏的复杂性。
-- 绘制用户流程图
-- 定义非目标以保护时间表
-
-### Phase 3: 技术起草
-使用严格的PRD架构生成文档。
-
-## PRD 质量标准
-
-### 需求质量
-使用具体、可衡量的标准。避免"快速"、"容易"或"直观"。
-
-**模糊（错误）**
-- 搜索应该快速并返回相关结果。
-- UI必须看起来现代且易于使用。
-
-**具体（正确）**
-- 搜索必须在200ms内返回10k记录数据集的结果。
-- 搜索算法必须在基准评估中达到>=85%的Precision@10。
-- UI必须遵循设计系统并达到100%的Lighthouse可访问性分数。
-
-### 严格PRD架构
-必须遵循此确切结构输出：
-
-1. **执行摘要**
-   - 问题陈述：1-2句话描述痛点
-   - 提议解决方案：1-2句话描述修复方案
-   - 成功标准：3-5个可衡量的KPI
-
-2. **用户体验与功能**
-   - 用户角色：这是为谁设计的？
-   - 用户故事：作为[用户]，我想[行动]以便[收益]
-   - 验收标准：每个故事的"完成"定义的项目符号列表
-   - 非目标：我们不构建什么？
-
-3. **AI系统需求（如适用）**
-   - 工具需求：需要什么工具和API？
-   - 评估策略：如何衡量输出质量和准确性
-
-4. **技术规格**
-   - 架构概述：数据流和组件交互
-   - 集成点：API、数据库和认证
-   - 安全与隐私：数据处理和合规性
-
-5. **风险与路线图**
-   - 分阶段推出：MVP -> v1.1 -> v2.0
-   - 技术风险：延迟、成本或依赖失败
-
-## 实施指南
-
-**DO（始终）**
-- 定义测试：对于AI系统，指定如何测试和验证输出质量
-- 迭代：呈现草稿并就特定部分征求反馈
-
-**DON'T（避免）**
-- 跳过发现：在至少询问2个澄清问题之前，切勿编写PRD
-- 虚构约束：如果用户未指定技术栈，请询问或标记为TBD
-
-## 示例：智能搜索系统
-
-### 1. 执行摘要
-**问题**：用户难以在大型仓库中找到特定的文档片段。
-**解决方案**：一个智能搜索系统，提供带有来源引用的直接答案。
-**成功**：
-- 将搜索时间减少50%
-- 引用准确性>=95%
-
-### 2. 用户故事
-**故事**：作为开发人员，我想提出自然语言问题，这样我不必猜测关键词。
-**验收标准**：
-- 支持多轮澄清
-- 返回带有"复制"按钮的代码块
-
-### 3. AI系统架构
-**所需工具**：codesearch, grep, webfetch
-
-### 4. 评估
-**基准**：用50个常见开发人员问题测试
-**通过率**：90%必须匹配预期引用

package/skills/requirement-analysis/requirement-completion-officer/SKILL.md

@@ -1,124 +0,0 @@
-【claude code调用标识：需求补全】【trae调用标识：需求补全+需求分析】【流程场景：1.完整3阶段SDD流程、2.从零开始新项目、3.小型功能迭代】
-
----
-name: 需求补全
-description: Analyzes user requirements, identifies missing information, and asks core questions to complete the requirements. Invoke when user presents a new project or feature request that needs clarification.
----
-
-# 需求补全官
-
-## 核心功能
-
-本技能用于分析用户提出的需求，识别其中缺失的关键信息，并按优先级提出最核心的问题，帮助用户补全需求，为后续的方案设计和实现提供清晰的指导。
-
-## 执行规则
-
-1. **禁止立刻给方案**：当用户提出需求时，首先进行分析，不直接提供解决方案
-2. **识别缺失信息**：判断需求中缺失的关键信息
-3. **优先级提问**：按优先级只问最核心的3-7个问题，不冗余
-4. **主动补全维度**：重点覆盖以下维度：
-   - 核心目标
-   - 服务对象
-   - 使用场景与约束
-   - 输入与输出要求
-   - 成功验收标准
-   - 时间/预算限制
-   - 技术/资源限制
-   - 风险边界与必选/可选要求
-5. **结构化梳理**：若需求模糊，先结构化梳理为：
-   - 目标
-   - 已知条件
-   - 缺失信息
-   - 建议补充项
-6. **信息完整后再输出方案**：确保信息完整后，再输出正式方案
-7. **不擅自补设定**：不确定的信息直接询问用户
-8. **输出风格**：短、直接、结构化
-
-## 使用流程
-
-1. **接收需求**：用户提出新的项目或功能需求
-2. **初步分析**：快速浏览需求，判断是否清晰完整
-3. **结构化梳理**：将需求拆解为目标、已知条件、缺失信息和建议补充项
-4. **优先级提问**：针对缺失信息，按重要性提出3-7个核心问题
-5. **收集反馈**：等待用户回答问题
-6. **信息整合**：根据用户反馈，整合完整的需求信息
-7. **方案输出**：信息完整后，输出正式的解决方案
-
-## 应用场景
-
-- 产品经理提出新功能需求
-- 开发人员需要明确项目范围
-- 设计师需要了解设计约束
-- 项目管理者需要确定项目边界
-
-## 输出格式示例
-
-### 需求分析
-
-**目标**：
-- [用户提出的核心目标]
-
-**已知条件**：
-- [已明确的需求信息]
-
-**缺失信息**：
-- [需要补充的关键信息]
-
-**建议补充项**：
-- [建议用户提供的额外信息]
-
-### 核心问题
-
-1. [问题1]
-2. [问题2]
-3. [问题3]
-4. [问题4]
-5. [问题5]
-
-## 注意事项
-
-- 保持客观中立，不偏向任何特定解决方案
-- 聚焦于需求本身，不深入技术实现细节
-- 尊重用户的专业知识，避免提出过于基础的问题
-- 及时调整问题优先级，根据用户反馈动态调整分析方向
-- 确保所有问题都与需求的核心目标相关
-
-## 示例
-
-### 输入
-用户："我需要一个电商APP的购物车功能"
-
-### 输出
-
-**需求分析**
-
-**目标**：
-- 实现电商APP的购物车功能
-
-**已知条件**：
-- 应用类型：电商APP
-- 功能模块：购物车
-
-**缺失信息**：
-- 核心目标：购物车的具体功能需求和业务逻辑
-- 服务对象：目标用户群体
-- 使用场景：用户如何添加、管理和结算商品
-- 输入与输出：商品添加方式和结算流程
-- 成功验收标准：功能验证方法
-- 技术/资源限制：技术栈和开发资源
-- 风险边界：异常处理和边界情况
-
-**建议补充项**：
-- 与其他模块的集成需求
-- 性能要求和响应时间
-- 安全考虑和数据保护
-
-**核心问题**
-
-1. 购物车需要支持哪些核心功能？（如添加商品、修改数量、删除商品、优惠券使用等）
-2. 目标用户群体是什么？（如普通消费者、企业用户等）
-3. 购物车的使用场景有哪些？（如移动端、PC端、不同网络环境等）
-4. 购物车与结算流程的集成方式是什么？
-5. 有哪些技术栈和开发资源限制？
-6. 性能要求是什么？（如响应时间、并发处理能力等）
-7. 有哪些安全和数据保护要求？