"Simplicity is the ultimate sophistication." — Leonardo da Vinci
「簡潔是複雜的極致。」—— Leonardo da Vinci
Roundtable Participants:
- Derek Huang | Staff Engineer at a FAANG company, 12 years of code review experience, self-described "PR nitpicker"
- Mia Torres | Claude Code power user, DevOps lead, runs /simplify on every branch before PR
- Prof. Alan Crawford | Software engineering professor, author of Refactoring Beyond the IDE
- Yuki Tanaka | Open-source maintainer, skeptical of AI-generated code changes
- Sandra Kim | Engineering manager, oversees a team of 30, focused on review process efficiency
- Leo Zhang | Junior frontend developer, 2 years of experience, adopted Claude Code 6 months ago
Moderator: Let's get straight to it. Claude Code's /simplify command — it spawns three parallel review agents that check your changed code for reuse, quality, and efficiency, then auto-fixes what it finds. Derek, you've reviewed tens of thousands of PRs. What's your take?
圓桌會議參與者：
- Derek Huang | FAANG 公司 Staff Engineer，12 年 code review 經驗，自稱「PR 吹毛求疵王」
- Mia Torres | Claude Code 重度使用者，DevOps 負責人，每個分支 PR 前必跑 /simplify
- Prof. Alan Crawford | 軟體工程教授，《Refactoring Beyond the IDE》作者
- Yuki Tanaka | 開源專案維護者，對 AI 生成的程式碼變更持懷疑態度
- Sandra Kim | 工程經理，管理 30 人團隊，專注於 review 流程效率
- Leo Zhang | Junior 前端工程師，2 年經驗，使用 Claude Code 約半年
主持人： 直接開始。Claude Code 的 /simplify 指令——它會同時派出三個平行 review agent，分別檢查你改動的程式碼在 reuse、quality 和 efficiency 方面的問題，然後自動修正。Derek，你 review 過上萬個 PR 了，怎麼看？
Round 1: What Exactly Does /simplify Do?
Derek Huang: Let me break down the mechanics first. When you run /simplify, Claude Code spawns three parallel agents:
- Code Reuse Agent — hunts for duplicated logic, DRY violations, missed abstractions
- Code Quality Agent — checks consistency, error handling, design patterns
- Efficiency Agent — spots performance issues, unnecessary iterations, missed concurrency
After all three finish, it aggregates findings, filters out false positives, and applies fixes directly to your files. It only looks at files you've changed in the current Git working tree — not your entire codebase.
Mia Torres: And you can focus it. Pass text arguments like:
/simplify focus on memory efficiency
/simplify check for duplicated logic
/simplify optimize database queriesThe argument gets injected into the agents' prompts, so they prioritize what you care about.
Leo Zhang: Wait — it auto-fixes? It doesn't just report issues?
Derek Huang: Correct. It edits your files directly. Which is why you need to review the diff afterward. It's not a linter that yells at you — it's a colleague who goes ahead and rewrites your code.
Yuki Tanaka: raises hand And that's exactly the problem. A colleague who rewrites your code without asking is not a colleague — that's a liability.
Moderator: Hold that thought, Yuki. We'll get to risks. Let's first establish the workflow.
第一回合：/simplify 到底做了什麼？
Derek Huang： 先拆解機制。當你執行 /simplify，Claude Code 會同時派出三個平行 agent：
- Code Reuse Agent —— 搜尋重複邏輯、DRY 違規、錯過的抽象
- Code Quality Agent —— 檢查一致性、錯誤處理、設計模式
- Efficiency Agent —— 找出效能問題、不必要的迭代、可用但未用的並發機制
三個 agent 全部完成後，它會彙整發現、過濾掉誤報，然後直接修改你的檔案。它只看你在當前 Git working tree 中改動過的檔案——不是整個 codebase。
Mia Torres： 而且你可以聚焦它。傳入文字參數：
/simplify focus on memory efficiency
/simplify check for duplicated logic
/simplify optimize database queries參數會被注入 agent 的 prompt，讓它們優先處理你在意的部分。
Leo Zhang： 等等——它會自動修正？不是只回報問題？
Derek Huang： 對。它直接編輯你的檔案。所以你之後必須 review diff。它不是一個對你嚷嚷的 linter——它是一個直接幫你重寫程式碼的同事。
Yuki Tanaka： 舉手 這就是問題所在。一個不問你就重寫程式碼的同事不是同事——是風險。
主持人： Yuki，先記住這個想法。我們會討論風險。先確立工作流程。
Round 2: When Should You Use It?
Mia Torres: My workflow is dead simple, and I've been doing this for six months with zero regrets:
- Implement the feature or bug fix
- Run tests — make sure it works
- Run
/simplify— let it clean up - Review the diff —
git diffto see what it changed - Open PR — with simplified code
The key insight: use it as the last step before PR, not during implementation. You don't want it rewriting code you're still iterating on.
Prof. Alan Crawford: I'd refine that. There are three ideal timing windows:
- Post-implementation, pre-PR — Mia's workflow. Catches the "I was focused on making it work, not making it clean" debris
- Post-prototype — when you've got experimental code that survived and you want to keep it. Run
/simplifyto turn a prototype into production-grade code - Post-merge cleanup — controversial, but sometimes you merge something urgently and want to clean it up in a follow-up commit
Sandra Kim: From a team process perspective, I've made /simplify a recommended pre-PR step in our team's contributing guide. Not mandatory — I don't want to be that manager — but strongly encouraged. Our average review cycle time dropped from 2.3 days to 1.6 days.
Derek Huang: That's a 30% reduction. What's driving it?
Sandra Kim: Fewer "nit" comments. The trivial stuff — duplicated constants, inconsistent error handling, that one function that should've been extracted — /simplify catches most of it. Reviewers can focus on architecture and business logic.
Yuki Tanaka: Or reviewers get lazy because they assume /simplify already caught everything.
Sandra Kim: We haven't seen that. If anything, reviewers are more engaged because they're not wasting mental energy on formatting and DRY violations.
第二回合：什麼時候該用？
Mia Torres： 我的工作流程非常簡單，實踐半年了，零後悔：
- 實作功能或修 bug
- 跑測試——確認能動
- 跑
/simplify——讓它清理 - Review diff——用
git diff看它改了什麼 - 開 PR——提交簡化後的程式碼
關鍵洞察：在 PR 之前的最後一步使用，不要在實作過程中用。 你不會想讓它重寫你還在迭代的程式碼。
Prof. Alan Crawford： 我補充一下。有三個理想的時機窗口：
- 實作後、PR 前 —— Mia 的工作流。抓住那些「我只專注讓它能跑，沒管整潔度」的殘留
- 原型完成後 —— 當你有實驗性程式碼存活下來且想保留時，跑
/simplify把原型轉成 production 等級的程式碼 - Merge 後清理 —— 有爭議，但有時候你緊急 merge 了某些東西，想在後續 commit 中清理
Sandra Kim： 從團隊流程的角度，我已經把 /simplify 列為我們團隊 contributing guide 中的建議 PR 前步驟。不是強制——我不想當那種經理——但強烈建議。我們的平均 review 週期從 2.3 天降到 1.6 天。
Derek Huang： 降了 30%。什麼推動了這個變化？
Sandra Kim： 更少的「nit」留言。那些瑣碎的東西——重複的常數、不一致的錯誤處理、那個應該被抽取出來的 function——/simplify 能抓住大部分。Reviewer 可以專注在架構和商業邏輯上。
Yuki Tanaka： 或者 reviewer 變懶了，因為他們假設 /simplify 已經抓住了一切。
Sandra Kim： 我們沒看到這種情況。反而 reviewer 更投入了，因為他們不用把腦力浪費在格式和 DRY 違規上。
Round 3: Can It Replace Human Code Review?
Moderator: The elephant in the room. Can /simplify replace human reviewers?
Derek Huang: No. Next question.
Moderator: ...elaborate?
Derek Huang: sighs Fine. Here's a comparison:
| Aspect | /simplify | Human Reviewer |
|---|---|---|
| Speed | Seconds to minutes | Hours to days |
| Consistency | Same criteria every time | Varies by mood, workload |
| Pattern detection | Excellent — three specialized lenses | Good, but humans miss patterns when tired |
| Business context | Zero | Full understanding of why code exists |
| Architectural judgment | Weak | Strong |
| False positive filtering | Automated, imperfect | Experience-based, reliable |
| Cost | Included in Claude Code | Engineer salary |
The critical gap is intent. /simplify can tell you "this function is duplicated in three places" but it can't tell you "this duplication is intentional because those three modules will diverge next quarter." Only a human who understands the roadmap knows that.
Prof. Alan Crawford: I'll formalize Derek's point. Code review serves four functions:
- Correctness — does the code do what it's supposed to?
/simplifycan partially help - Quality — is the code clean, maintainable, consistent?
/simplifyis excellent here - Knowledge transfer — do other team members understand the change?
/simplifydoesn't help at all - Architectural alignment — does this fit the system's direction?
/simplifyhas no context
So /simplify covers roughly 1.5 out of 4 functions of code review. It's a powerful complement, not a replacement.
Leo Zhang: As a junior, I actually want human reviewers. /simplify fixes my code but doesn't explain why. When Derek leaves a comment saying "extract this into a custom hook because X, Y, Z," I learn something. When /simplify just does it silently, I don't.
Sandra Kim: That's the strongest argument against full automation right there. Leo just described how code review is also a mentorship mechanism.
Mia Torres: I agree with all of that. But let me push back on one framing — nobody's seriously proposing /simplify as a replacement. The real question is: should /simplify run before human review, reducing the human's burden? And the answer is obviously yes.
第三回合：它能取代人類 Code Review 嗎？
主持人： 房間裡的大象。/simplify 能取代人類 reviewer 嗎？
Derek Huang： 不能。下一個問題。
主持人： ⋯⋯可以說明一下嗎？
Derek Huang： 嘆氣 好吧。這是一個比較：
| 面向 | /simplify | 人類 Reviewer |
|---|---|---|
| 速度 | 幾秒到幾分鐘 | 幾小時到幾天 |
| 一致性 | 每次標準相同 | 受心情、工作量影響 |
| 模式偵測 | 優秀——三個專門的視角 | 好，但人類疲勞時會遺漏 |
| 商業脈絡 | 零 | 完全理解程式碼為什麼存在 |
| 架構判斷 | 弱 | 強 |
| 誤報過濾 | 自動化，不完美 | 基於經驗，可靠 |
| 成本 | 包含在 Claude Code 中 | 工程師薪水 |
關鍵差距是意圖。/simplify 能告訴你「這個 function 在三個地方重複了」，但它不能告訴你「這個重複是故意的，因為這三個模組下季度會分歧」。只有理解 roadmap 的人才知道這點。
Prof. Alan Crawford： 我把 Derek 的觀點正式化。Code review 服務四個功能：
- 正確性 —— 程式碼是否做了它該做的事？
/simplify能部分幫助 - 品質 —— 程式碼是否乾淨、可維護、一致？
/simplify在這方面優秀 - 知識轉移 —— 其他團隊成員是否理解這個變更？
/simplify完全無法幫助 - 架構對齊 —— 這是否符合系統的方向？
/simplify沒有脈絡
所以 /simplify 大約覆蓋了 code review 四個功能中的 1.5 個。它是強大的補充，不是替代品。
Leo Zhang： 身為 junior，我其實想要人類 reviewer。/simplify 修了我的程式碼但沒有解釋為什麼。當 Derek 留言說「把這個抽取成 custom hook，因為 X、Y、Z」，我學到東西了。當 /simplify 默默地就做了，我什麼都沒學到。
Sandra Kim： 這是反對全面自動化最有力的論點。Leo 剛描述了 code review 同時也是一種指導機制。
Mia Torres： 我同意以上所有觀點。但讓我反駁一個框架——沒有人認真提議 /simplify 作為替代品。真正的問題是：/simplify 應不應該在人類 review 之前先跑一遍，減輕人類的負擔？ 答案顯然是肯定的。
Round 4: Will It Break My Code?
Yuki Tanaka: This is where I've been waiting. I maintain a library with 2,000+ dependents. If /simplify silently renames an exported function or "simplifies" a public API, that's a breaking change for 2,000 packages. Has anyone here actually had /simplify break something?
Mia Torres: Yes. Once. It extracted a piece of inline logic into a helper function, but the inline version was intentionally duplicated because it needed to diverge for a feature flag. I caught it in the diff review and reverted that specific change. Total time lost: 90 seconds.
Derek Huang: I've seen it over-abstract. It loves to create utility functions. Sometimes three lines of straightforward code is better than one line calling formatUserDisplayName() that lives in a file you have to navigate to. Premature abstraction is a real pattern with /simplify.
Prof. Alan Crawford: This maps to a well-known trade-off in refactoring theory. The Rule of Three says you should abstract only after seeing three instances of duplication. /simplify sometimes abstracts at two — or even one, if it predicts future reuse. That prediction is often wrong.
Leo Zhang: I've had it remove what it thought was dead code, but it was actually behind a feature flag that was off in development. Tests passed because the flag was off. I only caught it because I was reading the diff carefully.
Yuki Tanaka: And there's your problem. The safety net is "read the diff." But humans are terrible at reading diffs carefully, especially when they trust the tool.
Sandra Kim: Which is why I tell my team: treat /simplify output exactly like you'd treat a junior developer's PR. Read every line. Question every change. Don't rubber-stamp it because "the AI did it."
Moderator: Let's vote. Should you always review /simplify output before committing?
| Participant | Vote |
|---|---|
| Derek Huang | Yes — non-negotiable |
| Mia Torres | Yes — but it takes 2 minutes, not 20 |
| Prof. Alan Crawford | Yes |
| Yuki Tanaka | Yes — and I'd add: run tests after |
| Sandra Kim | Yes |
| Leo Zhang | Yes |
Result: 6-0. Always review the diff.
第四回合：它會改壞我的程式碼嗎？
Yuki Tanaka： 這就是我一直在等的部分。我維護一個有 2,000+ 個相依套件的 library。如果 /simplify 默默地重新命名一個 exported function 或「簡化」了一個 public API，對 2,000 個套件來說就是 breaking change。在座有人真的被 /simplify 改壞過東西嗎？
Mia Torres： 有。一次。它把一段 inline 邏輯抽取成 helper function，但那個 inline 版本是故意重複的，因為它需要為 feature flag 分歧。我在 diff review 時抓到了，revert 了那個特定的變更。浪費的總時間：90 秒。
Derek Huang： 我見過它過度抽象。它很愛建 utility function。有時候三行直白的程式碼比一行呼叫 formatUserDisplayName() 更好——後者住在一個你還得跳轉過去的檔案裡。提前抽象是 /simplify 的一個真實模式。
Prof. Alan Crawford： 這對應到重構理論中一個著名的取捨。三次法則（Rule of Three） 說你應該在看到三次重複之後才抽象。/simplify 有時在兩次就抽象了——甚至一次，如果它預測未來會重用。那個預測通常是錯的。
Leo Zhang： 我遇過它刪除了它認為是 dead code 的東西，但那其實是在一個開發環境中關閉的 feature flag 背後。測試通過了因為 flag 是關的。我只是因為仔細讀了 diff 才抓到的。
Yuki Tanaka： 問題就在這。安全網是「讀 diff」。 但人類在仔細讀 diff 這件事上很糟糕，特別是當他們信任這個工具的時候。
Sandra Kim： 這就是為什麼我告訴我的團隊：把 /simplify 的輸出當作 junior 開發者的 PR 來對待。 讀每一行。質疑每一個變更。不要因為「AI 做的」就橡皮圖章蓋下去。
主持人： 來投票。你是否應該在 commit 之前永遠 review /simplify 的輸出？
| 參與者 | 投票 |
|---|---|
| Derek Huang | 是——沒有商量餘地 |
| Mia Torres | 是——但只需要 2 分鐘，不是 20 分鐘 |
| Prof. Alan Crawford | 是 |
| Yuki Tanaka | 是——而且我會補充：之後也要跑測試 |
| Sandra Kim | 是 |
| Leo Zhang | 是 |
結果：6 比 0。永遠要 review diff。
Round 5: /simplify vs. Linters — Do You Still Need ESLint?
Moderator: If /simplify catches code quality issues, do you still need ESLint, Biome, Prettier?
Derek Huang: Absolutely. They solve different problems.
| Tool | Scope | Deterministic? | Speed |
|---|---|---|---|
| ESLint / Biome | Syntax rules, patterns, known antipatterns | Yes — same input, same output | Milliseconds |
| Prettier | Formatting | Yes | Milliseconds |
/simplify | Architectural cleanup, reuse, efficiency | No — LLM-based, non-deterministic | Seconds to minutes |
Linters are guardrails. They prevent known mistakes. /simplify is a second opinion. It catches things linters can't express as rules.
Mia Torres: The practical hierarchy is:
- Prettier / Biome — format on save (instant, deterministic)
- ESLint / Biome lint — catch rule violations on save or in CI (instant, deterministic)
/simplify— architectural cleanup before PR (slow, non-deterministic, but catches higher-level issues)
They're different layers. You wouldn't skip wearing a seatbelt because you have airbags.
Prof. Alan Crawford: nods Well put. Linters enforce a floor — minimum acceptable quality. /simplify raises the ceiling — pushing good code toward great code. You need both.
Yuki Tanaka: raises hand One caveat. /simplify is non-deterministic. Run it twice on the same code, you might get different changes. That's fine for a human-reviewed workflow, but it means you can't put it in CI as a gate. You'd get flaky passes.
Moderator: Vote. Should /simplify replace linters?
| Participant | Vote |
|---|---|
| Derek Huang | No |
| Mia Torres | No |
| Prof. Alan Crawford | No |
| Yuki Tanaka | No |
| Sandra Kim | No |
| Leo Zhang | No |
Result: 0-6. Linters stay. /simplify complements them.
第五回合：/simplify vs. Linter——你還需要 ESLint 嗎？
主持人： 如果 /simplify 能抓住程式碼品質問題，你還需要 ESLint、Biome、Prettier 嗎？
Derek Huang： 絕對需要。它們解決的是不同的問題。
| 工具 | 範圍 | 確定性？ | 速度 |
|---|---|---|---|
| ESLint / Biome | 語法規則、模式、已知反模式 | 是——相同輸入，相同輸出 | 毫秒 |
| Prettier | 格式化 | 是 | 毫秒 |
/simplify | 架構清理、重用、效率 | 否——基於 LLM，非確定性 | 秒到分鐘 |
Linter 是護欄。它們防止已知的錯誤。/simplify 是第二意見。它抓住 linter 無法用規則表達的東西。
Mia Torres： 實務上的層次是：
- Prettier / Biome —— 存檔時格式化（即時、確定性）
- ESLint / Biome lint —— 在存檔或 CI 中抓違規（即時、確定性）
/simplify—— PR 前的架構清理（慢、非確定性，但能抓到更高層次的問題）
它們是不同的層。你不會因為有安全氣囊就不繫安全帶。
Prof. Alan Crawford： 點頭 說得好。Linter 強制一個下限——最低可接受品質。/simplify 拉高上限——把好的程式碼推向優秀。兩者都需要。
Yuki Tanaka： 舉手 一個但書。/simplify 是非確定性的。對相同的程式碼跑兩次，你可能得到不同的變更。在人類 review 的工作流中這沒問題，但這意味著你不能把它放在 CI 裡當作 gate。你會得到不穩定的結果。
主持人： 投票。/simplify 應該取代 linter 嗎？
| 參與者 | 投票 |
|---|---|
| Derek Huang | 否 |
| Mia Torres | 否 |
| Prof. Alan Crawford | 否 |
| Yuki Tanaka | 否 |
| Sandra Kim | 否 |
| Leo Zhang | 否 |
結果：0 比 6。Linter 留下。/simplify 是補充。
Round 6: The Recommended Workflow — Final Consensus
Moderator: Let's build a concrete, actionable workflow. Each of you propose one rule, and we'll vote on each.
Mia Torres: Rule 1: Run /simplify after implementation is complete and tests pass, not during active development.
| Participant | Vote |
|---|---|
| Derek | Yes |
Passed 6-0.
Derek Huang: Rule 2: Always git diff after /simplify and review every change before committing.
| Participant | Vote |
|---|---|
| Derek | Yes |
Passed 6-0.
Yuki Tanaka: Rule 3: Run your test suite after /simplify and before committing.
| Participant | Vote |
|---|---|
| Derek | Yes |
Passed 6-0.
Prof. Alan Crawford: Rule 4: Revert any abstraction that /simplify creates for fewer than three instances of duplication.
Derek Huang: raises hand I disagree. That's too rigid. Sometimes two instances justify abstraction if the logic is complex.
Yuki Tanaka: I agree with Alan. The Rule of Three exists for a reason.
| Participant | Vote |
|---|---|
| Derek | No |
Failed 3-3. No consensus — use your judgment.
Sandra Kim: Rule 5: Use focused arguments when you know the weak area of your code. Example: /simplify focus on error handling after writing a lot of try-catch blocks.
| Participant | Vote |
|---|---|
| Derek | Yes |
Passed 6-0.
Leo Zhang: Rule 6: If you're a junior developer, read /simplify's changes as a learning exercise — try to understand why it made each change before accepting.
Derek Huang: That's actually excellent advice. Treat it as a free mentor.
| Participant | Vote |
|---|---|
| Derek | Yes |
Passed 6-0.
第六回合：推薦工作流程——最終共識
主持人： 來建立一個具體、可執行的工作流程。每人提一條規則，我們逐條投票。
Mia Torres： 規則 1：在實作完成且測試通過後才跑 /simplify，不要在開發過程中跑。
| 參與者 | 投票 |
|---|---|
| Derek | 是 |
6 比 0 通過。
Derek Huang： 規則 2：跑完 /simplify 後一定要 git diff，review 每一個變更後才 commit。
| 參與者 | 投票 |
|---|---|
| Derek | 是 |
6 比 0 通過。
Yuki Tanaka： 規則 3：跑完 /simplify 後、commit 前，先跑你的測試套件。
| 參與者 | 投票 |
|---|---|
| Derek | 是 |
6 比 0 通過。
Prof. Alan Crawford： 規則 4：如果 /simplify 對少於三個重複實例就建立抽象，就 revert 掉。
Derek Huang： 舉手 不同意。這太死板了。有時候兩個實例就足以證明抽象的合理性，前提是邏輯很複雜。
Yuki Tanaka： 我同意 Alan。三次法則存在是有原因的。
| 參與者 | 投票 |
|---|---|
| Derek | 否 |
3 比 3 未通過。無共識——自行判斷。
Sandra Kim： 規則 5：當你知道程式碼的弱點在哪時，使用聚焦參數。 例如：寫了一堆 try-catch 後跑 /simplify focus on error handling。
| 參與者 | 投票 |
|---|---|
| Derek | 是 |
6 比 0 通過。
Leo Zhang： 規則 6：如果你是 junior 開發者，把 /simplify 的變更當作學習練習——試著理解它為什麼做每一個變更，然後才接受。
Derek Huang： 這其實是非常好的建議。把它當成免費的 mentor。
| 參與者 | 投票 |
|---|---|
| Derek | 是 |
6 比 0 通過。
Final Summary: The /simplify Playbook
Five rules that passed unanimous vote, one that split:
Consensus Rules (6-0)
- Run
/simplifyafter implementation + tests, not during active coding - Always
git diffand review every change before committing - Run tests after
/simplify, before committing - Use focused arguments —
/simplify focus on [specific concern] - Juniors: read the changes as a learning exercise before accepting
No Consensus (3-3)
- Whether to enforce the Rule of Three for
/simplify's abstractions — use your own judgment
The Complete Workflow
implement → test → /simplify → git diff → review → test again → commit → PRWhat /simplify Is
- A post-implementation cleanup tool with three parallel review agents
- A complement to linters, formatters, and human code review
- A way to reduce nit-level PR comments by 30%+
- A learning tool for junior developers
What /simplify Is Not
- A replacement for human code review
- A linter or formatter
- Something you run during active development
- A CI gate (non-deterministic output)
- Magic that you can blindly trust
最終總結：/simplify 操作手冊
五條全票通過的規則，一條票數分裂：
共識規則（6 比 0）
- 在實作 + 測試完成後才跑
/simplify，不要在開發過程中跑 - 一定要
git diff並 review 每一個變更後才 commit /simplify之後、commit 之前，跑測試- 使用聚焦參數 ——
/simplify focus on [特定關注點] - Junior 開發者：把變更當學習練習讀過，再接受
無共識（3 比 3）
- 是否對
/simplify的抽象強制三次法則——自行判斷
完整工作流程
實作 → 測試 → /simplify → git diff → review → 再測試 → commit → PR/simplify 是什麼
- 一個實作後清理工具，有三個平行 review agent
- linter、formatter 和人類 code review 的補充
- 一種能減少 30% 以上 nit 等級 PR 留言的方式
- 一個 junior 開發者的學習工具
/simplify 不是什麼
- 人類 code review 的替代品
- linter 或 formatter
- 你在開發過程中跑的東西
- CI gate（輸出是非確定性的）
- 你可以盲目信任的魔法