写在前面
欢迎大家关注Rocky的公众号：WeThinkIn
欢迎大家关注Rocky的知乎：Rocky Ding
《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源：【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book，欢迎大家Star～
Rocky最新撰写的10万字AI Agent（AI智能体）深入浅出全维度解析文章： 深入浅出完整解析AI Agent（AI智能体）的核心基础知识
AIGC/LLM/AI Agent算法岗/开发岗求职面试内推学习社群 （涵盖AIGC、LLM大模型、AI Agent、传统深度学习、自动驾驶、机器学习、计算机视觉、自然语言处理、强化学习、大数据挖掘、具身智能、元宇宙、AGI等AI行业最新面试干货经验与核心知识）欢迎大家加入：https://t.zsxq.com/33pJ0
大家好，我是Rocky。
核心导读
很多人第一次接触 Agent Skills，会把它理解成一个装着提示词的文件夹：写一份 SKILL.md，再放几个脚本，模型似乎就"学会"了一项新能力。
这个理解不能说错，但只看到了静态文件，没有看到它进入 Agent 运行时之后发生了什么。
Agent Skills 真正有价值的地方，不是发明了一种新的 Markdown 格式，而是把能力发现、语义路由、按需加载、程序性执行和结果验证连接成了一套运行时协议。 文件夹只是载体；能否在正确时机选中正确能力、只加载必要上下文、调用受控脚本并证明任务完成，才决定一个 Skill 是工程资产，还是另一份更长的 Prompt。
这也是本文与常见 Skill 入门教程最不同的地方：重点不是逐项教你填写 YAML，而是回答四个更底层的问题。
- Agent 如何在几十甚至几百个 Skills 中找到真正相关的能力？
- 渐进式披露为什么能降低上下文成本，又会引入什么新风险？
SKILL.md、references/、scripts/、assets/分别应该承担什么责任？- 怎样把"模型大概会做"升级为"系统可重复执行、可检查、可回滚"？
Rocky 认为，Skills 的长期价值不在"让模型知道更多"，而在把个人经验和组织流程变成可路由、可执行、可验收的软件资产。
一、先校准定义：Skill 不是 Prompt，也不等于 Tool
按照当前 Agent Skills 开放规范，一个 Skill 至少是一个包含 SKILL.md 的目录。SKILL.md 由 YAML frontmatter 和 Markdown 指令正文组成；目录还可以包含 scripts/、references/、assets/ 以及其他资源。
但"目录里有什么"只是格式定义。要理解它的本质，需要把 Skill 拆成三个层次。
| 层次 | 回答的问题 | 典型内容 |
|---|---|---|
| 能力包 | 这项能力由什么组成？ | 指令、参考资料、脚本、模板、样例 |
| 路由描述 | 什么时候应该使用它？ | name、description、适用范围、排除条件 |
| 运行时行为 | 激活后如何完成任务？ | 加载资源、执行工具、更新状态、验证结果 |
Prompt 通常解决"这一轮应该怎么回答"；Tool 解决"模型可以调用哪个外部动作"；Skill 则更接近一份程序性知识包：它告诉 Agent 在什么条件下，按照什么流程，组合哪些工具和资源，最终以什么标准收尾。
因此，下面三个等式都不成立：
Skill ≠ 一段 Prompt \text{Skill}\neq\text{一段 Prompt} Skill=一段 Prompt
Skill ≠ 一个 API 或 CLI 命令 \text{Skill}\neq\text{一个 API 或 CLI 命令} Skill=一个 API 或 CLI 命令
Skill ≠ 模型新增了参数化知识 \text{Skill}\neq\text{模型新增了参数化知识} Skill=模型新增了参数化知识
更准确的表达是：
Skill = 路由元数据 + 程序性指令 + 可选资源 + 执行与验收约束 \text{Skill}=\text{路由元数据}+\text{程序性指令}+\text{可选资源}+\text{执行与验收约束} Skill=路由元数据+程序性指令+可选资源+执行与验收约束
模型没有因为目录出现而重新训练。变化发生在推理期：宿主把相关说明和资源加入当前任务的可用环境，使模型能够沿着一条经过设计的路径工作。
二、真正的调用链：发现、匹配、加载、执行、验证
一个生产级 Skill 的生命周期，不应被简化为"读取 SKILL.md"。完整链路至少包含五个状态。
2.1 Discovery：先让 Agent 知道"有哪些能力"
运行时首先建立 Skill 索引。开放规范把 name 和 description 视为核心发现信息：名称提供稳定身份，描述同时说明"能做什么"和"何时使用"。
这一阶段的关键并不是把说明写得华丽，而是提高可路由性。一个只有"帮助处理文档"的描述，会同时匹配 PDF、Word、表格、OCR 和排版任务；描述越宽泛，路由冲突越大。反过来，如果描述只列一个过窄例子，又会漏掉真实请求。
可以把路由过程抽象为：
s ∗ = arg max s i ∈ S P ( s i ∣ q , m i , c ) s^*=\arg\max_{s_i\in\mathcal{S}} P(s_i\mid q,m_i,c) s∗=argsi∈SmaxP(si∣q,mi,c)
其中， q q q 是用户请求， m i m_i mi 是第 i i i 个 Skill 的元数据， c c c 是当前环境与权限上下文。只有当最高匹配结果越过激活阈值，而且不违反排除条件时，运行时才应该激活该 Skill。
这说明 description 不是普通文档摘要，而是一个近似"路由分类器"的自然语言接口。它会直接影响误触发和漏触发。
2.2 Routing：决定是否激活，以及多个 Skills 如何排序
真实任务经常同时匹配多个能力。例如"分析一篇论文并导出 Word"至少涉及论文解析、技术写作和 DOCX 导出。运行时必须决定：
- 哪个 Skill 是主流程，哪个只是下游交付能力；
- 多个 Skill 是串行、并行还是互斥；
- 冲突指令按什么优先级解决；
- 哪些资源只在后续阶段加载。
这已经不是单个文件的格式问题，而是调度问题。最简单的实现依赖模型自己判断；更稳健的实现会加入显式依赖、阶段状态和冲突规则。
可把一次多 Skill 任务写成有向图：
G = ( V , E ) , V = { Skill 1 , ... , Skill n } G=(V,E),\quad V=\{\text{Skill}_1,\ldots,\text{Skill}_n\} G=(V,E),V={Skill1,...,Skilln}
边 ( s i , s j ) (s_i,s_j) (si,sj) 表示 s j s_j sj 依赖 s i s_i si 的输出或验收结果。只要依赖没有通过，后续 Skill 就不应继续。这种图结构比"把所有说明一次塞给模型"更接近可靠的软件工作流。
2.3 Activation：只在选中后加载完整指令
当前开放规范建议采用三级渐进式披露：启动时只加载约百 token 的元数据；激活后加载完整 SKILL.md，其指令体建议控制在约 5000 tokens、主文件建议少于 500 行；其他资源再按需要读取。
这里必须区分"规范建议"和"硬性约束"。name、description 及其格式属于规范要求；500 行是为了控制上下文和可维护性给出的建议，不是超过一行就失效的解析规则。
2.4 Execution：把自然语言计划落到确定性动作
激活之后，Agent 可能读取参考资料、运行脚本、调用 API、编辑文件或操作外部系统。真正可靠的 Skill 不会把所有工作都交给模型临场生成，而会尽量把稳定、可测试的步骤固化为程序。
例如，文档转换命令、数据校验器、图片压缩器、发布前检查脚本，都比"请认真检查一遍"更可靠。原因很简单：自然语言擅长描述意图和处理开放问题，程序擅长重复执行明确规则。
2.5 Verification：完成不是一句话，而是一组证据
很多 Skill 在最后一步失败：文件确实生成了，但打不开；草稿接口返回 ID，但正文图片是本地路径；代码改完了，却没有运行测试；下载结束了，文件其实是反爬页面。
所以 Skill 的最后一个状态必须是验证，而不是自我陈述。验证至少回答：
- 目标产物是否存在且格式正确；
- 内容身份是否与用户请求一致；
- 外部副作用是否落在正确环境；
- 图片、链接、接口和依赖是否真实可用；
- 失败时能否定位、重试或回滚。
只有当执行结果和验收证据同时成立，任务才从"动作已发生"变成"目标已完成"。
三、渐进式披露：它解决的是上下文税，不是知识本身
如果有 N N N 个 Skills，每个完整说明平均消耗 L i L_i Li tokens，全部预加载的上下文成本近似为：
C all = ∑ i = 1 N L i C_{\text{all}}=\sum_{i=1}^{N}L_i Call=i=1∑NLi
当 Skill 数量增加时，这个成本线性增长，而且每一轮推理都可能重复支付。更糟糕的是，过多无关规则会稀释当前任务的重要约束，使模型在长上下文中"看见了，但没遵守"。
渐进式披露把成本拆成三层：
C progressive = ∑ i = 1 N M i + ∑ j ∈ A I j + ∑ k ∈ R D k C_{\text{progressive}}=\sum_{i=1}^{N}M_i+\sum_{j\in A}I_j+\sum_{k\in R}D_k Cprogressive=i=1∑NMi+j∈A∑Ij+k∈R∑Dk
其中， M i M_i Mi 是所有 Skills 的短元数据， A A A 是本轮被激活的 Skill 集合， I j I_j Ij 是其主指令， R R R 是真正被读取的参考资源集合， D k D_k Dk 是对应资源成本。通常 ∣ A ∣ ≪ N |A|\ll N ∣A∣≪N，且 ∣ R ∣ |R| ∣R∣ 只覆盖当前任务所需材料，因此平均上下文开销显著下降。
但渐进式披露并不是免费的优化。它把"预加载成本"换成了三个新的系统问题。
第一，路由召回率。如果元数据没有让 Agent 选中正确 Skill，后面的高质量说明永远不会被读取。
第二，读取时机。过晚读取关键约束，可能导致前面已经做出不可逆操作；过早读取所有参考，又会退化为全量加载。
第三，隐藏依赖 。如果 SKILL.md 引用多层文档，而文档再引用其他资源，模型可能遗漏必要条件。当前规范因此建议引用链保持浅层，避免"参考文件套参考文件"的深层迷宫。
所以，渐进式披露真正优化的是上下文预算的分配：先用很少的信息判断需要什么，再把高成本知识投向当前最相关的任务。它不会自动保证选得对、读得全或执行得好。
四、四类文件的职责边界：不要把文件夹当杂物间
一个可维护的 Skill，需要让不同内容回到各自最合适的载体。
4.1 SKILL.md：控制面，不是百科全书
SKILL.md 应该包含任务目标、触发边界、主流程、关键决策点、资源路由和完成标准。它的作用类似控制面：告诉 Agent 现在处于哪一步、下一步该读取或执行什么、什么条件下必须停止。
如果把所有背景知识、API 全文、几十个示例和异常日志都塞进去，激活成本会迅速膨胀，真正重要的约束反而被淹没。
4.2 references/：深知识与长尾规则
参考目录适合放领域规范、复杂格式说明、供应商差异、长样例和低频故障手册。它们的共同特征是：有价值，但不是每次任务都需要。
好的引用方式不是"需要时阅读 references 目录"，而是明确路由条件，例如：
- 输入是本地 HTML 时读取
references/local-html.md； - 公式渲染失败时读取
references/math-repair.md； - 目标平台是 CSDN 时读取对应发布合同。
4.3 scripts/：确定性执行面
脚本适合处理可计算、可测试、重复率高的动作，包括结构解析、格式转换、哈希校验、接口调用、图片处理和自动化测试。
脚本的价值不只是节省 tokens。模型临时写代码时，错误会随提示、上下文和采样变化；经过测试的脚本可以把同一输入映射到更稳定的输出，并通过退出码、日志和结构化报告暴露失败。
4.4 assets/：最终产物依赖的静态材料
模板、样式、图片、字体、配置样例和固定数据适合放在 assets/。它们不是给模型逐字阅读的知识，而是执行阶段需要复用的材料。
这四类内容可以用一句话区分：
SKILL.md决定流程，references/提供知识，scripts/完成动作，assets/提供材料。
五、从"可能会做"到"稳定交付"：关键是把概率性推理包在确定性边界里
Skill 经常被宣传为"把几十次试错压缩成一次说明"。这个方向成立，但"写了说明"并不等于"一定做对"。大模型执行自然语言流程仍然具有概率性，会遗漏步骤、误解条件，也会对失败结果进行过度乐观的解释。
更合理的工程目标，是把模型放在它擅长的位置：理解意图、处理歧义、形成计划、解释证据；再用确定性组件约束高风险环节。
可以把 Skill 的任务成功率粗略分解为：
P ( success ) = P ( route ) ⋅ P ( plan ∣ route ) ⋅ P ( execute ∣ plan ) ⋅ P ( verify ∣ result ) P(\text{success})=P(\text{route})\cdot P(\text{plan}\mid\text{route})\cdot P(\text{execute}\mid\text{plan})\cdot P(\text{verify}\mid\text{result}) P(success)=P(route)⋅P(plan∣route)⋅P(execute∣plan)⋅P(verify∣result)
任何一项接近零，整条链路都会失败。只优化指令正文，相当于主要提高 P ( plan ) P(\text{plan}) P(plan)；生产系统还必须同时建设路由、执行和验证。
一个成熟 Skill 至少应包含以下确定性边界：
| 环节 | 应提供的工程约束 |
|---|---|
| 输入 | 类型、编码、大小、来源身份、必要字段校验 |
| 权限 | 可用工具、网络范围、凭证读取位置、审批条件 |
| 执行 | 幂等性、超时、重试、退出码、临时文件隔离 |
| 输出 | Schema、路径、文件格式、内容最小要求 |
| 验收 | 独立检查、远端回读、哈希/数量/状态核对 |
| 恢复 | 同一对象原地修复、断点续跑、回滚策略 |
这里最重要的变化是：不要让生成者兼任唯一裁判。 模型说"已经完成"只是一个待验证声明。测试程序、结构化验证器、远端状态回读和真实资源探测，才是完成证据。
六、Superpowers 说明了什么，又不能证明什么
Superpowers 是一个面向 Coding Agent 的技能框架与软件开发方法论。它把头脑风暴、计划、工作树、测试驱动开发、调试、代码审查和完成验证组织成可组合 Skills，并让前一个阶段显式引导后一个阶段。
它最有价值的启示不是"安装更多 Skills 就能得到高级工程师"，而是展示了Skill 可以充当工作流节点。单个 Skill 不再只解决一个局部任务，而是通过依赖关系构成软件交付图：
需求澄清 → 设计 → 计划 → 实现 → 测试 → 审查 → 收尾 \text{需求澄清}\rightarrow\text{设计}\rightarrow\text{计划}\rightarrow\text{实现}\rightarrow\text{测试}\rightarrow\text{审查}\rightarrow\text{收尾} 需求澄清→设计→计划→实现→测试→审查→收尾
这种做法把软件工程中的阶段门、检查清单和证据要求写进 Agent 的运行路径，确实能减少"拿到需求就直接改代码"的冲动式行为。
但它不能自动证明三件事。
第一，流程完整不等于需求正确。错误的问题定义，会被一套严谨流程更稳定地实现出来。
第二，强制 TDD 或多轮审查不一定适合所有任务。小型修复、探索性原型、一次性脚本和高不确定研究，需要不同的流程强度。
第三，更多阶段会增加 tokens、延迟和交互成本。必须用任务风险决定治理强度，而不是让所有请求都经过同一条重型流水线。
因此，评价 Superpowers 或任何 Skill 框架，不能只看仓库热度或 Skill 数量，而要看它能否在目标场景中提高任务成功率、缺陷发现率和可恢复性，并控制额外成本。
七、Skills 与 Function Call、MCP、CLI 的边界
Skills 经常与 Function Call、MCP、CLI 放在一起讨论，但它们解决的不是同一层问题。
| 机制 | 核心问题 | 主要产物 |
|---|---|---|
| Function Call / Tool Use | 模型选择什么动作、生成什么参数 | 结构化调用请求 |
| MCP | 外部能力如何发现、连接、鉴权和调用 | 标准化协议边界 |
| CLI | 如何用紧凑命令驱动成熟软件 | 命令、退出码、文本/文件结果 |
| Skills | 某类任务应在何时、按什么流程完成 | 程序性知识与工作流约束 |
它们可以组合，而不是彼此替代。一个 Skill 可以指导 Agent 调用 CLI，也可以通过 MCP 使用企业系统；模型仍可能用 Function Call 生成底层工具请求。
最典型的组合链路是：
用户目标 → Skill 路由 → 流程决策 → Tool/MCP/CLI 执行 → Skill 验收 \text{用户目标}\rightarrow\text{Skill 路由}\rightarrow\text{流程决策}\rightarrow\text{Tool/MCP/CLI 执行}\rightarrow\text{Skill 验收} 用户目标→Skill 路由→流程决策→Tool/MCP/CLI 执行→Skill 验收
Skills 关心的是"怎样把任务做完整"；工具协议关心的是"怎样把某个动作送达执行端"。把前者当成后者，会低估流程知识；把后者全部塞进 Skill，又会重复实现连接、权限和治理基础设施。
八、生产级 Skills 最容易被忽略的成本：安全、版本与负迁移
Skill 是可执行的知识包，也意味着它会扩大 Agent 的供应链和权限面。
8.1 指令注入与信任边界
第三方 SKILL.md、参考资料和脚本都可能包含危险指令。运行时不应因为文件位于 Skill 目录，就默认它拥有与系统指令相同的可信等级。至少需要区分：官方内置、组织审核、用户安装和临时下载四类来源，并为其配置不同权限。
8.2 脚本权限与副作用
一个文档处理 Skill 可能只需要读取文件，却在脚本中获得整个主目录和网络凭证；一个发布 Skill 可能把"保存草稿"误写成"立即发布"。最小权限、目标白名单、危险动作确认和审计日志必须落到执行层，不能只写在提醒文字里。
8.3 版本漂移
外部 API、CLI 参数、平台页面和模型宿主都会变化。Skill 在版本 v 1 v_1 v1 上成功，并不能证明它在 v 2 v_2 v2 上仍然有效。应记录运行时兼容条件、依赖版本、最后验证日期，并让验收失败能够阻止继续交付。
8.4 负迁移
把特定仓库、特定团队或特定平台积累的经验迁移到另一环境，可能产生比无 Skill 更隐蔽的错误。例如原环境允许覆盖文件，新环境要求保留审计副本；原平台用 status=0 表示草稿，另一平台可能把它解释为提交审核。
因此，真正可移植的不是"所有环境执行同一套命令"，而是把不变量与宿主适配层分开：任务目标、证据标准和风险原则尽量稳定；路径、API、权限和交互方式由具体运行时适配。
九、怎样评价一个 Skill：不要只看它有没有 SKILL.md
生产级评估至少需要覆盖路由、成本、质量和恢复四个维度。
9.1 路由指标
- Precision：被激活的任务中，有多少真的需要该 Skill；
- Recall：应该使用该 Skill 的任务中，有多少成功触发；
- 冲突率：多个 Skills 同时匹配时，是否选择了正确主流程；
- 错序率：依赖 Skill 是否在前置验收之前被调用。
9.2 上下文指标
- 启动元数据成本；
- 激活后的主指令 tokens；
- 每次任务实际读取的参考资源比例；
- 相比无 Skill 基线，额外 tokens 与延迟是多少。
9.3 交付质量指标
- 端到端任务成功率；
- 首次通过率与重试次数；
- 独立验证发现的缺陷数；
- 结果身份、格式、链接和外部状态是否一致。
9.4 恢复指标
- 中断后能否从结构化状态续跑；
- 失败是否污染原始文件或远端对象；
- 是否能在同一对象上修复，避免重复创建；
- 日志是否足够定位到路由、执行或验收阶段。
最简单的评测方式，是为同一组任务建立无 Skill、仅指令 Skill、指令加脚本、指令加脚本加验收四组基线。只要没有对照实验，就很难判断改进来自 Skill 设计、模型能力变化，还是任务本身更简单。
Rocky 认为，一个 Skill 的工程价值可以粗略表示为：
V skill = Δ 任务成功率 × 可复用次数 × 可审计性 上下文成本 + 维护成本 + 执行风险 V_{\text{skill}}=\frac{\Delta\text{任务成功率}\times\text{可复用次数}\times\text{可审计性}}{\text{上下文成本}+\text{维护成本}+\text{执行风险}} Vskill=上下文成本+维护成本+执行风险Δ任务成功率×可复用次数×可审计性
这不是可直接计费的精确公式，但它提供了正确的评价方向：不是文件越长、脚本越多、流程越重越好，而是能否用合理成本持续提高可靠交付。
十、从个人经验到组织资产：Skills 的跨周期价值
过去，很多工程经验只存在于资深成员的脑子里：遇到某类错误先查哪里，哪个字段会被平台静默归一化，什么结果看似成功其实没有落地，哪些危险操作必须先做只读检查。
文档只能记录这些知识，传统自动化只能覆盖预先枚举的路径。Skills 的机会，是在二者之间建立一层新的接口：用自然语言保留判断，用脚本固化确定性动作，用渐进式披露控制上下文，用验收合同约束完成状态。
但要警惕另一种夸大：文本可以模仿一个人的表达方式，也可以沉淀一部分工作习惯，却不能等价保存一个人的完整判断、关系经验和价值选择。Skill 能编码的是可观察、可描述、可执行的行为片段，不是人的全部。
这条边界反而让技术价值更清晰。我们不需要把人"炼成"文件；真正值得做的，是把高频、稳定、可验证的程序性经验提炼出来，让团队不必反复支付同样的试错成本。
结语：文件夹只是壳，运行时闭环才是本体
Agent Skills 的表层形态非常朴素：一个目录、一份 Markdown、若干脚本与资源。正因为格式简单，它才容易被不同工具采用，也容易进入版本控制和团队协作。
但简单格式不等于简单系统。一个真正可用的 Skill，背后至少要完成五件事：
发现 → 路由 → 加载 → 执行 → 验证 \text{发现}\rightarrow\text{路由}\rightarrow\text{加载}\rightarrow\text{执行}\rightarrow\text{验证} 发现→路由→加载→执行→验证
渐进式披露解决的是"何时为哪部分知识支付上下文成本"；脚本解决的是"如何稳定执行重复动作"；验收契约解决的是"怎样证明结果真的落地"；权限、版本和恢复机制则决定它能否进入生产环境。
所以，Agent Skills 的真正分水岭，不是会不会写 SKILL.md，而是能否把经验变成一套可调度、可执行、可验证、可维护的运行时能力。
工具会变化，宿主会变化，模型也会变化。能够跨周期积累的，不是某一版提示词，而是对任务边界、失败模式和完成证据的持续抽象。
推荐阅读
Rocky一直在运营技术交流群（WeThinkIn-技术交流群），这个群的初心主要聚焦于技术话题的讨论与学习，包括但不限于算法、开发、竞赛、科研以及工作求职等。群里有很多人工智能行业的大牛，欢迎大家入群一起学习交流～（请添加小助手微信Jarvis8866，拉你进群～）
1. 深入浅出完整解析AI Agent（AI智能体）的核心基础知识
2025年可以说是AI Agent全面落地应用的元年，因此Rocky在持续撰写对AI Agent的全维度解析文章：
深入浅出完整解析AI Agent（AI智能体）的核心基础知识
2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识
Rocky对扩散模型的本质原理与和核心基础知识进行了全面系统的深入浅出分析讲解，同时不断跟进补充扩散模型的最新技术发展，希望能给大家带来帮助：
深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识
3. 入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识
Rocky对AIGC时代"中场时刻"之后的主流AIGC创作大模型的核心基础知识进行了全面系统的深入浅出分析讲解，力求让大家通俗易懂理解AIGC时代的技术浪潮的本质价值：
入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识
4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识
Rocky对FLUX.1 Kontext和FLUX.1 Krea的核心基础知识作了全面系统的梳理与解析：
深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识
5. 深入浅出完整解析DeepSeek系列核心基础知识
Rocky对DeepSeek系列模型的核心基础知识作了全面系统的梳理与解析：
6. 深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识
Rocky对Stable Diffusion 3和FLUX.1的核心基础知识作了全面系统的梳理与解析：
深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识
7. 深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识
Rocky对Stable Diffusion XL的核心基础知识作了全面系统的梳理与解析：
深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识
8. 深入浅出完整解析Stable Diffusion（SD）核心基础知识
Rocky对Stable Diffusion 1.x-2.x系列模型的核心基础知识做了全面系统的梳理与解析：
深入浅出完整解析Stable Diffusion（SD）核心基础知识
9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识
Rocky对Stable Diffusion中最为关键的U-Net结构进行了深入浅出的全面解析，包括其在传统深度学习中的价值和在AIGC中的价值：
深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识
10. 深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识
对于AIGC时代中的"ResNet"------LoRA模型，Rocky进行了深入浅出的全面讲解：
深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识
11. 深入浅出完整解析ControlNet核心基础知识
AIGC图像创作开源社区已经形成以Stable Difffusion/FLUX为核心，ConrtolNet和LoRA作为首要AI辅助工具的变化万千的AIGC图像创作工作流。
ControlNet正是让AI图像创作社区无比繁荣的关键一环，它让AIGC图像创作过程更加的可控，更有助于广泛地将AIGC算法解决方案应用到各行各业中：
12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识
AI绘画和AI视频是两个互相促进、相互交融的领域，2024年无疑是AI视频领域的爆发之年，Rocky对AI视频领域核心的Sora、Seedance、Keling等大模型进行了全面系统的梳理与解析：
深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识
13. 深入浅出完整解析AIGC时代Transformer核心基础知识
在AIGC时代中，Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向，成为AI技术架构大一统与多模态整合的关键核心基座，大有一统"AI江湖"之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析：
深入浅出完整解析AIGC时代Transformer核心基础知识
14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识
AIGC创作框架正是AIGC算法工作流的运行载体，目前主流的AIGC创作框架有ComfyUI、Diffusers、Stable Diffusion WebUI等 。在传统深度学习时代，PyTorch、TensorFlow以及Caffe是传统深度学习模型的基础运行框架，到了AIGC时代，Rocky相信ComfyUI就是AIGC时代的"PyTorch"、Stable Diffusion WebUI就是AIGC时代的"TensorFlow"、Diffusers就是AIGC时代的"Caffe"：
深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识
15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识
在AIGC时代中，如何快速转身，入局AIGC产业？如何成为AIGC/LLM/AI Agent算法/开发工程师？如何在学校中系统性学习AIGC/LLM/AI Agent知识，斩获心仪的AIGC/LLM/AI Agent算法/开发offer？
Don't worry，Rocky为大家总结整理了全面的AIGC/LLM/AI Agent算法/开发工程师成长秘籍，为大家答疑解惑，希望能给大家带来帮助：
手把手教你成为AIGC/LLM/AI Agent算法/开发工程师，斩获AIGC/LLM/AI Agent算法/开发offer！
16. AIGC产业的深度思考与分析
2023年3月21日，微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示，自从1980年首次看到图形用户界面（graphical user interface）以来，以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。
Rocky也认为，AIGC及其生态，会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期，未来随着AIGC的全面落地和深度商用，会深刻改变我们的工作、生活、学习以及交流方式，各行各业都将被重新定义，过程会非常有趣。
那么，在此基础上，我们该如何更好的审视AIGC的未来？我们该如何更好地拥抱AIGC引领的革新？Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点，希望能帮助各位读者对AIGC有一个全面的了解：
深入浅出全面解析AIGC时代核心价值与发展趋势（2025年版）
17. AI算法工程师的独孤九剑秘籍
为了方便大家实习、校招以及社招的面试准备，同时帮助大家提升扩展技术基本面，Rocky将符合大厂和AI独角兽价值的算法高频面试知识点撰写总结成《三年面试五年模拟》之独孤九剑秘籍:
【三年面试五年模拟】AIGC时代的算法工程师的求职面试秘籍（持续更新中）
18. 深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识
GAN系列模型作为传统深度学习时代的最热门生成式Al模型，在AIGC时代继续繁荣，作为Stable Diffusion/FLUX系列大模型的"得力助手"，广泛活跃于AlGC图像创作的产品与工作流中：
深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识