> ## Documentation Index
> Fetch the complete documentation index at: https://felimet-hub.jmcores.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 03-1 如何判斷工具與 Skill 是否適合自己

> 別人說好用的工具，對你不一定好用。這個單元給你一套「契合度評估」方法，讓你用自己的任務與工作流當尺，而不是用別人的推薦或社群熱度當尺。

export const FitChecklist = ({lang = "zh"}) => {
  const t = {
    zh: {
      title: "契合度自評工具",
      subtitle: "勾選符合你情況的項目，工具會即時給出建議。",
      sections: [{
        label: "任務契合",
        items: ["我最常做的三個任務，這工具至少覆蓋兩個", "它的「殺手級功能」是我每週都會用到的", "它的限制（token 上限、離線、平台綁定）不會卡到我的真實場景"]
      }, {
        label: "工作流契合",
        items: ["它能在我現有的環境（OS、shell、IDE）裡直接跑，不需要建平行環境", "它的設定檔不會與我現有工具衝突", "它的 hook / skill 機制能在我的 agentic harness 內共存"]
      }, {
        label: "成本契合",
        items: ["我估算過學習 + 維護 + 訂閱 + 遷移成本，換算成時薪後是正值", "我已寫下成功標準（時間、品質、可重現性），不靠感覺判斷", "我設定了試用期限（1-2 週）與明確的放棄條件"]
      }],
      verdicts: [{
        min: 8,
        label: "適合試用",
        color: "#4a7c59",
        bg: "#eaf4ec",
        dark: {
          color: "#7ecf96",
          bg: "#1a3328"
        }
      }, {
        min: 5,
        label: "先補成功標準",
        color: "#8a6a1f",
        bg: "#fdf4dc",
        dark: {
          color: "#e0b84a",
          bg: "#2e2410"
        }
      }, {
        min: 0,
        label: "暫時跳過",
        color: "#8b3a3a",
        bg: "#fdecea",
        dark: {
          color: "#e07a7a",
          bg: "#2e1a1a"
        }
      }],
      verdictLabel: "評估結果",
      checkedCount: (n, t) => `已勾選 ${n} / ${t} 項`
    },
    en: {
      title: "Fit self-evaluation",
      subtitle: "Check the items that apply to your situation; the tool renders a verdict in real time.",
      sections: [{
        label: "Task fit",
        items: ["Of my three most frequent tasks, this tool covers at least two", "Its killer feature is something I will use at least once a week", "Its limitations (token limits, offline, platform lock-in) do not block my real scenarios"]
      }, {
        label: "Workflow fit",
        items: ["It runs in my existing environment (OS, shell, IDE) without a parallel setup", "Its config files will not conflict with my existing tools", "Its hook / skill mechanism can coexist within my agentic harness"]
      }, {
        label: "Cost fit",
        items: ["I have estimated learning + maintenance + subscription + migration costs and the hourly-rate net is positive", "I have written success criteria (time, quality, reproducibility) -- not relying on feeling", "I have set a trial time-box (1-2 weeks) and a written quit condition"]
      }],
      verdicts: [{
        min: 8,
        label: "Ready to trial",
        color: "#4a7c59",
        bg: "#eaf4ec",
        dark: {
          color: "#7ecf96",
          bg: "#1a3328"
        }
      }, {
        min: 5,
        label: "Write success criteria first",
        color: "#8a6a1f",
        bg: "#fdf4dc",
        dark: {
          color: "#e0b84a",
          bg: "#2e2410"
        }
      }, {
        min: 0,
        label: "Skip for now",
        color: "#8b3a3a",
        bg: "#fdecea",
        dark: {
          color: "#e07a7a",
          bg: "#2e1a1a"
        }
      }],
      verdictLabel: "Verdict",
      checkedCount: (n, t) => `${n} / ${t} checked`
    }
  };
  const copy = t[lang] || t.zh;
  const allItems = copy.sections.flatMap(s => s.items);
  const total = allItems.length;
  const [checked, setChecked] = useState({});
  const [dark, setDark] = useState(false);
  useEffect(() => {
    const check = () => setDark(document.documentElement.classList.contains("dark"));
    check();
    const obs = new MutationObserver(check);
    obs.observe(document.documentElement, {
      attributes: true,
      attributeFilter: ["class"]
    });
    return () => obs.disconnect();
  }, []);
  const toggle = key => {
    setChecked(prev => ({
      ...prev,
      [key]: !prev[key]
    }));
  };
  const count = Object.values(checked).filter(Boolean).length;
  const verdict = copy.verdicts.find(v => count >= v.min);
  const vColor = dark ? verdict.dark.color : verdict.color;
  const vBg = dark ? verdict.dark.bg : verdict.bg;
  const css = `
    .fc-root {
      --fc-sienna: #bf7551;
      --fc-sienna-light: #cf8a68;
      --fc-border: #e0d6cc;
      --fc-text: #2d2820;
      --fc-muted: #7a6e65;
      --fc-bg: #faf8f5;
      --fc-item-bg: #ffffff;
      --fc-item-hover: #f5f1ec;
      --fc-check-bg: #f0e9e2;
      font-family: inherit;
      border-radius: 10px;
      border: 1px solid var(--fc-border);
      background: var(--fc-bg);
      padding: 1.25rem 1.5rem 1.5rem;
      margin: 1.5rem 0;
    }
    .dark .fc-root {
      --fc-border: #3a3530;
      --fc-text: #e8e0d8;
      --fc-muted: #9a8e85;
      --fc-bg: #1e1c1a;
      --fc-item-bg: #262320;
      --fc-item-hover: #2e2b27;
      --fc-check-bg: #2a2520;
    }
    .fc-header { margin-bottom: 1rem; }
    .fc-title {
      font-size: 1rem;
      font-weight: 600;
      color: var(--fc-sienna);
      margin: 0 0 0.2rem;
    }
    .fc-subtitle {
      font-size: 0.82rem;
      color: var(--fc-muted);
      margin: 0;
    }
    .fc-sections { display: flex; flex-direction: column; gap: 1rem; }
    .fc-section-label {
      font-size: 0.78rem;
      font-weight: 600;
      text-transform: uppercase;
      letter-spacing: 0.06em;
      color: var(--fc-sienna-light);
      margin: 0 0 0.4rem;
    }
    .fc-items { display: flex; flex-direction: column; gap: 0.35rem; }
    .fc-item {
      display: flex;
      align-items: flex-start;
      gap: 0.6rem;
      padding: 0.5rem 0.65rem;
      border-radius: 6px;
      background: var(--fc-item-bg);
      border: 1px solid var(--fc-border);
      cursor: pointer;
      transition: background 0.15s;
      user-select: none;
    }
    .fc-item:hover { background: var(--fc-item-hover); }
    .fc-checkbox {
      flex-shrink: 0;
      width: 16px;
      height: 16px;
      border-radius: 4px;
      border: 1.5px solid var(--fc-sienna);
      background: var(--fc-check-bg);
      display: flex;
      align-items: center;
      justify-content: center;
      margin-top: 1px;
      transition: background 0.15s;
    }
    .fc-checkbox.checked {
      background: var(--fc-sienna);
      border-color: var(--fc-sienna);
    }
    .fc-checkmark {
      width: 9px;
      height: 9px;
      stroke: white;
      stroke-width: 2.5;
      fill: none;
    }
    .fc-item-text {
      font-size: 0.875rem;
      color: var(--fc-text);
      line-height: 1.45;
    }
    .fc-verdict-wrap {
      margin-top: 1.25rem;
      padding-top: 1rem;
      border-top: 1px solid var(--fc-border);
      display: flex;
      align-items: center;
      justify-content: space-between;
      flex-wrap: wrap;
      gap: 0.5rem;
    }
    .fc-count {
      font-size: 0.82rem;
      color: var(--fc-muted);
    }
    .fc-verdict-badge {
      font-size: 0.85rem;
      font-weight: 600;
      padding: 0.3rem 0.8rem;
      border-radius: 20px;
      transition: all 0.2s;
    }
    .fc-verdict-label {
      font-size: 0.75rem;
      color: var(--fc-muted);
      margin-right: 0.4rem;
    }
    @media (max-width: 540px) {
      .fc-root { padding: 1rem; }
      .fc-verdict-wrap { flex-direction: column; align-items: flex-start; }
    }
  `;
  return <div className="fc-root">
      <style>{css}</style>
      <div className="fc-header">
        <p className="fc-title">{copy.title}</p>
        <p className="fc-subtitle">{copy.subtitle}</p>
      </div>
      <div className="fc-sections">
        {copy.sections.map(section => <div key={section.label}>
            <p className="fc-section-label">{section.label}</p>
            <div className="fc-items">
              {section.items.map(item => {
    const key = section.label + "::" + item;
    const isChecked = !!checked[key];
    return <div key={key} className="fc-item" onClick={() => toggle(key)} role="checkbox" aria-checked={isChecked} tabIndex={0} onKeyDown={e => (e.key === " " || e.key === "Enter") && toggle(key)}>
                    <div className={`fc-checkbox${isChecked ? " checked" : ""}`}>
                      {isChecked && <svg className="fc-checkmark" viewBox="0 0 10 10">
                          <polyline points="1.5,5 4,7.5 8.5,2.5" />
                        </svg>}
                    </div>
                    <span className="fc-item-text">{item}</span>
                  </div>;
  })}
            </div>
          </div>)}
      </div>
      <div className="fc-verdict-wrap">
        <span className="fc-count">{copy.checkedCount(count, total)}</span>
        <span>
          <span className="fc-verdict-label">{copy.verdictLabel}</span>
          <span className="fc-verdict-badge" style={{
    color: vColor,
    background: vBg
  }}>
            {verdict.label}
          </span>
        </span>
      </div>
    </div>;
};

export const LearnerPrimer = ({items = [], lang = "zh"}) => {
  const t = lang === "en" ? {
    title: "Before this unit, be honest with yourself",
    sub: "If you can't answer these, that gap is exactly what this unit closes."
  } : {
    title: "讀這個單元前，先誠實面對",
    sub: "這幾題答不出來，正是這個單元要替你補的洞。"
  };
  const css = `
  .lp-root{--lp-bg:#FAF7F1;--lp-surface:rgba(191,117,81,0.05);--lp-border:rgba(0,0,0,0.09);--lp-edge:rgba(191,117,81,0.42);--lp-text:#2b2722;--lp-dim:#6f6a62;--lp-accent:#bf7551;border:1px solid var(--lp-border);border-left:3px solid var(--lp-edge);border-radius:13px;background:var(--lp-bg);color:var(--lp-text);overflow:hidden;margin:1.25rem 0;}
  .dark .lp-root{--lp-bg:#1b1a18;--lp-surface:rgba(207,138,104,0.07);--lp-border:rgba(255,255,255,0.08);--lp-edge:rgba(207,138,104,0.5);--lp-text:#e7e3da;--lp-dim:#a8a299;--lp-accent:#cf8a68;}
  .lp-head{display:flex;align-items:center;gap:9px;padding:13px 18px 11px;border-bottom:1px solid var(--lp-border);background:var(--lp-surface);}
  .lp-ic{color:var(--lp-accent);flex-shrink:0;}
  .lp-htx{display:flex;flex-direction:column;gap:1px;min-width:0;}
  .lp-title{font-size:14px;font-weight:650;line-height:1.3;letter-spacing:.01em;}
  .lp-sub{font-size:12px;color:var(--lp-dim);line-height:1.4;}
  .lp-list{list-style:none;margin:0;padding:10px 18px 14px;display:flex;flex-direction:column;gap:0;}
  .lp-item{display:flex;align-items:baseline;gap:11px;padding:7px 0;font-size:14px;line-height:1.6;border-top:1px solid var(--lp-border);}
  .lp-item:first-child{border-top:none;}
  .lp-mark{flex-shrink:0;color:var(--lp-accent);font-size:13px;font-weight:700;line-height:1.55;font-variant-numeric:tabular-nums;opacity:.85;}
  .lp-q{flex:1 1 0;min-width:0;color:var(--lp-text);}
  @media (max-width:620px){.lp-head{padding:12px 14px 10px;}.lp-list{padding:8px 14px 12px;}}
  `;
  return <div className="lp-root">
      <style>{css}</style>
      <div className="lp-head">
        <svg className="lp-ic" xmlns="http://www.w3.org/2000/svg" width="18" height="18" viewBox="0 0 24 24" fill="none" stroke="currentColor" strokeWidth="2" strokeLinecap="round" strokeLinejoin="round"><circle cx="12" cy="12" r="10" /><circle cx="12" cy="12" r="6" /><circle cx="12" cy="12" r="2" /></svg>
        <span className="lp-htx">
          <span className="lp-title">{t.title}</span>
          <span className="lp-sub">{t.sub}</span>
        </span>
      </div>
      <ul className="lp-list">
        {items.map((q, i) => <li className="lp-item" key={i}>
            <span className="lp-mark">{String(i + 1).padStart(2, "0")}</span>
            <span className="lp-q">{q}</span>
          </li>)}
      </ul>
    </div>;
};

<LearnerPrimer
  lang="zh"
  items={[
"別人說好用對你不等於好用，這是兩件事",
"你最常做的三個任務，這工具解決了幾個？",
"試用沒寫成功標準，剩下的只是感覺與新鮮感",
"投入再多設定，沉沒成本都不是繼續用的理由",
"KOL 每項都打勾不代表工具通過，他的工作流不是你的",
"「免費」只是把成本從月費搬到你的工時上",
"半年沒重評的工具組合，多半已經有一兩個過時了",
]}
/>

<Info>
  **這個單元解決什麼問題**

  別人說好用的工具，對你不一定好用。這個單元給你一套「契合度評估」方法，讓你用自己的任務與工作流當尺，而不是用別人的推薦或社群熱度當尺。
</Info>

## 學習目標

* [ ] 能用「任務契合 / 工作流契合 / 成本契合」三個面向評估一個工具或 Skill。
* [ ] 能設計一個小範圍試用協定，在投入前用低成本驗證。
* [ ] 能辨識並對抗沉沒成本，知道何時該放棄一個不適合的工具。
* [ ] 能為自己的工具組合設定定期重評節奏。
* [ ] 能用八個 KOL 篩選維度評估一個推薦來源的可信度，並把 KOL 推薦放在評估鏈的正確位置。

***

## 1. 「適合」的三個面向

別人的推薦清單只能告訴你「它能做什麼」，不能告訴你「它對你是否划算」。把判準收斂到三個面向，每個面向各問三到五題，會比看 star 數、讀 README、追蹤 KOL 推薦更接近真實決策。

### 1.1 任務契合：解決的是痛點還是幻想？

不要被「這個工具能做 X」說服，要問「你手上最常做的任務裡，它解決了哪一條」。

具體問題：

* 你最常花時間的三個任務是什麼？它覆蓋了幾個？
* 它的「殺手級功能」對你來說是每週會用一次，還是每年才會用一次？
* 它的限制（token 上限、不支援私有模型、無法離線、平台綁定）有沒有正好卡到你真實的場景？

<Note>
  **任務契合的反例**

  你看上一個「自動產生 PR 描述」的 Skill。但你的工作流是：本地 commit 前自己寫好訊息，PR 開了就 merge，幾乎不靠 PR 描述傳遞資訊。這個 Skill 再強，跟你的任務無關。
</Note>

### 1.2 工作流契合：要遷就它，還是它嵌進來？

工具通常強迫你改變某件事：換 IDE、換 shell、換設定檔位置、換模型、換 CI 流程。把這些摩擦逐條列出，看你願不願意付。

具體問題：

* 你的主力環境是 Windows + PowerShell，工具要求 Linux + zsh，你願意為了它建平行環境嗎？
* 它的設定檔路徑與你現有的（`.claude/`、`.codex/`、`.gemini/`、`.copilot/`）會不會互相覆蓋或搶優先序？
* 它的 hook / subagent / skill 機制能不能在現有的 agentic harness 內共存？還是會要求你整個換掉？
* 你用的是本地模型（llama.cpp、ollama）還是 API 模型，工具是否同時支援？

### 1.3 成本契合：把帳算清楚

成本不是只有訂閱費。把它拆成四項，逐項估：

| 成本類型     | 估算項目             | 提問                                |
| -------- | ---------------- | --------------------------------- |
| 學習       | 第一次到能上手的時間       | 看文件、跑範例、遇到障礙，合計要多少小時？             |
| 維護       | 設定會不會隨版本或專案演化而壞掉 | 半年內預期要修幾次？                        |
| 訂閱 / API | 月費或 token 成本     | 在你預期的使用量下，每月多少？                   |
| 遷移       | 從 A 換到 B 的轉換成本   | 你已存在的 prompts、rules、skills 要重寫多少？ |

<Tip>
  **成本換算的實用單位**

  把所有成本換算成「時薪等值」。月費 30 美元假設你時薪 20 美元，等於每月 1.5 小時。如果你每月只省 30 分鐘，這項成本是負的。
</Tip>

***

## 2. 試用協定：投入前的低成本驗證

不要「安裝了就算試用」。試用要可重現、可量測、可比較。

### 2.1 設計測試案例

選一個你**真實在做、可重複的任務**當測試案例。不要選「我來玩玩」或 demo 任務。

<Note>
  **試用案例設計**

  你想評估 Antigravity 是否能取代 Claude Code 處理日常的 Python 重構。挑三個你最近做過的 refactor commit，每個 200-500 行。把每個 commit 之前的狀態存成 task script，輸入一致，記錄結果。三個案例比單一案例穩，比十個案例省時。
</Note>

### 2.2 設定成功標準

三類指標，缺一不可：

* **時間**：完成同一個任務平均耗時（人 + AI）。自己量，不要靠感覺。
* **品質**：人為 review 後的接受率。不用全部通過，只要一致記錄就行。
* **可重現性**：同樣的 task 再跑一次，結果是否穩定。同 task 重跑出現實質差異佔半數以上，後續除錯時間會吃掉省下的時間。

不要只用「感覺順不順」。感覺會被當天精神、心情、第一次接觸的新鮮感嚴重污染。

### 2.3 限時試用

一週到兩週，不要更長。試用期間的紀律：

* 每天用一行記錄：今天用了沒？順不順？遇到了什麼問題？寫到哪個檔案不重要，持續才是重點。
* 不要中途換測試案例。換案例會讓試用失去比較基準。
* 不要為了讓測試「過」而調整工作流。試用是測工具，不是改你。

期末回頭看這 7 到 14 行，多數是負面訊號或空白，工具不適合你。

***

## 3. 沉沒成本與放棄判準

你為這個工具付出的設定時間、已寫的 prompts、已建立的肌肉記憶，**都不算繼續用的理由**。

### 3.1 放棄訊號

任一成立就該啟動重評：

* 每次使用都在對抗工具（繞過它的限制、修它的 bug、寫 workaround）。
* 產出品質不穩定，而且不穩定的原因在工具而非任務。
* 維護負擔（更新、修設定、處理相容性）開始吃掉它帶來的時間節省。
* 同事或隊友用別的工具能更快達到相同結果。

### 3.2 對抗「再試一下」陷阱

沉沒成本謬誤（sunk cost fallacy）是行為經濟學已確認的決策偏差 \[1]。當你發現自己在想「我已經花這麼多設定時間了，再撐一下」，把那筆花費從決策裡拿掉，重新問：「今天的我，什麼都不知道的情況下，會選這個工具嗎？」

如果答案是「不會」，就放棄。已投入的時間不會回來，繼續投入只會擴大損失。

<Tip>
  **強制決策點**

  在試用期開始前就寫下「什麼情況下我會放棄」。白紙黑字，未來的你比較不會被沉沒成本綁架。這是事前承諾裝置，跟你寫測試計畫是同樣道理。
</Tip>

***

## 4. 「適合」會變，定期重評

你今天的適合清單不是終身契約。三件事會讓它失效：

* **任務變了**：你換專案、換角色、換團隊、換工作內容。
* **工具變了**：工具本身升級、轉維護、被新工具取代。
* **你變了**：你的技能成長後，原本的瓶頸不再是瓶頸。

每季或每半年花一個小時，把目前主要在用的三到五個工具 / Skill 各跑一次第一節的三個面向問題（節奏依工具更新速度與你的工具組合大小自調）。如果哪一個分數明顯下降，啟動第二節的試用協定，主動尋找替代品。

<Note>
  **重評的具體動作**

  你用了一個 code-review Skill 六個月。重評時發現：工作流已從「PR 為主」轉成「trunk-based + 短 lived branch」，code review 頻率降到每週一次。Skill 變得低頻使用，但每月訂閱仍在跑。決定：取消訂閱，等真的回到 PR-heavy 流程再啟用。
</Note>

***

## 5. KOL 推薦的批判性接收

你採用新工具的入口之一是關鍵意見領袖（KOL，Key Opinion Leader）的推薦。KOL 本身要先篩選，否則你拿到的不是資訊，是別人的偏見加上平台演算法的增益。

KOL 篩選是上游濾鏡，不是第一節三個面向的替代品。兩者串接：先用 KOL 篩選把推薦來源分成可採納與不可採納兩群；只有從可採納群出來的推薦，才進第一節的三個面向 + 第二節的試用協定。

### 5.1 八個篩選維度

| 維度                   | 問什麼                                 | 紅燈訊號                 |
| -------------------- | ----------------------------------- | -------------------- |
| **Reasoning 論證透明度**  | 推薦時是否說「為什麼」與「在什麼條件下成立」，並主動點出缺點與取捨   | 只給結論不給理由；通篇只有優點      |
| **Disclosure 利益揭露**  | 是否清楚標示業配、聯盟連結、持股或廠商贈品，並把業配與真心推薦分開陳述 | 業配與真心推薦混雜未標；刻意隱藏     |
| **Range 批判光譜**       | 是否曾對自己領域內的東西說「不要買」或給負評              | 從不說壞話，零鑑別度           |
| **Recovery 認錯與修正**   | 過去的推薦出問題時是公開更正、補充說明，還是默默刪文          | 默默刪文；不認錯             |
| **Fit 處境相似度**        | 他的預算、技術水準、使用情境與你的差距                 | 職業玩家推業餘者；大企業預算推個人開發者 |
| **Depth 使用深度**       | 長期實際使用 vs 開箱速評 / 廠商樣機第一印象           | 樣本時間過短；樣機評測          |
| **Recency 時效與更新**    | 內容是否跟上領域變化；舊推薦在情況改變後是否更新或標註過時       | 3C / 軟體 / 工具類推薦過期未更新 |
| **Independence 獨立性** | 是否長期只吹捧單一品牌或生態                      | 被單一廠商實質綁定；負評只挑競品開刀   |

<Tip>
  **篩選門檻與權重**

  8 項中命中紅燈 0-1 項：可採納。命中 2-3 項：降權，他的推薦只能當發現入口的提示。命中 4 項以上：直接跳過這個人的所有推薦，省你的時間。
</Tip>

### 5.2 紅燈 KOL 樣態

<Note>
  **命中 4 項以上的典型組合**

  * **單一廠商綁定型**：某 YouTube 頻道主推 Apple 生態三年，從未給 Android 任何正評；影片開箱當天就有「購買連結」與聯盟標籤。命中 Independence、Disclosure、Range。
  * **快速換品不更新型**：某 Substack 作者推薦的工具每半年換一批，舊文從不更新；從未公開修正過任何一篇推薦。命中 Recency、Recovery、Range。
  * **業配隱藏型**：某 Podcast 來賓是某 AI 工具的 VP，推薦時說「我用了一年很滿意」，但該集是贊助集數，事先未揭露。命中 Disclosure、Depth、Range。
  * **高預算不自知型**：某硬體 KOL 推「生產力筆電」，預算 NT\$120k 起跳，從未給中低階機型任何篇幅。命中 Fit、Range、Independence（被高階生態綁定）。
</Note>

### 5.3 KOL 推薦在評估鏈的位置

KOL 通過篩選只是讓他的推薦「有資格」進入你的判斷；不是結論，也不是捷徑。流程是：

<Steps>
  <Step title="KOL 篩選">
    8 項命中紅燈 ≦ 1，否則只當發現入口。
  </Step>

  <Step title="第一節三個面向">
    對推薦的具體工具自己跑一遍（任務 / 工作流 / 成本契合）。
  </Step>

  <Step title="第二節試用協定">
    做實證，量時間、品質、可重現性。
  </Step>

  <Step title="第四節重評節奏">
    採納後納入定期重評清單。
  </Step>
</Steps>

KOL 推薦在這條鏈裡的權重不超過發現階段；任何一步沒過，結論就是不採用。KOL 八項全部通過但第一節三個面向打分偏低，照樣不採用。他的判斷跟你的判斷是兩件事。

<Warning>
  **KOL 通過 ≠ 工具通過**

  把篩選 KOL 跟篩選工具混為一談，是把「誰在推薦」誤用成「推薦什麼」。推薦者的可信度是輸入濾鏡，不是工具本身的訊號。第一節到第四節的紀律不能因為 KOL 知名而省略。
</Warning>

***

## 互動評估工具

<FitChecklist lang="zh" />

***

## 常見誤區

* **因為某大神在用就採用**。KOL 的任務、團隊、規模跟你不同，盲目跟風是把自己放進別人的問題模型。
* **把「功能多」當成「適合我」**。功能多通常代表設定面廣；設定面廣在你不需要的功能上，就是維護負擔。
* **投入太多設定後不願承認不適合**。沉沒成本謬誤的典型表現。設定花的時間不會回來，但繼續用會持續付出機會成本。
* **試用期沒寫成功標準**。沒有標準就只剩感覺，感覺會被期待與新鮮感污染。
* **把「免費」當成沒成本**。免費工具的學習、維護、遷移成本照樣存在。「免費」只是把成本從月費搬到你的工時上。

## 自我檢核

<Check>
  **自我檢核**

  * 你能說出你正在用的某個工具，具體解決了你哪個可量測的痛點嗎？
  * 你目前最貴的那個訂閱，是在上次重評之後才續的嗎？
  * 你的工作流裡，有沒有正在「對抗」的工具？對抗的成本是什麼？
  * 你上次啟動一次試用協定是什麼時候？結果如何？
</Check>

## 來源與延伸閱讀

事實主張依官方文件，快變動項標註截至 2026-05。

<div className="references">
  * \[1] R. Thaler, "Toward a Positive Theory of Consumer Choice," *Journal of Economic Behavior & Organization*, vol. 1, no. 1, pp. 39-60, Mar. 1980. [https://doi.org/10.1016/0167-2681(80)90051-7](https://doi.org/10.1016/0167-2681\(80\)90051-7) （截至 2026-05）沉沒成本效應的經濟學原始論述。
</div>

* 評估訊號的具體操作見 [03-2 跳脫 star 數迷思的評估框架](/code-agent/judgment/beyond-github-stars)。
* 安全 / 隱私 / 供應鏈的對位評估見 [03-3 安全、隱私與供應鏈風險](/code-agent/judgment/security-privacy-supply-chain)。
* 量化驗證見 [03-4 建立個人 benchmark 與驗證習慣](/code-agent/judgment/personal-benchmark)。