backlog-update

Feature 建议流程

0. 参数解析

从用户指令中提取以下信息（若不明确，按默认处理）：

• 分析维度：可选 ux（用户体验）、security（安全性）、performance（延迟/性能）、stability（稳定性）、features（新功能）、all（全部，默认值）
• 项目路径：当前工作目录（默认）

1. 项目全景调查

必须先全面理解项目，再提出任何建议。 从零开始阅读，不依赖任何先验知识。

1.1 文档阅读（按顺序）

依次完整阅读以下文件（若存在）：

1. README.md — 项目简介、使用方式、功能列表
2. DESIGN.md — 架构设计、技术栈、接口定义、Change Log
3. PRD.md / requirements.md — 产品需求文档
4. backlog.md / TODO.md — 现有功能 backlog 和待办
5. CLAUDE.md / .cursorrules / .clinerules — 项目开发规范

记录关键信息：项目目标、技术栈、架构模式、已有功能列表、已知问题。

1.2 代码结构扫描

扫描项目代码结构，理解实现全貌：

# 文件结构概览
find . -type f \( -name "*.js" -o -name "*.ts" -o -name "*.jsx" -o -name "*.tsx" \
  -o -name "*.py" -o -name "*.go" -o -name "*.rs" -o -name "*.vue" -o -name "*.svelte" \
  -o -name "*.html" -o -name "*.css" -o -name "*.scss" \) \
  ! -path "*/node_modules/*" ! -path "*/.git/*" ! -path "*/dist/*" ! -path "*/build/*" \
  | head -80

重点关注：

• 入口文件：main.js / index.js / App.tsx 等
• UI 文件：HTML 模板、组件文件、样式文件
• API/路由：服务端路由、API 封装
• 配置文件：package.json、vite.config、webpack.config 等
• 测试文件：测试覆盖情况

1.3 UI/UX 结构分析（如项目有前端）

深入阅读 UI 相关文件，绘制页面结构图：

• 页面分为哪些区域/面板
• 有多少输入框、表单、按钮
• 有多少独立的聊天/对话区域
• 信息层级关系（哪些是主流程、哪些是辅助功能）
• 响应式布局策略

1.4 现有问题收集

从以下渠道收集已知问题：

• DESIGN.md 的 Change Log 中反复出现的问题模式
• backlog.md 中标记为 [ ] 的未完成项
• 代码中的 TODO、FIXME、HACK 注释
• 测试文件中的 skip、xit 标记

2. 多维度分析

根据用户指定的维度（默认全部），从以下角度系统性分析并产出建议：

2.1 用户体验（UX）

分析清单：

• 信息架构：页面结构是否清晰？功能分组是否合理？是否存在重复或冗余的区域？
• 输入简化：是否有多个类似的输入框可以合并？表单是否可以智能默认减少用户决策？
• 视觉层次：主次是否分明？核心操作是否突出？次要功能是否适当隐藏？
• 操作流线：完成一个核心任务需要多少步？是否有不必要的跳转或确认？
• 反馈及时性：操作后是否有即时反馈？加载状态、成功/失败提示是否清晰？
• 认知负担：用户需要记住多少东西？术语是否易懂？新手能否自助上手？
• 一致性：同类操作的交互方式是否统一？样式、按钮、提示是否一致？

2.2 安全性（Security）

分析清单：

• 凭证管理：API Key / Token 是否明文存储或传输？加密方案是否可靠？
• 输入校验：用户输入是否经过 sanitize？是否存在注入风险（XSS / SQL / 命令注入）？
• 依赖安全：是否有已知漏洞的依赖？是否锁定了版本？
• 权限控制：最小权限原则？敏感操作是否有确认步骤？
• 数据泄露：日志/错误信息是否可能泄露敏感数据？前端是否暴露了后端实现细节？
• HTTPS / CORS：生产环境是否强制 HTTPS？CORS 配置是否过于宽松？

2.3 延迟与性能（Performance）

分析清单：

• 首屏加载：初始加载是否需要等待所有资源？是否可以懒加载？
• API 调用：是否有冗余请求？是否可以合并/缓存？超时处理是否合理？
• 流式响应：SSE/WebSocket 使用是否高效？是否有不必要的缓冲？
• 渲染性能：大量 DOM 操作是否使用了虚拟滚动或批量更新？
• 内存管理：是否有事件监听器泄漏？大对象是否及时释放？
• 构建优化：bundle size 是否合理？是否使用了 tree-shaking？

2.4 稳定性（Stability）

分析清单：

• 错误处理：API 调用失败、网络断开、超时等场景是否有优雅降级？
• 状态管理：应用状态是否有竞态条件？并发操作是否安全？
• 边界情况：空输入、超长输入、特殊字符、断网等场景是否处理？
• 恢复能力：崩溃后能否恢复到之前状态？是否有自动保存机制？
• 测试覆盖：关键路径是否有测试？测试是否稳定（非 flaky）？

2.5 新功能（Features）

分析清单：

• 用户需求：现有功能是否完整覆盖了核心场景？是否有明显的功能缺口？
• 效率提升：是否有重复性操作可以自动化？
• 集成能力：是否可以与其他工具/服务集成以提升价值？
• 数据洞察：是否可以增加统计、分析、导出等功能？
• 可扩展性：架构是否支持插件化、配置化扩展？

3. 建议产出

3.1 格式要求

按以下格式输出建议列表，每个建议必须包含：编号、维度标签、标题、问题描述、建议方案、优先级、预估改动量。

## Feature 建议报告

### 项目概况
- 项目名：xxx
- 技术栈：xxx
- 核心功能：xxx
- 当前状态：已有 N 个功能，M 个待完成

---

### P0 — 关键（影响核心体验或存在安全风险）

#### F1. [UX] 合并重复的聊天输入框
- **问题**：页面有 6 个独立的聊天区域，每个都有自己的输入框和发送按钮，
  用户需要在不同区域之间跳转，认知负担重
- **建议**：将所有聊天交互统一为一个全局输入框，根据当前上下文自动路由
  到对应的 AI agent
- **改动量**：中（~200 行前端代码）
- **影响范围**：index.html、main.js

#### F2. [Security] API Key 存储方案需加固
- **问题**：...
- **建议**：...
- **改动量**：小（~50 行）
- **影响范围**：...

### P1 — 重要（显著提升体验或解决痛点）

#### F3. [Performance] ...
...

### P2 — 有益（锦上添花，可后续迭代）

#### F4. [Features] ...
...

### P3 — 可选（长远考虑，当前不紧迫）

#### F5. [Stability] ...
...

3.2 优先级定义

3.3 质量要求

• 每个建议必须有具体的代码/文件引用，不能泛泛而谈
• 问题描述必须从用户视角出发，说明"用户会遇到什么"
• 建议方案必须可操作，不能只说"优化一下"
• 改动量评估必须诚实，不要低估复杂度
• 至少覆盖 3 个维度，不能只关注一个方面
• 建议总数 5~15 条，太少说明分析不够深入，太多说明缺乏聚焦

4. 讨论与确认

将建议报告展示给用户后，逐条讨论：

1. 展示完整报告，让用户通读一遍
2. 询问用户意见：
   • 哪些建议认同？想现在就做？
   • 哪些建议不认同或暂不需要？
   • 有没有遗漏的角度？
   • 优先级排序是否合理？
3. 根据反馈调整：
   • 用户不认同的 → 移除
   • 用户想调整优先级的 → 重新排序
   • 用户补充的新想法 → 追加
   • 用户想拆分/合并的 → 调整粒度

5. 加入 Backlog

用户确认最终列表后，将 agreed 的建议写入项目的 backlog.md（若不存在则创建）：

5.1 Backlog 格式

## X. [维度] Feature 建议名称

**问题**: [从用户视角描述的问题]
**改动范围**:
- `path/to/file1.js`: [具体改动描述]
- `path/to/file2.html`: [具体改动描述]
**验证方式**:
1. [具体可执行的验证步骤]
2. [预期结果]

5.2 写入规则

• 按优先级顺序追加到 backlog.md
• 每个建议作为独立的 backlog 条目（### 标题级别）
• 状态标记为 [ ]（未完成）
• 如果 backlog.md 已有类似条目，合并而非重复添加
• 如果建议涉及已有 backlog 条目的改进，在原条目中追加说明

5.3 确认输出

写入完成后，输出：

✅ Feature 建议已写入 backlog.md — 共 N 条（P0: x, P1: y, P2: z）

6. 注意事项

• 这是通用 skill，适用于任何项目，不假设特定技术栈或框架
• 不主动修改代码，只做分析和建议，代码改动由用户决定
• 尊重项目既有架构，建议应与现有技术栈和设计风格一致
• 务实导向，不追求完美方案，而是当前阶段最值得投入的改进
• 如果项目太小或太简单（如只有几个文件），建议范围也会相应缩小，不强行凑数
• 对于已有完善 backlog 的项目，重点补充 backlog 中未覆盖的角度，而非重复已有内容