ClaudeCode團隊CodeReview圖解

圖解 · 搭配中文導讀一起看

Claude Code 團隊怎麼做 Code Review

一句話：code 多到人看不完，所以讓機器一層一層先篩，人只看機器不擅長、又真的危險的地方。底線是出包不能變多。

內容依據 原文（2026-10-15）。圖都是重畫的示意圖，不是原文的圖。

機器做的事 人做的事 出問題

先看結果：他們做到了什麼

~90%Claude Code 自己的 code 是 Claude 寫的

×2 以上6 月到 9 月，合併的 PR 數量

−40% 以上同期需要 revert 的比例

產量翻倍，出包反而變少。下面一張一張看他們怎麼做到的。

1. 以前和現在差在哪

重點不是「有沒有人看過」，而是「這個改動可能出什麼事，該由哪一關擋」。人的時間只花在機器擋不住的地方。

2. 一個改動從寫到上線的路線

整條路上只有一格是橘色（人）。其他都是機器自動跑，人的注意力只放在有風險的那一步。

3. 為什麼要疊這麼多層

每一層都會漏，這是預期中的。靠的是「很少有問題能穿過全部」，最後再由回退兜底。所以他們不追求單一關卡完美，而是追求出事能很快發現、很快撤。

4. AI review 裡面在做什麼

多個 agent 各自找，再由另一組投票過濾，是為了壓誤報。作者是 agent 時，誤報特別貴：人看到雞毛蒜皮會略過，agent 會真的去改，多改一次就多一輪 review。

5. 要幾個人簽：看改了什麼，不看誰改的

由分類器看「改了什麼」決定等級。另外幾條硬規定：AI 的 approve 不算人的；指揮 AI 改的人要負責；簽的是某一個 commit，之後再推新 commit 要重簽。

6. reviewer 怎麼越變越準：事故變考題

另外兩個量噪音的方法：看作者怎麼處理每則 comment（修了／說它錯／說是故意的／說不相關），以及拿已知乾淨的 PR 去跑，看會不會亂報。

7. 不能無限來回：review 要能收斂

他們的四個對策：

輪數上限超過 3 輪，reviewer 請作者退一步重想做法。

後面只看新 diff前幾輪之後，不再整份重審。

一次點出整類 bug讓作者把所有同類位置一起修掉。

不重複報已經報過的不再報一次。

原文的實際數字：做了收斂改善之後，大多數 PR 一兩輪就過，很少再出現來回拉鋸。

8. 機器做什麼、人做什麼

交給機器

• 逐行讀 diff、找 bug
• 安全掃描
• lint、型別、各平台測試
• 合併前用最新 main 重跑
• 低風險改動直接放行

留給人

• 這東西該不該做（方向、範圍）
• 高風險 code：計費、自動更新、CI
• 之後會被別人照抄的架構
• 看證據判斷：檢查會漏掉什麼？說不出來就要求真的 review
• 為結果負責：誰下指令讓 AI 改的，誰負責

他們把資深工程師從「每個 diff 都讀」改成「只做機器不擅長的決定」。為了例行小錯把資深的人拉進來，成本比自動 review 高太多。

9. 配套的團隊習慣

你合的，你修改動合進去後壞了，通常由作者修，因為作者最有脈絡。不是在究責。

改動要小、要能撤影響範圍越大，檢查越嚴。

想懂某塊 code，請 Claude 寫說明不靠讀別人的 diff 學 codebase，幾分鐘就有一份照現況寫的說明。

方向不對就早點講agent 寫 code 很快，關掉一個 PR 不可惜。不要等寫完才用擋 merge 的 comment 反對。

圖為依原文內容重畫的示意圖。數字（90%、翻倍、−40%、65%→78%、8.9%→1.5%、2.08→1.32、59%、50 多輪、3 萬個改動）來自 原文；圖 3 的長度是示意。

ClaudeCode團隊CodeReview導讀

逐段導讀 · Engineering

Claude Code 團隊怎麼做 Code Review

原文：How the Claude Code team does code review
作者 Addy Osmani、Morgan Westlee Lunt、Qing Wang · 2026-10-15 · 原文約 14 分鐘

這是照原文章節順序寫的中文導讀，每一節都有講，但用的是我的話，不是逐句翻譯。灰底框裡的英文是原文短引。想讀完整原文，請開上面的連結，用瀏覽器內建翻譯。

目錄

1. 開場
2. 重新想 review 的目的
3. 稀缺的是人的時間
4. 一個改動的旅程
5. 逐層拆解（7 層）
6. 怎麼讓 reviewer 變好
7. 人留在哪些環節
8. 團隊怎麼共享脈絡
9. 誰合進去誰負責
10. 需要轉向的時候
11. 怎麼套用到你的團隊
12. 接下來的方向

開場

(untitled opening) · 副標

副標先把問題丟出來：agent 寫 code 的量這麼大，review 要怎麼跟上？團隊的答案是，在覆蓋率和審查深度都夠了之後，改成追求「人花最少的 review 時間，而且回退和事故不能因此變多」。

"the minimum amount of human review time that doesn't raise reverts or incidents" 在不讓回退或事故變多的前提下，把人的 review 時間壓到最低。

背景數字：Claude Code 自己的 code 大約九成是 Claude 寫的。6 月到 9 月，合併的 PR 數量翻倍以上，需要 revert 的比例反而降了四成多。

作者強調 review 沒有被拿掉，是大部分的「讀 code」移給了機器。整套流程以人的時間為優化目標，並讓出問題時能輕鬆撤回。

重新想 review 的目的

Rethinking the purpose of code review

agent 讓改動量暴增。Anthropic 的 monorepo 從 5 月每天約 2,500 個改動，到 9 月變成每天 3 萬以上。Claude Code 雖然有自己的 repo，壓力也差不多，一行一行人工看已經不可能。

作者把 review 拆成兩個工作：

• 在出貨前找到並修好問題。
• 讓團隊對 codebase 有共同的理解。

這篇主要談第一個，第二個留到後面的「共享脈絡」再講。

關鍵的觀念轉換是：「有沒有人讀過這段 code」只是個粗略的替代指標。真正該問的是這次改動可能出什麼錯，以及該由哪一道檢查（自動或人工）來抓。

"'did a human read the code?' is an imprecise proxy" 「有沒有人看過 code」只是一個不精確的替代指標。

review 因此從流程最後的一道關卡，變成寫的過程中就一直在跑的檢查，作者比喻成「邊寫邊跑的拼字檢查」。多數改動在人看到之前，Claude 已經審過也修過，人的注意力就能留給更高層的問題。

稀缺的是人的時間與注意力

The scarce resource: human time and attention

人的注意力應該花在只有人能解決的問題上，而新穎的工作還多得很。

作者提醒，人的時間有兩塊：花在 review 的時間，和事後修爛 code 的時間。只砍前面那塊，成本會原封不動跑到後面那塊。

"Cutting the first doesn't help if the time just shows up in the second." 如果省下的時間只是跑到修 bug 那頭，砍 review 時間就沒有意義。

目標設定：大多數 PR 合併時最多只有一個人參與，那個人可以就是作者本人，而且回退和事故不能增加。

追蹤的指標：

• 每個 PR 需要幾個人 approve（看中位數和 p95）。
• 人留了幾則 comment。
• PR 卡在等人的時間。

回退率和事故率則當護欄。這兩個數字一往上走，就代表人的時間沒有真的省下來。

一個改動的旅程

The life of a change

一個改動從作者的電腦出發，要經過好幾層 review 才會到使用者手上。

原文圖 A流程圖，分成四段：PR 前、每個 PR、合併、合併後。大部分步驟是自動的。

圖說大意：路徑大多自動化，人的注意力只放在有風險的地方。

逐層拆解

Layer by layer

最底下是快速回退，上面疊六層檢查。

原文圖 B問題由上往下穿過：PR 前驗證 → 必過 CI → AI review → 安全 review → 人工簽核 → merge queue 加 feature flag，最底下墊著快速回退。

圖說大意：每一層都會抓到一些、漏掉一些。能穿過全部的很少，剩下的交給回退。

1. 別人看之前，先自己驗過

The work is verified before anyone else looks

現在大部分的 review 在 PR 還沒開之前就做了。Claude 會跑測試、build，或做截圖比對，並把輸出秀出來，不是只說一句「完成了」。接著另開一個乾淨 context 的 subagent 重看一次 diff。

工程師還會跑內部的 skill：抓 bug、精簡 diff、做端到端檢查。UI 改動會對照設計規範。文中引用 Boris Cherny 的看法：驗證「大概是最重要的事」。

reviewer 一再標出同一類問題時，就回到源頭去修，做法有三種：改 skill、加 lint 規則，或改指示檔。

• CLAUDE.md：寫專案是什麼、慣例、什麼不做。要短，細節指向其他文件。
• REVIEW.md：由 code owner 寫。好的版本會：
  • 說明在這個區域「出錯」長什麼樣子。例如文件出錯就是內容說謊，設定出錯就是導錯路。
  • 限制雞毛蒜皮建議的數量。
  • 列出不用看的路徑。
  • 要求附檔案和行號當證據，不能只憑名字猜。

2. 每個 PR 都跑 AI review

AI review on every pull request

每個 PR 都由 Claude 審：把 diff 放回整個 repo 的脈絡，再對照 PR 說明裡寫的意圖。如果是修 bug，它會追是不是修到根因。這個功能已在 Team／Enterprise 方案正式提供，本機也能用 /code-review。

內部 PR 收到「有實質內容的 review comment」的比例，從 research preview 前的 16% 升到 54%。大 PR 通常會有 finding，小 PR 常常乾淨通過。管理員可以為每個 repo 選 Quick、Standard 或 Deep 三種深度。

運作方式：

• 多個 agent 同時找 bug。
• 另一組 agent 對每筆 finding 投票，確認是真的才留下。
• 只關於風格的 finding 直接丟掉。

留下來的照嚴重度排序，標成 Important、Nit 或 Pre-existing。最後一種代表原本就存在的問題，不會看起來像作者的錯。

"Every finding has to be answered." 每一筆 finding 都必須回應：要嘛修掉，要嘛附理由關掉。

3. 可以擋 merge 的安全 review

Security review that can block

另外有一道獨立的自動安全 review。只要它的 finding 還開著，PR 就不能合併。之後的 commit 修掉問題，finding 會自動清掉。外部團隊可以用開源的 GitHub Action 或 /security-review 拿到同樣的能力。

4. 會擋 merge 的自動檢查

Automated checks that block

lint、型別檢查、各平台的測試、build。一個典型的 CLI PR 會跑幾十項檢查。PR 模板會問兩件事：這次怎麼測的？要怎麼回退？發起改動的人要簽名負責。

5. 人工簽核依風險分級

Human approval, scaled by risk

不同改動風險不同，review 的力道也不同：

風險	例子	需要幾個人 approve
低	文件、文案、內部功能、藏在 flag 後面的新增改動	自動檢查和安全檢查都綠了就不用人
中	一般產品改動；快取、自動更新、system prompt 這類敏感區	1 人
高	風險最高的 code，加上規定一定要兩人的路徑	2 人

分級規則：

• 級別由分類器依「改了什麼」決定，不看是誰改的。第二個分類器會判斷要不要額外拉一個人進來，有些路徑則永遠要人看。
• 只有受信任的作者能走輕量路徑。agent 的 approve 永遠不能算成人的 approve。
• 指揮 agent 做這個改動的人，算是必要的 reviewer 之一。
• approve 只對某一個 commit 有效，之後再推新的 commit 要重新簽。

6. Merge queue、feature flag、逐步釋出

Merge queue, flags and a gradual release

merge queue 會把改動套到最新的 main 上，重跑一次檢查，避免「各自沒問題、合起來壞掉」的情況。新功能先藏在 flag 後面，只開給 Anthropic 員工。發版也是先到 latest 頻道，再到 stable。

7. 快速發現、快速回退

Fast detection, fast rollback

flag 不用重新部署就能關掉。團隊有每週輪替的值班。事故檢討時問的是「這個問題本來該被哪一層擋下來」。

作者也承認不足：發現問題目前還靠作者、值班和儀表板。當回退或事故數字變差時，自動把簽核收緊的斷路器還沒做。

文中引用一位同事的話：放慢速度確實會降低錯誤率，但主要只是因為什麼都做得比較少。團隊的選擇是：

"We'd rather get faster at noticing and fixing problems." 我們寧可在發現和修正問題上變得更快。

怎麼讓 reviewer 越來越好

How we make the reviewer better

reviewer 的品質靠一個持續的回饋迴圈提升。過去造成事故或被 revert 的 PR，經專家確認後收進評測集，reviewer 每天對這份題庫跑一次。

原文圖 C迴圈：發生事故 → 專家確認成案例 → 加入題庫 → 修改 reviewer → 每日評測 → 留下或丟掉這次修改。

圖說大意：題庫隨每次事故長大，reviewer 的每一次修改都要對全部題目跑分。

噪音怎麼量：

• 看作者怎麼處理每則 comment：修了、說它錯、說是故意的、說不相關。
• 拿已知乾淨的 PR 去跑 reviewer，看會不會亂報。

優先順序是先抓到真 bug，其次才是減少來回輪數。

"It's easy to catch more bugs if you don't mind flagging a lot of non-bugs." 如果不在乎誤報一堆不是 bug 的東西，要抓到更多 bug 很容易。

作者是 agent 的時候，噪音特別貴。人看到雞毛蒜皮的建議會直接略過，agent 會真的去改，於是多一個 commit、多一輪 review。

收斂問題：曾有一個 CLI 的 PR 一晚來回了五十多輪。用 git blame 一查，被標出來的 code 約 59% 在第一輪就已經在了。換句話說，後面幾輪大多只是陸續挖出舊 bug。

團隊原本預設每個 PR 跑很多輪，現在把「幾輪才通過」和抓到率（recall）一起追蹤。對策有四個：

• 輪數上限：超過三輪，reviewer 會請作者退一步，重新想做法。
• 前幾輪之後只看新的 diff。
• 點出整「類」bug，讓作者一次修完所有同類位置。
• 已經報過的不再重複報。

"Review has to converge." review 一定要能收斂。

review agent 也會每晚對既有的 code 跑一次。

原文圖 D做收斂改善前後的對照圖。

指標	改善前	改善後
一輪 review 加修正就通過	65%	78%
要五輪以上	8.9%	1.5%
平均要幾次 review 才通過	2.08	1.32

人留在哪些環節

Where humans stay in the loop

為了例行的小錯把資深工程師拉進來，成本遠高於自動 review。所以人的角色轉向需要判斷的事：

• 這東西到底該不該做：方向、品味、範圍。
• 高風險的 code：計費、自動更新、CI 設定。
• 之後會被別人照抄的架構。
• 判讀證據：測試輸出、跑過的指令、截圖、finding。要說得出這些檢查會漏掉什麼，說不出來就該要求真的 review，不要快速放行。
• 為結果負責。

"A person is accountable for every change that ships, whoever typed it." 不管是誰打的字，每個出貨的改動都有一個人要負責。

原文圖 E自動檢查繞著整個流程跑一圈，人只在五個點做決定。

圖說大意：人從「每個 diff 都讀」，轉成負責機器不擅長的決策。

團隊怎麼共享脈絡

Sharing context across the team

這裡回到 review 的第二個工作：散播理解。如果 diff 都交給機器讀，人就需要別的方式認識 codebase。

團隊沒有正式流程。工程師想了解某一塊，就請 Claude 針對那一小段 code 寫說明。花幾分鐘就好，而且反映的是 code 現在的樣子。有些人會請 Claude 做小型的視覺化網頁，照自己習慣的方式學一個模組。

作者認為這比讀一堆瑣碎的 diff 學得更多。另外，公開的 Slack 頻道讓大家看得到彼此在做什麼。

原文附圖一張 codebase 格狀圖，其中一塊被標亮，問題是「Claude Code 怎麼取得受管理的設定？」，箭頭指向說明文件或視覺化網頁。

誰合進去，誰負責

"You land it, you own it"

團隊的慣例：你合進去的東西壞了，通常由你來修，因為你最有脈絡。作者特別說明這不是究責：

"It isn't blame." 這不是在怪誰。

能這樣運作，是因為有幾個前提：

• 改動維持小。
• 一切都能撤回。
• 影響範圍決定要多嚴格。
• 回歸問題能很快浮現。
• 不究責的文化。

責任也透過公開頻道分擔，任何人都能接手一條討論或給意見。

需要轉向的時候

When we change direction

agent 讓「開始做」變得很便宜，所以有些 PR 本來就不該合。這時隊友通常會問為什麼要這樣做，或建議更簡單的路。

關掉一個 PR 不會覺得可惜，因為 code 寫起來本來就快。不同的方向應該在討論串早期就提出，不要等 PR 都寫完了，才用擋 merge 的 comment 表達。

怎麼套用到你的團隊

How you can adopt this process

作者說大部分元件現在就拿得到，並分四段給出檢查清單：

PR 之前

• 在簡短的 CLAUDE.md 裡告訴 agent 有哪些檢查可以跑。
• 本機跑 /code-review 和 /security-review。
• 加一份 REVIEW.md。

每個 PR

• 必過的 CI，PR 模板要有「測試、風險、怎麼回退」三欄。
• 加 AI reviewer。
• 加安全 review，所有討論串解決才能合。
• review 力道配合風險，並限制輪數。

簽核

• 寫下依改動內容（不是依作者）分的風險等級。
• 輕量路徑只開給受信任的作者。
• 敏感路徑用 CODEOWNERS 和分支保護。
• 機器人的 approve 永遠不能取代必要的人工 approve。

合併與之後

• merge queue、feature flag、分階段釋出、一步回退。
• 把事故變成評測題。
• 量人的時間，並用回退和事故率當護欄。

接下來的方向

Where this is going

對外推出的 Code Review 仍把 approve 留給人。Anthropic 自己的 repo 則已允許 owner 讓部分低風險改動自動合併，這條線還在移動。

review 漏掉東西時，修法會寫進 CLAUDE.md、skill，或變成一項新的檢查。

"The goal hasn't changed: less human time per change, and no more reverts than before." 目標沒變：每個改動花更少人的時間，回退不比以前多。

文章最後反問讀者：你們自動化了哪些檢查？哪些還需要人？我們有哪裡說錯了？致謝 Emma Webb、Michael Segner、Amie Rotherham。

中文導讀依原文章節順序改寫，非官方翻譯。完整內容與原始圖表請見 原文。

AI 使用心得( 不用 AI 潤稿 人工編輯版本 )

 AI 使用心得( 不用 AI 潤稿 人工編輯版本 )

-- 這裡絕對不能用AI輸出 是我最原始的心得 --

*這篇文章絕對不能用AI整理 *很重要*

*內容很亂也沒關西 因為是核心 人類輸出語言 不要用AI

太依賴AI 很多最核心資訊會被洗掉 保留最原始心得!

AI 注意力有限 要用 LOOP 反覆找問題 比如 SKILL清理 CODE VIEW

[專注AI循環][專注AI CODE驗收]

[認知載入]=>看CODE

語言模型能不能穩定理解你給它的程式

- 如何降第語意負擔

只規劃到實作前需要的東西 協定 & 規格 規則...相關 細節實作給AI

AI 三個臭皮匠 勝過諸葛亮?

開遊戲 -> 協定byte dump到檔案 -> 反查LOG

AI 確認需求比較重要 知道自己要什麼

Skill Daily 優化者 半夜跑一次

認知載入 AI -> 人 , 人 -> AI 雙向都要

需要管理 注意力

已經測試過 可用 可驗證的 AI 流程 可以不用花專注力 直接歸納成skill 或 Daily每日執行

手打CODE 也有價值(認知加強

在什麼階段 讓AI接手 會比較好 不會整個不知道在幹嘛

AI幫助實做 不要幫助思考 思考人類優先

請AI 自己提需求

/goal 看最近 AI 需求是什麼 卡在哪 unitybridge 需要新增什麼功能

在可控範圍內 多 code review 幾次

提出需求後 AI 如何驗證循環

管理記憶

如何快速同步記憶

需要管控 認知壓力

使用AI的問題在於記憶 - AI知道的淺規則比我們少 - 要把規則訂下來 寫成文件命中率才會高

使用SKILL 定期維護記憶 記憶只記錄抽象 不直覺 看CODE看不出來的部分

有明確驗收方式 都要用 /goal 降低中間來來回回 消耗注意力

要分 上線的CODE 還是 "測試類&工具類&編輯類" 的東西 如果是 "測試類&工具類&編輯類"

屬於只要測試目標達成就好 不用詳細Codereivew 注重結果跟LOOP迭代 釋放人類認知資源

每天的注意力有限 要管理注意力

驗收 驗收 驗收

跟runtime有關的CODE 特別是狀態複雜 有先後順序的CODE ,

AI 寫錯機率比較高 需要AI 使用runtime工具 自我驗證+循環

要怎麼處理語意上的錯誤? AI在遇到 語意跟實際情況有落差 淺規則 會容易寫錯

AI 只能處理合理的邏輯 不合理繞來繞去的情況 容易出錯 需要人類介入

歷史對話紀錄很重要 可以優化AI 比如 請AI自己查自己需要什麼工具 & AI自己查卡在哪

API的設計哲學 可以列給AI 讓他有個基礎去思考

Fable Code reivew 太消耗Token

每日 請AI看需要什麼 然後請AI迭代工具

知道自己在幹嘛 提示就會下的精準

AI 寢向達成任務 可能會偷懶

把 skill 當作程式碼在寫 一樣要做DRY 去除類似流程 保留唯一

CODE 越來越不值錢 API接口設計理念比較重要 CODE 可以被AI 簡單複製

Skill 要寫 Trigger_test 驗證SKILL品質用

使用AI 用 Top Down 方法更好 先關注大方向 細節AI處理

人會通靈 是因為有關鍵奇怪資訊 這個關鍵奇怪資訊 要md化 這樣AI才能跟人有一樣思考

能夠 文件化 指令化 都做 都有好處

使用AI到最後 會變成如何信任開發 如何驗證成果 因為看不完所有CODE

基於信任 連要上線的CODE 只要夠簡單 我都能無腦PUSH 每日晚上在請AI Code Review兜底

沒時間寫測試的時代已經過去了 用AI超快

已經從工程師 變成 AI觀察員了

人容易搞混的東西 命名 一致性 AI也會搞錯 所以要clean code

為了讓人跟AI 溝通摩擦變小 CODE 都要有語意正確 不要亂寫

AI本質上就是在猜 所以寫CODE的風格要直覺 不要搞一些奇怪花招 很容易猜錯 又要改

AI會被誤導很正常 他會傾向最直接 直覺的方式理解問題 需要特例說明

AI注意力有限 如果他沒有派出subagent 情況下 基本上一定會漏東西

對AI產出的內容 要對認知投入做把關 比如 SEPC 要花大量時間投入 因為他是功能是否正常 & 如何驗收的基礎

模型有隨機性 同個BUG 不同次review 可能不會發現

推理 + 驗證 可以有效降低幻覺

重要的是 驗證+循環 跑起來之後 才能降低使用AI的難度

StikcyNotes With Google Drive At Windows10

載入中…

你真的知道自己投入股市多少錢嗎？用 Python 還原「真實資金」的方法大公開

💰 用 Python 還原「到底花了多少錢買股票？」

有時候你會問自己：

「我帳上股票價值是這樣沒錯…但我到底實際投入了多少錢？」

這問題乍聽簡單，其實非常常見也非常棘手。

---

🧨 問題：我錢早就滾來滾去了啊！

很多人投資時：

• 沒記自己加碼多少錢（沒有入金記錄）
• 只剩券商提供的「買賣交易紀錄」

但這樣會出現什麼狀況？

• 你賣出股票，帳戶有現金
• 過幾天再買別的股票，用的是原本賣出的錢
• 重複買賣幾次後，你總買入金額可能膨脹了兩倍！

✅ 所以不能單看「買進總額」或「-帳面淨流出」來當作你的投入資金

---

✅ 解法：模擬帳戶現金流，還原真實加碼金額

💡 核心邏輯：

1. 把交易紀錄照時間排序
2. 模擬一個帳戶現金餘額（初始 0）
3. 遇到賣出（+金額）：錢進帳戶
4. 遇到買進（-金額）：
   • 有現金就扣
   • 不夠的話，補上缺口 → 這才是真的你「掏口袋的錢」

---

🧮 舉個例子

1月 買 -10,000 現金 = 0 → 實際投入 10,000
2月 賣 +12,000 現金 = 12,000
3月 買 -18,000 現金不足，補 6,000 → 再投入 6,000

✅ 結論：實際總投入是 16,000

不是你以為的「買了 28,000 就是投入 28,000」

---

🛠️ Python 程式碼怎麼寫？

account_cash = 0
net_invested = 0

for row in sorted_transactions:
    amt = row["Amount"]
    if amt > 0:  # 賣出
        account_cash += amt
    else:        # 買入
        needed = -amt
        if account_cash >= needed:
            account_cash -= needed
        else:
            net_invested += (needed - account_cash)
            account_cash = 0

---

📈 實際用途

• 想算報酬率，但沒記入金
• 有做再平衡、滾動買賣的交易人
• 想看 Sharpe Ratio / IRR 時，不想被「假投入」影響

---

🔚 小結

這個「還原現金投入」的方法非常簡單但非常實用。
比起只看總買進金額，它能更貼近你真正「從錢包拿出來」的資金。

把它寫進你的投資分析程式，或記帳工具裡面，你會對自己的績效有更真實的掌握 👌

---

（想要這段程式變成一個 pandas 函式或封裝工具？可以留言或私訊我 🙌）

PS Blending Modes (常用混合公式整理)

 以下內容整理自您提供的圖片，主要是各種「混合模式 (Blending Modes)」對應的運算公式。為方便閱讀，我將其歸納成表格形式，並依常見的 Photoshop/繪圖軟體混合模式命名進行分類。若有些名稱與您日常使用的軟體不同，請自行對照調整。

---

1. 基本比較類 (Darken / Lighten)

模式名	公式	說明
變暗 (Darken)	$C = \min(A, B)$	在每個像素比較兩圖層亮度，取較暗者為結果
變亮 (Lighten)	$C = \max(A, B)$	在每個像素比較兩圖層亮度，取較亮者為結果

---

2. 乘法 / 反向運算類 (Multiply / Screen / 相關衍生)

模式名	公式	說明
正片疊底(Multiply)	$C = \dfrac{A \times B}{255}$	兩圖層相乘後再除以 255，結果通常比原圖更暗
濾色(Screen)	$C = 255 - \dfrac{(255 - A) \times (255 - B)}{255}$	先將兩圖層反相，再進行乘法，最後再反相，結果通常比原圖更亮
線性加深(Linear Burn)	$C = A + B - 255$（若小於 0 則視作 0）	簡單的線性運算，使結果變暗
線性減淡(Linear Dodge)	$C = A + B$（若大於 255 則視作 255）	簡單的線性運算，使結果變亮
顏色加深(Color Burn)	$C = 255 - \dfrac{(255 - A) \times 255}{B}$（常見定義之一）	透過對亮部的「壓暗」達到加深效果，實作可能略有差異
顏色減淡(Color Dodge)	$C = \dfrac{A \times 255}{255 - B}$（常見定義之一）	透過對暗部的「提亮」達到減淡效果，實作可能略有差異

註：有關「顏色加深 / 顏色減淡」的公式，在不同軟體或文檔中可能會有些微差異，以上為常見版本參考。

---

3. 疊加 / 光系混合 (Overlay / Hard Light / Soft Light / Vivid Light 等)

這一類混合模式通常會先判斷 B(上層) 的亮度是否大於或小於中間值 (128)，再採用不同公式，使暗部和亮部各自以不同方式混合。

3.1 疊加(Overlay)

通常定義如下（此處以 128 為分界）：

• 若 $B \le 128$： $$C = \dfrac{A \times B}{128}$$
• 若 $B > 128$： $$C = 255 - \dfrac{(255 - A)(255 - B)}{128}$$

3.2 強光(Hard Light)

「強光」與「疊加」雷同，但視角不同（以 B 為基準）。常見定義為：

• 若 $B \le 128$： $$C = \dfrac{A \times B}{128}$$
• 若 $B > 128$： $$C = 255 - \dfrac{(255 - A) (255 - B)}{128}$$

註：某些資源中，強光(Hard Light) 也會寫成以上 Overlay 互換的形式，請依軟體實際實作為主。

3.3 柔光(Soft Light)

柔光的公式實作比較多樣，常見的 Photoshop 版本定義(以下僅作參考)：

• 若 $B \le 128$： $$C = \dfrac{A \times (B + 128)}{255}$$
• 若 $B > 128$： $$C = 255 - \dfrac{(255 - A)(255 - B)}{255}$$

不同軟體對「柔光」的實作公式也可能不同，主要是為了產生更柔和的光影過渡。

3.4 亮光(Vivid Light)、線性光(Linear Light)、點光(Pin Light) 等

• 亮光(Vivid Light)
  結合了「顏色加深 / 顏色減淡」的概念：

  $$\begin{cases} B \le 128: & C = 255 - \dfrac{(255 - A)\times 128}{B} \\ B > 128: & C = \dfrac{A \times 128}{255 - (B - 128)} \end{cases}$$

  （此為參考公式，實際實作可能有所調整。）

• 線性光(Linear Light)
  常見定義：

  $$C = A + 2B - 255$$

  （暗部時像線性加深，亮部時像線性減淡。）

• 點光(Pin Light)
  簡化來說，會將亮部與暗部門檻化，以保留部分像素原值、部分取另一圖層值。常見寫法：

  $$\begin{cases} B \le 128: & C = \min(A, 2B) \\ B > 128 : & C = \max(A, 2B - 255) \end{cases}$$

---

4. 其他特效類

模式名	公式	說明
實色疊加(Hard Mix)	$C = \begin{cases}255 & (A + B \ge 255)\\0 & (A + B < 255)\end{cases}$	會使結果只有純色 (非 0 即 255)，製造極端色塊效果
差值(Difference)	(C =	A - B
排除(Exclusion)	$C = A + B - \dfrac{A \times B}{128}$	與差值類似，但結果較柔和
相加(Add)	$C = A + B$（若超過 255 則視為疊色 / 補陰）	將像素值相加後再裁切，若值過大即「溢色」。有時用於製作發光效果
減去(Subtract)	$C = A - B$（若小於 0 則視為 0）	將像素值相減後再裁切，若小於 0 即「補陰」。

---

5. 小結

1. 比較類 (變暗 / 變亮) 只做簡單的比較取最小或最大值。
2. 乘法類 (正片疊底 / 濾色 / 顏色加深 / 顏色減淡 / 線性加深 / 線性減淡) 大多基於「乘法 + 反相」等簡單算式，控制明暗。
3. 光系混合 (疊加 / 強光 / 柔光 / 亮光 / 點光 / 線性光 / Vivid Light / Linear Light / Pin Light...) 則常用分段函式，依暗部或亮部使用不同算法。
4. 特效類 (差值 / 排除 / 實色疊加 / 相加 / 減去 ...) 產生反相、門檻化或其他獨特效果。

以上即為根據圖片上列出的混合模式與對應公式所做的整理與歸納。若有個別公式與您實務使用或軟體顯示不符，建議再對照實際的程式碼或官方文件，以取得最準確的數值與算法。希望對您有所幫助。

C# Struct 的自動哈希與相等比較：簡化開發的優勢

### 結論簡短版 `struct` 的一個重要優勢是，在大多數情況下，不需要手動覆寫 `GetHashCode()` 和 `Equals()`。C# 會自動基於 `struct` 的成員生成這些方法，讓開發更簡單並減少錯誤風險。這在需要高效查找和相等比較的情況下非常實用。 ### 範例說明 假設我們有一個 `Point` 結構：

struct Point
{
    public int X { get; }
    public int Y { get; }

    public Point(int x, int y)
    {
        X = x;
        Y = y;
    }
}

在這裡，我們不需要覆寫 `GetHashCode()` 和 `Equals()`，就可以直接將 `Point` 用作 `Dictionary` 的鍵：

var pointsDictionary = new Dictionary();
pointsDictionary[new Point(1, 2)] = "First Point";

// C# 自動處理哈希和相等比較
Console.WriteLine(pointsDictionary[new Point(1, 2)]); // 輸出：First Point

這展示了 `struct` 自動處理哈希和相等比較的方便性，讓我們不必手動覆寫這些方法，仍然可以高效使用字典查找等功能。