关于 tech-radar
tech-radar 是用于编写工程团队技术雷达的 skill，采用 ThoughtWorks 格式。它按象限和推荐环分类技术，并包含理由、决策记录及维护流程。
主要功能
- 01四类技术象限与四级推荐环
- 02附理由和日期的技术条目
- 03记录推荐环变更的决策轨迹
- 04雷达审查与维护流程
适用场景
- 01整理团队标准及待评估技术
- 02规划淘汰处于 Hold 环的技术
- 03每六个月审视技术选择
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/tech-radar确认已加载。
详细介绍
技术雷达
为工程团队生成一份完整的技术雷达文档。雷达为团队技术栈中的每项重要技术明确共同立场——哪些应标准化采用、哪些应试用、哪些应评估，以及哪些应主动停止使用。遵循 ThoughtWorks 技术雷达格式：四个象限（技术实践、工具、平台、语言与框架），每个象限包含四个环（采用、试用、评估、暂缓）。每项技术条目（“条目”）都应标注所属环、附上一段理由，并注明日期。加入决策记录，说明哪些条目发生了变动以及原因，并制定团队可执行的维护流程，以保持雷达内容更新。
必需输入
如果用户尚未提供，请询问以下信息：
- 团队或公司名称——用于文档标题
- 当前技术栈——列出团队当前使用的所有重要技术、工具、语言和平台
- 正在积极评估的技术——团队当前正在试用或考虑的工具或框架
- 计划弃用或迁出的技术——团队希望停止使用或正在积极迁移离开的技术
- 战略性技术选择——公司有意重点投入的技术（例如，“我们全面采用 Kubernetes”或“迁移到事件驱动架构”）
- 团队背景——团队规模、产品领域以及任何限制条件（法规、合规、供应商锁定方面的顾虑）
如果提及某项技术但未标注所属环，请根据提供的理由确定合适的环。如果无法确定应归入哪一环，请询问。
输出格式
技术雷达：[团队 / 公司名称]
版本：[月份 年份] 维护者：[团队名称 / 架构委员会 / CTO 办公室] **评审周期：**每半年一次（每 6 个月） 下次评审：[月份 年份 + 6 个月]
如何阅读本雷达
本雷达反映了[团队 / 公司名称]对当前使用、评估和淘汰的技术的看法。可使用本雷达，确保技术选择一致、帮助新工程师熟悉团队，并围绕技术栈开展有条理的讨论。
象限对技术类型进行分类：
| 象限 | 内容 |
|---|---|
| 技术实践 | 方法、模式和实践（例如，主干开发、事件溯源） |
| 工具 | 用于开发和交付流程的软件工具（例如，代码检查工具、CI 系统、可观测性平台） |
| 平台 | 基础设施和托管环境（例如，AWS、Kubernetes、Snowflake） |
| 语言与框架 | 编程语言和应用框架（例如，Go、React、FastAPI） |
环表示我们的建议：
| 环 | 含义 | 应采取的行动 |
|---|---|---|
| 采用 | 经过行业验证且适合我们——我们的标准选择 | 新项目默认使用；无需特别说明理由 |
| 试用 | 值得推进——我们正在有限的生产环境中试用 | 在范围明确的环境中使用，并接受架构监督；分享经验 |
| 评估 | 值得探索——我们尚未在生产环境中使用 | 进行技术预研、原型开发或调研；未经评审，不要用于生产环境 |
| 暂缓 | 不要使用该技术启动新项目 | 完成现有承诺；不要扩大使用范围；规划迁移 |
象限 1：技术实践
Adopt
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [技术名称，例如，主干开发] | [月份 年份] | [一句话说明：为什么采用它，以及它取代了什么] |
| [技术名称] | [月份 年份] | [一句话说明采用理由] |
| [技术名称] | [月份 年份] | [一句话说明采用理由] |
[技术名称] — Adopt [一段理由说明。解释该技术解决了什么问题、为何适合你们的情境，以及团队在应用前应了解什么。引用任何内部经验，例如：“我们在 2024 年将其推广到 8 项服务中，合并冲突减少了 40%。”]
[对 Adopt 环中的每项技术重复上述内容。]
Trial
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [技术名称] | [月份 年份] | [一句话说明：我们正在测试什么，以及测试范围] |
[技术名称] — Trial [一段说明。我们正在试用什么？涉及哪些团队或服务？我们要验证什么假设？什么情况会促使我们将其移至 Adopt 或 Hold？]
Assess
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [技术名称] | [月份 年份] | [一句话说明：我们感兴趣的原因] |
[技术名称] — Assess [一段说明。为什么我们对它感兴趣？要将其移至 Trial，需要看到什么？谁负责评估？]
Hold
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [技术名称] | [月份 年份] | [一句话说明：为什么停止采用，以及什么将取代它] |
[技术名称] — Hold [一段说明。为什么我们要暂缓采用它？迁移路径是什么？仍在使用它的团队最终应达到什么状态？]
象限 2：工具
Adopt
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [工具名称，例如，GitHub Actions] | [月份 年份] | [一句话说明采用理由] |
| [工具名称] | [月份 年份] | [一句话说明采用理由] |
[工具名称] — Adopt [一段理由说明。为什么它是我们的标准工具？它在我们的情境中有哪些优势？团队应遵循哪些配置或使用模式？]
[对 Adopt 环中的每项工具重复上述内容。]
Trial
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [工具名称] | [月份 年份] | [一句话说明：我们正在测试什么] |
[工具名称] — Trial [一段理由说明和试用范围。]
Assess
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [工具名称] | [月份 年份] | [一句话说明：我们评估它的原因] |
[工具名称] — Assess [一段说明：是什么引发了兴趣、由谁评估，以及评估时间线。]
Hold
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [工具名称] | [月份 年份] | [一句话说明：什么将取代它] |
[工具名称] — Hold [一段说明：弃用理由和迁移路径。]
象限 3：平台
Adopt
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [平台名称，例如，AWS EKS] | [月份 年份] | [一句话说明采用理由] |
| [平台名称] | [月份 年份] | [一句话说明采用理由] |
[平台名称] — Adopt [一段说明。该平台提供什么？它的使用边界是什么？团队应遵循哪些内部黄金路径配置？]
[对 Adopt 环中的每个平台重复上述内容。]
Trial
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [平台名称] | [月份 年份] | [一句话说明：试用范围] |
[平台名称] — Trial [一段理由说明和试用边界。]
Assess
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [平台名称] | [月份 年份] | [一句话说明：我们探索它的原因] |
[平台名称] — Assess [一段评估计划。]
Hold
| 技术 | 开始采用时间 | 备注 |
|---|---|---|
| [平台名称] | [月份 年份] | [一句话说明：迁移目标和时间线] |
[平台名称] — Hold [一段说明：是什么促使我们决定暂缓采用、迁移目标和时间线。]
象限 4：语言与框架
采用
| 技术 | 起始时间 | 备注 |
|---|---|---|
| [语言/框架，例如 Go] | [月份 年份] | [一句话说明理由] |
| [语言/框架] | [月份 年份] | [一句话说明理由] |
[语言/框架] — 采用 [一段文字。此语言或框架用于什么？团队需要具备怎样的熟练程度？作为标准选择的一部分，是否会搭配其他框架或库？]
[对每种“采用”环技术或框架重复此内容。]
试用
| 技术 | 起始时间 | 备注 |
|---|---|---|
| [语言/框架] | [月份 年份] | [一句话：范围明确的用例] |
[语言/框架] — 试用 [一段说明理由的文字。]
评估
| 技术 | 起始时间 | 备注 |
|---|---|---|
| [语言/框架] | [月份 年份] | [一句话：关注原因] |
[语言/框架] — 评估 [一段评估计划。]
暂缓
| 技术 | 起始时间 | 备注 |
|---|---|---|
| [语言/框架] | [月份 年份] | [一句话：说明原因和迁移路径] |
[语言/框架] — 暂缓 [一段文字：弃用理由、现有系统的责任，以及退役时间表。]
决策记录
此日志记录自雷达首版以来的所有环级别变更。请据此了解我们的技术选择如何演进。
| 技术 | 象限 | 原环级别 | 新环级别 | 版本 | 原因 |
|---|---|---|---|---|---|
| [名称] | [象限] | — | 采用 | [月份 年份] | 首次列入 — [一句话说明原因] |
| [名称] | [象限] | 评估 | 试用 | [月份 年份] | [促成此次调整的因素 — 证据、团队反馈、生产试用结果] |
| [名称] | [象限] | 试用 | 采用 | [月份 年份] | [采用理由 — 使用结果、团队满意度、已验证的规模能力] |
| [名称] | [象限] | 采用 | 暂缓 | [月份 年份] | [移至“暂缓”的原因 — 更好的替代方案、安全顾虑、成本、供应商问题] |
| [名称] | [象限] | — | 暂缓 | [月份 年份] | 首次列入 — 因为[原因]而直接列入“暂缓” |
雷达维护流程
参与人员
- 架构评审组 / CTO 办公室 — 最终决定环级别
- 所有工程师 — 通过[频道或表单]提交技术点提名
- 技术负责人 — 筛选提名，并为评审会议准备提案
更新频率
| 活动 | 频率 | 负责人 |
|---|---|---|
| 接受新的技术点提名 | 持续进行 — 任何工程师均可通过[频道]提交 | 任何人 |
| 提名筛选 | 每月 | 技术负责人 |
| 全面雷达评审会议 | 每 6 个月 | 架构组 |
| 发布雷达更新 | 每 6 个月 | [负责人姓名或角色] |
如何提名技术点
- 通过[Slack 频道 / 表单 URL]提交，内容包括：技术名称、象限、建议的环级别，以及一段说明理由的文字。
- 技术负责人会在 2 周内进行评审，并将其安排在下一次评审会议上，或要求补充信息。
- 在评审会议上，架构组进行讨论并投票。简单多数票决定结果；票数相同时，暂列“暂缓”，等待更多证据。
- 获批的技术点将在会议结束后 1 周内添加到雷达文档和决策记录中。
环级别变更标准
| 升至“采用”的条件 | 升至“试用”的条件 | 升至“评估”的条件 | 转为“暂缓”的条件 |
|---|---|---|---|
| 已在多个生产系统中验证；团队普遍接受过培训；具备明确的运维手册 | 至少有一个生产用例正在运行；已落实架构监督；已记录经验总结 | 已确定具体用例；已完成或正在进行技术验证；至少有 2 名工程师感兴趣 | 存在更好的替代方案；已知的安全/合规风险；战略方向发生变化；维护负担不可接受 |
对本雷达有疑问：[Slack 频道] | 提交提名：[URL 或频道]
质量检查
- 每个技术条目都有书面理由说明段落，而不只是表格中的一行
- 每个技术条目的决策记录中至少填写了初始归类日期
- 暂缓环中的条目包含明确的迁移路径或目标技术，而不只是“停止使用”
- 已提供各环的定义，并说明每个环的含义以及工程师应采取的措施
- 维护流程包括：提名渠道、审核频率、决策者以及环级变更标准
- 输入中被标为“战略性押注”的技术已归入采纳环（若已验证）或试用环（若正在推广）
- 被确定为需要弃用的技术已归入暂缓环，并在理由中提及替代方案
反模式
- 不要在缺乏证据证明某项技术已在团队规模下得到验证时，将其归入采纳环——过于理想化的归类会误导工程师
- 不要添加没有书面理由说明段落的技术条目——缺少上下文的表格行毫无用处
- 不要创建未指定明确迁移路径或目标技术的暂缓环条目
- 不要跳过维护流程——没有更新流程的技术雷达会在两个季度内过时
- 不要省略环的定义——工程师需要知道每个环的含义，以及应据此采取什么措施