浏览 AI使用教程
技术栈怎么选：优先匹配现有项目、团队和部署环境
技术栈不是越新越合适。现有代码、团队经验、部署环境和维护期限，往往比框架热度更能决定一次改造是否划算。
先比较关键条件，再作选择
把自己的条件代入判断项；没有证据的维度保留未知，不用印象替代结论。
只为加一个后台表格，值得把整个技术栈换掉吗
已有 Express + PostgreSQL 项目要加一个后台表格，AI 推荐换成全新框架和数据库，只因为新组合更热门。迁移成本远大于功能本身。
- 硬约束与偏好分开
- 现有系统优先纳入比较
- 迁移、培训和运维成本可见
内部表格与 CSV 导出的条件式比较
| 约束 | 现有 TypeScript/Express/React | 另引语言与框架 | 如何决定 |
|---|---|---|---|
| 团队维护 | 已有两名维护者和现成工具 | 要明确谁负责新运行时 | 没有维护人时不引入 |
| 同题原型 | 在现有后台增加表格查询与CSV导出 | 实现相同权限、筛选与导出契约 | 比较实际实现记录，当前均未计时 |
| 部署 | 当前Docker与监控可复用 | 镜像、健康检查与日志待验证 | 先消除真实阻断，不凭品牌选择 |
| 数据 | 沿用PostgreSQL与既有事务 | 不能仅为一个表格换数据库 | 只有现有方案不满足硬约束才重评 |
本表依据所给项目条件推导选择，不包含2小时/4小时跑分或两套真实原型结果。
什么证据足以推翻沿用结论
例如实测导出无法满足约定的数据量与时限，且已定位瓶颈不能通过流式导出或现有栈调整解决，才研究替代方案。应写输入规模、环境、指标与替代成本；需求尚未量化时先补量化，不直接迁移。
先把本例的条件、限制和目标摆出来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 团队熟悉 TypeScript/Express/React；部署在现有 Docker 环境；需求是内部 CRUD 与 CSV 导出。 |
| 不能越过的边界 | 先匹配现有技术和运维能力；只有硬约束无法满足才引入新组件；动态版本与支持期查官方资料。 |
| 要交付的结果 | 技术选型约束表 |
项目技术栈怎么选，哪些条件会改变最后选择
| 判断条件 | 本例怎么核对 | 本例归类 |
|---|---|---|
| 现有系统兼容 | 是否能复用语言、运行时、鉴权、数据库、组件和监控；迁移成本由谁承担。 | 集成成本 |
| 团队能力 | 至少两人能维护吗，测试和排错工具是否熟悉，交接材料能否得到。 | 可维护性 |
| 部署与运行 | 目标平台支持的运行时、构建、冷启动、存储、网络和费用边界是什么。 | 运行条件 |
| 数据与安全 | 事务、并发、权限、合规、备份和恢复需要到什么程度。 | 风险要求 |
| 最小原型实测 | 用同一纵向功能在候选栈中验证开发、测试、构建和部署，不用简单 Hello World 比较。 | 真实证据 |
项目技术栈怎么选：按本例条件得到的结论
技术选型约束表
约束表显示现有栈已满足认证、表格、导出和部署；新增只需沿用 ORM 与组件库。另一个框架在本次没有解决新增约束，因此不引入。选择理由、代价和未来触发重评条件写明。
边界变化后需要重新判断
当吞吐、合规或团队边界发生实质变化时重新评估；“以后可能需要”不能直接成为迁移理由。
为什么“沿用现有栈后实现仍很复杂”还不能交付
沿用现有栈后实现仍很复杂
- 原因
- 复杂来自需求或数据模型，不一定来自框架
- 怎么改
- 先定位具体瓶颈并做小型验证，再决定是否增加技术