你有没有发现身边用 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 把结果变成能交互、能展示、能带走的东西——试过一轮你会回来感谢自己的。