| 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 会产生费用，但这是为了换取正确性
- 如果同一领域的同类决策已在本次对话中审查过，可以跳过重复搜索
