Tech Evaluator

强制深度思考

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

1. "用户的核心需求是什么？必须支持哪些场景？"
2. "团队目前熟悉什么技术？学习新技术的时间预算是多少？"
3. "预算约束是什么？云服务成本敏感吗？"
4. "这个项目预期规模是什么？需要支持多少并发用户？"
5. "有没有合规要求（GDPR、等保）影响技术选择？"

任务目标

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

评估流程 (The Evaluation)

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

必须从用户处获取:

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

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

2025 主流技术栈参考:

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

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

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

使用 ATAM 方法:

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

第五步：产出 ADR (Generate ADR)

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

ADR 输出模板

# ADR-001: 技术栈选择

## 状态
Accepted / Proposed / Deprecated

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

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

## 候选方案对比

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

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

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

老师傅守则

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

工具箱

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