100x-搜尋查詢 是做什麼的？
一句話定位
輸入產品/人設卡片，輸出 Pinterest / TikTok / Reddit 三平台各 15 條英文搜尋短語，用於找 視覺參考素材、靈感圖和對標內容。屬於 100x 體系 L2 創意生成層，對應「搜尋關鍵詞」這一步。
何時觸發
使用者說：
- 「幫我找參考圖」/「找靈感圖」/「去哪裡找參考圖」/「給我搜尋關鍵詞」
- 「what should I search on Pinterest」/「find reference images」
- 「need TikTok/Reddit search terms for this product」
- 或直接給一個產品卡片 / persona 卡片，要求出一套搜尋詞
輸入
最小輸入（類別 A，硬性必填）：category（品類，自由文字，例如「保健品」「家居」「美妝個護」；
參考未來 taxonomies/，禁止套用任何客戶專屬品類詞典）。product_name 不是使用者
必須提供的輸入——拿不到具體品牌/產品名時用 "[品類錨點] <category>" 佔位繼續跑
（schema.json 要求輸出裡的 product_name 必須非空字串，那是「輸出契約的必填」，
不是「使用者輸入的必填」，兩者不是一回事）。詳見 workflow.md Phase 1 類別 A 驗證。
軟性補充（類別 B，缺失走三級降級，見 workflow.md Phase 1）：core_benefit、
target_audience、brand_tone、topic_angle（default/aesthetic/pain-driven/
sales-push 之一）。
上游可選產出（類別 C，缺失靜默跳過，不阻塞，也絕不要求使用者先跑別的 skill）：persona
卡片、insight 結果、爆點結果。若提供，則必須真正影響生成——2C 階段至少 6 條
要體現 persona 的具體受眾/身份角度，不能只是收下卡片但產出跟沒給一樣，詳見
workflow.md Phase 1 步驟 4 / Phase 2 相應段落。
輸出
結構見 schema.json：queries.pinterest/tiktok/reddit 各 15 條 {q, intent_cn, stage}，
meta.based_on_5a 宣告本次 5A 覆蓋。拿到類別 C（persona/insight）輸入時，
meta.persona_informed 須為 true 且 meta.persona_descriptor_terms 須列出從卡片摘取
的具體受眾/身份用詞，否則不算合規產出（公理 5）；沒拿到類別 C 輸入時兩個欄位都可以
省略。可選再渲染 3 張 Markdown 表（每平台一張，列：# / query / search_intent_cn /
5a_stage）。
核心約束（5 條公理，詳見 axioms.md）
- 每平台正好 15 條，全英文 ASCII，少 1 條或混中文 = 作廢
- 平台差異化鎖死：Pinterest 美學詞 / TikTok hashtag+梗詞 / Reddit 痛點問句，串台作廢
- 基於 5A 意圖分層生成，
meta.based_on_5a必填非空，45 條覆蓋 ≥3 個階段 - 每條必帶 ≤20 字中文搜尋意圖註釋，格式必須是「閉集類別標籤+純中文說明」（已知限制：
這是格式驗證，能擋住「整句照抄英文翻譯」，但擋不住「貼合法標籤殼、內容仍是逐字
直譯」這種更隱蔽的情況，例如給直譯內容隨手配一個「質疑:」前綴就能通過——這是已知
語義缺口，不是「保證零直譯」，見
axioms.md公理 4 TODO） - 拿到 persona/insight 輸入就必須真的體現在產出裡：
persona_informed=true時，45 條裡至少 6 條要命中persona_descriptor_terms宣告的具體受眾/身份用詞，否則作廢（已知限制：詞表判據擋不住「敷衍地摘幾個過寬泛的 詞湊數」，只能擋「完全沒用」，見axioms.md公理 5）
邊界（無例外）：無論產品文案源語言是什麼（支援英文與西語等多語種輸入），
輸出搜尋詞始終是英文——這是公理 1 的直接推論，不是額外限制。沒有非英文版本這個
選項：輸出短語嚴格受 schema.json 的 ASCII 強驗證約束，無非英文產出分支。
三階段流程
詳見 workflow.md：Phase 1 接收+驗證（類別 A/B/C） → Phase 2（5A 分配 → 平台桶生成 →
逐條自檢 → 批量自檢） → Phase 3 使用者觸發的返工（L1 單條 / L2 單桶 / L3 全體；沒有
L4——公理 1 對非英文輸出無例外，見上方「邊界」）。
獨立調用保證
類別 A 缺失（即 category 缺失——product_name 拿不到具體品牌名不算類別 A 失敗，
見上方「輸入」一節）→ 固定拒絕話術追問，不代猜、不編造。絕不要求使用者「先跑其他 skill」。
類別 B 缺失走三級降級（完整→追問一句→內聯推斷+meta.warnings提示）。類別 C 缺失
靜默跳過。
禁用詞
讓我 / 希望 / 或許 / 大概 / 可能 / 也許 / 讓我們；AI 客服味（as an AI / I'd be happy to /
feel free to）；無效美學詞 attractive/beautiful/stunning/serene/pristine/elegant/
cinematic/professional/studio/flawless；不編造 subreddit（本 skill 預設不加 r/xxx
前綴，見 axioms.md TODO）；不編造效果/認證/使用者見證。
敏感品類訊號檢測（內容政策護欄，已知有侷限，不是公理）
本 skill 會掃描 category/product_name 以及生成出的全部 q/intent_cn，如果同時
命中「敏感品類訊號」（如兩性健康/私密護理類詞及其近義詞/委婉說法）和「權威宣稱訊號」（如
虛構 FDA/醫生/專家認證類詞及其近義詞），不會拒絕生成，但會在產出的 meta.warnings
裡強制追加固定提示，判據見 workflow.md Phase1 步驟6，訊號詞表見 scripts/validate.js。
已知侷限（如實說明，不是「已完全解決」）：這是固定關鍵詞表判據，不是語義判據，
天然有兩層天花板：① 詞表只覆蓋常見近義詞/委婉說法，任何沒被收進表裡的
新造詞/換一種說法仍能繞過；② 只能掃描到最終產出 JSON 裡存在的欄位（category/
product_name/所有 q/所有 intent_cn），看不到 Phase1 當時讀到的、且完全沒有滲透進
這些欄位的原始輸入全文。設計說明：兩個訊號的掃描範圍統一為全文字段掃描
（category/product_name 及最終生成的 query 和 intent_cn 文字），詞表也補充了常見近義詞
（這只是縮小口子，不是堵死）。不能宣稱「擴表就能堵死」——如果需要更強保證，需要語義層檢測，
這和公理4 TODO 的「格式鎖 vs 語義鎖」天花板是同一類問題。
路由（推薦，非強依賴）
- 已有產品但缺品類/賣點畫像 → 人設/畫像類 skill（若已建）
- 想把搜尋到的素材轉成生成提示詞 → 提示詞組裝類 skill（若已建）
- 想做媒介裂變而不是找參考圖 → 視覺裂變類 skill（若已建）
- 想回入口重新分診 → 100x 體系總入口（若已建）
以上均為「產出後按需推薦」，不是前置依賴；對應 skill 尚未建好時不影響本 skill 獨立工作。
出廠自檢
執行 node scripts/validate.js --selftest 驗證。公理 2/3 是跨條目聚合規則，schema.json
（vanilla JSON Schema）表達不出來，真正執行判定的是 scripts/validate.js：
node scripts/validate.js <bundle.json> [bundle2.json ...] # 驗證產出
node scripts/validate.js --selftest # 跑內建回歸用例
來源
本 skill 方法論基於靈感搜尋方法論體系，採用自包含設計（包含 axioms.md、workflow.md、sources.md、schema.json 與驗證腳本），不依賴外部私有路徑，不含私有資料。逐項演進說明見 sources.md。