對於平常使用 Claude Code 等程式撰寫 AI 來開發的各位,我想提出一個問題。
「你能否舉出具體案例,說明自己是否有妥善使用程式撰寫 AI?」
對我來說,這是作為提交人事考核資料時所需要的內容。但我對自己的記憶力沒有信心。現在許多工作幾乎都只靠自然語言來互動,要記住每一件事中自己做了什麼判斷、下了什麼指示,根本不可能。
因此,我得出的答案是:「既然記不住,那就把它記錄下來就好」。應該記錄的判斷都已經在對話 session 裡了,所以我想到可以在 session 結尾呼叫一個「統整回顧 skill」,並開始實際運用。
這次我想以分享這個點子為主,介紹這個 skill 本身,以及目前為止的成果,因此寫了這篇文章。
這個 skill 的用法非常簡單。只要在「大致都已經實作完成了」的時候,在該 session 裡呼叫 /decision-log 即可。這個 skill 大致會做的事情有:
等等。
而記錄本身與記錄的觀點,則是保存在與 skill 定義不同的目錄中。以我自己為例,是用下面這樣的結構來整理:
~/.claude/skills/decision-log/SKILL.md # 只有流程。不包含要挑選什麼
<記錄位置>/振り返り観点.md # 定義 session 中哪些內容要撿取、哪些不要撿取
<記錄位置>/振り返り/<YYYY-MM>.md # 回顧內容的日誌。按月追加
<記錄位置>/adr/NNNN-<標題>.md # 有基於判斷做出採用時
當對 AI 下達「請評估自己」這類指示時,它通常都會用某種方式把話說得很好聽。若是在煩惱諮詢之類的情境下,這樣很有幫助;但若是要做記錄,這樣就不行了。必須徹底要求它以事實為基礎書寫,並明確下達像是「沒做過的事不要寫」這類指示。反過來說,若設定了像「是否有檢查」這類觀點,如果因為沒有特別提到就被直接斷定成「沒做」,那也會出問題。因此,我在設計這個 skill 時,特別要求它仔細進行這方面的事實確認。
另外,AI 如何理解指示也會因模型而異,所以依照表現挑選要用哪個模型來做回顧,或許也值得斟酌。目前我先用 Opus 5.5 測試了幾次,就我看到的範圍內,沒有出現像是「寫了其實沒做過的事」這類案例。
這個 skill 預期會產出兩種成果物。第一種是回顧本身的紀錄。只要先把紀錄保留下來,要讓 AI 讀取並萃取重點並不困難。至於整理人事考核用的資料,可以留到之後在成果物提交時再進行即可。
第二種是 ADR(Architecture Decision Record,架構決策紀錄)。簡單來說,就是「說明實作上的設計判斷,以及其經過與競爭方案的文件」。
在 Claude Code 的 session 中,經常會出現像是「這部分要怎麼做?」這類互動。這些所謂的決策問題有大有小,但實際上,做出決定這件事本身,往往也很值得記錄到 ADR 裡。因此,這個回顧 skill 也包含了根據這些經過來產出 ADR 的功能。
把這些產生出來的 ADR 在專案內的 repository 中分享,也能達到將難以直接留存在程式碼現況中的經過保存下來的效果。
從 9 月底開始運用大約 1 個月後,已記錄的工作有 5 件,另外一起撰寫的 ADR 有 10 件。
另外,作為我自己的課題,我一直覺得在送出 PR 之前的自我審查做得不夠徹底。因此在回顧觀點中,我也寫入了「是否有進行自我審查」,而 decision-log 也更進一步揭露出:我幾乎都在急著把 PR 送出去的流程下,沒有插入審查這一步。
於是我另外製作了自我審查 skill,並透過 hook 擋住,讓沒有經過它就無法建立 PR,藉此把審查這項作業從依賴我的意識中解放出來。作為蒐集自我改善材料的工具,decision-log 可以說是在發現問題點上發揮了作用的一個案例。
這次介紹的是一個會彙整 session 資訊,並依照事先設定的觀點進行反省與撰寫 ADR 的 skill:decision-log。雖然目前還看得到不少課題,例如「結果還是依賴呼叫時機來決定回顧時間」、「compaction 之後無法精確撈出對話內容」等等,仍有很多改善空間,但它似乎確實很適合用來撈出那些平常總會被我遺漏掉的資訊。
除了這裡介紹的用途之外,我也覺得像是事件處理紀錄、學習紀錄等其他內容,也能用同樣的形式來活用。如果你也有「之前做過的事,自己不記得,記錄裡也沒有」這樣的煩惱,不妨試試看。
株式会社シンシア招募沒有實務經驗的工程師,以及學生工程師實習生,並與他們一同工作。
※ 關於シンシア的工作方式,請見這裡
株式会社シンシア的工作方式與故事 - Wantedly
如果你也想成為彼此切磋技術、共同成長的夥伴,歡迎與我們聯絡!
原文出處:https://qiita.com/qwertyhoge/items/987c0ea8afdb5cd045e8