从聊天到工作空间：组织资料、上下文与交付物
理解 Projects、Artifacts 与上下文，组织一项持续工作。
一个项目讨论了几十轮，最后却找不到哪份需求是最新版；AI改完表格，又把上周已经否定的方案写了回来。这类问题往往发生在资料组织，而不是模型能力。
工作空间的价值，是让一项工作的依据、决定和产物有稳定位置。
Projects、Artifacts、文件目录和记忆功能只是不同载体。先分清信息的职责，再选择放在哪里，才能避免把聊天记录当成唯一项目档案。
01 / 定义：资料、规则、状态与产物
| 信息类型 | 回答什么 | 例子 |
|---|---|---|
| 来源资料 | 依据从哪里来？ | 访谈原话、原始CSV、历史需求 |
| 稳定规则 | 每次都应遵循什么？ | 字段口径、品牌用语、权限边界 |
| 当前状态 | 现在做到哪里？下一步是什么？ | 已通过检查、待确认项、阻碍 |
| 交付产物 | 别人具体拿什么使用？ | 报告、代码、原型、演示文件 |
同一段话可以讨论多次，但一个决定应只有一个现行正文。若聊天说最多导出1000条、需求文档写500条、测试又按2000条验收，AI无法替你判断哪一份代表真实业务决定。
02 / 推导：存进项目，不代表每次完整读到
应用可能直接提供资料，也可能只检索相关片段。长文可能被压缩，旧对话不一定自动进入新会话。因此“已经上传”只是存储事实，“本次使用了正确内容”需要另外确认。
- 先给资料编号和版本，避免同名文件含义不同。
- 明确哪份是当前规则，哪份仅作历史参考。
- 执行时指明相关文件与章节，减少无关材料竞争注意力。
- 完成时核对版本和关键字段，而不是相信“我已阅读全部资料”。
图中结果回到状态文件，原始资料不被覆盖。这样下一轮既能继续，也能追溯“这个结论最初依据什么”。
03 / 应用：整理一个导出功能项目
① 建立四个位置
export-project/
source/ 原始访谈与数据
product/ 当前需求与验收标准
work/ 草稿、代码或原型
STATUS.md 当前结果与下一步
目录名不是强制标准，职责才是。用 Claude Projects 时，可以把现行规则和相关资料放入项目知识，项目指令只写共同约束与资料入口。不要把产品按钮当成自动同步所有外部文件的承诺。
② 写一份简短的入口说明
目标：完成管理员导出当前筛选结果的原型。
当前规格：product/export-v2.md；旧版仅作对照。
统计口径：按订单编号去重，最多1000条。
原始资料：source/只读，不能用草稿覆盖。
本次输出：work/export-demo.html与检查记录。
完成后更新STATUS.md，列出产物、验证与未完成项。
③ 把可展示内容与正式数据分开
Artifacts 类载体适合预览交互界面、图形和文稿。看到一个可点击界面，不代表它已经连接数据库、保存了数据或完成部署。若是本地演示，应说明数据来自演示数组，刷新是否重置也要能解释。
④ 留下可以恢复工作的状态
# 当前状态
已完成：筛选、导出按钮、1000条上限提示。
已验证：空结果与超限提示；浏览器窄屏无横向溢出。
未验证：真实权限与生产数据接口。
下一步：使用三种角色检查数据范围。
有效产物：work/export-demo.html
状态写结果，不抄长聊天。它要让下一次会话可以开始正确工作，而不是要求接手者重新理解整个讨论过程。
04 / 验收：用一次新会话检验组织是否有效
- 新开会话，仅提供入口说明和状态文件。
- 让 AI 复述当前规则、产物位置和未验证事项。
- 要求它指出1000条上限的来源，确认没有使用旧版。
- 做一个小改动，例如调整提示文案，再检查是否误改原始资料。
- 打开输出，核对状态描述与真实页面一致。
如果恢复时缺关键决定，把它写回有效规格；如果总要加载几十份文件才能找到一条规则，缩短入口路径。不要因此把所有内容复制进一个越来越长的指令文件。
项目记忆应服务于恢复和核查。重复保存同一规则会制造多个版本，反而让下次判断更困难。
05 / 迁移：从一个目录到团队资料库
团队里需要进一步明确维护人、访问范围、资料生效与失效机制。删除源文档之后，旧检索索引和生成摘要是否仍可访问，也属于资料生命周期。更大规模的检索见上下文、检索与 RAG。
把所有历史聊天放进项目知识，是不是最完整？
完整归档和有效输入不是一回事。保留历史便于追溯，但当前任务应优先读取生效规则、相关证据和未解决问题；被否定的方案应明确标为历史，而不是和现行规则并列。
当一个协作方法在多个任务里稳定重复，再考虑把方法抽成Skill。资料回答“依据什么”，Skill回答“怎样处理”，两者可以配合，但不必互相替代。