Day 8：怎麼跟 AI 說，才會寫出你要的那篇 DevLog——/mcpost 使用指南

口述就夠，但要說「範圍」不是「主題」；附一次真實的抓錯與修正

口述就夠。但說「範圍」比說「主題」有用——這是實際踩過才學到的。

口述就夠。但說「範圍」比說「主題」有用——這是實際踩過才學到的。 一次真實的抓錯

對話跑了一整個早上：修了認證漏洞、改了 rate limit、順手把一個 skill 改名。然後： 使用者：「這個很重要，值得寫一篇 mcpost」

AI 理解成「前一則在講的那個 skill 改名」——因為那是最近一輪的話題。 使用者得再補一句才對得上： 使用者：「我指很重要，可以寫成 mcpost 是今天早上做的事」

差別只在一個時間範圍。而且第一次寫出來的文章結構也不對，還要第三輪才修好： 使用者：「內容不對，請針對 登入 Token 設計的重要性，從登入逾時設計， 發現 Token 問題，如果沒加變數，有什麼資安問題，中間動用到哪些參數」

這一句就是最好的示範——它同時給了主題、起點、轉折、重點、以及要涵蓋的層次。 一次到位，不用再改。 三種指法，由粗到準

指法 例子 什麼時候用 --- --- --- 時間 「把今天早上那段寫成 mcpost」 一整段工作，主題單一 事件 「開 enforce 那條線寫一篇」 對話跳來跳去，要挑一條主線 你的原始問題 「我問自動登出那個，寫一篇」 最準——因為那正是文章的檢索入口

不指定的話，預設抓「最近一輪有實質結論的 Q&A」。對話單純時夠用， 但只要當天做過兩件以上的事，預設幾乎一定抓錯。 想要更準，就給「大綱」

真正一次到位的講法，是把文章的骨架講出來。不需要完整句子，關鍵詞就行：

對照上面那句真實的指令： 從 登入逾時設計（起點） 發現 Token 問題（轉折） 如果沒加變數，有什麼資安問題（重點與後果） 中間動用到哪些參數（要涵蓋的層次）

四個子句，就把一篇五千字的文章框死了。比「寫一篇認證的文章」精準一個量級。 可以順便指定的三件事

① 不要寫什麼 「rate limit 那段不用寫，只寫認證」

對話裡常常混著支線。不講的話 AI 會傾向全部收進去，文章就散了。

② 給誰看 「寫給不熟這個系統的人」／「寫給三個月後的我」

影響鋪陳多寡。給自己看的可以直接跳結論，給別人看的要補脈絡。

③ 重點放哪 「重點放在怎麼算出只影響 5 個人」

同一批素材，重點不同就是兩篇不同的文章。 有一個欄位由你決定，不是 AI

DevLog 格式裡有個 question 欄位，規則是原文照抄你的提問，不准改寫。

原因是檢索入口： 三個月後你會搜「登入多久會自動登出」，不會搜「HMAC 簽章身分驗證」。

標題是寫給看到的人，question 是寫給未來在找答案的你。所以： 當初問得具體 → 之後撈得到 當初問得含糊（「這個怎麼用？」）→ 文章之後很難被找到

補救方式是直接說：「question 改成『XXX』」，換成你之後真的會搜的講法。 流程上你一定攔得住

AI 一定先給 preview 才送出，內容包含：標題／副標／專區／標籤／能見度／字數。 看了不滿意就直接講，不用客氣： 「標題太長」 「重點錯了，應該是量化那段」 「這裡有客戶名，拿掉」 「太細了，砍一半」

送出後也還是草稿 + unlisted，要公開得自己去按。這是刻意的設計： 公開與否是人的決定，不是 agent 的。 什麼東西不值得寫

判準只有一句：三個月後的自己會不會想再看一次？

不會就別寫。知識庫的價值來自密度，不是篇數—— 十篇「今天修了個 bug」會把一篇真正有用的埋掉。

具體不要寫的： 純操作紀錄（跑了哪些指令、改了哪幾行） 失敗的嘗試過程（除非失敗本身有教訓） 沒有結論的討論

要寫的：判準（怎麼決定要不要做）、踩坑的原因（為什麼會踩到）、 架構決策（為什麼不選另一條路）。 code 用 git 保存，git push 就好。 「為什麼這樣做」沒有 git，不主動撈出來就留在 scrollback 裡爛掉。 什麼時候不要這樣做 對話還沒有結論就不要寫。做到一半的東西寫成文章，之後改了方向就變成錯誤資訊。 不要一次寫一整天的事。範圍太寬的文章沒有主線，之後也搜不到—— 寧可拆成兩篇各自完整。 不要跳過 preview 直接送（--yes 是給 CI 用的）。 互動情境下那一眼是你唯一的攔截點。 不要把客戶真名、工號、網域寫進去。有自動掃描擋機密， 但識別資訊要靠寫的時候就抽掉——掃描器不知道哪個字串是客戶名。 本篇由 claude-code（claude-opus-5） 於開發過程中產生。 repo：RedBallFlow @ 4ed37e77 標籤：mcpost devlog prompting knowledge-base workflow