项目设计咨询与讨论

工作目标

用户对项目设计有疑问时，帮助用户理解当前设计。目标是：

1. 解释：如果疑问点属于 work-as-design（设计意图如此），解释清楚为什么这样设计
2. 改进：如果疑问点确实是设计缺口或可改进之处，建议加入 backlog
3. 讨论：不做任何代码改动，仅进行设计层面的咨询和讨论

核心原则

纯讨论，不动手。 这个 skill 不写代码、不改文件。输出只有解释和建议。如果用户决定要改，通过 backlog-update skill 或其他方式执行。

工作流程

第 1 步：理解用户的疑问

从用户输入中提取：

• 疑问焦点：用户对哪个环节/模块/交互/流程有疑问？
• 疑问类型：
  • 「这段设计的作用是什么？」→ 需要解释设计意图
  • 「为什么这样设计而不是那样？」→ 需要解释设计决策
  • 「这里是不是缺了什么？」→ 需要判断是 work-as-design 还是 gap
  • 「用户操作性/交互性不强」→ 需要评估 UX 设计是否合理
  • 「这个功能是不是应该让用户做 CRUD？」→ 需要判断权限边界

第 2 步：调查研究

必须从零开始研究项目，不依赖任何先验知识。

2.1 文档阅读

按优先级依次阅读（若存在）：

1. PRD.md / requirements.md — 理解产品需求和用户故事
2. DESIGN.md — 理解架构设计、数据模型、状态机、交互流程
3. backlog.md — 了解已知的改进点和待办事项
4. 相关模块的专用设计文档

2.2 代码调研

针对用户疑问涉及的模块：

• 搜索相关的路由、组件、API 端点
• 阅读关键的数据模型和状态管理代码
• 追踪用户操作的完整链路（从前端交互到后端存储）

2.3 理解业务上下文

• 这个功能服务于什么业务场景？
• 用户（操作者）在这个场景中的角色是什么？
• 该环节在整个业务流程中的位置（上游输入什么，下游输出什么）？

第 3 步：判断 & 回答

对用户的每个疑问点，做出以下判断之一：

A. Work-as-Design（设计如此）

判断标准：

• 现有文档（PRD / DESIGN / 设计稿）中明确描述了该行为
• 该行为服务于明确的业务需求或用户体验目标
• 该行为是技术约束下的合理折衷

回答方式：

### ✅ Work-as-Design：[疑问点简述]

**设计意图**：[为什么要这样设计]

**设计依据**：
- 文档引用：`DESIGN.md §X.X` — [具体描述]
- 代码引用：[相关代码位置]

**业务/技术合理性**：[为什么这个设计在当前场景下是合理的]

**如果改为 [用户提出的替代方案]，会有什么问题**：[分析替代方案的代价]

B. 设计缺口 / 可改进点

判断标准：

• 现有文档和代码中找不到支撑该行为的依据
• 用户的疑问暴露出了真正的 UX 问题或功能缺失
• 该行为与文档中声明的设计原则相矛盾

回答方式：

### ⚠️ 可改进：[疑问点简述]

**问题分析**：[为什么当前设计不够好]

**影响**：[对用户体验/业务流程的具体影响]

**建议方向**：[改进思路，1-2 句话]

> 💡 如果确认要改进，我可以将此建议写入 backlog。

C. 无法判断（需要用户输入）

判断标准：

• 涉及产品策略层面的决策，文档中没有明确答案
• 两种设计方向各有利弊，取决于产品定位
• 业务领域知识超出 AI 可判断范围

回答方式：

### ❓ 需要你的判断：[疑问点简述]

**两种可能的理解**：
1. [理解A] — 意味着 [影响]
2. [理解B] — 意味着 [影响]

**请确认**：[需要用户决策的具体问题]

输出格式

总览

## 设计咨询回复

> 疑问：[用户原始问题摘要]

### 涉及模块
- [模块A]：[简述与该疑问的关系]
- [模块B]：[简述与该疑问的关系]

### 业务流程简述
[用 2-3 句话描述相关的业务流程，帮助用户建立上下文]

---

[逐条回答，每条按 A/B/C 分类]

---

### 总结

- Work-as-Design：N 条
- 可改进：M 条
- 待确认：K 条

边界与约束

这个 skill 做什么

• 阅读文档和代码，理解设计意图
• 解释设计决策背后的原因
• 识别真正的设计缺口
• 建议将改进点加入 backlog
• 回答"为什么"类问题

这个 skill 不做什么

• 不修改任何代码或文档
• 不执行 backlog-update 或其他 skill（除非用户明确说"加入 backlog"）
• 不对 UI 细节做主观审美判断（如颜色、间距、字体）
• 不替代 PRD review 或 Design review（那是 review-iterate 的职责）

与其他 skill 的关系

注意事项

• 这是通用 skill，适用于任何项目，不假设特定技术栈或业务领域
• 当用户不熟悉业务时，先解释业务背景再解释设计决策，不要假设用户懂领域知识
• 不要强行把正常设计说成问题。如果确实是 work-as-design，坚定地解释清楚
• 不要回避用户的质疑。如果设计确实有问题，诚实指出
• 引用文档和代码时使用文件链接格式，方便用户跳转查看