ethan-skill 1.0.0

package/rules/cursor/.cursorrules

@@ -0,0 +1,747 @@
+# Ethan v1.0.0
+
+> 自动生成 - 请勿手动修改，源文件：src/skills/
+> Generated at: 2026-03-21T14:18:11.636Z
+
+## 触发词一览
+- 需求理解：需求理解、理解需求、分析需求
+- 任务拆解：任务拆解、拆解任务、拆分任务
+- 方案设计：方案设计、技术方案、架构设计
+- 执行实现：执行实现、开始实现、写代码
+- 进度跟踪：进度跟踪、跟踪进度、进度更新
+- 任务报告：任务报告、生成报告、任务总结
+- 周报生成：周报、生成周报、写周报
+- 代码审查：代码审查、code review、CR
+- 故障排查：故障排查、debug、线上故障
+- 技术调研：技术调研、技术选型、POC
+
+---
+
+## Skill 1：需求理解
+
+**触发词**：`需求理解`、`理解需求`、`分析需求`、`需求分析`、`我需要`、`帮我做`、`实现一个`、`开发一个`、`/需求理解`、`@ethan 需求`
+
+**描述**：深度解析用户需求，消除歧义，输出结构化需求文档
+
+### 1. 提取核心诉求
+
+- 用一句话总结用户最终想实现的**业务目标**
+- 区分"功能需求"（要做什么）与"非功能需求"（性能、安全、兼容性等）
+- 识别隐含的技术约束（语言栈、框架版本、部署环境）
+
+### 2. 识别歧义与缺失信息
+
+- 列出所有**不明确**的地方（用 ❓ 标记）
+- 列出**缺失**但必须明确的信息（用 ⚠️ 标记）
+- 最多提出 3 个最关键的澄清问题，避免信息过载
+
+### 3. 假设声明
+
+- 对于无法立即澄清的歧义，明确列出你的**假设前提**
+- 格式：「假设 X，如果实际是 Y，则需要调整 Z」
+
+### 4. 输出结构化需求文档
+
+按以下模板输出：
+
+```markdown
+## 需求理解确认
+
+### 核心目标
+[一句话描述]
+
+### 功能需求
+- [ ] 功能点 1
+- [ ] 功能点 2
+
+### 非功能需求
+- 性能：[描述]
+- 兼容性：[描述]
+
+### 技术约束
+- [约束条件]
+
+### 待澄清问题
+❓ 1. [问题]
+⚠️ 2. [缺失信息]
+
+### 当前假设
+- 假设 [A]，如果实际是 [B]，则 [调整]
+```
+
+**输出格式**：Markdown 结构化文档，包含核心目标、功能需求列表、非功能需求、技术约束、待澄清问题和假设声明
+
+**注意事项**：
+- 不要急于给出解决方案，先确保完全理解需求
+- 澄清问题不超过 3 个，聚焦最关键的
+- 假设声明必须明确，避免隐式假设导致方向偏差
+
+---
+
+## Skill 2：任务拆解
+
+**触发词**：`任务拆解`、`拆解任务`、`拆分任务`、`制定计划`、`任务规划`、`怎么实现`、`实现步骤`、`/任务拆解`、`@ethan 拆解`
+
+**描述**：将复杂需求拆解为可执行的原子任务，建立依赖关系和优先级
+
+### 1. 识别主要模块
+
+- 将需求按**功能域**或**技术层**划分为 3-7 个主要模块
+- 每个模块用一行说明其职责
+- 标注模块类型：[前端 UI] [后端 API] [数据库] [基础设施] [测试]
+
+### 2. 拆解为原子任务
+
+- 每个原子任务满足：**单人、半天内可完成**
+- 任务命名格式：「动词 + 对象 + 可选限定」
+  - ✅ 「实现用户登录 API（POST /auth/login）」
+  - ❌ 「做登录」（太模糊）
+- 标注预估工时：[S=2h] [M=4h] [L=8h] [XL=需再拆]
+
+### 3. 建立依赖关系
+
+- 用 → 表示依赖：「A → B」意为「完成 A 才能开始 B」
+- 识别可以**并行**执行的任务组
+- 找出**关键路径**（决定最短完成时间的任务链）
+
+### 4. 输出任务清单
+
+按以下格式输出：
+
+```markdown
+## 任务拆解
+
+### 模块概览
+| 模块 | 职责 | 预估任务数 |
+|------|------|-----------|
+| [模块名] | [职责] | [数量] |
+
+### 任务列表
+
+#### 阶段一：[阶段名]（可并行）
+- [ ] T01 [任务名] [S/M/L]
+- [ ] T02 [任务名] [S/M/L]
+
+#### 阶段二：[阶段名]（依赖阶段一）
+- [ ] T03 [任务名] [S/M/L] 依赖：T01
+
+### 关键路径
+T01 → T03 → T05（预估总工时：X 天）
+
+### 并行机会
+T02 可与 T01 同时进行
+```
+
+**输出格式**：Markdown 表格 + 任务列表，含模块概览、分阶段任务、依赖关系、关键路径
+
+**注意事项**：
+- 任务粒度宁细勿粗，XL 任务必须继续拆解
+- 优先识别阻塞性任务（其他任务依赖它的），优先排期
+- 第一阶段任务应尽量可并行，提高效率
+
+---
+
+## Skill 3：方案设计
+
+**触发词**：`方案设计`、`技术方案`、`架构设计`、`设计方案`、`怎么设计`、`数据库设计`、`接口设计`、`API 设计`、`/方案设计`、`@ethan 设计`
+
+**描述**：输出技术方案设计文档，包含架构选择、接口设计、数据模型和关键决策说明
+
+### 1. 技术选型
+
+- 列出关键技术决策点（框架、数据库、缓存、消息队列等）
+- 每个决策给出 2-3 个候选方案，并说明**选择理由**
+- 格式：「选择 A 而非 B，原因：[理由]；权衡：[牺牲了什么]」
+
+### 2. 架构设计
+
+- 用 ASCII 图或 Mermaid 描述系统架构
+- 说明各组件的职责和交互方式
+- 标注关键数据流向
+
+```mermaid
+graph LR
+  Client --> API[API Server]
+  API --> DB[(Database)]
+  API --> Cache[(Redis)]
+```
+
+### 3. 接口设计（API）
+
+按 RESTful 或 GraphQL 规范设计接口：
+
+```
+POST /api/v1/[resource]
+Request:  { field1: type, field2: type }
+Response: { code: 0, data: {...}, message: string }
+```
+
+- 统一错误码规范
+- 鉴权方式（Bearer Token / Cookie / API Key）
+
+### 4. 数据模型
+
+- 核心实体及字段（类型、约束、索引）
+- 实体关系（1:1、1:N、N:M）
+- 关键查询场景和对应索引策略
+
+### 5. 关键技术决策记录（ADR）
+
+对每个重要决策记录：
+- **背景**：为什么需要做这个决策
+- **决策**：选择了什么
+- **后果**：带来什么影响（正面/负面）
+
+**输出格式**：Markdown 设计文档，含技术选型表、架构图（Mermaid）、API 接口列表、数据模型、ADR 决策记录
+
+**注意事项**：
+- 先设计接口契约，再实现内部逻辑
+- 数据模型是设计的核心，多花时间在这里
+- ADR 不需要面面俱到，只记录有争议的或重要的决策
+
+---
+
+## Skill 4：执行实现
+
+**触发词**：`执行实现`、`开始实现`、`写代码`、`编写代码`、`实现功能`、`代码实现`、`开始开发`、`/执行实现`、`@ethan 实现`
+
+**描述**：按设计方案逐步实现代码，遵循最佳实践，同步记录实现决策
+
+### 1. 确认实现前提
+
+在开始写代码前确认：
+- ✅ 设计方案已确认
+- ✅ 依赖的接口/服务已就绪（或已 mock）
+- ✅ 开发环境配置正确
+- ✅ 知道本次实现的完成标准（Definition of Done）
+
+### 2. 分层实现顺序
+
+推荐实现顺序（由内而外）：
+1. **数据层**：Model/Schema 定义、数据库迁移
+2. **服务层**：业务逻辑、核心算法
+3. **接口层**：Controller/Route/Resolver
+4. **UI 层**：页面组件、交互逻辑
+5. **集成**：端对端连通、Edge Cases 处理
+
+### 3. 编码规范执行
+
+- 函数单一职责，超过 50 行考虑拆分
+- 命名自文档化：`getUserByEmail` > `getUser`
+- 错误处理：不吞异常，向上传递有语义的错误
+- 对**非显而易见**的逻辑写注释（解释"为什么"而非"做什么"）
+- 涉及安全的操作（SQL 查询、用户输入）必须做参数化/转义
+
+### 4. 每完成一个任务后
+
+- 执行单元测试（或手动验证）
+- 更新任务状态（参考"进度跟踪" Skill）
+- 如遇到设计偏差，记录变更原因
+- commit 前检查：无 console.log 遗留、无硬编码密钥
+
+### 5. 代码自检清单
+
+```
+□ 功能满足需求文档的验收条件
+□ 边界条件已处理（null、空数组、超长输入等）
+□ 错误信息对用户友好（生产环境不暴露内部堆栈）
+□ 无明显性能问题（N+1 查询、无限循环风险）
+□ 敏感数据不出现在日志中
+□ 代码可读性：同事无需解释能看懂
+```
+
+**输出格式**：代码实现 + 简要说明（实现思路、关键决策），每个任务完成后输出自检清单结果
+
+**注意事项**：
+- 不要一次性写完所有代码，小步提交，频繁验证
+- 遇到阻塞（依赖未就绪）立即反馈，不要等待
+- 实现过程中发现设计问题，先暂停讨论，不要随意修改设计
+
+---
+
+## Skill 5：进度跟踪
+
+**触发词**：`进度跟踪`、`跟踪进度`、`进度更新`、`更新进度`、`项目进展`、`任务状态`、`完成了什么`、`还剩什么`、`/进度跟踪`、`@ethan 进度`
+
+**描述**：实时更新任务状态，识别阻塞风险，保持项目透明度
+
+### 1. 状态同步
+
+对任务列表中每个任务标注状态：
+- ✅ **完成**：已验证通过
+- 🔄 **进行中**：正在开发
+- ⏸️ **阻塞**：有依赖未解除或遇到问题
+- ⏳ **待开始**：排队中
+- ❌ **取消**：不再需要（说明原因）
+
+### 2. 阻塞识别与处理
+
+对每个阻塞任务：
+- 描述阻塞原因（技术问题/依赖等待/需求不清晰）
+- 阻塞开始时间
+- 解除条件：「需要 [谁] 完成 [什么]」
+- 影响评估：「阻塞会导致 [哪些任务] 延期 [多少时间]」
+
+### 3. 完成度统计
+
+```
+总任务数：N
+✅ 完成：X（X%）
+🔄 进行中：Y
+⏸️ 阻塞：Z
+⏳ 待开始：W
+
+预估完成时间：[日期] [置信度：高/中/低]
+```
+
+### 4. 风险预警
+
+识别以下风险并标注优先级：
+- 🔴 **高风险**：当前阻塞影响关键路径，必须立即处理
+- 🟡 **中风险**：有延期可能，需要关注
+- 🟢 **低风险**：有 buffer，暂时观察
+
+### 5. 下一步行动
+
+明确列出：
+- **立即行动**（今天必须完成）
+- **需要协调**（需要其他人配合）
+- **待决策**（需要产品/技术负责人决定）
+
+**输出格式**：Markdown 状态看板，含任务状态列表、完成度统计、风险矩阵、下一步行动清单
+
+**注意事项**：
+- 每天至少更新一次进度（即使没有变化也要说明）
+- 阻塞问题第一时间暴露，不要等到 deadline 才说
+- 进度更新要诚实，不要因为"看起来不好"而隐瞒风险
+
+---
+
+## Skill 6：任务报告
+
+**触发词**：`任务报告`、`生成报告`、`任务总结`、`总结报告`、`完成总结`、`项目总结`、`阶段总结`、`/任务报告`、`@ethan 报告`
+
+**描述**：任务完成后生成总结报告，记录成果、问题和经验教训
+
+### 1. 成果汇总
+
+- 列出本次完成的所有功能点（对照原始需求）
+- 说明是否满足所有验收条件
+- 对比原计划：提前/按时/延期（延期说明原因）
+- 关键交付物清单（代码链接、文档、部署地址）
+
+### 2. 问题复盘
+
+对本次遇到的主要问题进行复盘：
+
+| 问题描述 | 根本原因 | 解决方案 | 预防措施 |
+|---------|---------|---------|---------|
+| [问题] | [原因] | [解决] | [预防] |
+
+### 3. 技术债务记录
+
+记录本次故意留下的技术债务（TODO/FIXME）：
+- 债务描述：[内容]
+- 产生原因：[为什么现在不做]
+- 影响范围：[哪些功能受影响]
+- 计划处理时间：[迭代版本]
+
+### 4. 性能与质量指标
+
+- 测试覆盖率：[X%]
+- 已知 Bug：[数量及严重程度]
+- 关键路径性能：[响应时间/吞吐量等]
+- 代码审查意见处理：[X 条，已解决 Y 条]
+
+### 5. 经验教训（Lessons Learned）
+
+**做得好的地方：**
+- [值得在下次继续的做法]
+
+**可以改进的地方：**
+- [下次应该不同的做法]
+
+**给团队的建议：**
+- [可复用的最佳实践或工具]
+
+**输出格式**：Markdown 总结报告，含成果汇总、问题复盘表格、技术债务列表、质量指标、Lessons Learned
+
+**注意事项**：
+- 报告面向不同读者（技术/产品/管理），注意分层表达
+- 技术债务必须记录，不能以"以后再说"带过
+- Lessons Learned 重在行动可操作性，避免空话
+
+---
+
+## Skill 7：周报生成
+
+**触发词**：`周报`、`生成周报`、`写周报`、`周报生成`、`本周总结`、`周总结`、`weekly report`、`/周报`、`@ethan 周报`
+
+**描述**：根据本周工作内容自动生成结构化周报，突出价值而非流水账
+
+### 1. 信息收集
+
+请提供以下信息（可以是碎片化描述，我来整理）：
+- 本周完成了哪些任务/功能？
+- 遇到了什么困难/问题？怎么解决的？
+- 有没有超出预期完成的事情？
+- 下周计划做什么？
+- 有没有需要协调/升级的事项？
+
+### 2. 内容提炼原则
+
+- **结果导向**：描述完成了什么，而非做了什么操作
+  - ❌「修改了登录接口的代码」
+  - ✅「完成登录功能优化，登录响应时间从 800ms 降至 200ms」
+- **量化表达**：能用数字的地方用数字
+- **价值关联**：说明工作对业务的意义
+
+### 3. 输出周报
+
+按以下模板生成：
+
+```markdown
+# 周报 - [日期范围]
+
+## 本周完成
+
+### 主要成果
+1. **[功能/项目名]**：[一句话描述成果和价值]
+2. ...
+
+### 技术攻坚
+- [解决了什么难题，用了什么方案]
+
+## 问题与风险
+- ⚠️ [当前面临的问题或风险，是否需要支持]
+
+## 下周计划
+1. [任务] - [预期完成时间]
+2. ...
+
+## 需要协调
+- [需要其他人/团队配合的事项]
+```
+
+### 4. 多版本适配
+
+根据读者不同，调整详细程度：
+- **团队版**：包含技术细节和具体数字
+- **管理层版**：聚焦业务价值和风险，去掉技术细节
+- **外部同步版**：只保留里程碑级进展
+
+**输出格式**：Markdown 周报文档，含本周成果、技术攻坚、问题风险、下周计划、协调事项
+
+**注意事项**：
+- 周报不是日志，不要列流水账，聚焦有意义的事情
+- 困难和风险要如实汇报，不要只报好消息
+- 下周计划要具体且可追溯，不要写「继续推进 XX」
+
+---
+
+## Skill 8：代码审查
+
+**触发词**：`代码审查`、`code review`、`CR`、`帮我 review`、`帮我看看代码`、`审查代码`、`review 一下`、`代码 review`、`/代码审查`、`@ethan review`
+
+**描述**：系统性审查代码变更，分级输出 Blocker/Major/Minor 问题，提升代码质量
+
+### 1. 理解变更意图
+
+- 阅读 PR 描述或变更说明，明确本次改动的**业务目标**
+- 识别变更范围：新功能 / Bug 修复 / 重构 / 性能优化 / 配置调整
+- 确认是否有对应的需求文档、设计文档或 Issue
+- 了解测试覆盖情况（单测/集成测试）
+
+### 2. 逐层审查
+
+按以下五个维度逐一检查：
+
+**✅ 正确性**
+- 逻辑是否正确，边界条件是否处理（null/undefined/空数组/越界）
+- 并发/异步场景是否有竞态条件
+- 错误处理是否完备
+
+**🔒 安全性**
+- 是否存在 SQL 注入、XSS、CSRF 等 OWASP Top 10 风险
+- 敏感信息（密钥、密码）是否硬编码
+- 权限校验是否完整
+
+**⚡ 性能**
+- 是否有 N+1 查询、不必要的全量加载
+- 循环内是否有重复计算或 DOM 操作
+- 是否缺少必要的缓存或索引
+
+**🔧 可维护性**
+- 函数/类职责是否单一
+- 命名是否清晰表达意图
+- 是否有重复代码（DRY 原则）
+- 复杂逻辑是否有注释说明
+
+**📏 规范性**
+- 是否符合项目代码风格（命名、格式、文件结构）
+- 是否有缺失的测试用例
+- API 变更是否更新了文档
+
+### 3. 按级别分类问题
+
+将发现的问题按以下三级分类：
+
+- 🚫 **Blocker**：必须修复才能合并（功能错误、安全漏洞、数据丢失风险）
+- ⚠️ **Major**：强烈建议修复（性能问题、可维护性严重不足、测试缺失）
+- 💡 **Minor**：建议改进（代码风格、命名优化、注释补充）
+
+每个问题标注：文件名 + 行号 + 问题描述 + 改进建议
+
+### 4. 输出审查报告
+
+按以下格式输出：
+
+```markdown
+## Code Review 报告
+
+### 总体评价
+[1-3 句话概述代码质量和主要问题]
+
+### 🚫 Blocker（必须修复）
+- [ ] `file.ts:42` 未校验用户输入直接拼接 SQL，存在注入风险
+  建议：使用参数化查询
+
+### ⚠️ Major（建议修复）
+- [ ] `service.ts:88` N+1 查询：循环内调用数据库
+  建议：改用批量查询 + Map 映射
+
+### 💡 Minor（可选优化）
+- [ ] `utils.ts:15` 变量名 `d` 含义不清晰
+  建议：改为 `duration`
+
+### ✅ 做得好的地方
+- [值得肯定的设计或实现]
+
+### 总结
+Blocker: X 个 | Major: Y 个 | Minor: Z 个
+```
+
+### 5. 跟进确认
+
+- 如果有 Blocker，明确告知不应合并，等修复后重新 Review
+- 如果只有 Minor，可以 Approve 并备注"建议改进但不阻塞"
+- 对于设计层面的分歧，建议另开会议讨论，不在 PR 中反复拉锯
+
+**输出格式**：Markdown 审查报告，含总体评价、分级问题列表（Blocker/Major/Minor）、亮点肯定和合并建议
+
+**注意事项**：
+- Review 的目的是提升代码质量，不是否定作者，保持建设性语气
+- Blocker 必须明确标注，避免重要问题被忽视
+- 超过 400 行的 PR 建议拆分后分批 Review
+
+---
+
+## Skill 9：故障排查
+
+**触发词**：`故障排查`、`debug`、`线上故障`、`报错了`、`排查问题`、`定位 bug`、`为什么报错`、`程序崩溃`、`/故障排查`、`@ethan debug`
+
+**描述**：系统性排查故障，通过假设验证和 5 Why 定位根因，输出临时/永久/预防三层方案
+
+### 1. 现象描述
+
+用结构化方式描述故障现象：
+
+- **错误信息**：完整的报错信息或日志（不要截断）
+- **影响范围**：哪些用户/请求/功能受影响，影响比例
+- **发生时间**：首次发现时间，是否有规律（特定时间/特定操作触发）
+- **复现步骤**：能否稳定复现？复现率？
+- **环境信息**：生产/测试/本地？最近是否有上线或配置变更？
+
+### 2. 建立假设
+
+根据现象，列出所有可能的原因假设：
+
+- 按**可能性**从高到低排序（先排查最常见的）
+- 每个假设标注**验证方式**（查日志/加断点/查数据库/还原操作）
+- 格式：「假设 [X] 导致，验证方式：[Y]」
+
+常见假设方向：
+- 代码逻辑错误（边界条件、空指针、类型错误）
+- 配置/环境问题（环境变量、连接字符串、版本不兼容）
+- 数据问题（脏数据、数据迁移遗漏、外键约束）
+- 依赖服务故障（数据库、缓存、第三方 API 超时）
+- 资源耗尽（内存溢出、连接池耗尽、磁盘满）
+
+### 3. 逐一验证
+
+按假设列表逐一排查：
+
+- 每个假设用最小代价验证（优先查日志，再加调试代码）
+- 验证结果：✅ 确认 / ❌ 排除 / ❓ 待进一步确认
+- 找到最可能的原因后，**缩小范围**继续深挖
+- 保留所有验证过程（方便写报告和复盘）
+
+排查工具：
+- 日志分析：关键字检索 + 时间范围过滤
+- 数据库：慢查询日志、EXPLAIN 分析
+- 网络：curl 测试接口、抓包分析
+- 内存/CPU：top、heap dump、火焰图
+
+### 4. 5 Why 根因分析
+
+找到直接原因后，用 5 Why 追溯根本原因：
+
+```
+现象：接口超时
+Why 1: 为什么超时？→ 数据库查询慢
+Why 2: 为什么查询慢？→ 缺少索引
+Why 3: 为什么缺索引？→ 上线时未执行迁移脚本
+Why 4: 为什么迁移未执行？→ 发布流程没有自动执行 migration
+Why 5: 为什么没有自动化？→ CI/CD 流程中没有这个步骤
+根因：CI/CD 缺少数据库迁移步骤
+```
+
+连续追问直到找到**可操作的系统性原因**（不是"人的失误"）
+
+### 5. 输出排查报告
+
+按以下格式输出完整报告：
+
+```markdown
+## 故障排查报告
+
+### 故障概述
+- **影响范围**：[描述]
+- **发生时间**：[时间]
+- **根本原因**：[一句话总结]
+
+### 时间线
+- HH:MM 发现异常
+- HH:MM 开始排查
+- HH:MM 定位原因
+- HH:MM 完成修复
+
+### 根因分析（5 Why）
+[5 Why 链条]
+
+### 解决方案
+
+#### 🚑 临时缓解（立即执行）
+- [临时措施，如回滚、降级、重启]
+
+#### 🔧 永久修复（计划排期）
+- [根本性解决方案]
+
+#### 🛡️ 预防措施（长期改进）
+- [流程/监控/测试改进，防止复发]
+
+### 经验教训
+[本次故障暴露的流程/技术缺陷]
+```
+
+**输出格式**：Markdown 排查报告，含故障概述、时间线、5 Why 根因分析、临时缓解/永久修复/预防措施三层方案和经验教训
+
+**注意事项**：
+- 先稳定服务（临时缓解），再追根因，避免长时间故障影响用户
+- 5 Why 要追到系统/流程层面，"人员失误"不是根因
+- 排查过程保留完整记录，方便事后复盘
+
+---
+
+## Skill 10：技术调研
+
+**触发词**：`技术调研`、`技术选型`、`POC`、`对比方案`、`选哪个好`、`方案对比`、`调研一下`、`技术评估`、`/技术调研`、`@ethan 调研`
+
+**描述**：结构化技术选型：问题定义→方案收集→加权评分矩阵→POC 验证→明确结论
+
+### 1. 问题定义
+
+明确调研的边界和目标：
+
+- **核心问题**：用一句话描述要解决什么技术问题
+- **约束条件**：
+  - 技术栈约束（语言、框架、云平台）
+  - 团队约束（学习曲线、现有技能）
+  - 资源约束（成本上限、时间窗口）
+  - 合规约束（开源协议、数据合规）
+- **评估维度**：列出 5-8 个评估标准，并为每个标准分配**权重**（权重之和为 100）
+  - 常用维度：功能完整性、性能、稳定性/成熟度、社区活跃度、学习成本、运维成本、License
+
+### 2. 方案收集
+
+系统收集候选方案：
+
+- 通过文档、GitHub、技术博客、同行推荐收集 **3-5 个**候选方案
+- 每个方案记录：
+  - 官网/仓库链接
+  - 版本/发布日期
+  - Stars/下载量（活跃度指标）
+  - 核心特性概述（3-5 条）
+  - 已知局限性
+- 去掉明显不满足约束条件的方案，保留 2-4 个进入深度对比
+
+### 3. 对比矩阵（加权评分）
+
+用加权评分矩阵量化对比：
+
+- 每个维度打分 1-5（1=很差，5=很好）
+- 加权得分 = Σ（各维度得分 × 权重）
+- 用 Markdown 表格呈现：
+
+```markdown
+| 评估维度 | 权重 | 方案 A | 方案 B | 方案 C |
+|---------|------|--------|--------|--------|
+| 功能完整性 | 30% | 4 (1.2) | 5 (1.5) | 3 (0.9) |
+| 性能 | 25% | 5 (1.25) | 3 (0.75) | 4 (1.0) |
+| 学习成本 | 20% | 3 (0.6) | 4 (0.8) | 5 (1.0) |
+| 社区活跃度 | 15% | 5 (0.75) | 4 (0.6) | 2 (0.3) |
+| 运维成本 | 10% | 3 (0.3) | 4 (0.4) | 5 (0.5) |
+| **加权总分** | 100% | **4.1** | **4.05** | **3.7** |
+```
+
+标注每个分数的**简短依据**（不要只给数字）
+
+### 4. POC 验证
+
+对得分接近的候选方案（差距 < 0.5 分），通过 POC 验证关键风险：
+
+- **POC 范围**：只验证最有风险的 1-2 个假设，不做完整功能
+- **POC 时间盒**：限定在 1-3 天内完成
+- **验证清单**：
+  - [ ] 核心功能可用性（Happy Path）
+  - [ ] 性能基准测试（如果性能是关键维度）
+  - [ ] 与现有技术栈的集成难度
+  - [ ] 边界场景和错误处理
+- 记录 POC 结果（代码片段 + 关键指标数据）
+
+### 5. 明确结论
+
+输出有据可查的选型结论：
+
+```markdown
+## 技术调研结论
+
+### 推荐方案
+**[方案名称]**
+
+### 推荐理由
+1. [主要优势 1]
+2. [主要优势 2]
+3. [评分最高/POC 验证通过]
+
+### 已知风险和缓解措施
+- 风险：[描述] → 缓解：[措施]
+
+### 放弃其他方案的原因
+- [方案 B]：[原因]
+- [方案 C]：[原因]
+
+### 后续行动
+- [ ] [下一步行动]
+```
+
+**输出格式**：Markdown 调研报告，含问题定义、候选方案概述、加权评分矩阵、POC 结果（如有）和最终选型结论
+
+**注意事项**：
+- 评估维度权重要在调研开始前确定，避免"为结论找理由"的逆向推导
+- POC 代码要保留在仓库中，方便团队评审
+- 选型结论要包含"不选其他方案的原因"，方便后续追溯决策依据
+
+---
+
+执行任何 Skill 时，严格按照定义的步骤和输出格式，不省略任何关键步骤。