夜雨聆风
你有没有过这种体验——
打开AI，先花十分钟交代："我是一家做某某业务的公司的负责人，我的团队有20个人，我希望你用简洁的中文回答，不要用太多专业术语……"
然后开始干活，干了五分钟，发现AI又忘了你的偏好。下一次对话，重新交代一遍。
十分钟铺垫，两分钟干活。每天都这样。
你觉得是自己的提示词写得不够好，于是去搜"万能提示词模板"，收藏了二十几条，一条比一条长。结果呢？每次还是从零开始。
Anthropic——就是做Claude的那家公司——今年发布了一份官方指南。里面有一句话，直接戳破了这个幻觉：
"如果你的每段新对话都要花十分钟解释你是谁、你在做什么、你想怎么得到答案，那么提示词不是主要问题。你的设置才是。"
这话狠，但它是实话。
提示词焦虑：一个被制造出来的问题
过去两年，"提示词工程"变成了AI时代的第一门必修课。公众号写提示词模板，短视频教你怎么跟AI说话，付费课把"写出完美提示词"包装成核心竞争力。
所有人都以为：用好AI的关键，是说得更准。
但真相是：说得再准，不如让它更懂你。
想象一个场景——你招了一个新人，第一天你花了半小时跟他讲公司做什么、团队怎么分工、项目进度到哪了、你喜欢什么风格的报告。第二天他又来了，问你："不好意思，公司做什么的？"
你会觉得是自己"介绍得不够好"吗？不会。你会觉得：这人没有记忆，没有上下文，每次都像第一次见面。
AI也是这样。你每次打开一个新对话，它就是那个失忆的新人。你写再精妙的提示词，它也只是这一轮的临时指令，下一轮全部清零。
问题不在你说了什么，在于你没给它一个可以记住的地方。
三层搭建法：从聊天框到工作环境
那份Anthropic指南提出了一个清晰的框架。我把它叫做"三层搭建法"。三层解决三个不同的问题，互相支撑但不可替代。
第一层：项目（Projects）——给AI一个工作室
普通聊天是打游击——一次任务，一次对话，做完就走。
项目是建基地——把你的背景、目标、规矩、参考资料统统放进去。AI在这个项目里的每一次对话，都能看到这些材料。
类比
跟一个了解你十年的老同事合作，vs 每次跟陌生实习生重新磨合。前者你知道他懂你的习惯，后者你每次都要从头解释"我不喜欢用表格排版"。
一个项目里应该放什么？不是什么都往里塞。指南说得很明确：五十条模糊的规矩，不如十条清晰的规则。一份精心维护的知识库，胜过一个堆满废弃文档的仓库。
实用的项目知识包括：
● 你在做什么，目标是什么
● 你的受众是谁，他们已经知道什么
● 你期望的输出风格——语气、深度、格式
● 哪些事情AI不该做，哪些事情它必须先问你
● 做到什么程度算"完成了"——验收标准
这些是稳定的、跨对话通用的指导。放进去之后，AI每次开口就有了起点，而不是空白。
第二层：连接器（Connectors）——给AI一把钥匙
上传文档，给AI的是一个快照——那一刻的数据，之后变了它不知道。
连接器给AI的是一个通道——它可以自己去取最新的信息，甚至可以在你授权的情况下执行操作：创建任务、更新记录、检索文档。
类比
你不会让助手每次都跑来问"资料在哪"，你会给他门禁卡，告诉他去哪个柜子找。连接器就是那张门禁卡。
但这里有个关键原则：最小权限。
只连需要的服务，只开必要的权限。AI只需要汇总项目进度？那读取权限就够了。它需要创建任务？开那个操作，但别顺手把删除权限也给了。
连接器还有一个容易被忽略的事实：AI能连上你的系统，不代表它懂你的业务。它能取到数据，但数据背后的含义、你们内部的惯例、某个字段为什么有两种填写方式——这些还得靠项目里的背景知识来补。
钥匙和地图是两回事。给了钥匙，还得给地图。
第三层：技能（Skills）——给AI一本操作手册
很多人以为技能就是"存下来的提示词"。不是。
一个提示词告诉AI"帮我审代码"。一个技能告诉AI：
先查安全漏洞，再看逻辑错误，最后才管格式。
每个发现都要标注位置、说明影响、区分是"必须修"还是"建议改"。
不要顺手改代码，只出报告。最后列出你会跑哪些测试来验证修复。
看出区别了吗？提示词是一个要求，技能是一套方法。
类比
新手厨师做出的菜不稳定，不是食材不好，而是没有标准食谱。有了食谱，每次的出品才可控。技能就是AI的食谱——流程、模板、示例、验证标准，全在里面。
好的技能要窄。"帮我做软件开发"太宽，没法执行。"审查ASP.NET Core API变更的安全性和性能问题"就窄，能稳定重复。
一个好的技能要回答四个问题：
什么时候用？ — 触发条件
需要什么输入？ — 必要材料
按什么流程走？ — 步骤和判断标准
怎么验证结果？ — 完成标准
还有一条：不要把项目里的背景知识塞进技能里。技能描述方法，项目提供上下文。两者分离，才能复用。一份代码审查技能可以给十个不同项目用，前提是每个项目自己放了自己的架构规则。
三层的关系：互撑但不可替代
把三层搞清楚之后，很多事就不纠结了。
把整个代码库塞进技能里？没意义——技能是方法，不是知识库。
把同一份审查清单写进每个项目？冗余——清单应该是技能，项目只放自己的架构规则。
连了仓库却不给架构说明？白连——AI能看到代码但不懂你的设计意图，审查结果一定浮于表面。
三层缺任何一层，效果都会打折。但三层也不需要一步到位。下面会讲怎么落地。
三个被忽略的实操细节
1. 搜索、研究、深度思考不是同一件事
很多人把这三个功能当成"让AI更努力"的三个档位。不是。
搜索是查事实——产品价格、软件版本、今天新闻、某条规定。简单，快，适合"我需要一个最新数字"的场景。
研究是跨源深挖——竞品对比、行业分析、文献综述。它会让AI跑好几轮搜索，比对不同来源，最后给出一份相对完整的报告。慢，但深。
深度思考是推理——信息已经有了，但推理很难。比如调试一个复杂的技术问题，比较两种架构方案的利弊，分析一个商业决策的连锁效应。
查价格用搜索，做竞品分析用研究，推理复杂问题用深度思考。别拿锤子当扳手。
2. 好提示词的五要素
三层搭建到位之后，提示词依然重要。但不是"你是一位拥有30年经验的顶级专家"这种废话——虚构头衔对AI没有任何实质帮助。
一个靠谱的提示词包含五样东西：
任务 — 你要什么结果？
上下文 — 在什么场景、给谁用？
限制 — 哪些不能做、哪些必须排除？
流程 — 应该先做什么后做什么？
验证 — 怎么确认结果是对的？
举个例子对比一下：
弱的："帮我审查这段API代码。"
靠谱的："审查这份API变更。优先看安全漏洞、数据暴露风险、查询性能问题、缺失的测试。格式问题不用管，那些有自动化工具处理。
每个发现都要：标注文件和代码位置、说明运行时影响、区分'必须修'还是'建议改'、给出最小安全修复方案。
不要改代码，只出报告。最后列出你会跑哪些测试来验证。"
第二个提示词给了AI一个明确的标准。也让你的验收变得简单——对照要求逐条检查就行。
3. 初稿不等于终稿
AI写出来的东西，句子流畅、排版整齐、语气得体。看上去很"完成"。
但流畅是廉价的，判断才是昂贵的。
一篇逻辑有漏洞但文笔流畅的文章，比一篇逻辑清晰但写法粗糙的文章更容易骗过你的眼睛。因为流畅会让你放松警惕。
指南建议的做法是把创建和评估分开：
● 先让AI理解任务、提方案，你纠偏——别让它在你还没确认方向的时候一口气写完
● 看初稿时拿验收标准逐条对照——别凭"感觉还行"就放过
● 修改时给具体反馈——"缓存那一段解释清楚，但没说清楚失效时怎么办。加一个数据库更新成功但缓存清除失败的真实例子。其他部分不动。"这比"再改改"有用一百倍
● 最后跑一遍验证——查事实、查链接、查数据、查遗漏
不要指望第一版就是最终版。也不要指望AI自己发现问题。你才是终审，AI只是初稿工。
怎么落地：从一个重复任务开始
看完上面的内容，你可能想：好，那我得把三层全搭起来、连五个系统、写十个技能。
别。
指南最后给了一个极其朴素的建议：从一个你每周都在重复的任务开始。
步骤很简单：
① 建一个项目，放一组简短的项目说明和最核心的参考材料
② 如果这个任务需要实时数据，连一个服务——只一个，只开必要权限
③ 写一个技能，定义清楚流程和验收标准
④ 真跑一次任务，用验收标准检查结果
⑤ 记下AI哪里缺上下文、哪里做了假设、哪里需要你纠正
⑥ 根据这些证据改进项目或技能
跑几轮之后，你就会知道：还需要连什么、还需要加什么知识、哪些技能值得写。在那之前，更多的设置只是装饰。
这也是三层搭建法的底层哲学：最小权限、最小配置、逐步扩展。不是一上来就全开，而是跑出真实需求之后再补。
最后说一句
用好AI这件事，已经被讨论得太复杂了。各种教程、模板、技巧满天飞，好像你得学完一套百科全书才能真正上手。
但Anthropic那份指南的核心结论，其实特别简单：
把稳定的信息放在项目里。
给AI最小必要的外部访问权限。
把重复任务的方法写成技能。
知道什么叫"完成"，然后验收。
你不需要所有功能。你需要正确的上下文、正确的访问权限、和一个清晰的验收标准。
其余的，用起来再说。
— 完 —