深入解析GPT-6 Astra提示词工程：从Skills、AGENTS.md到可验证的Agent交付

写在前面

欢迎大家关注Rocky的知乎：Rocky Ding

《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源：【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book，欢迎大家Star～

Rocky最新撰写的10万字AI Agent（AI智能体）深入浅出全维度解析文章： 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

大家好，我是Rocky。

核心导读：模型升级，也要升级对模型的管理方式

一个编码Agent修复了核心函数，随后停下来询问："要继续运行测试吗？"另一个Agent只修改了文档中的一个词，却先通读架构说明、扫描整个仓库，再启动耗时数十分钟的全量检查。这两种现象看起来相反，却可能来自同一个问题：系统中的指令已经跟不上模型的行为变化。

过去，开发者会为模型的每次失败补上一条规则。忘记测试，就强调必须测试；修改范围失控，就要求只能编辑被点名的文件；没有理解架构，就规定任何任务都先读完整套文档。这些做法在当时有明确价值，让不稳定的能力变得更可控。随着模型、工具和运行环境持续变化，其中一些规则仍然保护着系统，另一些却开始制造额外工作，甚至把模型引向错误的停止位置。

OpenAI 的《Rethinking skills and prompts for GPT-6 Astra》将这个问题落到了 Skills、AGENTS.md、决策边界和持续执行上。 $1$ Anthropic 的 Claude Fable 5.1 指南也讨论了提前结束、重复询问已授权操作，以及执行范围过度扩张等现象。 $4$ 两者共同说明，Agent 的有效能力取决于模型与指令系统之间的配合。

Rocky认为，提示词工程正在进入一个需要管理"指令生命周期"的阶段：每条长期规则都应当有适用条件、保护对象、验证方式，以及重新评估它的时机。 精简是可能的手段，可验证的交付才是目标。

这篇文章沿着一条主线展开：先理解指令如何影响执行，再把 Skills、仓库规范和完成标准放到各自合适的位置，最后用对照实验判断这些变化是否真正改善了结果。以下公式用于组织工程分析，不是对厂商训练机制的描述，也不是已经得到实验验证的性能定律。

1. 先厘清证据：工程指南能够证明什么

OpenAI 的这篇官方文章给出了几项具体观察：Skills 描述过长或数量过多时，Codex 会压缩描述；触发范围宽泛的技能容易被错误加载；无条件要求读取一组文档会消耗上下文；GPT-6 Astra 通常会主动验证工作，而过强的重复测试要求可能带来冗余检查；一些约束又会让模型在首版实现后过早停止。 $1$

这些是有明确对象和使用语境的工程指导。文章没有提供一套公开的受控实验，来量化删除多少规则可以降低多少延迟，也没有证明所有仓库都应减少测试。因此，"主动测试"不能写成质量保证，"更强的判断力"不能推导出不再需要运行时权限限制。

可核实的系统机制则更具体。Codex 的 Skills 文档解释了渐进式加载：首先提供名称和描述，在确定使用某个技能后再读取完整 SKILL.md。当前文档还说明，初始技能列表默认最多使用模型上下文窗口的 2%；窗口大小未知时使用 8,000 字符的预算。技能很多时，描述可能先被缩短，部分技能也可能从初始列表中省略并给出警告。skills.max_context_tokens 可以调整预算，文档注明上限为 10,000 tokens。 $2$

这里的 token 与字符是不同计量单位；2% 与 8,000 字符对应不同条件，不能相加，也不能把初始列表预算误认为单个技能正文的长度限制。技能被选中后，仍会读取完整正文。这种实现细节支持"描述必须清楚且聚焦"的建议，但无法单独证明"技能越少，效果必然越好"。

同样，AGENTS.md 的规则持续参与任务，并不意味着系统在每轮对话都重新扫描整个目录。当前官方文档说明，Codex 在一次运行开始时构建指令链，TUI 通常对应一次启动会话；发现过程结合全局位置、项目根到当前工作目录的层级，以及 AGENTS.override.md 等覆盖机制。合并文档还受到 project_doc_max_bytes 的限制，默认是 32 KiB。 $3$ 文件何时被发现、规则影响多长时间、工具是否重新读取文件，是三个不同的问题。

这些边界需要先说清楚，否则一篇提示词分析很容易从真实观察滑向万能结论。

2. 提示词在Agent里承担的是执行控制

普通问答里，一条指令主要影响回答内容。编码Agent的指令还会影响读哪些文件、选择哪个工具、修改多大范围、什么时候验证，以及何时返回结果。自然语言因此进入了执行控制链路。

可以把一次任务中的行为抽象为：

a t ∼ π θ ( ⋅ ∣ g , i , h t , o t ) . a_t \sim \pi_{\theta}(\cdot \mid g, i, h_t, o_t). at∼πθ(⋅∣g,i,ht,ot).

其中， g g g 是任务目标， i i i 是当前有效的指令， h t h_t ht 是此前的交互记录， o t o_t ot 是工具返回和环境观察， a t a_t at 是下一步行为。模型参数 θ \theta θ 发生变化后，同一组指令 i i i 可能产生不同的行动序列。这只是分析框架，不假设模型内部显式实现了这里的各个变量。

例如，"不要修改没有提到的文件"可以减少随意重构，但也可能阻止完成需求所必需的调用方适配。它保留了文件名边界，却没有表达用户真正关心的语义边界。相反，"修改范围限于完成这项行为所必需的代码和验证，接口保持兼容，不处理无关历史问题"更接近任务约束，但仍然需要工具权限来约束实际可执行操作。

能力、授权和验证必须分开。 模型有能力执行某个操作，不代表用户授权了它；用户授权某个任务，不代表执行环境已经允许访问相关系统；命令运行成功，也不代表用户要求的行为已经满足。

图中是本文提出的职责划分。AGENTS.md 保存项目层面的稳定事实与约定，Skills 承载特定工作流，当前任务描述目标与验收终点，沙箱和权限策略约束实际访问能力。这几层需要一致，不能指望在提示词中写一句"没有生产权限"就真的撤销生产凭据。

从维护角度看，一条指令至少应回答三个问题：它在什么情况下生效，防止什么错误，以及如何观察它的收益。如果这三个问题都说不清，却要求Agent每次执行，就应当进入审查清单。

3. Skills首先要解决"该不该用"，再解决"怎样用"

很多人把 Skill 当成知识包：文档越厚、流程越细，就越专业。但在加载正文之前，系统必须先决定是否使用它。技能描述实际上承担了一部分任务路由职责。

假设一个 Skill 用于 PostgreSQL 数据库结构迁移，它的描述却写成"所有涉及数据库、查询、模型和持久化的任务都使用本技能"。当任务只是调整一个查询字段时，这个描述也会产生很强的匹配信号。加载之后，迁移检查、回滚准备和发布步骤又可能继续推动执行，最终让一个局部修改变成不必要的迁移工作流。

OpenAI 给出的改进方向，是把触发范围收窄到新增或修改迁移，以及审查迁移的上线过程。 $1$ 描述应优先说明任务边界，而执行细节可以留到正文。

这张示例图展示的是触发条件的差异。它能够解释误触发是怎样发生的，不能证明更短的描述在所有任务上都有优势。若把描述缩成"数据库工具"，关键条件也会丢失。

进一步看，路由需要同时控制误触发与漏触发。误触发会加载无关流程，漏触发会跳过本来有价值的领域约束。可以用下面的加权目标组织评估：

L r o u t e = α F P R + β F N R + λ E $C l o a d$ . L_{\mathrm{route}}=\alpha\,\mathrm{FPR}+\beta\,\mathrm{FNR}+\lambda\,\mathbb{E} $C_{\\mathrm{load}}$ . Lroute=αFPR+βFNR+λE $Cload$ .

这里 FPR 表示本不该调用技能的任务被调用的比例，FNR 表示本该调用的任务未调用的比例， C l o a d C_{\mathrm{load}} Cload 是加载与执行额外流程的成本，三个权重由任务风险决定。这是一个设计用的评分思路，实际使用前应统一量纲或采用归一化指标。

处理数据库迁移、权限变更时，漏掉关键约束可能比多读一份文档严重得多；处理拼写修复时，无意义加载大型工作流则可能是主要浪费。因此，技能评估集不能只有正例，还应包含相邻但不适用的反例，例如"修改 SQL 查询输出列""解释 ORM 模型字段""新增表结构迁移""审查迁移回滚方案"。四类任务都与数据库有关，只有部分应该进入迁移工作流。

渐进式展开同样需要边界。一个复杂 Skill 的根文档可以给出选择路径，再指向专项参考资料和确定性脚本。共用的输出契约、不可遗漏的约束应当放在能够稳定发现的位置；低频操作细节则适合按需加载。如果关键检查藏在模型不会读取的子文档里，减少上下文的收益就可能被遗漏风险抵消。

还要区分确定性步骤与启发式步骤。提交数据库变更的顺序、签名请求的字段、资产校验规则，往往有明确的不变量，适合保留流程或落实到脚本。分析一个陌生模块应先读哪个文件，则可能更适合由任务线索驱动。模型能力增强后，最值得重新审查的是过去为了弥补理解能力不足而增加的僵硬步骤。

4. AGENTS.md要保存项目知识，并控制规则的作用域

仓库规范最有价值的内容，经常是模型无法从代码表面推断的事实：哪个命令才是该模块的测试入口，哪些生成文件不应直接编辑，哪些接口受兼容性要求约束，哪些目录属于历史迁移区。这些信息能够减少探索成本。

问题发生在"项目事实"被写成"所有任务的必经路线"。例如，架构说明对服务拆分很重要，数据库说明对 schema 变更很重要，部署说明对发布准备很重要。如果把三份文档变成每次修改前都必须完整阅读的内容，作用域就丢失了。

一种更可维护的方式，是把文档入口与触发条件放在一起：涉及服务边界时读取架构约束，涉及持久化结构时读取迁移约束，准备部署时读取发布约束。任务中一旦发现跨模块依赖，再扩大阅读范围。这样既承认模型能够沿调用关系寻找上下文，也保留项目中特有的约束信息。

这并不意味着只读最少文件。认证链路、共享基础库、构建系统和跨服务协议的改动，本来就可能需要广泛理解。合理的读取范围由影响范围决定，不能仅靠修改行数决定。 修改一行默认配置，有时比新增几十行独立函数影响更大。

可以在分析上把上下文预算写成一个会计恒等式：

B t o t a l = B r u l e s + B t a s k + B e v i d e n c e + B h i s t o r y + B r e s e r v e . B_{\mathrm{total}}=B_{\mathrm{rules}}+B_{\mathrm{task}}+B_{\mathrm{evidence}}+B_{\mathrm{history}}+B_{\mathrm{reserve}}. Btotal=Brules+Btask+Bevidence+Bhistory+Breserve.

它提醒我们，常驻规则、当前任务、相关证据、交互历史和预留空间会共同占用预算。不过，上下文长度不能直接替代延迟和账单：前缀缓存、工具等待、推理设置、并发策略都会影响实际成本。删除一段规则是否更快，应通过真实任务测量；删除规则是否更可靠，则要检查失败类型是否改变。

团队还应把规则的运行范围写清楚。项目根的约定适合整个仓库，服务目录的约定适合局部模块。官方文档中的发现和覆盖规则有具体实现条件，不能假定任何嵌套文件只要存在，就一定会被当前会话加载。 $3$ 对关键项目，检查实际加载的指令链，比猜测Agent"应该已经看见了"更可靠。

5. 测试策略需要明确的覆盖目标与停止条件

"模型会主动测试"是一种行为观察；"系统交付可靠"需要可检查的证据。把两者混在一起，就可能走向两个极端：要么所有改动都要求全量测试，要么因为模型更强而删除必要验证。

更合理的策略，是让检查对应具体风险。修复一个确定可复现的函数错误，可以先验证触发条件，再检查相关调用路径；修改共享接口或构建链路，通常需要扩大检查范围；涉及生产交付时，还要满足项目既定的发布门禁。模型可以帮助选择检查，但不能自行取消明确的验收要求。

一个测试的价值，可以用下面的简化视角理解：

V O I ( t ) = E $该检查带来的预期损失降低$ − C o s t ( t ) . \mathrm{VOI}(t)=\mathbb{E} $\\text{该检查带来的预期损失降低}$ -\mathrm{Cost}(t). VOI(t)=E $该检查带来的预期损失降低$ −Cost(t).

这是信息价值的工程解释，不是要求Agent精确预测每个测试的事故概率。它提示我们追问：运行这个检查会增加什么信息？失败以后能否采取行动？如果同一代码状态、同一环境和同一失败原因都没有变化，再跑一遍通常信息有限；如果问题具有随机性、外部依赖恢复了，或环境状态发生变化，重复运行则可能合理。

OpenAI 给出的授权示例涉及本地测试使用一次性夹具、没有生产访问，以及允许修复本次改动导致的问题并重跑受影响检查。 $1$ 这些条件之所以有用，是因为它们把操作对象、影响范围和后续权限说清楚了。团队采用前仍要确认环境确实满足这些条件。

下面是可供调整的仓库规则示例，具体命令应替换为项目自己的入口：

markdown 复制代码

修改后执行与受影响行为相匹配的检查，并满足仓库已有的必需门禁。
如果失败由本次改动引起，可以在已授权范围内修复，再重跑受影响检查。
如果确认是既有故障，记录复现方式和基线，不扩大为无关修复。
检查通过后，除非出现新改动、新失败或尚未覆盖的明确风险，不反复重跑。
本地测试的隔离条件以实际环境为准，不连接未获授权的生产系统。

这段示例保留了验证责任，也给出了收敛条件。它不要求模型为每次改动新建永久测试文件：已有测试、临时复现脚本、静态检查和界面验证各有用途。是否把新测试纳入仓库，还取决于行为风险和项目惯例。

6. Definition of Done把自主执行变成有限闭环

Agent写完首版代码就停下来，未必是推理能力不足。有时它是在认真执行另一条指令：实现后先等待审查，或者未经明确允许不得继续修改。若任务原本要求"运行、检查、修复并交付"，这些停止规则就和完成目标发生了冲突。

Definition of Done，简称 DoD，提供了另一种表达方式：描述完成时必须成立的条件。以修复订单导出为例，可以把终点写成"已复现的错误得到修复、导出字段保持兼容、相关检查通过、输出文件可读取、变更与验证记录齐全"。它不指定每一次文件读取和命令顺序，却限定了什么结果才有资格交付。

图中尤其需要区分三类失败：本次改动引入的缺陷应继续修复；与任务无关的既有问题应记录并判断是否阻塞；缺少权限或关键业务决定则可能需要暂停。没有这个区分，"持续推进"很容易被误解成无限扩展范围。

形式上，可以把完成判定表示为：

D o n e = ⋀ k = 1 m V k ( y , e ) . \mathrm{Done}=\bigwedge_{k=1}^{m}V_k(y,e). Done=k=1⋀mVk(y,e).

y y y 表示交付物， e e e 表示可检查证据， V k V_k Vk 表示一个验收条件。函数行为、接口兼容性、必需检查、产物可打开等条件都应有相应证据。对于审美、可读性或复杂业务正确性，验收中仍可能需要人工判断；并不是所有条件都能自动化。

一个可操作的任务描述可以是：

markdown 复制代码

目标：修复订单导出在空结果集时抛异常的问题，保持已有导出字段兼容。

可自行推进：定位相关代码，完成必要修改，使用已授权的本地测试环境，
修复本次修改造成的失败，并重跑受影响检查。

完成标准：空结果集产生合法导出文件；正常结果集行为不退化；
相关检查与仓库必需门禁通过；交付变更说明、验证证据和已知限制。

停止条件：需要访问生产数据、执行不可逆操作，或缺少会实质改变
交付结果的业务决定。请说明具体阻塞，同时完成不依赖该决定的工作。

这是一个示例契约，授权范围必须与用户意图和环境权限相符。"完成所有相关事情"过于含糊，"永远不要停止"缺少边界，"只能修改点名的文件"又可能把必要依赖排除在外。好的完成标准允许执行路径灵活变化，同时让范围和终点稳定。

Anthropic 对 Claude Fable 5.1 的指导也明确讨论了已授权工作中的重复确认，并提醒自主性增强可能降低模型对歧义请求的询问倾向，需要在自己的任务中评估这个权衡。 $4$ 这说明，自主推进与澄清机制需要一起设计。目标不是把确认次数压到零，而是让确认集中在真正需要人决策的位置。

7. 如何证明新指令更好：先做模型与提示词的交叉对照

如果团队同时更换模型、缩短提示词、升级工具并切换测试环境，随后任务完成速度变快，很难知道哪项变化起了作用。这种结果可以说明整个系统变了，却不能单独证明"精简提示词有效"。

一个基本方案是四组对照。A 组使用旧模型和旧指令；B 组只换新模型；C 组只换精简后的指令；D 组同时使用新模型和新指令。相同任务从相同仓库快照开始，工具、权限、外部依赖和预算条件尽量保持一致。下面是实验设计，本文没有运行该基准，也没有给出虚构的提效数字。

对新模型而言，最直接的指令比较是 D 与 B。若比较旧模型上的 C 与 A，还可以观察同一指令变化是否具有不同影响。设某项预先定义的结果指标为 Y Y Y，则交互差异可以写成：

Δ i n t e r a c t i o n = ( Y D − Y B ) − ( Y C − Y A ) . \Delta_{\mathrm{interaction}}=(Y_D-Y_B)-(Y_C-Y_A). Δinteraction=(YD−YB)−(YC−YA).

它衡量指令改动在两个模型上的效果差异。要把差异解释为因果作用，还需要控制分配方式、任务难度、环境状态和重复运行等因素，不能看到一个非零差值就直接下结论。不同模型的同名 effort 设置也未必对应相同推理量，Anthropic 文档明确提醒应重新测试这种权衡。 $4$

任务集至少应包含局部修复、跨模块改动、需要专项技能的任务、不该触发该技能的相邻任务，以及存在权限边界的任务。只测拼写修复，容易高估减少读取和测试的好处；只测复杂重构，又可能低估日常任务的冗余成本。

观察维度	建议记录什么	避免的误判
交付质量	所有验收条件通过率、独立检查结果	把测试命令退出码当成完整交付
范围控制	无关修改、未授权操作尝试、遗漏行为	把修改文件少等同于范围正确
技能路由	正例命中、相邻反例误触发、漏触发	只验证技能会被调用
人工介入	决策性澄清与重复确认分别计数	把所有询问都当成低效
执行成本	实际计费、工具调用、环境资源	直接用提示词字数估算账单
延迟与长尾	端到端时长、P50/P95、失败后重试	只报告成功任务的平均耗时

由于Agent执行具有随机性，最好对相同任务进行配对重复运行，并报告不确定性。运行顺序应随机化或交错安排，防止服务波动集中影响某一组；仓库和外部状态需要重置，避免先运行的Agent改变后续条件。若样本量有限，就如实给出任务级结果，不把少量成功案例包装成普遍结论。

初步确认收益后，还可以逐类消融：先收窄技能描述，再改变文档读取条件，随后调整验证策略，最后加入完成标准。这样更容易定位收益与回归。安全边界、发布门禁和必要业务约束应保持，不能为了让曲线好看而降低验收难度。

8. 长期维护：把指令债务纳入工程治理

团队积累的规则会形成一种"指令债务"：它们可能已经失去最初的保护作用，却仍在消耗上下文、触发流程或改变停止时机。它和代码债务一样，通常有合理的历史起点，也需要证据来决定怎样偿还。

一个实用做法，是为重要规则建立简短记录：适用目录、触发条件、要防止的失败、对应例子、维护者、验证任务以及最近一次检查结论。不是每一句写作偏好都需要复杂流程，但影响权限、交付和检查策略的规则应可追溯。模型或工具升级时，优先重新验证那些直接针对旧模型行为编写的补偿规则。

对不同模型共用的仓库，还应区分稳定约束与模型适配。接口兼容要求、生产操作边界、业务不变量适合共用；"多读一些""少测试几次""不要太早结束"等行为校准，更依赖模型和环境。可以通过经过评估的配置层管理差异，而不是把互相冲突的提醒长期堆进同一份公共文件。

从产品角度看，用户承担的不只是token费用，还有等待、重复确认、审查过量变更和接手半成品的成本。减少无效步骤只有在交付质量不退化时才有价值；让Agent执行更久，也只有在它持续推进验收条件时才有价值。能够稳定完成任务的系统，需要同时理解完成率、越界率、人工返工和长尾延迟。

对算法工程师，这要求把模型评测扩展到工具轨迹和环境交互；对Agent产品团队，需要把授权、进度和完成证据设计成清楚的产品行为；对创业团队，长期积累更可能来自真实任务分布、可靠执行环境和失败诊断能力。某份提示词是否精巧，可以很快被复制；哪些规则在自己的业务里有效，以及如何证明它们有效，需要持续的工程投入。

9. 还值得继续研究的三个问题

第一，技能路由能否显式校准不确定性？现在很多系统依赖描述完成隐式匹配。未来可以比较直接匹配、候选检索后判断、显式触发，以及"暂不使用技能"等策略，检查精度、召回与额外成本。目标是让任务与工作流之间的匹配可以诊断，而不是只看到最终答复的好坏。

第二，如何自动发现规则冲突？"完成全部验证再结束"与"首次实现后立即等待审查"可能同时存在。静态检查可以识别明显的重复和互斥要求，执行轨迹则能发现实际导致停顿的组合。但自然语言的条件和作用域复杂，自动删除规则会带来风险，更适合输出候选冲突、解释影响并通过回归任务验证。

第三，如何防止Agent只优化可见验收项？如果完成标准不完整，系统可能通过列出的检查，却遗漏用户真正关心的行为。可以结合固定验收、独立回归、抽样人工审查和失败案例补充，持续改进验证器。DoD 的质量本身也需要维护，不能把"有检查清单"当成终局。

这些方向尚不能用几段提示词解决，却很适合作为Agent工程研究的切入口。它们把语言指令、工具调度、软件验证与真实用户价值连接起来，也让提示词优化逐渐具备可比较的实验对象。

结语：让每一条规则对交付结果负责

GPT-6 Astra 相关指南的价值，在于提醒团队重新检查已经习以为常的执行规则。Skills 的触发条件决定是否进入正确工作流，AGENTS.md 的作用域决定哪些项目知识持续影响任务，完成标准决定何时可以交付，运行时权限决定实际可做什么。

Rocky认为，跨模型周期更值得积累的能力，是把目标说清楚、把边界落实到环境、把完成落实到证据，再用真实任务持续校准这套系统。 模型变强之后，某些细节可以交给它判断；需要人类承担的目标定义、风险选择和验收责任反而更加明确。

一次好的指令升级，应当让Agent更稳定地走到验收终点。有没有删掉很多字，并不是最重要的结果。

深入解析GPT-6 Astra提示词工程：从Skills、AGENTS.md到可验证的Agent交付

写在前面

核心导读：模型升级，也要升级对模型的管理方式

1. 先厘清证据：工程指南能够证明什么

2. 提示词在Agent里承担的是执行控制

3. Skills首先要解决"该不该用"，再解决"怎样用"

4. AGENTS.md要保存项目知识，并控制规则的作用域

5. 测试策略需要明确的覆盖目标与停止条件

6. Definition of Done把自主执行变成有限闭环

7. 如何证明新指令更好：先做模型与提示词的交叉对照

8. 长期维护：把指令债务纳入工程治理

9. 还值得继续研究的三个问题

结语：让每一条规则对交付结果负责

推荐阅读

1. 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

3. 入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识

4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

5. 深入浅出完整解析DeepSeek系列核心基础知识

6. 深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识

7. 深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识

8. 深入浅出完整解析Stable Diffusion（SD）核心基础知识

9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

10. 深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

11. 深入浅出完整解析ControlNet核心基础知识

12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

13. 深入浅出完整解析AIGC时代Transformer核心基础知识

14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

16. AIGC产业的深度思考与分析

17. AI算法工程师的独孤九剑秘籍

18. 深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识