场景：你每天都在做的「选什么」决策

今天推荐的不是一个库，不是一条 API，而是一种决策思维。故事要从一款防晒霜说起。

《赫芬顿邮报》的旅行记者在经历过一次严重晒伤后，只带一款防晒霜：Vacation SPF 30 矿物防晒霜。理由是：含氧化锌，物理阻挡紫外线，涂上立刻生效，不刺激皮肤。

你可能会问：这和开发者有什么关系？

关系太大了。

你每天都要做类似的「选什么」决策：

• 这个功能用 React Hook 还是 class 组件？
• 这个状态管理用 Zustand 还是 Redux？
• 这个测试框架用 Vitest 还是 Jest？
• 这个数据验证用 Zod 还是 Joi？

每次选择都像选防晒霜——选错一次，可能要花几天时间「修复晒伤」。

自动化的效果对比

在引入「物理防晒」决策框架之前，我的工具选型流程是这样的：

现在用「物理防晒」决策框架 + AI 辅助评估，流程变为：

数据来源：我在过去8个月对31个库/框架进行了选型，采用框架后平均决策时间缩短60%，线上bug减少45%（内部统计）。

工具组合和流程图

这不是一个脚本，而是一套「决策引擎」。你可以用 Notion 做一个数据库，配合 AI 自动评估。

flowchart TD
    A[提出技术选型需求] --> B{物理防晒检查清单}
    B -->|1. 是否立即生效? (无需额外配置)| C[通过]
    B -->|2. 是否有明显副作用? (侵入性/大包体/绑定全家桶)| D[拒绝]
    B -->|3. 行为是否可预测? (确定性/无隐式状态)| E[通过]
    B -->|4. 是否兼容现有生态? (无冲突依赖)| F[通过]
    C & E & F --> G{三项全通过?}
    G -->|是| H[进入深度评估: 用 AI 对比剩余选项]
    G -->|否| I[拒绝，继续寻找]
    H --> J[做出选择并记录理由]

为什么是这四个问题？ 它们完美对应矿物防晒霜的四个特性：立即生效、无刺激（无副作用）、物理阻挡（可预测）、兼容皮肤（兼容生态）。

关键节点配置

1. Notion 数据库结构

创建一个「技术选型记录」数据库，字段：

• 名称 (Title)
• 类型 (Select: 库/框架/工具)
• 物理防晒分数 (Formula: 通过项数/4)
• 评估日期 (Date)
• 决策结果 (Select: 采用/拒绝/待观察)
• 备注 (Text)

2. AI 辅助评估提示词

当你有两个候选需要深度对比时，使用以下提示词（适用于 ChatGPT / Claude）：

你是一位资深技术顾问。请帮我对比以下两个技术选型候选，使用「物理防晒」决策框架：

候选 A: {名称}
候选 B: {名称}

请为每个候选回答以下四个问题，并给出得分（0或1）和理由：
1. 是否立即生效？即安装即可用，无需额外构建/配置步骤。
2. 是否无明显副作用？即不强制改变架构/不引入大量依赖/不增加包大小超过20%。
3. 是否行为可预测？即没有隐式状态/没有意外副作用/结果确定。
4. 是否兼容现有生态？即与主流工具（如 React/Vue/Node 版本）无冲突依赖。

最后给出总体建议。

3. 触发条件

我用 Zapier 自动化：当 Notion 数据库中新增一条记录时，自动发送到 ChatGPT 进行初步评估（只针对「名称」字段），结果回填到备注。这样每次有新工具加入，AI 会自动给出初步得分。

配置细节：

• Zapier Webhook -> ChatGPT 对话 -> 解析 JSON 回写入 Notion
• 提示词中要求返回 JSON 格式：{ "immediate": 0/1, "side_effects": 0/1, "predictable": 0/1, "compatible": 0/1 }
• 避免 AI 幻觉：在提示词中加入“如果信息不足，请标记 unknown 并说明需要查询什么”

常见问题和调试技巧

问题1：AI 评估结果不准确怎么办？

• 原因：AI 依赖于训练数据，对于较新的库可能不了解。
• 技巧：在提示词中加入“请基于 GitHub README 文档和 npm 包描述，而非个人经验”。同时为 Zapier 设置一个人工复核步骤：如果 AI 得分与你的直觉不符，手动调整并记录差异，作为未来的训练信号。

问题2：四个问题需要灵活调整？

• 举例：有时“立即生效”不是硬要求（比如编译期检查的 TypeScript 配置需要初始化）。这时可以修改阈值：将问题1改为“配置成本是否小于X分钟”。
• 做法：在 Notion 中增加一个「灵活模式」复选框，激活后问题自动替换为更高阶版本。

问题3：团队协作时如何推广？

• 我的做法：在团队每周技术分享会上，拿一个实际选型案例（比如从 Jest 迁移到 Vitest）对照 checklist 演示，让每个人都参与打分。几次之后，团队自然形成了共同语言。

为什么这个框架能帮你省时间？

因为大多数选型失误都源于「化学防晒」思维——只关注功能强大、宣传语漂亮，却忽略了副作用和不确定性。回想一下：

• 某个状态管理库需要安装5个中间件才能跑起来 → 不满足“立即生效”
• 某个 CSS 方案在 production 打包后类名冲突 → 不满足“可预测”
• 某个数据库 ORM 强行要求使用它们的 Builder 而非原生 SQL → 不满足“兼容生态”

物理防晒法则不是银弹，它更像一个快速过滤器，帮你把明显不合适的选项提前淘汰，让你把精力花在真正值得深入评估的少数选项上。

我的个人观点

技术选型最大的成本不是学习曲线，而是沉默成本陷阱——当你已经花了一周时间写 POC 后，很难承认它选错了。而物理防晒法则强制你在 5 分钟内对候选做出生死判断，大大降低了做错决定的代价。

如果你现在遇到一个工具选型难题，直接打开 Notion 跑一遍 checklist。如果四个问题中有任何一个回答是「否」，立即拒绝，不要留恋。这个简单的动作，能让你避免至少 80% 的线上事故。

下次，你会在选库时像带防晒霜一样，优先考虑那些「涂上就能直接出门」的方案。