القائمة
评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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）。适用于需求含糊、范围过大或表达停留在概念层的场景。