| name | tech-evaluator |
| description | 服务于 `/genesis` Step 3「技术选型」：以 ATAM 与 12 维加权矩阵评估候选栈，产出可追溯的对比结论与 ADR 升格素材；不写正式 ADR 文件（落盘在 Step 5）。优先读本 SKILL 旁 `references/`。 |
技术评估师手册 — 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，例如：
- 用户核心场景与必须支持的用例边界是什么？
- 团队熟悉度与可接受的学习成本？
- 预算与云 / 许可证 TCO 敏感度？
- 预期规模与并发 / 数据量级？
- 合规（GDPR、等保等）是否一票否决某些栈？
任务目标（Step 3）
在不写 ADR 文件前提下，产出：
- 结构化约束摘要与候选栈列表；
- 12 维打分矩阵与加权汇总说明（权重须声明或采用本文建议并说明）；
- ATAM 权衡与风险短文；
- 供 Step 5 直接使用的 Markdown 候选方案对比总表。
评估流程 (The Evaluation)
第一步：收集约束 (Gather Constraints)
必须从用户或已加载工件取得（不足的按 spec 契约标注假设）：
- 功能需求：核心能力列表（可引用
01_PRD.md）。
- 非功能需求：性能、可用性、安全等级。
- 团队情况：人数、技能栈、学习意愿。
- 预算：开发、运维、时间。
- 特殊约束：合规、存量系统集成、客户指定技术。
- （如已执行 Step 2.5）
/explore 研究结论中的证据与备选方案。
做什么
固化输入边界，列出缺口与假设编号。
为什么
避免无约束的偏好打分和不复现的结论。
怎么验收
输出中可出现「假设 H-xx」对照表；无静默缺项。
第二步：识别候选技术栈 (Identify Candidates)
主流技术栈参考（可按项目替换或增删）：
| 场景 | 推荐栈 | 备选 |
|---|
| 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 |
做什么
列出 2 个及以上具名候选（语言 / 框架 / 关键中间件级），附一句选型范围说明。
为什么
单候选无权衡，无法完成 ATAM。
怎么验收
每个候选可被独立打分；无匿名「方案 A/B」。
第三步：12 维度评估 (12-Dimension Evaluation)
对每个候选按 1–5 分打分：
| 维度 | 权重建议 | 评估问题 |
|---|
| 需求匹配 | — | 能否实现所有核心功能？ |
| 扩展性 | — | 能否支撑 10x 增长？ |
| 性能 | — | 能否满足响应时间 / 吞吐量？ |
| 安全性 | — | 内置安全与合规支持？ |
| 团队技能 | — | 熟悉度与学习曲线？ |
| 人才市场 | — | 招聘与外包可得性？ |
| 开发速度 | — | 迭代与交付速度？ |
| TCO (总成本) | — | 开发 + 运维 + 许可证？ |
| 社区生态 | — | 库、工具与排障资源？ |
| 长期维护 | — | 技术寿命与 LTS？ |
| 集成能力 | — | 与存量与第三方集成？ |
| AI 就绪 | — | 接入 AI / LLM 的便利度？ |
做什么
填满矩阵；声明权重（均匀或加权）并计算可比总分或档级。
为什么
多维透明，便于 Step 5 写入 ADR 证据节。
怎么验收
表在 Markdown 中可复算；不适用维度有单行解释。
第四步：权衡分析 (Trade-off Analysis) — ATAM
- 识别质量属性场景（例：「1000 并发用户时 P95 < 200ms」）。
- 各候选对该场景的支持程度分级说明。
- 列出权衡点（例：性能好 vs 团队学习成本）。
- 列出风险点（例：新版本框架成熟度）。
做什么
把「为什么不是第二名」说清楚。
为什么
ADR 核心价值在取舍与后果，不单是赢家声明。
怎么验收
至少 1 个场景 + 若干权衡 / 风险，可与候选表交叉引用。
第五步：产出 ADR 升格素材（Step 3，非落盘）
在 /genesis Step 3 下，你不得新建或修改 03_ADR/*.md。产出完整 Markdown 对比结论与升格素材，使 Step 5 能对照 references/ADR_TEMPLATE.md 无损升格；段落与章节可标 Proposed / 待定。
若工作流显式要求本步预创建占位文件（极少见），仅允许空文件或 MANIFEST 约定路径，不得将占位等同于已接受 ADR。
禁止：在本 SKILL 内再嵌一套与 references/ADR_TEMPLATE.md 重复的完整 ADR 范文；章节疑问一律以该文件为准。
做什么
生成完整对比与符合 references/ADR_TEMPLATE.md 场域的草稿（内存或会话消息中的 Markdown）。
为什么
与 genesis 决策关口对齐，避免未成文的早期 ADR。
怎么验收
父代理能在 Step 5 打开 references/ADR_TEMPLATE.md 并对齐各节而无信息断档。
ALPHA 决策守则
- "无聊"技术优先：除非有充分理由，选成熟栈。
- 创新预算有限：每项目 1–2 个创新点配额，其余求稳。
- 团队能力为王：再好的技术用不了等于零。
- TCO 不只是钱：时间与认知负载计入成本。
references 与同 bundle 路径说明
与本 SKILL 同级的 references/ADR_TEMPLATE.md 供 ADR 骨架引用。读取时 仅以本 SKILL 旁 references/ 为准。
| 文件 | 用途 |
|---|
references/ADR_TEMPLATE.md | ADR 体格与必填节 |
执行形态与子代理编排
做什么
- 优先：若宿主提供 AGENT / 子代理：可委派候选搜集、单候选多维打分草稿或 ATAM 风险草案；编排侧下发本文 spec 产出契约 + 门禁 + ADR 模板字段，收束后为单一合并稿。
- 父代理：持有
sequential-thinking 必须在主会话或由明确指定的合并代理执行一轮完整 thought 链后再定稿；子代理不可替代该义务除非工作流写明。
- 回退：无子代理时，由当前会话完整执行全流程。
为什么
并行搜集与串行裁决分离，降低遗漏维度的概率。
怎么验收
合并稿仍满足 spec 契约；无互相矛盾的分数或重复候选名；/genesis Step 3 仍无 03_ADR 写操作。
Handoff checklist（编排 / 子代理 / Step 5）
<completion_criteria>
sequential-thinking 已完成 3—7 thought，且可在输出中见其结论被评估吸收。- 交付物满足 CRITICAL spec 产出契约（可核对 / 可计算 / 可推演 / 可升格 / 验证策略显式）。
- 在
/genesis Step 3 默认路径下，未对 .anws/v{N}/03_ADR/ 进行 ADR 落盘。
- Handoff checklist 全部为真或显式豁免项已记入最后一节「未决事项」。
- 与同一会话内其它 skill 一致，均取自工作区
.agents/skills/。
</completion_criteria>
