工程師或多或少都會做一些筆記，紀錄一些工作心得，技術實踐細節 ……等內容，但最大的痛點往往是：寫了不等於記住，更難確保關鍵時刻能派上用場。
自己在 Heptabase 上記了一大堆內容，但只有偶爾才會回來看這些內容。而且如果單純的重新閱讀，大多時候也不會從這些筆記中找出更新的體悟，效益也不高。
只有真的在工作碰到有關的問題，自己有突然想到跟筆記的某一段有關係，才會有機會再回頭重新思考。
有時候就會想，是不是能找個人來看看我的筆記，一直問我一些怪問題，讓我可以從不同的角度思考，那該有多好？
現在有個完美的陪練員可以幫我，那就是 AI。
用 Heptabase MCP 打造「刁民」助教
Heptabase 官方提供了 MCP 有一陣子了，但是直到最近，我有一些多餘的 AI 扣打可以用，才在想什麼地方可以消耗。
於是就想到這個之前想做，但沒辦法做的 Idea：讓 AI 從 Heptabase 找一個白板，從這個白板中的筆記發想內容，當一個刁民來反覆地問我問題，促進我的思考。
所以我就做了一段 Prompt 如下：
"主題" 白板中有很多子白板，從這群子白板中隨便挑一個白板
你是一個刁鑽的學生，你是試圖理解這個白板中的資料
你要隨機從這個白板中的資料，問我一個問題，當我回答問題時，你要嘗試用理論或數據反駁我
最多反駁五次，然後總結本次的討論內容，與提出可改進的理解。主題白板中有許多不同領域的筆記，讓 AI 隨機從這些挑一個領域來，讀取裡面的筆記內容來發想問題。
選擇一個主題之後，運用五個 Why 的概念，讓 AI 在我每次回答問題之後繼續追問，持續當個刁民反駁我五次。
使用 Antigravity 來驅動
由於 Antigravity 最近比較少使用，加上他 AI 額度好像一直被調降，所以最近比較少用到，但又覺得沒用有點浪費。
所以這次就決定使用 Antigravity 來串 Heptabase MCP，設定可以參考如下：
{
"mcpServers": {
"heptabase-mcp": {
"command": "npx",
"args": [
"-y",
"mcp-remote@latest",
"https://api.heptabase.com/mcp",
"--transport",
"http-only"
]
}
}
}當跟 AI 討論問題之後，我會請 AI 總結這次討論寫成一則紀錄Antigravity 可以直接透過 MCP 把這個紀錄寫回 Heptabase，但是我沒有這麼做。
主要是因為我想保持我的 Heptabase 都是我自己理解過的寫出來的內容，所以我會先把討論結果存放在本地的資料夾中。
之後我自己再把一些消化過的內容寫回 Heptabase 中。
實驗結果
大概進行了一週，除了討論了繼承 vs 組合、策略模式 vs 責任鏈模式、DIP、Domain Event 的發布與儲存、代碼共有。
我個人覺得效果很不錯，往往都能從這些來回問答中挖到更深的理解，而且不會花太多時間，很適合當一天一題的挑戰。
未來擴展方向
最後預計把 Notebooklm 與 Notion 也串進 Antigravity 中，讓 Antigravity 可以用來當作某種 AI 輔助的學習工具。
整合 Notebooklm 的文獻和 Notion 中的各種資源，看看是不是能延伸出更不同的應用。
如果有興趣朋友可以看看下面的實際討論過程。
至於內容是否正確，觀眾可以謹慎評估，畢竟我的理解不一定對 😅
代碼共有的討論過程
Round 1
AI 讀取了極限編程的白板，並問了代碼共有的問題
你的筆記說「代碼共有」讓每個人都有修改任何程式碼的權利，並強調「不需要記住 Code 怎麼寫，而是提高 Code 的可讀性，讓需要的人在需要的時候可以看 Code 理解」。
我的問題是：
這不就是在說，只要版本控制和註解寫好、code 可讀性高，任何人隨時都可以理解並修改別人的 code？那為什麼實務上很多團隊採用代碼共有之後，反而出現責任不清、程式碼品質下降的問題？是你的理解有問題，還是這個理論本身就有缺陷？
請回答！我的回答
理論上是這樣，實務上出現問題，大多可能是因為開發人員的素養不足或者是新進人員，對代碼的理解不夠，對極限編程的概念不熟悉所導致的，需要透過與資深人員 Pair Programming 傳授或同步理解，才能改善Round 2
接著又順著我的回答追問了 Pair Programming
🎓 反駁（第一回合）：
你的回答聽起來有道理，但我覺得這是在「怪人不怪制度」。
你說需要透過 Pair Programming 與資深人員傳授，才能讓代碼共有運作良好。但這不就是說，代碼共有本身無法獨立成立，它需要依賴 Pair Programming 才能運作？
這代表兩件事情：
成本問題：Pair Programming 本身就是讓兩個人做一件事，等於直接砍掉一半的產能（至少在短期內）。如果代碼共有要仰賴 Pair Programming 才能不崩潰，那總體成本可能遠超過你預期的效益。
循環論證：你在說「只要每個人都夠好、夠熟悉，制度就能運作」。但好的制度設計應該是即使人不是最頂尖的，制度本身也能降低出錯的機率，而不是靠人的素養撐起來。如果代碼共有要靠「人的素養夠高」才能成功，那它本身是否就是一個脆弱的設計？
你的筆記自己也提到「根本就沒人可以理解所有程式碼」，那 Pair Programming 能傳授的知識是否也是有限的？真的能解決問題嗎？我的回答
1. Pair Programming 看起來好像會砍掉一半產能，但他實際上會讓開發出來的產品品質更好（四眼法則），Bug 更少，反而能少掉許多 Debug 與 rewrite 的時間，實際上反而可能增快開發進度
2. 只要熟悉極限編程的這些原則與做法，其實就夠了，這些都是概念相對簡單的原則，不需要從聰明頂尖的人才能辦到Round 3
再到工作中實際會發生的狀況
🎓 反駁（第三回合）：
這兩個回答都很有趣！但我還是要挑戰你：
對第一點（先討論再分頭實作）：
你說討論確認方向後，確認夠簡單就分頭做。但問題是——「夠簡單」這個判斷本身就是風險所在。
兩個人討論完，覺得「夠簡單，分頭做吧」，然後分開實作時，A 可能往左走，B 往右走，兩人對「簡單實作方式」的詮釋就是不一樣。等到 Code Review 或 merge 時才發現風格差異或設計衝突，難道這不是反而製造了更多後期的溝通成本嗎？其實你並沒有消除協調成本，只是把它移到後面而已。
對第二點（XP 像健身，需要紀律）：
這個比喻很好，但有個致命的差異：
健身是個人行為，即使只有你一個人有紀律，你還是能從中獲益。
但 XP 是團隊行為。只要團隊中有一個人在 deadline 壓力下開始走捷徑——不寫測試、直接 push、跳過 Code Review——整個 code base 的品質就開始腐敗，其他有紀律的人也會被拖累。這就像健身房裡只要有一個人用器材完不放回去，整個環境就亂了。
所以問題不只是「個人有沒有紀律」，而是如何在組織層面確保全員紀律？你的筆記對這一點有具體答案嗎？我的回答
1. 確實如你所說，簡單的任務可以不一定要 Pair Programming 的一起 “實作”，但是這還是得透過前期一起討論需求，確認需求與實作大致方向之後，兩個人都覺得夠簡單之後，就可以分頭進行實作
2. 主要是極限編程的概念雖然簡單，但卻是相當反直覺，與延續工業化流水線的傳統開發方式截然相反。執行極限編程就跟健身一樣，人體天生不喜歡，但是我們還是得維持這個紀律，讓軟體更健康，更能長久Round 4
繼續問我如何在 Retrospective 中確保有心裡安全感
🎓 反駁（第四回合）：
你的回答越來越有體系了，但我繼續挑戰：
對第一點（用 Retrospective 改善）：
Retrospective 是「事後」的修正機制——但問題是，等你做完 Retrospective，那次的技術債或設計落差已經進了 code base 了。你是在用事後的學習來補救事前的失誤，每次 Retro 都是一次代價。
更重要的是：Retrospective 的品質高度依賴「心理安全感」。如果團隊文化讓成員怕被批評，Retro 就會流於表面，大家只說好聽的、不說真正的問題。你的筆記有提到 Retro，但對如何確保 Retro 的品質和心理安全感，有具體做法嗎？
對第二點（違反紀律就請他離開）：
開除人是成本最高昂的解法之一——招募、培訓新人的成本、流失的 domain knowledge，往往遠超過一個人破壞紀律的代價。
而且更根本的問題是：那個人為什麼違反紀律？ 很多時候，是因為 PM 或主管施加了不切實際的 deadline 壓力，讓他不得不走捷徑。如果組織結構本身就在激勵走捷徑，你開除一個人，下一個人還是會走同樣的路。這個問題你要怎麼回應？我的回答（到這裡其實也能感覺自己的回答有點虛，因為相關的知識與實務了解還不夠多）
1. 盡量讓參與開會的人權力對等，然後工作環境也要盡量開放一些，讓成員平時可以容易且自然的交流，不要只公事要討論時才聚再一起
2. 當 PM 或主管對個人實施壓力的時候，團隊應該要共同的承擔責任，對不合理的預期勇於說不，而不是讓某個人承擔。這也有助於讓團隊凝聚再一起，增加團隊的安全感Round 5
最後給出第五次反駁以及總結（這裡不太對，他應該要等我給完回答才總結 🤣）
🎓 反駁（第五回合，最後一回合）：
兩個回答都抓住了重點，但讓我做最後一次挑戰：
對第一點（權力對等的開放環境）：
「讓開會的人權力對等」——這說起來容易，但組織裡的權力結構是隱性的。即便你說「大家都是平等的」，資深工程師的一句話還是會無形中壓制新人的聲音。心理學上稱之為「地位特徵理論」——人會根據對方的社會地位自動調整自己的發言意願，這是人的本能，不是靠「開放的物理環境」就能解決的。
對第二點（團隊共同對抗不合理壓力）：
這個理想很美好，但「團隊共同說不」需要以數據與事實為後盾，否則只是集體情緒化的反抗，管理層可以輕易以「專業態度」或「責任感」為由駁回。你的 Estimation、Velocity 這些 Scrum 數據，正好就是這個底氣的來源——但問題是，如果管理層本身就不信任這些數據（認為是開發團隊在灌水），那又怎麼辦？
🏁 五回合到此結束，讓我總結我們的討論！
📝 本次討論總結：代碼共有能否真正落地？
討論核心問題： 代碼共有搭配 XP 實踐在理論上成立，但實務上為何容易失敗？
你的論點（逐步深化）：
失敗的根本原因是人的素養與熟悉度不足，需要 Pair Programming 傳承
Pair Programming 雖看似耗資源，但提升品質、減少 bug，長期反而更快
XP 原則雖反直覺，但像運動健身一樣，需要持續紀律
用 Retrospective 持續修正落差；違反紀律者最終請離
心理安全感來自權力對等的文化；Estimation 數據是對抗不合理壓力的底氣
可改進的理解：
Retrospective 的前提：有效的 Retro 需要心理安全感，而心理安全感需要刻意建立（如明確的 Retro 引導規則、匿名機制），不能只靠「開放環境」自然生成
數據要真正被信任：Estimation / Velocity 是說不的底氣，但需要長期建立管理層對數據的信任，這本身也是一個需要主動經營的過程
XP 最脆弱的地方不是個人紀律，而是組織文化：沒有組織上層的支持，XP 實踐很難在壓力下存活
現在我來把討論寫進你的 Heptabase 討論筆記資料夾 📁