技术栈评估
评估项目当前的技术栈是否适合其目标，并在可维护性、性能或功能扩展受阻时推荐替代方案。
何时使用
用户询问：“是否有更好的技术栈？”，“应该使用什么栈？”，“应该重写吗？”
用户表达维护痛点：“难以扩展”，“笨重”，“一切都耦合在一起”
规划新的功能，而当前的技术栈无法支持
考虑从原型迁移到生产级
何时不使用
用户有特定的 bug 需要修复 —— 使用 debug-issue 代替
用户想要在当前技术栈上构建新的功能 —— 使用 draft-feature-plan 代替
项目很小（< 20 个文件）—— 直接阅读文件并建议
工作流程
在推荐技术栈更改之前，了解用户实际要解决的问题。询问（或从上下文推断）：
关注点 信号 典型解决方案
性能 “大数据集上慢”，“加载需要很长时间” 优化数据层（Polars，DuckDB，缓存），不一定是前端框架
可维护性 “难以扩展”，“一切都耦合在一起”，“添加功能需要修改 4 个文件” 结构重构（拆分单体，合并 API，添加类型安全）
功能扩展 “需要实时更新”，“需要多用户”，“需要移动应用” 添加功能（WebSocket，DB 持久性，React Native）
团队增长 “新开发人员入职”，“需要文档” 添加类型，测试，组件库，不一定是新框架
部署/托管 “Railway 太贵”，“需要扩展” 评估托管替代方案，容器化，服务器端
现代化 “感觉老旧”，“想要使用当前最佳实践” 增量升级（TypeScript，测试，CI），而不是重写
关键洞察：大多数“技术栈”问题实际上是可维护性或结构问题。React 重写不会解决 1,400 行单体处理器的问题。类型系统不会帮助如果 API 有 51 个端点，而 15 个就足够了。
使用 codebase-survey 技能的可维护性审计来产生证据：
# 文件大小审计
find . -type f \( -name "
.py" -o -name ".js" -o -name "
.ts" -o -name ".tsx" \) -not -path "
/node_modules/" -not -path "
/.git/" -not -path "
/venv/" | xargs wc -l | sort -rn | head -20
# 方法/函数计数审计
grep -c "def " app/core/allocation.py # Python 方法
grep -c "@router." app/api/routes.py # FastAPI 端点
grep -c "function " app/static/js/charts.js # JS 函数
产生可维护性等级（A-F）和具体目标。
层次 当前技术栈 做得好的地方 被阻塞的方面
后端框架 数据处理 前端 状态管理 样式 图表/可视化 托管 持久性
呈现 2-3 个选项，按努力与回报排序：
选项 努力 回报 何时选择
最小（结构重构） 低 中 可维护性是唯一问题，技术栈否则良好
增量（现代化前端） 中 高 前端是痛点，后端是坚实的
完全（新技术栈） 高 最大 多个阻塞，团队增长或多平台需求
对于每个选项，指定：
什么改变了 什么保持不变 迁移路径（可以增量完成吗？） 风险（数据丢失，停机时间，学习曲线）
每个推荐必须引用证据：“将 AllocationProcessor（1,402 行，36 个方法）拆分为 5 个专注的处理器”—— 不是“使用更好的框架”
“将 51 个 API 端点合并为 ~15 个带有图表注册表”—— 不是“添加 GraphQL”
“将前端迁移到 React + TypeScript 以实现组件隔离和类型安全”—— 不是“React 更好”
常见的技术栈特定模式
Python FastAPI + Pandas + Vanilla JS 仪表盘
这是数据密集型内部工具的常见模式。典型的演化：
阶段 技术栈 痛点 下一步
1 FastAPI + Pandas + Vanilla JS 适用于 1-2 个用户，5-10 个图表 无需更改
2 同样的技术栈，文件增长 添加图表需要修改 4 个文件 拆分处理器，合并 API
3 同样的技术栈，30+ 个图表，多用户 无持久性，无共享，前端是意大利面条 添加 React + TypeScript，考虑 DB
4 继续增长 大数据集上的性能问题 Polars/DuckDB，缓存，物化视图
何时保留 FastAPI
在以下情况下保留 FastAPI：
数据处理是核心价值（Pandas/Polars/NumPy 工作流）
团队对 Python 很熟悉
应用程序是内部/BI 的，而不是面向客户的
部署很简单（Railway，Heroku）
何时添加 React
在以下情况下添加 React：
仪表盘有 10+ 个交互式视图
多个开发人员在不同的选项卡上工作
需要可重用的组件（过滤器，表格，导出按钮）
API 边界的类型安全很重要
何时添加数据库
在以下情况下添加持久性：
需要多用户协作
历史数据/查询快照很重要
重启时会话丢失是不可接受的
需要持久性
by @adelvillar1