★ FEATURED ARTICLE 最近有一份33页的文档在AI圈传得挺火Anthropic内部关于Claude使用方式的技能手册。我认真读了两遍相关的公开讨论又照着里面的方法论实际试了一周最大的感受是——这份手册最核心的一句话恰恰是很多人最意外的一句别让它动手。不是让Claude多干活而是别让它直接动手。这两个方向的差别解释了为什么同样是使用Claude与Skills有人又快又稳有人却总在收拾烂摊子。如果你正在用Claude或Claude Code做开发、写内容、搭自动化流程或者只是好奇AI编程工具到底该怎么用这份手册背后的逻辑都值得花几分钟琢磨。它不是在教你放弃自动化而是在教你划清楚自动化的边界。1. 手册里的核心反直觉Claude 被定位成参谋而非执行人1.1 别让它动手反对的到底是什么很多人一看到别让它动手就想那要Claude干什么其实这里说的动手指的是让AI直接执行那些有后果、有累积错误、难以撤回的操作。比如直接在工作目录里批量改文件、直接跑部署命令、直接提交发布、直接修改全局配置。这些操作的问题在于它们本质上是不可逆动作叠加多步决策。对语言模型来说单次生成一个代码片段是它的强项但让它从头到尾自主决定改哪些文件、怎么改、改完怎么验证每一步都有出错概率多步累积下来成功率会指数级下跌。我自己就栽过跟头。有一次让AI帮忙做代码重构指令是把项目里的回调改成async/await听起来目标很明确对吧结果它一口气改了三十多个文件其中两个地方依赖被改掉的函数签名整个测试直接崩了。关键不是它改得不对而是当AI一口气改很多的时候错误被放大了而且你很难追踪错误到底从哪一步开始。手册里的别让它动手本质上是在说把Claude当作战术参谋它可以出方案、给代码、标影响范围但扣扳机的必须是你。1.2 为什么这个观念和主流 AI Agent 宣传正好相反市面上好多AI工具都在宣传全自动、让你彻底解放双手Anthropic内部手册里反而强调保守这其实反映了他们对可靠性边界的清醒认知。我经常用一个比喻来理解这件事Claude像一个天赋极高但入职第一天的实习生。你让他写一份调研报告他可能比老员工写得还漂亮但你直接让他去对接客户、修改生产库、给全公司发通知你敢吗不敢。因为他还不熟悉你的业务规则、不知道哪些雷不能踩、更没法对自己的行为负责。AI也是同样的道理。Anthropic内部之所以把建议权和执行权分开是因为他们对质量要求极高一份方案错了可以马上改但推送到生产环境的东西错了影响的是真实用户。所以手册里的做法是让Claude把方案做得足够详细把代码写得足够完整把风险点标注得足够清楚然后由人来做最终确认。这不是不信任AI而是信任AI的方式更务实——把它最强的能力生成与推理用满把它最弱的能力自主承担后果交给人类兜底。1.3 手册对人类角色的重新定义不是监工是决策者这里有一层很容易被忽略的意思手册不只是给AI立规矩也在给使用AI的人重新定位。你不再是操作员每步都手动敲命令也不是甩手掌柜全程放手让AI跑而是决策者批准方向、把控风险、验收结果。这个角色转换非常关键。如果你是操作员心态你会觉得AI给的方案反正比你自己想得快于是逐渐放松审查最后被小错积累拖垮如果你是甩手掌柜心态你会把AI的一次性失误放大成巨大的返工成本。只有切换到决策者心态你才会在每一个关键节点认真问自己这个方案真的要批准吗影响范围我清楚吗回滚路径准备好了吗说白了手册并非教你怎么管住Claude而是教你怎么承担起使用AI的责任。一场协作里AI负责提供高质量的可能性你负责挑选可能性并承担后果这才是真正的人机分工。2. Skills 体系的底层设计让 Claude 知道该做什么而不是放权随便做2.1 Skills 到底是什么和普通 Prompt 的实质区别如果说别让它动手是手册的第一层核心那第二层核心就是对Skills的定位Skills是用来给Claude装知识的而不是用来放权限的。热搜词里大量出现skills大全skills下载平台前端开发skills分镜skills说明很多人已经意识到Skills很关键但理解上容易走偏。简单说Skills是一组预先编排好的专业方法包里面包含领域知识、操作规范、输出模板和边界规则。普通Prompt是一次性的指令Skills则是可复用的能力模块。对比维度普通 PromptSkills使用方式每次手动输入按需加载或自动触发内容构成一段话指令知识流程模板边界规则打包稳定性每次效果不稳定收敛到一套成熟流程适用场景临时、非高频任务高频、有强流程要求的任务打个比方普通Prompt是你口头吩咐新人帮我把这个表做一下Skills是你甩给他一本《本部门周报编制规范》里面写了数据来源、图表格式、检查清单、常见错误。后者当然更稳。2.2 手册里对 Skills 使用边界的态度约束比能力更重要手册里有一个让我印象很深的原则Skills应该规定Claude能获得什么信息、按什么格式输出、不能越界做什么而不是只告诉它你可以做到这些。Anthropic在内部使用Skills时偏好把约束写得非常具体。比如一份代码审查Skills里面可不止如何审查的流程还会清清楚楚写出这样几条只能提出修改建议不能直接改动仓库里的文件涉及安全敏感模块时必须标记为高风险交由人工复核给出的每条建议必须对应到具体代码行不允许笼统评价这种设计逻辑的本质是用Skills给Claude装上行业知识和行为约束让它从一个能说会道但没边界的模型变成一个懂规矩、知进退的协作者。很多人把Skills当成某种外挂装上后以为AI就什么都能干了。其实Skills真正的价值在于把不确定的黑盒变成可控的灰盒它依然可能出错但出错的范围、方式和速度都在你预设的轨道里。2.3 怎么判断一份 Skills 值不值得用既然热搜词里都在找skills推荐skills安装包这里有必要多说几句。我见过不少朋友一口气装了十几个Skills结果大部分在吃灰甚至有的互相打架。判断一份Skills值不值得用我一般看三点。第一它解决的是不是你自己高频遇到的问题。你天天写前端「前端开发Skills」就很有用你一个月才用一次那临时写Prompt反而更灵活没必要多一层依赖。第二它的规则是否清晰。一份好的Skills会明确说明输入、输出、边界、注意事项而不是堆砌形容词和空话。拿到Skills先读一遍规则段如果读完之后你依然不知道那我到底该拿它做什么这技能包多半是水的。第三它会不会拦截你的关键决策。如果发现用了某个Skills之后AI开始自动执行原本应该由你来确认的操作——比如直接改文件、直接外发消息、直接安装依赖——那就要警惕了。这种Skills违背了手册里别让它动手的精神风险很高。3. 从手册拆解内部工作流方案先行、人工审批、小步验收3.1 第一步先让 Claude 出方案而不是直接开工Anthropic内部的实际工作流第一步通常是方案对话。他们会要求Claude先分析需求、列出可能的做法、标出不确定的地方、给出推荐方案以及备选方案。在这一步Claude动的是嘴不是手。我们平时用Claude也应该照搬这个逻辑。比如你想让它帮你重构一段Python代码规范的提问方式是这样先不要改任何代码。请你分析当前实现存在的问题列出三种改进方案并就每种方案说明改动范围、迁移成本和风险点最后给出你的推荐及理由。而不是帮我把这个重构了。两种问法在Claude看来有本质区别。第一种把它限制在献策者角色它会用更多推理篇幅去权衡利弊第二种它可能直接一个版本改完扔给你改得对不对你自己去测试。实践下来第一种看起来慢实际总耗时更短——因为你省掉了大量的返工和排查时间。这套逻辑不只在代码场景成立。写方案、做研究、排日程也一样先让它提交一份作战计划你看完再决定是让它展开细节还是让你自己接手写。凡是涉及多步骤、几步骤之后可能有分叉的任务方案先行永远优于立刻执行。3.2 第二步人工审批点到底设在哪里手册里最值得普通用户学的就是人工审批点的设计。你不需要所有环节都盯着Claude更不需要完全放手而是在几个关键节点插入强制确认。拿我最近在走的Claude Code小步开发流程举例审批点我会这样设置环节Claude 的产出人工审批动作需求理解需求文档与任务拆解确认它是否真正理解了目标方案设计技术方案 / 改动清单确认技术选型与影响范围实现阶段每个小功能的代码小步提交前人工review测试验证测试用例建议 / dry-run 结果决定是否允许进入正式环境这里的关键不是每个步骤都要审批而是可能产生不可逆影响的操作必须有审批。推送、发布、覆盖文件、删除数据、批量发消息这些必须卡人。而生成草稿、整理要点、总结会议记录这类无副作用的操作大可以放手让Claude随便跑。顺便说一句Claude Code里有个常用功能叫自动接受工具调用默认建议别全开。你可以在配置里把它调成每次都问一下虽然多点几次确认但换来的是你对整个工作流状态的掌控感值。3.3 第三步小步执行并设定可回滚边界如果你确实需要Claude动手做些事手册的做法是圈定一个明确的小范围并且保证可回滚。几个我实测管用的约束只允许在feature分支上修改不给master分支的写权限运行前必须生成变更diff人过一眼再合并涉及第三方API调用或资金数据时只允许生成测试用例不允许直接操作生产数据所有自动执行先开dry-run模式看它准备做什么再决定放不放行。这些约束听起来像工程管理的基本素养但在AI协作里很容易被忽略。因为AI给你一种很全能的错觉你在它身上放权就像让一个能力很强但还不熟悉你业务的实习生直接管生产环境——多半会出事。我实测过最稳的执行粒度是一次让它改不超过三个文件每个文件改动控制在几十行以内然后立刻测试、验证、提交。改得越小出了问题越容易定位。这种小步快跑的节奏看起来不酷但长期下来返工率极低。3.4 一个完整的端到端案例用 Claude 做新功能开发为了让你把上面三条串起来我用一个实际案例演示方案先行—人工审批—小步执行怎么走。假设我要做一个新功能给博客加一个相关文章推荐模块。我不会上来就说帮我实现这个功能而是分四步。第一步方案。我让Claude先分析推荐算法有哪几种可选标签匹配、协同过滤、向量相似度各自对博客这种低数据量场景的适配度如何需要引入哪些依赖对现有架构的影响面在哪里。它给了方案我挑了最简单的标签匹配。第二步拆解。我批准方案后让Claude把任务拆成小步骤数据模型、查询逻辑、展示组件、测试用例。并且约定好每一步只给代码建议由我决定何时写入项目。第三步逐个实现。我每次只问一个子任务比如基于标签匹配算法给出查询相关文章的SQL和Python代码注意排除当前文章。拿到代码后我review、测试、提交再问下一步。第四步验证。我让Claude先给出一份测试用例清单说明覆盖哪些边界情况。我看完觉得不够又补了一条没有任何标签重叠时的兜底逻辑。整个过程Claude生成的代码占了八成以上但每一步的开关都在我手里。最终功能上线很顺利没有一次大的返工。这就是别让它动手策略在实践中该有的样子。4. 落到我们自己手中的四类用法把高级顾问价值榨出来4.1 用法一把 Claude 当方案评审员而不是代写机器这是我最推荐的入门用法。不要一开始就让Claude帮你从零写一个完整系统而是让它审你已有的代码、文章、方案。让它找问题、指风险、给改进建议你决定改哪些。这样做有三个好处第一你对现状的理解不会丢不会被AI带着跑偏第二Claude建议的质量通常比凭空输出高很多因为它有具体上下文可以参考第三万一它建议错了你多半也能发现因为你知道现状的来龙去脉。我每天都会把刚写完的代码贴给Claude加一句请以资深工程师视角做code review先不要修改原始代码只列出问题清单、风险等级、修改建议按优先级排序。它的回复通常很具体而且不会自作主张把代码全改掉。这种做法几乎完美契合手册的精神Claude输出专业判断人类执行最终修改。4.2 用法二把高频经验沉淀成自己的 Skills 包既然大家都在搜Skills下载那我顺带说一下怎么自己做一个简单可用的Skills。不需要多复杂三步就够。第一步找重复任务。比如你每周都要写数据分析周报每次都要重复交代格式、数据来源、图表风格。这种任务最适合做成Skills。第二步封装经验。把做这个任务需要遵循的步骤、参考标准、输出模板、易错点写清楚。这就是Skills的核心内容。比如一份数据分析周报Skills可以包含必须用哪些数据源、图表必须配文字结论、每部分字数上限、常见的数据口径错误。第三步配置成技能。在Claude Code或桌面端里把这份内容打包成专门的指令集设置触发条件或按需加载。以后说一句用周报技能生成这周的分析它会自动按你的流程走不需要每次重新解释背景。这和Anthropic内部把企业知识打包成Skills的思路一模一样只是规模不同。如果你手里还没有自己的Skills强烈建议从一件你每周重复做的事情开始做完之后你会明显感受到模板化协作和每次从零讲起的效率差距。4.3 用法三Claude Code 的正确姿势——先问再小步做Claude Code近期热度很高热搜词里大量出现claude code安装claude code使用vscode配置claude code说明很多人正在尝试这条路。但安装配置只是第一关真正拉开差距的是使用姿势。我总结了一套适合大多数人的姿势六句话先描述全局背景再问具体任务让Claude先列计划确认后再动手坚持小步提交一个改动配一个说明所有高风险操作改成手动确认测试案例永远让Claude先给你来决定跑不跑出错时把完整报错贴回去别只贴最后一行。用这个姿势跑了一段时间后你会明显感受到它比直接放权省心得多。不是AI不行而是人机协作需要节奏感。过早放权等于把方向盘交给了还不熟悉路况的副驾驶它技术再好你也心慌。4.4 用法四本地模型、隐私场景下的取舍热搜词里还有一条很有意思claude code 调用lmstudio的本地模型。对隐私要求高的场景不少人确实会把Claude Code接到本地模型上跑。这条路我也试过能跑通但有两个结论必须提醒。第一本地模型的推理能力通常比官方Claude有差距所以前面说的方案先行、人工审批、小步执行这套流程要执行得更严格。本地模型更容易偏离轨道人工把关的密度必须更高不能因为它跑在自己电脑上就觉得安全。第二Skills体系在本地模型上不一定完整兼容有些人能把一些复杂Skills跑出像样的效果有些则明显变差。遇到后一种情况别急着怪Skills写得不好先判断一下模型本身的指令遵循能力是否够用必要时把Skills拆得更简单减少复杂指令嵌套。4.5 普通用户最容易踩的三个坑结合我自己的经历和网上大量反馈三个最典型的坑列出来你们对照一下自己有没有中招。坑一一上来就全自动。很多人装完Claude Code第一件事就是让它自己搞定整个项目结果改出一堆不兼容代码然后责怪AI不行。其实问题不在AI而在你跳过了方案确认这个环节。全自动模式适合无人值守的简单任务不适合有技术债、有历史包袱的项目。坑二盲目堆Skills。看到skills大全就全装上我此前也干过最后发现很多Skills互相冲突同类问题两个技能包抢着响应。之后我只保留真正高频使用的三五个每个都有明确的触发条件效果反而大幅提升。坑三把Claude当成搜索引擎。它不是搜索引擎你直接问怎么写登录功能它给的是通用解法。你把项目背景、技术栈、已有代码上下文都放进去再让它基于现状给建议质量会完全不一样。好的结果来自好的上下文这句话不是空话。另外补一个小经验无论你用哪个模型如果发现同样的指令在多轮对话之后效果开始变差多半是上下文里累积了太多无效信息。此时别硬问开个新对话把关键背景重新交代一遍效果通常立刻回升。这个技巧看似简单我身边很多人到现在还在用。我自己用下来的体会是这份手册的最大启发不在于某个具体技巧而在于重新思考了人和AI的边界。Claude再强目前它最可靠的角色仍然是高密度输出建议的参谋而不是替你负全部责任的执行者。你把它放在参谋的位置它会源源不断地给你灵感你把它放到需要承担后果的岗位上它就会暴露出现阶段的脆弱。反正我如今写代码、写方案、做分析都默认这套节奏了——不是不敢用而是知道怎么用才稳。最后再给一条小建议如果你想验证一套AI协作流程靠不靠谱先用假数据、假目录、测试分支跑一遍dry-run全程观察它打算做什么再做最终决定。这比任何参数调优都管用。Skills的自建方法我后面会单独整理一份更详细的操作教程这套方法论可以先上手试试多跑几轮你就懂手册里那句别让它动手的含金量了。
阅读完成 · 觉得有帮助？
