tech-evaluator
星标10
分支0
更新时间2026年2月3日 02:46
评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。
安装
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
文件资源管理器
2 个文件SKILL.md
readonly
下载
相关职业SOC
基于 SOC 职业分类
菜单
评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | tech-evaluator |
| description | 评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。 |
"没有最好的技术栈，只有最适合的技术栈。" —— ThoughtWorks Technology Radar
本技能基于 SEI 的 ATAM (Architecture Tradeoff Analysis Method) 和 加权决策矩阵 方法论。
[!IMPORTANT] 在进行评估之前，你必须使用
sequential-thinkingskill，视复杂情况组织 2—7 个 thought 推理。 思考内容例如：
- "用户的核心需求是什么？必须支持哪些场景？"
- "团队目前熟悉什么技术？学习新技术的时间预算是多少？"
- "预算约束是什么？云服务成本敏感吗？"
- "这个项目预期规模是什么？需要支持多少并发用户？"
- "有没有合规要求（GDPR、等保）影响技术选择？"
产出 ADR (Architecture Decision Record) 文档，记录技术栈决策及其理由。
必须从用户处获取:
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 |
使用以下矩阵对每个候选栈打分 (1-5 分):
| 维度 | 权重建议 | 评估问题 |
|---|---|---|
| 需求匹配 | ★★★★★ | 能否实现所有核心功能？ |
| 扩展性 | ★★★★ | 能否支撑 10x 增长？ |
| 性能 | ★★★★ | 能否满足响应时间/吞吐量要求？ |
| 安全性 | ★★★★ | 内置安全特性？合规支持？ |
| 团队技能 | ★★★★★ | 团队熟悉程度？学习曲线？ |
| 人才市场 | ★★★ | 招人容易吗？ |
| 开发速度 | ★★★★ | 能否快速迭代？ |
| TCO (总成本) | ★★★★ | 开发+运维+许可证成本？ |
| 社区生态 | ★★★ | 库/工具丰富度？问题解答速度？ |
| 长期维护 | ★★★ | 技术寿命？LTS 支持？ |
| 集成能力 | ★★★ | 与现有系统/第三方服务集成？ |
| AI 就绪 | ★★ | 集成 AI/LLM 的便利性？ |
使用 ATAM 方法:
你必须创建 ADR_001_TECH_STACK.md，并将其写入 .specflow/v{N}/03_ADR/。
# ADR-001: 技术栈选择
## 状态
Accepted / Proposed / Deprecated
## 背景
[项目背景和约束描述]
## 决策
[选择的技术栈及核心理由]
## 候选方案对比
| 候选 | 总分 | 优势 | 劣势 |
|------|------|------|------|
| 方案 A | 42/60 | ... | ... |
| 方案 B | 38/60 | ... | ... |
## 权衡点
- [权衡 1]
- [权衡 2]
## 后果
- 正面: [...]
- 负面: [...]
- 需要的后续行动: [...]
references/ADR_TEMPLATE.md: ADR 模板references/TECH_RADAR_2025.md: 2025 技术雷达参考对已实现代码进行纯静态忠实度审查，验证实现是否忠于 PRD、ADR、System Design 与 05_TASKS.md 的既有契约，并识别契约漂移、任务漂移、测试漂移与回流遗漏，作为 challenge 的实现侧证据层。
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.
使用WBS方法将系统设计文档分解为层次化任务。支持依赖分析、追溯链、验收标准。
识别项目中的独立系统，定义系统边界。产出系统架构总览，为后续系统设计奠定基础。
为单个系统设计详细的技术文档。负责架构图、接口设计、数据模型、Trade-offs讨论等。
将模糊或高层需求转化为严格的产品需求文档（PRD）。适用于需求含糊、范围过大或表达停留在概念层的场景。