浏览 AI 知识库
技术栈怎么选：优先匹配现有项目、团队和部署环境
技术栈不是越新越合适。现有代码、团队经验、部署环境和维护期限，往往比框架热度更能决定一次改造是否划算。
先比较关键条件，再作选择
把自己的条件代入判断项；没有证据的维度保留未知，不用印象替代结论。
只为加一个后台表格，值得把整个技术栈换掉吗
已有 Express + PostgreSQL 项目要加一个后台表格，AI 推荐换成全新框架和数据库，只因为新组合更热门。迁移成本远大于功能本身。
- 硬约束与偏好分开
- 现有系统优先纳入比较
- 迁移、培训和运维成本可见
候选技术栈都实现同一个‘上传发票并保存草稿’
| 维度 | 栈 A | 栈 B | 决定 |
|---|---|---|---|
| 已有仓库集成 | 复用现有 Node/React/Postgres | 需新增语言与运行时 | A 少一条迁移链 |
| 开发 1 条闭环 | 2 小时完成上传、校验、保存 | 4 小时完成基础接入 | 记录真实耗时，不看 Hello World |
| 测试 | 沿用现有 Playwright 与数据库夹具 | 测试工具需重新搭建 | A 更快进入回归 |
| 部署 | 目标平台已有镜像和健康检查 | 冷启动与文件存储待验证 | B 保留为后续评估 |
| 未知项 | 并发上传上限待压测 | 权限中间件与备份待确认 | 两者都不能直接生产 |
先把本例的条件、限制和目标摆出来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 团队熟悉 TypeScript/Express/React；部署在现有 Docker 环境；需求是内部 CRUD 与 CSV 导出。 |
| 不能越过的边界 | 先匹配现有技术和运维能力；只有硬约束无法满足才引入新组件；动态版本与支持期查官方资料。 |
| 要交付的结果 | 技术选型约束表 |
项目技术栈怎么选，哪些条件会改变最后选择
| 判断条件 | 本例怎么核对 | 本例归类 |
|---|---|---|
| 现有系统兼容 | 是否能复用语言、运行时、鉴权、数据库、组件和监控；迁移成本由谁承担。 | 集成成本 |
| 团队能力 | 至少两人能维护吗，测试和排错工具是否熟悉，交接材料能否得到。 | 可维护性 |
| 部署与运行 | 目标平台支持的运行时、构建、冷启动、存储、网络和费用边界是什么。 | 运行条件 |
| 数据与安全 | 事务、并发、权限、合规、备份和恢复需要到什么程度。 | 风险要求 |
| 最小原型实测 | 用同一纵向功能在候选栈中验证开发、测试、构建和部署，不用简单 Hello World 比较。 | 真实证据 |
项目技术栈怎么选：按本例条件得到的结论
技术选型约束表
约束表显示现有栈已满足认证、表格、导出和部署；新增只需沿用 ORM 与组件库。另一个框架在本次没有解决新增约束，因此不引入。选择理由、代价和未来触发重评条件写明。
边界变化后需要重新判断
当吞吐、合规或团队边界发生实质变化时重新评估；“以后可能需要”不能直接成为迁移理由。
为什么“沿用现有栈后实现仍很复杂”还不能交付
沿用现有栈后实现仍很复杂
- 原因
- 复杂来自需求或数据模型，不一定来自框架
- 怎么改
- 先定位具体瓶颈并做小型验证，再决定是否增加技术