Anthropic Engineering的官方博客更新了一篇名为：Harness design for long-running application development的文章。

在长达数月的探索中，工程师 Prithvi Rajasekaran 发现了 AI 自主开发的两大致命弱点：一是上下文焦虑——模型在长任务中会逐渐失去方向并过早收尾；二是自我评估失真——AI 对自己的作品总是过度自信，即使输出平庸也会给出好评。

他构建了一套生成器与评估器分离的多Agent框架，让 AI 学会了“自我批判”。更令人惊喜的是，这套方法不仅适用于有标准答案的编码任务，甚至能让 AI 在主观性极强的前端设计中展现出“博物馆级”的审美判断。这是Claude团队对Agent Harness的一次最佳实践分享。

TL; DR

Anthropic 工程师通过借鉴 GAN（生成对抗网络）的思想，设计了一套多代理框架来突破 Claude 在自主应用开发中的性能瓶颈。核心创新是生成器-评估器分离：将执行工作的代理与评判工作的代理分开，解决了 AI 自我评估过于宽容的问题。

在前端设计任务中，通过定义四个可量化标准（设计质量、原创性、工艺、功能性）并进行多轮迭代，成功让 Claude 产出了具有创造性飞跃的设计。在全栈开发中，采用规划器-生成器-评估器三代理架构，配合“冲刺合同”机制，实现了 6 小时自主构建完整应用。

随着模型能力提升（Opus 4.5→4.6），框架可以简化，但评估器在任务处于模型能力边界时仍然关键。

以下是全文翻译：

---

在过去的几个月里，我一直在研究两个相互关联的问题：让 Claude 生成高质量的前端设计，以及让它在无需人工干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计技能和长期运行编码代理框架方面的努力，在那里，我和同事们能够通过提示工程和框架设计将 Claude 的性能提升到远超基线水平——但两者最终都遇到了瓶颈。

为了突破这一瓶颈，我寻找了适用于两个截然不同领域的新颖 AI 工程方法，一个由主观品味定义，另一个由可验证的正确性和可用性定义。从生成对抗网络（GANs）中汲取灵感，我设计了一个包含生成器和评估器代理的多代理结构。构建一个能够可靠地——并且有品味地——对输出进行评分的评估器，意味着首先要开发一套标准，能够将“这个设计好吗？”这样的主观判断转化为具体的、可评分的术语。

然后，我将这些技术应用于长期运行的自主编码，并从我们早期的框架工作中继承了两个经验：将构建分解为可处理的块，以及使用结构化工件在会话之间传递上下文。最终的结果是一个三代理架构——规划器、生成器和评估器——在多小时的自主编码会话中生成了功能丰富的全栈应用程序。

为什么 navie 实现会失败

我们之前已经展示过，框架（Harness）设计对长期运行的代理编码的有效性有着重大影响。在早期的实验中，我们使用初始化 Agent 将产品规格（spec）分解为任务列表，以及一个编码 Agent，在传递工件（artifacts）以在会话之间传递上下文之前，逐个功能地实现任务。更广泛的开发者社区已经在类似的见解上达成共识，例如“Ralph Wiggum”方法使用钩子（hooks）或脚本让代理保持在持续迭代循环中。

但一些问题仍然存在。对于更复杂的任务，代理随着时间的推移仍然倾向于偏离轨道。在分解这个问题时，我们观察到 Agent 执行此类任务时的两种常见失败模式。

首先是模型在冗长的任务中往往会失去连贯性，因为上下文窗口被填满。一些模型还表现出“上下文焦虑“，即当它们接近自己认为的上下文限制时，会过早地开始收尾工作。上下文重置——完全清除上下文窗口并启动一个新的 Agent，结合携带前一个 Agent 状态和后续步骤的结构化交接——可以解决这两个问题。

这与压缩不同，在压缩中，对话的早期部分会被就地总结，以便同一个 Agent 可以在缩短的历史记录上继续工作。虽然压缩保持了连续性，但它不会给 Agent 一个干净的起点，这意味着上下文焦虑仍然可能持续存在。重置提供了一个干净的起点，代价是交接工件（artifacts）需要有足够的状态让下一个 Agent 能够顺利接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 表现出足够强烈的上下文焦虑，以至于仅靠压缩不足以实现强大的长任务性能，因此上下文重置成为框架设计的关键。这解决了核心问题，但为每次框架运行增加了编排复杂性、token 开销和延迟。

第二个问题是自我评估，我们之前没有解决过。当被要求评估自己生成的工作时，Agent 倾向于自信地赞扬这项工作——即使在人类观察者看来，质量明显平庸。这个问题在设计等主观任务中尤为突出，因为没有类似于可验证软件测试的二元检查。布局是否感觉精致或通用是一个判断性的问题，而 Agent 在评价自己的工作时可靠地倾向于积极。

然而，即使在确实有可验证结果的任务上，Agent 有时仍然表现出糟糕的判断力，这会妨碍它们在完成任务时的表现。将执行工作的 Agent 与判断工作的 Agent 分离，被证明是解决这个问题的有力杠杆。这种分离本身并不能立即消除那种宽容；评估器仍然是一个倾向于对 LLM 生成的输出宽容的 LLM。但事实证明，调整一个独立的评估器使其持怀疑态度，要比让生成器批判自己的工作容易得多，而一旦存在外部反馈，生成器就有了具体的迭代目标。

前端设计：使主观质量可评分

我首先在前端设计上进行实验，这是自我评估问题最明显的地方。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局，这些布局在技术上是功能性的，但在视觉上并不出色。

两个见解塑造了我为前端设计构建的框架。首先，虽然美学不能完全简化为分数——个人品味总是会有所不同——但可以通过编码设计原则和偏好的评分标准来改进它们。“这个设计漂亮吗？”很难一致地回答，但“这是否遵循我们的良好设计原则？“给了 Claude 一些具体的评分依据。其次，通过将前端生成与前端评分分离，我们可以创建一个反馈循环，推动生成器产生更强的输出。

考虑到这一点，我编写了四个评分标准，并在提示中将它们提供给生成器和评估器代理：

• 设计质量： 设计是否感觉像一个连贯的整体，而不是部分的集合？这方面的强大工作意味着颜色、排版、布局、图像和其他细节结合起来创造了一种独特的氛围和身份。
• 原创性： 是否有自定义决策的证据，还是这只是模板布局、库默认值和 AI 生成的模式？人类设计师应该能够识别出深思熟虑的创意选择。未修改的库存组件——或 AI 生成的明显标志，如白色卡片上的紫色渐变——在这里会失败。
• 工艺： 技术执行：排版层次结构、间距一致性、色彩和谐、对比度。这是能力检查而不是创造力检查。大多数合理的实现默认情况下在这里都做得很好；失败意味着基础被破坏。
• 功能性： 独立于美学的可用性。用户能否理解界面的功能，找到主要操作，并在不猜测的情况下完成任务？

我强调设计质量和原创性超过工艺和功能性。Claude 在工艺和功能性方面默认已经得分很高，因为所需的技术能力往往对模型来说是自然而然的。但在设计和原创性方面，Claude 经常产生充其量是平淡的输出。这些标准明确惩罚高度通用的“AI 垃圾”(“AI slop“）模式，通过更重视设计和原创性，它推动模型承担更多的美学风险。

我使用少样本示例和详细的分数分解来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了迭代之间的分数漂移。

我在 Claude Agent SDK 上构建了循环，这使得编排变得简单明了。生成器代理首先根据用户提示创建 HTML/CSS/JS 前端。我给评估器提供了 Playwright MCP，这让它在对每个标准进行评分和撰写详细评论之前，可以直接与实时页面交互。在实践中，评估器会自行浏览页面，在生成评估之前截图并仔细研究实现。该反馈作为下一次迭代的输入流回生成器。我每次生成运行 5 到 15 次迭代，每次迭代通常会随着生成器对评估器的批评做出响应而将其推向更独特的方向。因为评估器是主动浏览页面而不是对静态截图进行评分，所以每个周期都需要实际的时钟时间。完整的运行延长到四个小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好，则改进当前方向，或者如果方法不起作用，则转向完全不同的美学。

在各次运行中，评估器的评估在达到平台期之前在迭代中有所改善，仍有改进空间。一些生成是渐进式改进的。其他的则在迭代之间采取了急剧的美学转变。

标准的措辞以我没有完全预料到的方式引导了生成器。包含诸如“最好的设计是博物馆级别的”这样的短语将设计推向特定的视觉趋同，表明与标准相关的提示直接塑造了输出的特征。

虽然分数通常在迭代中有所改善，但模式并不总是清晰的线性。后期实现作为整体往往更好，但我经常看到我更喜欢中间迭代而不是最后一个的情况。实现复杂性也倾向于在各轮中增加，生成器响应评估器的反馈而寻求更雄心勃勃的解决方案。即使在第一次迭代中，输出也明显优于根本没有提示的基线，这表明标准和相关语言本身在任何评估器反馈导致进一步改进之前就将模型引导离开了通用默认值。

在一个值得注意的例子中，我提示模型为一家荷兰艺术博物馆创建一个网站。到第九次迭代时，它为一个虚构的博物馆制作了一个干净的深色主题登陆页面。该页面在视觉上很精致，但基本上符合我的期望。然后，在第十个周期，它完全放弃了这种方法，将网站重新构想为一种空间体验：一个用 CSS 透视渲染的带有棋盘地板的 3D 房间，艺术品以自由形式的位置挂在墙上，以及基于门道的画廊房间之间的导航，而不是滚动或点击。这是我以前从单次生成中从未见过的那种创造性飞跃。

扩展到全栈编码

有了这些发现，我将这种受 GAN 启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期，其中代码审查和 QA 与设计评估器具有相同的结构性作用。

架构

在我们早期的长期运行框架（long-running harness）中，我们通过初始化 Agent、一次处理一个功能的 Coding Agent 以及会话之间的上下文重置，解决了连贯的多会话编码问题。上下文重置是一个关键的突破：该框架使用 Sonnet 4.5，它表现出前面提到的“上下文焦虑”倾向。创建一个在上下文重置之间运行良好的框架是保持模型专注于任务的关键。Opus 4.5 在很大程度上自行消除了这种行为，因此我能够完全从这个框架中删除上下文重置。代理作为一个连续会话在整个构建过程中运行，Claude Agent SDK 的自动压缩沿途处理上下文增长。

对于这项工作，我在原始框架的基础上构建了一个三代理系统，每个代理都解决了我在之前运行中观察到的特定差距。该系统包含以下代理角色：

规划器： 我们之前的长期运行框架要求用户预先提供详细的规格。我想自动化该步骤，所以我创建了一个规划器 Agent，它接受一个简单的 1-4 句提示并将其扩展为完整的产品规格。我提示它对范围要有雄心，并专注于产品上下文和高级技术设计，而不是详细的技术实现。这种强调是因为担心如果规划器试图预先指定细粒度的技术细节并出错，规格中的错误会级联到下游实现。让 Agent 专注于要生成的可交付成果并让它们在工作时找出路径似乎更明智。我还要求规划器寻找将 AI 功能编织到产品规格（product specs）中的机会。

生成器： 早期框架中的一次一个功能的方法在范围管理方面效果很好。我在这里应用了类似的模型，指示生成器以迭代（sprint）的方式工作，从规格中一次挑选一个功能。每个迭代（sprint）使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）堆栈实现应用程序，生成器被指示在每个迭代（sprint）结束时自我评估其工作，然后再交给 QA。它还有 git 用于版本控制。

评估器： 早期框架的应用程序通常看起来令人印象深刻，但当你真正尝试使用它们时仍然存在真正的错误。为了捕获这些错误，评估器使用 Playwright MCP 像用户一样点击运行中的应用程序，测试 UI 功能、API 端点和数据库状态。然后，它根据发现的错误和一组标准对每个迭代（sprint）进行评分，这些标准以前端实验为模型，在这里适应涵盖产品深度、功能、视觉设计和代码质量。每个标准都有一个硬阈值，如果任何一个低于它，迭代（sprint）就会失败，生成器会得到关于出了什么问题的详细反馈。

在每个迭代（sprint）之前，生成器和评估器协商一个迭代（sprint）协议：在编写任何代码之前就该工作块的“完成”标准达成一致。这样做是因为产品规格（product specs）故意保持高层次，我想要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提议它将构建什么以及如何验证成功，评估器审查该提议以确保生成器正在构建正确的东西。两者迭代直到达成一致。

通信通过文件处理：一个 Agent 会写一个文件，另一个 Agent 会读取它并在该文件内或用前一个 Agen 将依次读取的新文件进行响应。然后，生成器根据商定的合同进行构建，然后再将工作交给 QA。这使工作忠实于规格（spec），而不会过早地过度指定实现。

运行这个框架（harness）

对于这个框架（harness）的第一个版本，我使用了 Claude Opus 4.5，针对完整框架和单代理系统运行用户提示进行比较。我使用 Opus 4.5，因为这是我开始这些实验时我们最好的编码模型。

我编写了以下提示来生成一个复古视频游戏制作器：

创建一个 2D 复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为和可玩测试模式。

下表显示了框架类型、运行时长和总成本。

框架的成本超过 20 倍，但输出质量的差异立即显现。

我期待一个界面，我可以在其中构建一个关卡及其组成部分（精灵、实体、瓷砖布局），然后点击播放来实际玩这个关卡。我首先打开单独运行的输出，初始应用程序似乎符合这些期望。

然而，当我点击时，问题开始出现。布局浪费空间，固定高度的面板使大部分视口空着。工作流程是僵化的。尝试填充关卡提示我首先创建精灵和实体，但 UI 中没有任何内容引导我进入该序列。更重要的是，实际的游戏是坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入研究代码发现，实体定义和游戏运行时之间的连接被破坏了，没有表面指示哪里出了问题。

在评估单独运行后，我将注意力转向框架（harness）运行。这次运行从相同的一句提示开始，但规划器步骤将该提示扩展为分布在十个迭代（sprint）中的 16 个功能规格。它远远超出了单独运行尝试的内容。除了核心编辑器和播放模式外，规格还要求精灵动画系统、行为模板、音效和音乐、AI 辅助精灵生成器和关卡设计器，以及带有可共享链接的游戏导出。我给了规划器访问我们的前端设计技能的权限，它阅读并使用它来为应用程序创建视觉设计语言作为规格的一部分。对于每个迭代（sprint），生成器和评估器协商一个协议，定义迭代（sprint）的具体实现细节，以及将被测试以验证完成的可测试行为。

应用程序立即显示出比单独运行更多的精致和流畅。画布使用了整个视口，面板的大小合理，界面具有与规格中的设计方向一致的一致视觉身份。我在单独运行中看到的一些笨拙确实仍然存在——工作流程仍然没有明确表示你应该在尝试填充关卡之前构建精灵和实体，我必须通过摸索来弄清楚这一点。这被解读为基础模型的产品直觉中的差距，而不是框架旨在解决的问题，尽管它确实暗示了一个地方，在框架内进行有针对性的迭代可以帮助进一步提高输出质量。

在编辑器中工作时，新运行相对于单独运行的优势变得更加明显。精灵编辑器更丰富、功能更全，具有更清晰的工具调色板、更好的颜色选择器和更可用的缩放控件。

因为我要求规划器将 AI 功能编织到其规格中，所以应用程序还配备了内置的 Claude 集成，让我可以通过提示生成游戏的不同部分。这大大加快了工作流程。

最大的区别在于播放模式。我实际上能够移动我的实体并玩游戏。物理有一些粗糙的边缘——我的角色跳到平台上但最终与它重叠，这在直觉上感觉不对——但核心功能起作用了，而单独运行没有做到这一点。在移动了一会儿后，我确实遇到了 AI 游戏关卡构建的一些限制。有一堵大墙我无法跳过，所以我被困住了。这表明框架可以处理一些常识性改进和边缘情况以进一步完善应用程序。

阅读日志，很明显评估器使实现与规格（spec）保持一致。每个迭代（sprint），它都会遍历迭代（sprint）合同的测试标准，并通过 Playwright 执行运行中的应用程序，针对任何偏离预期行为的内容提交错误。合同是细粒度的——仅迭代 3 就有 27 个涵盖关卡编辑器的标准——评估器的发现足够具体，可以在不进行额外调查的情况下采取行动。下表显示了我们的评估器识别的几个问题示例：

让评估器达到这个水平需要做一些工作。开箱即用，Claude 是一个糟糕的 QA Agent。在早期运行中，我看到它识别出问题，然后说服自己它们不是什么大问题并批准工作。它还倾向于表面测试，而不是探测边缘情况，因此更微妙的错误经常漏掉。调整循环是阅读评估器的日志，找到其判断与我的判断不同的示例，并更新 QA 提示以解决这些问题。在评估器以我认为合理的方式进行评分之前，需要几轮这样的开发循环。即便如此，框架（harness）输出显示了模型 QA 能力的局限性：小的布局问题，在某些地方感觉不直观的交互，以及评估器没有彻底执行的更深层嵌套功能中未发现的错误。显然还有更多的验证空间可以通过进一步调整来捕获。但与单独运行相比，应用程序的核心功能根本无法工作，提升是显而易见的。

迭代框架（harness）

第一组框架结果令人鼓舞，但它也很笨重、缓慢且昂贵。合乎逻辑的下一步是找到简化框架而不降低其性能的方法。这部分是常识，框架中的每个组件都编码了关于模型无法自行完成的假设，这些假设值得压力测试，既因为它们可能不正确，也因为随着模型的改进，它们可能很快就会过时。我们的博客文章构建有效的 Agent 将基本思想框定为“找到尽可能简单的解决方案，只在需要时增加复杂性“，这是一个对任何维护 Agent 框架的人来说都是一致的。

在我第一次尝试简化时，我大幅削减了框架并尝试了一些创造性的新想法，但我无法复制原始框架的性能。也很难判断框架设计的哪些部分实际上是承重的，以及以什么方式。基于这一经验，我转向了一种更有条理的方法，一次删除一个组件并审查它对最终结果的影响。

当我进行这些迭代周期时，我们还发布了 Opus 4.6，这为减少框架复杂性提供了进一步的动力。有充分的理由期待 4.6 需要比 4.5 更少的脚手架。从我们的发布博客：“[Opus 4.6] 规划更仔细，维持代理任务的时间更长，可以在更大的代码库中更可靠地运行，并具有更好的代码审查和调试技能来捕获自己的错误。”它还大大改进了长上下文检索。这些都是框架被构建来补充的能力。

删除迭代（sprint）构造

我首先完全删除了迭代（sprint）构造。迭代（sprint）结构有助于将工作分解为块，以便模型能够连贯地工作。鉴于 Opus 4.6 的改进，有充分的理由相信模型可以在没有这种分解的情况下也能很好地处理工作。

我保留了规划器和评估器，因为每个都继续增加明显的价值。没有规划器，生成器的范围不足：给定原始提示，它会在不首先指定其工作的情况下开始构建，并最终创建一个功能不如规划器丰富的应用程序。

删除迭代（sprint）构造后，我将评估器移至运行结束时的单次通过，而不是每个迭代（sprint）评分。由于模型的能力大大增强，它改变了评估器对某些运行的承重程度，其有用性取决于任务相对于模型可以可靠地自行完成的任务的位置。在 4.5 上，该边界很近：我们的构建处于生成器单独可以做好的边缘，评估器在整个构建过程中捕获了有意义的问题。在 4.6 上，模型的原始能力增加了，因此边界向外移动。过去需要评估器检查才能连贯实现的任务现在通常在生成器单独处理得很好的范围内，对于该边界内的任务，评估器成为不必要的开销。但对于仍然处于生成器能力边缘的构建部分，评估器继续提供真正的提升。

实际含义是评估器不是一个固定的是或否决定。当任务超出当前模型可靠单独完成的范围时，它值得付出代价。

除了结构简化之外，我还添加了提示以改进框架如何将 AI 功能构建到每个应用程序中，特别是让生成器构建一个适当的 agent，可以通过工具来驱动应用程序自己的功能。这需要真正的迭代，因为相关知识足够新，以至于 Claude 的训练数据对其覆盖很少。但经过足够的调整，生成器正在正确构建 agent。

更新框架的结果

为了测试更新的框架，我使用以下提示生成了一个数字音频工作站（DAW），这是一个用于作曲、录音和混音歌曲的音乐制作程序：

使用 Web Audio API 在浏览器中构建一个功能齐全的 DAW。

运行仍然很长且昂贵，大约 4 小时，token 成本为 124 美元。

大部分时间都花在了构建器上，它在没有 Opus 4.5 所需的迭代（sprint）分解的情况下连贯运行了两个多小时。

与之前的框架一样，规划器将一行提示（prompt）扩展为完整的规格（spec）。从日志中，我可以看到生成器模型在规划应用程序和 agent 设计、连接 agent 以及在交给 QA 之前测试它等方面都做得很好。

话虽如此，QA Agent 仍然捕获了真正的差距。在其第一轮反馈中，它指出：

这是一个强大的应用程序，具有出色的设计保真度、坚实的 AI agent 和良好的后端。主要失败点是功能完整性——虽然应用程序看起来令人印象深刻，AI 集成运行良好，但几个核心 DAW 功能只是显示而没有交互深度：剪辑无法在时间线上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有视觉效果编辑器（EQ 曲线、压缩器仪表）。这些不是边缘情况——它们是使 DAW 可用的核心交互，规格明确要求它们。

在其第二轮反馈中，它再次捕获了几个功能差距：

剩余差距：

• 音频录制仍然只是存根（按钮切换但没有麦克风捕获）
• 通过边缘拖动调整剪辑大小和剪辑分割未实现
• 效果可视化是数字滑块，而不是图形（没有 EQ 曲线）

生成器在自行处理时仍然容易遗漏细节或存根功能，QA 在捕获这些最后一英里问题以供生成器修复方面仍然增加了价值。

根据提示，我期待一个程序，我可以在其中创建旋律、和声和鼓模式，将它们编排成一首歌曲，并在此过程中从集成代理获得帮助。下面的视频显示了结果。

该应用程序远非专业的音乐制作程序，代理的歌曲创作技能显然还需要大量工作。此外，Claude 实际上听不到，这使得 QA 反馈循环在音乐品味方面不太有效。

但最终的应用程序具有功能性音乐制作程序的所有核心部分：在浏览器中运行的工作编排视图、混音器和传输。除此之外，我能够完全通过提示组合一个简短的歌曲片段：代理设置了节奏和调性，铺设了旋律，构建了鼓轨，调整了混音器电平，并添加了混响。歌曲创作的核心原语存在，代理可以自主驱动它们，使用工具从头到尾创建一个简单的制作。你可能会说它还不是完美的音调——但它正在接近。

接下来会发生什么

随着模型的不断改进，我们可以大致预期它们能够工作更长时间，处理更复杂的任务。在某些情况下，这意味着围绕模型的脚手架随着时间的推移变得不那么重要，开发人员可以等待下一个模型并看到某些问题自行解决。但另一方面，模型越好，开发框架（harness）以实现超出模型基线能力的复杂任务的空间就越大。

考虑到这一点，这项工作中值得继续的几个经验教训是，对你正在构建的产品进行实验，跟踪出现的问题，并做调整以实现你期望的结果，这始终是良好的实践。在处理更复杂的任务时，有时可以通过分解任务并将专门的 agent 应用于问题的每个方面来获得改进空间。当新模型发布时，重新检查框架（harness）通常是良好的实践，剥离不再对性能承重的部分，并添加新部分以实现以前可能无法实现的更大能力。

从这项工作中，我获得的信念是随着模型的改进，有趣的框架（harness）组合空间不会缩小。相反，AI 工程师的有趣工作是继续寻找下一个新颖的组合。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】