菜单
技术选型技能：在多个候选方案中做出有依据的决策。 和 deep-research 的区别：deep-research 是广度调研（搞清楚一件事）， tech-evaluation 是聚焦决策（A 还是 B，选哪个，给结论）。 包含权重矩阵、PoC 验证流程、决策报告模板。 触发词：选型、选哪个、A 还是 B、对比、评估方案、用什么框架、用什么库。 触发场景：task-start 方案阶段遇到选型问题、引入新依赖前、架构决策。 即使用户没有说"选型"，只要意图是"在几个方案中做选择"，都应触发此技能。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
通用写作技能：以"内容→组件→组合"的方式产出技术文档、产品文档、汇报材料。 覆盖 spec / plan / PRD / 用户手册 / 项目汇报 / 方案路演 / 调研报告 等所有结构化文档场景。 核心理念：组件驱动，不预设模板。先看内容形态，再挑能装这种形态的组件， 组合自然成文——不强制章节结构、不预设"必备模块"。 组件库（HTML / Markdown / 图示）见 references/components.md， 常见组合范式（spec / plan / PRD 等）见 references/templates/——但模板是参考不是规定。 触发词：写文档、写方案、写计划、写 PRD、写汇报、项目总结、写指南、帮我写、文档、方案设计。 即使用户没有明确说"写"，只要意图是"产出一份结构化的文档/报告/材料"，都应触发此技能。 本 skill 只负责"写"，不负责"调研"（调研由 deep-research 承担）和"调度"（流程由 task-start 承担）。
深度调研技能：对任意命题进行系统性调研并输出专业研究报告。 覆盖技术选型、行业分析、学术研究、竞品分析、概念探索等所有调研场景。 核心方法论：快速扫描→假设驱动研究、内外数据结合（先摸清内部现状再对标外部水位）、 反面证据强制搜索、数据来源三级分类、结论置信度分级、多层次报告输出。 采用 Orchestrator-Subagent 架构（Lead+Sub-agent 并行深挖、压缩回传、Scaling Rules 预算控制）， 对齐 Anthropic 官方 Research 工程实践。 包含信息交叉验证、专业图表生成（Diagram Bridge 统一图表体系）、 数据来源分级标注、分析框架自动选择、报告组件驱动（不预设模板，按内容形态调用组件）、质量自检（6 步工作流）。 触发词：调研、研究、分析报告、对比分析、行业报告、技术选型、竞品分析、 市场调研、深度研究、出一份报告、帮我调研一下、了解一下xxx、 评估、诊断、健康度、差距分析。 即使用户没有明确说"调研"，只要意图是"系统性地了解某个命题并形成结论"，都应触发此技能。
MD 文件浏览器预览：GitHub 风格渲染 + 左侧自动目录。 在完成方案设计（specs）或开发计划（plans）的 MD 文件后触发。 询问用户是否要在浏览器中打开预览，确认后执行。 触发词：方案写完、计划写完、review MD、预览文档。 工作流位置：task-start 方案产出后 / 任意 MD 文档完成后
专业图表生成技能：根据需求自动选择合适的图表类型，生成符合设计规范的 PNG 图表。 覆盖 29 种图表：结构图（流程图、泳道图、时序图、架构图、状态图、ER图、类图、思维导图、甘特图、Kanban、Git Graph 等） 和统计图（柱状图、折线图、饼图、雷达图、热力图、散点图、桑基图、漏斗图、瀑布图、矩形树图、柱线混合图等）。 统一工具：HTML/SVG + 内联 JS 布局计算。ER/类图使用 ELKjs 布局引擎。 所有图表遵循统一的设计规范（配色/字体/组件/间距），风格现代简洁。 支持三种输出：PNG（默认）、HTML（富文档嵌入）、DSL（Mermaid 文本，嵌入 MD 文档）。 触发词：画图、画一个、生成图表、流程图、架构图、时序图、柱状图、对比图、关系图。 即使用户没有说"画图"，只要需求中涉及可视化展示（流程、架构、数据对比、关系），都应触发此技能。 被 deep-research 等其他技能调用时，同样遵循本规范生成图表。
项目知识库引擎：持续维护 docs/ 目录作为活的知识库。 灵感来源：Karpathy LLM Wiki — LLM 不只是写文档，而是持续维护知识库。 五个核心操作：Ingest（摄入新信息）、Query（检索知识）、Lint（健康检查）、Index（索引维护）、Synthesize（聚合全局视图）。 触发词：文档检查、清理文档、文档索引、docs 整理、知识库、文档过期了吗、架构文档、用户手册。 触发场景：task-manager 标 done 时自动触发 Ingest、定期 Lint 健检、用户查询项目历史、 task-finish 提醒后触发 Synthesize 更新 architecture/ 或 user-guide/。 即使用户没有说"文档管理"，只要涉及 docs/ 目录的整理/检查/更新，都应触发此技能。
提交前质量门禁：CR 自检（快速/深度）。在 commit 之前触发。 只负责代码质量自检，不负责复盘——复盘在需求标 done 时由 task-manager 触发。 触发词：提交代码、自检、准备提交。 工作流位置：task-start → task-execute → task-finish（自检）→ task-manager（需求关闭时复盘）
| name | tech-evaluation |
| version | 1.0.0 |
| last_updated | "2026-04-08T00:00:00.000Z" |
| repository | https://github.com/312362115/claude |
| description | 技术选型技能：在多个候选方案中做出有依据的决策。 和 deep-research 的区别：deep-research 是广度调研（搞清楚一件事）， tech-evaluation 是聚焦决策（A 还是 B，选哪个，给结论）。 包含权重矩阵、PoC 验证流程、决策报告模板。 触发词：选型、选哪个、A 还是 B、对比、评估方案、用什么框架、用什么库。 触发场景：task-start 方案阶段遇到选型问题、引入新依赖前、架构决策。 即使用户没有说"选型"，只要意图是"在几个方案中做选择"，都应触发此技能。 |
选型的核心不是"哪个更好"，而是"在我们的场景下哪个更合适"。 没有最好的技术，只有最合适的技术。
用 AskUserQuestion 明确以下信息：
| 要素 | 问什么 | 为什么重要 |
|---|---|---|
| 要解决的问题 | 选型是为了解决什么？ | 锚定评估标准 |
| 候选方案 | 已经有哪些候选？需要我帮忙发现更多吗？ | 确定评估范围 |
| 硬性约束 | 必须满足的条件（许可证、语言、兼容性） | 先排除不合格的 |
| 优先维度 | 最看重什么？（性能 / 生态 / 学习成本 / 成本） | 决定权重 |
| 决策时间 | 需要多深入？快速判断还是深度评估？ | 控制投入 |
用硬性约束做第一轮筛选：
## 候选方案筛选
| 候选 | 约束 1（MIT 许可） | 约束 2（支持 TS） | 约束 3（活跃维护） | 结果 |
|------|-------------------|-------------------|-------------------|------|
| 方案 A | ✅ | ✅ | ✅ | 进入评估 |
| 方案 B | ✅ | ❌ | ✅ | 排除 |
| 方案 C | ✅ | ✅ | ❌（2 年无更新） | 排除 |
如果筛选后只剩 1-2 个候选，且差异明显：
如果筛选后有 2-3 个势均力敌的候选 → 进入第三步完整评估。
根据用户关注的维度，构建权重矩阵：
## 评估维度与权重
| 维度 | 权重 | 说明 |
|------|------|------|
| 功能匹配度 | 30% | 是否满足核心需求 |
| 性能 | 25% | 对应场景下的实际表现 |
| 生态与社区 | 20% | 文档质量、社区活跃度、第三方集成 |
| 学习成本 | 15% | 团队上手难度 |
| 运维成本 | 10% | 部署复杂度、监控、升级成本 |
权重确定方式：
对每个维度，用事实和数据评估，不用"感觉"：
| 维度 | 怎么评估 | 数据来源 |
|---|---|---|
| 功能匹配度 | 列出需求清单，逐项检查每个候选是否支持 | 官方文档、GitHub issues |
| 性能 | 找 benchmark 数据，或自己跑 PoC 测试 | 官方 benchmark、第三方评测、自测 |
| 生态与社区 | GitHub stars/issues 响应速度、npm 周下载量、Stack Overflow 问题数 | GitHub、npm、Stack Overflow |
| 学习成本 | 文档质量、API 设计是否直觉、有无迁移指南 | 官方文档、教程资源 |
| 运维成本 | 部署方式、配置复杂度、升级历史（有无 breaking changes） | CHANGELOG、升级指南 |
对关键维度，写代码验证比看文档更可靠：
## PoC 验证
### 验证目标
用方案 A 和方案 B 分别实现 <核心场景>，对比：
- 代码量和复杂度
- 实际性能数据
- 遇到的坑
### 验证结果
| 指标 | 方案 A | 方案 B |
|------|--------|--------|
| 代码行数 | 120 行 | 85 行 |
| 响应时间(p95) | 23ms | 18ms |
| 遇到的问题 | 文档缺失，靠看源码 | 顺利，文档完整 |
PoC 不需要做完整功能，只需要验证最不确定的维度。
## 综合评分
| 维度 | 权重 | 方案 A | 方案 B | 方案 C |
|------|------|--------|--------|--------|
| 功能匹配度 | 30% | 9 | 8 | 7 |
| 性能 | 25% | 7 | 9 | 8 |
| 生态与社区 | 20% | 8 | 7 | 9 |
| 学习成本 | 15% | 6 | 8 | 7 |
| 运维成本 | 10% | 7 | 8 | 6 |
| **加权总分** | | **7.65** | **8.05** | **7.50** |
## 选型决策
**推荐：方案 B**
### 核心理由
- 加权总分最高（8.05）
- 在最看重的性能维度（权重 25%）上明显领先
- PoC 验证中开发体验最好
### 取舍说明
- 放弃方案 A 的原因：学习成本较高，团队没有相关经验
- 放弃方案 C 的原因：社区活跃但功能匹配度不足
### 风险提示
- 方案 B 的社区规模较小，未来可能面临维护风险
- 建议：核心功能不过度依赖其独有特性，保持可替换性
选型结论写入 spec 文档（调 writing skill 的技术文档模式），至少包含：
task-start（方案阶段遇到选型）→ tech-evaluation（评估决策）
deep-research（需要广度调研时）← tech-evaluation 按需调用
tech-evaluation → writing（输出选型报告到 spec）
tech-evaluation vs deep-research：