Claude Code做技术选型：怎么让它给出有依据的建议
有一次我问 Claude Code「用 Zustand 还是 Redux」，它给了我一个废话答案
那个答案大概是这样的：Zustand 更轻量适合小项目，Redux 更成熟适合大项目，取决于你的具体情况。
然后我换了一个问法，加了六行上下文，它给了我一个明确的结论：用 Zustand，理由是你的状态只在 Dashboard 模块内部共享，跨页面共享的需求极少，Redux 的 boilerplate 会让你的代码量增加 40% 但解决不了你实际存在的问题。
我直接用了。这才是有价值的技术选型建议。
为什么它总是给你「看情况」
Section titled “为什么它总是给你「看情况」”不是它不想给你答案，是你的问题本身没有给它做决策的材料。
技术选型不是一道有标准答案的题，它是一个在约束条件下的权衡。没有约束条件，就没有办法权衡，它只能给你所有选项的优缺点——也就是你问之前就能在文档里查到的东西。
问题是，大多数人问技术选型的方式是：「A 和 B 哪个好？」
这个问题等于让它猜你的约束条件，它猜不准，所以给你「各有优缺点」。
要让它给出有依据的建议，你要做的事情只有一件：把你的约束条件显式化，然后让它在你的约束条件下做推断。
我在这个问题上摸索了很久，最后总结出了一套专门用于技术选型的 Prompt 结构。
技术选型 Prompt 的四层结构
Section titled “技术选型 Prompt 的四层结构”第一层：项目现状——告诉它你的起点
Section titled “第一层：项目现状——告诉它你的起点”项目现状：- 技术栈：Next.js 14 App Router，Prisma，已用 NextAuth v5- 团队规模：1个人，我自己- 项目阶段：MVP，上线了三个月，月活 500- 时间约束：我这周只有两天时间做这件事这层的作用是锚定背景。它知道你是一人独立开发 MVP，就不会推荐一个需要专职 DevOps 维护的方案。
很多人会漏掉”时间约束”——这是最影响技术选型的隐性约束之一。一个理论上更优的方案，如果实现成本是两周，而你只有两天，那它就不是你的最优解。
第二层：具体问题——说清楚你要解决什么
Section titled “第二层：具体问题——说清楚你要解决什么”具体问题：我需要在用户登录后，在 Dashboard 的多个子页面之间共享用户的订阅状态（active/trialing/canceled），偶尔会根据订阅状态控制某些功能的显示和隐藏。这个状态更新不频繁，基本上是用户登录时读一次，订阅变化时更新一次。注意这里不是说「我要做状态管理」，而是描述具体的业务场景 ：什么数据、在哪里用、更新频率是多少。
这三个维度直接决定状态管理方案的选择。高频更新、跨多个不相关模块共享、需要时间旅行调试——这是 Redux 的场景。低频更新、局部共享、不需要复杂调试——这是 Zustand 或 Context 的场景。
第三层：已有选项和顾虑——告诉它你在纠结什么
Section titled “第三层：已有选项和顾虑——告诉它你在纠结什么”我在考虑的方案：- 方案 A：Zustand，听说学习成本低- 方案 B：React Context 放在 layout.tsx，不引入新库- 方案 C：直接从 Session 里读，每次需要时重新 fetch
我的顾虑：- 不想引入太多新依赖，项目现在依赖已经不少了- 担心 Context 在大组件树里有性能问题- Zustand 没用过，不确定上手成本这层让它知道你已经思考过哪些方向，以及你的顾虑是什么。
大多数教程不告诉你的细节： 把你的顾虑写进去，比只写候选方案更重要。顾虑是你真实的决策障碍，写出来之后它会直接告诉你这个顾虑是不是成立——有时候你担心的问题根本不存在，或者存在但在你的场景下不重要。
我有一次担心 Context 的性能问题，把这个顾虑写进去之后，它告诉我：在我的场景下（状态很少更新、只有三四个组件订阅），Context 的性能问题完全不会出现，这个顾虑不成立。直接省掉了我引入 Zustand 的时间。
第四层：推理要求——让它说出结论和理由
Section titled “第四层：推理要求——让它说出结论和理由”请按以下格式回答：1. 你的明确推荐（只选一个，不要「看情况」）2. 推荐这个的最关键理由（一条，最重要的那条）3. 这个方案在我的场景下的局限性（诚实地说）4. 什么情况下我应该重新考虑换方案这层是强制它做取舍，而不是列清单。
「只选一个」这四个字非常关键。不加这个约束，它会给你「两个都可以，取决于……」。加了这个约束，它必须在你的约束条件下做一个判断，然后为这个判断负责。
完整示例：实战演示
Section titled “完整示例：实战演示”这是我最近做的一个真实技术选型，实时通知功能用什么方案。
给它的完整 Prompt：
【项目现状】 Next.js 14 App Router，部署在 Vercel，月活 800，一人开发。 预算有限，不想引入需要单独收费的服务。
【具体问题】 需要在用户订阅状态变化时（Stripe Webhook 触发），实时通知前端更新 UI——比如订阅成功后立刻显示付费功能，不需要刷新页面。 通知频率：每个用户平均每月 2-3 次。 延迟要求：3 秒内更新就行，不需要毫秒级。
【在考虑的方案】
- 方案 A：SSE（Server-Sent Events）
- 方案 B：轮询，每 30 秒 fetch 一次状态
- 方案 C：WebSocket
【顾虑】
- Vercel 的 serverless 函数有执行时间限制，担心 SSE 和 WebSocket 不适用
- 轮询感觉太暴力，但实现最简单
请按以下格式回答：
- 明确推荐（只选一个）
- 最关键理由（一条）
它的回答（核心部分）：
推荐：方案 B（轮询），间隔改为 60 秒。
最关键理由：你的通知频率极低（月均 2-3 次），用户对 3 秒内更新已经满足，60 秒轮询完全达标，而且实现成本是三者最低的。
局限性：每个用户每小时产生约 60 次请求，800 月活的情况下峰值并发不高，但随着用户增长轮询成本线性增加。
何时重新考虑：月活超过 5000，或者有需要秒级响应的通知场景（如实时协作）。
关于你的顾虑：Vercel 对 SSE 和 WebSocket 的支持在 Edge Runtime 下是可行的，但确实有坑——SSE 在 serverless 函数里的连接管理比较复杂，对一人团队来说维护成本高。你的顾虑是成立的。
这个回答让我在五分钟内做了决定，然后花了半小时实现了轮询逻辑。
如果我直接问「SSE、轮询、WebSocket 哪个好」，我能得到的是三个方案的技术介绍，然后我自己再花一小时研究 Vercel 的限制，再花半小时做决定。
进阶：让它对自己的建议做压力测试
Section titled “进阶：让它对自己的建议做压力测试”这是技术选型里最有价值、也最少被用到的步骤。
方案确定之后，立刻让它质疑自己：
你刚才推荐了 [方案]。现在站在反对方的立场上，给我三个这个方案最可能在我的项目里出问题的场景，以及出问题的严重程度。
它会给你类似这样的回答：
场景一：六个月后月活增长到 5000，60 秒轮询产生的请求量可能触发 Vercel 的 API 路由频率限制，需要加 rate limiting 或者迁移到 SSE。严重程度：中（有预警时间，可以计划性迁移）。
场景二：如果你以后要做多人协作功能（多个用户同时编辑），轮询的延迟会导致协作体验很差。严重程度：高（届时必须换方案）。
场景三：……
这个压力测试让你在采用方案之前就知道它的天花板在哪里，什么情况下需要换。不会出现”用了半年突然发现这个方案根本撑不住”的情况。
坑一：以为它不熟悉某个新库，其实是我的问题描述太模糊
有一次我在问一个比较新的库（Upstash Redis 的 rate limiting 方案），它给的建议很保守，一直在推荐更老的方案。
我以为是它对这个库不够熟悉，其实是我的问题描述里没有说清楚”我已经在项目里用了 Upstash Redis，想直接用它的 rate limiting 功能”。
它不知道我已经有了这个依赖，所以在推荐时把”需要引入新服务”当成了成本，给了我一个不需要新依赖的保守方案。
解决方案： 在「项目现状」那层，把已有的依赖和服务列清楚，特别是付费服务和不常见的库。它知道你已经有了，就不会把引入它当成额外成本。
坑二：让它做了技术选型，但没问局限性，三个月后被坑了
有一次我问它数据缓存方案，它推荐了用 Next.js 的内置 fetch cache，我直接用了，当时觉得很方便。
三个月后项目需要做细粒度的缓存失效控制（某个用户的数据更新后立刻让他的缓存失效），发现 Next.js fetch cache 在这个场景下支持很差，最后花了两天迁移到 Redis。
如果当时问了「这个方案的局限性是什么、什么情况下需要重新考虑」，它一定会告诉我细粒度失效控制是它的弱项。
解决方案： 技术选型永远要问局限性和退出条件，不管方案看起来多合适。这是最省钱的保险。
让 Claude Code 给出有依据的技术建议，本质是把你脑子里的隐性约束变成显性输入。
它能推断，但它猜不到你没说的东西。你说得越具体，它的推断越精准，给的建议也就越能直接用。
最后一个实际的问题： 你最近做过的一次技术选型，当时是怎么做决定的——查文档自己研究、问 AI 拿到「各有优缺点」然后自己判断，还是别的方式？现在看来，当时的决定是对的还是出现了什么问题？