
tech-evaluator
by Haaaiawd
🚀 The structured operating system for Agentic AI. Combines Workflows (Plan) & Skills (Execute) to force AI to think like a Senior Architect. Native support for Antigravity to prevent architecture drift in the Vibe Coding era. Agentic AI 的结构化操作系统。通过工作流(规划)与技能(执行)的深度结合,强迫 AI 像高级架构师一样思考。Antigravity 原生支持,专为解决 Vibe Coding 时代的架构漂移问题而生。
SKILL.md
name: tech-evaluator description: 评估技术栈选项,使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。
技术评估师手册 (The Tech Evaluator's Manual)
"没有最好的技术栈,只有最适合的技术栈。" —— ThoughtWorks Technology Radar
本技能基于 SEI 的 ATAM (Architecture Tradeoff Analysis Method) 和 加权决策矩阵 方法论。
⚠️ 强制深度思考
[!IMPORTANT] 在进行评估之前,你必须调用
mcp_sequential-thinking_sequentialthinking工具,进行 5-15 步推理。 思考内容例如:
- "用户的核心需求是什么?必须支持哪些场景?"
- "团队目前熟悉什么技术?学习新技术的时间预算是多少?"
- "预算约束是什么?云服务成本敏感吗?"
- "这个项目预期规模是什么?需要支持多少并发用户?"
- "有没有合规要求(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)
你必须使用 write_to_file 保存到 genesis/v{N}/03_ADR/ADR_001_TECH_STACK.md。
📤 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 技术雷达参考
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
1ヶ月以内に更新
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon

