AI資安事件紀錄：把零碎訊息整理成正式Incident Timeline

01解決的工作問題

資安事件發生時，資訊永遠是先亂後齊：監控系統跳出一則告警、員工用Line回報「電腦怪怪的」、IT值班電話裡聽到片段描述、隔天信箱又多幾封轉寄的可疑信件截圖。這些訊息時間戳記不同、可信度也不同，要在向上呈報、配合稽核或法遵之前，把它們整理成一份看得懂先後順序的Incident Timeline，是每次事件都要重做一次的苦工。最大的風險不是整理慢，而是整理時「順手補全」：把「使用者說可能是」寫成「已確認」，把系統紀錄沒寫清楚的時間點自己猜一個合理值，甚至因為某個IP或帳號重複出現，就在摘要裡暗示是誰做的、動機是什麼。這些補全在草稿階段看起來讓報告更完整，一旦流出到法遵、保險理賠、或司法調查的脈絡裡，就是會被追究的錯誤陳述。AI適合把零碎、格式不一的原始紀錄快速讀完並依時間排出骨架，但攻擊者是誰、動機為何、責任歸屬如何，永遠必須是人根據證據另外判定，不能讓AI用推論帶過。

02什麼時候用、什麼時候別用

什麼情況下該用這一套

• {'t': '手上有多來源的零碎紀錄', 'd': 'log、信件、電話紀錄、對話截圖，需要整理成一份看得懂的時間線。'}
• {'t': '事件需要留存紀錄或走正式流程', 'd': '事件性質偏向要呈報主管、配合稽核，或可能進入法遵/保險程序。'}
• {'t': '有人先做初步分類', 'd': 'IT或資安窗口先把來源整理過一輪，AI只負責整理不做調查。'}

什麼情況下別用

事件仍在即時延燒需要立刻圍堵時

先處理、先隔離，整理時間線是事後動作，不能拖延應變。

需要判定攻擊者身分或責任歸屬時

這是調查與司法/保險程序的範疇，AI不能也不該代勞。

已進入司法程序或高度機密的案件

紀錄可能是呈堂證供，處理與保存方式要先問法務，不是先丟給AI。

唯一來源是口耳相傳、沒有任何留存紀錄可查證時

AI沒有東西可以整理，硬整理只會製造一份看似正式但沒有根據的文件。

誰會用到

資訊／資安

你最常是第一個彙整原始紀錄的人。log與截圖丟給AI前，先確認時間都轉成同一個時區，不然時間軸會全部對不齊。

主管

你要決定Owner與Next Step怎麼分派，也是最後拍板要不要往上呈報的人。AI排出來的時間軸只是底稿，不能直接對外發。

法務

你關心的是「已確認」與「未確認」有沒有被誠實區分，以及有沒有出現責任歸屬或攻擊者身分的推論。這兩件事發生任何一件，這份文件都不能用。

所屬工作情境

04完整步驟圖的文字版，逐步展開

一句話版（快速回顧）

1. 人蒐集並分類原始紀錄，去識別化敏感資訊
2. AI逐則抽取時間/事件/來源，標記已確認或未確認
3. AI依時間排序整合成初版Incident Timeline
4. 人工逐列查證、填Owner與Next Step
5. AI依查證後版本產出正式Incident Summary
6. 主管/法遵終審核准後發送歸檔

完整版（每一步誰做、產出什麼）

05開始前要準備什麼標「必要」的沒備齊就先別開始

原始紀錄全彙整必要

系統/防火牆/EDR log截圖或匯出檔、通報信件、電話通報的逐字稿（可用STT轉出）、Line/Teams對話紀錄截圖或匯出文字。

各紀錄的來源與時間格式標記必要

每則資料註明來自哪個系統、是誰回報、原始時間戳（含時區），沒有時間戳的要註明「無時間戳」。

個資與敏感資訊先遮蔽必要

使用者帳號、客戶資料、內部IP若含個資，先代碼化或去識別化。

已知的權責分工必要

誰是這起事件的Owner、誰有權拍板通報，先確認好，不要等時間軸做完才找人。

公司既有的事件分級/通報規範可選

有的話拿出來對照，法規要求的通報時限、要通報哪個主管機關。

前一版本的Timeline可選

若事件已整理過一次，這次是更新，附上前一版方便比對變化。

餵進去的東西要長這樣

去識別化後的原始紀錄：系統/防火牆log匯出、通報信件、電話通報逐字稿、對話紀錄，每則標明來源與時間。

• 每則資料要標明來源類型（log／信件／電話／對話），方便判定已確認/未確認的可信度。
• 所有時間先統一時區，log常用UTC，信件與對話用當地時間，混用會排錯順序。
• 個資、帳號、客戶資料先代碼化再貼進AI。
• 電話通報先用STT轉成逐字稿再整理，逐字稿本身也要保留。
• 沒有時間戳的紀錄要註明「無時間戳」，不要自己補一個。

【來源1：防火牆log匯出，UTC+8】2026-08-16 23:07:12至23:46:58，帳號svc_vpn03登入失敗41次，IP 203.0.113.44；23:47:31同帳號同IP登入成功。
【來源2：使用者轉寄信件，2026-08-17 08:15】「昨晚收到簡訊說VPN驗證碼要重設，我輸入了驗證碼，附截圖。」
【來源3：電話逐字稿(STT)，約2026-08-17 09:02】「三民店電腦變慢，跳出英文視窗，看不懂。」
【來源4：IT群組對話，2026-08-17 09:30-09:50】技術員發現不明排程工作並停用；09:50停用帳號、強制改密碼。

06Prompt（快速／完整／進階）

A 快速版貼上就能用；B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足；C 進階版是拿去建 GPT／Skill／Agent 的系統指令。三種都附可替換變數、使用範例、預期輸出與人工確認點。

以下是一起資安事件的零碎原始紀錄，來源不只一種（可能包含系統log、通報信件、電話逐字稿、群組對話紀錄）。請幫我整理成一份 Incident Timeline 草稿，規則如下：

1. 用表格呈現，每一列包含：時間、事件、來源、已確認／未確認、已採取措施、Owner、Next Step。
2. 「已確認」只能用在原始紀錄裡有明確文字支持的項目；沒有直接證據、只是聽說或推測的一律標「未確認」，並在旁邊註明依據是哪一則原始紀錄。
3. 時間有缺口、衝突、或原始紀錄沒寫清楚時，不要自己猜一個合理的時間，要照實寫「時間不明」並註明原因。
4. Owner、已採取措施、Next Step 這三欄，如果原始紀錄裡沒有明確資訊，一律留白或寫「待補」，不要自己填。
5. 絕對不要判定或暗示攻擊者是誰、動機是什麼、或是誰的責任。這些欄位不存在於這份時間軸裡，也不要藏在「事件」欄的描述文字裡。
6. 整理完之後，額外列出「待查證清單」：哪些項目標了未確認、需要跟誰核對才能升級為已確認。

原始紀錄：
{貼上}

以下是一起資安事件的零碎原始紀錄，來源不只一種。請幫我整理成Incident Timeline草稿。（照母提示詞六條規則）

【來源1：防火牆log匯出，時區已轉為UTC+8】
2026-08-16 23:07:12 至 23:46:58，帳號svc_vpn03對VPN登入失敗共41次，來源IP 203.0.113.44（非公司白名單IP段）。
2026-08-16 23:47:31，同帳號同IP登入成功。

【來源2：使用者轉寄信件，寄件時間2026-08-17 08:15】
「昨天晚上收到一封簡訊，說VPN驗證碼要重新設定，點進去輸入了驗證碼，現在想想覺得怪怪的，附上簡訊截圖。」

【來源3：電話通報逐字稿(STT轉出)，通話時間約2026-08-17 09:02】
「呃...我是三民店的店長啦，我這邊電腦從早上開始就變得很慢，剛剛還跳出一個英文的視窗，我看不懂，也不知道要按什麼。」

【來源4：IT群組對話紀錄，2026-08-17 09:30】
IT技術員A：「去svc_vpn03那台筆電看了一下，工作排程器裡多一個沒看過的排程工作，名稱亂碼，已經先停用。」
IT技術員A：「09:50已經把svc_vpn03帳號停用，強制改密碼。」

原始紀錄：{以上四則}

【Incident Timeline 草稿】

| 時間 | 事件 | 來源 | 已確認/未確認 | 已採取措施 | Owner | Next Step |
|---|---|---|---|---|---|---|
| 2026-08-16 23:07–23:46 | 帳號svc_vpn03遭連續41次VPN登入失敗嘗試，來源IP 203.0.113.44 | 防火牆log匯出 | 已確認〔佐證：log時間戳與失敗次數〕 | 尚未記載 | 待補 | 待補 |
| 2026-08-16 23:47 | 同帳號同IP登入成功一次 | 防火牆log匯出 | 已確認〔佐證：log顯示成功登入紀錄〕 | 尚未記載 | 待補 | 待補 |
| 2026-08-16 夜間（確切時間不明） | 使用者收到偽冒VPN驗證簡訊並輸入驗證碼 | 使用者轉寄信件 | 未確認〔僅憑使用者描述與截圖，尚無簡訊發送方紀錄可交叉核對〕 | 尚未記載 | 待補 | 待補 |
| 2026-08-17 約09:02 | 三民店店長回報電腦變慢、跳出英文視窗 | 電話逐字稿 | 未確認〔僅憑口頭描述，缺乏系統紀錄佐證，且「英文視窗」內容不明〕 | 尚未記載 | 待補 | 待補 |
| 2026-08-17 09:30 | svc_vpn03筆電上發現不明排程工作 | IT群組對話紀錄 | 未確認〔技術員口頭描述，未附排程工作名稱截圖或log〕 | 已停用該排程工作 | 待補 | 待補 |
| 2026-08-17 09:50 | svc_vpn03帳號停用並強制改密碼 | IT群組對話紀錄 | 已確認〔佐證：技術員對話紀錄明確記載動作與時間〕 | 帳號已停用、密碼已重設 | 待補 | 待補 |

【待查證清單】
1. 使用者收到的簡訊截圖：需IT或資安人員核對簡訊發送號碼與時間，才能把該列升級為已確認。
2. 三民店「英文視窗」的實際內容：需請店長截圖或請IT到場查看，目前描述不足以判斷是什麼。
3. 不明排程工作的名稱與內容：需技術員補上截圖或log，才能確認與登入事件的關聯。

本時間軸未判定造成這起事件的原因或是誰的責任，這些欄位刻意留白，待調查與查證後由人另行判定。

以下是Incident Timeline的草稿，以及我對其中幾列的查證結果。請依查證結果更新時間軸，並產出正式的Incident Summary。

查證更新規則：
1.【逐列比對】對照我提供的查證結果，把有佐證的「未確認」項目改為「已確認」並註明新佐證；沒有查證結果的項目維持未確認，不要自己升級。
2.【NextStep收斂】對於仍是未確認的項目，在Next Step欄位寫出具體要查什麼、由誰核對、什麼時候要有結果——這三項我會在附件裡告訴你，你只需要照填，不要自己指派人名。
3.【產出Incident Summary】用200-350字寫一段摘要，只重述已確認的事實與已採取措施的時間順序，不得出現攻擊者身分、動機、或責任歸屬的字眼；遇到「為什麼」「是誰」這類問題，一律寫「原因與責任歸屬待調查，不在本摘要判定範圍」。
4.【風險提示】另外列出這份時間軸目前最大的3個未確認缺口，說明缺口不補齊會有什麼風險。

規則：
- 不得把「已停用帳號」「已重設密碼」這類已採取措施寫成因果推論（不能寫「因為是外部入侵所以停用帳號」，只能寫「已停用帳號」）。
- 不得推測或補齊任何時間、Owner、Next Step，沒有依據就維持留白或未確認。

時間軸草稿：{貼上}｜查證結果與Owner/NextStep指派：{貼上}

（貼上A版產出的6列草稿，並附查證結果：簡訊截圖經比對確認為釣魚簡訊、店長已補充英文視窗截圖顯示為勒索軟體訊息框但IT尚未鑑定完成、排程工作已附截圖經比對疑似惡意程式但仍待鑑定；Owner指派：帳號相關由IT資安小組負責、對外通報評估由法遵負責，NextStep補上期限）

【已更新的Incident Timeline（節錄）】

| 時間 | 事件 | 來源 | 已確認/未確認 | 已採取措施 | Owner | Next Step |
|---|---|---|---|---|---|---|
| 2026-08-16 夜間 | 使用者收到偽冒VPN驗證簡訊並輸入驗證碼 | 使用者轉寄信件＋簡訊截圖比對 | 已確認〔佐證：簡訊發送號碼經比對為已知釣魚號碼〕 | 已請使用者變更VPN密碼 | IT資安小組 | 追查是否有其他使用者收到同批簡訊，08-19前回報 |
| 2026-08-17 約09:02 | 三民店電腦跳出英文視窗 | 電話逐字稿＋店長補充截圖 | 已確認〔佐證：截圖顯示為勒索軟體樣式提示框，惟尚未經鑑定確認是否為真實感染〕 | 已將該台電腦隔離離線 | IT資安小組 | 送鑑定確認是否為勒索軟體，08-18前出結果 |
| 2026-08-17 09:30 | svc_vpn03筆電發現不明排程工作 | IT群組對話紀錄＋截圖 | 已確認為存在該排程工作，內容是否惡意仍未確認 | 已停用該排程工作 | IT資安小組 | 送鑑定分析排程工作內容，08-18前出結果 |

【Incident Summary】
2026年8月16日23時07分起，帳號svc_vpn03遭連續41次VPN登入失敗嘗試，同日23時47分該帳號成功登入一次，來源IP非公司白名單範圍。8月17日上午，一名使用者回報於前一晚收到偽冒VPN驗證簡訊並輸入驗證碼，經比對該簡訊發送號碼確認為已知釣魚號碼。同日上午，三民店回報電腦出現異常提示視窗，經截圖比對疑似勒索軟體樣式，該電腦已隔離離線，鑑定結果待08-18前確認。IT技術人員於同日09:30在svc_vpn03筆電上發現不明排程工作並已停用，09:50已停用該帳號並強制重設密碼。造成事件之原因與責任歸屬待鑑定與調查後另行判定，不在本摘要範圍內。

【最大的3個未確認缺口】
1. 三民店電腦是否真的遭勒索軟體感染：若未釐清就對外說明，可能低估或高估事件嚴重度。
2. 排程工作的實際內容與行為：若未鑑定就假設是惡意程式，可能誤導後續處理方向。
3. 是否有其他使用者收到同批釣魚簡訊：若沒有全面追查，可能還有未發現的受害帳號。

請把以下規則，寫成一份可以直接用來建立共用「資安事件時間軸整理助手」的系統指令。

【系統指令要包含】
1. 角色與任務：只負責把零碎原始紀錄整理成Incident Timeline草稿與Incident Summary，不做調查、不判定攻擊者身分或責任歸屬。
2. 欄位規範：時間、事件、來源、已確認/未確認、已採取措施、Owner、Next Step七欄，Owner與Next Step一律留白或寫「待補」，由人另行指派。
3. 已確認/未確認判定規則：只有原始紀錄裡有明確文字或紀錄支持的項目才能標已確認，並附佐證出處；口頭轉述、電話、群組閒聊一律先標未確認。
4. 時間規則：時間有缺口、衝突、格式不一時，一律寫「時間不明」並註明原因，不得推算或估計。
5. 禁止事項（硬限制）：不得在任何欄位或摘要中出現攻擊者身分、動機、責任歸屬的推論字眼（如：疑似是、可能是、研判為外部/內部人士所為）；出現需求時一律回報「原因與責任歸屬待調查，不在本助手判定範圍」。
6. 待查證清單：每次輸出都要附上，列出未確認項目與具體要核對的內容。
7. 輸出格式：Incident Timeline表格 ＋ 待查證清單 ＋（若要求）Incident Summary摘要段落。

【另外請給我】
(a) 一份「使用說明」，給第一次通報事件的同事看，含三個好用法與三個誤用示範。
(b) 一份「維護說明」：多久要檢查一次這份規則有沒有跟上公司實際的通報流程、誰負責更新。

規則全文：{貼上}｜公司既有的事件分級/通報規範（如有）：{貼上}

（貼上規則全文，並附公司資安事件分級表：一級事件需2小時內通報主管、疑似個資外洩需依法72小時內評估是否通報主管機關）

【共用「資安事件時間軸整理助手」系統指令】

一、你的角色
你是本單位的資安事件時間軸整理助手。你只負責把零碎原始紀錄整理成Incident Timeline草稿與Incident Summary，不做調查、不判定攻擊者身分、動機或責任歸屬。

二、欄位規範
時間、事件、來源、已確認/未確認、已採取措施、Owner、Next Step。Owner與Next Step一律留白或寫「待補」，由人指派。

三、已確認/未確認判定
只有原始紀錄中有明確文字或系統紀錄支持的項目才能標已確認，並附佐證出處；電話、口頭轉述、群組閒聊一律先標未確認，需經人工佐證後才能升級。

四、時間規則
時間有缺口、衝突或格式不一時，寫「時間不明」並註明原因，不得推算或估計一個「合理」時間。

五、禁止事項
不得出現攻擊者身分、動機、責任歸屬的推論字眼。任何牽涉到「誰做的、為什麼做」的句子一律改寫成「原因與責任歸屬待調查，不在本助手判定範圍」。

六、待查證清單
每次輸出都要附上，列出未確認項目、需要核對的內容、建議由誰核對。

七、依公司分級規範提醒
若事件疑似涉及個資外洩，於輸出末段提醒使用者：「請依公司規範評估是否需於72小時內通報主管機關，此判定由法遵/主管進行，本助手不代為判定」。

──────────

【使用說明】
這個助手做什麼：把你手上的log、信件、電話逐字稿、對話紀錄整理成看得懂先後順序的時間軸草稿。
這個助手不做什麼：告訴你是誰做的、為什麼會發生、要不要對外究責。

好例子：
1. 貼上防火牆log與使用者回報信件，請它先排出時間軸。
2. 查證完幾個項目後，貼回查證結果請它更新已確認狀態。
3. 時間軸定稿後，請它產出200-350字的Incident Summary給主管看。

壞例子：
1.「幫我看這是不是外部駭客做的」——不是這個助手的工作。
2.「摘要寫得篤定一點，主管才會重視」——篤定意味著把未確認寫成已確認，不行。
3.「時間對不上，你幫我抓一個合理的」——一律寫時間不明。

【維護說明】
- 公司分級/通報規範異動時，第七節要同步更新。
- 每季抽查一次實際輸出，確認沒有身分/責任推論悄悄溜進摘要裡。
- 負責人：〔填寫〕。

07產出應該長什麼樣拿到的東西要長這樣

Incident Timeline表格（七欄）＋待查證清單；需要摘要時另附Incident Summary（200-350字）。

完成品：同一批紀錄的兩種整理：有沒有守住已確認/未確認的界線

【沒有守住界線】
AI產出（節錄）：
「事件經過：週日深夜疑似遭外部人士以暴力破解方式嘗試入侵VPN，並於凌晨成功登入，研判攻擊者隨後在使用者電腦植入惡意排程工作，可能與隔日使用者收到的釣魚簡訊為同一批攻擊行動。」

→ 讀起來很像一份完整的事件敘述。問題是：
→ 「疑似遭外部人士」「研判攻擊者」是AI自己接出來的推論，原始紀錄裡沒有任何一句支持「外部人士」這個結論。
→ 「可能與釣魚簡訊為同一批攻擊行動」把兩件時間相近但沒有直接關聯證據的事，寫成因果關係。
→ 這種寫法一旦被拿去呈報或通報，之後如果調查結果不是這樣，整份文件的可信度都會被質疑。

【守住界線】
AI產出（節錄）：
「2026-08-16 23:07至23:46，帳號svc_vpn03發生41次VPN登入失敗，23:47同帳號同IP登入成功〔已確認，佐證：防火牆log〕。2026-08-17上午，一名使用者回報前一晚收到疑似釣魚簡訊並輸入驗證碼〔未確認，僅憑使用者描述，簡訊發送方尚待核對〕。同日09:30，IT技術員於svc_vpn03筆電上發現不明排程工作並已停用〔未確認為惡意，內容待鑑定〕。造成登入成功與排程工作出現之原因、以及與簡訊事件是否相關，待調查後另行判定，不在本摘要範圍。」

→ 每一句都能回頭指出佐證在哪裡，也誠實標出還沒查清楚的部分。
→ 「兩件事是否相關」被清楚標成未確認、待調查，而不是被寫成一個順口的因果句。
→ 差別在哪：第一種在講一個聽起來合理的故事，第二種在講目前查證到什麼程度。前者好讀，後者才是能拿去做決策與呈報的東西。

| 時間 | 事件 | 來源 | 已確認/未確認 | 已採取措施 | Owner | Next Step |
|---|---|---|---|---|---|---|
| 2026-08-16 23:47 | svc_vpn03登入成功 | 防火牆log | 已確認〔佐證：log紀錄〕 | 尚未記載 | 待補 | 待補 |
| 2026-08-17 約09:02 | 三民店回報電腦異常 | 電話逐字稿 | 未確認〔僅口頭描述〕 | 尚未記載 | 待補 | 待補 |

【待查證清單】
1. 三民店異常視窗內容：需請店長補截圖，IT核對。

08工具怎麼挑

這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議，不是限定。

09會卡住與會做錯的地方

會卡住的地方（流程困難點）

時間戳記格式不一

系統log是UTC、信件是寄件時間、電話回報只有「大概下午三點」，排序前要先統一格式，不然順序會亂。

口頭轉述被當成第一手證據

電話或群組裡「聽說」「好像」的說法，如果沒有標明來源與可信度，會被誤讀成已確認事實。

AI順手補推論

時間有缺口、行為有模式時，AI很容易自己接出「可能是外部入侵」這類句子，看起來專業但沒有證據。

已確認/未確認的界線模糊

「系統紀錄顯示」跟「使用者表示」可信度不同，混在一起寫，沒人能判斷哪些能直接引用。

會做錯的地方（常見失敗方式）

其他注意事項

• 把電話或群組裡的「聽說」直接當成已確認事實寫進報告
• AI在時間有缺口時自己編一個合理的時間點
• 摘要段落裡偷偷出現「疑似是外部入侵」這類推論字眼

10人工把關與安全限制

AI／Agent／Tool 介入在哪幾步

這幾關不下放

已確認/未確認的最終判定

只有人看過佐證後才能把一則事件從未確認改成已確認。

攻擊者身分與動機

AI一律不判定，人也不能在審核時偷偷補上未經查證的猜測。

Owner與Next Step的指派

由主管或事件負責人指派，不是AI自動填。

通報範圍與時限

是否要通報主管機關、多久內要通報，由法遵或主管依法規判定。

最終發送前的審閱

時間軸與摘要在發出前，要有一個人確認沒有推論性語句才能發送。

安全與權限限制

原始紀錄先去識別化

帳號、客戶資料、內部IP在貼給AI前先代碼化，只留辨識事件所需的最低資訊。

電話逐字稿的保存

STT轉出的逐字稿本身也是紀錄，要跟其他原始資料一起歸檔備查，不能轉完就刪。

文件的存放與分享範圍

Incident Timeline可能含未公開的資安弱點資訊，存放與轉發範圍要限制在需要知道的人。

未確認項目不得外流

草稿階段標未確認的項目在核准前不對外發送，避免半成品被誤當定論引用。

法遵/司法保存要求

若事件可能進入保險理賠或司法程序，原始紀錄與各版本時間軸都要保留，不得覆蓋舊版。

11Checklist 與驗收標準

做的時候逐項打勾

• 每一列都有時間、事件、來源、已確認/未確認、已採取措施、Owner、Next Step七個欄位
• 已確認的項目都能指出對應的原始紀錄佐證
• 電話與口頭轉述未經佐證前一律標未確認
• 時間有缺口時如實寫「時間不明」，沒有被推算的時間
• 摘要裡沒有攻擊者身分、動機或責任歸屬的推論句
• 最終版本經主管或法遵審閱核准後才發送

做完了才檢查：全部成立才算完成

1. 每一列都有時間、事件、來源、已確認/未確認、已採取措施、Owner、Next Step七個欄位，沒有空白未標「待補」的欄位。
2. 已確認的項目都能指出對應的原始紀錄佐證。
3. 電話與口頭轉述的項目，未經書面或系統紀錄佐證前一律標未確認。
4. 時間有缺口或衝突的項目已如實標「時間不明」，沒有被推算的時間點。
5. 摘要段落沒有出現攻擊者身分、動機或責任歸屬的推論句。
6. 待查證清單已附上，且每項都指定了要跟誰核對。
7. Owner與Next Step由人指派，不是AI自動填入。
8. 原始紀錄中的個資與敏感資訊已去識別化。
9. 最終版本經主管或法遵審閱核准後才發送或歸檔。

12實際案例

13相關方法與下一步

可直接使用RELATED PROMPTS