Claude Projects 的工程化使用——不只是聊天记忆
Claude Projects 的工程化使用——不只是聊天记忆
适读人群：重度 Claude 用户，想提升使用效率的开发者 | 阅读时长：约14分钟 | 核心价值：Projects 功能的深度用法，从"记住对话"升级到"专业角色定制"
我第一次用 Claude Projects 的时候，觉得这功能挺鸡肋——不就是能保持聊天记录、上传几个文件嘛。
用了一段时间之后，我改变了看法。它鸡肋，是因为大多数人用法太浅。
我现在建了五六个专用 Project，每天会在不同的 Project 里切换。有些 Project 对我来说，已经像一个专属的工作搭档，能记住我的项目背景、我的偏好、甚至我的"历史踩坑"。
这篇文章把我的具体用法说清楚。
Projects 的核心能力
先把基础说清楚，很多人不了解 Projects 的完整能力边界。
独立的对话空间
每个 Project 有独立的对话历史，互相隔离。在"Java 代码审查"Project 里的对话，不会和"文章写作"Project 里混在一起。
Project Instructions（系统提示词）
这是核心功能。每个 Project 可以设置专属的 System Prompt（Instructions），这段文字会在每次对话时自动加入上下文，相当于给这个 Project 里的 Claude 做了专属配置。
Knowledge（知识文件）
可以上传文件作为 Project 的知识库。PDF、代码文件、文档都可以。Project 里的每次对话，Claude 都能访问这些文件。
对话历史上下文
Claude 能记住 Project 内的历史对话，不需要每次重新说背景。
我的 Java 代码审查 Project
这是我用得最久的一个 Project，配置也是最细的。
Instructions（系统提示词）：
你是我的 Java 代码审查专家，专注 Spring Boot 3.x 生态。
## 我的项目背景
- 后端技术栈：Java 17, Spring Boot 3.2, MyBatis-Plus, Redis, RabbitMQ
- 架构：微服务，约12个服务，用 Spring Cloud + Nacos
- 数据库：MySQL 8.0 + TiDB（部分大表已迁移）
- 团队：8人后端，经验参差不齐，有3年经验和10年经验的都有
## 代码规范（每次 Review 必须遵守）
- 构造器注入，禁止 @Autowired 字段注入
- 返回值统一用 Result<T> 封装
- Service 层抛业务异常，不返回 null
- 数据库操作必须考虑多租户 tenantId 隔离
- 金额字段必须 BigDecimal，不能用 double/float
## 你做 Code Review 的方式
1. 先总结代码的主要功能（1-2句话）
2. 按严重程度分级：[严重] [警告] [建议]
- [严重]：会导致功能错误、数据问题、安全漏洞的问题，必须修改
- [警告]：可能导致性能问题或维护困难，建议修改
- [建议]：优化空间，可以考虑
3. 每个问题给出：问题描述 + 修改后的代码示例
4. 最后给总体评价：能否合入主干
## 我的历史踩坑（这些问题在我们项目里出现过，特别关注）
- MyBatis-Plus 的 updateById 会更新所有字段，注意用 UpdateWrapper 指定字段
- Redis 缓存的 key 没有加租户前缀，导致租户数据混用
- RabbitMQ 消费者没有幂等处理，消息重试导致重复操作
- 事务里有 HTTP 调用，事务时长过长
- @Async 方法里的异常被吞掉了知识库文件：
我上传了几个文件：
- 我们内部的 Java 开发规范文档（PDF）
- 项目里几个复杂模块的架构设计文档
- 一份"历史问题汇总"的 Markdown 文件（每次出线上问题，我会补充进去）
使用方式：
提交 Code Review 请求时，我直接把代码粘贴进去或者上传文件。不需要每次说背景，因为 Instructions 里已经有了。
效果：Claude 给出的 Review 能识别出我们项目特有的风险，不只是通用的 Java 最佳实践。"[严重] updateById 会更新所有字段，这里应该用 UpdateWrapper 只更新 status 字段，否则会覆盖其他并发修改的数据" 这种问题，它会主动发现。
文章写作 Project
我每周写几篇技术文章，这个 Project 是专门为写作配置的。
Instructions：
你是我的文章写作助手，我是老张，写技术转型相关的微信公众号文章。
## 我的写作风格
- 第一人称，直接、口语化但有深度
- 开头必须是真实的个人经历或场景，不能是抽象论述
- 有明确的个人观点，不要"各有利弊，看具体情况"这种废话
- 代码示例要真实可运行，不能有未定义的占位符
- 禁用词：首先、其次、综上所述、总之、不言而喻、与此同时
## 文章结构偏好
- 开头：真实场景（100-200字）
- 主体：按逻辑递进，不是平铺罗列
- 代码示例：有注释，可以直接用
- 结尾：有具体结论，不是空话总结
## 我的读者
主要是做了5-15年的 Java 工程师，在做 AI 转型。技术基础扎实，讨厌废话，需要能直接用的东西。
## 你帮我写作的方式
- 改稿时，直接给修改后的版本，不要只说"这里可以改成..."
- 如果我的观点有错误，直接指出，不要委婉
- 标题建议时，给3-5个备选，不要只给1个
- 不要主动给我加 emoji我实际的使用方式：
我不让 AI 直接写文章。我的方式是：
- 先自己写一个粗糙的提纲（100-200字的要点列表）
- 把提纲发给这个 Project，让它提问："这个主题有什么地方你没说清楚？"
- 回答它的提问，补充细节
- 让它帮我整理成文章结构
- 我自己写正文（主要的事情还是我来做）
- 写完发给它审稿，重点让它找"废话、空话、逻辑跳跃"
- 根据反馈修改
这个工作流里，AI 做的是帮我理清思路、找问题，不是替我写。写出来的文章读起来还是我的语气。
RAG 调试 Project
这是最近新建的一个 Project，专门用来解决我做 RAG（检索增强生成）应用时遇到的问题。
背景： 我在维护几个 RAG 应用，核心技术栈是 LangChain4j + Elasticsearch + 自定义的 Embedding 服务。RAG 调试比普通应用调试难得多，因为问题可能在文档处理、向量化、检索策略、Prompt 设计的任何一个环节。
Instructions：
你是 RAG 系统调试专家。我的技术栈：LangChain4j（Java）, Elasticsearch 8.x 做向量存储, 自研 Embedding 服务（BGE-M3 模型）。
## 我的 RAG 架构
文档处理 -> 分块（固定大小 + 语义感知） -> 向量化（BGE-M3）-> ES 存储
查询时：向量检索 TopK + BM25 混合检索 -> RRF 融合 -> Rerank -> 送给 LLM
## 常见问题分类（你帮我调试时优先考虑这些）
- 召回问题：该找到的没找到（分块策略、相似度阈值）
- 精度问题：找到了一堆无关的（Rerank 权重、过滤条件）
- 答案质量：找到了但 LLM 没用好（Prompt 设计、上下文拼接方式）
- 幻觉问题：LLM 没有基于检索到的内容回答
## 我的调试习惯
我会给你：用户 Query + 检索到的文档片段 + LLM 的回答
你帮我分析：哪个环节出了问题，建议怎么调整
## 你不需要
每次都解释 RAG 是什么，我知道。直接进入问题分析。知识库：
上传了：
- LangChain4j 官方文档的 PDF（用于精确查询 API 用法）
- 我们 Embedding 服务的接口文档
- 一份"已解决的 RAG 问题案例"（Markdown 格式，持续更新）
使用体验：
调 RAG 的时候，我经常遇到"明明文档里有这个信息，但 AI 回答不出来"的情况。以前我要一步步自己分析：是分块没分好？还是向量相似度太低没召回？还是召回了但 Prompt 里没用到？
现在我把完整的调试信息发给这个 Project，它能快速定位到问题环节，给出具体的调整建议。因为它了解我的架构，不需要我每次解释技术背景。
一个被忽视的技巧：Knowledge 文件的更新机制
很多人上传了文件就不管了，但 RAG 调试 Project 里那份"已解决的案例"文件，我是定期更新的。
每次解决了一个复杂的 RAG 问题，我会在本地的 Markdown 文件里记录：
## 问题：用户问"合同签署时间"，但返回的是"合同生效时间"
**表现：** 两个时间在文档里相差2个段落，检索时把错误的段落排到了前面
**根因：** 分块时把一个合同模板的两个相关段落切断了，导致上下文丢失
**解决方案：**
1. 在分块时检测标题标记（## 开头的行），不在段落中间切断
2. 相邻段落有句子级语义相似度 > 0.85 时合并为一个块
**效果：** 上线后这类问题消失然后删掉旧版文件，上传新版。这个案例文件现在有30多个案例了，是我 RAG 开发经验的沉淀，也是这个 Project 能给出有效调试建议的重要来源。
Projects 的使用局限
不是所有场景都适合用 Projects，说几个我遇到的局限：
对话历史的"噪音问题"。 一个 Project 用了很长时间之后，历史对话里会有很多过时的信息。Claude 有时候会"记住"历史里的错误决策，给出和当前需求不符的建议。解决方式：定期清理 Project 内的历史对话，或者新建一个 Project 迁移（带上更新后的 Instructions 和知识文件）。
知识文件不是实时的。 上传的文件是某个时间点的快照，代码变了、规范更新了，要手动更新文件。这个要建立更新习惯，不然知识库会越来越过时。
同一 Project 里不要做差异太大的事情。 我见过有人把"代码审查"和"写周报"放在同一个 Project 里，然后 Claude 的角色感就乱了。不同的工作场景，建不同的 Project。
每个 Project 的 Instructions 字数有限制。 不要试图把所有规范全塞进去，写最关键的部分，太长了 Claude 会"选择性遵守"。
值得养成的习惯
建 Project 的时机： 某个场景的对话你要做超过3次，就值得建一个 Project。不要每次都重复说背景信息。
Instructions 要迭代。 用一段时间之后，你会发现 Claude 某些地方总是不符合你的预期，多半是 Instructions 没说清楚。把不满意的地方加进去。
知识文件的命名要清晰。 上传的文件名字要能说明内容，比如 团队Java规范_v3.pdf 比 规范.pdf 好，Claude 会用文件名帮助理解文件内容。
多个 Project 用不同对话风格。 我的代码 Review Project 里，我让 Claude 表现得很"严格"，不客气。写作 Project 里，更像一个聊天对象。这种角色分离让每个 Project 用起来更舒服。
Claude Projects 本质上是让你花一次成本配置好上下文，然后在每次对话里节省重复说背景的时间。用得越深，这个时间节省越明显。