即刻App年轻人的同好社区
下载
想把一个 2 个 G 的视频传到 NotebookLM 上，结果提示太大，只支持 200M 以内的视频。
Google 上搜索找到几个在线压缩视频的网站，结果发现都需要付费。
于是想着看看能不能用 Curosr 解决，没想到一句命令就轻松搞定。
AI Coding 果然是构造工具的工具。
如果我用 Claude Skill 将我遇到的每个需求都变为一个 Skill，那么就构成了一个个人私有工具库？
Google 上搜索找到几个在线压缩视频的网站，结果发现都需要付费。
于是想着看看能不能用 Curosr 解决，没想到一句命令就轻松搞定。
AI Coding 果然是构造工具的工具。
如果我用 Claude Skill 将我遇到的每个需求都变为一个 Skill，那么就构成了一个个人私有工具库？
5 11
本周开始学习 Claude Skill，初步的感受是：
1、纯 LLM 是无法高效解决所有问题的，该引用代码的时候，最好还是引用代码；
2、可以用自然语言去构建更复杂的系统；
用 Gemini 让其解释 Claude 的原文，然后再去看原文，确实更容易理解：
-----
用“智能体技能”来武装智能体，使其适应真实世界
1. 引言
💡 核心观点： Claude 本身很强大，但要完成“真实世界的工作”，还需要“程序性知识”（即“如何一步步做某件事”）和“组织上下文”（即“我们公司是怎么做事的”）。
🤔 问题所在： 随着 AI（如 Claude Code）能力增强，它们可以与复杂的计算环境（如文件系统、代码执行）交互。但我们需要一种可组合、可扩展、可移植的方法来赋予它们特定领域的专业知识。
✅ 解决方案：智能体技能
定义：它是一个有组织的文件夹，里面包含了指令、脚本和资源。
作用：AI 智能体（如 Claude）可以动态地发现和加载这些技能，以便在特定任务上表现得更好。
比喻：作者打了一个非常形象的比喻——为 AI 构建一个技能，就像为新员工编写一份“入职指南”。
价值：你不需要为每个任务都定制一个 AI，而是可以通过分享你的专业知识（打包成技能），将一个通用的 AI “特化”成能满足你需求的专业 AI。
2. 技能的剖析
这部分是全文的核心，它用一个“PDF 处理技能”作为例子，讲解了技能的内部构造。
❓ 问题： Claude 擅长理解 PDF 内容，但不擅长直接操作 PDF（比如填写表单）。
🛠️ 技能的实现：
最简结构： 一个技能就是一个目录，目录里必须包含一个 SKILL.md 文件。
SKILL.md 的头部： 文件开头必须有 YAML 格式的元数据，至少包含两个字段：“名称”和“描述”。 作用：AI 启动时，会预加载所有已安装技能的“名称”和“描述”。这让 AI 对“自己会什么”有个大致了解。
🧠 核心设计原则：渐进式披露
这是理解技能工作原理最关键的概念。它指的是 AI 按需加载信息，而不是一次性把所有东西都塞进大脑（上下文窗口）。
第一层：元数据（名称与描述） AI 仅凭“名称”和“描述”来判断“这个技能是否可能与当前任务相关”。 好处：非常轻量，AI 可以快速检索上百个技能，而不会占用宝贵的上下文窗口。
第二层：SKILL.MD 的主体内容 如果 AI 认为某个技能相关（比如用户说“帮我填个 PDF 表单”），它才会去读取这个技能的 SKILL.md 文件的全部内容。 这些内容就是指导 AI 如何完成任务的详细指令。
第三层：捆绑的附加文件 如果一个任务非常复杂（比如“填表单”和“合并 PDF”是两种不同操作），SKILL.md 可能会变得非常臃肿。 做法：你可以在技能目录里放其他文件（如 forms.md 或 reference.md），然后在 SKILL.md 里引用它们。 好处：AI 只在需要时（比如真的要“填表单”时）才会去读取 forms.md，保持了核心 SKILL.md 的精简。
总结： “渐进式披露”让技能变得灵活且可扩展。AI 不需要一次性阅读整本“操作手册”，而是先看“目录”（元数据），再读“章节”（SKILL.md），最后才去查“附录”（附加文件）。
3. 技能与上下文窗口
这部分展示了技能是如何被触发并加载到上下文窗口的。
工作流程（序列操作）：
开始状态： 上下文窗口中只有“核心系统提示”、所有技能的“元数据”（名称和描述）以及用户的“初始消息”。
触发技能： Claude 判断 PDF 技能相关，于是它调用一个工具（如 Bash 工具）去读取 pdf/SKILL.md 的内容。
加载第三层： Claude 在阅读 SKILL.md 后，发现任务是“填表单”，于是它进一步读取 forms.md 文件。
执行任务： Claude 现在拥有了完成任务所需的全部指令（来自 SKILL.md 和 forms.md），开始执行用户的任务。
4. 技能与代码执行
这部分讲了技能如何与代码结合，实现更强大、更可靠的功能。
🚀 核心观点： 大语言模型虽然擅长很多事，但某些操作（如排序、精确计算）用传统代码执行更高效、更可靠。
技能中的代码： 技能文件夹中可以包含可执行的代码脚本（例如 Python 脚本）。 在 PDF 的例子中，技能包含一个 Python 脚本，用于“读取 PDF 并提取所有表单字段”。
工作方式： Claude 可以自行决定“运行”这个脚本，而不是把脚本内容读入上下文窗口。
好处：
确定性：代码的执行结果是稳定、可重复的。
效率：运行脚本远比让大语言模型模拟脚本执行更便宜、更快速。
节省上下文：AI 不需要“阅读”代码或 PDF 文件的二进制内容。
5. 开发与评估技能
这部分提供了创建和测试技能的最佳实践（非常重要）：
从评估开始： 先找到 AI 在执行你的任务时哪里做得不好（它的能力“缺口”）。 然后增量地构建技能来弥补这些不足。
为规模化而设计： 当 SKILL.md 太臃肿时，就把它拆分成多个独立文件（即“渐进式披露”的第三层）。 如果某些指令是互斥的（比如“创建 PDF”和“编辑 PDF”），分开存放可以减少 Token 消耗。
从 Claude 的视角思考： 监控 Claude 如何实际使用你的技能，观察它是否会错意或过度依赖某些指令。 “名称”和“描述”至关重要，因为这是 Claude 决定是否使用该技能的唯一依据。
与 Claude 一起迭代： 在和 Claude 一起工作时，让它帮你把成功的经验和犯过的错误“固化”到一个技能里。 如果它用技能时出错了，让它“自我反思”是哪里出了问题。这能帮你发现 AI 真正需要什么上下文。
6. 使用技能时的安全考量
🛡️ 风险： 技能既然能提供指令和执行代码，那么恶意的技能就可能带来风险（如泄露数据、执行恶意操作）。
建议：
只安装来自可信来源的技能。
使用不可信来源的技能之前，仔细“审计”其内容，特别是代码依赖和外部网络连接。
7. 技能的未来
📈 现状： 目前“技能”已在 Claude.ai、Claude Code 和 API 中得到支持。
🎯 短期目标： 完善“技能”的全生命周期管理（创建、编辑、发现、分享）。
🌌 长期愿景：
让“技能”与 MCP（模型上下文协议）协同工作，处理更复杂的涉及外部工具的工作流。
最终目标是让 AI 自主地创建、编辑和评估“技能”，将它们自己的行为模式“编码”成可重用的能力。
总结
“技能”是一个概念简单、格式简单的工具。
这种简单性使得组织、开发者和最终用户都能更容易地构建定制化的 AI，并赋予它们新的能力。
-----
1、纯 LLM 是无法高效解决所有问题的，该引用代码的时候，最好还是引用代码；
2、可以用自然语言去构建更复杂的系统；
用 Gemini 让其解释 Claude 的原文，然后再去看原文，确实更容易理解：
-----
用“智能体技能”来武装智能体，使其适应真实世界
1. 引言
💡 核心观点： Claude 本身很强大，但要完成“真实世界的工作”，还需要“程序性知识”（即“如何一步步做某件事”）和“组织上下文”（即“我们公司是怎么做事的”）。
🤔 问题所在： 随着 AI（如 Claude Code）能力增强，它们可以与复杂的计算环境（如文件系统、代码执行）交互。但我们需要一种可组合、可扩展、可移植的方法来赋予它们特定领域的专业知识。
✅ 解决方案：智能体技能
定义：它是一个有组织的文件夹，里面包含了指令、脚本和资源。
作用：AI 智能体（如 Claude）可以动态地发现和加载这些技能，以便在特定任务上表现得更好。
比喻：作者打了一个非常形象的比喻——为 AI 构建一个技能，就像为新员工编写一份“入职指南”。
价值：你不需要为每个任务都定制一个 AI，而是可以通过分享你的专业知识（打包成技能），将一个通用的 AI “特化”成能满足你需求的专业 AI。
2. 技能的剖析
这部分是全文的核心，它用一个“PDF 处理技能”作为例子，讲解了技能的内部构造。
❓ 问题： Claude 擅长理解 PDF 内容，但不擅长直接操作 PDF（比如填写表单）。
🛠️ 技能的实现：
最简结构： 一个技能就是一个目录，目录里必须包含一个 SKILL.md 文件。
SKILL.md 的头部： 文件开头必须有 YAML 格式的元数据，至少包含两个字段：“名称”和“描述”。 作用：AI 启动时，会预加载所有已安装技能的“名称”和“描述”。这让 AI 对“自己会什么”有个大致了解。
🧠 核心设计原则：渐进式披露
这是理解技能工作原理最关键的概念。它指的是 AI 按需加载信息，而不是一次性把所有东西都塞进大脑（上下文窗口）。
第一层：元数据（名称与描述） AI 仅凭“名称”和“描述”来判断“这个技能是否可能与当前任务相关”。 好处：非常轻量，AI 可以快速检索上百个技能，而不会占用宝贵的上下文窗口。
第二层：SKILL.MD 的主体内容 如果 AI 认为某个技能相关（比如用户说“帮我填个 PDF 表单”），它才会去读取这个技能的 SKILL.md 文件的全部内容。 这些内容就是指导 AI 如何完成任务的详细指令。
第三层：捆绑的附加文件 如果一个任务非常复杂（比如“填表单”和“合并 PDF”是两种不同操作），SKILL.md 可能会变得非常臃肿。 做法：你可以在技能目录里放其他文件（如 forms.md 或 reference.md），然后在 SKILL.md 里引用它们。 好处：AI 只在需要时（比如真的要“填表单”时）才会去读取 forms.md，保持了核心 SKILL.md 的精简。
总结： “渐进式披露”让技能变得灵活且可扩展。AI 不需要一次性阅读整本“操作手册”，而是先看“目录”（元数据），再读“章节”（SKILL.md），最后才去查“附录”（附加文件）。
3. 技能与上下文窗口
这部分展示了技能是如何被触发并加载到上下文窗口的。
工作流程（序列操作）：
开始状态： 上下文窗口中只有“核心系统提示”、所有技能的“元数据”（名称和描述）以及用户的“初始消息”。
触发技能： Claude 判断 PDF 技能相关，于是它调用一个工具（如 Bash 工具）去读取 pdf/SKILL.md 的内容。
加载第三层： Claude 在阅读 SKILL.md 后，发现任务是“填表单”，于是它进一步读取 forms.md 文件。
执行任务： Claude 现在拥有了完成任务所需的全部指令（来自 SKILL.md 和 forms.md），开始执行用户的任务。
4. 技能与代码执行
这部分讲了技能如何与代码结合，实现更强大、更可靠的功能。
🚀 核心观点： 大语言模型虽然擅长很多事，但某些操作（如排序、精确计算）用传统代码执行更高效、更可靠。
技能中的代码： 技能文件夹中可以包含可执行的代码脚本（例如 Python 脚本）。 在 PDF 的例子中，技能包含一个 Python 脚本，用于“读取 PDF 并提取所有表单字段”。
工作方式： Claude 可以自行决定“运行”这个脚本，而不是把脚本内容读入上下文窗口。
好处：
确定性：代码的执行结果是稳定、可重复的。
效率：运行脚本远比让大语言模型模拟脚本执行更便宜、更快速。
节省上下文：AI 不需要“阅读”代码或 PDF 文件的二进制内容。
5. 开发与评估技能
这部分提供了创建和测试技能的最佳实践（非常重要）：
从评估开始： 先找到 AI 在执行你的任务时哪里做得不好（它的能力“缺口”）。 然后增量地构建技能来弥补这些不足。
为规模化而设计： 当 SKILL.md 太臃肿时，就把它拆分成多个独立文件（即“渐进式披露”的第三层）。 如果某些指令是互斥的（比如“创建 PDF”和“编辑 PDF”），分开存放可以减少 Token 消耗。
从 Claude 的视角思考： 监控 Claude 如何实际使用你的技能，观察它是否会错意或过度依赖某些指令。 “名称”和“描述”至关重要，因为这是 Claude 决定是否使用该技能的唯一依据。
与 Claude 一起迭代： 在和 Claude 一起工作时，让它帮你把成功的经验和犯过的错误“固化”到一个技能里。 如果它用技能时出错了，让它“自我反思”是哪里出了问题。这能帮你发现 AI 真正需要什么上下文。
6. 使用技能时的安全考量
🛡️ 风险： 技能既然能提供指令和执行代码，那么恶意的技能就可能带来风险（如泄露数据、执行恶意操作）。
建议：
只安装来自可信来源的技能。
使用不可信来源的技能之前，仔细“审计”其内容，特别是代码依赖和外部网络连接。
7. 技能的未来
📈 现状： 目前“技能”已在 Claude.ai、Claude Code 和 API 中得到支持。
🎯 短期目标： 完善“技能”的全生命周期管理（创建、编辑、发现、分享）。
🌌 长期愿景：
让“技能”与 MCP（模型上下文协议）协同工作，处理更复杂的涉及外部工具的工作流。
最终目标是让 AI 自主地创建、编辑和评估“技能”，将它们自己的行为模式“编码”成可重用的能力。
总结
“技能”是一个概念简单、格式简单的工具。
这种简单性使得组织、开发者和最终用户都能更容易地构建定制化的 AI，并赋予它们新的能力。
-----
2 00
最近在做入门 AI 视频创作者的调研，发现一个很统一的点：创作者都在用飞书多维表格进行分镜管理。
确实，虽然目前市面上有很多分镜管理的工具，但都不及表格这种形式的灵活，以及飞书本身的协作能力🤔。
并且加上多维表格本身的 AI 能力，出一个视频 Demo 也很快。
正好飞书给了一个福利，免费领3 个月价值 100 多的多维表格 VIP 服务：
兑换码：New8Z5k9S2x3Q5t
兑换链接：fcna6swh3rtl.feishu.cn
👏欢迎领取～
确实，虽然目前市面上有很多分镜管理的工具，但都不及表格这种形式的灵活，以及飞书本身的协作能力🤔。
并且加上多维表格本身的 AI 能力，出一个视频 Demo 也很快。
正好飞书给了一个福利，免费领3 个月价值 100 多的多维表格 VIP 服务：
兑换码：New8Z5k9S2x3Q5t
兑换链接：fcna6swh3rtl.feishu.cn
👏欢迎领取～
0 00
黄叔说的 3 个趋势，在我们团队确实已经都在执行落地了。
有些区别的是，目前团队的组织，其实还是按照产品-设计-技术-测试的架构。
在我们的团队里，目前设计的工作似乎没有很好被 AI 取代，可能是因为还没研究出好的 AI 工具。
由于项目比较大，目前只在新的、独立的项目里采用 Spec Coding 的形式，而且 Spec Coding 也是产品、技术都参与，主要去评审各环节产出的文档。
有些区别的是，目前团队的组织，其实还是按照产品-设计-技术-测试的架构。
在我们的团队里，目前设计的工作似乎没有很好被 AI 取代，可能是因为还没研究出好的 AI 工具。
由于项目比较大，目前只在新的、独立的项目里采用 Spec Coding 的形式，而且 Spec Coding 也是产品、技术都参与，主要去评审各环节产出的文档。
AI产品黄叔: 昨天和一个创业的朋友@Erix 聊 总结出产品经理未来的三个趋势 第一是：从文档到Demo 从字节到阿里 老板们已经开始强制要求只看AI Coding出来的Demo了 这很好理解，比起文档和PPT 可交互的成品更容易理解 很多年前蒋凡开会不带电脑 直接用iPad、手机看Demo 只不过过去需要产研团队协作才能做到 现在甚至1-3人即可快速完成 第二是：产品经理都要变成工程师 这种偏Demo的工程师会由现在的产品和UI转行 之前的研发就是偏落地的工程师 最后就全都是工程师 转不了的直接被淘汰 最近参加的黑客松都体现了快速Demo 用社媒获客和迭代产品的强大趋势 产品经理落地能力将会得到质的飞跃 不再是办公室里吹空调比嘴皮子了 第三是：Spec Coding必定盛行 先写文档再开发，这本来也是产品的基本工作 所以新招人就直接招产品经理 然后学Vibe Coding直接开干 再加上AI，可以生成非常详细的PRD 以及不断迭代的PRD Spec = PRD = Code 最后，为何这个变化不可逆 效率与组织逻辑的必然 1. 减少沟通损耗 2. 大厂效率提升 3. 小团队崛起 如果大厂也这么变化 “大团队和小团队没有什么成本和执行力的问题,没有区别了,最后就是想法。”
0 00
做惯了 B 端/业务型产品的人，一旦开始做 C 端，才会体会什么叫“重新做人”。
从 0 开始做产品、和用户 1 对 1 聊天，发现：
产品没灵感，不是没想法——
而是自己根本不是用户，也离用户太远。
从 0 开始做产品、和用户 1 对 1 聊天，发现：
产品没灵感，不是没想法——
而是自己根本不是用户，也离用户太远。
5 00