技术栈最容易犯的第一个错#

上一章刚把 《拿到 PRD 后先做什么：需求收敛、范围裁剪与验收口径》 收住，很多人下一步就会本能地问一句：那技术栈到底怎么定？

这个问题本身没错，错的是问法。
如果这句话背后的真实意思是“我们现在就把前端框架、后端框架、数据库、ORM、队列、测试、部署、监控、AI SDK 一次定完”，那项目大概率又要开始漂了。

原因很简单：技术栈不是介绍页上的名词清单，而是一连串工程承诺。每定下一项，后面都会跟着目录结构、上下文、脚手架、测试方式、CI、部署和迁移成本。AI 越强，这个问题越大。因为它太会给你一份“看上去已经很完整”的答案了，甚至还能顺手把目录、脚手架和 demo 一起补出来。问题在于，那些补出来的内容，很多时候不是在帮你节省决策，而是在替你提前锁死还没想清楚的东西。

所以我现在对“技术栈定盘”这件事的理解，和以前不太一样了。

它不是项目开局的仪式，而是一个跟着需求逐步收紧的过程。
真正应该尽早定下来的，往往只有最小底板；真正昂贵的那些选择，最好等到具体问题浮出来再做。

一句话原则

技术栈不是一开始就要定死的总清单，而是随着需求收敛、风险暴露和验证结果，分阶段做出的工程决策。

一开始真正该定的，通常只有底板#

项目刚开始，最怕的不是“定得不够多”，而是“定得太像终局”。
很多产品在这个阶段，其实只需要先把下面几件事定住：

1. 主语言和基本类型系统。

   比如你已经明确这条线以 Web 技术为主，那先定 TypeScript 这种语言级底板通常没有问题。它解决的是团队沟通、接口约束和 AI 协作成本，不是在替未来拍板某个具体框架。

2. 最基础的交互层和开发底座。

   很多项目在起步时，先用 React 搭一个最小交互层，再配 Vite 或 Bun 这种足够轻的开发底座，其实就已经够了。这里的重点不是“React 一定是最优解”，而是你先需要一个能让问题尽快暴露出来的工作台。

3. 最低限度的工程约束。

   包管理怎么做、代码风格怎么收、lint/typecheck 到什么程度、仓库是不是 monorepo，这些可以早一点定。因为它们决定的是协作效率和基本秩序，不会直接把产品架构钉死。

4. 哪些东西现在还没有资格被决定。

   这一步反而最重要。一个成熟团队不会假装自己什么都知道，而是会明确写下“这几项现在先不拍板，等问题更具体再定”。

真正不适合在开局就拍死的，通常是这些高耦合选择：

• 数据库和 ORM，因为它们高度依赖真实数据模型和访问模式。
• 消息队列、异步编排、Agent 框架，因为它们依赖任务形态，而不是依赖想象。
• 宿主方案，比如到底是 Web、PWA、Tauri、Expo、Lynx 还是别的东西，因为这取决于能力边界，而不是取决于个人偏好。
• 重型 Harness，比如 E2E、Playwright、大规模压测，因为这类成本应该跟着项目阶段长，不应该先把全套基建包完。

换句话说，一开始先把项目“跑起来”就够了，不要急着把未来三个月要用到的所有武器都挂上去。

技术选型应该跟着问题往前推#

技术栈真正靠谱的定法，不是“凭经验一口气说完”，而是每次围绕一个具体问题往前推一步。

我更推荐下面这个顺序：

1. 先把当前要解决的工程问题写具体。

   不要问“后端用什么框架”，而要问“这一阶段到底要扛什么压力”。
   是要处理高并发实时连接，还是只是做一个简单管理后台？
   是要做本地优先同步，还是只是普通 CRUD？
   是要接系统级能力，还是只是在浏览器里渲染一个页面？

   问题一旦具体，技术选型才会从“喜好之争”变成“约束匹配”。

2. 让 AI 给你候选方案，不要让 AI 替你拍板。

   AI 最适合干的，不是替你说“最好的技术栈就是 X”，而是基于当前约束，一次性列出几种候选方案，并把它们的差异摊开。
   你真正想从 AI 那里拿到的，应该是：

   • 候选方案 A、B、C 分别适合什么约束
   • 每个方案最容易踩什么坑
   • 它们的学习成本、迁移成本、生态成熟度和 AI 友好度分别怎么样
   • 当前阶段最值得先验证的风险是什么

3. 判断这次选型到底需不需要“查新”。

   这是 AI 时代特别容易被忽略的一步。
   很多人默认 AI 知道一切，但模型的知识库天然有时差，而且对很多技术的理解还会停留在旧印象上。结果就是：它给出的方案未必错，但可能已经不是当前主流；或者它知道一个工具存在，却不知道它最近一年是不是已经大幅成熟，或者反过来已经明显掉队。

   所以技术选型前，最好先问自己一句：这次要解决的问题，到底是“稳定优先”，还是“性能/宿主能力/新领域优先”？

   如果是稳定优先，比如内部系统、管理后台、标准业务服务，那成熟、保守、大家都熟的栈完全可能就是更好的答案。
   如果是性能敏感、本地宿主能力很多、图形交互很重、AI 基础设施变化很快，或者本来就处在一个变化特别快的领域，那就不要只靠模型回忆，直接要求 AI 去查官方文档、release notes、迁移指南和近期生态对比。

4. 用最小 demo 验证最危险的假设。

   这一步是很多团队最容易偷懒的地方。
   选型一旦看起来“逻辑很顺”，大家就想直接开写功能。但真正贵的，不是选错一个按钮库，而是把核心路径押在了一个未经验证的前提上。

   所以最小 demo 不应该是“做个首页看看”，而应该是“把最难、最容易翻车的那一段先跑通”。
   如果担心的是实时流式渲染，那 demo 就该验证流式中断、重连和错误恢复。
   如果担心的是原生宿主能力，那 demo 就该验证权限、打包、文件读写、系统通知这些真实能力。
   如果担心的是大数据量渲染，那 demo 就该直接测渲染和交互表现，而不是只画几张静态图。

5. 把结论写回当前阶段文档，而不是写进脑子里。

   技术选型最怕口头共识。
   每次选完，至少要落三件事：

   • 这次为什么选它
   • 这次明确没选什么，以及为什么没选
   • 什么时候需要重新评估

   这样后面新开 issue、新来的人、新接手的 AI，才知道这不是拍脑袋决定的。

一个更好用的 AI 选型提示词

与其问 AI“这个项目用什么技术栈”，不如直接把问题问成下面这样：

基于以下当前阶段需求，而不是基于项目终局想象，给我 3 个技术方案：

- 当前要解决的问题：
- 当前明确不做的事：
- 团队已有经验：
- 性能/宿主/部署约束：
- 希望优先优化的是稳定性、开发速度，还是性能：

请按下面格式输出：
1. 方案概述
2. 适合的前提
3. 明显短板
4. 迁移成本
5. 当前是否需要查最新资料
6. 最值得先做的最小 demo 是什么

不要直接给唯一答案，也不要假设所有未来需求都已经确定。

这个提示词真正有用的地方，不是让 AI 替你做决定，而是逼它把“适用前提”和“验证点”一起说出来。

什么时候该保守，什么时候该主动追新#

很多人会把技术选型理解成一种立场问题：要么迷信新栈，要么迷信老栈。
其实都不对。真正该判断的，是这次项目的主要风险到底在哪。

如果风险主要在业务本身，那技术就应该稳一点。
如果风险主要在底层能力，那技术就应该更贴近当下主流。

可以这样粗暴地判断：

• 做后台、运营系统、常规内容站、标准 API 服务，优先看成熟度、维护成本、团队熟悉度。这个时候“老一点但成熟”的栈，往往 ROI 更高。
• 做图形编辑器、本地桌面宿主、复杂原生能力、实时协作、AI infra、性能敏感服务，优先看当前生态和能力上限。这个时候如果还完全照着两三年前的印象选，风险反而更大。

比如一提到移动或跨端宿主，很多团队脑子里还是只有 React Native、WebView 或桌面壳这几条老路线。但如果当前需求真的把性能、原生渲染、跨端一致性放在很前面，那就应该把 Lynx 这类更新的宿主方案一并拉进比较，而不是默认它不存在。

这里有一个很现实的点：
不是所有“新”的东西都值得上，也不是所有“老”的东西都该被淘汰。
真正要看的，是它是不是刚好解决了你当前最贵的那个问题。

所以不要追着“最新趋势”跑，也不要把“我们一直都这么做”当成理由。
项目需要的是匹配，不是情怀。

最小 demo 不是可选项，而是技术选型的过滤器#

只靠文档和对比表做技术选型，通常只能排除明显不合适的方案，排不掉那些“看起来没问题，真正一上手才暴露代价”的坑。

最小 demo 的价值，就是把纸面判断变成真实摩擦。

一个合格的 demo，至少应该满足三件事：

1. 它只验证关键路径，不顺手扩成半个正式项目。
2. 它要覆盖当前最危险的假设，而不是最容易做的页面。
3. 它需要有明确的通过标准，否则做完也只是“感觉还行”。

最小 demo 还会顺手帮你识别另一类经常被忽略的问题：AI 能不能稳定写这套东西。

这件事在 AI Native 开发里特别关键。
有些技术从架构上没问题，但 AI 对它的语料熟悉度差、常见坑少、代码生成质量不稳定，那它在真实协作里就会变成一笔持续成本。
所以 demo 不只是验证“技术能不能跑”，也在验证“AI 以后能不能低摩擦地帮你继续做”。

demo 要测什么，不要测什么

如果你担心的是技术路线可行性，demo 就应该直接顶在风险点上：

• 关心本地宿主能力，就测权限、文件读写、系统通知、打包和升级链路。
• 关心流式交互，就测中断、重试、取消、状态回放，而不是先把聊天界面画漂亮。
• 关心图编辑或复杂可视化，就测加载、缩放、拖拽、保存和大图性能，不要先做 Landing Page。

反过来，如果一个 demo 只是把脚手架、登录页、列表页快速搭完，那它大概率验证不了任何真正重要的东西。

GraphSpec 这个案例，真正提醒我的是什么#

如果只看表面，GraphSpec 很容易被理解成“现在先把整套栈定出来，再开工”。
但这个项目一路讨论下来，给我的反而是相反的提醒：产品理解都还没完全对齐的时候，技术选型定得越满，后面越容易把错误方向做得很扎实。

它最开始的材料只是一个粗糙 PRD，真正推进项目的第一步，不是选框架，而是先把问题地图、阶段边界和产品心智模型收住。后面之所以会反复讨论，本质上不是为了纠结某个库，而是为了回答更上位的问题：主资产到底是什么，CLI、图数据、扫描器、可视化各自扮演什么角色。

GraphSpec 里的具体教训

在 GraphSpec 这条线里，过早把“scanner 驱动的文件依赖图”当成产品主线，就是一个典型例子。

如果这个误解不先纠正，后面哪怕技术栈选得再漂亮，AI 也只会沿着错误方向不断补全实现。后来真正有价值的动作，不是继续往下写代码，而是把总纲收成一份更像项目章程的东西，再让后续 issue 去逐步细化。

相关文档可以参考：

1. proposal.md
2. design.md

这也是为什么我现在更倾向于这样处理技术栈：

1. 先定最小底板，比如语言、交互层、基本工程约束。
2. 具体到某个问题，再做那一层的技术对比。
3. 对变化快的领域，明确要求 AI 查新。
4. 用最小 demo 先过风险点，再决定是否真的纳入主线。

如果这一章最后只留下五句话#

• 技术栈不是项目开局要一次定完的愿望清单，而是一组分阶段收紧的工程承诺。
• 一开始先定最小底板就够了，很多高耦合选择应该延后到具体问题出现时再做。
• AI 适合帮你拉候选、做对比、暴露风险，不适合替你直接拍板。
• 稳定型需求可以保守，性能敏感或变化快的领域必须要求 AI 查最新资料。
• 任何重要技术路线，在真正写功能前，最好都先过一个最小 demo。

下一篇：《仓库起盘：先搭一个能承载 AI 协作的骨架》