企业官网建设流程全解析

写在前面

欢迎大家关注Rocky的知乎：Rocky Ding
AIGC算法工程师/开发工程师面试面经秘籍分享：WeThinkIn/Interview-for-Algorithm-Engineer欢迎大家Star～

AIGC时代的《三年面试五年模拟》AI算法工程师/开发工程师求职面试秘籍独家资源：【三年面试五年模拟】AI算法工程师面试秘籍

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

AIGC算法岗/开发岗面试面经交流社群（涵盖AI Agent、AIGC图像创作、AI视频、LLM大模型、AI多模态、数字人、传统深度学习、具身智能等AIGC面试干货资源）欢迎大家加入：https://t.zsxq.com/33pJ0

大家好，我是Rocky。

核心导读

这篇 Anthropic 工程博客真正值得讨论的，并不是它又列了一组 Agent 工作流模式，而是它把 2024 年以来 AI Agent 产业落地里最容易被忽略的一件事讲清楚了：有效的 Agent 系统，首先不是“让模型更自由”，而是把模型的自由放进一个可观测、可验证、可回滚的任务闭环里。

Rocky认为，这篇文章的价值在于它非常克制。它没有把 Agent 神化成“自主智能体即将替代一切”，也没有把框架包装成护城河，而是把 Agent 拆回到几个朴素的工程问题：什么时候只需要一次 LLM 调用？什么时候需要固定工作流？什么时候才值得让模型动态规划工具使用？工具接口应该如何设计，才能让模型少犯错？

这背后其实是 AI Agent 走向生产环境时的一个关键转向：上半场大家关心“模型能不能做事”，下半场真正重要的是“系统能不能稳定地把事做完”。模型能力是起点，任务边界、反馈信号、工具设计、评测体系和人工监督，才是 Agent 从 Demo 走向产品的工程地基。

问题背景：作者到底想解决什么

Agent 这个词在过去一年被用得太宽。有些人说 Agent，是指一个能长期自主运行、自己规划、自己调用工具的系统；有些人说 Agent，只是指几个提示词串起来、再加一点工具调用的自动化流程。Anthropic 在文章里先做了一个很重要的切分：把这一整类系统统称为 agentic systems，但在架构上区分 workflow 和 agent。

Workflow 是 LLM 和工具沿着预定义代码路径被编排。也就是说，系统知道大概要走哪些步骤，模型只是步骤里的智能处理单元。Agent 则不同，它让 LLM 动态决定自己的过程和工具使用方式，模型不只是执行节点，而是在一定边界内控制任务推进。

这个区分非常关键。因为很多团队做 Agent 失败，不是模型不够强，而是一开始就把“工作流问题”误判成“自主 Agent 问题”。如果任务路径本来清楚，硬要让模型自由规划，只会增加成本、延迟和不可控性；如果任务路径本来不可预测，却强行写死流程，系统又会在真实场景里失去弹性。

Anthropic 的中心建议很直接：先找最简单可行解，只有当复杂度能被实际效果证明时，才增加复杂度。很多应用甚至不需要 Agent，优化单次 LLM 调用，加上检索和上下文示例，已经足够。

这句话听起来保守，但它反而是 Agent 工程化最重要的现实主义。AI 产品真正难的部分往往发生在第一次演示成功之后，而不是 Demo 跑通当天。第一次能跑通只能说明模型有潜力，第十次、第一百次、在边界条件下还能稳定完成，才说明系统有产品价值。

核心思路：用一句主线串起来

这篇文章可以用一句话概括：从增强型 LLM 出发，用最少的抽象和最清晰的反馈，把任务逐级拆成 Prompt chaining、Routing、Parallelization、Orchestrator-workers、Evaluator-optimizer，最后才进入真正开放式 Agent。

这里的顺序不是简单的模式清单，而是一条复杂度阶梯。越往后，模型获得的自主权越大，系统能处理的不确定性越强，但成本、延迟、调试难度和错误累积风险也越高。

Rocky认为，这也是很多 Agent 团队需要补的一课：Agent 不是“框架越复杂越先进”，而是“任务不确定性越高，才越需要更强的动态决策能力”。架构复杂度应该来自问题本身，而不是来自对 Agent 概念的想象。

方法展开：沿着原文逻辑拆解

1. 增强型 LLM：Agent 系统的最小原子

Anthropic 把增强型 LLM 作为所有 agentic systems 的基础单元。所谓增强，不是简单把模型换成更大参数，而是让 LLM 接入 retrieval、tools、memory 等外部能力。模型可以自己生成搜索查询、选择合适工具、决定保留哪些信息。

这张图真正说明的是，现代 LLM 应用的基本单元已经不再是“prompt -> answer”这么简单，而是“模型 + 上下文 + 工具 + 记忆”的组合。模型负责语言理解、推理和决策，检索负责补充外部知识，工具负责改变外部状态，记忆负责跨轮次延续任务上下文。

但这里也有一个容易被忽略的细节：能力接入不是越多越好。工具越多，模型越需要理解每个工具的适用边界；记忆越复杂，越容易引入过期信息或错误状态；检索越开放，越需要判断来源质量。增强型 LLM 的核心不是堆能力，而是让模型能以低认知负担使用这些能力。

这也是 Model Context Protocol 这类协议出现的意义。它试图把工具与上下文接入标准化，让模型可以通过更清晰的接口访问外部世界。Rocky认为，从产业角度看，MCP 这类协议的长期价值不只是“接更多工具”，而是把 Agent 的外部行动能力变成可复用基础设施。

2. Prompt chaining：把大问题拆成更容易被模型做对的小问题

Prompt chaining 是最朴素也最常用的 workflow：把任务拆成一串步骤，每一步 LLM 处理上一步的输出，中间可以加程序化检查，确保过程没有跑偏。

这个模式的本质，是用延迟换准确率。一个复杂任务直接交给模型，模型需要同时完成理解、规划、生成、检查等多个动作，注意力会被拉得很散。把它拆成多个清晰步骤后，每次调用只处理一个更窄的问题，系统也能在中间节点加 gate 做质量控制。

原文给的例子包括：先生成营销文案，再翻译成另一种语言；先写文档大纲，检查大纲是否符合要求，再基于大纲写正文。这些例子都符合一个共同特征：任务可以被干净拆分成固定子任务。

Rocky在实际使用 LLM 做内容、代码和资料整理时也有类似体感。很多人觉得模型“不稳定”，其实是把太多目标塞进一次调用里：既要它查资料，又要它判断价值，还要它写成公众号风格，还要它生成标题和摘要。更稳的方式往往不是换一个更玄的 Agent 框架，而是把任务拆开：先收集，后判断，再组织，最后润色。

Prompt chaining 的边界也很清楚：如果任务路径固定，它很好用；如果任务下一步取决于输入本身、外部结果或动态环境，它就会变得僵硬。也就是说，它适合“可拆解”，但不适合“不可预知”。

3. Routing：不要让一个提示词同时讨好所有场景

Routing 的思路是先分类输入，再把不同类型输入送到不同后续流程、提示词或工具链里。它解决的是 LLM 产品里一个非常现实的问题：如果用一个通用提示词处理所有请求，优化某一类输入时，很可能伤害另一类输入。

客户服务是最典型的例子。普通咨询、退款请求、技术支持、投诉升级，表面上都叫“客服问题”，但所需信息、风险级别、工具权限和回复风格完全不同。如果全部塞给同一个 Agent，系统很容易在低风险问题上过度谨慎，在高风险问题上又不够严格。

Routing 的价值在于 separation of concerns，也就是把不同问题分给不同专家路径处理。它可以是 LLM 分类，也可以是传统分类模型或规则。关键不是分类技术本身，而是类别边界必须足够稳定，分类结果必须足够可靠。

这里还有一个很重要的成本视角。原文提到，可以把简单常见问题路由给更便宜的小模型，把困难异常问题路由给更强模型。这是 Agent 产品化必须面对的经济问题：如果每一个请求都调用最强模型、多轮工具链和复杂 Agent，单次体验可能很好，但商业闭环未必成立。

Rocky认为，很多 AI 应用最终拼的不是“能不能调用最强模型”，而是“能不能把强模型用在真正需要它的地方”。Routing 本质上是把模型能力变成资源调度问题。

4. Parallelization：并行不是为了炫技，而是为了速度和置信度

Parallelization 让多个 LLM 调用同时处理任务，再由程序聚合结果。Anthropic 把它分成两类：Sectioning 和 Voting。前者把任务拆成独立子任务并行运行，后者让多个模型调用从不同角度尝试同一任务，提升结果置信度。

Sectioning 适合那些天然可以拆开的任务。例如一个模型生成主回复，另一个模型同时做安全审查；或者自动评测时，让不同模型调用分别评价准确性、完整性、风格一致性和风险。这样比让一个模型在同一次调用里兼顾所有目标更稳，因为每个调用的注意力更聚焦。

Voting 则适合高风险判断。例如代码漏洞审查，可以让多个提示词从不同漏洞类型切入；内容安全审核，可以让多个判断维度分别给出结论，再用阈值控制误杀和漏判。

这类模式的本质不是“多跑几次就更智能”，而是用系统结构弥补单次模型输出的不确定性。LLM 输出天然带有概率性，尤其在模糊、开放、高风险任务里，一次输出往往不该被直接当成最终事实。并行调用加聚合，可以把模型的不稳定性转化成可管理的统计信号。

但 Parallelization 也不是免费午餐。它会增加调用成本，也会引入结果聚合问题。不同模型意见冲突时，谁来裁决？多维度评估之间如何加权？这些都需要具体业务定义。没有清晰评价标准的并行，只会生成更多看似丰富、实则难以决策的文本。

5. Orchestrator-workers：当子任务无法预先写死时，让模型来拆任务

Orchestrator-workers 比普通并行更进一步。它不是提前写好所有子任务，而是让一个中心 LLM 根据输入动态拆解任务，再把子任务分派给多个 worker LLM，最后综合结果。

这个模式特别适合代码修改和复杂搜索。比如一个 coding agent 接到任务后，可能需要改几个文件、每个文件改哪里、是否需要新增测试，这些都很难提前写死。搜索任务也类似，系统不知道哪些信息源最相关，也不知道中间发现会不会改变后续搜索方向。

它和 Parallelization 长得很像，但关键差异在于：Parallelization 的子任务通常是预定义的，Orchestrator-workers 的子任务是动态生成的。也就是说，前者解决“可并行的固定任务”，后者解决“需要动态拆解的复杂任务”。

Rocky认为，这是 Agent 从 workflow 走向更高阶系统能力的一个临界点。因为从这里开始，模型不再只是执行步骤，而开始参与任务结构设计。它需要判断问题空间、拆分工作量、分配资源、综合结果。这个能力很强，但风险也变大：拆错任务会导致后续所有 worker 都在错误方向上努力。

所以 Orchestrator 的质量决定整个系统上限。它不只是一个“调度器”，更像一个项目经理。它要知道任务目标，也要知道哪些子任务可以独立推进，哪些子任务存在依赖关系，哪些结果需要回到主线重新评估。Agent 产品要做得好，不能只盯着模型生成能力，还要设计好这个调度层的反馈与约束。

6. Evaluator-optimizer：让模型在明确评价标准下自我迭代

Evaluator-optimizer 是一个生成器和一个评估器之间的闭环：一个 LLM 生成结果，另一个 LLM 根据标准给出反馈，生成器再修改，直到达到目标或触发停止条件。

这个模式真正有效有两个前提。第一，任务有明确评价标准；第二，人类给出的反馈确实能改进模型结果，而且模型也能生成类似质量的反馈。文学翻译、复杂搜索、长文润色、代码审查，都可能符合这个条件。

这里最值得注意的是“可评价性”。很多团队喜欢做自我反思、自我批判、多轮改写，但如果没有可验证标准，循环很容易变成语言上的自我安慰。模型会不断说“我改进了逻辑、增强了严谨性”，但实际结果未必更好。

Rocky认为，Evaluator-optimizer 的核心不是“让模型多想几轮”，而是把人类原本隐性的质量标准显性化。比如一篇技术文章，评价标准可以包括：是否有中心判断、是否区分事实和解释、是否解释机制、是否指出边界、是否有读者可执行的启发。如果这些标准不清楚，所谓 optimizer 只是让文本变长。

这个模式也解释了为什么 AI 写作、AI 编程和 AI 搜索正在从“单次生成”走向“生成-评估-修正”的工作流。未来真正有价值的 AI 产品，不只是给用户一个答案，而是能稳定穿过一个质量收敛过程。

7. Agents：当路径无法预设时，才进入真正自主循环

在 Anthropic 的定义里，Agent 是 LLM 根据环境反馈循环使用工具、推进任务、必要时请求人类帮助的系统。它从用户命令或交互开始，明确任务后进行规划和执行；执行过程中，通过工具结果、代码运行、环境状态等 ground truth 判断进展；遇到阻塞点时暂停，请求人类反馈；最后在任务完成或达到停止条件时结束。

这张图是整篇文章的核心。它提醒我们，Agent 的关键不是“自主”两个字，而是“环境反馈”。没有反馈，模型只是在想象中推进；有了反馈，系统才能判断自己是否真的改变了外部世界。

Coding agent 为什么相对容易落地？因为代码世界天然有反馈：测试能否通过，类型检查是否报错，文件是否修改成功，程序是否运行。客服 Agent 为什么也适合？因为工单是否解决、退款是否成功、用户是否确认，都可以成为闭环信号。

反过来，如果一个任务没有清晰成功标准，没有可靠环境反馈，没有合理工具权限，也没有人类监督 checkpoint，那么把它做成 Agent 反而危险。自主性会放大错误，长链路会累积偏差，工具权限会把语言错误变成真实世界错误。

Anthropic 明确提醒，Agent 适合开放式问题：步骤数量难以预测，固定路径无法硬编码，且你对模型的决策能力有一定信任。但它也带来更高成本和错误累积风险，因此需要沙盒测试和护栏。

Rocky认为，这里有一个很重要的产品判断：Agent 不是“越自主越高级”，而是“在可信环境里，把可验证任务规模化”。真正成熟的 Agent 产品，应该让模型在需要自由的地方自由，在需要控制的地方被约束。

8. 两个最有落地价值的场景：客服与编程

Anthropic 在附录里强调了两个实践场景：Customer support 和 Coding agents。它们看似差异很大，一个面向业务服务，一个面向软件开发，但底层逻辑相同：都有对话入口、外部工具、明确目标、反馈循环和人工监督。

客服场景里，Agent 可以通过工具访问客户数据、订单历史、知识库，并执行退款、更新工单等动作。更重要的是，客服问题的成功标准相对明确：用户定义的问题是否被解决。一些公司甚至采用按成功解决计费的商业模式，这说明 Agent 的价值可以和业务结果绑定。

编程场景里，Agent 的优势更明显。代码问题结构化，结果可以通过自动化测试验证，模型可以根据测试结果迭代修复。SWE-bench 这类任务之所以成为 Agent 能力评估的重要基准，也是因为它把“会写代码”进一步推进到“能根据真实 issue 修改多文件项目，并用测试反馈收敛”。

但 Anthropic 也没有把 coding agent 说成完全自动化。自动化测试可以验证功能，但人类 review 仍然重要，因为系统要求、架构一致性、长期可维护性，不一定能被单个测试集完全覆盖。

这也是 Rocky对 Agent 落地最核心的判断：Agent 最先改变的，不是所有工作，而是那些结果可验证、过程可反馈、工具可封装、人类可审查的工作。这类任务会率先被规模化；而那些目标模糊、评价主观、外部状态复杂且风险高的任务，会更长时间停留在人机协同阶段。

实验与证据：结果能支撑到什么程度

这篇文章不是一篇学术论文，没有给出系统 benchmark、消融实验或统一指标。它的证据主要来自 Anthropic 与多个行业客户合作构建 LLM agents 的工程经验，以及 Anthropic 自身在 coding agent、computer use 等系统中的实践。

因此我们不能把它当成“某个模式一定优于另一个模式”的严格实验证明。它更像是一份从生产经验中提炼出来的工程设计指南。它能支撑的结论是：在当前 LLM 能力和产品约束下，简单、可组合、可观测的系统更容易成功；复杂框架和高自主 Agent 只有在任务不确定性真正需要时才值得引入。

从证据强度看，它最可靠的部分是模式归纳和工程经验：这些模式确实覆盖了当前很多 Agent 产品的常见结构。它较弱的部分是缺少量化比较：比如不同模式在成本、延迟、准确率、故障率上的具体差异，文章没有展开。

但这并不削弱它的实践价值。恰恰相反，Agent 行业现在最缺的不是更多概念，而是更清晰的工程判断。很多团队的问题不是不知道有 prompt chaining、routing、parallelization，而是不知道什么时候该用，什么时候不该用，以及如何证明复杂度真的带来了收益。

这篇工作的边界与可复现性

这篇文章有几个边界需要特别说明。

第一，它主要讨论通用 Agent 工程模式，而不是某个具体框架的完整实现。读者可以从中获得架构判断，但不能直接得到一套可运行系统。

第二，它没有把安全、权限、审计、合规展开到企业级深度。对于客服、金融、医疗、法律、企业内部操作等场景，Agent 的工具权限和审计日志会成为核心问题。一个 Agent 能调用工具，不等于它应该拥有所有工具权限。

第三，它没有提供严格的成本模型。实际生产中，复杂 agentic systems 往往会显著增加 token 成本、工具调用成本、延迟成本和调试成本。什么时候值得多花这些成本，需要结合业务转化、人工节省、错误代价来算。

第四，它默认读者已经具备一定 LLM 工程能力。比如如何写提示词、如何设计评测集、如何记录中间状态、如何处理工具异常，这些都需要团队自己补齐。

因此，这篇文章最适合被当作 Agent 架构的“决策地图”，而不是“施工图纸”。它告诉你复杂度阶梯长什么样，但每一级怎么在自己的业务里落地，还要回到任务、数据、工具、评测和业务闭环。

如果继续研究/落地，应该关注什么

如果把这篇文章往后推进，Rocky认为有五个方向最值得关注。

第一，Agent 复杂度评估。团队需要建立一套判断标准：单次 LLM 调用、固定 workflow、动态 orchestrator、开放 Agent，到底应该选择哪一级？这个标准应该同时考虑任务不确定性、错误代价、反馈可得性、工具风险、成本预算和用户容忍度。

第二，Agent eval。传统模型评测只看答案对不对，但 Agent 评测要看过程是否可控、工具调用是否合理、错误恢复是否有效、最终任务是否真实完成。未来 Agent 产品的护城河，很大一部分会来自任务级评测集和运行日志分析。

第三，Tool / ACI 设计。Anthropic 在附录里提到，工具定义应该像 prompt 一样被认真工程化。好的工具接口要让模型容易用对，参数命名清晰，格式接近模型训练中常见的文本形态，避免让模型做大量格式开销。Rocky认为，未来会出现一种新的工程能力：不是 HCI，而是 ACI，也就是 Agent-computer interface 设计能力。

第四，权限和沙盒。Agent 一旦能操作外部系统，就必须有权限分层、沙盒验证、回滚机制和人工确认。特别是涉及资金、账户、生产环境、用户数据的场景，没有这些机制的 Agent 只能是演示，不该进生产。

第五，商业闭环。Agent 最有价值的地方不是“看起来像人”，而是能否把可衡量任务结果规模化。客服按成功解决计费、编程按 issue 修复和测试通过衡量，都是更健康的方向。真正能穿越周期的 Agent 产品，不会只卖“智能感”，而会卖可验证的结果。

术语与概念速查

拓展思考：值得继续扩展研究与思考的创新点

1. Agent 的护城河会从框架迁移到任务闭环

早期 Agent 项目喜欢比谁的框架复杂、节点多、链路长。但从 Anthropic 的经验看，真正有效的系统反而常常使用简单模式。Rocky认为，这意味着 Agent 创业和产品竞争的护城河不会长期停留在框架层。

框架会开源，模式会被复制，模型能力会被 API 化。真正难复制的是任务闭环：你是否理解用户真实工作流，是否知道哪些步骤可以自动化，哪些必须人类确认，哪些反馈能衡量任务完成，哪些工具权限可以安全开放。

工具不是护城河，判断才是护城河。Agent 时代尤其如此。

2. Agent 工程师会从 prompt writer 变成系统设计者

如果只是写几个提示词，Agent 很难稳定进生产。一个合格的 Agent 工程师，需要懂任务拆解、工具接口、评测体系、日志分析、权限控制、产品交互和业务指标。

这会改变 AI 岗位结构。过去很多人把 LLM 应用开发理解成 prompt engineering，但真正进入生产环境后，prompt 只是其中一环。更重要的是全链路交付能力：从问题定义到数据接入，从工具封装到异常处理，从模型选择到成本控制，从评测集到上线监控。

AI不会尊重一个人熬了多少年，只会放大一个人真正能创造多少价值。Agent 工程正在把这个趋势进一步放大。

3. “自主性”不是目标，“可控地完成任务”才是目标

很多关于 Agent 的讨论，把自主性当作终点。但 Anthropic 这篇文章提醒我们，自主性只是手段。Agent 不是为了看起来像一个独立员工，而是为了在某些任务中减少人工步骤、扩大执行规模、提升结果质量。

如果固定 workflow 能完成任务，就不需要 Agent；如果一次 LLM 调用能完成任务，就不需要 workflow；如果检索加示例能解决问题，就不需要多轮工具调用。

真正成熟的 AI 产品，往往不是把技术上限全部展示给用户，而是把刚好够用的复杂度隐藏在稳定体验后面。

4. ACI 会成为 Agent 产品的关键基础设施

Anthropic 在附录里讲了一个很细但很重要的例子：在 SWE-bench Agent 中，他们发现模型在使用相对路径工具时容易出错，于是把工具改成强制使用绝对路径，模型使用就稳定了。

这个例子很小，却非常本质。人类工程师可以理解相对路径、当前目录、上下文切换；模型在长链路执行中却可能因为一个路径状态判断错误导致任务失败。解决方案不是责怪模型“不够聪明”，而是设计更不容易出错的工具接口。

这就是 ACI 的价值。未来很多 Agent 系统的差距，不在模型 API 本身，而在工具是否为模型友好地设计。一个好的工具定义，本质上是在替模型减少无意义认知负担，让它把能力用在真正的任务推理上。

总结：Agent 不是更复杂的聊天机器人，而是可验证任务系统

读完 Anthropic 这篇文章，Rocky最大的感受是：Agent 行业正在从概念热闹走向工程克制。

有效 Agent 的核心不是堆框架、堆工具、堆自主循环，而是从任务本身出发，选择刚好够用的复杂度。能用单次调用解决，就不要硬上 workflow；能用固定 workflow 解决，就不要硬上 Agent；必须让模型动态规划时，就一定要给它清晰工具、环境反馈、停止条件、评测标准和人工监督。

Agent 的本质不是“模型像人一样行动”，而是“模型在可验证环境里完成任务”。

这句话可能没有“AI 员工全面来临”那么刺激，但它更接近产业真实。因为所有能穿越周期的技术，最后都要从惊艳回到可靠，从概念回到结果，从自由回到约束。

对开发者来说，真正该学习的不是某个 Agent 框架的语法，而是任务拆解和系统评测能力。对产品经理来说，真正该判断的不是能不能做 Agent，而是这个任务是否值得 Agent 化。对创业者和投资人来说，真正该看的不是 Demo 多像人，而是它有没有明确反馈闭环、可持续成本结构和真实客户结果。

工具红利会退潮，认知红利会上升。Agent 时代真正有价值的，依然是那些能把模型能力、工程系统、产品场景和商业闭环连在一起的人。

参考来源

• Anthropic Engineering, “Building effective agents”, published Dec 19, 2024.

推荐阅读

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

2025年可以说是AI Agent全面落地应用的元年，因此Rocky在持续撰写对AI Agent的全维度解析文章：深入浅出完整解析AI Agent（AI智能体）的核心基础知识

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

和Rocky一起学习探究扩散模型的本质原理与和核心基础知识，同时不断跟进扩散模型的最新发展。Rocky在本文中对扩散模型的本质做了全面系统的梳理与讲解：深入浅出完整解析扩散模型DDPM、DDIM、SDE、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

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

https://zhuanlan.zhihu.com/p/1975174691049189562

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

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

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

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

6、Sora等AI视频大模型的核心原理，核心基础知识，网络结构，经典应用场景，从0到1搭建使用AI视频大模型，从0到1训练自己的AI视频大模型，AI视频大模型性能测评，AI视频领域未来发展等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

Sora等AI视频大模型文章地址：深入浅出完整解析Sora、Wan2.1、AnimateDiff、CogVideoX等AI视频大模型核心基础知识

7、Stable Diffusion 3和FLUX.1核心原理，核心基础知识，网络结构，从0到1搭建使用Stable Diffusion 3和FLUX.1进行AI绘画，从0到1上手使用Stable Diffusion 3和FLUX.1训练自己的AI绘画模型，Stable Diffusion 3和FLUX.1性能优化等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

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

8、Stable Diffusion XL核心基础知识，网络结构，从0到1搭建使用Stable Diffusion XL进行AI绘画，从0到1上手使用Stable Diffusion XL训练自己的AI绘画模型，AI绘画领域的未来发展等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

Stable Diffusion XL文章地址：深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识

9、Stable Diffusion 1.x-2.x核心原理，核心基础知识，网络结构，经典应用场景，从0到1搭建使用Stable Diffusion进行AI绘画，从0到1上手使用Stable Diffusion训练自己的AI绘画模型，Stable Diffusion性能优化等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

Stable Diffusion文章地址：深入浅出完整解析Stable Diffusion（SD）核心基础知识

10、ControlNet核心基础知识，核心网络结构，从0到1使用ControlNet进行AI绘画，从0到1训练自己的ControlNet模型，从0到1上手构建ControlNet商业变现应用等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

ControlNet文章地址：深入浅出完整解析ControlNet核心基础知识

11、LoRA系列模型核心原理，核心基础知识，从0到1使用LoRA模型进行AI绘画，从0到1上手训练自己的LoRA模型，LoRA变体模型介绍，优质LoRA推荐等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

LoRA文章地址：深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

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

在AIGC时代中，Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向，成为AI技术架构大一统与多模态整合的关键核心基座，大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析：

Transformer文章地址：深入浅出完整解析AIGC时代Transformer核心基础知识

13、最全面的AIGC面经《手把手教你成为AIGC算法工程师，斩获AIGC算法offer！（2024年版）》文章正式发布！

码字不易，欢迎大家多多点赞：

AIGC面经文章地址：手把手教你成为AIGC算法工程师，斩获AIGC算法offer！

14、50万字大汇总《“三年面试五年模拟”之算法工程师的求职面试“独孤九剑”秘籍》文章正式发布！

码字不易，欢迎大家多多点赞：

算法工程师三年面试五年模拟文章地址：https://zhuanlan.zhihu.com/p/545374303

《三年面试五年模拟》github项目地址（希望大家能多多star）：https://github.com/WeThinkIn/Interview-for-Algorithm-Engineer

15、Stable Diffusion WebUI、ComfyUI、Fooocus三大主流AI绘画框架核心知识，从0到1搭建AI绘画框架，从0到1使用AI绘画框架的保姆级教程，深入浅出介绍AI绘画框架的各模块功能，深入浅出介绍AI绘画框架的高阶用法等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

AI绘画框架文章地址：深入浅出完整解析主流AI绘画框架（ComfyUI、Stable Diffusion WebUI、Fooocus）核心基础知识

16、GAN网络核心基础知识，网络架构，GAN经典变体模型，经典应用场景，GAN在AIGC时代的商业应用等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

GAN网络文章地址：https://zhuanlan.zhihu.com/p/663157306

17. AI算法工程师的《三年面试五年模拟》求职秘籍

AIGC时代的算法工程师的求职面试秘籍（持续更新中）

18. 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年版）