过去一段时间，我重新整理了 HOC 这个项目。
最早的 HOC 设想很大：自动挖词、自动判断需求、自动建站、自动发文章、自动做 SEO、自动变现。听起来很完整，但真正开始拆的时候，会发现它太容易变成一个“大而全但不稳定”的系统。
所以这次重启，我做了一个反向决定：先不做完整闭环，只做最前面的一小段。
这个子项目叫 Keyword Radar。
它不是自动建站工具，也不是内容农场工具。它当前只负责一件事：每天发现一些可能值得做的小站关键词机会，并尽量回答清楚一个问题：
这个词，值不值得我花一天做一个 MVP？
项目入口暂时是内部访问页：Keyword Radar 私有入口。功能还在优化阶段，目前不会对外开放。
说明：这篇复盘已做脱敏处理，只保留产品思路、架构取舍和开发方法，不包含服务器地址、API Key、通知通道、内部密码或可直接复用的私有配置。
为什么先砍掉自动建站
自动建站听起来很诱人。
但如果前面的关键词判断不准，自动建站只会放大错误：错误的词会变成错误的页面，错误的页面会变成错误的运营成本。系统越自动，错误传播越快。
所以 Keyword Radar 的第一版刻意不做这些事：
- 不自动生成完整网站。
- 不自动发布文章。
- 不自动发外链。
- 不自动注册账号。
- 不做站群和黑灰产 SEO。
- 不把付费工具后台当作无限抓取的数据源。
它只做需求发现和机会判断。
我希望系统先变成一个“判断器”，而不是一个“执行机器”。
第一版真正要跑通的链路
Keyword Radar 的 MVP 链路被收敛成这样：
公开信号 / 导入关键词
→ Candidate Pool
→ 可选 SERP / metrics 数据增强
→ Human Review
→ Reviewed Candidates
→ MVP Brief
→ 人工决定是否做这里面最重要的不是数据量，而是判断结构。
一个候选词进入复核表时，我希望至少能看到：
- 它来自哪里。
- 它像不像真实需求。
- 它适合工具页、模板页、内容页，还是对比页。
- 有没有趋势或社区信号。
- SERP 里有没有弱竞品、小站、论坛或薄内容。
- 是否可能是拼写错误或伪机会。
- 能不能用一天做出第一版。
- 有没有广告、联盟、导流、低价付费等变现可能。
这比只输出一个关键词列表更有价值。
从 BuilderPulse 得到的启发
开发过程中，我参考过 BuilderPulse 的产品思路。
真正有启发的不是某个具体实现，而是它的判断方式：
- 多个公开信号交叉验证机会。
- 每天只输出少数高置信 build idea。
- 每个机会必须解释 Why now。
- 把 signal 转成具体可做项目。
- 报告要从信息堆砌变成行动建议。
这几条后来变成 Keyword Radar 的报告原则。
一个好的机会报告不应该只说“今天发现 200 个关键词”。它应该更像这样：
这个信号为什么出现
它可以转成哪个关键词
这个关键词应该做什么页面
第一页竞品哪里弱
第一版 MVP 怎么做
为什么现在值得看
最后建议做、观察，还是放弃免费数据优先
第一版我没有把付费 API 设为强依赖。
原因很简单：系统还没证明自己能持续发现赚钱机会之前，不应该先开始烧钱。
当前更合理的策略是：
免费公开数据找机会
人工复核少数候选词
真的准备投入时再用付费工具补数据免费阶段主要看这些信号：
- Google Suggest / Bing Suggest / YouTube Suggest。
- Google Trends 相关趋势。
- GitHub Trending。
- Product Hunt。
- Hacker News。
- Reddit。
- 竞品标题、URL、sitemap。
- 人工查看 AITDK、Google Trends、GSC 等工具。
付费工具和 API 暂时保留为增强层，比如 Ahrefs、Semrush、Serper、DataForSEO。它们有价值，但不应该成为第一阶段的成本负担。
评分系统怎么演化
一开始的评分模型比较简单：
- 搜索意图是否清晰。
- 是否适合工具页或模板页。
- 竞品强不强。
- 商业价值如何。
- 上线速度快不快。
- 合规风险高不高。
后来逐步补了几个更实际的判断。
KGR / EKGR
只看搜索量是不够的。
我更关心的是：有多少页面真的在精准抢这个词。
所以系统里加入了 KGR / EKGR 的计算能力：
KGR = intitle_count / monthly_volume
EKGR = intitle_count * (1 + KD / 100) / monthly_volume如果一个词有一定搜索量，但 intitle 结果很少，就说明精准竞争可能没有那么强，新站更有机会。
typo 风险
有些趋势词看起来突然暴涨，其实可能只是拼写错误、随机字符、Google 自动纠错词或社区标题碎片。
这种词不能直接推荐做站。
所以我单独加了一层 typo / correction risk checker，把明显伪机会打上人工复核标签。
UI/UX Opportunity Score
后来我又补了一个更偏产品的指标：UI/UX Opportunity Score。
它用来判断一个关键词的前排竞品，是否有可能通过更好的页面体验来超过：
- 首屏是否讲得清楚。
- 操作路径是否够短。
- 移动端是否顺手。
- 是否有 FAQ、Contact、Privacy、Terms 等信任元素。
- 广告、弹窗、按钮是否干扰任务。
- 品牌感是否统一。
这个指标不是为了让第一版做复杂设计，而是提醒自己：有些词不是靠更多内容赢，而是靠更清楚、更可信、更好用的页面赢。
人工复核层很重要
如果完全自动化，系统很容易自信地犯错。
所以我给 Keyword Radar 加了一个 Human Review 层。它会把候选词导成 CSV 和 Markdown，让人补充：
- 用户真实搜索意图。
- SERP 观察。
- 竞品弱点。
- MVP 范围。
- 变现路径。
- 最终决定。
- 优先级。
只有人工标记为 build_mvp 且状态为 reviewed 的词，才会生成 MVP Brief。
这一步看起来不够自动，但它让系统更稳。
通知不是炫技，而是让系统进入日常
一个机会雷达如果不能每天被看到，很快就会被忘掉。
所以我把报告接入了现有通知通道。每次 pipeline 跑完，会把日期、输出文件和关键状态推送出来。
这里没有重新创建新的机器人，也没有把 token 写入项目代码。通知只是为了让系统进入日常工作流，而不是为了多一个功能。
目前最大的不足
Keyword Radar 现在已经能跑通 MVP，但还没有证明它能稳定找到赚钱机会。
最大的问题有几个：
-
免费数据噪音高。
社区标题和 Trending 项目名会产生很多不像关键词的短语。 -
Google Trends 容易限流。
它适合作补充，不适合作主入口。 -
缺真实搜索量和竞争数据。
monthly volume、KD、CPC、intitle_count 仍然需要人工或付费工具补充。 -
新旧链路还没有完全统一。
早期 SQLite 报告链路和后来的 JSONL candidate pool 还在并存。 -
还没有上线后的 GSC 反馈。
真正让系统变聪明的，是上线页面后的曝光、点击、CTR 和排名数据。
这些问题不急着用复杂架构解决。下一步更应该先跑几天真实验证。
下一步我更想做什么
我不会急着把它做成 Dashboard，也不会马上接一堆付费 API。
更务实的下一阶段是：
减少噪音
加强人工 SEO 指标回填
接入 AITDK / GSC 的人工复核数据
连续跑 7 天
挑 3 个真的做 MVP
用上线结果反过来校准评分如果它能帮我找到第一个真正带来流量或收入的小站机会，再考虑付费 API、商业化包装和更多自动化。
这个项目可能怎么商业化
Keyword Radar 如果未来要商业化，我不认为它应该一开始就做成通用 SEO SaaS。
更现实的路径是三种：
-
内部选题引擎
先为自己的工具站、模板站、内容页服务。只要它帮我做出一个有收入的小项目，它就已经有价值。 -
付费机会报告
每周输出少数高置信关键词机会，每个机会包含 Why now、竞品弱点、MVP 建议和变现路径。卖的不是关键词列表，而是行动判断。 -
轻量项目调研服务
帮独立开发者或小团队找某个行业里的低竞争页面机会，交付一份可执行报告。
我更倾向从第一条开始。
先让系统帮自己赚钱，再考虑让系统本身赚钱。
最后的判断
Keyword Radar 现在还不是一个成熟产品。
但它已经从一个很大的 HOC 想法里，切出了一个足够小、足够实用、可以每天运行的模块。
这对我来说是一个好的开始。
很多项目失败，不是因为做得太少，而是因为一开始想把所有环节都自动化。
这次我希望反过来：先把判断做准，再决定要不要放大执行。