文档(金鹏): 2026-08-20 章节 26 篇文章摘要归档
- 26 篇微信公众号文章原文+摘要归档至 知识/微信公众平台/{公众号}/
- 9 个主题分组：Skill工程/Agent运行时/数据基础设施/交互工具/产品服务/大模型前沿/产业开源/制造业AI/军事社会
- 生成 9 组配图（2560x1440 大图 + 160x90 thumb）至 知识/金鹏/20260820/
- 知识/金鹏.md 2026-08-20 章节改写为结构化索引（主题标签+配图+金句+分层子条目）
- 1 个小红书视频链接以视频笔记条目保留（内容无法文本化）
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Claude
@@ -0,0 +1,556 @@
|
||||
# 万字长文：做了些爆款 Skills 以后，我对 Skills 的看法
|
||||
|
||||
> **来源**：微信公众平台（歸藏的AI工具箱）
|
||||
> **作者**：歸藏的AI工具箱
|
||||
> **发布日期**：2026-08-20（原文未标注明确日期，按下载日占位）
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/sZXl5kHA9LErEwnegpvgXg
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
我最近几次聊 Skills，有一个越来越明确的判断：
|
||||
|
||||
大家现在都在说 Agent，但大多数人其实还没有真正理解 Agent。
|
||||
|
||||
大众理解里的 Agent，往往还是一个聊天框。
|
||||
|
||||
你输入一句话，它回答一段文字；你再输入一句，它继续回答。
|
||||
|
||||
这个视角下，AI 好像天然会带来一种平权：以前不会写代码的人可以写代码，不会做 PPT 的人可以做 PPT，不会剪视频的人可以剪视频。
|
||||
|
||||
只要模型足够强，大家的能力差距就会被抹平。
|
||||
|
||||
|
||||
|
||||
但我越来越觉得，这个判断是错的。Agent 不是简单抹平能力差距，而是在放大能力差距。
|
||||
|
||||
头部用户已经默认理解 Agent 的组成：
|
||||
|
||||
文档、规则、memory、loop、MCP、CLI、工具调用、权限、安全沙箱、上下文工程、定时任务、心跳、文件系统、代码执行和 Skill。
|
||||
|
||||
但普通用户只知道"Agent 能写代码""Agent 可以调用 Skill"，并不知道 Agent 的上限从哪里来，也不知道自己应该如何组织目标、资料和流程，才能让 Agent 真正工作。
|
||||
|
||||
**Agent**：这里指的不只是聊天机器人，而是能理解目标、规划步骤、调用工具并持续执行任务的 AI 系统。
|
||||
|
||||
**Memory**：Agent 用来保存长期偏好、项目状态和历史决策的外部记忆，不等同于模型训练记忆。
|
||||
|
||||
**Loop**：Agent 反复"思考、调工具、观察结果、再决定下一步"的执行循环。
|
||||
|
||||
这里就出现了一个很大的认知割裂：头部用户已经在搭系统，普通用户还在问聊天框。
|
||||
|
||||
目标清晰、上下文好、品味和判断强的人，会被 Agent 放大；目标混乱、没有文档、没有判断的人，也会被 Agent 放大混乱。
|
||||
|
||||
所以用户会出现 K 型分化。去年还可以靠产品设计、交互设计和用户教育降低一些门槛，今年我觉得已经很难靠简单 UX 弥合这个差距。
|
||||
|
||||
|
||||
|
||||
Skill 则可以弥合 Agent 使用能力差距。
|
||||
|
||||
## Skill 是能力商品，不只是提示词
|
||||
|
||||
我现在对 Skill 的一句话定义是：
|
||||
|
||||
Skill 是把专家经验、工作流、品味和工具调用封装成可分发、可复用、可迭代的 Agent 能力单元。
|
||||
|
||||
**Skill**：把提示词、流程、工具调用、模板、脚本、边界和经验打包起来的可复用能力单元。
|
||||
|
||||
|
||||
|
||||
它不是单纯的提示词，也不是传统意义上的 App。
|
||||
|
||||
它更像 Agent 时代的"能力商品"。用户不需要理解底层的 MCP、CLI、workflow、memory、loop、模型选择、代码执行和上下文工程，只需要知道：
|
||||
|
||||
它解决什么问题，产出什么结果，怎么使用，别人用得怎么样。
|
||||
|
||||
提示词本身很难成为产品。它容易被复制，难以分发，没有版本管理，也缺少安装和调用语义。
|
||||
|
||||
Skill 把提示词、规则、示例、工具调用、文件结构、脚本、依赖和使用说明打包起来，让它变成一个可以安装、调用、迭代和传播的能力包。
|
||||
|
||||
所以 Skill 和 Prompt 本质上并非完全不同，但 Skill 的调用效率更高，分发和理解成本更低，也能承载更多工程化内容。
|
||||
|
||||
更重要的是，很多任务并不是一句提示词能解决的。
|
||||
|
||||
它们是一组稳定流程：读取材料，分析需求，选择模板，调用工具，生成产物，验证结果，修复问题，导出文件。
|
||||
|
||||
Skill 把这套流程从一次性对话中抽出来，变成可以反复调用的工作流。
|
||||
|
||||
|
||||
|
||||
比如 PPT Skill 的流程不是"生成 PPT"这么简单。
|
||||
|
||||
它要读取文章或大纲，询问主题、页数和配图，选择主题、颜色和版式，生成 HTML PPT，自动后验检查常见问题，再修正缺属性、未居中、溢出、图片裁切、节奏重复等问题，必要时还要调用图像模型生成配图，最后输出可演示、可分享的文件。
|
||||
|
||||
|
||||
|
||||
这背后真正有价值的，是 Skill 把人的演示经验被外化了。
|
||||
|
||||
## Skill 的核心，是把人的经验外化
|
||||
|
||||
我做的设计类 Skill 很能说明这一点。
|
||||
|
||||
真正有价值的部分是把人的审美、版式判断、设计系统经验、模板选择、图片裁切规则、明暗遮罩规则、字体和颜色规则固化进去。
|
||||
|
||||
这要求创作者同时懂三件事：传统专业知识，AI 的上下限，以及产品化思维。
|
||||
|
||||
传统专业知识决定你知道什么结果算好。比如设计、剪辑、写作、健身、法律、商业化投放，每个行业都有大量隐性判断。AI 的上下限决定你知道模型什么能做、什么做不稳、什么必须工程化兜底。
|
||||
|
||||
产品化思维决定你知道用户场景、使用门槛、反馈路径和稳定性要求。
|
||||
|
||||
|
||||
|
||||
这也是我做几个 Skill 时最深的体会。
|
||||
|
||||
PPT Skill 最开始不是为了"做一个 Skill"，是因为我真的要做一场分享。
|
||||
|
||||
第一版基本成型后，我通过五六轮对话调整间距、字号、字体、颜色、配图、重复内容、WebGL 背景等问题。
|
||||
|
||||
讲完之后发现大家最关心的不是分享本身，而是 PPT 怎么做，于是才把这套模板和流程沉淀成 Skill。
|
||||
|
||||
社交媒体卡片 Skill 也不是凭空抽象出来的。它来自非常具体的内容分发需求：
|
||||
|
||||
3:4 竖版图文卡片，适配小红书、公众号、Twitter 等不同场景。它要处理 11 类内容，两套视觉系统，28 个版式骨架，真实图片 + Coding 排版，还要规避 AI 图限流、文字不锐利、平台风格不匹配等问题。
|
||||
|
||||
|
||||
|
||||
Logo Generator Skill 也是同一逻辑。它没有直接让图像模型一把梭生成 Logo，因为图片模型的文字、结构和可编辑性不稳定。
|
||||
|
||||
它选择先生成 SVG Logo 变体，再生成展示图和 WebGL 背景，把 Logo 本体、展示场景和交互背景拆成不同层，分别用最适合的技术处理。
|
||||
|
||||
|
||||
|
||||
AI Desk Card 则说明 Skill 的边界可以扩展到物理环境。
|
||||
|
||||
它让 Agent 接管屏幕边缘的物理信息位：固件烧录、Wi-Fi 配置、信息推送、定时任务、memory、todo、日历、GitHub 展示、墨水屏刷新，都可以被封装成一套 Skill。
|
||||
|
||||
|
||||
|
||||
这些案例共同说明：Skill 的核心是"人把什么经验变成了可调用的能力"。
|
||||
|
||||
|
||||
|
||||
## 用户不关心概念，用户关心结果
|
||||
|
||||
对普通用户来说，Skill、MCP、CLI、Plugin 叫什么并不重要。
|
||||
|
||||
他们关心的是：这个功能能解决什么问题，适合什么场景，我点一下能不能用，需要输入什么材料，结果长什么样，别人用得怎么样。
|
||||
|
||||
**MCP**：Model Context Protocol，可以理解为让 AI 以统一方式连接外部工具、数据源和服务的协议。
|
||||
|
||||
**CLI**：Command Line Interface，命令行工具；对 Agent 来说，它常常是比图形界面更稳定、更容易自动化的操作入口。
|
||||
|
||||
因此，面向用户的产品层不应该堆术语。Codex 把很多东西统一叫插件，我觉得就是一个正确方向：弱化概念，强调功能。
|
||||
|
||||
底层可以是 Skill、MCP、CLI 或原生 Plugin；用户只需要知道它能干什么。
|
||||
|
||||
|
||||
|
||||
但对产品和创作者来说，这些底层形态的区别又很重要。
|
||||
|
||||
Skill 适合承载相对垂直、可描述、可复用的工作，比如 PPT、社交媒体卡片、文章配图、写作润色、视频包装、简历优化、数据可视化、某个行业 SOP。
|
||||
|
||||
MCP 更适合 Agent 架构中的原子服务和上下文连接，比如地图、浏览器、网盘、设计稿、数据库、企业 API。
|
||||
|
||||
CLI 则是目前很现实的通用 Plugin 形态：命令行、代码、Skill 都可以封装进去，也不绑定单一 Agent 平台。
|
||||
|
||||
飞书 CLI 就是一个很好的例子。用户不用理解 200 多条命令，也不用知道背后是哪个 API。
|
||||
|
||||
他只需要说"帮我把今天的智能纪要拉到笔记里"，Agent 背后可以搜索云文档、读取妙记、下载逐句转写、写入本地 Markdown、建立反向链接。
|
||||
|
||||
用户看到的是结果，Agent 用的是工具，Skill 封装的是流程。
|
||||
|
||||
|
||||
|
||||
这也是为什么 Skill、CLI 和 MCP 的关系不能只从技术概念上理解。
|
||||
|
||||
它们最终都要落到一个问题：怎么让普通用户用上头部用户已经验证过的能力。
|
||||
|
||||
## 好 Skill 的架构：中心短，辐射厚
|
||||
|
||||
很多人会把 Skill 理解成一个 SKILL.md 文件，这只说对了一半。
|
||||
|
||||
**SKILL.md**：很多 Skill 的入口说明文件，用来告诉 Agent 什么时候加载这个能力、按什么流程执行、哪些坑不能踩。
|
||||
|
||||
好的 Skill 往往是一个目录。SKILL.md 只是入口，旁边还可以有 scripts/、references/、assets/、模板、schema、配置文件、子 Skill 和特殊案例。
|
||||
|
||||
复杂 Skill 不怕有复杂内容，怕的是把复杂内容一次性塞给模型。文件系统本身就是一种上下文工程。
|
||||
|
||||
**上下文窗口**：AI 一次能"看见"和处理的信息范围，文档、代码、聊天记录和工具说明都会占用它。
|
||||
|
||||
好 Skill 的信息架构应该是"中心短，辐射厚"。
|
||||
|
||||
SKILL.md 只放高信号流程和判断；references/ 放重文档和领域材料，按条件读取；scripts/ 放确定性逻辑，让 Agent 调用而不是重写；assets/ 放模板、schema、示例、字体、主题和版式骨架；配置文件或稳定数据目录放首次配置、偏好和历史记录。
|
||||
|
||||
|
||||
|
||||
这里有个很关键的点：Skill 的 description 不是宣传语，也不是功能摘要，是路由触发器。
|
||||
|
||||
好的 description 应该描述用户什么时候需要它，最好来自真实用户表达；坏的 description 只是解释"这个 Skill 做什么"。
|
||||
|
||||
比如一个 PPT Skill，不应该写"这个 Skill 可以生成漂亮 PPT"。
|
||||
|
||||
它应该写"当用户需要把文章、大纲或演讲内容转成可演示 HTML PPT 时加载"。前者是广告，后者是 Agent 的判断条件。
|
||||
|
||||
这能解释为什么"把所有能力塞进一个大 Agent"不是好方向。
|
||||
|
||||
大而全的 harness 会把工具定义、协议细节和长文档塞满上下文，带来更高延迟、更高 token 成本和更多误用。
|
||||
|
||||
反过来，薄 harness 只提供最小运行环境，Skill 作为按需加载的能力包，才能让系统长期复利。
|
||||
|
||||
**Harness**：运行 Agent 的外层程序，负责模型循环、文件读写、上下文管理和安全边界。
|
||||
|
||||
更稳的架构是 Thin Harness, Fat Skills：harness 保持薄，负责跑模型循环、读写文件、管理上下文、执行权限和安全边界；
|
||||
|
||||
Skill 变厚，承载流程、判断、领域知识、模板、脚本、资产、gotchas 和 eval；
|
||||
|
||||
确定性工具下沉给 CLI、scripts 或 API；模型留在理解、判断、综合、取舍和表达这些更适合它的部分。
|
||||
|
||||
**Thin Harness, Fat Skills**：让 Agent 底层运行环境保持轻，把具体流程、领域知识、模板、脚本和失败经验放进按需加载的 Skill 里。
|
||||
|
||||
|
||||
|
||||
## Skill 质量要像代码质量一样维护
|
||||
|
||||
好 Skill 不是一次写完。它需要维护，而且要像代码质量一样维护。
|
||||
|
||||
一个比较可靠的生命周期是：
|
||||
|
||||
1. 先用无 Skill 的 Agent 跑真实任务，找到它会错在哪里；
|
||||
|
||||
2. 基于真实 query 写 eval，包括正例、反例和 forbidden load；
|
||||
|
||||
3. 先调 description，确保该加载时加载，不该加载时不加载；
|
||||
|
||||
4. 写主体时删除显而易见的内容，只保留会改变模型行为的判断；
|
||||
|
||||
5. 把失败案例追加到 gotchas，而不是不断加长主流程；改 description 或路由边界时补 eval；
|
||||
|
||||
6. 再做跨模型测试，看不同编排模型对 Skill 触发和执行的差异。
|
||||
|
||||
**Eval**：用一组真实或模拟任务测试 Skill 是否按预期触发、执行和交付结果。
|
||||
|
||||
**Gotchas**：从真实失败里总结出来的"别这么做"清单，往往比正向说明更能提升 Skill 稳定性。
|
||||
|
||||
|
||||
|
||||
每个 Skill 都是一种税。
|
||||
|
||||
它进入索引后，每个会话、每个用户都在为它的 name 和 description 付上下文成本；
|
||||
|
||||
它被加载后，后续对话都在为主体内容付成本。
|
||||
|
||||
所以每一句都要问：没有这句，Agent 会不会做错？如果不会，就删。
|
||||
|
||||
gotchas 是最高价值内容，因为它们来自真实失败。
|
||||
|
||||
正向原则往往模型已经知道，负面边界才是专家经验。
|
||||
|
||||
设计 Skill 中"不要纯白纯黑""连续三页相同节奏是 P0 错误""文字不能压脸""AI 图只在无合适真实图时使用"，都属于 gotchas 或强约束。
|
||||
|
||||
|
||||
|
||||
这也解释了为什么完全自动生成 Skill 只能做初稿。
|
||||
|
||||
模型可以帮你起草结构，但它无法凭空拥有你的失败样本、审美判断、行业边界和用户反馈。
|
||||
|
||||
真正有价值的是人把经验注入进去，再通过 eval 和 gotchas 让它持续变厚。
|
||||
|
||||
## 设计 Skill 的本质：把品味变成约束
|
||||
|
||||
设计类 Skill 不是简单的"AI 会画图"。
|
||||
|
||||
它需要解决模型不稳定、图像限流、文字不锐利、排版不可控、风格一致性难判断等问题。
|
||||
|
||||
设计 Skill 的核心是把专业品味变成模型可执行的限制。
|
||||
|
||||
模型默认会收敛到一些平庸模式：
|
||||
|
||||
Tailwind 大色块、紫色渐变、emoji 堆砌、Inter 字体、发光、过度圆角、无意义动效、信息密度失控。这不是模型没有审美素材，而是没有稳定的取舍原则。
|
||||
|
||||
所以设计 Skill 里最有价值的是主观但明确的约束：
|
||||
|
||||
• 不使用纯白和纯黑，降低刺眼和廉价感；
|
||||
|
||||
• 不让用户任意输入 hex，只提供经过验证的主题色板；
|
||||
|
||||
• 不用紫色多彩渐变、发光和大面积 blur 作为主视觉捷径；
|
||||
|
||||
• 动画只在必要时使用，且只动 transform 和 opacity；
|
||||
|
||||
• 图文卡片优先真实摄影和截图美化，AI 生图只是兜底；
|
||||
|
||||
• 版式骨架先被人工验证，AI 负责填充、组合和微调；
|
||||
|
||||
• 文字必须根据图像主体、明度和可读区域自适应落点、字色、遮罩和断行。
|
||||
|
||||
这些规则看起来限制自由，实际是在保护输出下限。设计类 Skill 的质量来自"替用户排除绝大多数会变丑的选项"。
|
||||
|
||||
|
||||
|
||||
好看不是玄学，而是可拆解、可编码、可检查的行业常识。
|
||||
|
||||
Skill 的价值，就是把这些常识压进 SKILL.md、模板、checklist、主题变量和后验检查里。
|
||||
|
||||
PPT Skill 和社交媒体卡片 Skill 的一个共同方法，是把 AI 的任务从"自由设计"降级成"在高质量骨架里填充"。
|
||||
|
||||
PPT Skill 里，10 种页面布局、5 套主题色、字体三级分工、7:5 / 6:6 / 8:4 网格、hero 与 non-hero 的节奏交替，构成了一个稳定的演示系统。AI 不需要从零发明版式，只需要根据内容选择合适页面类型并填进去。
|
||||
|
||||
社交媒体卡片 Skill 进一步把场景校准到手机信息流：
|
||||
|
||||
3:4 是主战场，1 秒决定停不停下。它不是把 PPT 截图成竖图，而是重新定义了图文品类、版式比例、断行规则和素材优先级。
|
||||
|
||||
11 个内容品类、两套视觉系统、28 个版式骨架、截图美化、地图组件、真实图库和克制 AI 生图，共同构成了"内容平台视觉 Skill"。
|
||||
|
||||
Logo Generator Skill 也是同一逻辑：
|
||||
|
||||
不直接让图像模型一把梭生成 Logo，因为图片模型的文字、结构和可编辑性不稳定；
|
||||
|
||||
它是先生成 SVG 变体，再做展示图和 WebGL 背景。这里把 Logo 本体、展示场景、交互背景拆成不同层，分别用最适合的技术处理。
|
||||
|
||||
人工沉淀审美系统，模型理解内容和语义，代码负责稳定排版和导出，图像模型只处理适合它的视觉部分。
|
||||
|
||||
这比单纯"让 AI 画一张图"更慢一点，但可控、可改、可复用，也更适合内容创作者长期使用。
|
||||
|
||||
|
||||
|
||||
## Skill 生态不能做成仓库列表
|
||||
|
||||
如果一个 Skill 能被图文、案例、评价、使用数据、作者、应用场景反向链接起来，它就不只是一个工具，而是一个社区节点。
|
||||
|
||||
**反向链接**：从使用案例、文章、图文或项目页面反过来链接到某个 Skill，让人能看到它被谁用、怎么用、效果如何。
|
||||
|
||||
当前很多 Skill 展示的问题是：
|
||||
|
||||
列表很长，像 GitHub 仓库名；图标都一样；没有结果展示；没有评价指标；
|
||||
|
||||
多模态 Skill 也只用文本展示；用户不知道哪个适合自己。
|
||||
|
||||
推荐 10 个或 20 个精选 Skill，并讲清楚怎么用，远好过给用户几千个列表。
|
||||
|
||||
|
||||
|
||||
每个 Skill 都应该像一个软件功能页。页面应该说明：
|
||||
|
||||
它解决什么问题，适合什么场景，需要输入什么，输出长什么样，典型提示词是什么，生成结果截图或视频，谁用过、怎么评价，有哪些常见失败情况，如何安装和修改。
|
||||
|
||||
这本质上需要强运营。
|
||||
|
||||
不是把名字列出来，而是一个一个挑、一个一个写介绍、展示结果，最好还有视频讲解。
|
||||
|
||||
GitHub 是代码型 Skill 的天然托管地，因为 Skill 往往包含代码，需要版本管理；
|
||||
|
||||
GitHub 有生态位、版权声明和分发基础；AI 也熟悉 Git 和 GitHub 操作；开源还能覆盖所有 Agent 平台，不绑定单一产品。
|
||||
|
||||
但小红书适合做视觉内容和使用案例分发。
|
||||
|
||||
小红书的优势是内容感知、视觉展示、用户审美和评论体系。
|
||||
|
||||
PPT Skill 和社交媒体卡片 Skill 都已经在小红书之外的人群中传播，比如咖啡馆主理人、数码测评、活动策划、餐厅、三线城市分享场景。这说明 Skill 能跨出 AI 圈。
|
||||
|
||||
应用商店式 Skill 分发也有潜力：更精准推荐、更低使用门槛、可能给创作者分成。
|
||||
|
||||
但对创作者来说，如果只在一个平台上架，就等于押注这个平台能做好产品、生态、分发和市场占领。
|
||||
|
||||
更稳的策略可能是：GitHub 做基础分发和跨平台覆盖，平台 Skillhub / 应用商店做体验优化、运营推荐和商业转化。
|
||||
|
||||
未来的 Skill 平台，本质上会同时是 App Store、GitHub、社区种草页、评价系统和 Agent 工具层。
|
||||
|
||||
|
||||
|
||||
## 普通用户真正卡在哪里
|
||||
|
||||
AI 圈外的人并非不能用 Skill。
|
||||
|
||||
实际观察中，咖啡馆主理人、数码测评、活动策划、健身教练等都能用出好结果。
|
||||
|
||||
真正卡点是交互心智。
|
||||
|
||||
很多人仍然用传统软件思维，以为一次生成就该完成：
|
||||
|
||||
不习惯通过 chat 连续调整；不知道可以要求 AI 改颜色、改字、修溢出、换图；不知道如何提供上下文和素材；也不知道如何从自己的工作流中抽 Skill。
|
||||
|
||||
因此，Skill 产品不仅要提供安装，还要提供使用教育。
|
||||
|
||||
行业 Skill 会是一个很重要的方向。很多行业有非常好的经验和客户洞察：
|
||||
|
||||
健身、法律、餐饮、活动策划、教育、商业化投放等。但行业专家不一定知道如何做 Skill，也担心分享后被盗。
|
||||
|
||||
|
||||
|
||||
这里的关键不是把 Skill 作为服务添加项。
|
||||
|
||||
健身教练可以用 Agent 维护会员饮食、训练、有氧、提醒和反馈，提高客户粘性和服务效率。
|
||||
|
||||
法律从业者可以把琐碎文本处理、条文审查、格式检查做成辅助 Skill，但核心判断仍由人完成。
|
||||
|
||||
餐饮和活动行业可以用图文 Skill 把真实图片和故事包装成可传播内容。
|
||||
|
||||
AI 不能替代线下履约，但可以提高获客、沟通、维护和复用效率。
|
||||
|
||||
这类行业用户只需要基础启蒙：带他做一次需求分析，落地成一个 Skill，他就知道边界在哪里。
|
||||
|
||||
每个行业都有先锋用户：有创造力、有好奇心、想用 AI 获得竞争优势。先服务这些人。
|
||||
|
||||
|
||||
|
||||
## 内容 Skill：文章、产品和案例互相喂养
|
||||
|
||||
从我已有文章看，我正在形成一条很清晰的内容 Skill 路线：
|
||||
|
||||
不是为某个抽象 AI 概念写文章，是先做出一个能用的 Skill，再把制作过程、设计判断和使用场景写成传播内容。
|
||||
|
||||
这类内容有几个特点。
|
||||
|
||||
PPT Skill 最初来自一次 AI 和组织分享，观众问得最多的是 PPT 怎么做，于是从一次交付沉淀成开源 Skill。这是副产品变主产品。
|
||||
|
||||
文章本身像说明书，但不是 README。
|
||||
|
||||
它要讲清楚为什么这样设计、适合谁、边界在哪、真实效果如何，降低用户理解门槛。
|
||||
|
||||
产品演示本身就是内容资产。PPT 截图、图文卡片、Logo 展示图、Desk Card 场景图，都可以成为传播素材。
|
||||
|
||||
Skill 反过来也提升写作效率。社交卡片 Skill 可以把文章段落直接转成更适合小红书、公众号或 Twitter 的视觉卡片。
|
||||
|
||||
|
||||
|
||||
每篇文章都在扩展 Skill 的语义边界。
|
||||
|
||||
PPT 是演示，Social Card 是内容分发，Logo 是项目品牌资产，Desk Card 是硬件和环境 UI，夜巡录则指向游戏 demo 工作流。
|
||||
|
||||
这说明 Skill 不只是"工具产品"，也是内容创作者的表达基础设施。
|
||||
|
||||
过去文章和产品是分开的：先做产品，再写推广。现在 Skill、文章、案例、开源仓库、社交反馈会互相喂养。
|
||||
|
||||
这就是个人产品在 Agent 时代的复利飞轮。
|
||||
|
||||
|
||||
|
||||
## Skill 的边界会继续扩大
|
||||
|
||||
过去"插件"通常意味着软件里的一个按钮。现在 Skill 的边界可以明显更大。
|
||||
|
||||
|
||||
|
||||
浏览器 Skill 会是消费者入口。Tabbit Browser 一类产品说明，Skills 可以进入浏览器场景，变成普通用户在网页、资料、脚本和自动化之间的入口。
|
||||
|
||||
浏览器是大众最熟悉的工作环境，如果 Skill 能以"现成脚本 / 使用案例 / 一键执行"的方式出现，会比裸露 CLI 或 GitHub 仓库更容易被理解。
|
||||
|
||||
硬件 Skill 则说明 AI 可以接管环境 UI。
|
||||
|
||||
AI Desk Card 的价值在于它把 Agent 的能力延伸到了物理环境：
|
||||
|
||||
安装固件、配置 Wi-Fi、写 cron、读取 Memory、选择 widget、刷新墨水屏，全流程由 AI 引导。用户不再面对 App 设置页，AI 本身就是设置页。
|
||||
|
||||
游戏 Skill 代表更长链路的创作流程。
|
||||
|
||||
夜巡录开发手记里提到的"独立游戏 demo Skill"，从玩法母题、原型、素材采集、绿幕抠图、contact sheet、视频生成、音乐、Electron 打包、GitHub Actions 到 Release。
|
||||
|
||||
封装是一套跨程序员、美术、动画、作曲和运维的生产流水线。它的价值是把"做个原型"和"独立交付完整作品"之间的墙变薄。
|
||||
|
||||
|
||||
|
||||
Skill 的未来不只会局限在聊天框里，它会扩展到浏览器、桌面、本地文件、硬件、内容平台、游戏引擎和真实工作环境。
|
||||
|
||||
|
||||
|
||||
## Skill 与 Gene：手写经验和自动进化的边界
|
||||
|
||||
还有一个值得保留但需要谨慎使用的对比：Agent Skill 与 GEP Gene。
|
||||
|
||||
Skill 更像人类预先沉淀的能力包：有明确创建者、明确边界、明确流程和版本。
|
||||
|
||||
Gene / Capsule 这类概念强调运行中从成功经验里自动长出能力：带成功率、变异历史、适用上下文和自动修复机制。
|
||||
|
||||
**Gene / Capsule**：这里指从 Agent 反复执行中的成功路径里沉淀出的可复用经验单元，强调自动演化而不是人工手写。
|
||||
|
||||
这两者不是简单替代关系，是不同的层级。
|
||||
|
||||
Skill 适合承载人的专家经验、审美、行业 SOP、工具不变式和明确交付标准；
|
||||
|
||||
Gene 适合从重复执行中捕捉成功路径，把临时试错变成可复用经验；Capsule 类似把多个 Gene 组合成更长工作流。
|
||||
|
||||
从当前产品现实看，Skill 仍是更可落地的单位，因为它能被写、被审、被发布、被解释、被传播。
|
||||
|
||||
但长期看，自动沉淀 Skill / Gene 化经验会成为方向：Agent 先用通用工具试错，成功后把路径写回 Skill 或生成新的子能力。
|
||||
|
||||
|
||||
|
||||
这也回应了"自动沉淀 Skill"的讨论。系统可以自动发现重复流程，但是否值得沉淀、如何命名、边界在哪里、哪些失败要写进 gotchas，仍然需要人的判断。
|
||||
|
||||
真正理想的形态不是完全自动，也不是完全手写，而是人定义品味和边界，Agent 负责收集证据、提出改动、补充 eval 和维护长尾经验。
|
||||
|
||||
|
||||
|
||||
## 盗用不是靠藏，防御方式是持续分发
|
||||
|
||||
Skill 很难靠闭源防盗。即便不开源，只要看到产出结果，试用几次，也可能被复刻。
|
||||
|
||||
所以防御方式不是"藏起来"，而是开源覆盖更多平台，用影响力威慑过分盗用者，做自媒体让用户知道源头是谁，用持续迭代建立领先，用社区案例和评价体系形成品牌资产。
|
||||
|
||||
在产品壁垒降低的时代，个人产品如果没有渠道、资源和营销，就必须自己做宣发。以前自媒体是可选项，现在是基础设施。
|
||||
|
||||
|
||||
|
||||
## 平台真正该做什么
|
||||
|
||||
如果要做 Skill 平台，不能只押 Skill。用户下载独立端的理由，首先是 Agent 基础体验足够好：
|
||||
|
||||
漂亮好用的客户端，多模型支持，尤其国产模型；文件、项目、memory、CLI、MCP、Skill 管理；
|
||||
|
||||
权限和安全沙箱；长程任务和状态延续；多设备流转，手机控制桌面，桌面反向控制手机；官方高质量插件开箱即用。
|
||||
|
||||
|
||||
|
||||
Workbody 的启发是，它没有做特别独特的东西，只是把该有的基础体验做齐了。很多国内产品连这一点还没做好。
|
||||
|
||||
一些高频、必须、常见的能力应该内置并打磨好，不要让用户自己折腾安装。
|
||||
|
||||
官方插件强，会形成壁垒。多设备、云端和本地互控，也会形成壁垒。
|
||||
|
||||
Skill 与本地环境强相关时，移动端需要遥控 PC。
|
||||
|
||||
Skill 可跨端通用，但依赖本地文件、脚本、浏览器、CLI 的 Skill 在移动端很难直接跑。
|
||||
|
||||
移动端适合轻量级从 0 到 1 创作；桌面端适合重任务和本地环境调用。
|
||||
|
||||
自动沉淀 Skill 是长期方向，但好 Skill 仍需要人。Dumate 等产品提出"自动沉淀 Skill"：从用户重复工作中自动总结流程。
|
||||
|
||||
这个方向成立，但好 Skill 仍需要业务 SOP、品味、测试和迭代。自动生成可以做初版，真正能稳定交付的 Skill 需要打磨。
|
||||
|
||||
|
||||
|
||||
## 一个完整 Skill 生命周期
|
||||
|
||||
如果把前面的判断收束成一条路径，一个完整 Skill 生命周期大概是这样的。
|
||||
|
||||
1 先发现真实需求，从自己或行业用户的重复工作开始。
|
||||
|
||||
2 再做一次高质量产物，不要先抽象，先用 Agent 解决真实任务。
|
||||
|
||||
3 然后抽象流程，识别可复用步骤、输入、输出、约束和工具。
|
||||
|
||||
4 接着工程化模板，把审美、版式、调用、验证和修复机制固化。
|
||||
|
||||
5 再做跨模型测试，好模型看上限，差模型保下限。
|
||||
|
||||
6 之后才是封装发布，GitHub 托管，配 README、示例和安装方式。
|
||||
|
||||
7 再做内容分发，用小红书、Twitter、公众号、视频展示结果。
|
||||
|
||||
8 然后收集反馈，从 issue、评论区、用户案例和平台数据里找真实问题。反馈还要筛选，只吸收能提升泛化和稳定性的部分。
|
||||
|
||||
这条路看起来长，但它的本质很简单：
|
||||
|
||||
每一次真实任务，都不只是在完成任务，而是在积累下一次能调用的能力资产。
|
||||
|
||||
|
||||
|
||||
Agent 时代最稀缺的是可复用的能力组织方式。
|
||||
|
||||
Skill 之所以重要，是因为它第一次让人的经验、工作流和品味，有机会变成一种可以分发、调用、评价和持续迭代的商品。
|
||||
|
||||
这可能才是 Agent 生态里真正的大机会。
|
||||
|
||||
好，今天的内容就到这里。如果你觉得有帮助，欢迎帮我点个赞，或者转发给你需要的朋友。
|
||||
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
# 📊 文章摘要：万字长文：做了些爆款 Skills 以后，我对 Skills 的看法
|
||||
|
||||
> **原文**：[2026-08-20_万字长文_做了些爆款_Skills_以后_我对_Skills_的看法](./2026-08-20_万字长文_做了些爆款_Skills_以后_我对_Skills_的看法.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/sZXl5kHA9LErEwnegpvgXg
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：歸藏的AI工具箱
|
||||
> **发布日期**：2026-08-20
|
||||
> **摘要日期**：2026-08-20
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **经验商品化** — Skill 首次把人的专家经验、工作流和品味封装成可分发、可调用、可迭代的"能力商品"，成为弥合 Agent 使用能力 K 型分化的关键机制。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是爆款 Skill 创作者的一手方法论总结。作者基于 PPT Skill、社交媒体卡片、Logo Generator、AI Desk Card 等实战案例，提出核心判断：Agent 不是抹平而是放大能力差距，用户正出现 K 型分化，而 Skill 是弥合这一差距的机制——它把专家经验外化为可复用的能力单元。文章系统阐述了 Skill 的定义、信息架构（中心短辐射厚、Thin Harness Fat Skills）、质量维护方法（eval + gotchas）、设计类 Skill 的本质（把品味变成约束）、生态分发策略（GitHub + 小红书 + 持续分发防盗）以及 Skill 与 Gene（自动进化经验）的层级关系。局限在于：案例全部来自作者个人实践，缺乏第三方验证与失败率数据，部分判断（如 K 型分化）是趋势推断而非实证结论。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **Agent 放大而非抹平能力差距** — 目标清晰、判断力强的人被 Agent 放大，目标混乱者也被放大混乱，用户呈 K 型分化；UX 设计已难以弥合这一差距 `[分类: 范式突破]`
|
||||
2. **Skill 是能力商品，不是提示词** — 把专家经验、工作流、品味和工具调用封装成可分发、可复用、可迭代的能力单元；用户无需理解 MCP/CLI/memory 等底层概念 `[分类: 范式突破]`
|
||||
3. **Thin Harness, Fat Skills 架构** — harness 保持薄（模型循环、权限、安全边界），Skill 变厚（流程、领域知识、模板、gotchas、eval）；大而全 Agent 塞满上下文是反方向 `[分类: 争议]`
|
||||
4. **description 是路由触发器，不是宣传语** — 好的 description 描述"用户什么时候需要它"（判断条件），坏的只解释"这个 Skill 做什么"（广告）`[分类: 共识]`
|
||||
5. **"中心短，辐射厚"的信息架构** — SKILL.md 只放高信号流程；references/ 按条件读取重文档；scripts/ 放确定性逻辑；文件系统本身就是上下文工程 `[分类: 共识]`
|
||||
6. **每个 Skill 都是一种税** — 进入索引后每个会话都为其 name/description 付上下文成本；每句都要问"没有这句 Agent 会不会做错，不会就删" `[分类: 共识]`
|
||||
7. **gotchas 是最高价值内容** — 失败案例清单来自真实失败，负面边界才是专家经验；正向原则模型往往已知 `[分类: 共识]`
|
||||
8. **设计 Skill 本质是把品味变成约束** — 主观但明确的规则（不用纯白纯黑、禁紫色渐变捷径、动画只动 transform/opacity）在保护输出下限；把 AI 任务从"自由设计"降级为"在高质量骨架里填充" `[分类: 范式突破]`
|
||||
9. **防盗靠持续分发而非闭源** — 开源覆盖更多平台、做自媒体标明源头、持续迭代建立领先；壁垒降低时代自媒体是基础设施 `[分类: 争议]`
|
||||
10. **Skill 与 Gene 是层级而非替代** — Skill 承载人的手写经验（可写、可审、可发布），Gene 从重复执行中自动沉淀成功路径；理想形态是人定义品味和边界，Agent 收集证据、补 eval `[分类: 未探索方向]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者立论隐含三个前提：(1) Agent 能力差距主要来自使用者的组织能力而非模型能力——若模型快速进化到"全自动编排"，K 型分化可能收窄；(2) 专家经验可以被显式编码进 SKILL.md 与规则——但大量隐性知识（审美、时机判断）未必能完整外化；(3) Skill 生态会形成分发-评价体系——这依赖平台方行为，尚无定论。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论据全部来自作者本人爆款 Skill 的一手经验，含具体设计细节（28 个版式骨架、11 类内容、gotchas 示例），内部效度高；但存在明显的幸存者偏差——只讲了成功的 Skill，未提供失败 Skill 的比例与原因。对"Grok Bot 式零配置"路线、平台战略的判断属趋势推断。文章逻辑链条完整：从现象（认知割裂）到定义（能力商品）到方法（架构/维护/分发）逐层递进。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
适用于内容创作、设计、办公自动化等"可描述、可复用"的垂直工作流场景；对强物理约束、高安全合规、需实时数据的场景（作者自己也指出 AI 不能替代线下履约）不适用。作者为中国个人开发者视角，对平台政策、企业级采购的判断需打折。数据时效性：写作时点的 Skill 生态早期特征明显，结论可能随平台格局变化而失效。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "Agent 不是简单抹平能力差距，而是在放大能力差距。"
|
||||
|
||||
> "Skill 是把专家经验、工作流、品味和工具调用封装成可分发、可复用、可迭代的 Agent 能力单元。"
|
||||
|
||||
> "每个 Skill 都是一种税。"
|
||||
|
||||
> "gotchas 是最高价值内容，因为它们来自真实失败。正向原则往往模型已经知道，负面边界才是专家经验。"
|
||||
|
||||
> "好看不是玄学，而是可拆解、可编码、可检查的行业常识。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 一手爆款经验，方法论颗粒度细到可直接操作（description 写法、eval 顺序、gotchas 优先级）
|
||||
- 提出"能力商品""Thin Harness, Fat Skills""中心短辐射厚"等可迁移框架
|
||||
- 覆盖完整生命周期：需求发现→工程化→发布→分发→防盗→反馈
|
||||
|
||||
**不足**：
|
||||
- 样本单一（全部为作者本人作品），存在幸存者偏差
|
||||
- K 型分化、平台演化等判断缺乏数据支撑
|
||||
- 对企业级场景（权限、审计、合规）着墨极少
|
||||
|
||||
**适用场景**：Agent/Skill 开发者、AI 产品经理、内容创作者工具设计、个人产品化路线规划
|
||||
|
||||
**关联建议**：可对照 OpenAI Anthropic 官方 Skill 工程文档验证方法论；与《Grok Bot 诞生》（本批归档）对读，理解零配置与厚 Skill 两条路线的张力；关注作者提到的 Gene/Capsule 自动沉淀方向的后续进展
|
||||
@@ -0,0 +1,199 @@
|
||||
# 开源一个 PPT Skill｜压进了我 10 年的设计经验
|
||||
|
||||
> **来源**：微信公众平台（歸藏的AI工具箱）
|
||||
> **作者**：歸藏的 AI 工具箱
|
||||
> **发布日期**：2026-08-20（原文未标注明确日期，按下载日占位）
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/GXjjlxpIJ604HVCCZJkUBA
|
||||
|
||||
---
|
||||
|
||||
上周被李继刚老师邀请去做了场私享会，关于 AI 和组织的访谈。
|
||||
|
||||
散场之后，发现大家问得最多的一句话是："那个 PPT 是什么做的，能不能开源一下？"
|
||||
|
||||
没想到副产品成了主产品。
|
||||
|
||||
索性就把它开源了，叫 guizang-ppt-skill（github.com/op7418/guizang-ppt-skill）。
|
||||
|
||||
今天这篇文章聊聊这个 Skill 长什么样，以及作为一个做了十年设计的人，我为什么会觉得它好看。
|
||||
|
||||
## 它长什么样
|
||||
|
||||
打开 Skill 生成的 PPT，第一眼的感觉大概是：这不太像 AI 做的。
|
||||
|
||||
|
||||
|
||||
几个直观特征：
|
||||
|
||||
- 封面：墨色底 + 衬线大标题，背后一层若隐若现的 WebGL 流体在缓缓流动
|
||||
- 正文：底色切回纸白，墨字压在上面，像一本摊开的印刷杂志
|
||||
- 翻页：横向左右滑动，键盘、滚轮、触屏手势都行，不是 PowerPoint 的下一页
|
||||
- 元数据：每页四个角落有小号等宽字，写着 "Act II · 15 / 25" 这类报刊页码
|
||||
|
||||
我给这套视觉基调起了个名字，叫"电子杂志 × 电子墨水"。
|
||||
|
||||
灵感来源是《Monocle》《卫报》《NYT》这类印刷杂志的版式传统，叠加 Kindle 电子纸的阅读美学，再用当代 Web 的交互语法串起来。
|
||||
|
||||
## 它能做什么
|
||||
|
||||
Skill 目前提供 10 种页面布局、5 套主题色预设，和一套完整的翻页交互。
|
||||
|
||||
10 种布局覆盖了一场 15-30 页分享会用到的几乎所有页面类型：
|
||||
|
||||
|
||||
|
||||
开场封面、章节幕封、数据大字报、左文右图、图片网格、Pipeline 流程、悬念问题、大引用、Before/After 对比、图文混排。
|
||||
|
||||
每种都是一段可以直接粘贴的 HTML 骨架，改掉文字和图片就能用。
|
||||
|
||||
|
||||
|
||||
5 套主题分别对应不同场景：
|
||||
|
||||
**墨水经典** — 商业发布、通用默认
|
||||
|
||||
**靛蓝瓷** — 科技、研究、AI 发布会
|
||||
|
||||
**森林墨** — 自然、可持续、人文
|
||||
|
||||
**牛皮纸** — 怀旧、文学、独立杂志
|
||||
|
||||
**沙丘** — 艺术、设计、创意
|
||||
|
||||
每套主题只是 6 个 CSS 变量的不同取值，切换主题只要替换 :root 里那 6 行代码。
|
||||
|
||||
用户不允许自定义 hex，后面会说原因。
|
||||
|
||||
翻页交互支持键盘左右箭头、鼠标滚轮、触屏滑动、底部圆点跳转、ESC 键打开缩略图索引。
|
||||
|
||||
尽量接近在浏览器里翻一本真实杂志的体验。
|
||||
|
||||
产物是一个单文件 HTML，双击浏览器就能看，发给别人也只是一个文件，不用担心字体和动画在别人电脑上乱掉。
|
||||
|
||||
|
||||
|
||||
## 怎么用
|
||||
|
||||
其实这份 Skill 真正的价值不在模板本身，而在它定义了一套人 × AI 协作做 PPT 的接口。
|
||||
|
||||
下面三件事，是我自己用了一周后，觉得最值得告诉别人的。
|
||||
|
||||
### 先跟 AI 说清这 6 件事
|
||||
|
||||
Skill 装好之后，你只需要说一句"帮我做一份杂志风 PPT"，Claude 会反过来主动问你 6 个问题：
|
||||
|
||||
1. 受众是谁、什么场景？（行业内部 / 商业发布 / 私享会）
|
||||
2. 分享时长多久？（15 分钟 ≈ 10 页，30 分钟 ≈ 20 页）
|
||||
3. 有没有原始素材？（文档、数据、旧 PPT、文章链接）
|
||||
4. 有没有图片、放在哪？
|
||||
5. 想要哪套主题色？（5 套预设里选）
|
||||
6. 有没有硬约束？（必须包含 XX 数据 / 不能出现 YY）
|
||||
|
||||
你不用一次说完，它会一条条问。答完之后，它会先给你一份大纲和主题节奏表，对齐之后再开始写代码——这一步拦截了我 80% 的返工。
|
||||
|
||||
以前用 AI 做 PPT 最痛的是什么？是它直接开始写，等你看到第 10 页才发现整体方向就是错的。这套澄清流程把"对齐"前置到了开头。
|
||||
|
||||
|
||||
|
||||
### 图片这样塞
|
||||
|
||||
图片放在和 index.html 同级的 images/ 文件夹，文件名有规则：
|
||||
|
||||
```
|
||||
ppt/
|
||||
├── index.html
|
||||
└── images/
|
||||
├── 01-cover.jpg
|
||||
├── 03-figma.png
|
||||
└── 05-dashboard.png
|
||||
```
|
||||
|
||||
- 页号补零 + 英文语义——01 不是 1，cover 不是 fengmian。方便按顺序排，AI 引用也清晰
|
||||
- 照片用 JPG，截图用 PNG——截图带文字，PNG 保真不糊
|
||||
- 单张 ≥ 1600px 宽——大屏投影才不糊
|
||||
|
||||
你只需要告诉 Claude"第 3 页是 Figma 界面截图"，它会自动写成 images/03-figma.png，你把同名文件丢进文件夹就行。
|
||||
|
||||
### 无损换图的秘诀：同名覆盖
|
||||
|
||||
文案改完想换张图，结果要全局搜替换路径，一不小心就把 HTML 改坏了。
|
||||
|
||||
正确做法只有一句话：新图用同名覆盖旧图，HTML 一个字不改。
|
||||
|
||||
## 为什么长成这样
|
||||
|
||||
聊完怎么用，聊聊它为什么是这个样子。
|
||||
|
||||
好看不是玄学，是一套可以拆解的决策。我做的事情，本质上是把杂志行业一百年沉淀下来的排版语言，搬到了 HTML 里。
|
||||
|
||||
### 字体的三级分工
|
||||
|
||||
|
||||
|
||||
- 衬线 → "观点"。大标题用衬线，读者一眼就觉得"这是一句该被重视的话"。
|
||||
- 非衬线 → "信息"。正文密度高、阅读不累。
|
||||
- 等宽 → "元数据"。页眉页脚的章节号、日期、页码，像杂志页脚，也像终端里的代码。
|
||||
|
||||
读者不用费劲想，眼睛自己就知道这句话是正文还是附注。
|
||||
|
||||
### 色彩的纪律
|
||||
|
||||
|
||||
|
||||
纸白、墨色，加一个重点色，就够了。
|
||||
|
||||
纯白刺眼、纯黑暴力，印刷行业从来不这么干，Kindle 也是。
|
||||
|
||||
Skill 的 5 套主题，底色没有一个是 #FFFFFF，字色没有一个是 #000000。
|
||||
|
||||
每套只暴露 6 个 CSS 变量，SKILL.md 里写明：不允许用户自定义 hex，只能五选一。
|
||||
|
||||
约束越严，风格越稳。 保护美学，比给用户自由更重要。
|
||||
|
||||
### 网格与节奏
|
||||
|
||||
|
||||
|
||||
7:5、6:6、8:4 几套固定网格保证单页秩序。
|
||||
|
||||
hero 页和 non-hero 页必须交替，保证整本的节奏。
|
||||
|
||||
一页密、一页疏，就是翻杂志时那种呼吸感。
|
||||
|
||||
Skill 里写了条硬规则：连续三页以上相同主题会被判为 P0 错误。
|
||||
|
||||
没有节奏的 PPT 就是一沓 slide 堆成的 PDF。
|
||||
|
||||
## 写在最后
|
||||
|
||||
上面这些规则，没有一条是我发明的。
|
||||
|
||||
我做了十年设计，UI、交互、AI 特效都干过，这些其实都是行业常识。
|
||||
|
||||
我只是把它们一条条写进了 SKILL.md 和 checklist.md，让 AI 能替我逐条执行而已。
|
||||
|
||||
换句话说，这个 Skill 就是我这十年审美的一个压缩包。
|
||||
|
||||
以前做一份像样的 PPT，我得花两天手动调网格、选字号、抠色值。
|
||||
|
||||
现在把素材丢给 AI，它按照这些规则直接拼出来，我只需要检查一下。
|
||||
|
||||
也正因为这样，我才敢把它开源。
|
||||
|
||||
规则本来就不是我的独家，《Monocle》的设计师比我早用了几十年，我只是把它 copy 到了 2026 年的 HTML 里。
|
||||
|
||||
|
||||
|
||||
Skill 已经放在 GitHub 上：github.com/op7418/guizang-ppt-skill
|
||||
|
||||
README 里有一段"给 AI 的安装 prompt"，复制粘贴给你的 Claude Code或其他 AI Agent，它会自动完成安装。
|
||||
|
||||
装好之后对它说一句"帮我做一份杂志风 PPT"就会触发。
|
||||
|
||||
也可以在 Bloome 这个 Agent 里面用，目前是免费的：
|
||||
|
||||
https://bloome.im/agent/join/iKXCLtkD?ref=wNL9Ew2G
|
||||
|
||||
如果觉得内容对你有帮助的话，可以帮我点个赞，或者分享给你需要的朋友。
|
||||
|
||||
也可以在评论区分享一下你拿这个 Skill 做的 PPT。
|
||||
@@ -0,0 +1,77 @@
|
||||
# 📊 文章摘要：开源一个 PPT Skill｜压进了我 10 年的设计经验
|
||||
|
||||
> **原文**：[2026-08-20_开源一个_PPT_Skill_压进了我_10_年的设计经验](./2026-08-20_开源一个_PPT_Skill_压进了我_10_年的设计经验.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/GXjjlxpIJ604HVCCZJkUBA
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：歸藏的 AI 工具箱
|
||||
> **发布日期**：2026-08-20
|
||||
> **摘要日期**：2026-08-20
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **经验压缩包** — 把专家十年沉淀的设计规则逐条写进 SKILL.md 让 AI 逐条执行，Skill 的本质是专家经验的"压缩包"，而非模板集合。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
作者（十年经验的设计师）在一次私享会后应听众要求开源了 guizang-ppt-skill——一个生成"电子杂志 × 电子墨水"风格单文件 HTML 演示文稿的 Claude Skill，包含 10 种页面布局、5 套主题色预设与完整翻页交互。文章依次介绍 Skill 的形态、使用方式（6 问澄清流程、图片命名规则、同名覆盖换图）以及背后的设计决策依据（字体三级分工、色彩纪律、网格与节奏）。其真正价值不在 PPT 工具本身，而在示范了"专家经验 → 可执行规则 → AI 代劳"的 skill 构建方法论；局限是产品介绍性质偏重，关键主张（如拦截 80% 返工）无验证数据，且未讨论 Skill 的适用边界。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **副产品成主产品** — 私享会访谈的 PPT 反而成为被追问最多的产物，遂开源为 guizang-ppt-skill（github.com/op7418/guizang-ppt-skill）。 `[分类: 共识]`
|
||||
2. **产物是单文件 HTML** — 10 种布局、5 套主题（各仅 6 个 CSS 变量取值）、完整翻页交互，双击浏览器即看，分发无字体与动画兼容问题。 `[分类: 共识]`
|
||||
3. **6 问澄清流程把对齐前置** — Skill 触发后 Claude 主动追问受众/时长/素材/图片/主题/硬约束，先出大纲与节奏表对齐再写代码，作者称拦截了 80% 返工。 `[分类: 争议]`
|
||||
4. **图片接口约定** — images/ 目录 + 页号补零英文语义命名（01-cover.jpg）、照片 JPG/截图 PNG、单张 ≥1600px；换图用同名覆盖、HTML 一字不改。 `[分类: 共识]`
|
||||
5. **字体三级分工** — 衬线承载"观点"、非衬线承载"信息"、等宽承载"元数据"，读者无需思考即可分辨句子层级。 `[分类: 共识]`
|
||||
6. **色彩纪律：约束优于自由** — 5 套主题底色无 #FFFFFF、字色无 #000000；禁止用户自定义 hex 只能五选一，"约束越严，风格越稳"。 `[分类: 争议]`
|
||||
7. **节奏硬规则** — hero 页与 non-hero 页必须交替，连续三页以上相同主题判为 P0 错误，"没有节奏的 PPT 就是一沓 slide 堆成的 PDF"。 `[分类: 共识]`
|
||||
8. **Skill=十年审美的压缩包** — 规则没有一条是作者发明的，全是行业常识；作者做的是把《Monocle》等杂志百年排版语言写进 SKILL.md 与 checklist.md 让 AI 执行。 `[分类: 范式突破]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
- 预设"杂志风"是普遍可接受的演示美学，未考虑政企汇报等偏好模板化/官方风格的场景。
|
||||
- "拦截 80% 返工"基于作者一周的个人使用，样本为一人的主观感受。
|
||||
- 隐含读者已有 Claude Code 或兼容 Agent 环境，非技术用户路径（Bloome）仅一句带过。
|
||||
|
||||
### 论据与逻辑
|
||||
- 论证方式是"展示+归因"：先展示效果特征，再逐条解释设计依据，逻辑清晰但属于自我印证。
|
||||
- 诚实度较高：明确承认规则全部来自行业常识而非原创，这反而增强了可信度。
|
||||
- 设计原则（字体分工、色彩纪律、网格节奏）有印刷行业百年实践背书，论据来源可靠。
|
||||
|
||||
### 边界与局限
|
||||
- 未讨论 Skill 的失败案例或生成质量的不稳定情形。
|
||||
- 单文件 HTML 形态的固有局限（打印导出、企业模板合规、离线字体体积）未提及。
|
||||
- "不允许自定义 hex"是强约束设计，对有品牌色需求的用户反而增加了门槛，作者未讨论该权衡的适用范围。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "换句话说，这个 Skill 就是我这十年审美的一个压缩包。"
|
||||
|
||||
> "好看不是玄学，是一套可以拆解的决策。"
|
||||
|
||||
> "约束越严，风格越稳。 保护美学，比给用户自由更重要。"
|
||||
|
||||
> "没有节奏的 PPT 就是一沓 slide 堆成的 PDF。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：以真实开源作品示范了"专家经验规则化"的 skill 构建路径；设计决策逐条给出依据，可迁移性强；对自身非原创性的坦诚提升了说服力；6 问澄清与同名覆盖等细节可直接复用。
|
||||
|
||||
**不足**：无效果验证数据；对适用边界（企业合规、打印、品牌色）零讨论；产品宣传成分与 Bloome 推广链接稀释了方法论浓度。
|
||||
|
||||
**适用场景**：skill 设计方法论参考（如何把领域专家经验转写为可执行规则）；快速生成高质感 HTML 演示文稿；本院 skill 评测与澄清流程设计的对照样本。
|
||||
|
||||
**关联建议**：与《企业内Agent工具落地实践》中 skill 三层渐进加载、评测分层互证——本文是"个人经验型 skill"的实例，该文提供企业级治理框架；其"P0 错误硬规则"做法可借鉴到本院 skill 的 checklist 机制；可与本院 arno-gen-pptx（PptxGenJS 路线）对比两种 PPT 生成技术路线的取舍。
|
||||
@@ -0,0 +1,388 @@
|
||||
# 我复刻了 Claude 刚发布的生成式 UI 交互！
|
||||
|
||||
> **来源**：微信公众平台（歸藏的 AI 工具箱）
|
||||
> **作者**：歸藏的 AI 工具箱
|
||||
> **发布日期**：2026-08-20（原文未标注明确日期，按下载日占位）
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/3IQIs6zP5jfdTwmT5LUJ6g
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
前天 Anthropic 在 Claude 里面上线了基于生成式 UI 的新交互。
|
||||
|
||||
可以帮你在聊天信息流里面用地吗可视化的方式介绍一些概念和信息，远比原来的纯文本要好理解。
|
||||
|
||||
|
||||
|
||||
我之前就一直在看类似的方案，刚好 Claude 发了，我就感觉我也得加紧做了。
|
||||
|
||||
同时刚好也可以逆向参考一下他的方案。
|
||||
|
||||
疯狂 PUA 了两天 Codex 和 Claude 还真让我搞出来了！
|
||||
|
||||
|
||||
|
||||
这个功能能让 AI 直接在聊天里画交互式图表，流式输出，边生成边渲染。
|
||||
|
||||
以前让 AI 写网页，得等整个页面代码全部生成完才能渲染，等半天。
|
||||
|
||||
现在不一样了。
|
||||
|
||||
你能看着图表一笔一笔在画布上画出来，SVG 节点一个接一个冒出来。
|
||||
|
||||
生成过程本身就很震撼，而且生成完直接就能交互。
|
||||
|
||||
直接在我的 Agent 产品 Code Pilot 里面体验：https://github.com/op7418/CodePilot
|
||||
|
||||
这篇内容我就会介绍一下它的用法，以及具体的实现过程和一些注意事项。
|
||||
|
||||
## 有哪些好玩的用法
|
||||
|
||||
数据分析：数字终于能看懂了
|
||||
|
||||
比如让它画一个"美国和伊朗冲突每天成本估算"的图表。
|
||||
|
||||
以前 AI 给你一大段文字，数字关系根本看不清。
|
||||
|
||||
现在直接出图表，每部分金额多少一目了然，文字和图表混在一起输出，该解释的解释，该画的画。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
小工具：写个可交互的计算器啥的
|
||||
|
||||
让它做一个复利计算器。
|
||||
|
||||
拖滑块改初始金额、改投资年限，下面的图表和数字实时变化。
|
||||
|
||||
这不是静态图片，是真的能交互的小工具。
|
||||
|
||||
贷款计算、单位换算这类东西都能做。
|
||||
|
||||
|
||||
|
||||
架构图：程序员最爱
|
||||
|
||||
你可以让他帮你画某个项目的架构，或者某一个实现方案的可视化。
|
||||
|
||||
比如这里我让它画 API 到 JWT 身份验证的完整流程。
|
||||
|
||||
特性对比、流程图、层级结构全是图形化的，比看文字描述理解架构快太多了。
|
||||
|
||||
|
||||
|
||||
分析线上数据
|
||||
|
||||
还有个玩法直接丢一个 GitHub 仓库链接给它，它自己抓数据然后可视化分析。
|
||||
|
||||
比如这里我就把我自己的项目地址 Codepilot 发给他让他分析。
|
||||
|
||||
星数、fork 数、技术栈、架构设计、核心模块，全部画成图表。
|
||||
|
||||
一眼就能看清楚项目全貌，比读一大段文字强多了。
|
||||
|
||||
|
||||
|
||||
可以进行交互和深度解释
|
||||
|
||||
这个最强的是他跟模型结合的相当紧密，不是一顿输出就完事了。
|
||||
|
||||
你可以跟他生成的示意图进行交互，让他进行更详细的解释。
|
||||
|
||||
比如这里我让他解释季风和洋流的关系。
|
||||
|
||||
|
||||
|
||||
如果我们想更详细的了解就可以点击那个洋流机制的按钮。
|
||||
|
||||
就会自动向当前的模型发送指令，继续帮你生成洋流机制的示意图。
|
||||
|
||||
|
||||
|
||||
当然我们可以进行更加复杂的交互，比如常见的物理数学公式的可视化。
|
||||
|
||||
这种对于学生来说非常好用，每个参数都可以通过滑块和输入控制，动画立刻会发生变化。
|
||||
|
||||
|
||||
|
||||
国产模型支持
|
||||
|
||||
Codepilot 实现之后不只是 Claude 能用。
|
||||
|
||||
Kimi K2.5、Minimax M2.5、Anthropic 原生模型都跑得起来。
|
||||
|
||||
K2.5 画的图形我觉得甚至比 Sonnet 4.6 还好看，架构分析也很详细。
|
||||
|
||||
如果用这个功能我推荐首选 K2.5 试试。
|
||||
|
||||
好，到这里，模型的玩法基本上展示完了。
|
||||
|
||||
如果你不关心是如何实现的，可以直接去装个 Codepilot，愉快地玩耍了。
|
||||
|
||||
## 如何实现的
|
||||
|
||||
|
||||
|
||||
### Claude 怎么做的
|
||||
|
||||
Claude.ai 官方用的是 tool_use 机制。
|
||||
|
||||
模型调用一个专用 tool 输出结构化的 widget 内容，
|
||||
|
||||
前端解析 tool 调用的 input 参数来渲染。
|
||||
|
||||
这个方案在 Claude.ai 自己的架构下没问题。
|
||||
|
||||
但搬到 CodePilot 就不行了，原因有三个：
|
||||
|
||||
第一，SDK 限制。
|
||||
CodePilot 用 Claude Agent SDK 的 preset: 'claude_code' 模式，
|
||||
没法注册自定义 tool。
|
||||
SDK 暴露的是 text delta 流，tool 层面扩展不了。
|
||||
|
||||
第二，流式体验。
|
||||
tool_use 的结果要等 input_json_delta 拼完才能渲染，
|
||||
不支持 HTML 增量渲染。
|
||||
代码围栏方式下，HTML 随文本流式到达，边生成边预览。
|
||||
|
||||
第三，渲染隔离。
|
||||
|
||||
Claude.ai 用 Shadow DOM 做隔离。
|
||||
|
||||
我们选了 sandbox iframe。
|
||||
|
||||
iframe 隔离更彻底——完全独立的 JS 执行环境，
|
||||
|
||||
CSP 精确控制资源加载，
|
||||
|
||||
不存在样式泄漏和脚本逃逸。
|
||||
|
||||
### 我们怎么做的
|
||||
|
||||
触发：代码围栏
|
||||
|
||||
模型输出一段特殊的 Markdown 代码围栏来触发渲染：
|
||||
|
||||
```
|
||||
show-widget
|
||||
{"title":"training_flow","widget_code":"<svg width=\"100%\" viewBox=\"0\" 0\" 680\" 400\">..."}
|
||||
```
|
||||
|
||||
这个格式复用了 CodePilot 已有的代码围栏模式
|
||||
（image-gen-request、batch-plan 等），
|
||||
前端 parser 链天然支持。
|
||||
|
||||
|
||||
|
||||
渲染：sandbox iframe
|
||||
|
||||
每个 widget 渲染在一个 sandbox="allow-scripts" 的 iframe 里。
|
||||
iframe 的 srcdoc 是一个精心构建的 receiver 页面。
|
||||
CSP 策略只放行 4 个 CDN 域名的外部脚本，
|
||||
connect-src 'none' 禁止所有网络请求。
|
||||
|
||||
通过 postMessage 接收内容更新。
|
||||
流式预览阶段发 widget:update，不执行脚本。
|
||||
最终渲染发 widget:finalize，执行脚本。
|
||||
|
||||
ResizeObserver 监听内容高度变化，
|
||||
通过 postMessage 报告给父页面。
|
||||
|
||||
所有 `<a>` 点击被拦截，
|
||||
转发给父页面在新窗口打开。
|
||||
|
||||
主题同步靠监听父页面的 class 变化，
|
||||
实时切换深色/浅色模式。
|
||||
|
||||
|
||||
|
||||
CSS 变量桥接
|
||||
|
||||
这是让 widget 跟应用视觉融合的关键。
|
||||
|
||||
CodePilot 用 OKLCH 色彩空间的 CSS 变量。
|
||||
Anthropic 的 widget 设计指南用 --color-background-primary 这类标准变量名。
|
||||
|
||||
桥接层在 iframe 初始化时，
|
||||
把 CodePilot 的变量值注入 iframe 的 :root。
|
||||
模型按指南写的 CSS 就能直接用当前主题的颜色。
|
||||
|
||||
深色模式切换时，
|
||||
父页面检测到 class 变化，
|
||||
重新算变量值推给 iframe。
|
||||
|
||||
|
||||
|
||||
流式渲染
|
||||
|
||||
这是整个实现里最复杂的部分。
|
||||
|
||||
模型逐 token 生成。
|
||||
任意时刻收到的 widget 代码都可能是不完整的 JSON、
|
||||
不完整的 HTML、不完整的 `<script>` 标签。
|
||||
|
||||
处理流程是这样的：
|
||||
|
||||
正则匹配 ```show-widget，
|
||||
区分"未闭合"和"已闭合"状态。
|
||||
|
||||
手动定位 "widget_code":" 后面的内容，
|
||||
逐字符反转义。
|
||||
不能用 JSON.parse，因为 JSON 还没写完。
|
||||
|
||||
检测到未闭合的 `<script>` 标签时，
|
||||
在 `<script` 之前截断，
|
||||
避免 JavaScript 代码显示成可见文本。
|
||||
|
||||
120ms debounce 防止 iframe 更新太频繁。
|
||||
|
||||
流式内容剥离所有脚本和事件处理器，
|
||||
预览阶段不需要交互。
|
||||
|
||||
|
||||
|
||||
### 体验打磨：那些不该被注意到的细节
|
||||
|
||||
其实从代码或者是实现方案来看并不复杂，复杂的是体验的打磨。
|
||||
|
||||
这里边有太多可以影响体验的地方，需要让用户注意不到那些细节和生成的过程。
|
||||
|
||||
这就需要在每个阶段去用不同的方式处理：
|
||||
|
||||
1. 1.那些看起来不像流式的细节
|
||||
2. 2.不该出现的内容
|
||||
|
||||
|
||||
|
||||
文字消失
|
||||
|
||||
模型先输出一段介绍文字（"我来为你可视化解释..."），
|
||||
然后开始输出 widget 围栏。
|
||||
围栏一出现，前面的文字突然没了，
|
||||
等 widget 渲染完才回来。
|
||||
|
||||
原因是 parseAllShowWidgets() 对纯文本返回空数组。
|
||||
围栏刚出现但还没闭合时，
|
||||
围栏前的文字被传进这个函数，结果被丢了。
|
||||
|
||||
修复：检测到围栏前的文本不含已完成的 widget 围栏时，
|
||||
直接渲染为 `<MessageResponse>`，绕过解析函数。
|
||||
|
||||
高度跳变
|
||||
|
||||
widget 渲染完的瞬间，整个聊天区域抖一下。
|
||||
|
||||
iframe 初始高度 0px。
|
||||
内容第一次报告实际高度时可能是 400px+，
|
||||
CSS transition 让这个变化在 300ms 内完成，
|
||||
就成了明显的动画跳变。
|
||||
|
||||
修复：首次高度报告时临时禁用 CSS transition，
|
||||
让高度瞬间到位。
|
||||
后续高度微调才用平滑过渡。
|
||||
|
||||
Finalize 闪烁
|
||||
|
||||
widget 从流式预览切到最终渲染时，内容闪一下。
|
||||
|
||||
receiver iframe 在 finalize 时执行 root.innerHTML = html 整体替换 DOM。
|
||||
即使新旧内容完全一样（纯 SVG widget），
|
||||
浏览器也会触发一帧重绘。
|
||||
|
||||
修复：finalize 时先把新 HTML 解析到临时容器，
|
||||
分离出 script 元素。
|
||||
比较去掉 script 后的 visual HTML 跟当前 DOM——
|
||||
一样就跳过 innerHTML 替换，直接追加 script 执行。
|
||||
纯 SVG widget 实现了零重绘 finalize。
|
||||
|
||||
滚动回跳
|
||||
|
||||
聊天正在自动滚到底部，
|
||||
突然跳回几百像素前的位置，再跳回来。
|
||||
|
||||
streaming 结束时，
|
||||
StreamingMessage 组件卸载，MessageItem 组件挂载。
|
||||
这是两个完全不同的 React 组件，
|
||||
内部的 WidgetRenderer 被销毁再重建。
|
||||
新实例的 iframe 高度从 0 开始，
|
||||
内容区高度骤降，
|
||||
use-stick-to-bottom 检测到高度变化就触发了滚动调整。
|
||||
|
||||
修复：模块级高度缓存。
|
||||
每当 widget 报告高度时，
|
||||
以 widgetCode 前 200 字符为 key 写入缓存。
|
||||
新的 WidgetRenderer 实例在 useState 初始化时从缓存读高度，
|
||||
iframe 以正确高度开始渲染，
|
||||
不存在 0→实际的过渡。
|
||||
|
||||
Script 代码泄露
|
||||
|
||||
带 Chart.js 的 widget 加载时，
|
||||
底部显示一大段 JavaScript 代码。
|
||||
|
||||
模型输出的 `<script>` 标签在流式传输中逐字符到达。
|
||||
`<script>` 开标签到了但 `</script>` 还没到时，
|
||||
sanitizeForStreaming 剥离了开标签，
|
||||
但标签内的 JavaScript 代码变成了裸文本节点，
|
||||
被浏览器渲染成可见内容。
|
||||
|
||||
修复：在 StreamingMessage 的 partial code 提取后，
|
||||
检测最后一个 `<script` 有没有匹配的 `</script>`。
|
||||
没有就在 `<script` 位置截断。
|
||||
widget 指南规定 script 放最后，截断不影响视觉内容。
|
||||
截断期间展示 shimmer 遮罩，
|
||||
状态栏显示"正在为可视化添加交互动画"。
|
||||
|
||||
iframe Ready 竞态
|
||||
|
||||
极少数情况下 widget 完全不渲染，停在 0px 高度。
|
||||
|
||||
WidgetRenderer 通过 useEffect 注册 message 事件监听。
|
||||
但 iframe 的 receiver script 加载完就立刻发 widget:ready。
|
||||
如果 iframe 加载速度快于 React effect 执行，
|
||||
widget:ready 在监听器注册之前就发出去了，
|
||||
iframeReady 永远不会变成 true。
|
||||
|
||||
修复：在 iframe 元素上加 onLoad 回调兜底。
|
||||
onLoad 触发时 receiver script 必然已执行完，
|
||||
是可靠的就绪信号。
|
||||
|
||||
React 组件树稳定性
|
||||
|
||||
widget 在围栏闭合瞬间闪一次。
|
||||
|
||||
两个问题叠在一起：
|
||||
流式 partial widget 没有 React key，
|
||||
闭合后获得 key="w-0"，key 变了导致 remount。
|
||||
shimmer overlay 用外包 `<div>` 实现，
|
||||
改变了组件树结构，type 变了又导致 remount。
|
||||
|
||||
修复：给 partial widget 算稳定的 key
|
||||
（w-N，N 是在最终 segments 数组中的预期位置），
|
||||
跟闭合后的 key 一致。
|
||||
shimmer overlay 移进 WidgetRenderer 内部，
|
||||
通过 showOverlay prop 控制。
|
||||
组件树始终是 `<WidgetRenderer key="w-N">`，不变。
|
||||
|
||||
## 写在最后
|
||||
|
||||
整个生成式 UI 系统，
|
||||
难的不是"让一段 HTML 在 iframe 里跑起来"。那很简单。
|
||||
|
||||
真正的复杂度在于：
|
||||
让这个 iframe 在流式传输、组件生命周期切换、主题变化这些状态转换中，
|
||||
保持视觉上的稳定。
|
||||
|
||||
每一个"闪一下""跳一下""消失一下"，
|
||||
都要去理解 React 的 reconciliation、
|
||||
浏览器的渲染管线、
|
||||
postMessage 的时序。
|
||||
|
||||
最终效果是：
|
||||
用户看到模型的回复里自然地穿插着图表和示意图。
|
||||
|
||||
就像它们本来就该在那里。
|
||||
|
||||
这是今天的内容。如果觉得对你有帮助的话，可以帮我点个赞，或者是发给有需要的朋友。
|
||||
@@ -0,0 +1,74 @@
|
||||
# 📊 文章摘要：我复刻了 Claude 刚发布的生成式 UI 交互！
|
||||
|
||||
> **原文**：[2026-08-20_我复刻了_Claude_刚发布的生成式_UI_交互](./2026-08-20_我复刻了_Claude_刚发布的生成式_UI_交互.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/3IQIs6zP5jfdTwmT5LUJ6g
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：歸藏的 AI 工具箱
|
||||
> **发布日期**：2026-08-20
|
||||
> **摘要日期**：2026-08-20
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **流式生成 UI** — 在聊天流内边生成边渲染可交互 widget，真正的工程难点不是"跑起来"，而是状态转换中的视觉稳定
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
Anthropic 在 Claude 上线生成式 UI 交互后，作者在两天内于自研 Agent 产品 CodePilot 中复刻了该能力：AI 直接在聊天里流式输出交互式图表（数据分析、可交互计算器、架构图、仓库分析、公式可视化），生成完即可交互，并支持 Kimi K2.5、Minimax M2.5 等非 Anthropic 模型。文章价值在于完整披露了实现方案——代码围栏触发 + sandbox iframe 渲染 + CSS 变量桥接 + 流式增量渲染，以及七个真实踩坑（文字消失、高度跳变、finalize 闪烁、滚动回跳、script 泄露、iframe 竞态、React remount）的成因与修复。局限是部分论断（如 K2.5 画图优于 Sonnet 4.6）为主观体验，未附基准数据。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **官方方案不可直接照搬** — Claude.ai 用 tool_use + Shadow DOM，但 Claude Agent SDK 的 claude_code preset 无法注册自定义 tool，且 tool_use 必须等 input_json_delta 拼完才能渲染，不支持增量 `[分类: 共识]`
|
||||
2. **代码围栏触发渲染** — 模型输出 `show-widget` 特殊代码围栏而非 tool 调用，复用已有 parser 链，HTML 随文本流式到达、边生成边预览 `[分类: 争议]`
|
||||
3. **sandbox iframe 隔离** — 相比 Shadow DOM，iframe 提供完全独立 JS 环境、CSP 精确控制（connect-src 'none'）、无样式泄漏和脚本逃逸 `[分类: 共识]`
|
||||
4. **两阶段渲染协议** — 流式预览发 widget:update（不执行脚本），最终渲染发 widget:finalize（执行脚本），预览阶段剥离所有脚本和事件处理器 `[分类: 共识]`
|
||||
5. **CSS 变量桥接实现主题融合** — iframe 初始化时把宿主 OKLCH 色彩变量注入 :root，模型按标准变量名写 CSS 即自动适配深浅色主题 `[分类: 共识]`
|
||||
6. **流式渲染需手写解析而非 JSON.parse** — 逐字符反转义未完成的 JSON，检测未闭合 `<script>` 标签提前截断防代码泄露，120ms debounce 控制 iframe 更新频率 `[分类: 共识]`
|
||||
7. **真正的复杂度在体验打磨** — 七个"闪一下/跳一下/消失一下"问题分别源于 React reconciliation、浏览器渲染管线、postMessage 时序，需高度缓存、稳定 key、onLoad 兜底等手段逐一消解 `[分类: 范式突破]`
|
||||
8. **国产模型可用** — Kimi K2.5、Minimax M2.5 均能驱动该功能，作者主观认为 K2.5 图形质量超过 Sonnet 4.6 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
- 假定读者具备 React/iframe/CSP 前置知识，修复细节点到为止，未给完整代码
|
||||
- 假定"边生成边渲染"是生成式 UI 的必要体验，未论证用户是否真的需要看到生成过程
|
||||
- 假定模型能稳定输出符合规范的 show-widget 围栏格式，未讨论格式出错时的降级策略
|
||||
|
||||
### 论据与逻辑
|
||||
- 论据以第一手实现经验为主，每个问题都给出"现象→根因→修复"闭环，可信度高
|
||||
- 三个不采用官方方案的理由（SDK 限制、流式体验、渲染隔离）具体且可验证
|
||||
- "K2.5 比 Sonnet 4.6 好看"属于个人观感，无对照样本；"疯狂 PUA 了两天"是营销话术而非工程描述
|
||||
|
||||
### 边界与局限
|
||||
- 未涉及安全风险的深层讨论：模型生成的 HTML/JS 在 sandbox 内执行，CSP 白名单 4 个 CDN 域名，但供应链风险未评估
|
||||
- widget 与模型的"深度交互"（如点击按钮继续生成）机制仅展示效果，未披露实现细节
|
||||
- 未提供性能数据（流式渲染的 token 吞吐影响、iframe 数量上限）
|
||||
- CodePilot 为作者自己的产品，文章兼具产品推广属性，评价立场需注意
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "真正的复杂度在于：让这个 iframe 在流式传输、组件生命周期切换、主题变化这些状态转换中，保持视觉上的稳定。"
|
||||
|
||||
> "每一个'闪一下''跳一下''消失一下'，都要去理解 React 的 reconciliation、浏览器的渲染管线、postMessage 的时序。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：罕见地把生成式 UI 的完整工程实现（含七个踩坑修复）公之于众；sandbox iframe + 代码围栏 + 流式两阶段渲染的方案可直接迁移到任何聊天式 AI 产品；对官方方案的逆向分析有理有据。
|
||||
|
||||
**不足**：模型能力对比为主观判断；安全与性能维度缺失；部分交互机制只展示未讲解；自带产品推广色彩。
|
||||
|
||||
**适用场景**：为聊天类 AI 产品添加生成式 UI / 可视化输出能力；设计流式渲染管线；排查 React 组件切换导致的视觉抖动类问题。
|
||||
|
||||
**关联建议**：与《从 OpenCode 升级到 V2，我们看到上下文工程与驾驭工程的三个趋势》互为参照——前者关注 Agent 输出端的渲染工程，后者关注 Agent 驾驭端的系统工程；sandbox iframe 隔离思路也可与 Agent 安全沙箱设计话题关联。
|
||||
Reference in New Issue
Block a user