tech-radar-context

tech-radar-context

概述

展示 Tikal 的观点，了解与当前提示词相关的技术，助力根据以色列技术雷达做出技术栈选择。此技能的工作方式类似于 team-discover，但其搜索范围是 Tikal Tech Radar 数据集（从 https://tikalk.com/radar.json 实时获取），而不是团队 CDR 索引：它会从提示词中提取候选技术，将其与雷达 条目匹配，并注入一张简明的 技术雷达上下文表格（环、象限、Tikal 的“原因”观点），并为任何处于 Stop 的技术提供符合 Tikal 倾向的替代方案。

雷达分为四个象限——DevOps、Backend、AI/ML、Web/Mobile——以及四个采用环：

环	含义	指引
Try	表面上看起来不错的新事物（口碑不错、新解决方案）	探索／评估；尚未推荐用于生产环境
Start	更多公司应该采用的好方案；如果处于 Beta 阶段，应积极推进并参与贡献	建议在新项目中采用
Keep	稳定版（非 Beta），并获得主要用户群体认可（社区规模大、企业在使用）	默认推荐用于当前和新项目
Stop	建议公司停止使用的项目——已有更好的替代方案	提醒避免使用；推荐 Keep／Start 中的替代方案

每个条目的 description 都包含一个 HTML <p>Why?</p> 区块，后跟一个 <p>Description</p> 区块。Why? 文本体现了 Tikal 的明确立场和理由——这是需要展示的观点。同一项技术可能出现多次（位于不同象限），且对应不同的环；请报告每个相关位置。

适用场景

当提示词涉及选择或评估技术时，由模型调用此技能，例如：

• 选择框架、库、数据库、消息代理或云工具。
• 比较选项（“X 与 Y”、“我们应该使用 Z 吗？”）。
• 设计系统、服务或流水线，其中隐含着技术栈决策。
• 审查现有技术栈以进行现代化改造或替换。

如果是纯业务／产品问题，且不涉及技术选择，或者用户明确要求忽略雷达，则不要调用此技能。

手动调用：

/tech-radar-context               # inject radar context for the current prompt
/tech-radar-context redis vs kafka

核心流程

步骤 1：提取候选技术

从当前提示词（或调用此技能的技能所提供的描述）中，提取所有明确提及或明显暗示的技术：语言、框架、库、数据库、消息代理、CI/CD 工具、云服务、AI/LLM 工具、构建工具等。规范化明显的别名（例如，“postgres” → “PostgreSQL”，“k8s” → “Kubernetes”，“GH Actions” → “GitHub Actions”）。

如果提示词只暗示了某个类别，而没有指定产品（例如，“我们需要一个向量数据库”，“选择一个 Python Web 框架”），则将该类别作为查询，并展示雷达在该领域推荐的选项。

步骤 2：查询实时雷达数据集

执行确定性搜索辅助脚本（相对于此技能目录）：

POSIX（bash + jq）：

bash scripts/radar-search.sh <tech1> [tech2 ...]

Windows（PowerShell）：

pwsh scripts/radar-search.ps1 <tech1> [tech2 ...]

或者输出 JSON（bash 添加 --json，PowerShell 添加 -Json）。

该脚本会从 https://tikalk.com/radar.json 获取最新的雷达 JSON，处理别名映射（k8s → Kubernetes、postgres → PostgreSQL、gh actions → GitHub Actions 等），提取 Tikal 的 <p>Why?</p> 观点，并自动生成 Markdown 表格。

如果某项技术出现在多个位置，且对应的环相互冲突（例如，Node.js 同时属于 DevOps: Stop 和 DevOps: Keep），脚本会检测并标记一条指引冲突说明。

实时雷达 JSON 的架构（https://tikalk.com/radar.json）：

{
  "title": "Explore the Tech Radar",
  "quadrants": ["DevOps", "Backend", "AI/ML", "Web/Mobile"],
  "rings": ["Try", "Start", "Keep", "Stop"],
  "blips": [
    {
      "name": "FastAPI",
      "quadrant": "Backend",
      "ring": "Keep",
      "description": "<p>Why?</p>\n<p>...Tikal's opinion...</p>\n<p>Description</p>\n<p>...</p>",
      "isNew": false
    }
  ]
}

步骤 3：匹配技术条目

对于步骤 1 中的每个候选项，按 name 查找匹配的技术条目（不区分大小写、 识别别名、允许像 “Airflow 2” / “Airflow 3” 这样的次要版本后缀，以及 像 “Redux” → “Redux Toolkit” 这样的部分匹配）。一个候选项可能匹配多个 象限中的技术条目——全部保留。

对于类别查询（步骤 1），选择该领域中最值得推荐的雷达条目：优先选择 匹配象限中的 Keep/Start 条目，并指出应避免的 Stop 条目。

步骤 4：提取 Tikal 的观点

对于每个匹配的技术条目，解析 description HTML：

• <p>Why?</p> 块中的文本（直到下一个 <p>Description</p>）是Tikal 的观点／理由——最主要的判断依据。
• <p>Description</p> 块是中立背景信息——仅在有帮助时使用。

去除 HTML 标签，转换为纯文本，并将 “Why?” 内容精简为一到两句话， 用于上下文表格（如果 ring 为 Stop，或者用户正在直接权衡该技术，则 可引用得更完整）。

步骤 5：为 Stop 推荐替代方案

当某个候选项匹配 Stop 条目（或属于雷达明确不推荐的旧技术）时， 从同一象限中选择符合 Tikal 推荐的 Keep 或 Start 替代方案，并参考 “Why?” 文本。数据集支持的一些常见示例：

• Airflow 2 → Airflow 3 / Dagster
• Create React App → Vite / Next.js
• Jenkins → GitHub Actions / GitLab CI / Tekton
• requirements.txt / Poetry → uv
• Moment.js / Luxon → day.js / date-fns
• Redux / Redux Toolkit → Zustand / TanStack Query
• Ant Design / Styled Components → Tailwind CSS / shadcn/ui / Radix UI

除非已加载的数据集支持，否则不要硬编码替换方案——应根据雷达在该象限中 实际的 Keep/Start 条目推导替代方案。

步骤 6：注入技术雷达上下文（输出约定）

在可见响应中、任务答案之前，输出一个 Tikal 技术雷达上下文部分， 以便后续推理基于雷达信息：

## Tikal Tech Radar Context

| Technology | Quadrant | Ring | Tikal's Opinion (Why?) |
|------------|----------|------|------------------------|
| FastAPI | Backend | Keep | Better alternative to Flask; async, fast, big and growing community. |
| Jenkins | Backend | Stop | Plugin hell + XML config; legacy vs GitHub Actions / GitLab CI / Tekton. |

**Radar guidance**
- ✅ Keep/Start: FastAPI — safe to adopt.
- ⚠️ Stop: Jenkins → consider GitHub Actions, GitLab CI, or Tekton (see Why? above).

_Source: Tikal Israeli Tech Radar (live: https://tikalk.com/radar.json) · N technologies matched._

• 每个匹配的技术条目占一行（相关时包括不同象限中的重复条目）。
• 分组列出简短的雷达指导：可放心采用的技术，以及应避免并附替代方案的技术。
• 添加一行 _Source_，注明数据来自实时雷达源以及匹配到的技术数量。

如果候选技术均未匹配任何条目，应明确说明，并提供空表格及 _Source_ 行 （例如：_Source: … · 0 technologies matched._）——不得编造雷达条目。

失败处理

• 实时获取失败（网络错误、超时、无效 JSON）→ 脚本以非零状态码退出，并向 stderr 输出清晰的错误消息。技能必须输出空上下文表格，注明无法访问技术雷达源，并在不使用雷达上下文的情况下继续完成用户任务——绝不能用过时的缓存或内置数据冒充当前数据。
• 无匹配项 → 空表格 + 0 technologies matched 行。

警示

• 为不在已加载数据集中的技术编造 ring、象限或 “Why?” 观点——应报告 0 matches。
• 实时获取失败时，悄悄改用缓存、内置或过时的雷达数据——必须始终报告雷达源不可访问，绝不能将旧数据当作当前数据呈现。
• 硬编码未得到已加载雷达支持的 Stop → 替代方案。
• 将中立的 <p>Description</p> 文本当作 Tikal 的观点——观点位于 <p>Why?</p> 块中。
• 忽略重复条目：同一技术可能出现在不同象限，且 ring 不同；应列出每个相关位置。
• 把加载技能当作任务本身——核心流程必须实际运行并生成技术雷达上下文表格。

验证

• 从提示词中提取候选技术（如果未指定产品，则根据类别查询生成候选技术）。
• 从 https://tikalk.com/radar.json 实时获取雷达数据集。
• 生成 Tikal 技术雷达背景信息表格，包含“技术 / 象限 / 环 / Tikal 的意见（原因？）”列，意见取自 <p>Why?</p> 块。
• 对于匹配到的 Stop 环技术，会从同一象限中根据数据集找出与 Tikal 意见一致的 Keep/Start 替代方案。
• _Source_ 行会报告实时雷达数据源和匹配数量；若未匹配到任何技术，则返回空表格并显示 0 technologies matched，而非编造数据。若获取失败，则报告错误，且技能会在没有雷达背景信息的情况下继续运行。

配置

• 数据源：https://tikalk.com/radar.json（每次调用时实时获取；不包含打包的快照或缓存）。
• 获取超时：10 秒。若获取失败，技能会在没有雷达背景信息的情况下继续运行，而不会阻塞或使用过时数据替代。