Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin Chain SAFU CryptoTax DeFAI AGI Claude Me Claude Skill Claude Design Claude Cowork
獨立知識媒體
與任何項目無關聯
讓 Claude 替你工作,不只是幫你回答
claudecowork-me.com
最新
五場會議記錄變一份週報:為什麼中間要停下來看一眼,不要一次做完  ·  錄一個技能,還是排一個定期任務?先分清楚這兩個問題不一樣  ·  「語氣要專業但不要太生硬」:與其寫成規則,不如貼一封舊信  ·  技能用了三個月後:改壞了怎麼退回去,是這個場景真正的難題  ·  排程技能失敗了,該讓它自己重跑幾次,還是馬上叫人?  ·  第一次串接 MCP Server:多數人卡關的不是設定,是搞錯了它在做什麼
scene-library

五場會議記錄變一份週報:為什麼中間要停下來看一眼,不要一次做完

30 秒速讀
一次做完看起來比較快,但錯誤只有在中間停下來看一眼的時候,才會停在它發生的那一步,不會被帶到你交出去的那份文件裡。

完整解析 +
01 · 為什麼發生?

把五場會議記錄整理成一份週報,指的是一個看似單一、實際上有兩個階段的任務:先把每場會議個別摘要出重點,人工確認這些摘要沒有問題之後,再把它們整合成一份週報。這跟一般理解的「請 AI 幫我做週報」不是同一件事——多數人直覺會把整個任務丟進單一次呼叫,期待 Claude 一次做完摘要跟整合,但這個任務結構裡有一個真正需要人眼確認的中間站:個別摘要階段容易混入離題內容或發現多場會議討論同一件事,這個判斷只有看過摘要之後才做得出來,不能跳過。

02 · 運作原理是什麼?

這個做法會被需要,是因為單一次呼叫要同時處理「哪些是真正的重點」跟「哪些會議在講同一件事」這兩層判斷,而後者的答案要看過前者的結果才知道——你沒辦法在還沒看到任何一份摘要之前,就先告訴 Claude「第二場跟第四場其實在講同一個專案,請合併寫」,因為連你自己都還沒意識到這件事。這正是很多人第一次遇到週報輸出品質不穩定時,會誤以為是指令寫得不夠精確的原因:問題不在指令,是任務本身天生分成兩個依序發生的判斷層,硬要塞進一次呼叫,等於要求 Claude 在完全沒有中間資訊的情況下,同時做好兩層判斷。

03 · 如何應用

操作分兩步。第一步,把五場會議的逐字記錄交給 Claude,指令明確要求「針對每場會議個別產出重點摘要,五份分開列出,不要合併」,這一步刻意不要求整合,目的是先拿到未經合併判斷污染的原始摘要。第二步,花兩三分鐘讀過這五份摘要,重點檢查三件事:有沒有摘要把離題閒聊當成重點寫進去、有沒有幾場會議其實在討論同一個專案該合併著寫、有沒有哪場會議根本沒有值得往上報的內容。確認或稍微修改這五份摘要之後,把它們一起交給 Claude,第二次指令是「整合這五份已確認的摘要,寫成一份週報」。兩次呼叫之間的那次人工確認,就是整套流程裡真正防止錯誤被帶到最終文件的關鍵動作。

04 · 我該怎麼做?

對你來說,這套流程真正改變的是「錯誤被發現的時機」。一次做完的做法,錯誤要嘛你根本沒發現就送出去了,要嘛送出去後被主管抓到才回頭補救;拆成兩步、中間確認一次,錯誤在還只是五份摘要裡的一份、還沒被整合進最終文件之前就被攔下來,修正成本低很多。要留意的是判斷什麼時候值得走這套流程:會議數量少、內容單純、你早就知道重點是什麼的週次,直接一次做完即可,不需要為了流程而流程;會議數量多、內容彼此有重疊、或這份週報要對外負責的週次,中間那兩三分鐘的確認,換來的是不用在主管面前被問到答不出來,這筆帳很划算。

完整內容 +

週五下午,手上有這週五場會議的逐字記錄,加起來將近一萬字,你需要在下班前生出一份給主管看的週報。最直覺的做法是把全部逐字記錄貼給 Claude,下一句指令:「幫我摘要這些會議重點,整理成一份週報」。這個做法通常能跑出東西,但真正用過的人都知道,跑出來的週報常常哪裡怪怪的——可能是某場會議裡一個離題的閒聊被當成重點寫了進去,也可能是兩場會議討論同一個專案,週報裡卻被拆成兩段各講一半,重複又矛盾。

問題不是指令不夠清楚,是任務本身有一個看不見的中間站

多數人第一次遇到這種輸出問題,會覺得是自己指令下得不夠精確,於是把提示寫得更長、加更多形容詞(「請摘要出真正重要的重點,忽略閒聊內容」)。這個方向通常沒什麼用,因為問題根本不在指令精確度,是任務本身天生需要一個中間站——先把五場會議各自摘要出重點,你看過這五份摘要、確認沒有離題內容混進去、也看出哪幾場其實在討論同一件事之後,才進入下一步,把這些已經篩過的摘要整合成一份週報。這箇中間站不是可有可無的裝飾,是這個任務結構裡真正需要人眼確認的節點。

把任務拆成兩次呼叫,中間插入一個檢查點

具體做法分兩步。第一步,把五場會議的逐字記錄分別(或一次全部附上但清楚標示各自邊界)丟給 Claude,要求「針對每場會議個別產出重點摘要,不要合併」,這一步的產出是五份獨立的摘要,不是一份週報。第二步,先花兩三分鐘看過這五份摘要——這是整個流程裡真正需要你判斷的地方:有沒有哪則摘要把離題的閒聊當成重點、哪幾場會議其實在討論同一個專案該合併著寫、有沒有哪場會議根本沒有值得往上報的內容。確認或稍微修改過這五份摘要之後,才把它們一起交給 Claude,這次要求「整合這五份已確認的摘要,寫成一份週報」。

這個做法本質上是 prompt chaining(提示鏈接)的實際應用——把一個大任務拆成好幾個獨立的提示,前一次呼叫的輸出經過確認後,才變成下一次呼叫的輸入。它的價值不在於「拆比較高級」,是在拆開之後,錯誤會停在它發生的那一步,不會被一路帶到最終的週報裡才被發現。如果只用一次呼叫做完整件事,你要嘛得逐字讀一遍原始的一萬字記錄去抓錯(等於自己重做一次),要嘛就是冒著把離題內容當成重點呈交給主管的風險。

什麼情況不需要拆成兩步

不是每次寫週報都值得走這個流程。如果這週只有一場會議、內容單純、你對「重點是什麼」已經心裡有數,一次呼叫通常就夠了,拆兩步反而多花時間確認一份你早就知道答案的摘要。值得拆的情況,是會議數量多(三場以上)、內容彼此有重疊或需要交叉比對、或是這份週報要往上呈交、你需要對內容負責——這幾個條件愈符合,中間站的檢查價值就愈高。

這跟你的工作有什麼關係

五場會議一萬字,一次呼叫做完通常一兩分鐘就有結果,看起來省時間;但如果那份週報裡混進了離題內容或重複矛盾的段落,你要嘛在主管會議上被問到答不出來,要嘛得回頭花時間重新核對整份原始記錄,這個代價遠高於中間多停留的那兩三分鐘。拆成兩步、中間插入一次快速確認,看起來慢,實際上是把犯錯的成本從「週報送出去之後」提前到「週報送出去之前」,而後者永遠比前者便宜。

圖解
五場會議記錄整合為週報:兩次呼叫加一次人工確認五場會議逐字記錄先各自摘要,不合併;人工花兩三分鐘確認五份摘要有沒有離題內容、哪幾場該合併、有沒有不值得上報的;確認後才整合成最終週報,錯誤在還是單份摘要時就被攔下Weekly Report: Chained, Not One-Shot5 Meeting TranscriptsCall 1: Summarize5 separate summariesno mergingHuman Checkpoint2-3 min: off-topic?same project? worth reporting?Call 2: Integrateconfirmed summaries -> reportFinal Weekly Reporterror-checked before sendClaude Cowork Me · claudecowork-me.com
歡迎截圖分享,轉載請註明來源
編輯的話 +
Grace Patel 的觀點
本篇為 prompt chaining 詞條的實際應用場景,與既有 meeting-minutes-scene(單場會議紀錄格式化)角度不同,該篇處理的是單次呼叫的格式轉換任務,本篇處理的是跨多場會議、需要人工中間確認的多階段任務。
提問
請至少輸入 10 個字
相關文章
「語氣要專業但不要太生硬」:與其寫成規則,不如貼一封舊信
scene-library · 07/31
技能用了三個月後:改壞了怎麼退回去,是這個場景真正的難題
scene-library · 07/30
跨時區會議協調場景:與其問「你哪個時間方便」,不如讓 Claude 先幫你排出所有人都醒著的選項
scene-library · 07/08
跨部門協作溝通場景:用 Claude 把「說不通」的內部溝通,轉化成往解決方向走的對話
scene-library · 07/02