如何真正设置 Claude Projects（大多数人不知道的完整课程）

大多数人都不了解的 Claude Projects 正确设置方法——完整教程 2026 年 7 月 8 日 · 16 分钟阅读 · 查看原文 ↗ Claude 营销 自动化 AI 大多数人把 Claude 当成一个搜索框来用。 每一次会话的开头都一模一样。你是一名营销文案写手。我的业务是这个。我的受众是那个。现在给我写出来。然后你关掉标签页，第二天又从零开始，把整个简报重新讲一遍——每天早上训练同一个员工，然后让他到晚上就把所有东西都忘光。 那不是一个工作流程。那是永远从零开始。 Claude Projects 解决了这个问题，但几乎没有人正确地设置它。大多数人只是创建一个项目，粘贴一行指令，丢进去一个随机的 PDF，然后奇怪为什么它并没有比普通聊天好到哪里去。它的威力是真实的，但它藏在设置界面不会告诉你的那些细节里。 这是一门完整教程，教你如何像真正依赖 Projects 的人那样去设置它。这里的每一项功能都是真实且最新的。到最后，你会拥有一个能把完整上下文自动加载进每一次对话、永远不需要重新简报、并且产出的内容听起来像你本人而不是一个通用助手的项目。 一个项目到底是什么 剥掉营销话术，一个 Claude Project 就是把三样东西捆绑在一个持久工作区里。 自定义指令。一个系统级提示词，自动应用于项目内的每一次对话。这是一份长期有效的简报，决定了 Claude 的行为方式、它以为自己在跟谁说话、以及它遵循什么规则——而这一切都不需要你把它输入到聊天框里。 知识库。Claude 可以在每一次对话中参考的文件和文档，随时可用，永远不需要重新上传。风格指南、规格说明、过往作品、参考资料。 有作用域的会话。项目内的所有聊天都归为一组，并继承相同的指令和知识。 有一件重要的事需要一开始就理解，因为它会不断让人踩坑。项目内的会话之间不会互相共享消息历史。共享的状态是指令和文件，而不是聊天记录。每一个新会话都只加载这两样东西，从零开始。这一点决定了你下面要如何设计所有内容。 Projects 在 Claude 的每一个套餐上都可用，包括免费版，不过免费用户被限制为最多五个项目，而且项目指令这一功能本身是付费功能。在 Pro、Max 和 Team 上，你可以获得完整的设置。 几乎所有人都会犯的错误 在开始设置之前，先理解这个最大的错误，因为避开它就已经赢了大半。 人们把知识库当成储物柜。他们把什么都往里塞。整本品牌手册。六个月的会议记录。一份四十页的战略文稿。这个逻辑听起来很合理：上下文越多，产出越好。 事实并非如此，原因如下。项目知识并不会完整地加载到每一次回复中。Claude 通过检索，按查询拉取最相关的内容。当你用大量松散相关的材料塞满知识库时，你就稀释了 Claude 找到真正关键信号的能力，而且你还要冒着把上下文窗口塞满文件的风险，给真正的对话留下更少的空间。 能显著提升产出的那条规则，恰恰和人们预料的相反。让每一份知识文档都保持紧凑而具体，大约一到三页。一份三页的品牌语气指南，每次都能胜过一份四十页的品牌手册，因为有用的信号更密集，噪音更低。在知识库里，精准永远胜过数量。 第一步：带着真正的意图创建项目 打开 Claude，点击侧边栏里的 Projects，点击 New project（新建项目）。 名字比你想象中更重要。给它起一个具体的名字。"Newsletter"（简报）或"Client Proposals"（客户提案）或"API Documentation"（API 文档），而不是"Work"（工作）或"Stuff"（杂项）。原因在于，你最终会拥有多个项目，而整个意义就在于区隔。一个模糊的名字会导致一个模糊的项目，它会慢慢累积不相关的垃圾，这正是上面说的稀释问题。 这就引出了大多数人忽略的第一条原则。一个项目对应一个关注点。不要把后端代码和营销内容放进同一个项目。不要把客户 A 和客户 B 混在一起。分开的项目意味着更干净、更聚焦的上下文，而聚焦的上下文正是项目能起作用的全部原因。想要搞一个包罗万象的超级项目的冲动，正是你当初想逃离的那个通用聊天机器人所诱惑你的冲动。 第二步：像写长期简报一样写指令，而不是写提示词 这是整个设置中杠杆最高的一环，也是弱项目和好项目之间差距最大的地方。 一个薄弱的指令块写着"你是一个会写营销内容的乐于助人的助手。"这没有给 Claude 任何它原本没有的东西。 一个强大的指令块，是一份写给一个还完全不了解你的人的完整长期简报——因为这就是项目里每一次新对话开始时的真实处境。它应该涵盖：你是谁、你做什么，这个项目存在的首要任务是什么，你的语气和风格偏好，你要求的输出格式，Claude 应当默认掌握的专业领域知识，以及最关键的一点——Claude 永远不应该做的事。 下面是一个适用于几乎所有项目类型的模板结构： 角色（ROLE） 你是[具体角色]，从事[具体领域]。你在为 [对他们一无所知的具体受众]写作。 这个项目是干什么的（WHAT THIS PROJECT IS FOR） 这里的主要任务是[任务 1]、[任务 2]、[任务 3]。除非另有说明， 否则默认每一次请求都与其中一项相关。 如何回应（HOW TO RESPOND） 语气：[具体]。格式：[具体]。长度：[具体]。 除非真的被卡住，否则不要问澄清性问题。做一个合理的 假设，说明它，然后继续。 应当默认什么（WHAT TO ASSUME） [领域事实、产品细节、定位——在每一次回复中都应该 被视为既定前提的内容。] 绝不（NEVER） [Claude 在这个项目中永远不应该做的具体事情：AI 陈词滥调、 某些断言、某些格式，凡是你的硬性规则都算。] 那条关于"不要问澄清性问题"的指令值得单独点出来。默认情况下，Claude 常常会以一轮"在开始之前，你能不能告诉我更多关于……"开头。对于一个你每天都在用的项目来说，这种开场白纯粹是摩擦。告诉它做一个合理的假设、说明它、然后继续，就能消除这种来来回回，立刻加快每一次会话。 为那个跟你毫无历史记录的读者写这些指令，因为每一次新对话都真的从那里开始。指令和文件是唯一会延续下去的东西。你上一段对话的记忆不会。 第三步：精准地构建知识库 现在到文件了。记住那条规则。紧凑、具体、每份一到三页。以下是一个构建得当的知识库里真正该有的内容，以内容项目为例。 一份语气与风格指南。你如何写作。句子的节奏、你用哪些词、你禁用哪些词、你产出的感觉。 一份受众文档。你在为谁写作，他们关心什么，他们已经知道什么，他们对什么持怀疑态度。 一份支柱或范围文档。这个项目覆盖的具体主题或类别，好让 Claude 保持在轨道内。 一小批最佳范例。三到五篇你真正最好的作品。用示范来教学远比用描述有效。Claude 从真实范例中学习你的模式，效果胜过任何数量的指令。 与这项工作相关的参考资料。SEO 笔记、产品规格、技术约束，凡是该领域所需的都行。 给每个文件起一个描述性的名字。"Brand Voice Guide v3"（品牌语气指南 v3）、"Q2 Product Roadmap"（Q2 产品路线图）、"API Documentation Payments Module"（API 文档支付模块），而不是"notes"（笔记）或"stuff"（杂项）。描述性的名字能帮助检索为正确的查询调出正确的文档，而这正是你依赖的整套机制。 值得知道的限制。在 Pro、Max 和 Team 上，每个项目最多 20 个文件，每个文件 30MB，支持 PDF、文本、markdown、代码文件、CSV 和图片。只要遵循精准规则，这就绰绰有余。如果你撞到了上限，问题几乎总是你在上传数量而不是信号。 第四步：在信任检索之前先测试它 这一步几乎没有人做，而它正是"以为项目能用的人"和"知道项目能用的人"之间的分水岭。 上传完知识之后，在项目里开一个对话，明确测试 Claude 能否检索到每一份文档。直接问： 基于项目知识里的 Brand Voice Guide（品牌语气指南），我应该如何 写一篇文章的开头第一句？请引用你正在使用的具体指导。 如果 Claude 准确地引用了文档，说明检索在工作。如果它给出一个泛泛的答案，或者找不到那份指导，那就有问题了。也许是文件没有处理成功，也许是命名太模糊，也许是这份文档被埋在了太多其他文档之下。宁可在一场测试中发现这个问题，也不要三周之后才发现 Claude 其实从来都没有读过你最重要的那份文件。 对每一份关键文档都跑一遍这个测试。它只要五分钟，而这就是"一个你希望它能用的项目"和"一个你知道它能用的项目"之间的区别。 第五步：为每一次对话选择正确的模型 一个大多数人彻底忽略的细节。在项目内部，你可以为每一次对话独立选择使用哪个 Claude 模型。项目并不会把你锁死在某一个模型上。 这关系到成本和质量的平衡。对于项目里常规的起草工作，用更快的模型；对于那些需要深度推理或复杂综合的对话，切换到能力更强的模型。同一个项目、同样的指令、同样的知识，只是根据具体任务的需求换不同的引擎。大多数人从来都不知道自己能这么做，结果要么把一切都跑在最顶级的模型上而多花了钱，要么把一切都跑在快速模型上而表现不佳。 第六步：把会话当作思考，而不只是任务 这里有一个习惯，会随着时间推移悄悄让项目变得更强大。 不要只用项目会话来完成收尾任务。用它们来出声地思考。梳理一个问题，解释你的推理，讲清楚你为什么要做某个决定。因为项目是有作用域且一致的，这些思考型会话能帮助 Claude 理解你的推理模式，而不仅仅是你的产出模式。 结果就是，几周之后，在一个被充分使用的项目里，Claude 开始不仅匹配你的格式，还匹配你的判断。它会提出符合你真实思考方式的方案，因为它已经在这个有作用域的情境里见过你是如何思考的，而不仅仅是你生产了什么。 第七步：维护它，因为一个项目只和它的文件一样新鲜 项目不是一设了之。它只和里面的内容一样准确，而过时的知识会产生自信满满却错误的情境，这比没有情境更糟。 建立一个维护习惯。当你的定位变了，就更新语气指南。当规格被修订，就替换掉旧的那份。当策略转向，就更新范围文档。每季度回顾一次你的项目指令，因为六个月前写的指令现在可能正积极地与你正在做的事相矛盾，而 Claude 会忠实地遵循那条过时的规则。 能持续保有价值的项目，是那些人们持续更新的项目。会悄悄变得没用的项目，是那些设置过一次就再也没碰过、而真实的工作已经在它周围继续前行的项目。 新的一层：Cowork 项目 值得知道，因为它极大地扩展了上面的一切。根据 2026 年的更新，Projects 如今也存在于 Claude Cowork（桌面端 agentic 应用）之中，而这一版本增加了基于聊天的项目所没有的能力。 Cowork 项目增加了在会话之间持久存在的有作用域记忆，所以你可以说"在上周的报告基础上继续"，而 Claude 清楚地知道那是什么，同时又不会把那段上下文泄露到你的其他工作中。它们增加了专用的本地文件夹，所以项目会在你的机器上读取和写入真实文件。它们还增加了计划任务，所以项目可以按你设定的节奏自动运行重复性工作。 设置逻辑和上面的一切完全相同。清晰的指令、紧凑相关的文件、一个项目对应一个关注点。但天花板更高了，因为 Cowork 项目不仅仅是为对话提供信息，它会针对真实文件执行工作，并且可以在没有你的情况下按计划运行。一个不错的起步动作是把它指向一个文件夹，然后说： 读取这个文件夹里的每一个文件。然后总结你对这个工作区了解到的 一切：这里有什么，我大概用它来干什么，以及你将遵循哪些指令。 如果有任何不清楚的地方，在擅自假设之前先问。 这一条命令就能让 Claude 在第一天学会这个项目，从那一刻起它就会记住。 你今天就能搭起来的四个项目模板 理论只有落地之后才有用。下面是四个直接映射到最常见用例的项目设置，每个都标明了什么该放进指令、什么该放进知识库，这样你就可以直接复制这个结构。 内容项目。指令定义你作为某类受众的写作者的角色、你的语气、你的排版规则和你的硬性禁令。知识库里放一份语气指南、一个受众画像、一份支柱文档，以及三到五篇你表现最好的作品。这就是那个能让你发布的每一篇东西都始终听起来像你本人、而不是每次换一个写手的项目。知识库里的最佳范例在这里比任何指令都更管用，因为语气是"熏"出来的，不是"教"出来的。 代码项目。指令定义你的技术栈、你的约定、你偏好的模式，以及你永远不想被做的事。知识库里放一份架构文档、你的关键源文件、你的编码规范，以及项目所触及的任何东西的 API 文档。把 Claude 指向这里，它就不再建议那些与你的既有模式对着干的代码，而是开始匹配它们。一个代码库对应一个项目，绝不要共用一个，因为把两个代码库混在一起，是得到"两边都不合适"的建议的最快方式。 客户项目。一个客户对应一个项目。指令定义客户是谁、他们的品牌、他们的偏好，以及你和他们合作的工作范围。知识库里放他们的品牌指南、过往交付物、被提炼到要点的会议记录，以及任何专门针对他们的约束。这就是一个独立经营者或机构如何让每一个客户的上下文完美分离，从而让客户 A 的语气永远不会渗进客户 B 的作品里。 研究项目。指令定义你正在探究的问题或领域，以及你希望发现成果如何结构化。知识库里放你的源材料、你此前的笔记，以及你正在推进的论点。随着你不断喂给它更多内容，它会在所有东西之上构建出一幅图景，而因为它是有作用域的，它不会把这项研究和你正在做的其他任何事情搞混。这是基于聊天的项目最接近"第二大脑"概念的样子——一个你可以反复盘问的知识体，它之所以保持连贯，是因为它与一切无关之物隔离开来。 注意这四个模板共同的模式。指令承载长期规则和行为；知识库承载参考材料和范例。这种分离是刻意的，而把正确的内容放进正确的那一层，是让项目能起作用的关键所在。一条关于"该如何表现"的规则属于指令；一份 Claude 需要参考的文档属于知识库。把这两者搞混——把行为规则塞进知识文件，或者把参考文档粘进指令框——是一种悄无声息地让项目表现不佳、却又找不出明显原因的方式。 大多数人忽略的分层个性化 还有一件事值得知道，因为它叠加在以上所有东西之上。项目指令并不是 Claude 拥有的唯一个性化层级，理解它们如何组合能给你更精细的控制。 一共有三个层级，而且它们在每一次回复中都会同时生效。账户级指令，在你的个人资料设置里设定，适用于每一处每一次聊天，无论什么项目。项目指令只在一个特定项目内部生效。而样式（styles）是按聊天设定的，为那一段对话调整语气和格式。 实用的做法是让每一层去做它最擅长的事。把你和 Claude 打交道时放之四海皆准的规则——比如你通用的沟通偏好——放进账户级个人资料指令里，这样你就不用在每一个项目里重复它们。把项目特定的上下文和规则放进项目指令里。当某段特定对话需要不同于项目默认值的语气时，用样式来做一次性调整。 大多数人把所有东西都塞进一个层级，从而失去了这种控制。当你正确地分开它们时，你就不再需要在每一个项目里重复你的通用偏好，而每个项目的指令就能纯粹聚焦在"是什么让这个项目与众不同"上。这种聚焦，再一次，正是把项目设置好的全部主题。 真正会复利增长的设置 把整件事拼起来，一个正确构建的项目能给你的、而普通聊天永远给不了的东西是这样的。 每一次对话一开始，完整上下文就已经加载好了。你的语气、你的受众、你的规则、你的参考资料，在你打出第一个字之前就全都就位了。你不再需要反复简报。你不再从零开始。你不再每天早上训练同一个员工。 产出不再听起来千篇一律，而是开始听起来像你，因为 Claude 是在用你真实的范例和真实的标准工作，而不是一张白纸外加一条仓促的一行提示词。 而且它会复利。第一周需要一些小的修正，Claude 会从文件里学习你的模式。到了第三周，它匹配你方式的程度已经足够接近，你不再需要解释那些你过去每次都要解释的事情。三十分钟的设置，换来了持续数月的回报。 这是诚实的底线。大多数人永远得不到这个好处，不是因为功能难，而是因为他们用九十秒草草设置，却从没做过那些真正要紧的部分。精准的知识库。真正的长期简报。检索测试。维护习惯。 做好这四件事，Claude Projects 就不再是你的聊天文件夹，而会变成这样一个分水岭：你是把 Claude 当搜索框用，还是把它当作一个已经确切知道你是谁、你需要什么的系统来运转。 这周就好好设置一个项目。挑你做得最多的工作。写下真正的指令。上传三份紧凑的文档。测试检索。然后看看下一次对话的感觉会有多不同。 关注 @cyrilXBT，获取完整构建方案、精确的指令模板，以及我每天都在用的项目设置。 标签：# X # Claude # Marketing # Automation # AI # Growth # Guide # Cowork 相关文章 How to design an AI agent Who the fuck wants to pay for your platform when $200 already buys Claude Max or Codex? AI Claude Marketing Automation