---
name: tech-review
description: >
  Reviews technical decisions before implementation. Detects outdated or
  suboptimal approaches by searching current best practices. Use when the
  user asks to implement something using a specific tool, library, or
  methodology.
---

# Tech Review

## 核心理念

用户因为信息差给出了过时或不优的技术方案时，AI 有责任在**执行前**发现并告知。

这不是"违抗用户指令"——不执行是违抗，发现更好的方案并告知是专业化。

## 触发条件

**必须触发**：用户指令中包含"用 [X] 做 [Y]"结构的技术实现请求。X 是一个工具/库/框架/方法论，Y 是一个目标。这种结构意味着用户已经做了技术选型，这个选型需要被验证。

**不触发**的典型场景：
- 纯业务逻辑（"写个登录接口"——不指定具体工具）
- 纯 debug（"修一下这个 bug"）
- 纯配置变更（"把端口改成 3000"）
- 用户明确说"按我说的做，不用查"
- 你 100% 确定该方案仍是当前最佳做法

> 不确定要不要触发？宁查勿漏。多一次搜索远比让用户走弯路划算。

## 工作流

### Step 1：提取技术决策

识别用户指令中所有"用 X 做 Y"性质的技术决策。可能不止一项。

### Step 2：搜索验证

对提取出的每一项技术决策，执行 web search。搜索词不限以下示例，根据实际情况组织：

```
[X] alternative
[X] vs [已知替代方案]
[X] deprecated
[场景描述] best practice
```

**每次审查至少搜索一次**。即使你认为自己的知识是准确的，也搜索确认——因为你不知道你的训练数据截止到什么时候。

### Step 3：输出审查报告

使用以下**固定格式**输出结果：

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔍 技术方案审查
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

审查结果：[ ✅ 方案可行 / ⚠️ 有更好的选择 / ❌ 方案不推荐 ]

涉及的技术决策：
  1. [选型 A] → [结论，附搜索来源概要]
  2. [选型 B] → [结论，附搜索来源概要]

[审查结果为 ✅]
  当前方案仍是最佳做法，按原计划执行。

[审查结果为 ⚠️ 或 ❌]
替代建议：
  - 方案一：[名称] — [简要说明]
  - 方案二：[名称] — [简要说明]

─────────────────────────────────────
请选择：A) 按原方案继续  B) 改用建议方案  C) 我自己调整
─────────────────────────────────────
```

### Step 4：等待选择

- **A** — 尊重用户意愿，按原方案执行，不再质疑
- **B** — 替换为建议方案，继续执行
- **C** — 用户修改需求后重新来过
- **用户不回复** — 不继续执行

## 说明

- 这个 Skill 的价值不在于"AI 替用户做决定"，而在于**消除信息差**
- web search 会产生费用，但这是为了换取正确性
- 如果同一领域的同类决策已在本次对话中审查过，可以跳过重复搜索