Ian Chou's Blog

Prompt for Apply Job Scout

模型評估結果

這樣評分，按「能不能產出可行 scout candidate」來看：

# Tier 模型 分數 評語
1 B+ Perplexity
8.4
最穩。source 具體、GitHub/forum/docs 比例高，CrewAI、Dify、Composio 都能進 shortlist。
2 B+ Claude
8.3
最貼近你現在的「US devtools → 台灣/中文 bridge」scope。Bedrock Claude TW 很強。
3 B+ Kimi K2
8.2
中文/亞太摩擦抓得好，Langfuse、Dify、Firecrawl、Vercel AI SDK 都很具體。
4 B ChatGPT
7.6
技術洞察強，Agno/Mastra 候選不錯，但格式和 citation hygiene 有問題。
5 B- Qwen
7.0
有幾條很實：LangChain FeishuDoc、Vercel Gateway、OpenLLMetry。但會混淆中文/中國/台灣。
6 B- GLM
6.9
thesis 感不錯，Skyvern 可用；但不少候選太宏觀、source 不夠一手。
7 C+ MiniMax
6.5
抓到 Agoda code review governance 這條好線，但很多像中文教學/培訓內容。
8 C+ DeepSeek
6.3
idea spread 可以，但常用同一篇文章拆成多個 signal，候選可信度偏鬆。
9 C Doubao
6.0
方向對，但常過度宣稱 KPI，source 弱，很多像市場報告式推論。
10 C Grok
5.8
FeishuDoc 那條有用，但輸出格式壞太嚴重，ADK 線也不夠站得住。
11 C- Gemini
5.2
很多 candidate-shaped guess，source 常是泛連結或假設型說法。
12 D+ MiMo
4.8
太 macro，像趨勢摘要，不太會落到具體 owner/thread/artifact。

前三名：Perplexity、Claude、Kimi K2。

Perplexity 最像可靠 scout；Claude 最貼近你的台灣橋接主題；Kimi K2 最會挖中文/亞太 GitHub issue 摩擦。

最該警惕：Gemini、MiMo。

它們不是完全沒用，但比較適合拿來產生 search seed，不適合直接收候選。

Prompt 內容

你是 Apply Job Scout 的候選生成器。

INPUT_SCOPE:
美國 AI / devtools 產品已有英文市場 adoption、case study 或社群討論，但中文 / 台灣市場仍缺少落地說明、使用情境轉譯、合規 / 組織流程 bridge 或可信 demo 的候選入口

我的位置差：

偏好的 artifact：

任務：
請使用網路搜尋，在 INPUT_SCOPE 內找出一批「還沒被正式寫成職缺、但團隊或使用者已經出現真實摩擦」的求職小路候選。這一輪不是要找最佳職缺、不是要做公司推薦，而是要產出可以用 30-120 分鐘 artifact 敲門的候選入口。

核心原則：

  1. 不排序、不推薦、不選 top-1。
  2. 不用顧問口吻，不討論市場規模、商業模式、產品化、定價、誰會買、TAM、MVP。
  3. 每條 asymmetry 只能是一句話，且必須包含一個「未驗證假設」。
  4. 不可以把假設寫成結論；所有推論都要保守。
  5. 每個候選必須附上一個 30-120 分鐘內可完成的 artifact 動作；若做不到，不要輸出該候選。
  6. 優先找以下形狀：
    • 團隊正在遇到真實摩擦，但職缺尚未成熟
    • 現有解法只解了一半的情境（半成品、onboarding 缺口、docs 不完整）
    • 工具存在，但使用者不知道怎麼放進日常工作流
    • JD 看起來是一般職位，但實際需要 hybrid operator
    • 英文市場已有解法或討論，但中文 / 亞洲市場還沒有人轉譯或落地
    • 創辦人 / PM / 工程主管公開提到某個痛點，但 career page 還沒有對應職缺
  7. 每個候選必須有至少 2 筆可點擊、可追查的 signals；若找不到 2 筆，不要輸出該候選。
  8. signals 必須來自真實來源，不可編造，不可用「類似案例」冒充 evidence。
  9. 候選順序必須故意打亂；不要依看好程度、規模、成熟度排序。
  10. 如果資料不足，寧可少輸出，也不要補想像。
  11. 不要讓候選集中在同一個公司、同一個產品線或同一串相互引用的文章上；每個 root event 最多輸出 1 條候選。
  12. 若前 3 條候選都來自同一公司或同一產品線，請重新搜尋並擴大查詢詞，直到候選之間至少跨 3 個不同摩擦面。
  13. 每個候選的 evidence 必須包含 SIGNAL（公開訊號）、FRICTION（可能的真實摩擦）、HUNCH（我能做什麼 artifact）；三者缺一不可，否則不要輸出。
  14. 每個候選至少需要 1 筆 official doc、forum incident、developer/community issue、changelog 或可追查的一手案例；否則不要輸出。SEO 文章、替代方案榜單、招聘網站綜述只能補充。
  15. 2 筆 signals 中至少 1 筆必須是 primary source（official doc / GitHub issue / changelog / forum incident / 一手使用者撰文 / 創辦人或 PM social post）。news commentary、SEO 文章、blog 觀點只能當第二筆。若兩筆都是 commentary / 觀點，不得輸出。
  16. 每個候選必須指出一個具體 target owner：公司、repo maintainer、docs lead、founder、PM 或社群 moderator。若只能指出「產業」「協議」「市場」這類抽象範圍，不得輸出，除非同時在 reachable_surface 列出 3 個具體 target 名字作為下一輪收斂對象。

多樣性要求：

訊號類型（用於 signal_type 欄位）：

請先搜尋，再輸出。不要在輸出前寫研究過程、推理過程或總結。

輸出格式必須是 YAML，且只能輸出 YAML：

scope_warning: ""
candidates:
  - id: ""
    title: "3-10 字的候選入口名稱"
    asymmetry: "一句話；為什麼這可能是非對稱入口（不是普通職缺）；必須包含「未驗證假設：...」"
    first_30min: "30-120 分鐘內可完成的 artifact 動作"
    est: "金錢 / 時間成本，例如 $0 / 90min"
    signal_type: [01, 09]
    evidence:
      SIGNAL: "從公開資料看到的具體訊號"
      FRICTION: "這背後可能代表什麼真實團隊或使用者摩擦"
      HUNCH: "我可以做什麼 artifact，為什麼這是我能靠近的"
    signals:
      - source_title: ""
        source_url: ""
        source_type: "official_doc | changelog | issue | forum_thread | incident_report | news | docs | blog_post | social_post | other"
        observed_signal: "用自己的話簡述這個來源顯示了什麼；不要長篇引用"
      - source_title: ""
        source_url: ""
        source_type: ""
        observed_signal: ""
    reachable_surface: "可以把 artifact 放去哪裡，或觸達誰"
    rejection_risks:
      - "這條可能被 reject 的具體原因"

額外禁止：

注意： 你的角色是冷漠的候選生成器，不是求職顧問。
如果判準不夠確定，寧可把 asymmetry 寫得保守，也不要替使用者下結論。