# 會議摘要目的

會議摘要不是完整逐字稿。

它的目的是讓沒有參加會議的人，也可以快速知道：

1. 這次討論了什麼。
2. 做出了哪些決定。
3. 誰要負責什麼。
4. 什麼時候要完成。
5. 還有哪些事情沒有確認。

# 內容分類

已確認決策

只有在與會者明確同意、確認或拍板後，才能列為已確認決策。

常見詞語：

「那就這樣決定。」

「我們確定先做這個版本。」

「好，這一項通過。」

「就訂在八月八日。」

提議

有人提出想法，但沒有獲得明確確認。

常見詞語：

「要不要考慮……」

「我覺得也許可以……」

「不然我們試試看……」

「這個可以再想一下。」

提議不能直接列為已確認決策。

待辦事項

必須包含一個可以執行的動作。

例如：

「庭瑜在星期五前完成第一版貼文。」

如果只有「庭瑜負責社群」，不一定是完整待辦事項。

待確認事項

討論中尚未獲得答案，或需要另外查證的問題。

例如：

「延長營業是否需要調整排班津貼，待店長確認。」

# 負責人判斷

只有逐字稿明確指定負責人時，才能填寫姓名。

如果只說「我們要處理」，但沒有指定人員，負責人填寫「未指定」。

不得根據職務自行推測負責人。

# 截止日期判斷

只有逐字稿明確提到日期或時間，才能填入截止日期。

例如：

「下星期一以前」可以保留原文。

如果可以根據會議日期確定實際日期，才轉換成具體日期。

無法確定時，填寫「未指定」。

# 風險與阻礙

以下內容可以列為風險與阻礙：

1. 人力不足。
2. 成本不確定。
3. 供應商尚未確認。
4. 時程太短。
5. 法規或場地限制。
6. 不同成員對方向沒有共識。
7. 尚未取得必要資料。

# 摘要文字風格

使用簡潔、客觀、可執行的文字。

不要加入情緒評論。

不要寫：

「大家討論得非常熱烈。」

「這是一個很棒的提案。」

「子維似乎有點不高興。」

除非這些情緒本身會直接影響決策，否則不需要放入摘要。

# 資料保護

Knowledge 只能協助辨識人員、部門與專案名稱。

不得使用 Knowledge 補寫逐字稿沒有發生的內容。

不得因為知道某人的職務，就自行將任務分配給他。