direction-validator

name	direction-validator
description	从“查询增长”或“人群/社区增长”进入，形成明确人群问题簇和候选词群，再用真实 Chrome、SERP、竞品、流量、变现与真人行动选择和验证网站或 APP 方向。用于增长社区归类、Reddit/X/YouTube 等登录态调研、词找词/词找站/站找词、关键词与竞品验证、Landing Page/APP MVP 规划、社区触达、地推或付费验证。
scope	project

direction-validator / 从增长人群与词到方向

本 skill 有两个入口，最后汇合到同一套验证闸门：

Query-first：     查询增长 → 词群 → SERP/站 → 人群与问题
Community-first：社区增长 → 人群问题簇 → 用户语言 → 候选词群
                                      ↓
                           搜索/竞争/触达/变现
                                      ↓
                             Website / APP MVP

一个好方向不是抽象 idea，也不只是一个热词或热门社区，而是：明确人群 × 具体场景 × 重复任务 × 可承接产品 × 可复现流量/触达 × 付费时刻。

本 skill 自包含运行所需的方法与模板；它可以被复制到任何项目。赫兹是主方法源，哥飞的 SEO 实操作为选词与上站补强，Greg Isenberg 的社区增长方法只作 Community-first 辅源。**每次激活后、开始任何调研前，完整阅读 references/keyword-research-method.md。**该文件已经内置关键原文摘录、公式、操作顺序、边界和二手来源标注，无需先爬取公众号链接；链接只用于追溯和更新。

• 用户不理解“词/词群/搜索意图”时，完整阅读 references/beginner-find-word.md，先教学再调研。
• 候选需要社区观察、竞品评论、发帖、访谈、私信、付费招募或小额广告时，完整阅读 references/user-contact-playbook.md，先选择合规且可复现的验证入口。
• 从增长社区进入时，先复制 assets/audience-opportunity-card.md，形成一个人群问题簇后再进入关键词证据卡；不要从社区名直接跳到产品。

0. 先写验证合同，防止调研变成拖延

在扩词前先写明：本轮截止时间、现金预算、最多深查几个候选、最多使用几个渠道、什么行动算成功、出现什么情况立即 watch/reject。截止时必须做决定，不用“再查一点”代替结论。

默认项目护栏（不是赫兹或哥飞给出的通用阈值）：

• 纸面研究每轮只深查 1–3 个词群；
• 至少取得两类相互独立的证据，其中一类来自市场/搜索事实，另一类来自行为或商业事实；
• 至少存在一个可复现的目标用户或冷流量入口；
• 进入重产品开发前，至少出现一个强行动信号：提供脱敏样例、完成工作流走查、重复使用、主动询价、订金或付款；
• 若强信号只能靠先造一个很小的可用页面/人工服务获得，则允许做该实验，但不把它扩成完整产品。

搜索量、帖子、评论、竞品和访谈不必全部做齐；选择能最快改变当前闸门的最小组合。可信朋友引荐是可选加速器，不是必要条件。

完成判据：证据卡顶部已填验证合同，且失败时不会继续无上限搜集资料。

1. 先选本轮策略

向用户确认或根据上下文标记本轮优先级，避免把不同机会误放在一张榜里：

• 新词抢时差：反馈快、竞争可能低、波动和一波流风险高；
• 增长社区切入：先找正在聚集的人群与 why now，再从 pain / advice / solution requests 翻译成候选词；社区热度不能替代搜索和商业验证；
• 稳定词群：更适合长期 SEO 资产、通常竞争更强、反馈更慢；
• 低竞争多内页：每词小，但能由真实不同页面聚合；
• 竞品切入：已有付费或流量验证，寻找更窄的场景、长尾或更好的承接页。

用户未指定时，默认同时保留“一个稳定词群”和“一个新词观察位”，不把它们用同一指标排序。

完成判据：每个候选都标注策略；本轮只深挖同一策略中的一个词群。

2. 选择入口并建立 Seed Pool

A. Query-first：从词或站进入

从下面入口收集词或网站，每条附原始来源和日期。先收集 15–30 个线索，再合并成不超过 5 个词群：

• 词找词：领域词根 + 功能词根；Google autocomplete、related searches、Google Trends related/rising queries；
• 词找站：直接搜索候选词，看前排站、页面类型和相邻词；
• 站找词：从对标站的关键词、着陆页、新点击量页面、广告词或 GSC（若是自有站）反推词；
• 站找站：从 Similarweb 相似站、共同 Adsense、外链来源、榜单或导航站找到同类站；
• 新词源：跟踪模型、平台、游戏、产品更新的一手发布和社区讨论，再回 Google Trends 与 SERP 验证；
• 服务/差评：Fiverr、Upwork、插件评论、社区 workaround 只作为可扩词的线索。

AI 可以扩展同义词、修饰词、地区词和页面词；每个新增词仍要回到真实搜索或来源验证。把重复词合并为主题，不把关键词清单当结论。

B. Community-first：从增长社群进入

当前阶段不搭全量社区监控。每轮只做：

1. 找 3–5 个规模足以产生真实讨论、且日/周/月增长可解释的候选社区；
2. 检查真实活跃度，不把成员数、点赞或单次新闻爆发直接当需求；
3. 只在满足“同一类人 + 相似场景/任务 + 相似替代方案”时归为一个 audience；主题相近但任务不同的社区不要硬合并；
4. 从 pain & anger、advice requests、solution requests 各抽少量代表性内容，并回原帖核查；
5. 补充教育型创作者的热门内容与评论，提取用户语言和潜在分发入口；
6. 用 assets/audience-opportunity-card.md 写出一个人群问题簇，再把用户原话翻译为候选词群。

Greg Isenberg 案例中的 1 万～10 万成员只作发现启发，不是硬阈值。增长率、发帖/评论密度、具体求助比例和 why now 比单独的成员数更重要。

评论层有三种不同用途：提取选词与用户表达、判断趋势/替代方案语境、以及在后续 规则允许时回到相关讨论提供价值并邀请测试。它们不能混为“评论多所以有需求”， 也不能把评论者当作可批量投放链接的名单；实际触达时完整阅读 references/user-contact-playbook.md。

社区调研必须走 Chrome 登录态

• 对 Reddit、X、YouTube、Discord、Facebook、封闭论坛或任何依赖用户登录态/插件的社区，必须调用 Codex Chrome 插件，复用用户当前 Chrome 会话；不要用普通网页搜索或无登录 API 冒充“已查看社区”。
• 第一次访问若遇到登录页、私密社区、年龄/地区/成员权限、二次验证或其他访问门槛，立即停在该页面，告诉用户需要在哪个站完成什么登录/授权；用户完成后继续复用同一 Chrome 状态。
• 不读取 cookies、密码、浏览历史或会话存储，不绕过付费墙、验证码、社区权限或安全提示。
• API/MCP 只用于官方允许的公开批量数据；它可以补趋势数字，不能替代登录态中的帖子上下文、评论、版规和互动质量。
• 每次社区观察记录：URL/社区、日期、时间窗、规模与增速口径、活跃度、代表性原话、访问限制和未取得的数据。没有实际打开原帖，不标为 observed。

完成判据：

• Query-first：15–30 个带来源的词/站线索，合并成 ≤5 个词群；
• Community-first：3–5 个候选社区归成最多 1 个本轮深查的人群问题簇，并产出 1–3 个候选词群。

3. 把词群变成可判断的站型

Community-first 先写：

什么人 × 什么场景 × 什么重复任务 × 当前替代方案 → 用户会如何搜索/求助 → 候选承接物。

对每个词群写一行：

主词 + 修饰词群 → 用户搜索时想完成什么 → 最合适的页面类型 → 第一种变现方式。

页面类型只从实际 SERP 的主流结果中选：工具、目录/本地服务页、模板/资源页、攻略/内容页、品牌/导航页或交易/询价页。若预想站型与 SERP 意图不匹配，改站型、改词或淘汰；不强行把每个词做成 AI 工具。

同一主题至少拆出：主词、任务/功能词、长尾修饰词、地区/对象/格式等变体。低竞争多内页策略还要说明每个页面为什么提供独特价值，不能只换词批量生成薄页。

产品形态先开放为 Website / APP / 人工服务 / 内容：

• 一次性查询、计算、比较、生成或本地发现，优先验证 Website；
• 持续使用、通知、相机、定位、离线、个人数据或习惯形成明显时，才优先验证 APP；
• 查询尚未形成但人群增长和问题很强时，不因 SEO 量低淘汰，转到社区触达或 APP/人工 MVP；
• 任何形态都必须写清首个可复现获客入口。

完成判据：每个词群都映射到一个用户任务、一个候选承接物、一个流量/触达入口和一条初始变现假设。

4. 跑 Keyword Evidence Card（关键词证据卡）

一次只对 1–3 个最可能的词群做深查。用 assets/keyword-evidence-card.md 记录下列事实、查询和日期：

1. 需求与时机：趋势相对基准、相关查询、国家/语言、查询簇，而非单个热度数字。新词要追溯首发时间，区分刚出现、已过峰还是稳定增长。
2. SERP 与竞争：真实前 10 的页面类型、品牌/官方占比、内容新旧、产品质量、外链/域名信号；allintitle:、KD、KGR 只作辅助信号。
3. 可承接性：你能否在一个页面里交付比当前结果更完整、更快、更垂直或更可信的结果；写出具体差异，不写“做得更好”。
4. 用户与行为：Reddit/Facebook 等社区原话、访谈/招募、现有 workaround 和目标人群出现的位置；记录渠道规则和身份门槛。
5. 流量路径：对标的关键词着陆页、外链、社媒、广告或导航站来源中，至少一个你能复现的入口。
6. 竞品与变现：竞品评论中的反复抱怨、替代方案、定价、CPC、支付/报价流程或已有商业行为；判断广告、联盟、付费工具、付费上架、线索或订阅中哪一种与任务自然相连。

每条证据标为 observed、source-stated、inferred 或 unknown。Google Trends 0–100 不是绝对搜索量；支付网关入站流量也不是收入。

同一帖子被多人转述、同一 SEO 工具给出的多个指标、同一竞品的多条评论都不能自动算多类独立证据。证据按信号强度记录：

• 弱信号：搜索量、点赞、抱怨、“听起来有用”；适合进入候选池；
• 中信号：反复出现的具体流程、已有付费竞品/人工替代、愿意留联系方式或接受访谈；适合设计最小实验；
• 强信号：交付脱敏样例、完整走查、重复使用、主动询价、订金或付款；才足以显著提高重开发信心。

完成判据：每个词群都有一张证据卡，需求、SERP、承接、用户、流量、竞品/变现均有结论或明确未知，并注明证据是否独立及信号等级。

必做：判断双增长状态

分别记录，不互相替代：

人群/社区增长	查询增长	默认路线
强	强	强候选：继续 SERP/竞品与 MVP 验证
强	未形成/弱	早期候选：社区触达、访谈、APP/人工 MVP；不因低搜索量直接淘汰
弱/不明显	强	SEO-first：按词群和 SERP 验证
弱/不明显	弱	除非已有强付费/法规/B2B 证据，否则降低优先级

成员增长、讨论增长、查询增长和收入增长是四种不同信号；报告中必须写明正在观察哪一种。

必做：用用户真实 Google/Chrome 复核 SERP

当 Chrome/应用内浏览器可用时，优先控制用户浏览器打开 Google，使用用户实际地区、语言和登录环境复核；不要只依赖搜索 API、SEO 工具摘要或模型记忆。若浏览器不可用，明确记录替代工具和局限，不把替代结果写成“已完成 Chrome 实查”。

每个候选至少查询并记录日期、地区和可见前排结果：

1. 主词：验证大盘意图、主流页面类型和强竞品；
2. 2–5 个任务副词/长尾词：验证更具体的使用时刻和可排名切口；
3. 商业词：如 price、cost、for sale、software、alternative、commission，验证付费时刻；
4. 问题词：如 how to、before、without、from photo、Reddit，发现尚未被顺畅完成的任务；
5. 竞品品牌词 + review/alternative：寻找反复抱怨、迁移原因和 workaround。

逐个打开足够多的真实结果来覆盖主要页面类型；默认检查前 10，不机械凑数。记录广告、自然结果、SERP feature、结果新旧、价格、输入输出、注册/支付路径。Google 的个性化与地区差异本身也是证据；必要时再用无痕/退出登录或其他地区数据交叉检查。

发现竞品只证明有人承接需求，不自动证明还有机会；“界面不好看”“我可以接 AI/OCR”“功能更多”也不自动构成缺口。只有同时满足以下三项，才把缺口写为 observed：

• 用户在具体时刻有一个未完成或高摩擦任务；
• 当前前排产品确实没有顺畅完成它，且最好有社区、评论或 workaround 佐证；
• 可以写出从输入到结果的具体新承接，并说明它为什么值得切换或付费。

AI、OCR、图像理解和大模型只是可能的交付手段。先验证“用户需要从图片得到什么决策或结果”，再用最便宜的人工/模型 Demo 测准确度、成本与失败边界，不能因为技术可做就反推需求成立。

完成判据：证据卡包含真实浏览器 SERP 快照、主词/副词/商业词的查询记录、竞品功能矩阵，以及一句可被反驳的缺口命题；若只能写“更漂亮/更智能”，竞争或承接闸门不得通过。

用户可触达性不是需求本身

在主动联系真人前，先确认社区规则、帖子是否可回复、账号是否有最低年龄/karma 限制、研究或工具反馈是否只允许进入固定帖。可选入口包括：公开观察与竞品评论 → 对近期真实痛点作有上下文的回复 → 征得同意后私聊 → 获准的研究入口/付费招募 → 冷流量 Landing Page。无需按顺序全部完成，选当前最可复现的一种。

禁止伪装真实使用经历、隐瞒研究目的来绕过规则、在内容被过滤后重复刷帖，或索取未脱敏的订单/客户数据。被平台过滤、版规禁止或账号无法发言，只能标为渠道失败；合资格用户看见方案后仍不行动，才是需求、承接或变现的反证。

“人工触达验证”包括社群参与、创作者联系、访谈招募、冷邮件和真实线下地推。只有面对面派发/拜访才写“线下地推”；不要把所有线上社区触达都笼统称为地推。

5. 用顺序闸门筛词，而不是加权打分

按下面顺序判断 go / watch / narrow / reject。任何前置项失败，都不能被后面的流量或热度抵消。

闸门	通过时必须能回答	失败后的回边
需求	是否有一组真实查询或其他可观察行为，而非单个热词？	回 Seed Pool 扩词或换时机
意图	搜索结果是否表明用户需要你计划做的页面？	改站型、改修饰词或淘汰
竞争	新站能否在一个清晰切口获得曝光？	拆更长尾、更垂直或换词群
承接	能否写出一个可交付的、具体的差异？	回竞品页与用户任务重做
触达	是否有一个合规、可复现的用户或冷流量验证入口？	换社区、招募、搜索或广告入口；仍不可达则 watch
流量	是否至少有一个可复现入口？	回站找站/竞品渠道调研
变现	谁会在何时为什么付钱，或广告价值从何而来？	回商业证据；只留观察位

KGR、EKGR、KDROI 只在输入数据可信且会改变选择时计算。赫兹没有给通用及格线，报告原始值、来源与假设，不发明“低于某数必做”的规则。

在顺序闸门旁同步维护六项经营证据：人群痛点、竞争、交付、付费时刻、SEO 流量、付费意愿。能量化时优先写原始量，不急着合成一个总分：查询量/趋势、前 10 独立产品数、任务完成步骤与模型单次成本、竞品价格、可复现流量规模、真实 checkout/付款数。数字必须注明来源、样本、地区、时间窗和可信度；没有可靠数据就写 unknown，不要用估算伪装精确。

完成判据：每个候选有首个未通过闸门和唯一下一步；最多保留 3 个 go/watch 候选。

6. 选定一个词群后的动作

• go：按“最小失败实验”推进：先写最便宜的反证 → 用概念页、可点击样例、人工服务或一个最小可用功能承接 → 投放一小股合资格流量 → 观察使用、询价、订金或付款 → 决定扩大、改切口或停止。Landing Page 是销售/意图实验，不默认能够靠广告盈利，也不必先造完整产品。涉及发布、广告、收款、真人联系时先取得用户授权。
• 对 AI/OCR 候选，Demo 只实现缺口命题所需的最短链路；同时记录模型选择、单次可变成本、响应时间、人工纠错率和不可接受错误。埋点只收集会改变决策的事件（到达、开始、完成、结果有用、付费点击、checkout、付款），热图和 SEO 建议属于诊断工具，不是需求成功信号。
• watch：记录首发源、目标查询和复查日期；新词未形成查询簇时不抢先造大量页面。
• narrow：只保留能解决竞争或意图问题的修饰词/页面类型，再回证据卡。
• reject：记录失败闸门和反例，回 Seed Pool；不要因已经花了调研时间而继续堆功能。

搜索数据负责选词，真实点击、使用、询价和付款负责验证站。若上线后有流量无转化，先复查搜索意图、页面承接和价格路径，不把流量当成功。

7. 学习新方法时更新，不自创规则

只有用户明确要求精读/吸收某篇赫兹、哥飞或其他具体辅源材料时，走学习分支：

1. 提炼其中的入口、执行顺序、可观察判据、工具路由和反例；
2. 标注哪些是作者明确规则，哪些只是案例或本项目归纳；
3. 用一个真实词群做纸面试跑，判断它是否改变当前流程；
4. 把确认有效的增量写入 references/keyword-research-method.md，并在交付时说明变更。

没有可观察判据的新观点只记录为学习笔记，不升级为 skill 规则。

8. 人机交接与停止条件

Agent 负责检索、扩词、SERP/竞品实查、整理证据卡与提出 go/watch/narrow/reject 建议。用户决定策略偏好、愿不愿意长期做主题、预算、对外动作和最终选词。

只询问会改变当前 frontier 的人类决定；问题编号，并给推荐答案与理由。每轮最多补一次关键未知后交还用户，防止无限调研。若新增信息不会改变 go/watch/narrow/reject，停止研究并执行验证合同中的实验或淘汰。方向尚未进入 go，不开始产品代码项目；为取得强信号而制作的可丢弃概念页/人工交付不算重产品开发。