tech-evaluator

スター10

フォーク0

更新日2026年2月3日 02:46

评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

ソース

jmerelnyc

jmerelnyc/specflow

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

技术评估师手册 (The Tech Evaluator's Manual)

"没有最好的技术栈，只有最适合的技术栈。" —— ThoughtWorks Technology Radar

本技能基于 SEI 的 ATAM (Architecture Tradeoff Analysis Method) 和 加权决策矩阵 方法论。

⚠️ 强制深度思考

[!IMPORTANT] 在进行评估之前，你必须使用 sequential-thinking skill，视复杂情况组织 2—7 个 thought 推理。思考内容例如：

"用户的核心需求是什么？必须支持哪些场景？"

"团队目前熟悉什么技术？学习新技术的时间预算是多少？"

"预算约束是什么？云服务成本敏感吗？"

"这个项目预期规模是什么？需要支持多少并发用户？"

"有没有合规要求（GDPR、等保）影响技术选择？"

⚡ 任务目标

产出 ADR (Architecture Decision Record) 文档，记录技术栈决策及其理由。

🧭 评估流程 (The Evaluation)

第一步：收集约束 (Gather Constraints)

必须从用户处获取:

功能需求: 核心功能列表
非功能需求: 性能目标、可用性要求、安全等级
团队情况: 人数、技能栈、学习意愿
预算: 开发预算、运维预算、时间预算
特殊约束: 合规要求、现有系统集成、客户指定技术

第二步：识别候选技术栈 (Identify Candidates)

2025 主流技术栈参考:

场景	推荐栈	备选
Web 全栈	Next.js + TypeScript	Nuxt, SvelteKit
后端 API	Go / Rust / Node.js	Python FastAPI, Java Spring
桌面应用	Tauri (Rust + Web)	Electron, Flutter Desktop
移动应用	React Native / Flutter	Swift/Kotlin 原生
AI/ML	Python + PyTorch/TensorFlow	Rust (Candle), Julia
数据密集	PostgreSQL + TimescaleDB	ClickHouse, DuckDB

第三步：12 维度评估 (12-Dimension Evaluation)

使用以下矩阵对每个候选栈打分 (1-5 分):

维度	权重建议	评估问题
需求匹配	★★★★★	能否实现所有核心功能？
扩展性	★★★★	能否支撑 10x 增长？
性能	★★★★	能否满足响应时间/吞吐量要求？
安全性	★★★★	内置安全特性？合规支持？
团队技能	★★★★★	团队熟悉程度？学习曲线？
人才市场	★★★	招人容易吗？
开发速度	★★★★	能否快速迭代？
TCO (总成本)	★★★★	开发+运维+许可证成本？
社区生态	★★★	库/工具丰富度？问题解答速度？
长期维护	★★★	技术寿命？LTS 支持？
集成能力	★★★	与现有系统/第三方服务集成？
AI 就绪	★★	集成 AI/LLM 的便利性？

第四步：权衡分析 (Trade-off Analysis)

使用 ATAM 方法:

识别质量属性场景 (如 "1000 并发用户时响应 < 200ms")
评估每个候选栈对场景的支持程度
识别权衡点 (如 "选 Go 性能好但团队需学习")
识别风险点 (如 "选新框架可能踩坑")

第五步：产出 ADR (Generate ADR)

你必须创建 ADR_001_TECH_STACK.md，并将其写入 .specflow/v{N}/03_ADR/。

📤 ADR 输出模板

# ADR-001: 技术栈选择

## 状态
Accepted / Proposed / Deprecated

## 背景
[项目背景和约束描述]

## 决策
[选择的技术栈及核心理由]

## 候选方案对比

| 候选 | 总分 | 优势 | 劣势 |
|------|------|------|------|
| 方案 A | 42/60 | ... | ... |
| 方案 B | 38/60 | ... | ... |

## 权衡点
- [权衡 1]
- [权衡 2]

## 后果
- 正面: [...]
- 负面: [...]
- 需要的后续行动: [...]

🛡️ 老师傅守则

"无聊"技术优先: 除非有充分理由，优先选择成熟稳定的技术。
创新预算有限: 每个项目只有 1-2 个"创新点"配额，其余用"无聊"技术。
团队能力为王: 再好的技术，团队不会用也是白搭。
TCO 不只是钱: 时间成本、认知成本也是成本。

🧰 工具箱

references/ADR_TEMPLATE.md: ADR 模板
references/TECH_RADAR_2025.md: 2025 技术雷达参考

このリポジトリの他の Skills

同じリポジトリ

code-reviewer

jmerelnyc/specflow

对已实现代码进行纯静态忠实度审查，验证实现是否忠于 PRD、ADR、System Design 与 05_TASKS.md 的既有契约，并识别契约漂移、任务漂移、测试漂移与回流遗漏，作为 challenge 的实现侧证据层。

2026-03-2010

nexus-mapper

jmerelnyc/specflow

Generate a persistent .nexus-map/ knowledge base that lets any AI session instantly understand a codebase's architecture, systems, dependencies, and change hotspots. Use when starting work on an unfamiliar repository, onboarding with AI-assisted context, preparing for a major refactoring initiative, or enabling reliable cold-start AI sessions across a team. Produces INDEX.md, systems.md, concept_model.json, git_forensics.md and more. Requires shell execution and Python 4.10+. For ad-hoc file queries or instant impact analysis during active development, use nexus-query instead.

2026-03-2010

task-planner

jmerelnyc/specflow

使用WBS方法将系统设计文档分解为层次化任务。支持依赖分析、追溯链、验收标准。

2026-02-2010

system-architect

jmerelnyc/specflow

识别项目中的独立系统，定义系统边界。产出系统架构总览，为后续系统设计奠定基础。

2026-02-0210

system-designer

jmerelnyc/specflow

为单个系统设计详细的技术文档。负责架构图、接口设计、数据模型、Trade-offs讨论等。

2026-01-0810

spec-writer

jmerelnyc/specflow

将模糊或高层需求转化为严格的产品需求文档（PRD）。适用于需求含糊、范围过大或表达停留在概念层的场景。

2026-01-0610

name	tech-evaluator
description	评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。

技术评估师手册 (The Tech Evaluator's Manual)

"没有最好的技术栈，只有最适合的技术栈。" —— ThoughtWorks Technology Radar

本技能基于 SEI 的 ATAM (Architecture Tradeoff Analysis Method) 和 加权决策矩阵 方法论。

⚠️ 强制深度思考

[!IMPORTANT] 在进行评估之前，你必须使用 sequential-thinking skill，视复杂情况组织 2—7 个 thought 推理。思考内容例如：

"用户的核心需求是什么？必须支持哪些场景？"

"团队目前熟悉什么技术？学习新技术的时间预算是多少？"

"预算约束是什么？云服务成本敏感吗？"

"这个项目预期规模是什么？需要支持多少并发用户？"

"有没有合规要求（GDPR、等保）影响技术选择？"

⚡ 任务目标

产出 ADR (Architecture Decision Record) 文档，记录技术栈决策及其理由。

🧭 评估流程 (The Evaluation)

第一步：收集约束 (Gather Constraints)

必须从用户处获取:

功能需求: 核心功能列表
非功能需求: 性能目标、可用性要求、安全等级
团队情况: 人数、技能栈、学习意愿
预算: 开发预算、运维预算、时间预算
特殊约束: 合规要求、现有系统集成、客户指定技术

第二步：识别候选技术栈 (Identify Candidates)

2025 主流技术栈参考:

场景	推荐栈	备选
Web 全栈	Next.js + TypeScript	Nuxt, SvelteKit
后端 API	Go / Rust / Node.js	Python FastAPI, Java Spring
桌面应用	Tauri (Rust + Web)	Electron, Flutter Desktop
移动应用	React Native / Flutter	Swift/Kotlin 原生
AI/ML	Python + PyTorch/TensorFlow	Rust (Candle), Julia
数据密集	PostgreSQL + TimescaleDB	ClickHouse, DuckDB

第三步：12 维度评估 (12-Dimension Evaluation)

使用以下矩阵对每个候选栈打分 (1-5 分):

维度	权重建议	评估问题
需求匹配	★★★★★	能否实现所有核心功能？
扩展性	★★★★	能否支撑 10x 增长？
性能	★★★★	能否满足响应时间/吞吐量要求？
安全性	★★★★	内置安全特性？合规支持？
团队技能	★★★★★	团队熟悉程度？学习曲线？
人才市场	★★★	招人容易吗？
开发速度	★★★★	能否快速迭代？
TCO (总成本)	★★★★	开发+运维+许可证成本？
社区生态	★★★	库/工具丰富度？问题解答速度？
长期维护	★★★	技术寿命？LTS 支持？
集成能力	★★★	与现有系统/第三方服务集成？
AI 就绪	★★	集成 AI/LLM 的便利性？

第四步：权衡分析 (Trade-off Analysis)

使用 ATAM 方法:

识别质量属性场景 (如 "1000 并发用户时响应 < 200ms")
评估每个候选栈对场景的支持程度
识别权衡点 (如 "选 Go 性能好但团队需学习")
识别风险点 (如 "选新框架可能踩坑")

第五步：产出 ADR (Generate ADR)

你必须创建 ADR_001_TECH_STACK.md，并将其写入 .specflow/v{N}/03_ADR/。

📤 ADR 输出模板

# ADR-001: 技术栈选择

## 状态
Accepted / Proposed / Deprecated

## 背景
[项目背景和约束描述]

## 决策
[选择的技术栈及核心理由]

## 候选方案对比

| 候选 | 总分 | 优势 | 劣势 |
|------|------|------|------|
| 方案 A | 42/60 | ... | ... |
| 方案 B | 38/60 | ... | ... |

## 权衡点
- [权衡 1]
- [权衡 2]

## 后果
- 正面: [...]
- 负面: [...]
- 需要的后续行动: [...]

🛡️ 老师傅守则

"无聊"技术优先: 除非有充分理由，优先选择成熟稳定的技术。
创新预算有限: 每个项目只有 1-2 个"创新点"配额，其余用"无聊"技术。
团队能力为王: 再好的技术，团队不会用也是白搭。
TCO 不只是钱: 时间成本、认知成本也是成本。

🧰 工具箱

references/ADR_TEMPLATE.md: ADR 模板
references/TECH_RADAR_2025.md: 2025 技术雷达参考