日期： 2025年10月8日 星期三
雲端天氣： 雲朵排成一行
心情： 悠哉
親愛的日記：
今天是年度績效考核的前一週，蘇蘇在辦公室抓著頭髮一臉崩潰：「老陳，你還記得我上半年做了什麼嗎？我只記得修了很多 bug，但主管要我寫『具體貢獻』...」
老陳：「你沒有平常記錄嗎？我每週會彙整一次成果，考核前只要整理一下就好。」
蘇蘇：「什麼？還要另外整理？我光寫程式就忙不完了...」
老陳：「那你現在不就要花更多時間回想嗎？而且很多細節你已經忘了。」
蘇蘇看著自己的 Git commit 記錄，滿滿的 fix、perf、refactor 感到焦頭爛額。
老陳：「蘇蘇，你該不會是想當料理鼠王吧？」 蘇蘇一臉困惑：「蛤？」
老陳：「就像電影《料理鼠王》裡的小米，真正的大廚是牠，但端菜出去時大家只看到林葛尼。你寫了一堆程式碼，但主管看績效考核時，只看到一片空白。」
蘇蘇：「......所以我是那隻躲在廚房裡的老鼠？」老陳哈哈大笑兩聲走掉了，空氣裡只剩下寂靜。
AI 醬豎著貓毛哆嗦了一下：「好冷喔...不是啦！蘇蘇！重點是要讓別人看見妳的貢獻呀～讓 AI 醬幫你！」
吹噓文件（Brag Document） 是一份記錄你工作成果的文件，用來追蹤你完成的專案、解決的問題、協作的貢獻，以及技術成長。
這個概念來自工程師 Julia Evans 在 2019 年發表的文章《Get your work recognized: write a brag document》。她指出：
"There's this idea that, if you do great work at your job, people will (or should!) automatically recognize that work and reward you for it with promotions / increased pay. In practice, it's often more complicated than that."
（有種想法是：如果你工作表現出色，別人就會（或應該）自動認可你的工作，並給予升遷或加薪作為回報。但實際上，事情往往比這複雜得多。）
為什麼叫「Brag Document」？
這個名稱聽起來有點彆扭，但 Julia Evans 刻意用這個詞，是為了鼓勵工程師：
在工程師文化中，大部分工程師往往習慣謙虛，埋頭努力注重於解決問題，但這常導致自己的努力被忽略，久而久之內心容易不平衡。
吹噓文件就是要你誠實地寫下：「我做了這些貢獻」。
也有人可能會說：「這些主管平常 code review 其實應該都很了解你做了什麼」，但現實也不會往往都如你所想是 happy path，主管可能根本沒有空 code review，可能過陣子就忘了，或是根本沒有理解實際上解決了什麼問題，其實去洞悉這些不全然是主管的責任，也是你自己的責任。
不管在哪一間公司，工程師都應該在日常保持把貢獻成果化的習慣，這不只在考核能發揮用處，甚至未來找工作時你整理履歷不必再重新回頭追溯。
沒有使用吹噓文件時，容易無法展示貢獻度的原因：
1.主線任務：技術表述 vs 業務價值表述
直接把 commit message 貼出來，難直接看出業務價值：
寫成直接明確的業務價值：
2.支線任務：隱性貢獻
這些是最容易被忽略的：
工程師專注解決問題，忽略了「成果記錄」
由於成果檔案會儲存在專案外的 ~/achievements/ 目錄，需要先設定 Claude Code 的存取權限。
在專案根目錄建立或編輯： .claude/settings.json
{
"permissions": {
"additionalDirectories": [
"~/achievements"
]
}
}
這樣 Claude Code 才能讀寫 ~/achievements/ 目錄下的檔案。
回顧 Day 23，我們又可以再次運用學過的 Slash Command 指令技巧。現在我們來建立一個自動產生成果摘要的指令。
步驟一：建立每日記錄指令
建立檔案：.claude/commands/brag-daily.md
---
description: Generate daily achievement summary
argument-hint: date (optional, format: YYYY-MM-DD)
---
請執行以下步驟產生每日成果摘要：
步驟 0：確認日期
如果使用者提供了 $ARGUMENTS（格式：YYYY-MM-DD）：
- 使用該日期作為目標日期
- 用 git log --since="YYYY-MM-DD 00:00" --until="YYYY-MM-DD 23:59" 查詢該日的 commit
如果沒有提供日期：
- 預設為今天
- 用 git log --since="today" 查詢今日的 commit
步驟 1：執行 git log 查看指定日期的 commit 記錄
步驟 2：分析 commit 內容，分類為：
- 核心專案貢獻
- Bug 修復
- Code Review 與協作
- 文件與知識分享
- 重構與優化
步驟 2.5：主動詢問隱藏貢獻
在分析完 commit 後，一次性詢問我以下問題，提醒我補充 git 記錄之外的貢獻：
- 今天有協助同事解決問題嗎？（pair programming、troubleshooting）
- 有進行 code review 或提供技術建議嗎？
- 有在會議中分享技術見解或做決策嗎？
- 有撰寫文件、更新 wiki 或分享知識嗎？
- 有進行技術調研或 POC 嗎？
- 有參與技術討論或指導新人嗎？
我會一次補充完給你。
步驟 3：將技術語言轉換成業務價值語言，並在對話中展示給我看
重要原則：
- 不要臆測或編造數字（如：降低 X%、提升 Y 倍）
- 只使用可從 commit、code 或我提供的資訊中確認的數據
- 如果無法量化，用描述性語言即可（如：「改善效能」而非「提升 50% 效能」）
- 需要數字時，主動詢問我而非自行臆測
請用以下格式輸出到對話視窗：
## 今日成果 (YYYY-MM-DD)
### 專案與開發
- [專案名稱] Bug 修復：修復內容 - 影響範圍 - 業務價值
- [專案名稱] 功能開發：新增功能 - 解決什麼問題 - 業務價值
- [專案名稱] 重構：重構內容 - 改善效果
### 協作貢獻
- Code Review：審查數量與重要發現
- 技術支援：協助內容
- 知識傳遞：教學或指導內容
### 技術優化
- 優化內容 - 量化成果
### 知識分享
- 文件或分享主題
注意事項：
1. 先在對話中顯示摘要，讓我確認內容是否正確
2. 如果我說不對，請根據我的回饋修正
3. 確認無誤後，我會說「可以儲存」
4. 收到確認後，將摘要儲存到：~/achievements/daily/YYYY-MM-DD.md
- ~ 代表使用者的家目錄（例如：/Users/username/achievements/）
- 使用步驟 0 確認的目標日期（如果用戶指定了日期，就用該日期；否則用今天）
- 格式範例：2025-10-08.md
- 如果目錄不存在，先建立目錄：mkdir -p ~/achievements/daily
5. 如果該檔案已存在，詢問是否覆蓋
不要直接儲存檔案，一定要等我確認後才執行儲存。
步驟二：建立週期彙整指令
建立檔案：.claude/commands/brag-summary.md
---
description: Generate weekly/period summary from daily achievements
argument-hint: YYYY-MM-DD YYYY-MM-DD (optional)
---
請執行以下步驟產生週期成果摘要：
步驟 1：解析彙整區間
如果 $ARGUMENTS 是空白：
- 彙整本週（從本週一到今天）
- 自動計算本週的起始和結束日期
如果 $ARGUMENTS 包含兩個日期（格式：YYYY-MM-DD YYYY-MM-DD）：
- 第一個日期是起始日
- 第二個日期是結束日
- 範例：2025-10-01 2025-10-08
步驟 2：讀取期間內的每日成果
從 ~/achievements/daily/ 目錄讀取指定區間內的所有 YYYY-MM-DD.md 檔案
如果找不到任何檔案，提示使用者：
「在 ~/achievements/daily/ 目錄中找不到該區間的每日記錄。請先用 /brag-daily 建立每日記錄。」
步驟 3：分析與彙整
將所有每日成果合併分析，萃取重點：
- 辨識重複出現的主題（代表持續投入的重點項目）
- 合併相關的小任務成大的成就
- 量化累積成果（如：解決 X 個 bug、審查 Y 個 PR）
- 突出關鍵里程碑或重大突破
步驟 4：轉換為高層次摘要
將技術細節提升為業務影響層次：
- 專注於「達成什麼目標」而非「做了什麼事」
- 強調影響範圍和商業價值
- 使用量化數據支持成果
重要原則：
- 不要臆測或編造效能數字（如：降低 X%、提升 Y 倍）
- 只使用每日成果中已記錄的確實數據
- 可統計的數字：commit 數、PR 數、協助人次、檔案數等客觀可計數項目
- 效能或業務影響若無數據，用描述性語言即可
- 可能需要具體數字時，在摘要中註明「可以補充內容」
請用以下格式輸出到對話視窗：
## 週期成果摘要 (YYYY-MM-DD ~ YYYY-MM-DD)
### 重點成就
- [最重要的 2-3 項關鍵成果，附業務價值]
### 專案貢獻
- 專案名稱：階段性成果 - 業務影響 - 量化指標
### 問題解決
- 累計修復：X 個問題
- 重點修復：[影響最大的問題描述]
### 團隊協作
- Code Review：X 次審查，[重要發現或建議]
- 技術支援：協助 X 位同事，[關鍵議題]
- 知識傳遞：[教學或分享主題]
### 技術優化
- [優化項目] - [量化成果]
### 知識累積
- [文件、研究或分享主題]
### 統計數據
- Commits: X 次
- Files changed: X 個
- Code reviews: X 次
- 協助同事: X 次
注意事項：
1. 先在對話中顯示摘要，讓我確認內容是否正確
2. 如果我說「重點不對」或「業務價值描述不對」，請根據我的回饋修正
3. 確認無誤後，我會說「可以儲存」
4. 收到確認後，將摘要儲存到：
- 週摘要：~/achievements/weekly/YYYY-WW.md
- 自訂區間：~/achievements/period/YYYY-MM-DD_to_YYYY-MM-DD.md
- ~ 代表使用者的家目錄（例如：/Users/username/achievements/）
- 如果目錄不存在，先建立對應目錄：mkdir -p ~/achievements/weekly 或 mkdir -p ~/achievements/period
5. 如果該檔案已存在，詢問是否覆蓋
不要直接儲存檔案，一定要等我確認後才執行儲存。
日常工作流程：每日記錄
情境一：當天記錄
每天下班前執行：
/brag-daily
情境二：補記前幾天（忘記當天記錄）
隔天早上回顧昨天，或補記前幾天：
# 補記昨天
/brag-daily 2025-10-07
# 補記指定日期
/brag-daily 2025-10-05
執行流程範例：
步驟 1：AI 分析今日的 commit
正在分析 2025-10-08 的 commit 記錄...
找到 3 個 commit：
- fix: resolve race condition in payment module
- test: add unit tests for payment validation
- refactor: extract payment processor to separate class
步驟 2：AI 主動詢問隱藏貢獻
我已經分析了你今天的 commit 記錄。
現在想了解一下 git 記錄之外的貢獻，請一次回答以下問題：
- 今天有協助同事解決問題嗎？
- 有進行 code review 或提供技術建議嗎？
- 有在會議中分享技術見解或做決策嗎？
- 有撰寫文件、更新 wiki 或分享知識嗎？
- 有進行技術調研或 POC 嗎？
- 有參與技術討論或指導新人嗎？
你回答：
有，我今天幫小王解決了 Redis 連線池的問題，
還 review 了兩個 PR（#456 和 #457），
下午的技術會議討論了新的快取策略，我建議用 Redis Cluster
步驟 3：AI 產生今日摘要（先顯示在對話中）
## 今日成果 (2025-10-08)
### 專案與開發
- 支付系統：修復並發處理問題，避免用戶重複扣款
- 新增單元測試確保修復有效
- 重構支付處理器，提升程式碼可維護性
- 相關 commit：3 個
### 協作貢獻
- Code Review：審查 2 個 PR
- PR #456：[可以補充內容]
- PR #457：[可以補充內容]
- 技術支援：協助同事解決 Redis 連線池問題
- 技術決策：技術會議中建議採用 Redis Cluster 作為新快取策略
請確認內容是否正確？需要修改與補充的請告訴我，確認無誤請說「可以儲存」。
步驟 4：你檢查並回饋
PR #456 是發現了 API 的錯誤處理不完整，
PR #457 是建議改用更有效率的資料結構
AI 理解並更新後再次確認，你說「可以儲存」：
已儲存到：~/achievements/daily/2025-10-08.md
週期彙整流程：產生週報或自訂區間報告
情境一：彙整本週
週五或需要時執行：
# 彙整本週（從週一到今天）
/brag-summary
情境二：彙整自訂區間
產生月報、季報或指定區間：
# 彙整 10/1 到 10/8
/brag-summary 2025-10-01 2025-10-08
# 彙整整個十月
/brag-summary 2025-10-01 2025-10-31
# 彙整 Q3
/brag-summary 2025-07-01 2025-09-30
執行流程範例：
步驟 1：AI 讀取每日記錄並分析
正在彙整 2025-10-07 ~ 2025-10-11 的成果...
從 ~/achievements/daily/ 讀取每日記錄：
找到 5 天的記錄：
- 2025-10-07.md
- 2025-10-08.md
- 2025-10-09.md
- 2025-10-10.md
- 2025-10-11.md
開始分析與彙整...
步驟 3：AI 產生週期摘要
## 週期成果摘要 (2025-10-07 ~ 2025-10-11)
### 重點成就
- 完成支付系統並發問題修復，確保雙 11 促銷期間系統穩定
- 主導新快取架構設計，採用 Redis Cluster 提升可擴展性
- 協助團隊解決 5 個技術難題，提升團隊整體效率
### 專案貢獻
- 支付系統：修復並發處理漏洞，新增測試覆蓋，重構程式碼架構
- 業務影響：保護用戶資金安全，避免客訴
- 技術指標：新增 15 個單元測試，程式碼重複率降低
### 問題解決
- 累計修復：3 個 bug
- 重點修復：支付並發問題（高優先級，影響營收）
### 團隊協作
- Code Review：10 次審查，發現 2 個安全問題，3 個效能優化建議
- 技術支援：協助 5 位同事，主要議題包括 Redis、API 設計、測試策略
- 知識傳遞：分享 Redis Cluster 最佳實踐
### 技術優化
- 支付模組重構：提升可維護性和測試覆蓋率
### 知識累積
- Redis Cluster 架構研究與方案設計
- 支付系統並發處理最佳實踐
### 統計數據
- Commits: 18 次
- Files changed: 25 個
- Code reviews: 10 次
- 協助同事: 5 次
請確認內容是否正確？需要修改請告訴我，確認無誤請說「可以儲存」。
步驟 4：確認後儲存
你說「可以儲存」：
已儲存到：~/achievements/weekly/2025-42.md
建議將成果記錄在專案外的統一位置，預設範例使用 ~/achievements/：
~/achievements/
├── daily/ # 每日記錄
│ ├── 2025-10-01.md
│ ├── 2025-10-02.md
│ └── ...
├── weekly/ # 週摘要
│ ├── 2025-40.md
│ ├── 2025-41.md
│ └── ...
└── period/ # 自訂區間
├── 2025-Q1.md
├── 2025-01-01_to_2025-03-31.md
└── ...
你也可以自訂路徑：
如果想放在其他位置（如 ~/Documents/work-achievements/），記得同步修改：
.claude/settings.json 中的 allowedDirectories 路徑.claude/commands/brag-daily.md 和 brag-summary.md 中的儲存路徑統一管理的好處：
如果你想要更自動化的解決方案，bragdoc.ai 是一個專門幫開發者追蹤成就的工具：
主要特色：
官方網站： https://www.bragdoc.ai/
相比 Claude Code Slash Command：
可以根據需求選擇：
無論使用哪種方法，最終產出的文件建議包含：
## [時間範圍] 成果總結
### 核心專案
- 專案名稱：你的貢獻 - 解決的問題 - 業務價值
- 影響範圍：[量化數據]
- 相關連結：[PR/Issue]
### 協作貢獻
- Code Review：[數量] 個 PR，重要發現
- 技術支援：協助同事解決的問題
### 技術優化
- 優化內容 - 量化成果（速度提升、成本降低等）
### 知識分享
- 內部分享：主題與參與人數
- 文件撰寫：解決了哪些問題
- 技術文章：[如果有對外發表]
### 技術成長
- 學習的新技能與應用場景
- 取得的認證或完成的課程
Julia Evans - Get your work recognized: write a brag document
https://jvns.ca/blog/brag-documents/
GitHub - Brag now, remember later: Document your accomplishments
https://github.com/readme/guides/document-success
親愛的工程師朋友：
記錄成果是為了避免你的價值被低估。
從今天開始，試著記錄你的工作日常吧。可以先從最簡單的開始：每週五花 10 分鐘，用 /brag-daily 產生摘要，存到檔案裡。
兩個月後，你會發現自己其實進步非常多，也做了非常多的事情。
今日金句： "There's this idea that, if you do great work at your job, people will automatically recognize that work. In practice, it's often more complicated than that." — Julia Evans
明日預告： Day 26 - AI 醬還在想...
iThome鐵人賽
看影片追技術