在 AI 加持下,技术选型这件事已经不只是"你愿不愿意学",而是"你有没有来得及阻止"。
背景
现在的节奏你应该感受到了:
大模型能生成代码、部署脚本、CRUD 界面,甚至能帮你生成一整套微服务架构。看起来开发门槛变低了,但实际上,技术栈扩散的速度却越来越快。
前一秒还在用 Python 写服务,后一秒已经把 LangChain、RAG、Vector DB 给你上到线上环境。甚至你根本没来得及开个技术评审会,项目就已经"跑起来"了。

如果你没有专门的架构组、不是大厂那种团队规模,背后没有 Infra 团队兜底,AI赋能编码就很容易从"创新"变成"事故"。(真实体验)
所以,需要用某个框架来限定这种意外发生!
什么是技术雷达?
一句话解释:技术雷达 = 团队的技术共识地图 + 选型建议库 + 禁用黑名单

这不是某种高大上的"架构治理平台",它非常朴素:
- 一个文档或可视化页面,记录团队允许、推荐、尝试或禁止的技术
- 有标准的分类方式(比如 Adopt / Trial / Assess / Hold)
- 有合理的分组维度(比如 工具 / 框架 / 平台 / 语言)
- 最重要的是,它可读、可更新、有共识
举个例子:
css
{
"label": "LangChain",
"group": "Frameworks",
"ring": "Trial",
"description": "适合构建简单的 LLM 应用原型,暂不推荐用于核心生产服务"
}
起步,就是这样一个简单的例子。
当然,也有复杂的版本:
css
{
"entries": [
{
"label": "PostgreSQL",
"ring": "Adopt",
"quadrant": "Platforms",
"active": true,
"description": "主力关系型数据库,适用于99%的业务系统。推荐默认使用。"
},
{
"label": "MongoDB",
"ring": "Hold",
"quadrant": "Platforms",
"active": false,
"description": "在部分早期项目中使用,但维护成本高、权限体系薄弱,不建议在新项目中选用。"
},
{
"label": "Go + Wire + Fx",
"ring": "Adopt",
"quadrant": "Languages & Frameworks",
"active": true,
"description": "Go作为主要微服务语言,配合Wire进行依赖注入,适合稳定高并发服务场景。"
},
{
"label": "LangChain",
"ring": "Trial",
"quadrant": "Frameworks",
"active": true,
"description": "快速构建大模型应用的Python框架,推荐在原型验证和非核心路径中试用。"
},
{
"label": "Vector DB: Qdrant",
"ring": "Assess",
"quadrant": "Platforms",
"active": true,
"description": "新兴的开源向量数据库,支持快速向量检索,考虑用于AI检索场景替代Milvus。"
},
{
"label": "PaddleOCR + FastAPI",
"ring": "Trial",
"quadrant": "Tools",
"active": true,
"description": "适用于轻量化文档识别服务,已在内部审批流转系统中集成试点。"
},
{
"label": "Vue3 + Vite + Pinia",
"ring": "Adopt",
"quadrant": "Languages & Frameworks",
"active": true,
"description": "推荐Web端主力技术栈,支持现代化组件化开发,已在多个前台系统落地。"
},
{
"label": "Java + SpringBoot 2.7",
"ring": "Adopt",
"quadrant": "Languages & Frameworks",
"active": true,
"description": "老系统主力框架,适用于对 Java 生态有依赖的流程类/审批类服务。"
},
{
"label": "OpenAI API + Function Call",
"ring": "Trial",
"quadrant": "Platforms",
"active": true,
"description": "面向业务场景进行智能化编排的推荐方案,需结合 RAG 架构审慎使用。"
},
{
"label": "LLM Prompt Management: Langfuse",
"ring": "Assess",
"quadrant": "Tools",
"active": true,
"description": "面向 LLM 项目的 prompt 管理和 A/B 测试平台,正在评估引入是否可控。"
},
{
"label": "Jenkins",
"ring": "Hold",
"quadrant": "Tools",
"active": false,
"description": "已被 GitHub Actions + ArgoCD 替代为主力CI/CD平台,仅用于维护旧流水线。"
},
{
"label": "K8s Operator(自定义资源)",
"ring": "Assess",
"quadrant": "Techniques",
"active": true,
"description": "面向复杂 DevOps 任务的自动化运维尝试,需评估团队编排能力。"
}
]
}
这个 JSON 可以直接配合 github.com/bicatu/tech... 来生成可视化图谱。
工具
如果不想自己搭建,也可以直接引用开源:www.thoughtworks.com/radar

雷达分四个象限:技术手段(Techniques)、工具(Tools)、平台(Platforms)、语言与框架(Languages & Frameworks)
每个条目根据成熟度被归类为:
- Adopt(推荐使用) :我们已实践并认可,广泛使用;
- Trial(尝试) :部分团队用过,推荐试点项目;
- Assess(评估) :值得关注,有潜力,候选技术;
- Hold(谨慎/停用) :历史遗留、或踩坑较多,建议避开。
可以挂在自己内网里,自定义公司的版本,并设定"每季度一次更新"机制等等。
这不是形式主义,而是团队技术资产的盘点,经验之谈:在AI加速狂奔的当下,如果没有一个指引方向,代码最终的负债一定会失控。

📌 如果你觉得这篇文章对你有帮助,欢迎点赞收藏,你也可以加威 atar24,有交流群,抽奖 + 技术福利持续发放中!