# How to Actually Set Up Claude Projects That Most Users Don't Know - Full course
**作者**: CyrilXBT
**日期**: 2026-07-08T01:37:23.000Z
**来源**: [https://x.com/cyrilXBT/status/2074669139730284735](https://x.com/cyrilXBT/status/2074669139730284735)
---
Most people use Claude like a search bar.
Every session starts the same way. You are a marketing copywriter. My business is this. My audience is that. Now write me the thing. Then you close the tab, and tomorrow you do the entire briefing over again from scratch, training the same employee every single morning and letting them forget everything by night.
That is not a workflow. That is starting from zero, forever.
Claude Projects fix this, and almost nobody sets them up correctly. Most people create a project, paste one line of instructions, drop in a random PDF, and wonder why it does not feel dramatically better than a normal chat. The power is real, but it lives in the details that the setup screen does not explain.
This is the full course on setting up Claude Projects the way people who actually rely on them do it. Every feature here is real and current. By the end you will have a project that loads full context into every conversation automatically, never needs re briefing, and produces output that sounds like you instead of like a generic assistant.
## What A Project Actually Is
Strip away the marketing and a Claude Project is three things bundled into one persistent workspace.
Custom instructions. A system level prompt that applies to every conversation inside the project automatically. This is the standing brief that shapes how Claude behaves, who it thinks it is talking to, and what rules it follows, without you typing any of it into the chat.
A knowledge base. Files and documents Claude can reference in every conversation, always available, never needing re upload. Style guides, specs, past work, reference material.
Scoped conversations. All chats inside the project are grouped together and inherit the same instructions and knowledge.
One important thing to understand up front, because it trips people up constantly. Conversations inside a project do NOT share message history with each other. The shared state is the instructions and the files, not the chats. Each new conversation starts fresh with only those two things loaded. This matters for how you design everything below.
Projects are available on every Claude plan, including free, though free users are capped at five projects and project instructions specifically are a paid feature. On Pro, Max, and Team you get the full setup.
## The Mistake Almost Everyone Makes
Before the setup, understand the single biggest error, because avoiding it is most of the battle.
People treat the knowledge base like a storage locker. They dump everything in. The entire brand manual. Six months of meeting notes. A forty page strategy deck. The logic seems sound. More context equals better output.
It does not work that way, and here is why. Project knowledge does not get fully loaded into every response. Claude pulls the most relevant content per query through retrieval. When you overload the knowledge base with loosely related material, you dilute Claude's ability to find the signal that actually matters, and you risk filling the context window with files, leaving less room for the actual conversation.
The rule that produces dramatically better output is the opposite of what people expect. Keep each knowledge document tight and specific, roughly one to three pages. A three page brand voice guide beats a forty page brand manual every single time, because the useful signal is denser and the noise is lower. Precision beats volume in the knowledge base, always.
## Step 1: Create The Project With Real Intent
Open Claude, click Projects in the sidebar, click New project.
The name matters more than it looks. Name it specifically. "Newsletter" or "Client Proposals" or "API Documentation," not "Work" or "Stuff." The reason is that you will end up with multiple projects, and the entire point is separation. A vague name leads to a vague project that slowly accumulates unrelated junk, which is exactly the dilution problem above.
This leads to the first principle most people miss. One project per concern. Do not put your backend code and your marketing content in the same project. Do not mix client A and client B. Separate projects mean cleaner, more focused context, and focused context is the whole reason projects work. The instinct to have one mega project for everything is the instinct to recreate the generic chatbot you were trying to escape.
## Step 2: Write Instructions Like A Standing Brief, Not A Prompt
This is the highest leverage part of the entire setup, and it is where the gap between a weak project and a great one is widest.
A weak instruction block says "You are a helpful assistant that writes marketing content." That gives Claude nothing it did not already have.
A strong instruction block is a complete standing brief written for someone who knows nothing about you yet, because that is exactly the situation at the start of every new conversation in the project. It should cover who you are and what you do, the primary tasks this project exists for, your tone and style preferences, your required output format, the domain knowledge Claude should assume, and critically, the things Claude should never do.
Here is a template structure that works across almost any project type:
ROLE
You are [specific role] working on [specific domain]. You are writing for
[specific audience who knows nothing about them].
WHAT THIS PROJECT IS FOR
The main tasks here are [task 1], [task 2], [task 3]. Assume every request
relates to one of these unless told otherwise.
HOW TO RESPOND
Tone: [specific]. Format: [specific]. Length: [specific].
Do not ask clarifying questions unless genuinely blocked. Make a reasonable
assumption, state it, and proceed.
WHAT TO ASSUME
[Domain facts, product details, positioning that should be treated as given
in every response.]
NEVER
[Specific things Claude should never do in this project: AI cliches, certain
claims, certain formats, whatever your hard rules are.]
That one instruction about not asking clarifying questions is worth calling out. By default, Claude often opens with a round of "before I start, can you tell me more about..." For a project you use daily, that preamble is pure friction. Telling it to make a reasonable assumption, state it, and proceed removes the back and forth and speeds up every single session immediately.
Write these instructions for the reader who has zero history with you, because every new conversation genuinely starts there. The instructions and the files are the only things that carry forward. The memory of your last conversation does not.
## Step 3: Build The Knowledge Base With Precision
Now the files. Remember the rule. Tight, specific, one to three pages each. Here is what actually belongs in a well built knowledge base, using a content project as the example.
A voice and style guide. How you write. Sentence rhythm, words you use, words you ban, the feel of your output.
An audience document. Who you are writing for, what they care about, what they already know, what they are skeptical of.
A pillars or scope document. The specific topics or categories this project covers, so Claude stays in lane.
A small set of best examples. Three to five pieces of your actual best work. This teaches by demonstration far more effectively than description. Claude learns your patterns from real examples better than from any amount of instruction.
Reference material specific to the work. SEO notes, product specs, technical constraints, whatever the domain requires.
Name each file descriptively. "Brand Voice Guide v3," "Q2 Product Roadmap," "API Documentation Payments Module," not "notes" or "stuff." Descriptive names help retrieval surface the right document for the right query, which is the whole mechanism you are relying on.
The limits worth knowing. On Pro, Max, and Team you get up to 20 files per project, 30MB per file, supporting PDF, text, markdown, code files, CSV, and images. That is plenty if you follow the precision rule. If you are hitting the ceiling, the problem is almost always that you are uploading volume instead of signal.
## Step 4: Test Retrieval Before You Trust It
Here is a step almost nobody does, and it separates people who think their project works from people who know it does.
After you upload your knowledge, open a conversation in the project and explicitly test whether Claude can retrieve each document. Ask directly:
Based on the Brand Voice Guide in the project knowledge, how should I
approach the opening line of a post? Quote the specific guidance you are using.
If Claude accurately references the document, retrieval is working. If it gives a generic answer or cannot find the guidance, something is wrong. Maybe the file did not process, maybe the naming is too vague, maybe the document is buried under too many others. Better to find that out in a test than to discover three weeks later that Claude was never actually reading your most important file.
Run this test for each critical document. It takes five minutes and it is the difference between a project you hope works and one you know works.
## Step 5: Pick The Right Model Per Conversation
A detail most people miss entirely. Inside a project, you can choose which Claude model to use for each conversation independently. The project does not lock you into one model.
This matters for cost and quality. Use a faster model for routine drafting inside the project, and switch to a more capable model for the conversations that need deep reasoning or complex synthesis. Same project, same instructions, same knowledge, different engine depending on what the specific task needs. Most people never realize they can do this and either overpay by running everything on the top model or underperform by running everything on a fast one.
## Step 6: Use Conversations As Thinking, Not Just Tasks
Here is a habit that quietly makes projects far more powerful over time.
Do not only use project conversations for finished tasks. Use them to think out loud. Work through a problem, explain your reasoning, talk through why you are making a decision. Because the project is scoped and consistent, these thinking conversations help Claude understand your reasoning patterns, not just your output patterns.
The result is that over weeks, Claude inside a well used project starts matching not just your format but your judgment. It suggests approaches that fit how you actually think, because it has seen how you think inside that scoped context, not just what you produce.
## Step 7: Maintain It, Because A Project Is Only As Current As Its Files
A project is not set and forget. It is only as accurate as what is inside it, and outdated knowledge produces confidently wrong context, which is worse than no context.
Build a maintenance habit. When your positioning changes, update the voice guide. When a spec is revised, replace the old one. When a strategy shifts, update the scope document. Review your project instructions quarterly, because instructions written six months ago may now actively contradict what you are doing, and Claude will faithfully follow the outdated rule.
The projects that stay valuable are the ones people keep current. The ones that quietly become useless are the ones that were set up once and never touched again while the real work moved on around them.
## The New Layer: Cowork Projects
Worth knowing, because it extends everything above significantly. As of the 2026 updates, Projects also live inside Claude Cowork, the desktop agentic app, and this version adds capabilities the chat based projects do not have.
Cowork projects add scoped memory that persists between sessions, so you can say "build on last week's report" and Claude knows exactly what that was, without leaking that context into your other work. They add dedicated local folders, so the project reads and writes real files on your machine. And they add scheduled tasks, so a project can run recurring work automatically on a cadence you set.
The setup logic is the same as everything above. Clear instructions, tight relevant files, one project per concern. But the ceiling is higher, because a Cowork project does not just inform conversations, it executes work against real files and can run on a schedule without you. A good first move is pointing it at a folder and saying:
Read every file in this folder. Then summarize what you know about this
workspace: what is here, what I probably use it for, and what instructions
you will follow. If anything is unclear, ask before assuming.
That single command makes Claude learn the project on day one, and from there it remembers.
## Four Project Templates You Can Build Today
The theory is only useful once it is concrete. Here are four project setups that map directly onto the most common use cases, each with what goes in instructions versus knowledge, so you can copy the structure.
The Content Project. Instructions define your role as a writer for a specific audience, your tone, your formatting rules, and your hard bans. Knowledge holds a voice guide, an audience persona, a pillars document, and three to five of your best performing pieces. This is the project that makes everything you publish sound consistently like you instead of like a different writer each time. The best examples in the knowledge base do more work here than any instruction, because voice is caught, not taught.
The Code Project. Instructions define your stack, your conventions, your preferred patterns, and the things you never want done. Knowledge holds an architecture document, your key source files, your coding standards, and API documentation for anything the project touches. Point Claude at this and it stops suggesting code that fights your existing patterns and starts matching them. One project per codebase, never a shared one, because mixing two codebases is the fastest way to get suggestions that fit neither.
The Client Project. One project per client. Instructions define who the client is, their brand, their preferences, and the scope of your work with them. Knowledge holds their brand guidelines, past deliverables, meeting notes distilled to essentials, and any constraints specific to them. This is how a solo operator or agency keeps every client's context perfectly separated, so client A's voice never bleeds into client B's work.
The Research Project. Instructions define what question or domain you are investigating and how you want findings structured. Knowledge holds your source material, your prior notes, and your working thesis. As you feed it more, it builds a picture across everything, and because it is scoped, it does not confuse this research with anything else you are working on. This is the closest a chat based project gets to the second brain concept, a body of knowledge you can interrogate that stays coherent because it is walled off from everything unrelated.
Notice the pattern across all four. Instructions carry the standing rules and the behavior. Knowledge carries the reference material and the examples. The separation is deliberate, and getting the right content into the right layer is most of what makes a project work. A rule about how to behave belongs in instructions. A document Claude needs to reference belongs in knowledge. Mixing those up, putting behavioral rules in a knowledge file or pasting reference docs into the instruction box, is a quiet way to make a project underperform without an obvious reason why.
## The Layered Personalization Most People Miss
One more thing worth knowing, because it stacks on top of everything above. Project instructions are not the only personalization layer Claude has, and understanding how they combine gives you finer control.
There are three layers, and they all apply at once on every response. Account wide instructions, set in your profile settings, apply to every chat everywhere regardless of project. Project instructions apply only inside a specific project. And styles, set per chat, tune tone and format for that one conversation.
The practical move is to use each for what it is best at. Put the rules that apply to everything you do with Claude, like your general communication preferences, in the account wide profile instructions, so you do not repeat them in every project. Put project specific context and rules in the project instructions. Use styles for one off adjustments when a particular conversation needs a different tone than the project default.
Most people cram everything into one layer and lose this control. When you separate them correctly, you stop repeating your universal preferences in every single project, and each project's instructions stay focused purely on what makes that project different. That focus is, once again, the entire theme of setting projects up well.
## The Setup That Actually Compounds
Put the whole thing together and here is what a properly built project gives you that a normal chat never will.
Every conversation starts with full context already loaded. Your voice, your audience, your rules, your reference material, all present before you type a word. You stop re briefing. You stop starting from zero. You stop training the same employee every morning.
The output stops sounding generic and starts sounding like you, because Claude is working from your actual examples and your actual standards, not a blank slate plus a rushed one line prompt.
And it compounds. Week one needs small corrections as Claude learns your patterns from the files. By week three, it is matching your approach closely enough that you stop explaining things you used to explain every time. The thirty minutes of setup pays back over months.
Here is the honest bottom line. Most people never get this benefit, not because the feature is hard, but because they set it up in ninety seconds and never did the parts that actually matter. The precise knowledge base. The real standing brief. The retrieval test. The maintenance habit.
Do those four things and Claude Projects stop being a folder for your chats and become the difference between using Claude as a search bar and running it as a system that already knows exactly who you are and what you need.
Set up one project properly this week. Pick the work you do most. Write the real instructions. Upload three tight documents. Test retrieval. Then watch how different the next conversation feels.
Follow @cyrilXBT for the full builds, the exact instruction templates, and the project setups I use every day.
## 相关链接
- [CyrilXBT](https://x.com/cyrilXBT)
- [@cyrilXBT](https://x.com/cyrilXBT)
- [@cyrilXBT](https://x.com/@cyrilXBT)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:37 AM · Jul 8, 2026](https://x.com/cyrilXBT/status/2074669139730284735)
- [3,085 Views](https://x.com/cyrilXBT/status/2074669139730284735/analytics)
---
*导出时间: 2026/7/8 10:03:52*
---
## 中文翻译
大多数人只是把 Claude 当作一个搜索栏来用。
每个会话的开头总是一成不变：你是一个营销文案写手。我的业务是这样的。我的受众是那样的。现在帮我写个东西。然后你关掉标签页，第二天又从头开始把整个简报重讲一遍，就像每天早上都在培训同一个新员工，然后让他们到了晚上就忘得一干二净。
这根本不是工作流。这是永远从零开始。
Claude Projects（项目）就是为了解决这个问题，但几乎没有谁能把它们设置正确。大多数人建个项目，粘贴一行指令，扔进去一个随机的 PDF，然后纳闷为什么感觉它没比普通聊天好多少。威力是真实的，但它隐藏在设置页面未曾解释的细节里。
这是一套关于如何正确设置 Claude Projects 的完整教程，完全是按照那些真正依赖它的人的方式来进行的。这里提到的每个功能都是真实且当前可用的。学完后，你将拥有一个能自动将完整上下文加载到每次对话中的项目，它不再需要反复简报，产出的内容听起来像你，而不像一个通用的助手。
## 项目究竟是什么
剥离掉营销术语，一个 Claude Project 就是捆绑在一个持久化工作空间里的三样东西：
* **自定义指令**。一个系统级提示，自动应用于项目内的每次对话。这是一份常驻简报，它塑造了 Claude 的行为、它认为自己在跟谁对话、以及遵循什么规则，而不需要你在聊天中输入任何内容。
* **知识库**。Claude 可以在每次对话中参考的文件和文档，随时可用，无需重新上传。风格指南、规范、过往作品、参考资料。
* **限定范围的对话**。项目内的所有聊天都归为一组，并继承相同的指令和知识。
有一点需要提前理解，因为它总是让人栽跟头：**项目内的对话之间并不共享消息历史**。共享的状态是指令和文件，而不是聊天记录。每次新对话都是重新开始，只加载这两样东西。这对于你设计下面的一切至关重要。
Projects 在所有 Claude 计划中都可用，包括免费版，不过免费用户最多只能创建 5 个项目，且“项目指令”功能本身是付费功能。在 Pro、Max 和 Team 版中，你可以使用完整设置。
## 几乎每个人都会犯的错误
在开始设置之前，请先理解这一个最大的错误，因为避开了它，你就成功了一大半。
人们把知识库当作储藏室。他们把所有东西都倒进去。整本品牌手册。六个月的会议记录。四十页的战略演示文稿。这逻辑听起来没毛病。上下文越多等于输出越好。
但事实并非如此，原因如下：项目知识**不会**完全加载到每个回复中。Claude 会通过检索机制，针对每个查询提取最相关的内容。当你把大量松散相关的材料塞进知识库时，你稀释了 Claude 找到真正重要的信号的能力，而且你冒着用文件填满上下文窗口的风险，留给实际对话的空间反而变少了。
能显著提升输出质量的规则，与人们的预期恰恰相反。**保持每个知识文档简短而具体，大约 1 到 3 页**。一份 3 页的品牌语调指南每一次都能击败 40 页的品牌手册，因为有用的信号密度更高，噪音更低。在知识库中，精准度永远胜过体量。
## 第 1 步：带着明确意图创建项目
打开 Claude，点击侧边栏的 Projects（项目），点击 New project（新建项目）。
**名称比看起来更重要**。要具体命名。比如“Newsletter（通讯）”、“Client Proposals（客户提案）”或“API Documentation”，不要叫“Work（工作）”或“Stuff（东西）”。原因是你最后会有多个项目，而整个目的就在于**分离**。一个模糊的名称会导致一个模糊的项目，慢慢堆积无关的垃圾，这正是上面提到的“稀释”问题。
这就引出了大多数人忽视的第一条原则：**一个项目对应一个主题**。不要把你的后端代码和营销内容放在同一个项目里。不要混合客户 A 和客户 B。分离的项目意味着更干净、更聚焦的上下文，而聚焦的上下文正是项目起作用的原因。那种想要一个包揽一切的“超级项目”的本能，其实是在重造你试图逃离的那种通用聊天机器人。
## 第 2 步：像写常驻简报一样写指令，而不是写提示词
这是整个设置中杠杆率最高的部分，也是平庸项目和卓越项目差距最大的地方。
一段薄弱的指令块会说：“你是一个写营销内容的乐于助人的助手。”这没给 Claude 提供任何它原本不具备的东西。
一段强有力的指令块是一份完整的常驻简报，是写给一个对你一无所知的人看的，因为这正是项目中每次新对话开始时的真实情况。它应该涵盖你是谁、你做什么，这个项目存在的主要任务，你的语调和风格偏好，你要求的输出格式，Claude 应该假设具备的领域知识，以及关键的是——**Claude 绝不应该做什么**。
以下是一个几乎适用于任何项目类型的模板结构：
>**角色**
>你是 [具体角色]，正在 [具体领域] 工作。你正在为 [具体且对你的领域一无所知的受众] 写作。
>
>**本项目用途**
>这里的主要任务是 [任务 1]、[任务 2]、[任务 3]。除非另有说明，否则假设每个请求都与其中之一相关。
>
>**如何回复**
>语调：[具体]。格式：[具体]。长度：[具体]。
>除非真的卡住了，否则不要提出澄清性问题。做出合理的假设，陈述它，然后继续。
>
>**默认假设**
>[领域事实、产品细节、定位，这些应在每次回复中被视为既定事实。]
>
>**绝不**
>[在这个项目中 Claude 绝不应该做的具体事项：AI 惯用语、特定声明、特定格式，无论你的硬性规则是什么。]
那个关于“不要提出澄清性问题”的指令值得单独拿出来说。默认情况下，Claude 经常以“在我开始之前，能不能多告诉我一点关于……”来开场。对于一个你每天使用的项目来说，这种前言纯属摩擦。告诉它做出合理的假设，陈述假设，然后继续，能消除来回拉扯，立竿见影地加快每次会话。
**要像写给一个对你毫无过往了解的读者那样去写这些指令**，因为每次新对话确实都是从那里开始的。能延续下去的只有指令和文件。你对上一次对话的记忆是延续不下去的。
## 第 3 步：精准构建知识库
现在是文件。记住规则：**简短、具体，每个 1 到 3 页**。以下是一个构建良好的知识库中实际应该包含的内容，以一个内容项目为例：
* **语调和风格指南**。你的写作方式。句子节奏、你常用的词、你禁用的词、你输出的质感。
* **受众文档**。你在为谁写作，他们关心什么，他们已经知道什么，他们对什么持怀疑态度。
* **支柱或范围文档**。该项目涵盖的具体主题或类别，以便 Claude 始终在正轨上。
* **一小部分最佳范例**。3 到 5 件你真正的最佳作品。这通过演示教学的效果远胜于描述。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 和图片。如果你遵循精准度原则，这绰绰有余。如果你碰到了上限，问题几乎肯定是你上传的是体量而不是信号。
## 第 4 步：在信任之前测试检索
这是一步几乎没人做的事，但它区分了那些“觉得”自己项目能用的人和“知道”自己项目能用的人。
上传你的知识后，在项目里开一个对话，明确测试 Claude 是否能检索到每个文档。直接问：
>根据项目知识中的 Brand Voice Guide（品牌语调指南），我应该如何处理文章的开篇句？请引用你使用的具体指导。
如果 Claude 准确地引用了文档，说明检索工作正常。如果它给出一个通用的答案或找不到指导，那就出了问题。可能是文件没处理成功，可能名字太模糊，可能文档被埋在其他太多文件下面了。在测试中发现这一点，比三周后发现 Claude 从来没读过你最重要的文件要好得多。
对每个关键文档都运行这个测试。只需五分钟，这正是区分一个你“希望”它有用的项目和一个你“知道”它有用的项目之间的差距。
## 第 5 步：为每次对话选择正确的模型
这是一个大多数人完全错过的细节。在一个项目内，你可以为每次对话独立选择使用哪个 Claude 模型。项目并没有把你锁死在一个模型上。
这对成本和质量都很重要。在项目内部进行常规起草时使用更快的模型，在需要深度推理或复杂综合的对话中切换到能力更强的模型。同一个项目，相同的指令，相同的知识，但根据具体任务的需求使用不同的引擎。大多数人从未意识到他们可以这样做，结果要么是在顶级模型上运行所有任务而多花钱，要么是全程用快速模型而效果不佳。
## 第 6 步：把对话当作思考过程，而不只是任务
这里有一个习惯，它能让项目随时间推移变得强大得多。
不要仅仅把项目对话用于完成任务。要用它们来**大声思考**。解决一个问题，解释你的推理，谈论你为什么要做某个决定。因为项目是限定范围且一致的，这些思考性的对话能帮助 Claude 理解你的推理模式，而不仅仅是你的输出模式。
结果是，几周后，在一个使用频繁的项目里，Claude 开始不仅匹配你的格式，还匹配你的判断。它建议的方法符合你的真实思维方式，因为它在该限定的上下文中看到过你是如何思考的，而不仅仅是你生产了什么。
## 第 7 步：维护它，因为项目的有效性仅取决于其文件的时效性
项目不是设置好就可以忘记的。它的准确性仅取决于其中的内容，过时的知识会产生“自信的错误”上下文，这比没有上下文更糟糕。
养成维护习惯。当你的定位改变时，更新语调指南。当规格修订时，替换旧的。当战略转移时，更新范围文档。每季度审查一次项目指令，因为六个月前写的指令现在可能与你的工作 actively 矛盾，而 Claude 会忠实地遵循那条过时的规则。
保持有价值的项目，是那些人们一直保持其最新状态的项目。那些悄悄变得没用的，正是那些只设置一次就再也没碰过的项目，而实际工作早已在它们周围继续前进了。
## 新层级：Cowork 项目
值得了解，因为它极大地扩展了上述一切。截至 2026 年的更新，Projects 也存在于 Claude Cowork（桌面代理应用）中，这个版本增加了基于聊天的项目所不具备的功能。
Cowork 项目增加了在会话之间持久存在的限定范围记忆，所以你可以说“基于上周的报告继续做”，Claude 确切地知道那是什么，而不会让该上下文泄露到你的其他工作中。它们增加了专用的本地文件夹，所以项目可以读写你机器上的真实文件。它们还增加了定时任务，所以项目可以按你设定的节奏自动运行循环工作。
设置逻辑与上述一切相同。指令清晰、文件精简相关、一个项目对应一个主题。但上限更高，因为 Cowork 项目不仅为对话提供信息，它还对真实文件执行工作，并且可以不需要你介入地按计划运行。一个很好的第一步是把它指向一个文件夹并说：
>阅读此文件夹中的每个文件。然后总结你对这个工作区的了解：这里有什么，我可能用它做什么，以及你将遵循什么指令。如果有任何不清楚的地方，请在假设之前先提问。
这单一的一条命令让 Claude 在第一天就学会了该项目，从那里开始，它就会记住了。
## 你今天就能构建的四个项目模板
理论只有在具体化时才有用。这里有四个直接映射到最常见用例的项目设置，每个都说明了指令与知识库中应包含什么内容，你可以复制这个结构。
* **内容项目**。指令将你的角色定义为针对特定受众的写手，你的语调、格式规则和硬性禁止事项。知识库包含语调指南、受众画像、支柱文档，以及 3 到 5 个你表现最好的作品。这就是让你发布的每样东西都听起来始终像你，而不是每次都像不同写手的项目。在这里，知识库中的最佳范例所起的作用比任何指令都大，因为语调是“感染”来的，不是“教”会的。
* **代码项目**。指令定义你的技术栈、惯例、首选模式，以及你绝不想要做的事情。知识库包含架构文档、关键源文件、编码标准，以及项目涉及到的任何 API 文档。让 Claude 指向这里，它就会停止建议与你现有模式冲突的代码，转而开始匹配它们。**每个代码库一个项目，绝不混用**，因为混合两个代码库是得到“两边都不适配”的建议的最快方式。
* **客户项目**。**每个客户一个项目**。指令定义客户是谁、他们的品牌、偏好，以及你与他们合作的范围。知识库包含他们的品牌指南、过往交付物、提炼为要点的会议记录，以及任何针对他们的约束条件。这就是个人经营者或代理机构如何保持每个客户的上下文完美分离，以便客户 A 的语调绝不会混入客户 B 的工作中。
* **研究项目**。指令定义你正在研究的问题或领域，以及你希望发现如何结构化。知识库包含你的原始材料、先前的笔记和你工作中的论点。随着你喂给它更多，它会跨所有内容构建图景，因为它是限定范围的，所以它不会把这项研究与你正在做的其他任何事情混淆。这是基于聊天的项目最接近“第二大脑”概念的地方，一个你可以查询的知识体，它因为与所有不相关内容隔绝而保持连贯。
注意这四种项目的共同模式。**指令承载常驻规则和行为。知识库承载参考资料和范例**。这种分离是有意为之，把正确的内容放入正确的层级是项目起作用的大部分原因。关于如何行为的规则属于指令。Claude 需要参考的文档属于知识库。把这两者搞混——把行为规则放在知识文件里，或者把参考资料粘贴进指令框——是让项目表现不佳且无明显原因的隐秘方式。
## 大多数人错过的分层个性化
还有一件事值得了解，因为它叠加在上述一切之上。项目指令并不是唯一的个性……