公司雷达
竞争情报编排工具。 接收公司名称，跨 8 个以上平台并行研究，为每家公司计算 0-100 的热度评分，并生成包含 AI 简报的结构化雷达报告。
这是一个编排技能。它将数据收集工作委托给现有的 opendirectory 微技能，并协调它们的输出——它不替代这些微技能。
架构
输入：公司名称 / URL
|
[1. 档案阶段] -- 网络研究以构建公司档案
|
[2. 信号采集] -- 并行平台研究（8 个渠道）
/ | | | | | \ \
GH TW RD HN PH YC WEB MEDIA
|
[3. 评分引擎] -- 4 维热度评分（0-100）
|
[4. AI 综合] -- 执行简报生成
|
输出：雷达报告 + 各公司深度分析
信号渠道及其 Opendirectory 映射
| 渠道 | Opendirectory 技能 | 检测内容 |
|---|---|---|
| GitHub | gh-issue-to-demand-signal + 网络搜索 | Stars、forks、commits、releases、发布速度 |
| Twitter/X | twitter-GTM-find-skill | 推文、提及、互动、创始人活跃度 |
reddit-icp-monitor、reddit-post-engine | 社区情绪、痛点、热度 | |
| Hacker News | hackernews-intel | 故事提及、点数、首页信号 |
| Product Hunt | producthunt-launch-kit | 发布、投票、制造者活动 |
| YC Jobs | yc-intent-radar-skill / yc-jobs-scraper | 职位列表、招聘部门、增长信号 |
| 网络/新闻 | Tavily 搜索 + competitor-pr-finder | 新闻、产品公告、融资 |
| 定价 | pricing-finder | 价格变动、层级更新、计划结构 |
| 市场定位 | map-your-market | ICP、竞争对手格局、信息空白 |
常见错误
| 代理可能会... | 为什么这是错误的 |
|---|---|
| 顺序运行技能 | 所有 8 个信号渠道都是独立的。必须并行运行。 |
| 捏造 GitHub star 计数或招聘人数 | 每个数据点必须追溯到特定的搜索结果或技能输出。不能有“大约 500 stars”。 |
| 跳过热度评分计算 | 雷达报告需要评分的输出，而不仅仅是原始数据转储。热度评分是核心区别。 |
| 因为某个技能失败而输出不完整的报告 | 一个渠道失败不会阻塞整个报告。根据已有数据评分，并注明差距。 |
| 使用 AI 训练知识来描述公司 | 每个公司的描述必须来自实时的网络研究，而不是记忆。 |
| 忘记根据热度评分评估活动级别 | 热度评分有明确的阈值：高（60+）、中（30-59）、低（1-29）、沉睡（0）。 |
步骤 1：设置检查
检查用户平台支持的渠道所需 API 密钥是否可用：
if [ -z "$TAVILY_API_KEY" ]; then echo "TAVILY_API_KEY: 未设置 -- 网络丰富化需要此密钥"; else echo "TAVILY_API_KEY: 已配置"; fi
if [ -z "$GITHUB_TOKEN" ]; then echo "GITHUB_TOKEN: 未设置 -- GitHub API 速率限制为 60 req/hr"; else echo "GITHUB_TOKEN: 已配置"; fi
被编排的特定技能有其自己的 API 密钥要求。请查看每个技能的 SKILL.md 以了解详情。完整运行所需：
TAVILY_API_KEY-- 网络搜索和公司丰富化（在 app.tavily.com 获取）GITHUB_TOKEN-- GitHub API 访问（在 github.com/settings/tokens 获取）
如果缺少 TAVILY_API_KEY：停止并告知用户。没有它，公司分析和网络丰富化无法运行。
步骤 2：解析输入
从对话中收集：
companies：要追踪的公司名称/URL 列表（必填，最少 1 个，每次运行最多 10 个）output_preference："full report"（默认）、"alert-only"、"briefing-only" 或 "heat-score-only"（排行榜表 + 分数，不包含深度分析）timeframe："realtime"（默认）、"last-week" 或 "last-month"
如果用户只提供一个公司名称： 仍然运行完整的雷达流程。单公司雷达是有效的——获取完整的档案。
如果超过 10 个公司： 告诉用户“每次雷达扫描最多 10 个公司。我将运行前 10 个。如果您想替换任何一个，请告诉我。”
询问是否有任何公司有特定的已知标识：
- GitHub 组织名称（如果与公司名称不同）
- Twitter 句柄
- YC 批次（如果是 YC 公司）
- Product Hunt slug
这可以节省研究时间。如果未知，档案阶段将发现它们。
步骤 3：公司档案阶段
在运行平台研究之前，为每个公司构建基本档案。
步骤 3a：初始网络丰富化
为每个公司运行 Tavily 搜索以发现：
[公司名称] official website twitter github linkedin producthunt yc founders
从搜索结果中提取：
- 域名/网站 URL
- 描述（2-3 句话）
- Twitter 句柄（来自结果中的 twitter.com/X.com URL）
- GitHub 组织（来自结果中的 github.com URL）
- LinkedIn URL
- Product Hunt slug
- YC 批次和 URL（如果适用）
- 创始人姓名和 Twitter 句柄
输出格式： 为每个公司生成一个档案对象，遵循 references/company-profile-format.md 格式。
步骤 3b：与用户确认
显示发现的档案，并在继续之前要求用户确认或更正。
## 发现的公司档案
| 公司 | 域名 | Twitter | GitHub | YC 批次 | 创始人 |
|---|---|---|---|---|---|
| ... | ... | ... | ... | ... | ... |
在继续信号采集之前，请指正任何错误的标识？
等待用户确认。不要跳过此步骤——错误的标识会产生错误的信号。
步骤 4：并行信号采集
现在，对所有已确认的公司并行运行所有平台的研究。
信号采集映射
对于每个平台，使用适当的方法。同时运行所有平台——不要顺序执行。
GitHub 信号
使用网络搜索（Tavily）查找 GitHub 组织，然后搜索：
github.com/[org] stars forks commits
提取：
- 所有仓库的总 stars
- 所有仓库的总 forks
- 最近 7 天的 commits
- 最近 30 天的 releases
- 最后推送日期
- 主要编程语言
- 开放的 issue 数量
或者调用 gh-issue-to-demand-signal 技能，如果你想要从 GitHub Issues 中获得更深入的需求信号分析。
Twitter/X 信号
使用 twitter-GTM-find-skill 或 Tavily 搜索：
twitter.com/[handle] site:twitter.com [公司] startup
提取：
- 最近 24 小时的推文数量
- 提及量
- 创始人推文活动
- 关键话题/标签
Reddit 信号
使用 reddit-icp-monitor 方法或 Tavily 搜索：
site:reddit.com [公司名称] [产品类别]
提取：
- 提及次数
- 帖子得分（点赞）
- 情绪（正面/负面/中立）
- 关键抱怨或赞美
- 相关 subreddit
Hacker News 信号
使用 hackernews-intel 方法或 HN Algolia API 搜索：
site:news.ycombinator.com [公司名称]
提取：
- 故事数量
- 总点数
- 首页故事
- 关键话题
Product Hunt 信号
使用 producthunt-launch-kit 方法或 Tavily 搜索：
site:producthunt.com [公司名称] products
提取：
- 最近发布
- 点赞数
- 评论/情绪
- 发布频率
YC Jobs 信号
使用 yc-intent-radar-skill / yc-jobs-scraper 方法或 Tavily 搜索：
site:workatastartup.com [公司名称] OR site:ycombinator.com/companies [公司名称]
提取：
- 开发职位数量
- 职位名称/角色
- 部门分类（工程、销售、市场等）
- 地点/远程状态
网络/新闻信号
使用 Tavily 搜索：
[公司名称] funding announcement product launch news 2026
提取：
- 最近融资轮次
- 产品发布
- 新闻中宣布的关键招聘
- 合作伙伴关系公告
定价信号（可选，如果用户想要定价情报则运行）
使用 pricing-finder 技能或 Tavily 搜索：
[公司名称] pricing plans 2026
提取：
- 定价层级
- 计划结构变化
- 免费层级 vs 付费
处理失败情况
- 如果任何渠道返回 0 结果，在报告中注明“未检测到信号”
- 如果任何技能不可用（API 密钥缺失），注明“渠道不可用”
- 永远不要根据记忆编造数据。如果你找不到，标记为未找到。
- 一个空渠道不会使整个报告无效。
步骤 5：热度评分计算
使用捆绑的 scripts/heat-score-calc.mjs 为每个公司评分。该脚本实现了 references/heat-score-methodology.md 中的 4 维评分算法。
如何运行
将所有信号数据收集到一个 JSON 文件中，匹配以下模式：
{
"companies": [{
"name": "CompanyName",
"signals": {
"stars": null, "forks": null, "ph_votes": null,
"commits_week": null, "releases_month": null,
"active_shipping": false, "last_activity_days": null,
"tweets_24h": null, "mentions": null,
"reddit_posts": null, "reddit_score": null,
"hn_stories": null, "hn_points": null,
"youtube_videos": null,
"jobs": null, "dept_count": null,
"sentiment": null, "traction": null
}
}]
}
用发现的值填充每个字段。任何未找到的内容保留为 null——脚本将 null 视为 0。
然后运行：
node scripts/heat-score-calc.mjs --file signals.json
或者通过管道传递：
echo '{"companies":[...]}' | node scripts/heat-score-calc.mjs
返回内容
脚本输出包含每个公司结果的 JSON：
{
"generated_at": "2026-05-29T...",
"company_count": 3,
"companies": [
{
"name": "Vercel",
"heat_score": 89,
"level": "High",
"dimensions": {
"authority": { "score": 25, "max": 25, "breakdown": {...} },
"shipping": { "score": 25, "max": 25, "breakdown": {...} },
"social": { "score": 17, "max": 25, "breakdown": {...} },
"growth": { "score": 22, "max": 25, "breakdown": {...} }
},
"alerts": [...]
}
]
}
每个公司包括：
heat_score— 总分 0-100level— 高（60+）、中（30-59）、低（1-29）、沉睡（0）dimensions— 每个维度的分数，含最大值和详细分类alerts— 自动检测的显著信号
评分规则（在脚本中实现）
这些是脚本应用的公式。它们在此处记录以供透明参考：
| 维度 | 信号 | 最大值 |
|---|---|---|
| 权威性 | GitHub stars（min(15, stars/1000*3)）、forks（min(5, forks/200*2)）、PH votes（min(5, votes/100*5)） | 25 |
| 发布速度 | Commits/周（min(10, commits*2)）、releases/月（如果>0 则 5）、活跃标志（5）、时效性（如果<7 天则 5，如果<30 天则 3） | 25 |
| 社交 | 推文（5）、提及（5）、Reddit 帖子（3）+ 得分（2）、HN 故事（4）+ 点数（3）、YouTube（3） | 25 |
| 增长 | 职位（min(10, jobs*3)）、部门多样性（min(5, dept_count*2)）、AI 情绪（5）、AI 牵引力（5） | 25 |
- 每个维度上限为 25。缺失信号得 0 分。永远不要估算数据。
- 完整的方法论和边界情况见
references/heat-score-methodology.md。
步骤 6：AI 执行简报
对于每个得分高于 0（即检测到任何信号）的公司，使用收集到的数据生成 AI 执行简报。
简报必须涵盖：
**执行简报：[公司名称]**
**背景：** 1-2 句话说明他们做什么以及他们的市场地位
**热度评分：** [分数]/100 — [活动级别]
**近期活动：**
- 产品：发现的关键产品或发布信号
- 招聘：招聘状态、部门、重要角色
- 社区：来自 Reddit/HN/Twitter 的情绪总结
**威胁评估：**
- 竞争威胁级别：[低 / 中 / 高]
- 理由：2-3 句话解释原因
**关键信号（最重要的发现）：**
一句话说明该公司正在发生的最重要的事情。
**数据置信度：**
哪些渠道数据良好，哪些数据缺失。
规则：
- 简报中的每个声明必须追溯到收集的数据
- “数据置信度”部分是强制性的——诚实地说明差距
- 威胁评估应相对于雷达中的其他公司进行比较，而非孤立进行
- 每个简报保持在 250 字以内
步骤 7：组装并输出雷达报告
将所有内容编译成结构化的雷达报告格式。使用 references/radar-report-template.md 获取确切的输出结构。
报告应包括：
- 执行摘要 — 带有排名公司的顶级发现
- 热度评分排行榜 — 所有公司的排名表
- 各公司深度分析 — 每个公司包含完整档案、信号数据、分数分解和 AI 简报
- 信号提醒 — 检测到的显著事件（招聘激增、病毒式传播、发布）
- 数据质量说明 — 哪些渠道有数据，哪些缺失
以 markdown 格式输出，准备复制到 Slack、Notion、Google Docs 或电子邮件。
步骤 8：可选——安排定期雷达
如果用户想要持续监控：
- 保存公司列表和 API 配置
- 设置 cron 计划（GitHub Actions 或系统 cron）
- 每次运行生成更新的报告
- 为分数变化配置提醒（例如，“如果任何公司分数跃升 20+ 分，则提醒”）
此技能是一个编排器——每次运行都会完整执行整个流程。