tech-evaluator

技术评估师手册 — Genesis Step 3

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

本技能基于 SEI 的 ATAM (Architecture Tradeoff Analysis Method) 与 加权决策矩阵。在 /genesis 中与 Step 3 绑定；ADR 的正式写入与编号治理以 Step 5 与 genesis.md 为准。

---

CRITICAL /genesis 门禁（本线专用收口）

[!IMPORTANT]

• /genesis Step 3：只输出评估结果与 Markdown 对比素材，不得在本步创建或修改 .anws/v{N}/03_ADR/ 下任何 ADR 文件。原因见 genesis.md Step 3 / Step 5：ADR 为正式决策记录，须在 Step 5 完整审视后落盘。
• Step 5 落盘目标（供下游引用，非 Step 3 执行项）：将 Step 3 对比表升格为 .anws/v{N}/03_ADR/ADR_001_TECH_STACK.md（及姊妹 ADR），章节结构以 references/ADR_TEMPLATE.md 为唯一权威。
• 若宿主会话声明 非 /genesis 或显式授权「本步即写 ADR」，以当场工作流为准；默认仍按 Step 3 不写 ADR。

[!NOTE] ADR 时序：Step 3 只产出评估与对比素材，不写 03_ADR/；Step 4 产出系统边界与 02_*；Step 5 再升格 ADR，使影响范围与真实系统 ID 对齐。阶段表与四点论证见 genesis.md Step 3 的 NOTE。若会话非 /genesis 或用户授权本步写 ADR，以当场工作流为准。

---

CRITICAL spec 产出契约（Step 3 交付物）

[!IMPORTANT]

• 可核对：约束块须覆盖功能需求、非功能需求、团队、预算、特殊约束；缺的项写「未提供—评估基于假设 H-…」，不得静默省略。
• 可计算：每个候选栈须有 12 维得分表（1–5）或逐维「不适用 + 原因」；禁止只给总分不给细表。
• 可推演：ATAM 段落须含至少一个质量属性场景、若干权衡点、若干风险点；不得用形容词堆叠代替场景。
• 可升格：最终对比表须能无损映射到 references/ADR_TEMPLATE.md 的章节与必填节，供 Step 5 粘贴与润色。
• 验证策略显式：须回答或标注待决：单测 / 集成 / E2E 侧重、冒烟 / 回归门禁、质量门禁落在 PR / INT / 预发 / 发布的哪一层（与 genesis.md Step 3 要求一致）。
• 单一真源：数值与结论以 Step 3 产出表为准；Step 5 仅做编辑与状态流转，不得在无新证据时反向改分。

---

强制深度思考

[!IMPORTANT] 在开始评估前必须调用 sequential-thinking skill，按复杂度组织 3—7 个 thought，例如：

1. 用户核心场景与必须支持的用例边界是什么？
2. 团队熟悉度与可接受的学习成本？
3. 预算与云 / 许可证 TCO 敏感度？
4. 预期规模与并发 / 数据量级？
5. 合规（GDPR、等保等）是否一票否决某些栈？

---

任务目标（Step 3）

在不写 ADR 文件前提下，产出：

1. 结构化约束摘要与候选栈列表；
2. 12 维打分矩阵与加权汇总说明（权重须声明或采用本文建议并说明）；
3. ATAM 权衡与风险短文；
4. 供 Step 5 直接使用的 Markdown 候选方案对比总表。

---

评估流程 (The Evaluation)

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

必须从用户或已加载工件取得（不足的按 spec 契约标注假设）：

• 功能需求：核心能力列表（可引用 01_PRD.md）。
• 非功能需求：性能、可用性、安全等级。
• 团队情况：人数、技能栈、学习意愿。
• 预算：开发、运维、时间。
• 特殊约束：合规、存量系统集成、客户指定技术。
• （如已执行 Step 2.5）/explore 研究结论中的证据与备选方案。