;
};
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
{t.title}{t.sub}
{items.map((q, i) =>
{String(i + 1).padStart(2, "0")}{q}
)}
;
};
**What this unit solves**
A tool someone else swears by may do nothing for you. This unit gives you a fit-evaluation framework anchored in your own tasks and workflow, not in recommendations or community hype.
## Learning objectives
* [ ] Evaluate a tool or Skill across three dimensions: task fit, workflow fit, and cost fit.
* [ ] Design a small-scope trial protocol to validate a tool at low cost before committing.
* [ ] Recognize and counter sunk-cost bias, and know when to abandon a tool that does not fit.
* [ ] Set a periodic re-evaluation cadence for your tool stack.
* [ ] Apply eight KOL screening dimensions to assess the credibility of a recommendation source, and place KOL recommendations at the correct position in the evaluation chain.
***
## 1. The three dimensions of "fit"
A recommendation list tells you only "what it can do"; it cannot tell you "whether it is worth it for you." Collapsing the judgment into three dimensions, asking three to five questions per dimension, gets you closer to a real decision than reading star counts, skimming READMEs, or following KOL recommendations.
### 1.1 Task fit: does it solve a real pain point or a fantasy?
Do not be persuaded by "this tool can do X." Ask instead: "which of the tasks I spend the most time on does it actually address?"
Concrete questions:
* What are the three tasks you spend the most time on? How many does this tool cover?
* Is its "killer feature" something you would use once a week, or once a year?
* Do its limitations (token limits, no private-model support, no offline mode, platform lock-in) happen to block your real use cases?
**A task-fit counter-example**
You are eyeing a Skill that auto-generates PR descriptions. But your workflow is: write the commit message yourself before committing locally, open a PR and merge it, almost never relying on the PR description to convey information. However capable that Skill is, it is irrelevant to your tasks.
### 1.2 Workflow fit: do you adapt to it, or does it slot into your flow?
Tools usually force you to change something: swap your IDE, your shell, your config file location, your model, your CI pipeline. List every friction point and ask whether you are willing to pay for each one.
Concrete questions:
* Your primary environment is Windows + PowerShell; the tool requires Linux + zsh. Are you willing to maintain a parallel environment for it?
* Will its config file path collide with your existing ones (`.claude/`, `.codex/`, `.gemini/`, `.copilot/`) or compete for precedence?
* Can its hook / subagent / skill mechanism coexist within your existing agentic harness, or does it require you to replace the whole thing?
* Do you use local models (llama.cpp, ollama) or API models? Does the tool support both?
### 1.3 Cost fit: run the actual numbers
Cost is not just the subscription fee. Break it into four items and estimate each:
| Cost type | What to estimate | The question |
| ------------------ | ----------------------------------------------------- | ------------------------------------------------------------------ |
| Learning | Time from zero to functional | How many hours total for docs, examples, and obstacles? |
| Maintenance | Will the config break as versions or projects evolve? | How many times do you expect to fix it in six months? |
| Subscription / API | Monthly fee or token spend | At your expected usage, what is the monthly figure? |
| Migration | Switching cost from A to B | How many existing prompts, rules, and skills would need rewriting? |
**A useful unit for cost conversion**
Convert all costs into hourly-rate equivalents. A $30/month fee at a $20/hour rate equals 1.5 hours per month. If you save only 30 minutes per month, the net cost is negative.
***
## 2. The trial protocol: low-cost validation before you commit
"Installed it, that counts as a trial" does not count. A trial needs to be reproducible, measurable, and comparable.
### 2.1 Design test cases
Pick a **real, repeatable task** as your test case. Do not pick a "let me play around" or demo task.
**Trial case design**
You want to evaluate whether Antigravity can replace Claude Code for your day-to-day Python refactoring. Pick three recent refactor commits you actually made, each 200-500 lines. Save the state of the codebase before each commit as a task script, keep the input consistent, and record the results. Three cases are more stable than one, and cheaper than ten.
### 2.2 Set success criteria
Three classes of metric, all required:
* **Time**: average time to complete the same task (human + AI). Measure it; do not rely on feeling.
* **Quality**: acceptance rate after human review. You do not need a perfect pass rate; you just need consistent recording.
* **Reproducibility**: run the same task again and check whether the result is stable. If more than half of re-runs differ substantially, debugging time will eat whatever time you saved.
Do not rely solely on "does it feel smooth." Feelings are heavily contaminated by your energy level, mood, and the novelty of first contact.
### 2.3 Time-box the trial
One to two weeks, no longer. Discipline during the trial:
* One-line daily log: did you use it today? Was it smooth? What problems came up? Where you write it does not matter; consistency does.
* Do not swap test cases mid-trial. Changing cases destroys the baseline for comparison.
* Do not adjust your workflow to make the test "pass." The trial is testing the tool, not retraining you.
At the end, look back at those 7 to 14 lines. If most are negative signals or blank, the tool does not fit.
***
## 3. Sunk cost and the criteria for quitting
The setup time you put in, the prompts you wrote, the muscle memory you built: **none of those are reasons to keep using the tool**.
### 3.1 Signals to quit
Any one of these is enough to trigger a re-evaluation:
* Every use is a fight against the tool (working around its limits, patching its bugs, writing workarounds).
* Output quality is unstable, and the instability originates in the tool, not the task.
* Maintenance overhead (updates, config fixes, compatibility issues) is starting to eat the time savings it provides.
* Colleagues or teammates reach the same result faster with a different tool.
### 3.2 Countering the "one more try" trap
Sunk cost fallacy is a well-confirmed decision bias in behavioral economics \[1]. When you catch yourself thinking "I've already invested so much setup time, I'll push through a bit longer," remove that sunk cost from the decision and ask fresh: "Knowing nothing about what I've already spent, would I choose this tool today?"
If the answer is no, walk away. Time already invested does not come back; continuing to invest only compounds the loss.
**Force a decision point in advance**
Before the trial starts, write down the conditions under which you will abandon it. Having it in writing makes it harder for future-you to be held hostage by sunk cost. This is a precommitment device, the same logic as writing a test plan before you write the code.
***
## 4. "Fit" changes: schedule re-evaluations
Your current fit list is not a lifetime contract. Three things will invalidate it:
* **Your tasks changed**: you switched projects, roles, teams, or job responsibilities.
* **The tool changed**: it upgraded, went into maintenance mode, or got superseded.
* **You changed**: your skills grew and the old bottleneck is no longer a bottleneck.
Every quarter or every six months, spend one hour running the three-dimension questions from Section 1 across the three to five tools or Skills you use most heavily (adjust the cadence to your tools' update velocity and stack size). If any tool's score drops noticeably, activate the trial protocol from Section 2 and actively search for an alternative.
**What a re-evaluation looks like in practice**
You have been using a code-review Skill for six months. On re-evaluation you notice: your workflow has shifted from "PR-centric" to "trunk-based + short-lived branches," and code reviews are down to once a week. The Skill is now low-frequency but the monthly subscription is still running. Decision: cancel the subscription; re-enable it if and when you return to a PR-heavy flow.
***
## 5. Receiving KOL recommendations critically
One of the ways you discover new tools is through recommendations from key opinion leaders (KOLs). KOLs themselves require screening first; without it, what you receive is not information but someone else's bias amplified by platform algorithms.
KOL screening is an upstream filter, not a replacement for the three dimensions in Section 1. The two connect in sequence: use KOL screening to split recommendation sources into "eligible" and "ineligible"; only recommendations from the eligible group enter the three-dimension evaluation in Section 1 and the trial protocol in Section 2.
### 5.1 Eight screening dimensions
| Dimension | What to ask | Red-flag signal |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| **Reasoning transparency** | Does the recommendation explain "why" and "under what conditions," and proactively name downsides and trade-offs? | Conclusions with no reasoning; exclusively positive coverage |
| **Disclosure** | Are sponsorships, affiliate links, equity stakes, and vendor gifts clearly labeled, with sponsored and genuine recommendations kept separate? | Sponsored and genuine mixed without labeling; deliberate concealment |
| **Range** | Have they ever said "don't buy" or given a negative assessment for something in their domain? | Never says anything negative; zero discriminatory value |
| **Recovery** | When a past recommendation turned out to be wrong, did they publicly correct or clarify, or quietly delete? | Quietly deleted; never admitted an error |
| **Fit** | How far is their budget, technical level, and use context from yours? | Professionals recommending to hobbyists; enterprise budgets applied to solo developers |
| **Depth** | Long-term real use vs. unboxing speed review / first impression on a vendor sample unit | Sample period too short; sample-unit review |
| **Recency** | Does the content keep pace with how the field is changing? Are outdated recommendations updated or flagged as stale? | Consumer electronics / software / tools recommendations not updated after the landscape shifts |
| **Independence** | Do they consistently champion only a single brand or ecosystem? | Effectively tied to one vendor; negative coverage reserved exclusively for competitors |
**Screening threshold and weighting**
0-1 red flags out of 8: eligible. 2-3 red flags: downweight; their recommendations are hints for discovery only. 4 or more red flags: skip everything from this person entirely. It saves time.
### 5.2 KOL archetypes that hit four or more red flags
**Typical combinations that hit four or more**
* **Single-vendor captive**: a YouTube channel that has promoted the Apple ecosystem for three years and never given Android a positive review; affiliate links appear on the same day as the unboxing. Hits Independence, Disclosure, Range.
* **Rapid-switcher who never updates**: a Substack author whose recommended tools rotate every six months; old posts are never updated; no recommendation has ever been publicly corrected. Hits Recency, Recovery, Range.
* **Hidden sponsorship**: a podcast guest who is a VP at an AI tool company says "I've used it for a year and I love it," but the episode is a sponsored one never disclosed upfront. Hits Disclosure, Depth, Range.
* **High-budget self-unaware**: a hardware KOL recommending "productivity laptops" starting at NT\$120k, with no coverage of mid-range or budget options. Hits Fit, Range, Independence (captured by the high-end ecosystem).
### 5.3 Where KOL recommendations sit in the evaluation chain
Passing the KOL screen merely makes a recommendation "eligible" to enter your judgment; it is not a conclusion, not a shortcut. The sequence is:
At most 1 red flag out of 8; otherwise treat the recommendation as a discovery hint only.
Run the specific recommended tool yourself through task / workflow / cost fit.
Do the empirical work: measure time, quality, and reproducibility.
Once adopted, add it to the periodic re-evaluation list.
The KOL recommendation's weight in this chain does not exceed the discovery stage. Fail any step and the conclusion is: do not adopt. A KOL who passes all eight dimensions but whose recommended tool scores low across Section 1 still does not get adopted. Their judgment and your judgment are two separate things.
**KOL passes the screen does not mean the tool passes**
Conflating "screening the KOL" with "screening the tool" is misusing "who is recommending" as a proxy for "what is being recommended." The recommender's credibility is an input filter, not a signal about the tool itself. The discipline of Sections 1 through 4 cannot be skipped because the KOL is well-known.
***
## Interactive evaluation tool
***
## Common pitfalls
* **Adopting a tool because a well-known person uses it.** Their tasks, team, and scale differ from yours. Blind following puts you inside someone else's problem model.
* **Treating "more features" as "fits me better."** More features usually means a broader configuration surface; a broad configuration surface covering features you do not need is maintenance burden.
* **Refusing to admit a tool does not fit after investing too much setup time.** This is the textbook sunk cost fallacy. Setup time does not return, but continued use keeps paying opportunity cost.
* **Running a trial without written success criteria.** Without criteria there are only feelings, and feelings are contaminated by expectation and novelty.
* **Treating "free" as having no cost.** A free tool still carries learning, maintenance, and migration costs. "Free" just moves the cost from a subscription fee to your working hours.
## Self-check
**Self-check**
* Can you name a specific, measurable pain point that a tool you currently use actually solves?
* Is your most expensive current subscription one you renewed after your last re-evaluation?
* Is there a tool in your workflow that you are actively fighting against? What is the cost of that fight?
* When did you last run a structured trial protocol? What was the outcome?
## Sources and further reading
Factual claims are grounded in official documentation; fast-changing items are annotated as of 2026-05.
* \[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) (as of 2026-05) Original economic treatment of the sunk cost effect.
* For concrete signal evaluation see [03-2 Beyond GitHub Stars: an evaluation framework](/en/code-agent/judgment/beyond-github-stars).
* For security, privacy, and supply-chain assessment see [03-3 Security, Privacy, and Supply-Chain Risk](/en/code-agent/judgment/security-privacy-supply-chain).
* For quantitative validation see [03-4 Building a Personal Benchmark and Verification Habit](/en/code-agent/judgment/personal-benchmark).