《图解Skill：AI提效实战指南》读书笔记
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
一、这本书真正想解决什么问题
这本书表面上讲的是 Agent Skills：怎么写
SKILL.md，怎么设计 description，怎么拆分参考文档，怎么把多个技能串成工作流，怎么测试、发布和维护技能。但它真正解决的问题不是“怎么写提示词”，而是：当 AI 已经能完成很多任务之后，我如何不再每天重复教它做同一件事。提示词解决的是一次对话里的沟通问题，技能解决的是跨任务、跨时间、跨工具的经验复用问题。
这件事和我现在很有关。无论是写作、App 开发、文章配图、代码审查、技术调研，很多工作不是“不会做”，而是每次都要重新交代上下文、格式、偏好、禁忌和检查标准。时间不是浪费在核心判断上，而是浪费在重复说明和返工上。
如果只带走一个判断：AI 提效的关键，不是把每次提示词写得更长，而是把反复出现的工作流程沉淀成可执行、可维护、可验证的技能。
二、核心概念
这是什么
技能的本质，是把我脑子里的经验写成一份智能体能执行的操作手册。它不是一句“帮我写得专业点”，而是明确告诉智能体：什么时候触发、读取什么输入、按什么流程处理、输出到哪里、哪些事不能做、哪里需要暂停让我判断。
提示词像临时口头交代，技能像长期有效的工作 SOP。区别不在形式，而在是否能复用、能迭代、能被不同场景稳定调用。
用在什么场景
适合用于反复出现、结果需要稳定、多步骤、有固定偏好的任务，比如读书笔记、周报、文章配图、代码审查、App 上架文案、会议纪要、数据分析。
不适合用于一次性的探索性问题，或者本来就希望每次结果不同的创意发散。把还没摸清楚的流程过早写成技能，会把错误流程固化下来。
怎么用
我可以从最常用的 3 类任务开始：
- 写作：把自己的写作风格、禁用表达、文章结构偏好写成技能。
- 开发：把代码审查标准、iOS 项目约定、提交前检查项写成技能。
- 独立产品：把 App 发布清单、截图文案、版本更新说明做成技能。
核心不是一次写完，而是先让 AI 裸跑真实任务，再把反复出错的地方沉淀进技能。
实践步骤
- 找出最近一周重复做过 3 次以上的任务，写下任务名。
- 对其中一个任务，记录每次都要交代 AI 的固定要求。
- 把这些要求整理成：触发场景、输入、流程、输出、禁止清单。
- 用一个真实任务跑一遍，记录 AI 哪些地方没按预期做。
- 把失败点补进技能里的“踩坑点”，而不是每次临时提醒。
这是什么
书里最实用的区分是：提示词负责语义判断，脚本负责确定性规则，技能负责把两者组合成流程。
这点很关键。很多人用 AI 做自动化失败，不是因为模型不行，而是把确定性任务交给模型，比如长文分块、文件重命名、表格计算、图片尺寸处理。这类任务应该交给脚本。模型适合做判断、归纳、表达和选择，不适合承担必须 100% 稳定的机械操作。
用在什么场景
适合任何混合型任务：既有判断，也有固定流程。比如文章配图：哪里需要配图由模型判断；图片文件命名、路径插入、尺寸校验最好交给脚本或明确规则。
不适合把所有逻辑都塞进
SKILL.md。技能不是万能文本，它应该调度工具，而不是替工具干活。怎么用
开发时尤其要记住：
- Java / iOS / 产品架构分析：交给模型判断。
- 格式化、统计、切分、校验：交给脚本。
- 多步骤流程、标准、边界和验收：写进技能。
我的独立开发工作里，最应该先做的是“发布前检查技能”：模型检查文案和风险，脚本检查文件、尺寸、截图数量、版本号和 changelog 是否齐全。
实践步骤
- 拿一个当前流程，拆成“判断类动作”和“机械类动作”。
- 判断类动作保留给模型，比如选择角度、识别问题、生成说明。
- 机械类动作交给脚本，比如分块、改名、插入路径、统计字数。
- 在技能里只写清楚什么时候调用脚本、脚本输出什么。
- 每次出错时判断：这是模型判断错，还是规则没有锁死。
这是什么
上下文窗口看起来越来越大，但它不是无限仓库。越多信息塞进上下文，模型越容易漏掉关键指令。技能的按需加载，就是为了解决这个问题：启动时只加载技能名片，用到时再读取完整说明，重型资料再拆到
references/ 里。这个观点对我很重要。过去我容易把所有规则、背景、模板一次性塞给 AI，以为信息越全越好。实际结果经常是模型变慢、变钝、遗漏重点。
用在什么场景
适合复杂项目、长对话、多技能协作场景。尤其是写作工作流、代码重构、数据分析这类任务，如果把草稿、规范、历史讨论、参考资料全放进上下文，质量会下降。
不适合把长期规则全塞到一个巨大的技能文件里。
SKILL.md 应该放核心流程，细节按需引用。怎么用
我做技能时要控制主文件长度，只保留：
- 什么时候触发；
- 输入输出；
- 核心流程；
- 禁止清单；
- 踩坑点；
- 必须读取哪些参考文件。
大段示例、模板、API 文档、风格样例，放到
references/。并且要在主文件里明确写：“需要某种场景时，先读取某个文件。”实践步骤
- 检查现有技能，主文件超过 3000 字的先标记。
- 把模板、案例、术语表拆到
references/。
- 在主文件中写清楚读取条件，而不是假设智能体会自己发现。
- 长任务尽量通过文件路径传递结果，不把全文塞回对话。
- 当对话开始变慢或输出漏规则时，开新对话，只带关键上下文继续。
这是什么
多个技能可以串联、并联、循环，形成工作流。但书里真正有价值的不是“全自动跑到底”，而是“哪里该自动，哪里必须让我拍板”。
比如写作工作流里，素材分析、草稿生成、润色、配图可以自动化，但大纲选择最好保留人工检查点。因为角度选择是判断，不是执行。
用在什么场景
适合写作、产品设计、内容发布、App 上架、技术方案评审。凡是中间有关键方向选择的流程，都不应该无脑自动化。
误用是把 AI 当成流水线，让它从素材一路生成终稿并发布。这样看似省事，实际把最重要的判断权交出去了。
怎么用
我可以把写作流程拆成：
- 素材分析；
- 生成多个角度；
- 我选择一个；
- 写初稿；
- 润色并输出报告；
- 我看报告决定是否重写；
- 配图和排版。
这里真正节省时间的是让 AI 做重复工作，不是替我决定文章该写什么。
实践步骤
- 选一个常用流程，画出每一步。
- 标记哪些步骤是“执行”，哪些步骤是“判断”。
- 执行步骤自动化，判断步骤设置暂停点。
- 技能之间用文件传递，不用长文本互相复制。
- 每次工作流失败，只改失败的那一环，不一口气重写全部。
这是什么
技能不是写完就结束，它和软件一样需要生命周期：先分析需求，再设计流程，再实现，再测试，最后上线或发布。书里最现实的一点是：测试不能只凭“感觉还行”，尤其是要准备正例、反例和边界用例。
这让我意识到，技能本身就是一个小产品。只要它会反复影响我的工作，就值得用产品和工程的方式维护。
用在什么场景
适合任何长期使用的个人技能、团队技能、公开技能。尤其是会读写文件、联网、调用脚本、发布内容的技能，必须加安全边界。
不适合为了某个单次问题设计庞大的技能体系。先跑通 MVP，再补功能，再拆结构，再长期打磨。
怎么用
我应该给自己的核心技能建一个简单评测集。比如读书笔记技能至少要测试：
- 一本技术书摘录；
- 一本商业书摘录；
- 一段很短的材料；
- 一个不该触发读书笔记的任务。
每次改技能后，拿旧版本和新版本输出对比，而不是只看新版本是否顺眼。
实践步骤
- 为每个常用技能写 2 个正例、1 个反例。
- 每次改技能前复制旧版本。
- 用同一批输入跑新旧版本，比较是否更稳定。
- 把失败原因归纳成通用规则，不为单个例子打补丁。
- 涉及文件、网络、删除、发布的技能，先用假数据跑一遍。
三、对我真正有用的 4 个点
Insight
AI 不是用一次就算提效。真正的提效是：同一类任务第二次、第三次、第五次出现时，我不需要重新解释偏好、格式、流程和禁忌。
我的理解
我以前很多所谓“用 AI 提效”，其实只是把手工劳动换成了手工指挥。每次都要补充背景、纠正风格、解释输出格式，本质上还是自己在当流程管理器。技能的价值，是把这部分管理成本降下来。
如何用在我身上
我的开发工作里，可以先做“代码审查技能”和“iOS 发布检查技能”。我的副业里，可以做“App 更新日志技能”“小红书图文拆解技能”“读书笔记技能”。生活里，可以做“周复盘技能”，固定检查时间、精力、输出和偏差。
Insight
书里反复强调先跑通 MVP，再补功能、拆结构、持续优化。这和软件开发一样。过早设计复杂技能，最后问题会变得不可定位。
我的理解
我很容易在一开始就想把规则写全，结果技能变长、触发变复杂、维护成本上升。更好的做法是先写一个只解决核心问题的版本，真实使用几次，让失败暴露出来。
如何用在我身上
独立开发里尤其适用。不要一开始就做完整的增长、文案、截图、发布、复盘工作流。先做一个“版本发布笔记技能”，只负责根据 changelog 生成 App Store 更新说明。稳定后再接截图、上架检查和社媒分发。
Insight
书里对人机分工的判断很清楚：判断、取舍、验收留给人；重复、整理、格式化、生成交给智能体。这比“AI 替代一切”的说法更接近现实。
我的理解
AI 最大的问题不是不能干活，而是它不知道什么对我重要。尤其是写作和产品方向，如果让 AI 一路自动跑到底，最后会得到一个工整但没有判断的结果。我不能把关键判断外包，只能把判断前后的脏活累活外包。
如何用在我身上
写作时，我要保留选题、角度、大纲选择和最终删改权。开发时，我要保留架构取舍和上线判断权。AI 可以帮我生成方案、补测试、查遗漏，但不能替我决定产品要不要做、文章该不该发。
Insight
技能一旦能读文件、写文件、联网、运行脚本，就不再是普通提示词。它有真实操作能力，也就有真实风险。
我的理解
这点容易被忽视。自己写的技能也可能误删、误覆盖、误发；别人的技能更可能有隐藏风险。越是本地智能体，能力越强，越要设置边界。
如何用在我身上
以后凡是涉及本地文件的技能，都要默认放在专属工作目录里运行。覆盖文件前先备份，删除和发布必须二次确认。公开分享技能前，要删掉本地路径、密钥和个人配置，不能把自己的环境假设写死进去。
四、经验、反直觉点和被忽略的细节
最反直觉的是：上下文越大，不等于越该塞更多东西。信息太多会稀释注意力。技能设计的目标不是“让 AI 一次知道所有事”，而是“让 AI 在正确时间读取正确材料”。
第二个容易忽略的点是
description。它不是写给人看的简介，而是技能能否被正确触发的入口。一个模糊的 description，会让好技能根本没有机会执行。功能定义和触发场景要贴近真实用户表达，而不是写成漂亮但无用的宣传语。第三个点是，禁止清单和踩坑点不是一回事。禁止清单是事前确定的底线，比如不能覆盖原文件、不能编造数据；踩坑点是实际使用中反复暴露的问题，比如忘记读取参考模板、改坏写作风格、返回全文挤爆上下文。后者往往比流程说明更有价值。
第四个点是，不是所有任务都值得做成技能。只做一次的任务，用提示词就够了；流程还没稳定的任务，先不要固化；需要创造性发散的任务，也不一定要技能化。技能有维护成本，不能把“可技能化”误解成“都应该技能化”。
第五个点是，工作流不是越自动越好。自动化最危险的地方，是把关键判断也顺手自动掉。大纲选择、产品方向、是否发布、是否重写，这些地方需要人工检查点。真正好的工作流，是让我从执行者变成导演，而不是让我退出现场。
五、可执行清单
接下来一周可以做的 3 件事
- 整理一个自己的“写作风格技能”
具体动作：写清楚角色定位、3 条风格要点、10 条以内禁用表达、常用术语表。
为什么做：写作是高频任务，风格反复交代最浪费时间。
如何判断有效：同一篇草稿改写前后，AI 是否少用空话、套话、过度总结句。
- 做一个“iOS / App 发布检查技能”MVP
具体动作：只覆盖版本号、更新说明、截图、隐私说明、发布前手动确认这 5 项。
为什么做：发布流程重复且容易漏项，适合先技能化。
如何判断有效：下一次发版时，是否减少了临时回忆和反复检查。
- 给现有常用技能加“踩坑点”部分
具体动作：把最近 3 次 AI 输出不满意的问题写进去，每条都变成具体规则。
为什么做：技能真正的质量来自失败后的修正。
如何判断有效：同类错误下次是否明显减少。
一个可以立刻尝试的小实验
今天选一篇准备写的文章，不让 AI 直接写正文。先让它只做两件事：分析素材、生成 3 个不同切入角度，并明确暂停等待我选择。
这个实验的价值，是验证“人工检查点”是否能提升最终文章质量。判断标准不是生成速度，而是我是否更容易选出一个真正想写的方向。
一个长期可以坚持的习惯
每周五花 15 分钟维护一次技能：新增一个踩坑点，删除一条无效规则，检查一个技能是否过长。
记录方式很简单：每个技能维护一个
CHANGELOG.md，只写日期、改了什么、为什么改。长期看，这就是个人工作经验的版本管理。六、我应该避免什么
避免把提示词越写越长，却不沉淀成技能。长提示词只能解决这一次，下一次仍然要重来。
避免把还没跑通的流程过早固化。尤其是新产品增长、写作选题、复杂开发流程，先用真实任务跑几遍，再决定哪些步骤稳定。
避免把所有资料塞进
SKILL.md。主文件太长会拖慢理解，也会增加遗漏。模板、案例、术语、API 文档应该拆出去，按需读取。避免让 AI 一路自动化到最终发布。生成、整理、润色可以交出去；选择、判断、验收和发布确认必须保留。
避免无脑安装和运行第三方技能。尤其是会联网、执行脚本、读写本地文件的技能，必须先检查
SKILL.md 和 scripts/，第一次用假数据跑。避免为了显得专业而设计复杂工作流。先让一个技能解决一个明确问题，跑通之后再串联。复杂系统不是设计出来的，是稳定的小模块逐步长出来的。
七、一句话总结
这本书真正改变我的，是让我把 AI 使用从“临时指挥”转向“把自己的工作经验工程化”。
2026.07.02 20:27
沪·赵巷