用 OpenClaw 生成了團隊健檢報告，把摸魚的同事揪出來了😅

===================================

> 你有沒有好奇過，你的隊友到底是幾點寫的程式碼？是凌晨三點靈感爆發的夜貓子，還是朝九晚五準時下班的養生達人？

一切的起源：一個深夜的疑問

故事要從一個加班到凌晨兩點的夜晚說起。

那天我照例在提交程式碼，突然發現 Git log 裡有一條提交時間是 03:47，來自我們組的後端同學。我震驚之餘又有點心疼，然後下意識地翻了翻其他人的紀錄，發現了更多有趣的事，有人專挑週末提交，有人的 commit message 永遠只有一個字 fix，還有人一次提交能改 500 個檔案……

我心想，如果把這些資料系統地分析一下，會不會看到一幅很有意思的開發者側寫？

這就是 who-is-actor 誕生的初心。

它是什麼？

簡單來說，這是一個 OpenClaw 分析工具的 Skill 外掛。它做的事情很純粹：掃描你指定的 Git 倉庫，或者一個目錄下的所有倉庫，然後像一個沉默的觀察者，把每個開發者的行為資料抽絲剝繭，最終生成一份五維度的體檢報告。

五個維度分別是：

提交習慣 -- 你一天提交幾次？每次改多少行？commit 訊息寫了幾個字？
工作習慣 -- 你是早起鳥還是夜貓子？週末有沒有在偷偷加班？最長連續寫了幾天程式碼？
研發效率 -- 你寫的程式碼有多少後來又被刪了？是不是經常在同一個檔案上反覆改？
程式碼風格 -- 你主要寫什麼語言？commit 訊息有沒有遵循規範？
程式碼品質 -- 修 bug 的提交佔了多大比例？有沒有動不動就一個大提交丟上來？

扒出來的「真實側寫」

我用它分析了團隊倉庫後，看到的一些真實畫面：

深夜戰士 -- "A 同學"

這位老兄的提交時間幾乎全部集中在深夜，而且清一色在週末。如果你半夜兩點 @ 他，大機率能秒回。他不是不睡覺，他只是把白天的時間讓給了生活，然後在萬籟俱寂的時候打開編輯器，一個人安靜地寫程式碼。

不過看資料也會發現一些值得關注的訊號：他的程式碼流失率高達 66%，意味著寫下的程式碼有三分之二後來又被刪除了。這可能是探索性編碼的正常現象 —— 畢竟深夜寫程式碼，有時候是先寫再想，寫完再推倒重來。他的返工率也有 46.2%，7 天內重複修改同一個檔案的頻率不低。

但換個角度想，這也許恰恰說明他是一個追求完美的人，程式碼寫完不滿意，再改，改完還是不滿意，接著改。

批量輸出者 -- "B 同學"

看到這個資料的時候我差點以為分析工具出了 bug，單次提交平均兩萬行？再仔細一看，原來是做專案初始化和大規模遷移的。他擁有倉庫中 100% 的檔案所有權，是當之無愧的專案奠基人。

有趣的是，他的程式碼流失率為 0%，寫下的每一行程式碼都還活著。搞基建的人就是這樣，一磚一瓦都是實打實的。不過他的 commit 訊息也就 30 來個字，簡潔高效，有那味了。

週末勇士 -- "C 同學"

三分之二的提交都在週末，還有三分之一在深夜。但看另一組資料就知道，這是一個效率極高的人：程式碼流失率只有 3.8%，幾乎不做無用功。每一次提交都目標明確，落筆精準。如果說深夜戰士是先寫再想，那這位就是想清楚再寫。

偶爾現身的貢獻者 -- "D 同學"

有些人在專案中只留下了一個提交，但那一個提交可能就是修了一個關鍵 bug，或者補上了一段缺失的文件。在開源世界裡不存在貢獻太少這一說，每一個 commit 背後，都是一個真實的人在某個時刻打開了編輯器，讀懂了程式碼，然後伸出了手。

技術解剖：它是怎麼做到的？

架構一覽

整個專案的架構非常清晰，像一條流水線：

<div><div><div></div><span></span></div><div><div> <span>體驗AI程式碼助手</span></div><div> <span>程式碼解讀</span></div><div>複製程式碼</div></div></div>```
<span>路徑輸入 → Scanner 偵測倉庫 → 5 個 Analyzer 遍歷 Git 歷史 → Reporter 產生報告</span>


- **Scanner** 負責掃描，找到指定路徑下的所有 Git 倉庫
- **5 個 Analyzer** 各司其職，遍歷提交歷史，按作者分組聚合資料
- **3 個 Reporter** 提供 Markdown、JSON、HTML 三種輸出格式

### 核心演算法亮點

幾個我覺得設計得比較巧妙的地方：

**1. 返工率 Rework Ratio 的計算**

如果你在 7 天內對同一個檔案改了兩次以上，就算一次返工。這個定義很現實 —— 真正的返工通常發生在短時間內反覆修改同一個地方，可能是需求變了，可能是 code review 的反饋，也可能是自己發現了之前的問題。

**2. 檔案所有權 Ownership 的判定**

如果你對某個檔案的修改次數超過了所有人修改該檔案總次數的 50%，你就擁有這個檔案。這個概念借鑑了 Google 的 Code Ownership 實踐 —— 每個檔案都應該有一個主人，出了問題知道找誰。

**3. Bus Factor 的衡量**

如果某個人被公車撞了，不是真的，專案還能繼續嗎？工具統計每個檔案有多少獨立貢獻者，取平均值。如果這個數字低於 2，說明知識過於集中，團隊需要注意知識共享。

**4. 深夜編碼的精確定義**

22:00 到次日 04:59 都算深夜編碼。這不是為了抓考勤，而是為了發現團隊健康問題。如果一個人的深夜編碼比例長期超過 15%，也許不是他效率高，而是白天的會議太多了。

### 程式碼風格檢測

工具還會檢測 commit 訊息是否遵循 Conventional Commits 規範，以及是否關聯了 Issue 編號。這兩個資料看似簡單，其實反映了一個團隊的工程化成熟度。

如果你的團隊 Conventional Commit 遵循率低於 50%，可能需要考慮引入 commitlint 之類的工具了。

用法很簡單
-----

作為 Skill 外掛，你可以直接在對話中觸發：

<div><div><div></div><span>arduino</span></div><div><div> <span>體驗AI程式碼助手</span></div><div> <span>程式碼解讀</span></div><div>複製程式碼</div></div></div>```
<span><span>"分析一下這個倉庫每個人的研發效率"</span></span>
<span><span>"幫我看看團隊成員的工作習慣"</span></span>
<span><span>"比較一下 Alice 和 Bob 的程式碼品質"</span></span>
<span><span>"誰在摸魚？"</span></span>

也可以直接用指令列：

<div><div><div></div><span>bash</span></div><div><div> <span>體驗AI程式碼助手</span></div><div> <span>程式碼解讀</span></div><div>複製程式碼</div></div></div>```
<span><span># 分析單一倉庫</span></span>
<span>python src/main.py -r /path/to/repo</span>
<span></span>
<span><span># 掃描整個資料夾</span></span>
<span>python src/main.py -r /path/to/projects --scan-all</span>
<span></span>
<span><span># 指定時間範圍，產生 HTML 報告</span></span>
<span>python src/main.py -r /path/to/repo -s 2025-01-01 -u 2025-12-31 -f html -o report.html</span>



生成的報告長這樣：

![image.png](https://i.imgur.com/ycQ51Jw.jpeg)

每個人的資料都是一面鏡子。

寫在最後：資料不是枷鎖
-----------

還有我必須坦誠地說：**這個工具不是用來做績效考核的。**

資料可以幫我們發現問題，但不能定義一個人的價值。那個凌晨三點提交程式碼的同事，也許比任何人都更熱愛這個專案；那個 commit 訊息只寫 fix 的人，也許正在爭分奪秒地修復一個線上事故。那個只貢獻了一個提交的人，也許是花了整整一週才理解了程式碼才敢動手。

寫這個工具的初心，是想透過冰冷的 Git 紀錄，看到背後一個個**真實的、有溫度的人**。看到他們的工作節奏，理解他們的習慣，在必要時幫助他們，比如發現某人連續深夜加班，也許該找他聊聊是不是遇到了什麼困難。

程式碼會說話，但只有用心聽，才能聽到正確的答案。

---

專案地址：[github.com/Wscats/who-…](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2FWscats%2Fwho-is-actor)

---

原文出處：https://juejin.cn/post/7616598871089938483