你有没有发现，身边用 Claude 的人其实分成两种：一种把它当聊天窗口，有问必答，问完就走；另一种会建 Projects、会玩 Artifacts，同样一个模型，他们手里的 Claude 像是换了个人。前一种用法不是错，但非常亏。我把两种方式都实打实用了好一阵子之后，可以负责任地说：只聊天不建项目，等于让 Claude 每次都“失忆重来”；而一旦把 Projects 的专属上下文和 Artifacts 的迭代能力用起来，它能从一个“问答机器”变成真正的“协作工作台”。这篇文章就围绕这两块展开，把我实测过的搭建思路、操作细节和踩坑过程全部写出来。
1. 只当聊天窗口，等于让 Claude 每次都“失忆重来”
1.1 聊天模式的三重浪费
默认打开 Claude 就是聊天窗口，这没问题，问题在于大多数人把聊天窗口当成了唯一入口。我见过很多同事、朋友的做法是：把一个需求从头到尾放在同一个对话里，聊到后面发现上下文快不够了，再开一个新对话，然后把之前说过的需求重新粘贴一遍。这就是最典型的浪费——你把大量时间花在“让模型想起来”而不是“让模型干活”上。
拆开看，聊天模式至少有三重浪费。第一是背景信息重复输入：每开一个新对话，Claude 对你的项目背景、术语定义、格式偏好一无所知，你得把它当新同事重新培训一遍。第二是上下文窗口被中间过程占满：一个长对话里，真正和最终目标相关的内容可能只占开头和结尾，中间几十轮都是试错、修正、讨论细节，这些内容会挤占模型能看到的有效信息。第三是结果无法复用：同一个主题下，A 对话里产出的结论，B 对话里根本不知道，下次又得重新生成一遍。
1.2 一次实测：它是怎么“忘记”最初规则的
我印象很深的一次实测是整理一批用户的资料。我一开始在聊天窗口里给了 Claude 一套很明确的输出规则：摘要不超过 120 字、必须包含“来源”“时间”两个字段、语气中性。前几轮它都执行得很好。但聊到二十多轮，中途反复讨论了很多格式调整和例外之后，我再让它按“最初规则”处理下一批资料，输出的内容字段对上了，但摘要长度明显超标，语气也带了主观评价。
这不是模型变笨了，而是因为它能看到的上下文里，最初几条规则只占非常小的一部分，后面大量“临时讨论”反而模糊了重点。我当时就意识到：聊天模式适合一次性问答，不适合需要稳定规则的持续任务。后来我把同样一套规则写进 Projects 的自定义指令里，再反复测试，发现只要规则文件在那里，无论对话进行了多少轮，它都会优先遵守——因为项目级指令在每次对话开始时就被加载，权重比对话中间的散装讨论高得多。
1.3 Projects 的本质：给模型配一个“专属工作台”
Projects 解决的正是上面这些浪费。你可以把它理解成一个长期存在的工作空间：里面可以放项目文件（文档、表格、代码、PDF 等），还可以写一套项目级自定义指令。每次在这个项目里发起新对话，Claude 都会自动带着这些文件上下文和指令开始，不用你重新解释任何东西。
我用过一个类比：普通聊天窗口像你临时找个专家问问题，每次都要先把背景讲一遍；Projects 则是给这个专家配了一间办公室，桌上放着你的项目资料，墙上贴着操作规范，他每次进来干活前先看一遍文件和规则，然后直接动手。
这也解释了为什么标题里强调“专属大脑”——Projects 不是简单的文件存储，它是一套可复用的上下文系统。你在这个项目里的每一次对话，都会继承同一套背景知识和工作规范，所以聊得越多、沉淀越多，而不是聊得越多、忘得越多。
2. 搭一个专属大脑：Projects 的输入、规则与组织方式
2.1 文件上传：宁缺毋滥，信噪比是第一位
Projects 允许上传一批文件作为项目上下文，但千万别把“允许上传”理解成“应该多上传”。我见过有人把一个项目的所有资料一股脑扔进去，几十个文件，里面还包括很多过期版本和无关截图，结果 Claude 的输出质量反而明显下降——它被大量低信噪比的信息干扰了。
我的经验是把文件分为三类：规则类（必须遵守的标准、需求说明、术语定义）、样例类（输入输出的例子、参考模板）、数据类（要处理的数据、待整理的清单）。每个文件在命名时就把职责写清楚，比如01_清洗规则_最终版.md、02_样例数据_脱敏.csv，这样 Claude 在组织回答时更容易区分“这是必须遵守的”和“这是仅供参考的”。实测下来，5-8 个精心挑选的文件，效果通常比 30 个杂乱文件好得多。
2.2 自定义指令：把“给人的要求”翻译成“给模型的约束”
自定义指令是整个 Projects 专属大脑最核心的部分。很多人会写“你是一个资深分析师”“请认真回答问题”，这类话太虚了，模型拿到之后不知道该转换成什么行为。真正有效的自定义指令应该包含四个维度：角色（以什么身份处理任务）、风格（输出语言、语气、结构偏好）、约束（必须做什么、禁止做什么）、流程（接到任务先做什么再做什么）。
我自己的写法是这样的，给读者一个可直接参考的模板：
角色：你是一名资深数据分析师，负责本项目的所有资料处理工作。 风格： - 所有输出使用简体中文，语气客观、简洁。 - 涉及列表时使用 Markdown 有序或无序列表。 - 不要使用感叹号和情绪化表达。 约束： - 处理资料摘要时，必须包含“来源”“时间”“结论”三个字段，摘要不超过 120 字。 - 禁止推断数据之外的结论。 - 如果资料中有不确定的信息，明确标注“待确认”，不要猜测。 流程： - 收到任务后，先对照项目文件中的规则文档确认要求。 - 分步输出处理结果，每步说明依据。 - 输出前检查一遍是否违反上述约束。这类指令为什么有效？因为模型能“检查”每条约束是否被满足。像“摘要不超过 120 字”这种可量化的要求，它执行起来几乎不会失误；而“语气客观简洁”这种稍微抽象的要求，配合“不要用感叹号”这样的具体例子，也能变得可操作。我还建议在指令里写明优先级：如果项目文件中的旧说明和本指令冲突，以本指令为准。这样能避免一些边界混乱。
2.3 项目空间的划分粒度：按“输出物”分，不按“输入领域”分
Projects 到底建几个、怎么建，这是很多人纠结的问题。我的建议是：按“输出物”划分，不要按“输入领域”划分。举例来说，如果你手头有一个数据整理的任务，同时也想做一个配套的展示页面，不要都塞进同一个项目，因为两个任务的输出形式、操作规范完全不同。我会拆成两个项目：一个叫“数据整理流程”，命令里规定输出 Markdown 表格和摘要；另一个叫“展示页面原型”，命令里规定只输出 HTML/CSS/JS 的 Artifact，并且要求适配移动端。
按输出物划分还有一个隐藏好处：方便复用。当你需要对同一个输出物做长期迭代时，所有对话都在同一个项目里发生，之前的讨论和结论虽然不会自动继承，但这个项目里的文件会持续更新，你在新对话里提到的参考材料永远是最新版本。我第一次试的时候，把项目建得特别大，想把整个工作流都装进去，结果 Claude 经常在文件之间“找不着北”。后来我把文件精简到 5 份以内，再把规则写清楚，整个流程就顺了。
3. Artifacts 不只是“代码输出框”：四种被低估的玩法
3.1 玩法一：原地迭代，让对话变成“改稿现场”
大多数人对 Artifacts 的印象就是“一个独立的输出块，可以预览、可以复制”。这种理解太浅了。Artifacts 真正厉害的地方是它能在对话中被持续引用和修改，而且修改的是“同一个产物”，不是每次都生成一个崭新但陌生的东西。
我实测过做一个数据可视化卡片。第一次让 Claude 生成一个 HTML 卡片，它输出了一个 Artifact，长条形，左上方大数字，右侧几个指标。我看了之后说“把主数字的颜色改成深蓝，指标区改成网格布局”，它直接在原 Artifact 上更新了；然后我又说“网格布局下面加一条时间趋势折线”，它又更新了。连续迭代了九次，我只用自然语言描述修改点，从没复制过一行代码，最后版本和初始版本已经完全是两个东西了。
这个玩法的关键在于：在对话中明确指向“那个 Artifact”，或者用“把它改一下”这种说法。Claude 会识别出你在引用一个已有的输出产物，从而进行原地更新，而不是重新生成一个。这样你的整个思考过程就变成了一个连续的“改稿现场”，每一步都有上下文，每一步都基于之前的改动。
3.2 玩法二：交互式 HTML 原型，让想法变成可点的东西
Artifacts 支持 HTML、CSS、JavaScript 的渲染预览，这意味着你可以在对话里直接生成可交互的原型——按钮能点、表单能填写、下拉框能切换，完全不需要离开对话界面就能体验到一个“活”的东西。这个能力被很多人低估了，他们只让 Claude 写静态代码，却忘了它能在 Artifact 里跑起来。
我试过做一个“字段映射配置器”：左侧是源字段列表，右侧是目标字段列表，中间用连线或下拉选择建立映射关系，底部还有一个实时预览区域，显示配置后生成的 JSON 结构。整个原型就是一个单独 HTML 文件，我用自然语言让 Claude 增加拖拽排序、增加冲突提示、调整配色，它都在同一个 Artifact 里完成了。最后我把文件下载下来，直接发给同事演示，比写十页需求文档都清楚。
这类交互式原型特别适合用来“验证想法”。你不用先学前端、不用搭环境，只需要把想法描述清楚，剩下的渲染和交互逻辑交给模型。我自己现在遇到需求不明确的场景，第一反应都是让 Claude 先出一个可点击的原型，而不是先写文档。
3.3 玩法三：一份需求文档和一个实现，保持联动
Artifacts 可以在同一个对话里同时存在多个。我常用的一个组合是：一个 Artifact 放需求文档（Markdown 格式），另一个 Artifact 放实现代码（HTML 文件），然后告诉 Claude“需求文档里写的是规则，实现代码必须遵守这些规则；如果需求文档有修改，同步更新实现代码”。
这个组合特别适合处理“文档与实现不一致”的痛点。手动维护时，需求改了一处，代码里往往漏改；但在 Claude 的 Artifact 体系里，你只需要说“把需求文档第 3 节改成这样，对应更新实现代码”，它就能在一次操作里把两个 Artifact 都更新，并且保持逻辑一致。我实测过在需求文档里加了一条“时间字段为空时显示‘未知’”，让 Claude 同步更新代码，它准确找到了实现里的对应分支并做了修改，没有波及到其他功能。
3.4 玩法四：多个 Artifact 组合成一套“迷你系统”
不要满足于单个 Artifact，试着让多个 Artifact 互相配合。我在一个项目里做过这样的组合：第一个 Artifact 是一套 SVG 图标集合，第二个 Artifact 是一个展示这些图标的页面模板，第三个 Artifact 是一份使用说明文档。我告诉 Claude“图标集是共享资源，页面模板引用其中几个图标，说明文档要写清楚如何替换图标”，然后三个 Artifact 就形成了一个小小的资源包。
这种组合的意义在于：你开始用工程师的思维方式使用 Claude——有共享模块、有调用方、有文档。虽然在单个对话里它不可能构建一个真正的大型系统，但对于个人项目、小工具、原型验证，已经完全够了。我通常会把这三个 Artifact 分别下载保存到本地目录，对应assets/、pages/、docs/，下次要做类似东西时，直接复制这套结构让 Claude 继续扩展。
4. 实测跑一遍：Projects 专属大脑 + Artifacts 做可视化配置工具
4.1 需求场景：一份数据清洗规则，想变成点选界面
为了验证 Projects 和 Artifacts 的组合拳，我设计了一个完整的小实验，完全用 Claude 完成，中间没有自己写一行代码。场景是这样的：我手头有一套数据清洗规则，原本写在文档里，包括“去除空白字符”“统一日期格式”“根据某个字段的取值范围打标签”等十几条规则。我想做一个可视化配置界面：用户能在页面上看到所有规则，选择启用或禁用，配置具体参数，最后导出一份配置 JSON。
这个场景非常适合做测试，因为它的核心痛点很明确——把“文档里的规则”变成“可交互的配置工具”。同时它需要稳定的规则上下文（适合 Projects），也需要连续迭代的界面（适合 Artifacts）。下面记录的是我实际操作的完整流程。
4.2 操作过程：五个步骤从零到完成
第一步，新建一个 Project，命名为“清洗规则配置器”。第二步，上传文件：一份 Markdown 格式的清洗规则文档，一份 CSV 格式的示例数据（20 行，全部是脱敏假数据），并在自定义指令里写明：所有界面输出必须是单个 Artifact 形式的 HTML 文件，样式要简洁，所有配置结果必须能导出为 JSON。第三步，发起第一轮对话，描述界面需求：左侧是规则列表，可开关、可拖拽排序；右侧是选中规则的参数配置区；底部是实时生成的 JSON 预览。第四步，Claude 生成了第一个 Artifact，是一个基础可交互界面，规则列表和配置区都出来了。第五步，我连续提了几轮修改意见：给启用状态加上视觉区分、拖拽排序的手柄改到左侧、JSON 预览增加“复制到剪贴板”按钮、规则参数里日期格式改成下拉选择而不是自由输入。每一次它都在同一个 Artifact 上原地更新。
让我把其中一轮对话真实还原一下，方便读者感受迭代密度。我当时的输入是：“在 JSON 预览区域的上方加一个状态栏，显示当前已启用规则的数量；规则列表每一项的右侧加一个删除按钮，删除时要有确认提示。”它很快就更新了 Artifact，状态栏出现在预览区上方，删除按钮也带上了确认逻辑。这种体验是聊天窗口给不了的——聊天窗口只会给你代码片段，而 Artifact 会给你一个能直接操作的界面。
4.3 结果与感受
最终这个原型完整支持了功能，包括规则启停、拖拽排序、参数配置、JSON 导出、删除确认，整个过程中我没有写任何代码，也没有复制过任何代码。从项目建立到最终版本，大约花了不到一个小时，其中大部分时间是我在想“下一步改哪里”，而不是在调试。这个效率对于原型验证来说是惊人的。
事后我复盘了一下为什么能这么顺。一方面是因为项目文件里那套清洗规则一直在线，Claude 不需要我在对话里反复解释“什么叫去除空白字符”；另一方面是因为 Artifacts 的迭代模式让我可以像“甲方提修改意见”一样工作，先看结果再提需求，回路非常短。我强烈建议每个有类似需求的人都试试这个组合：先建项目给它喂材料，再用 Artifact 让它产出可交互的东西。
5. 这轮实测踩到的坑，和我的具体解法
5.1 坑一：项目塞了 30 份文件，Claude 反而“不知道该听谁的”
我一开始为了追求“考虑周全”，把一个研究主题相关的所有文件都传进了项目里，大概 30 份，有论文 PDF、内部说明、历史版本、截图、网页导出等。结果 Claude 在回答问题时频繁引用一些无关紧要的细节，而核心规则反而执行得不够坚定。它会“综合”所有文件的说法，哪怕某些文件早就过期了。
这个问题我用两个办法解决。第一是精简：只保留最核心的 5-8 份文件，过期版本一律移除。第二是优先级声明：在自定义指令里写清楚“当项目文件与内置知识冲突时，以项目文件为准；当不同项目文件之间冲突时，以文件名带 _final 的版本为准”。这样模型的决策路径就清楚了，不再“东听一句西听一句”。
5.2 坑二：Artifact 改着改着，最初版本找不回来了
这是我在做可视化卡片时踩的坑。迭代了四五轮之后，我突然想对比一下第一版的配色和第二版的差异，结果发现最初那张 Artifact 已经被覆盖了，页面里只剩最新版本。我当时的反应是：完了，第一版没存。后来我养成了一个习惯：在需要保留某个方案时，明确告诉 Claude“请把这个 Artifact 复制一份，命名为 A 方案，然后在此基础上修改”。没有这句显式指令，它默认是在原 Artifact 上原地改，最早的版本不会自动保留。
这个坑特别容易出现在“想让模型做多方案探索时”。如果你同时想对比 A/B 两种布局，千万别只靠它自己“记得”第一种，直接在对话里说“新建一个 Artifact 做 B 方案”，让两个版本同时在界面上存在，这样你才能对比选择。
5.3 坑三：PDF 解析的“看起来能用”陷阱
上传 PDF 时也要多留个心眼。我试过传一份扫描版 PDF 进项目，表面上 Claude 能回答一些问题，但涉及到具体数字和表格结构时，它给出的内容经常和原文对不上。后来我用文字提取工具把 PDF 转成了 Markdown，再传进项目，准确率立刻上来了。
这背后的原因倒不难理解：扫描版 PDF 在模型眼中不是“文字”，而是“图片”；而带复杂表格的 PDF，即使里面有文字层，行列顺序也可能在解析时被打乱。所以我的项目文件策略是：能转 Markdown 就转 Markdown，能转 CSV 就转 CSV，尽量不给模型留“猜”的空间。
5.4 坑四：抽象指令注定换来抽象结果
最后一个坑是我自己在自定义指令里犯的错。第一次写的时候我写了“界面要美观大气”，结果生成的 Artifact 确实没什么大问题，但也说不上好看——因为“美观大气”太主观了，模型根本没有可验证的标准。后来我改成“主色使用深蓝 #2D6AFF，圆角统一 8px，字体用系统无衬线字体，卡片阴影用 0 2px 8px rgba(0,0,0,0.1)”，出来的界面立刻有了明确风格。
这条经验对所有需要控制生成质量的人都适用：指令越具体，结果越可控。不要指望模型理解你的审美，把审美翻译成可执行的参数，它就真的能执行。我现在写自定义指令时，凡是涉及视觉、格式、长度、语气的地方，都会在每一个抽象词汇后面补上具体的示例或数值。
最后分享一个我现在默认的工作流：接到任何需要持续迭代的任务，第一件事不是打开聊天窗口，而是新建一个 Project，上传材料，写下可量化的规则；然后把第一版尝试放在 Artifacts 里，后续所有修改都基于它原地迭代。每轮对话结束前，要求 Claude 把当前版本的关键信息整理成一句摘要，方便下一次对话快速知道进度。这套流程在两三周的使用里，帮我省掉了很多重复输入和返工的时间。你也完全可以从小处开始：找一件你最近在重复做的事，建一个项目，把它变成专属大脑，再让 Artifacts 把结果变成能交互、能展示、能带走的东西——试过一轮，你会回来感谢自己的。
