1. 从“技能堆砌”到“精准工程”一次AI应用范式的反思最近AI圈子里有个讨论挺有意思源头是A社这里我们心照不宣地指代Anthropic官方发布的一个消息大意是说他们删掉了自家产品中大约80%的预设“skills”。这个消息一出结合最近围绕Claude、Claude Code以及各种“skills”的热度让我这个在AI应用开发一线折腾了快十年的老码农忍不住想停下来好好聊聊这件事背后的门道。这绝不仅仅是一个功能更新公告它更像是一个强烈的信号标志着我们使用大模型的方式正在从一个“功能超市”的草莽时代走向“精准工程”的理性时代。如果你也关注过Claude Code的安装、各种skills的推荐与下载或者为“system prompt与function call区别”这类问题头疼过那么你很可能正处在那个“堆砌技能”的阶段。我们总希望手里的AI助手无所不能于是到处搜集“神级”system prompt安装五花八门的skills插件试图用一个“超级提示词”解决所有问题。但结果往往是提示词越来越长上下文窗口被无关信息挤占AI的理解反而变得模糊输出质量不稳定甚至出现“精神分裂”——因为不同技能之间的指令可能会互相冲突。A社这个“删掉80% skills”的动作在我看来是一次非常勇敢且必要的“断舍离”。它背后的核心逻辑是少即是多精准胜过庞杂。这直接指向了当前AI应用开发特别是智能体Agent构建中的一个核心议题上下文工程Context Engineering。今天我就结合自己踩过的无数坑来拆解一下这个转变意味着什么以及我们作为开发者或深度用户应该如何调整自己的策略从盲目收集“技能包”转向系统地构建“工程化上下文”。2. 理解“Skills”的本质是能力扩展也是上下文负担在深入讨论“删除”之前我们得先搞清楚在Claude这类大模型的应用语境里“skills”到底是什么。根据我的实践和理解它并不是一个严格的技术术语而更像是一个产品层面的抽象概念通常指代以下几类东西2.1 预设的系统提示词System Prompt模板这是最常见的形式。比如一个“代码审查skill”本质上就是一个精心编写的system prompt告诉模型“你现在是一名资深代码审查员请专注于检查代码的安全性、可读性和性能并以特定格式给出建议。” 用户启用这个skill就等于把这个长篇的、特定领域的指令注入到了对话的上下文开头。2.2 封装好的函数调用Function Calling或工具使用能力在一些更高级的框架或插件如Claude Code、Cursor中的某些功能里“skill”可能代表一组预定义的工具。例如一个“网络搜索skill”背后可能封装了调用Serper API或 Tavily Search的函数。当用户提出需要最新信息的问题时模型可以自动调用这个skill背后的函数来获取数据。2.3 特定领域知识或风格的微调提示还有一些skills旨在让模型模仿特定的写作风格如“中文小说家skill”或者掌握某个垂直领域的知识如“产品经理skill”。这通常也是通过一个高度特化的system prompt来实现的引导模型在特定语境下思考和回应。那么问题出在哪里问题就在于“堆砌”。每个skill无论其形式如何本质上都是一段需要被模型“消化”的文本指令或规则。当你同时激活多个skills时会发生以下几件事上下文污染与指令冲突模型需要同时处理来自不同skill的、可能相互矛盾的指令。比如“代码审查skill”要求严谨、挑剔而“创意写作skill”鼓励发散、包容。让模型同时扮演这两个角色它就会陷入混乱输出变得不伦不类。有效上下文窗口被挤占大模型的上下文窗口是宝贵的资源。每一个字符的system prompt、每一个skill的描述都在消耗这个窗口。当80%的上下文都被固定的、可能用不到的skill指令占据时留给实际任务对话和思考的空间就所剩无几了。这直接导致模型无法处理复杂、长篇的任务或者容易遗忘对话早期的关键信息。性能与成本问题更长的上下文意味着更长的处理时间和更高的API调用成本对于按Token计费的服务。加载一堆用不上的skills纯粹是浪费资源和金钱。维护与调试噩梦当你的应用行为异常时你需要在一大堆交织在一起的skill指令中定位问题根源这比调试单一、清晰的指令要困难得多。A社删除那80%的skills很可能就是删除了那些使用率极低、过于细分、或容易与其他技能产生冲突的预设模板。这是一种“壮士断腕”目的是为了保障核心用户体验的清晰、稳定和高效。3. 从“Skills”思维转向“上下文工程”思维既然盲目堆砌skills行不通那正确的道路是什么答案就是“上下文工程”。这个词最近很火但它不是什么玄学而是一套系统化、可重复的方法论旨在为特定任务设计最优的上下文环境主要是system prompt和对话结构以最大化模型的性能。我们可以把大模型想象成一个能力超强但需要明确指引的实习生。堆砌skills就像扔给他一本厚厚的、目录混乱的《员工全能手册》指望他什么都会。而上下文工程则是针对他今天要做的“撰写季度市场报告”这个具体任务专门准备一份清晰的任务简报、相关的数据表格、报告范例以及检查清单。3.1 上下文工程的核心原则任务单一性原则一次只让模型专注于一件事。不要试图用一个提示词让模型既写诗又debug。如果需要多步骤任务应该将其拆解通过多次、有结构的对话来完成。指令清晰、无歧义原则使用明确、具体的语言。避免“更好”、“高质量”这类模糊词汇。用“输出格式为Markdown表格包含‘问题’、‘根因’、‘建议’三列”来代替“请详细分析”。角色与边界定义原则明确告诉模型“你是谁”例如“你是一名经验丰富的SRE工程师”以及“你的权限是什么”例如“你只能分析提供的日志不能执行任何系统命令”。这能有效约束模型的幻想提高输出的专业性。结构化思维链Chain-of-Thought引导原则对于复杂问题在prompt中鼓励或要求模型“逐步思考”。例如“请先分析问题现象再推测可能的原因最后给出验证步骤和解决方案”。这能显著提升推理的准确性和逻辑性。示例驱动原则Few-Shot Prompting对于格式固定或风格要求严格的任务直接给出一两个输入输出的例子比用一百句话描述更有效。这就是“Show, don‘t tell”。3.2 一个实战对比旧“Skills”模式 vs. 新“工程化”模式假设我们需要让AI协助进行代码重构。旧模式启用多个Skills启用“资深程序员skill”。启用“代码重构skill”。启用“代码审查skill”。然后提问“请重构这段代码。”结果模型可能同时受到多个泛化指令的影响输出混杂了风格建议、安全警告、重构手法重点不突出且可能遗漏关键的重构目标如提高性能。新模式上下文工程你是一个专注于Python代码性能优化的专家。你的任务是对用户提供的代码进行重构唯一目标是提升其运行效率。 重构时请遵循以下步骤 1. 首先分析原代码的时间复杂度和潜在性能瓶颈。 2. 其次提出具体的重构策略例如使用更高效的数据结构、避免重复计算、利用向量化操作等。 3. 最后输出重构后的完整代码并在关键修改处添加注释解释为何这样修改能提升性能。 输出格式 ## 性能分析 [你的分析] ## 重构策略 [你的策略] ## 重构后代码 python [你的代码]现在这是需要重构的代码 [用户粘贴代码]* **结果**模型的注意力被高度聚焦在“性能优化”这个单一目标上思考过程被结构化输出格式清晰直接给出了可落地的结果。这个对比清晰地展示了一个精心设计的、任务特定的上下文其效果远胜于启用一堆泛化的、可能相互干扰的“技能”。4. 构建属于你自己的“超级上下文”实操指南与工具理解了理念我们来看看具体怎么做。放弃寻找“万能skill”开始构建你自己的可复用上下文模块。4.1 第一步任务拆解与角色定义在写任何prompt之前先回答这几个问题核心任务是什么一句话说清成功的标准是什么可衡量的输出AI需要扮演什么角色专家、助手、评审它需要知道哪些边界信息不能做什么格式要求参考风格例如针对“写作技术博客引言”的任务核心任务根据技术主题和要点撰写吸引人的博客引言。成功标准引言包含痛点场景、点明主题价值、引发读者兴趣字数在150-250字。角色技术社区资深布道师。边界语言口语化、避免学术腔、不出现未来展望式套话。4.2 第二步设计系统提示词System Prompt这是上下文工程的核心。一个好的system prompt是自包含的、清晰的、可执行的。它通常包含以下部分身份与使命明确角色和核心任务。工作流程给出思考或行动的步骤Chain-of-Thought。输出规范严格定义格式、长度、语言等。风格与语气定义输出的文风。约束与禁忌明确禁止做的事情。一个用于技术博客引言生成的System Prompt示例你是一名在[某技术领域如前端开发]有十年经验的资深技术布道师擅长用通俗易懂的语言向开发者分享干货。你的任务是为一篇技术博客撰写开篇引言。 写作流程 1. 首先理解用户提供的博客核心主题与关键要点。 2. 然后构思一个目标读者中级开发者最常见的、与主题相关的痛点或困惑场景。 3. 接着自然引出这篇博客将要解决的问题或带来的价值点明主题。 4. 最后用一句话激发读者的阅读兴趣暗示文章中有“避坑指南”或“性能提升秘籍”等实用内容。 写作要求 - 语言口语化、亲切像朋友间分享经验。使用“我遇到过”、“你会发现”这样的句式。 - 结构遵循“场景痛点 - 引出主题 - 预告价值”的逻辑。 - 字数严格控制在150-250字之间。 - 禁忌绝对不要使用“随着技术的发展”、“本文将介绍”、“综上所述”等套路化表达。禁止空泛的展望。 你的输出就是且仅是这篇引言正文不需要任何额外说明。4.3 第三步利用工具进行管理与复用你不需要每次都手动输入长篇的system prompt。现代AI工具已经提供了很好的管理能力Claude Desktop / Claude Code它们通常支持自定义的“预设提示词”或“工作空间设置”。你可以把上面设计好的、针对不同任务代码审查、写作、头脑风暴的system prompt保存为不同的预设。使用时就像选择不同的“工作模式”一样切换而不是加载一堆skills。Cursor IDE在Cursor中你可以通过.cursorrules文件来为特定项目或目录定义AI行为规则这本质上就是一种项目级的、持久化的上下文工程。文本片段管理工具使用像Espanso跨平台文本扩展、TextBlaze或IDE自带的代码片段功能将你精心设计的prompt模板保存为快捷短语。例如输入;blogintro就自动展开为上面那个完整的博客引言生成prompt。4.4 第四步迭代与优化——你的“技能”在进化上下文工程不是一劳永逸的。你的prompt需要根据使用反馈持续优化。收集失败案例当AI输出不符合预期时不要简单重试。分析是哪个环节的指令不清导致了歧义是角色定义模糊还是流程步骤有漏洞A/B测试对于同一任务设计两个略有不同的prompt比如一个强调步骤一个强调示例对比输出结果找到更优解。抽象与模块化当你积累了多个优秀的prompt后你会发现其中有一些可复用的模块。例如“逐步思考”这个指令或者“输出格式为Markdown表格”这个要求可以抽象出来作为你设计新prompt的通用组件。通过这种方式你不再依赖别人提供的、未必适合你场景的“黑盒skills”而是建立起一个属于你自己的、不断进化的、高度适配你工作流的“上下文工具箱”。这才是真正的“超级技能”。5. 针对热门搜索词的具体分析与避坑指南结合你提供的热搜词很多困惑其实都源于“skills思维”的惯性。我们来逐一拆解“system prompt与function call区别”这是两个不同层面的概念。System Prompt是对话开始前设定的“角色说明书”和“基础规则”它定义了AI的初始状态和行为框架会持续影响整个会话。Function Calling是模型在对话过程中根据用户请求和自身能力判断主动调用外部工具如查天气、搜数据库的一种机制。你可以把system prompt理解为公司的规章制度和岗位描述而function calling是员工在具体工作中根据规章和岗位要求去使用计算器、查阅档案等具体工具的行为。一个设计良好的system prompt里可以包含对function calling的使用规范和引导。“Claude Code安装/使用教程” “Virtual Machine Platform not available”Claude Code通常作为一个本地或远程开发环境它本身可能依赖虚拟机技术如WSL2 on Windows来提供隔离的容器环境。Windows上报错“Virtual Machine Platform not available”或“requires the virtual machine platform”根本原因是系统未启用相关虚拟化功能。解决方案这不是一个Claude Code或skills问题而是系统环境问题。你需要进入BIOS/UEFI设置确保CPU的虚拟化技术Intel VT-x / AMD-V已启用。在Windows功能中开启“Hyper-V”和“Windows虚拟机监控程序平台”。如果使用WSL2确保已安装并设置为默认版本。核心教训在追逐各种炫酷的AI工具和skills之前先把基础运行环境搭建扎实。很多问题与AI无关而是基础的开发运维问题。“AI Skills怎么写” / “Skills开发”现在你应该明白与其问“怎么写一个skill”不如问“如何为[某个具体任务]设计一个高效的上下文”。开发重点从“起一个酷炫的技能名和描述”转向了深度理解任务这个任务的输入、输出、流程、边界是什么精准定义角色什么角色最适合完成这个任务设计清晰指令如何用最无歧义的语言描述步骤和格式提供优质示例能否提供一两个完美的输入输出对作为范本 这个过程更像是在编写一份极其详尽、且能被AI完美执行的“任务说明书”而不是在赋予它一个模糊的“超能力”。“Superpower Skills 安装” / “Skills推荐”我建议你停止寻找和安装这类“超级技能包”。它们的通用性注定会带来前述的各种问题。取而代之的是去观察和逆向工程那些让你觉得惊艳的、在特定场景下效果很好的AI交互案例。分析它的prompt可能是什么样的它的对话结构是如何引导的然后把这种思路应用到你自己的任务设计中去。这才是有效的学习。“Cursor能用Skills吗”Cursor等智能IDE集成了AI但其设计哲学更偏向于“深度理解代码上下文并提供辅助”而非“加载各种技能”。它通过分析整个项目文件、打开的文件标签来构建上下文这本身就是一种强大的、隐式的上下文工程。在Cursor里与其寻找skills不如学会如何通过清晰的代码注释、规范的函数命名、以及有目的性的提问例如在代码块上方用注释写明“请重构这个函数以提高可读性”来更好地利用其内置的AI能力。6. 总结拥抱精准放弃幻想A社删除80%的skills是一个具有象征意义的行业动作。它告诉我们大模型应用的初级阶段——那个靠猎奇和堆砌功能吸引用户的阶段——正在过去。无论是平台方还是我们使用者都在走向成熟。对于平台方这意味着产品设计需要更聚焦于提供稳定、强大的基础模型能力以及灵活、易用的上下文管理工具如可自定义的预设、项目级配置而不是维护一个庞大而臃肿的“技能商店”。对于我们每一个开发者或深度用户这意味着我们需要进行一次思维升级从“收集者”变为“设计师”停止四处搜罗“神奇咒语”开始学习如何为你自己的具体问题设计“精准蓝图”。从“求多”变为“求准”一个为你的任务量身定制的、200字的优质prompt其价值远胜于10个加起来2000字的通用skills。从“黑盒依赖”变为“白盒构建”理解上下文工程的原理让你能解释AI为什么这样输出也能在它出错时快速调整你的“设计图”。重视基础环境与数据再好的prompt工程也需要运行在稳定的环境和高质量的数据输入信息之上。确保你的代码、文档、提问本身是清晰的。这条路听起来比直接安装一个skill要麻烦但它带来的回报是确定性和高效率。当你通过精心设计的上下文让AI稳定地输出符合你预期的、高质量的结果时你会感受到那种“一切尽在掌握”的踏实感。这或许才是人机协作真正走向深度的开始。别再迷恋那个看似无所不能的“技能超市”了拿起你的“工程设计图”开始为你和AI的协作搭建那个最精准、最高效的工作台吧。