要整理 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