要整理 AI 對話和項目，先為每個項目訂定一個目的和一位負責人，再把參考事實、常設指令、可重用的 Prompt 範本和臨時對話分開。只把經覆核的輸出提升為長期脈絡，控制誰能看到上載的材料，並在工作區的前提假設過時後封存或重建。

這是管治流程，不是教你寫每條 Prompt 或項目計劃的指南。個別要求請參考寫好 AI Prompt，里程碑和依賴請參考 AI 項目規劃流程。

關鍵要點

一個項目應只有一個長期目標、範圍和一位負責人。

事實、指令、範本、對話和已批准的輸出需要不同的生命週期。

很長的聊天紀錄並不等於知識庫。

共享項目可能令協作者看到其中的檔案、對話和指令。

在過時脈絡變成隱形規則之前，覆核、匯出、刪除或重建。

如何整理 AI 對話和項目？

多段對話需要相同的已核實來源、指令、術語或交付標準時，使用項目；脈絡不應保留的短期問題，用一般對話。

各平台實現項目的方式不同。ChatGPT Projects 可以容納對話、檔案、指令、分享設定和項目記憶；把對話移入項目後，它會承繼該項目的指令和檔案脈絡。［1］ Claude Projects 使用項目知識和項目指令，Anthropic 亦指出，除非加入項目知識，否則脈絡不會在不同對話之間共享。［2］這些細節可能改變，依賴某項具體的分享、記憶、匯出或刪除行為前，先查閱現行官方文件。

讓資訊模型獨立於介面。如能把項目匯出為一個簡單的資料夾，包含 README、來源登記表、指令檔、Prompt 範本、決策紀錄和封存，工作區便不太依賴某個供應商現時的選單。

第一步：以目標、範圍和負責人開始 AI 項目整理

上載檔案之前，先寫一份項目章程：

欄位	檢查問題
目標	這個工作區要支援甚麼可重複成果？
範圍內	哪些產品、團隊、日期、地區或文件類型屬於項目？
範圍外	哪些決定或數據必須留在其他位置？
負責人	誰批准指令、來源、成員和封存？
驗收	甚麼條件令輸出可在聊天以外使用？
覆核日期	何時必須重新檢查事實和存取權？

避免把項目命名為「工作」或「AI 雜項」，這會累積互不相容的目標和隱藏假設。較好的名稱是 customer-onboarding-sop 或 q3-research-brief，再加一句說明目的。

兩項交付成果的負責人、保密級別、受眾或覆核周期不同時，便把它們分開。共用術語不足以成為合併項目的理由。

第二步：分開五類脈絡

把每一項放進正確的層級：

**參考事實：**已批准的政策、來源文件、定義、數據字典和已核實的限制。
**項目指令：**關於範圍、語氣、證據、私隱和輸出驗收的長期規則。
**Prompt 範本：**用於重複工作、附參數的操作程序。
**臨時對話：**探索、提問、被放棄的做法和未經覆核的草稿。
**已批准的輸出：**經人手覆核、可成為日後工作輸入的成果。

不要把可重用的 Prompt 貼進事實層。不要把模型生成的摘要當作已批准的來源。也不要只因某次腦力激盪出現在對話早段，便把它變成常設指令。

以文件為主的工作，可透過文件摘要流程產生摘要，但在任何被提升的摘要旁，都要保留原始文件、日期、範圍和覆核人。

這張圖描述的是資訊的角色，並不聲稱每個平台都提供相同的資料夾或控制選項。

第三步：為可重用 AI Prompt 建立命名、版本和封存規則

簡單的慣例便能令脈絡易於查找，而不必依賴模型記憶：

{project}-{artifact}-{status}-v{major.minor}-{date}

例如，onboarding-source-register-approved-v1.2-20260824 能把一份經覆核的登記表，與一段標題為「最新來源」的對話區分開。使用一小組狀態詞，例如 draft、review、approved、superseded 和 archived。

範本的版本要與每次執行分開管理。一條可重用的 Prompt 可以叫 vendor-comparison-template-v2.1；每次完成的使用都應記錄範本版本、輸入、日期、模型或工具、覆核人和輸出位置。否則無法判斷兩個結果是否遵循同一程序。

以封存取代把舊材料改名為「最終版-最終版」。被取代的項目應指向它的替代品，替代品則應說明改了甚麼。除非保存規則要求，否則不要只為令工作區顯得整齊而刪除決策證據。

第四步：只把已覆核成果提升為長期脈絡

對話是工作記憶，當中有不完整的問題、幻覺、已更正的錯誤，以及從未被選用的方案。把整段對話存為權威脈絡，等於讓模型重用被捨棄的材料。

使用一道提升關卡：

確定候選的事實、指令、範本或輸出。
對照原始來源或負責人檢查。
刪除沒有依據的主張和敏感材料。
加上負責人、來源、版本、生效日期和覆核日期。
把它放進正確的長期層級。
把原對話標示為輔助歷史，而不是權威依據。

當確實措辭、日期或例外情況很重要時，已批准的摘要不應取代來源。維護一份來源登記表，記錄 URL 或檔案識別、發布者、核對日期、適用範圍和已知局限。

第五步：控制成員、上載和敏感資料

分享之前，假設協作者可能看到項目中的對話、檔案、指令和成員資料。OpenAI 現行的 Projects 文件說明，共享項目的成員可以查看對話和檔案，其權限會影響編輯和邀請。［1］ Anthropic 記錄了工作方案中項目的可見度和權限級別。［2］請按你的方案和機構查閱現時確實的行為。

採用最低權限：

只邀請需要這個項目的人；
把機密工作與廣泛共享的指引分開；
盡快移除已離開的成員；
在可以使用具名邀請而又合適時，避免使用分享連結；
檢查上載檔案中的個人資料、密鑰、法律限制和客戶保密資料；
記錄誰批准上載以及預期的保存期限。

OpenAI 的資料控制文件介紹了模型改進、匯出、帳戶刪除和臨時對話等設定。［3］訓練開關並不等於完整的保密政策。僱主的帳戶條款、保存設定、管理員控制、連接器、法律責任和平台方案仍然重要。加入敏感資料前，請閱讀 AI 私隱風險指南。

第六步：處理過時事實、衝突指令和脈絡污染

按風險和變化速度安排項目覆核。平台文件、價格、法律、人員、產品能力、限期和營運指標都會很快過時；穩定的寫作規則可較少覆核。

覆核時，問以下問題：

哪些事實已超過覆核日期？
有否兩條指令對同一決定作出不同規定？
某個範本是否假定了已停用的流程或欄位？
未經覆核的輸出是否與已批准的來源存放在一起？
前成員是否仍能存取項目？
模型是否反覆引用一段舊對話，而不是現行來源？

明確解決指令衝突。使用優先次序，例如：機構政策、項目章程、已批准的任務指令，最後才是臨時的用戶要求。記錄某條規則為何取代另一條，而不是不加說明地刪去被取代的規則。

NIST 的生成式 AI 風險概況強調在 AI 生命週期中進行管治、來源追溯、監察和評估。［4］對小型團隊而言，這表示具名負責人、來源紀錄、定期覆核、存取檢查，以及輸出在重用前已被評估的證據。

第七步：有目的地匯出、刪除或重建

需要可攜性、審計證據、政策容許的備份，或要交接給另一位負責人時，進行匯出。一份有用的匯出包含：

項目章程和負責人；
現行指令；
來源登記表和已批准的檔案；
附版本的可重用 Prompt 範本；
決策和變更紀錄；
已批准的輸出及其覆核人；
仍未解決的問題；
在容許的情況下，成員和保存說明。

當保存期已結束、資料誤傳、存取無法控制，或政策要求移除時，進行刪除。確認刪除涵蓋的範圍：對話、檔案、記憶、項目、匯出、已連接的來源或服務供應商端的保存，可能各有獨立控制。OpenAI 現行的 Projects 文件說明，刪除項目會移除其檔案、對話和指令，而且無法復原；但操作時仍須核對平台行為和機構的保存規則。［1］

當項目出現大範圍的指令衝突、來源出處不明、保密級別混雜，或過時歷史多到逐項修復反而不可靠時，進行重建。由經覆核的匯出建立一個乾淨的新項目；不要把整段舊對話歷史複製回去。

小型 Prompt 登記冊

把每條可重用的 Prompt 存為一套附欄位的程序，而不是一段「神奇」的文字：

欄位	用途
名稱和版本	區分程序與某次聊天執行
任務和非目標	防止範圍漂移
必需輸入	讓缺失事實可見
准許來源	控制證據和保密邊界
輸出格式	令覆核可以重複
失敗行為	缺少資料時停止而非編造
覆核人和測試	定義輸出如何獲得批准

用一個常規個案、一個邊界個案和一個欠缺輸入的個案測試範本。如它只在操作者記得隱藏指令時才能運作，便仍算不上可重用。

每月進行脈絡健康檢查

採用簡短、可重複的覆核，而不是等到明顯出錯才處理。抽取一份近期輸出，把其中每項持久主張追溯到現行的來源登記表。檢查平台顯示的項目指令是否與匯出的已批准副本一致。把成員名單與現時團隊名單比較，並確認每個上載檔案仍有有效的用途和保存依據。

然後檢查範本登記冊：停用重複的 Prompt，更新那些包含舊假設的例子，並確認欠缺輸入時仍會安全地停止。覆核仍未解決的決定，要麼指派負責人和限期，要麼把它們移出使用中的脈絡。最後，在政策容許時匯出覆核後的狀態，並記錄下一次覆核日期。

這項檢查應產出一份小型變更紀錄，而不是整個工作區的又一份 AI 摘要。證據是覆核者實際檢查過的來源、指令、存取和版本紀錄。

總結

為每個項目訂定目標、範圍、負責人、驗收規則和覆核日期。
把事實、指令、範本、臨時對話和已批准的輸出分開。
為 Prompt 做版本管理，並封存被取代的材料，保留可追溯的替代關係。
按現行平台和機構規則控制成員和敏感上載。
在過時脈絡變成隱形的「事實來源」之前，匯出、刪除或重建。

常見問題

每個主題都要建立項目嗎？

不需要。當多段對話共用持久的來源、指令、負責人和覆核規則時，才建立項目。不應成為長期脈絡的獨立工作，使用臨時對話。

長聊天紀錄就是項目知識嗎？

不是。對話包含未經覆核的草稿和被捨棄的想法。只把經覆核的事實或輸出提升到一個標示清楚的長期層級。

可重用 Prompt 應怎樣命名？

使用以任務為本的名稱加版本號，例如 policy-comparison-v1.3。記錄必需輸入、輸出格式、失敗行為和覆核人，而不是只依賴標題。

可以複製另一個項目的指令嗎？

只有在檢查過範圍、負責人、保密級別、術語和優先次序後才可以。相同的措辭可能掩蓋對新項目並不適用的規則。

項目指令互相衝突怎麼辦？

暫停受影響的工作，找出兩條指令及其負責人，應用已記錄的優先次序規則，並記錄處理結果。不要讓模型決定政策。

多久覆核一次工作區？

按風險和變化速度訂定頻率。變化快的平台事實和權限要比穩定的風格指引更頻密地覆核；在重要的重用或交接之前，一定要覆核。

刪除聊天會刪除所有副本嗎？

不一定。這些資料也可能存在於檔案、項目知識、記憶、匯出、已連接的來源、已批准的輸出或保存系統中。請核對現行的平台和機構規則。

何時重建比清理更好？

當出處不清、指令大範圍衝突、保密界線混雜，或過時的脈絡無法可靠分開時，進行重建。只由經覆核的來源和已批准的指令開始。

延伸閱讀：

免責聲明：平台項目、記憶、分享、保留和資料控制功能會改變。依賴任何控制前，請核對最新官方文件、方案設定、機構政策及適用法律。

來源：

OpenAI — Projects in ChatGPT — https://help.openai.com/en/articles/10169521-projects-in-chatgpt
Anthropic — How can I create and manage projects? — https://support.anthropic.com/en/articles/9519177-how-can-i-create-and-manage-projects
OpenAI — Data Controls FAQ — https://help.openai.com/en/articles/7730893-data-controls-faq
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 8 月 24 日。

如何整理 AI 對話和項目：分層管理事實、指令與可重用 Prompt