1. 为什么大多数人只用了这个工具三成实力我观察到一个很普遍的现象身边不少朋友用 Claude 的方式基本停留在“打开对话框、敲问题、等回复、关掉”这个循环里。问天气、写邮件、改病句、查资料用完就走下次再来又是一张白纸。这种用法当然没问题但它就像买了一台高配工作站却只拿来当计算器——能用但浪费得让人心疼。真正让这个工具从“聊天窗口”变成“生产力中枢”的是两个被严重低估的功能Projects和Artifacts。前者解决的是“记忆”和“上下文”的问题后者解决的是“产出”和“迭代”的问题。把这两个东西用透你的工作流会发生质变——不再是每次从零开始对话而是有一个持续积累、越用越懂你的专属大脑不再是复制粘贴来回倒腾而是直接在对话里生成可预览、可修改、可交付的成品。这篇文章适合三类人一是每天要处理大量文档、代码、方案的知识工作者二是需要反复迭代同一类产出比如周报、设计稿、分析报告的职场人三是想把 AI 真正嵌进日常工作流、而不是当玩具玩的技术爱好者。我会从设计思路、核心机制、实操步骤到踩坑经验把 Projects 和 Artifacts 的高阶玩法拆开讲清楚让你看完就能上手复现。先说结论Projects 是“容器”Artifacts 是“产物”。容器负责装知识、定规则、存记忆产物负责把对话里的内容变成能直接用的东西。两者配合起来才构成一个完整的“专属大脑 输出工厂”闭环。下面我逐层拆解。2. Projects 专属大脑的底层逻辑与设计思路2.1 它到底解决了什么核心痛点普通对话最大的问题是无状态。你这次跟它聊了半小时项目背景关掉窗口下次再问相关问题时它完全不记得你是谁、在做什么、之前定过什么规则。你只能把背景信息一遍遍重新粘贴既费时间又容易遗漏。Projects 的本质是给对话加了一个持久化的上下文层。你可以把它理解成一个“项目文件夹”里面可以放参考资料、写工作规则、存历史结论。每次在这个项目里发起对话它都会自动加载这些内容作为背景。这就好比你去一家常去的理发店师傅记得你的发型偏好、上次剪到什么程度、这次该怎么修——而不是每次进门都要从头描述一遍。这个机制带来的直接好处有三个一致性同一项目内的输出风格和标准统一、累积性知识越存越多回答越来越准、隔离性不同项目的上下文互不干扰避免串味。2.2 为什么是“项目制”而不是“单次对话”我试过两种极端用法一种是所有事情都在一个超长对话里做结果上下文越来越臃肿早期的重要信息被淹没回答质量反而下降另一种是每件事都开新对话结果每次都要重新交代背景效率极低。项目制是这两者之间的最优解。它按“工作单元”来切分上下文——一个持续进行的项目对应一个 Project项目内的对话共享背景项目之间彼此独立。这个设计符合真实工作的组织方式你不会把所有工作混在一起也不会每做一件小事就换一个办公室。从技术角度看这背后涉及上下文窗口的管理。单次对话越长模型需要处理的 token 越多早期信息被“稀释”的概率越大。而 Projects 通过结构化的知识注入而不是靠对话历史堆积让关键信息以更高效的方式进入上下文既保证了记忆又控制了噪音。2.3 一个 Project 里应该放什么这是很多人用不好的关键。我见过有人把 Project 当成网盘什么都往里塞结果背景信息杂乱无章模型反而抓不住重点。我的经验是Project 里的内容分三类各有各的放法第一类是“规则类”内容放在项目指令Project Instructions里。比如输出语言、语气风格、格式要求、禁止事项。这类内容应该精炼、明确、可执行。举个例子“所有回复用中文技术术语保留英文原文代码块必须标注语言类型不要用‘总之’‘综上所述’这类总结词。”这种规则写进去项目内所有对话都会遵守。第二类是“知识类”内容作为文件上传或粘贴到项目知识库。比如产品文档、需求说明、历史数据、参考案例。这类内容体量大、更新频率低适合作为静态背景。第三类是“结论类”内容随着项目推进不断补充。比如某次讨论定下的方案、某个问题的最终答案、某个决策的理由。这类内容需要你主动维护把对话里的重要产出“沉淀”回项目知识库形成正向循环。提示规则类内容要短而硬知识类内容要全而准结论类内容要勤更新。三者混在一起放效果会大打折扣。3. Artifacts 高阶玩法从对话到可交付产物3.1 Artifacts 到底是什么为什么它改变了工作方式如果说 Projects 解决的是“输入”问题Artifacts 解决的就是“输出”问题。传统对话里模型给你一段代码或一篇文章你得复制出来、粘贴到编辑器、保存、预览、发现问题再复制回去改。这个来回过程极其消耗注意力。Artifacts 把这个循环压缩进了对话窗口本身。当模型生成的内容达到一定体量或属于特定类型代码、文档、网页、图表等它会自动把内容放进一个独立的“画布”区域与对话分离。你可以直接在画布里预览、编辑、迭代改完继续对话产物实时更新。这个设计的精妙之处在于关注点分离对话区负责“讨论”画布区负责“成品”。你不需要在聊天记录里翻找那段代码也不需要担心复制时格式错乱。产物始终以一个独立、完整、可操作的形式存在。3.2 哪些场景最适合用 Artifacts不是所有输出都值得放进 Artifacts。我总结了几类最适合的场景场景类型典型产出为什么适合代码开发函数、组件、脚本可预览、可运行、可迭代文档撰写报告、方案、邮件模板结构完整、便于整体修改网页原型HTML/CSS/JS 页面实时渲染、所见即所得数据可视化图表、仪表盘直观呈现、便于调整结构化内容表格、清单、流程图格式清晰、易于复用反过来短问答、简单解释、一两句话的回复就不需要 Artifacts。判断标准很简单如果这个产出你会保存下来、后续还要用、或者需要反复修改就值得放进 Artifacts。3.3 让 Artifacts 真正好用的三个操作习惯第一个习惯是明确指定产物类型。不要只说“帮我写个网页”而是说“用 HTML 和 CSS 做一个单页简历模板包含头部、工作经历、技能标签三个区块”。指定得越具体Artifacts 生成的结构越清晰后续修改越容易。第二个习惯是在画布上直接迭代而不是重开对话。很多人发现产物有问题习惯重新描述一遍让模型重做。更好的做法是在对话里指出具体问题“第三段的字体太小”“这个函数的边界条件没处理”模型会在原有 Artifacts 基础上修改保留你已经满意的部分。这就像改文档用“修订模式”而不是每次重写。第三个习惯是把满意的产物沉淀回 Project。当你迭代出一个满意的模板或组件把它保存到项目知识库里下次同类任务可以直接调用不用从零开始。这就形成了“产出—沉淀—复用”的飞轮。4. 实操过程从零搭建一个专属工作流4.1 第一步创建 Project 并写好项目指令打开工具后找到 Projects 入口新建一个项目。名字要具体比如“周报生成器”“产品需求分析”“前端组件库”不要用“我的项目”这种模糊命名。接下来是最关键的一步写项目指令。我通常按这个模板来写角色你是一个资深的技术文档工程师。 任务根据我提供的要点生成结构清晰、语言简洁的技术文档。 输出要求 1. 使用中文技术术语保留英文。 2. 每个章节必须有编号格式为“## 1. 章节名”。 3. 代码块必须标注语言类型。 4. 不要使用“总之”“综上所述”等总结词。 5. 如果信息不足先提问再动笔。 禁止事项 - 不要编造未提供的数据。 - 不要使用过于口语化的表达。这段指令的作用是给项目内的所有对话定基调。写完之后你可以先发一条测试消息看看输出是否符合预期不符合就调整指令直到满意为止。4.2 第二步上传知识库文件项目指令定好规则后接下来填充知识。点击项目里的“添加内容”或类似入口上传相关文件。支持的类型通常包括文本、PDF、代码文件等。上传时有个技巧给文件起清晰的名字。比如“2024Q3产品需求文档”“用户反馈汇总”“竞品分析报告”。模型在检索知识时文件名是重要的索引线索。如果文件名是“文档1”“新建文件”模型很难判断该在什么场景下调用它。另一个技巧是控制单文件体量。如果一个文件特别大比如几百页模型可能只能抓取部分内容。更好的做法是按主题拆分成多个小文件每个文件聚焦一个子话题。这样检索时命中率更高回答也更精准。4.3 第三步在项目内发起对话并触发 Artifacts知识库准备好后就可以在项目内发起对话了。这时候你会发现模型已经自动加载了项目指令和知识库内容回答会明显更贴合你的需求。触发 Artifacts 的关键是让产出达到“值得独立呈现”的体量。比如你说“帮我写一个用户登录页面的 HTML”模型大概率会生成一个 Artifact。但如果你说“登录页面一般包含哪些元素”它就只会用文字回答。我实测下来以下指令最容易触发高质量的 Artifacts“用 HTML/CSS/JS 实现一个……”“写一个完整的 Python 脚本功能是……”“生成一份包含以下章节的文档……”“把这个数据结构用表格呈现出来……”生成后画布区会出现产物预览。你可以直接在画布上查看效果然后在对话区提出修改意见。4.4 第四步迭代、沉淀、复用产物生成后进入迭代循环。我的做法是先看整体结构对不对再看细节。结构问题用一句话指出“把第二部分和第三部分调换顺序”细节问题具体到位置“表格第三列的宽度太窄内容换行了”。迭代到满意后做一件很多人会忽略的事把最终产物保存回项目知识库。比如你把一个周报模板迭代得很完美就把它作为“周报模板 v1”存进项目。下次写周报时直接说“用周报模板 v1 的格式填入本周要点”效率直接翻倍。这个“沉淀”动作是区分普通用户和高阶用户的分水岭。普通用户每次从零开始高阶用户让每次产出都成为下一次的起点。5. 常见问题与排查技巧实录5.1 项目指令写了但模型不遵守怎么办这是最常见的问题。原因通常有三个一是指令太长太杂模型抓不住重点二是指令之间有冲突三是指令和当前对话的具体要求矛盾。排查思路先把指令精简到 5 条以内每条只讲一件事。然后检查有没有互相矛盾的地方比如既要求“简洁”又要求“详细展开”。最后看具体对话里有没有覆盖指令的要求如果有以具体对话为准。我的经验是指令要写成“硬约束”而不是“软建议”。不要说“尽量用中文”要说“必须用中文”。不要说“可以加编号”要说“每个章节必须加编号”。模型对明确指令的遵守度远高于模糊建议。5.2 Artifacts 生成的内容格式错乱格式错乱通常发生在代码类产物上。常见表现是缩进丢失、标签不闭合、样式不生效。排查步骤检查对话里有没有明确指定语言和框架版本。检查产物是否被截断体量太大时可能只生成了一部分。在对话里指出具体错误位置让模型针对性修复。一个实用技巧是要求模型在生成前先说明技术选型。比如“你打算用原生 JS 还是框架样式用 Flex 还是 Grid”确认后再生成格式问题会少很多。5.3 项目知识库内容多了之后回答变慢变差这是上下文过载的典型症状。知识库不是越多越好而是越精准越好。我的处理方式是定期做“知识库体检”问题表现可能原因处理方式回答变慢知识库文件过多过大删除过期文件拆分大文件回答跑偏知识库内容互相矛盾合并重复内容标注版本抓不住重点文件命名模糊重命名为具体主题名忽略新内容旧内容权重过高删除或归档旧版本注意知识库维护是一个持续动作不是一次性工作。我一般每两周清理一次把不再相关的文件归档保持知识库“轻装上阵”。5.4 不同项目之间内容串味正常情况下项目之间是隔离的但如果发现串味检查两个地方一是确认当前对话确实在目标项目内发起而不是在通用对话里二是检查项目指令里有没有引用其他项目的内容。隔离机制本身是可靠的串味基本都是人为操作导致的。5.5 产物无法导出或复用Artifacts 的产物通常支持复制和下载。如果遇到无法导出的情况先确认产物类型是否支持导出有些交互式内容可能只支持预览。如果确实需要复用最稳妥的方式是把产物内容复制出来保存到本地或项目知识库。我个人的习惯是重要的产物一定在项目知识库里留一份“母版”画布里的产物只是工作副本。这样即使对话丢失母版还在随时可以重新调用。6. 把工具用成“外脑”的几个关键认知用了大半年这套工作流我最大的体会是工具的上限不取决于它有多少功能而取决于你把它放在工作流的什么位置。如果你把它当聊天窗口它就只是个更聪明的搜索引擎如果你把它当项目容器和产出工厂它就能成为你真正的“外脑”。Projects 的价值在于“记住”Artifacts 的价值在于“做出”。两者结合形成的是一个持续运转的循环知识输入—规则约束—对话产出—产物迭代—沉淀复用。这个循环转起来之后你会发现很多重复性工作被压缩了注意力可以集中在真正需要判断和创造的地方。最后分享一个我踩过坑才明白的道理不要追求一次就把项目指令和知识库做到完美。我一开始花了大量时间设计“完美”的项目结构结果实际用起来发现很多预设根本用不上。更好的方式是先用最小配置跑起来在用的过程中逐步补充规则、上传文件、沉淀产物。让项目跟着你的实际需求生长而不是一开始就搭一个空架子。这个内容后续还可以这样扩展把多个 Project 串联起来形成一个跨项目的协作网络——比如一个项目负责需求分析一个项目负责方案撰写一个项目负责代码实现产物在项目之间流转。这个玩法我还在摸索等跑通了再单独写一篇。