本页目录
一份需求文档还没写完，又要开会话写架构设计，项目背景难道得再讲一遍？我用 ChatGPT Projects 把共同说明和参考文件放在一起，每条会话只负责一个任务。接着再换到 Cherry Studio，看看调用 API 模型时怎么接自己的知识库。
两条路都能减少重复交代背景，但不是同一套资料管理系统。下面先从我的文档编写场景走起，再讲具体配置与检查方法。
1. 文档多、规范多，先整理共同背景
我遇到的实际工作是医疗器械软件相关的资质材料整理。需求、产品研究和架构设计之间有依赖，还要参考软件需求规范，单独写每份文件时很容易漏掉共同条件。
适合先放进项目的内容，可以这样分：
| 内容 | 放在哪里 | 用途 |
|---|---|---|
| 产品背景、写作要求、任务边界 | 项目指令 | 让不同会话遵循共同要求 |
| 规范、产品说明和已有文档 | 项目文件 | 提供可引用的依据 |
| 某一份文档的起草与修订 | 单独会话 | 保留该任务的修改过程 |
这里的医疗器械只是我的工作场景，方法也可以用于其他文档项目。不过监管材料的生成稿需要专业人员逐条审阅；上传前确认授权并脱敏，不把真实患者或客户信息拿来做公开示例。
2. 创建 Projects，写指令，再上传文件
- 打开 ChatGPT，在项目入口选择新建项目，填一个容易识别的名称。
- 打开项目的指令设置，说明产品背景、需要编写的材料及回复要求，保存。
- 在同一项目中添加参考文件，等待上传完成，检查文件列表。
- 从项目内开始新会话，交代本次具体任务，不必把共同背景重复写一遍。
项目指令可以简洁，但要有明确边界。例如下面是供你调整的示例，不是提交材料的专业规范：
本项目用于整理一个软件产品的技术文档。
以提供的产品说明和规范为依据，不补造参数或测试结果。
起草时标明依据；缺少必要资料时先提问。
每条会话围绕一个交付物，最终内容由负责人审核。我这次使用的桌面客户端没有上传入口，于是通过网页端添加文件，再切回同一项目刷新确认。这个做法解决了那次界面差异，不代表现在桌面端一直不能上传；遇到入口不同，先检查当前版本和实际项目，不必反复新建。
3. 一条会话写需求，另一条写架构
资料准备好后，先在项目内开一条会话，要求起草需求文档，并明确应参考的规范文件。生成后核对章节、引用和例外条件，再在这条会话中继续修订。
接着新开一条会话写架构设计，让它引用同一组项目资料。这样需求的修改过程和架构的修改过程各自清楚，不会挤在一条超长聊天里。
我测试时，回答提到了已上传的软件需求规范，也把参考资料中的业务信息带进了架构稿。提到文件名不等于符合规范：要回到原文检查它是否选对版本、漏了条件，或者补了资料中没有的数据。
广告
演示界面的模型选择也有版本差异。看不到选择器，不能据此推断产品一定在后台切换成某个具体模型；使用时看当前产品说明和可选项，不靠答案风格猜型号。
4. 全局变化改项目指令，具体修订留在会话
如果产品共同背景变了，例如客户端界面数量或数据保存方式调整，更新项目指令与参考文件；某份文档的措辞、章节和细节，则继续在对应会话里修改。
更新共同说明不会自动重写已经生成的文档。改完之后主动让各任务重新核对受影响章节，保存确认后的结果。项目文件、对话记录和最终交付物有不同用途，不把一段旧回答直接当作已经同步的最新版。
涉及共享和敏感资料时，还要核对当前项目权限与记忆设置。项目名像文件夹，不代表访问范围和上下文边界已经符合组织要求。
5. API 方案：Cherry Studio 先检索，再交给模型
另一条路是第三方客户端。这里用 Cherry Studio 知识库搭建中的资料做演示：先建索引，再让 OpenAI 模型参考检索结果回答。
- 在 Cherry Studio 知识库中导入非敏感测试文件，确认嵌入处理完成。
- 用知识库搜索查一个文件中特有的概念，确认命中正确段落。
- 打开 设置 → 模型服务 → OpenAI，配置自己的 API Key 和可用模型。
- 新开会话，选择对应模型，再选择刚建好的知识库。
- 提问并打开回答中的引用，对照来源核验。
我用一份视频标题文档中的“切入口”概念测试，API 模型的回答带出了对应资料。你可以换成自己的术语手册，最好选一个没有原文就容易答偏的问题。
这里是客户端管理与检索知识库，再调用模型 API，不是一次 API 调用自动给所有文件建立永久记忆。ChatGPT 的订阅与 API 费用也不能混算；嵌入与生成各用哪家服务，分别看客户端配置。
如果需要平台托管检索，可另行评估 OpenAI File search。它不是本文客户端实验里已经部署的部分，不应把两套系统的存储、计费和权限混在一起。
让资料可复用，让结果可审查
Projects 更适合围绕同一项目管理共同说明与多条任务；客户端加 API 则让你自行选择生成模型和检索链路。无论选哪条路，都要检查文件版本、引用原文和缺失条件，而不是只看回答是否“很懂我”。
先拿一份公开手册做小测试，再决定要不要迁入更多资料。你最想减少哪类重复工作：需求文档、工作规范，还是知识整理？欢迎分享经验，评论里不要贴客户文件或 API Key。感谢阅读，也期待看到你把这套方法用在真正的项目中。
广告
