Shaw Talebi · 35:37 · 发布 2026-06-28 · 165次观看(截至抓取) · 观看原视频
主旨
2026 年 agent 从”会写代码”进化到”会做知识工作”,而 Claude Skills(即 Agent Skills)是让非技术人员把这种能力真正教给 agent、避免每次从零沟通的开放标准与四步实践法。
核心论点
- 2025 年是编程 agent 的天下,2026 年协同办公 agent 让非技术人员也能全权委托知识工作。(→ 详解1)
- 没有 skills 时,agent 每次对话都是一张白纸,靠反复来回喂上下文才能得到想要的结果,耗时又耗 token。(→ 详解2)
- Agent Skills 本质是一个文件夹加渐进式披露机制,让 agent 只在需要时按需拉取相关知识,而不是一次性塞满上下文。(→ 详解3)
- 构建技能只需四步:做一次、蒸馏成技能、复用技能、持续迭代——不需要预先手写大段说明书。(→ 详解4)
- 组织内分享技能有个人 / 团队(plugin)/ 全组织三个层级,可逐步从”各自野生”过渡到版本控制与权限管理。(→ 详解5)
- 技能的安全边界取决于 agent 能看到什么、能做什么;来源不可信的技能与写入专属数据的技能各有各的风险。(→ 详解6)
- 好的技能应归为上下文 / 工具 / 流程三类之一,且要把反复出现的反馈提炼成可泛化原则,而不是堆砌一次性规则。(→ 详解7)
- 同样的底层模型,harness(围绕模型的工具与工程)决定了最终产品力上限,这是 Copilot 与 Claude 协同办公工具体验差距的根源。(→ 详解8)
知识点详解
1. 2026 拐点:从编程 agent 到协同办公 agent 01:21
2025 年的故事围绕编程 agent 展开,Claude Code、Cursor、Codex 都是为活在命令行里的开发者打造的工具。作者认为 2026 年最大的变化是”AI agents are finally smart enough to just do your work”——一批可称为协同办公 agent 的产品(Claude Co-work、Codex 桌面版等)出现,专为知识工作设计,不需要懂代码或工程背景也能把工作委托给它。
只要理解自己的业务背景、知道工作是怎么完成的,就能教会 agent 去做,不需要技术门槛。这是本片立论的起点:技能(skills)要解决的正是”非技术人如何把经验教给 agent”这一问题。
2. 没有 skills 的代价:上下文每次清零 02:04
作者用一个具体场景说明痛点:让 Claude 生成一份周度营销报告,Claude 很聪明也很主动,会自己去 Google Drive 拉数据、跑分析、出报告,但第一版大概率不对——用错了数据源、格式不对、目标读者不对。于是你要反复给反馈,Claude 每次都认真调整,但每一次调整都要重新理解你的业务上下文。
“Every conversation is like a fresh slate”——agent 足够聪明,却没有记忆,每次对话都是一张白纸。最终虽然能拿到满意的结果,但要花 30 分钟来回沟通,这些时间和 token 成本会在每次重复这类任务时被重复消耗。这正是 Agent Skills 要解决的问题。
3. Agent Skills 剖析:开放标准 + 渐进式披露 03:21
Agent Skills 是”just like MCP is an open standard”的另一个开放标准,本质是可复用的指令集,教会 agent 你业务独有的上下文、工具和流程。一个 skill 就是一个文件夹:核心是 skill.md,此外可以有 references(领域知识文档)、assets(模板、PDF、slide 素材)、scripts(agent 自己写好留用的脚本)。
真正的威力在于渐进式披露:每次对话开始时,agent 不会把所有技能文件都塞进上下文,而是先只看到每个技能的简短描述;判定相关后才拉入完整的 skill.md;真正需要时才进一步拉取 references 里的细节。“The real power of skills is this idea of progressive disclosure”——用作者的话说,这就是”给 agent 在对的时间给对的上下文”。这与 skill.md + YAML front matter 这套打包机制,即索引里已记录的 Claude Skills 概念是同一件事的具体展开。
4. 技能构建四步法 07:06
作者提出一个从新手到资深从业者都适用的技能构建四步法:第一步,先让 agent 把任务做一遍——“The first step is you do the task one time”,过程会很痛苦、来回很多,但这段对话里积累了极丰富的上下文;第二步,直接对 Claude 说”把这个做成一个 skill”,Claude 会自动把整段对话蒸馏成 skill.md;第三步,用这个 skill 再做一次同样的任务,原本 30 分钟的来回可能缩短到 5 分钟;第四步,技能不是一次定型的,每次使用后根据新反馈继续更新,像新员工不断在自己的笔记本上记笔记一样持续进化。
现场演示中,作者用 Claude Co-work 把一份 Keynote 幻灯片做成 Word 版讲义手册,完整走了一遍这四步:先手动来回沟通格式、可视化等细节做出第一版,再让 Claude 把这次对话蒸馏成”create handout doc”技能,然后在新会话里上传同一份幻灯片,Claude 自动调用该技能一次做对大部分内容,最后再针对没做好的地方(比如生成配图方式不对)给出反馈更新技能。这个演示直接印证了四步法不是纸上谈兵。
5. 组织内分享技能的三个层级 13:26
“You can share skills at three levels”:个人技能是当前演示的场景,只为自己的独特工作流服务;组织级技能由管理员统一决定给全员开放,适合品牌系统、通用文档模板这类价值广泛且需要一致性的场景;介于两者之间的是团队级技能,管理员建群组、把一组技能打包成 plugin 分配给具体团队(销售、市场、财务各自管理自己的技能包),这些 plugin 会做版本控制、自动同步,并托管在 GitHub 上。
作者建议从”小而野生”开始——大家各自建技能、互相安利好用的,等规模变大成为负担时,再升级到 plugin+权限这种更正式的治理方式。
6. 安全边界:能看什么、能做什么 20:18
关于 agent 安全,作者归纳为两个核心问题:agent 能看到什么,agent 能做什么。对 skills 而言,主要风险是从网上下载不可信来源的技能——“Don’t download skills from untrusted sources”,因为 Claude 会信任已加载的技能内容,可能被诱导做不该做的事。作者也指出一个反直觉的事实:别人的技能通常对你没什么价值,因为技能的价值恰恰在于足够贴合你独有的工作流。
另一个边界是合规:很多企业可以和 Anthropic 这类供应商签”零保留”(zero retention)协议,让对话数据在会话结束后被删除,但这个政策不适用于 skills 本身——“Anthropic has to like save that data somewhere to make that skill available to the users”。这意味着如果把专属数据写进 skill 内容里,零保留政策可能对这部分内容不生效,受监管行业(如金融机构)需要单独考虑这一限制。
7. 技能设计原则:三分类 + 提炼可泛化原则 28:31
“There really like three kinds of skills you can think about”:一类教 agent 关于业务/团队的上下文知识,一类教工具用法(比如 Anthropic 官方那个教 Claude 读写 docx 的技能),一类教流程(比如本片演示的做讲义流程)。三类之间没有互斥,一个 skill 常常同时承载不止一种。
更新技能时有个容易踩的坑:把每次反馈都原样堆成一条条 ad hoc 规则,skill 会越堆越臃肿、越来越脆弱,反而不好用。作者主张”You want Claude to take your feedback and distill those into generalizable principles”——把具体反馈提炼成能覆盖一大类情况的通用原则,这样 skill 才会真正越用越聪明,而不是变成一份补丁清单。
8. 模型 vs Harness:体验差距的真正来源 33:21
问答环节被问及为何不推荐 Copilot 时,作者的回答落到了模型与 harness 的区分上:“It’s not just about the model, it’s about the so-called harness”——即使 Copilot 底层调用的也是 Claude 或 GPT,产品体验的差距来自模型之外的所有代码与工具编排。他进一步指出”If you have a really smart model and not a powerful harness”,再聪明的模型也造不出强大的最终产品,而 Harness 与模型协同训练/适配(如 Claude Code、Claude Co-work、Codex/Cursor 各自的专属 harness)才是真正拉开差距的地方。这与索引中已有的 harness 概念是同一逻辑在协同办公场景下的印证。
可执行步骤
- 挑一件最近两周反复手动重复的任务(比如周报、邮件模板、某类数据整理),让 agent 先完整做一遍,哪怕过程来回很多次。
- 做完后直接让 agent 把这次对话蒸馏成一个 skill,不要自己手写 skill.md。
- 下一次遇到同类任务时先用这个 skill,记录哪里还不到位,把反馈继续喂给 agent 更新 skill,而不是每次从头讲一遍。
- 定期审视自己的技能清单,删掉长期不用的,避免技能堆积成认知负担。
- 涉及专属或敏感数据时,先确认零保留政策是否覆盖 skill 内容,再决定要不要把这部分信息写进技能。
关联
- 印证:与索引中的 Harness(围绕模型的工具/context/skills 集合决定加速上限)完全一致——本片”model vs harness”的论述是同一概念在协同办公场景下的又一次印证。
- 印证:与索引中的 Claude Skills(文件夹+YAML front matter 的可复用模块机制)是同一机制,本片补充了”进企业内如何分级分享”与”四步构建法”两块该概念索引未覆盖的细节。
- 印证:与索引中的 [渐进式披露]同源——本片给出的是该策略在 Anthropic Agent Skills 产品设计里的原始落地形态(元数据描述→skill.md→references 三级展开)。
一手来源与延伸
- 作者提到的个人非编程技能仓库:GitHub
shaheente/noncodingskills(原话拼读不清晰,视频描述区未给出确切链接,未核验,不确定是否为准确仓库名,故不作为可点击引用收录)。
术语
- Agent Skills(智能体技能,可复用指令集,教 agent 业务上下文/工具/流程)
- progressive disclosure(渐进式披露,按需分级加载上下文)
- co-working agent(协同办公 agent,面向非技术知识工作者的 agent 产品形态)
- harness(围绕模型的工具/代码/工程集合,决定模型能落地成什么产品)
- plugin(团队级技能打包单元,可版本控制、可分配给特定团队)
- zero retention policy(零保留政策,会话结束后供应商删除对话数据的约定)
金句
“AI agents are finally smart enough to just do your work.” → 与其说是新模型发布,不如说是”能不能被普通业务人员用起来”这道门槛被跨过了。 “Every conversation is like a fresh slate.” → 一句话点破 agent 缺记忆的核心痛点,也是 skills 存在的全部理由。 “It’s not just about the model, it’s about the so-called harness.” → 解释了为什么同一个底层模型,不同产品的用户体验可以天差地别。
立场与利益
作者是 AI Builder Academy 创始人,曾开设付费课程 AI Builder’s Bootcamp,并明确提到自己更熟悉 Anthropic 生态、服务的是 50-200 人规模的中型企业客户;演讲中对 Copilot 的负面评价、对 Claude Co-work 的正面示范都需结合这层商业立场看待,但四步构建法和 progressive disclosure 机制本身是可独立验证、不依赖购买其课程或咨询服务的通用方法论。
价值定位
面向非技术背景、但需要日常委托 agent 做知识工作(报告、文档、流程类任务)的个人或团队管理者,提供了一套无需写代码就能”训练”agent 记住自己业务偏好的实操框架;对已经在用 Claude Code / 熟悉 skill 文件夹机制的技术用户而言,本片新增信息量集中在企业内分享治理(三层级)与安全合规边界(untrusted sources、zero retention 例外)两块,核心机制部分与已有笔记高度重叠。
自检问题
- 为什么没有 skills 时,即便 agent 很聪明,每次完成同一类任务仍需要反复来回沟通? 答案:因为 agent 没有跨会话记忆,每次对话都是全新起点(“every conversation is like a fresh slate”),需要重新理解业务上下文、数据源和格式偏好,详见详解2。02:04
- progressive disclosure 具体是怎么分层加载上下文的? 答案:会话开始时只展示每个 skill 的简短描述;判定相关后才拉入完整 skill.md;真正需要时才进一步读取 references 里的细节文档,详见详解3。04:44
- 技能构建四步法的四个步骤分别是什么? 答案:先让 agent 做一次任务(哪怕来回很多)→ 让 agent 把这次对话蒸馏成 skill → 用这个 skill 再做一次同类任务 → 根据新反馈持续迭代更新 skill,详见详解4。07:06
- 零保留政策(zero retention)对 skills 为什么会失效? 答案:零保留政策约定会话结束后数据被删除,但 skill 需要被持久保存才能在之后的会话里被复用,所以写进 skill 里的专属数据不受该政策保护,详见详解6。21:33
- 更新技能时,为什么直接堆砌反馈规则是个坑? 答案:逐条堆砌的 ad hoc 规则会让 skill 越来越臃肿脆弱;应该把反复出现的反馈提炼成可泛化的通用原则,才能让技能真正越用越好,详见详解7。29:17