这是一份完整的 12 步路线图，贯穿真正决定一个 agent 能否跑通的七大支柱：context（上下文）、tools（工具）、memory（记忆）、loops（循环）、graphs（图）、harness、evals（评测）——每一步都配了一个 Claude 工作流作为实证。

前沿模型在 SWE-bench Verified 上的成绩，一年内从 30% 涨到了 80% 以上。Coding agent 确实在以肉眼可见、且可量化的方式变强。

但与此同时，只有 17% 的企业高管表示，自己公司已经在全面落地 AI agent。

Agent 之所以失败，是因为 context 膨胀失控，是因为循环永远收敛不了，是因为没人能衡量上周的改动到底有没有带来任何改善。Demo 在你自己的机器上能跑，生产环境完全是另一回事。

这份 12 步路线图，就是要带你跨过横亘在这两者之间的七大支柱——每个支柱都有自己的失效模式、自己的 Claude 工作流，也有自己那种如果你跳过它就会悄悄搞死你的 agent 的方式。

先换个角度看问题，后面的内容才能串起来。这七样东西不是七门独立的技能，而是同一门技能的七个切面。

• 烂的 context 会毁掉循环。
• 没有 evals 的循环，永远收敛不到任何你能信赖的结果上。
• 没有 evals 的图，放大的不是吞吐量，而是错误。
• 没有 harness 的记忆，会话一结束就蒸发了。
• 没有 context 管理的工具，会在干活开始之前就把窗口塞满。

也就是说，把它们拆开来孤立地学没有任何意义——但它们之间存在依赖顺序：先打地基，再谈执行，最后才是可靠性。这十二步就是这么排的。

1. Context —— 先看看实际加载了什么

---

Karpathy 的那个框架最值得记住：模型是 CPU，context window 是 RAM。Context engineering 的艺术，就在于往这块 RAM 里精确地填入下一步所需要的东西——不多不少。

有一个数字能颠覆你的认知：在 Claude Code 里，你还没敲下第一个字符，大约 7,850 个 token 就已经加载进去了——系统提示词、自动记忆、skill 描述、CLAUDE.md、环境信息、MCP 工具名。

而你真正写的 prompt 大概只有 45 个 token。所有人都在优化那 45 个，却从来没人去看一眼那 7,850 个。

/context 命令会按类别打印真实的 token 占用明细，告诉你加载了哪些 memory 文件，并标出哪次工具调用吃掉的 token 最多。

有两个数字值得盯紧：memory files（数值偏重说明 CLAUDE.md 写得太肥）和 free space（剩余空间）。搭配 /memory 一起用，可以看到当前生效的具体是哪些文件。

2. Context —— 先砍，再分层

---

Anthropic 在 Claude 5 这一代砍掉了 Claude Code 系统提示词 80% 以上的内容，在他们的 coding 评测上却没有测出任何性能损失。

大多数 context 并不是错的——它们是写给更弱模型的指导，如今只是在白白消耗 token，还逼着 Claude 在开工之前先自行调和一番自相矛盾。

两条规则能让"砍"这个动作变得安全：

• 按块删，而不是按行删——单独一句话落在你评测的噪声地板之下，什么也说明不了。

另外，把绝对规则改写成原则：不要写"永远不要写多行注释"，而要写"写出与周围代码风格一致的代码"——注释密度、命名、惯用写法都跟着周围代码走。

规则给的是一个固定答案，原则给的是 Claude 通过阅读你的 repo 自行找到正确答案的方法。

• 留下来的东西要组织成树状结构，而不是一坨长文。Anthropic 给出了一个硬性数字：项目级 CLAUDE.md 控制在 200 行以内，只保留 Claude 自己推断不出来的坑。

其他一切都应该变成 skill（描述在启动时加载，正文在被调用时才加载）或者路径作用域规则（只有读到匹配文件时才加载）。

`` # payments-api
Subscription billing and invoicing for the web app.

Gotchas

// Non-obvious. Claude cannot infer these by reading the repo.

• All shared types live in src/types.ts — one monolithic file.
• Money is integer cents, never a float.
• Webhook retries must stay idempotent — provider replays for 72h.
• db/legacy/ is frozen. Read it, never edit it.

Deeper guides

• Verification → .claude/skills/verify/
• Releases → .claude/skills/deploy/

// NOT here: directory tree, framework, test runner, language
// version. Claude reads those from the repo itself. ``

3. Tools 与 MCP —— agent 够得着什么

---

工具是 agent 触碰世界的方式，而工具的描述本身就是 context——这让这一节成了"agent 能做什么"与"agent 负担得起知道什么"之间的枢纽。

老一套的建议是拿示例来教模型用工具。

这个做法现在要反过来：在当前这代模型上，示例反而会把 Claude 限制在示例所描述的那个探索空间里。应该去设计富有表达力的参数。

一个 pending | in_progress | completed 的 status 枚举，不用任何示例就教会了模型整个生命周期——类型本身就是文档。

Anthropic 之所以能在 SWE-bench Verified 上做到业界最佳，部分原因是对工具描述做了精细打磨，而不是改模型。

而且按需获取胜过一股脑倾倒。Claude Code 只加载 MCP 工具的名称——大约 120 个 token——schema 则通过 tool search 按需拉取。

对工具描述应用检索机制、而不是全部加载，能把工具选择的准确率提升大约三倍。

这就让描述成了发现入口：要写清楚这个工具什么时候该用，而不只是它能干什么。一个 Claude 找不到的工具，等于你没发布。

`` @mcp.tool()
def find_stalled_shipments(hours: int = 24) -> list[dict]:
"""Shipments with no scan event in N hours.
Use when ops asks what is stuck, or before an escalation review."""
return query(STALLED_SQL, hours)

@mcp.tool()
def reroute(shipment_id: str, hub: str, reason: str) -> dict:
"""Reroute a shipment. Writes an audit row — compliance
requires a reason on every manual intervention."""
return post_with_audit(shipment_id, hub, reason)

“Use when…” is the discovery surface for tool search.

reason: str is required, so the audit trail cannot be skipped.

The type enforces what a paragraph of instructions would only ask for. ``

4. Memory —— 什么能活过这个窗口

---

每一个长任务最终都会超出单个窗口的容量。

在那个边界上会发生什么，是一个大多数人从未主动做过的设计决策——他们放任自动压缩去猜，然后纳闷为什么 agent 忘掉了自己一小时前刚说过的约束。

这里的机制很具体，值得背下来。项目根目录的 CLAUDE.md 和 auto memory 会从磁盘重新注入。

但路径作用域规则（paths: 限定的）和嵌套的 CLAUDE.md 文件存在于消息历史里——它们会被摘要掉，直到再次读到匹配文件时才会回来。

被调用过的 skill 正文会回来，但每个 skill 上限 5k、总量上限 25k，最旧的先被丢弃、从末尾截断——所以任何关键内容都应该放在 SKILL.md 的开头。

最可靠的办法其实是计算机领域最古老的那一招：写到文件里。

一个 plan 文件、一份进度日志、agent 边走边更新的笔记。它不占窗口也能持久存在，而且因为活在磁盘上，天然扛得住压缩。

也要有意识地压缩——/compact focus on the auth bug 可以只保留你指定的内容；/clear 则被严重低估了，当下一个任务不依赖前面二十条消息时，清掉就好。

5. Loops —— 什么时候停

---

Agent 循环就是：行动 → 观察 → 决策 → 重复。整个工程问题都藏在最后一步：它怎么知道自己干完了？

放任不管的话，模型会在两个方向上给出糟糕的回答——要么在半成品上宣布胜利，要么在三代之前就已经做完的事情上永远磨下去。

这两者都不是靠更好的 prompt 能解决的，因为它们都是结构性问题。停止条件必须放在模型判断之外的代码里。对有边界的工作，那是一个测试门禁或者 schema 校验。

对于规模未知的探索性工作，正在收敛的模式是 loop-until-dry（跑到枯竭为止）：持续运行，直到连续 K 轮都没有新发现。

有一个细节决定成败，几乎所有人第一次都会搞错：去重时，要和所有见过的东西比对，而不是只和已确认的结果比对。

否则被拒绝的发现每一轮都会重新冒出来，循环永远跑不干，你等于造了一台永远在付费重新发现同一批死胡同的机器。

`const seen = new Set(); const confirmed = []; let dry = 0;

while (dry < 2) { // stop after 2 empty rounds
const found = await runFinders();
const fresh = found.filter((b) => !seen.has(key(b)));

if (!fresh.length) { dry++; continue; }
dry = 0;
fresh.forEach((b) => seen.add(key(b)));
// ^ dedupe against SEEN, not against confirmed.
// Backwards, and this loop never terminates.

confirmed.push(…(await verify(fresh)));
}`

6. Loops —— 谁来验收答案

---

一个收敛的循环，收敛的仍然是模型自己相信的东西。解法是引入 verifier——一个处于模型自身判断之外的东西，它唯一的职责就是想方设法证伪这个结论。

如果它活下来了，就通过。如果活不下来，它永远到不了答案那里。

有三种模式值得掌握：

• 对抗式验证：对每一个发现，派生 N 个独立的怀疑者，提示词要求它们去反驳；只有多数怀疑者都驳不倒时，才保留这个发现。
• 多视角验证：给每个验证者一个不同的视角——正确性、安全性、可复现性——因为多样性捕捉到的失效模式，是 N 个相同的检查永远抓不到的。
• 评审团模式：从不同角度生成 N 个候选方案，用并行的评委打分，然后从胜出者出发做综合，同时嫁接亚军方案里的亮点。

`› For each finding, spawn three verifiers - correctness, security, reproducibility. Accept only what survives two of three.

● 6 findings → 18 verifier agents, running in parallel

✓ missing auth on /invoices/:id 3/3 — accepted ✓ race in webhook retry 2/3 — accepted

● “unsafe regex in validator” 0/3 — killed

● “N+1 query in dashboard” 1/3 — killed 2 of 6 findings were confident and wrong. The loop caught them, not your reviewer, and not your users.`

注意这指向了什么。Verifier 本质上就是一个内联运行的 eval——和第三层（可靠性层）是同一套纪律，只不过应用粒度从每次发布变成了每条结果。能搭出好的 verifier 的团队，会发现第 11 步轻松得多，因为他们早就写清楚了"好"到底意味着什么。

7. Graphs —— 什么能并行跑

---

大多数人把 agent 写成一条直线——第一步、第二步、第三步，每一步都礼貌地等上一步完成。然后他们发现，其中一半步骤根本不需要等。

节点是一个工作单元，边意味着"这个输出喂给那个输入"。如果两者之间没有数据流动，就不该有边——那等待就是纯粹的浪费。

最常用的形状是菱形：fan out 收集广度，用普通代码做 reduce，再用一个 agent 做综合。

Reduce 这一步值得强调，因为钱就是在这里漏掉的——拍平和去重用 flatMap 加一个 Set 就够了，不需要动用 agent。

边是免费的。把 agent 花在判断上，别花在管道上。

这里的上限真的很高。Claude Code 的动态工作流可以在单次运行中协调多达 1,000 个并行 subagent，而且编排本身不消耗任何模型 token，因为它是脚本，不是对话。

› Run a workflow to audit every route under src/routes/ for missing auth. One agent per route file, verify each finding before reporting. ● Claude wrote an orchestration script · launching… ✓ Scope 1/1 ✓ Fan- out 18/18 one agent per file ◯ Verify 11/18 3-vote skeptics per finding ○ Synthesize 0/1 your session stays responsive — the fleet runs in the background

正是这种架构，让一个团队在六天内把 Bun 运行时大约 960,000 行代码从 Zig 移植到了 Rust，测试套件仍有 99.8% 通过。

8. Graphs —— 图形的代价

---

拓扑不是装饰——它是你在延迟和开销上能握到的最大杠杆，而两个选择决定了大部分代价。

第一，parallel() 对比 pipeline()。parallel() 的 barrier 会让所有节点等最慢的那个跑完，才进入下一阶段。

pipeline() 则让每个条目独立流过所有阶段——条目 A 已经在第 3 阶段时，B 还可以停在第 1 阶段。

默认用 pipeline。只有当某个阶段确实需要一次性拿到所有前序结果时（比如跨集合去重），才动用 barrier。"感觉更整洁"不是理由；barrier 带来的延迟是真实的、可度量的、被浪费掉的时间。

第二，按节点分级用模型。每个 subagent 默认继承你会话所用的模型，除非脚本显式覆盖，所以一次大规模运行默认全程按最高档计费。

有边界的、重复性的节点——提取这个字段、给这张工单分类——应该放在更便宜的模型上；判断真正发生的 merge 节点，才留在高档模型上。

一百个便宜的 fan-out 节点喂给一个顶级模型做综合，成本只是同样任务平铺直跑的一小部分，最终质量却一样。

9. Harness —— 活过会话之死

---

Anthropic 对问题的描述再精准不过：一个长任务就是一个软件项目，由轮班工程师完成，而每一位新工程师到岗时，对上一班发生的事毫无记忆。

光靠压缩解决不了这个问题。即便是前沿模型，跨 context window 循环执行"构建一个 claude.ai 克隆"这样的任务，照样会失败——而且失败的方式是两种特定的、可复现的模式。

第一种，agent 试图一口气把整个应用做完，context 在实现过程中耗尽，给下一个会话留下一个半成品、无文档可查的功能，让下一个会话去逆向工程。

第二种，项目后期，agent 环顾四周，看到确实有了进展，于是宣布任务完成。

这两种问题都要在写任何代码之前解决，靠的是一个只跑一次的 initializer agent，负责搭好环境：一个能启动 dev server 的 init.sh、一份进度日志、一个初始 git commit，以及一份 JSON 格式的功能清单——claude.ai 克隆的那份清单有 200 多个条目，每一个都标记为 failing。

`` {
"category": "functional",
"description": "New chat button creates a fresh conversation",
"steps": [
"Navigate to main interface",
"Click the 'New Chat' button",
"Verify a new conversation is created",
"Check that chat area shows welcome state"
],
"passes": false
}

// 200+ of these, all starting false. Agents may ONLY flip passes.
// “It is unacceptable to remove or edit tests” — deliberately strong
// wording, because a model that CAN edit the spec WILL edit the spec. ``

有一个细节值得直接照搬：那份清单选了 JSON 而不是 Markdown，因为实测表明，模型不当地重写 JSON 的概率明显更低。

10. Harness —— 每个会话只做一个增量

---

环境搭好之后，每个 coding 会话都拿到一份契约：先搞清楚现状，只挑一个功能，像用户一样验证它，把 repo 留在干净状态。

"干净"就是真实团队里的那个意思——没有重大 bug，代码整洁，下一位工程师可以直接开工，不用替别人收拾烂摊子。

定位现状的仪式是机械化的，每次都能省 token：pwd、读进度文件、读 git log、读功能清单、跑 init.sh，然后在动手之前先测试基础功能还正常。

最后那个检查比听起来重要得多——没有它，一个在已经坏掉的应用上开新功能的 agent，只会把破损越挖越深。

说到标记完成：Claude 的惯性是改完代码、跑几个单元测试，就宣布搞定，从头到尾没验证过功能端到端是否真的通了。

[Assistant] Getting my bearings on the current state. [Tool] bash — pwd [Tool] read — claude-progress.txt [Tool] read — feature_list.json [Tool] bash — git log --oneline -20 [Tool] bash — ./init.sh start the dev server [Assistant] Verifying fundamentals before touching anything… ✓ core chat, theme switching, conversation loading all pass [Assistant] Picking the highest-priority failing feature. no guessing. no archaeology. the previous shift left notes.

给它真实的测试工具，并要求它像真实用户那样去验证——浏览器自动化，真实点击。

单是这一条要求，就在 Anthropic 的实验中带来了显著的性能提升，抓到了只看代码永远发现不了的 bug。

11. Evals —— 要数字，不要感觉

---

崩溃点永远是同一句话：用户反馈改动之后 agent 感觉变差了，而团队除了猜测加手动排查之外，没有任何验证手段。

没有 evals，调试就是被动的——等投诉、手动复现、修复、祈祷别的地方没跟着退化。你根本分不清真实的退化和噪声。

起步可以比你想象的小。团队拖延，是因为他们觉得需要几百个任务；其实从真实失败中提炼出 20–50 个就是很好的起点，因为早期改动的效应量本来就大。

从你已经在手动测试的东西里挖，从 bug tracker 里挖，从客服工单里挖。写任务时，要保证两位领域专家能独立得出相同结论——任务里的含糊，最终都会变成指标里的噪声。

还要构建平衡的测试集：既测某个行为应该触发的场景，也测它不应该触发的场景，否则你优化出来的会是一个对什么都去搜索的 agent。

有意识地组合三种评分器。

• 代码评分——快、便宜、客观；能用就尽量用。
• 模型评分——处理细微差别时用评分标准（rubric），并且要对照人类校准；理想情况下每个维度用一个独立的评委，而不是一个评委给所有维度打分。
• 人工评分——金标准，但要省着用，主要用来校准前两种。

而且只评 agent 产出的结果，不评它走的路径：检查是否严格执行了某个工具调用序列是脆弱的，因为 agent 经常找到你没预料到的有效路径。

`task:
id: "fix-auth-bypass_1"
desc: "Fix authentication bypass when password field is empty"
graders:
- type: deterministic_tests # fast, objective, reproducible
required: [test_empty_pw_rejected.py]
- type: llm_rubric # nuance tests can’t capture
rubric: prompts/code_quality.md
- type: static_analysis
commands: [ruff, mypy, bandit]
- type: state_check # the OUTCOME, not the claim
expect: { security_logs: { event_type: "auth_blocked" } }
tracked_metrics:
- type: transcript
metrics: [n_turns, n_toolcalls, n_total_tokens]

The agent says “fixed”. The state_check decides whether it was.

Grade outcomes, not announcements.`

12. Evals —— 让数字保持诚实

---

没人读的评测套件，就是一个不值得信任的数字。在读过足够多的试验记录之前，你不知道你的评分器到底好不好用——当一个任务失败时，记录会告诉你，是 agent 真的犯了错，还是你的评分器拒掉了一个正确的解法。

失败应该让人觉得公平：哪里错了、为什么错，一目了然。

有两个陷阱会让好的 agent 看起来很差。

• 多次试验通过率都是 0%，通常意味着任务本身是坏的，而不是 agent 不行。Opus 4.5 最初在 CORE-Bench 上只拿到 42%——后来一位研究者发现了僵化的评分逻辑（期待 “96.124991…” 却拒掉了 “96.12”）、含糊的规格说明，以及无法复现的任务。修完之后：95%。
• 另一个方向相反的陷阱是饱和——一个 100% 的评测只能追踪退化，却给不出可以攀登的山坡，真实的能力提升开始以噪声的形式出现。

然后把两个指标分清楚。pass@k 是 k 次尝试中至少成功一次的概率——它随 k 增大而上升。pass^k 是 k 次全部成功的概率——它随 k 增大而快速下降。单次成功率 75% 的情况下，三次全部通过的概率只有大约 42%。

一次成功就够用的场景用 pass@k；任何面向客户的场景用 pass^k，因为用户期待的是每次都行。

› Run the suite against the new model and compare to baseline. ● 47 tasks × 3 trials · 141 runs · parallel capability suite pass@1 61% → 74% +13 regression suite pass@1 99% → 99% held consistency pass^3 52% → 68% +16 ● 2 regressions: refund_partial, escalation_tone → transcripts written to ./eval-results/failures/ the upgrade decision took an afternoon, not three weeks

最后，把它变成例行公事。把评测套件接入 CI，每次改动、每次模型升级都跑一遍。

正是这件事，把新模型发布从"几周的手动测试"变成"跑一遍套件、读一下 diff"——这是一种复利优势，没有 evals 的团队永远追不上。

配 Claude 跑的 7 个实战任务——每个支柱一个

1. 打开那扇你从没看过的窗。先测量，再动手砍。memory files 数值偏重，说明 CLAUDE.md 写得太肥——一条命令就能诊断，一个下午就能修好。

› /context，然后 /doctor

2. 审计你的工具描述。每条描述都应该说清楚这个工具什么时候该用，而不只是它能干什么。那句话就是发现入口——没有它，接上了的工具 Claude 也永远不会去选。

› 审查这个 MCP server 里的每一条工具描述。给每条加一句"什么时候用"，并收紧参数类型。

3. 把状态搬到文件系统上。让 Claude 维护一个它边干活边改写的 plan 文件。它因为活在磁盘上而扛得住压缩——长任务也就不会再干到一半丢了线索。

› 开工之前，把计划写进 plan.md，每完成一步就更新一次。每次恢复工作时重新读一遍。

4. 给你的循环加上 verifier。随便挑一个由 Claude 自己宣布完成的任务。加一个外部检查，然后看看第一个答案有多大概率活不过三个怀疑者。

› 每次修复之后，派生三个验证者——正确性、安全性、可复现性。只接受三者中至少两个通过的结果。

5. 把一个线性任务改成 fan-out。找一个你在顺序遍历文件或数据源的任务。每个条目一个 agent，同时跑，最后做一次 merge。墙钟时间的差距就是整堂课。

› 跑一个工作流，审计 src/routes/ 下的每一个路由。每个文件一个 agent，验证每一条发现，然后做综合。

6. 搭一个多会话项目的脚手架。在开始一个长构建之前，让 Claude 写好 init.sh、一份进度日志，以及一份 JSON 格式的功能清单，所有条目都标记为 failing。

› 扮演一个 initializer agent：写出 init.sh、claude-progress.txt，以及覆盖所有需求的 feature_list.json，全部 passes: false。

7. 把上周的 bug 变成评测套件。打开你的 bug tracker，把真实的失败转化成 20 个有明确通过标准的任务。这套评测比这个季度你能引入的任何框架都值钱。

› 这里是 20 个真实失败案例。把每一个写成 eval 任务：能用确定性评分器的就用，不能的就写评分标准。

结语：

任何人都能让一个 demo 跑起来。真正的活儿，是之后的所有事情。

模型会按自己的节奏持续变强，而这种变强是免费的——不管你做没做什么，它都会如期而至。

不免费的是模型周围的那套系统。

• 保持精简的 context。agent 真的能从中做出选择的工具。
• 能活过窗口的记忆。能收敛、且有人验收的循环。
• fan out 而不是排队的图。能让下一个会话接着上一个会话干的 harness。还有一个能告诉你这一切有没有变好的数字。

大多数人会继续等，等一个足够好、好到不需要这一切的模型出现。

而把十二步搭起来的那些人，做出的 agent 即使在模型状态不好的时候里也能照常工作——在生产环境里，这从来都是唯一真正算数的可靠性。

普通人如何抓住AI大模型的风口？

领取方式在文末

2026年入行AI大模型的黄金窗口!!!

AI产业正迎来前所未有的爆发式增长。 从DeepSeek以百万年薪重金招募顶尖研究员，到百度、阿里、腾讯等头部企业加速推进AI Agent商业化布局，再到国家层面持续出台政策，大力扶持数字经济与AI人才培育体系，多重信号清晰指向一个共识：AI的“黄金十年”已全面开启

在产业浪潮的强劲推动下，AI人才争夺战日趋白热化。技术迭代与场景落地双轮驱动，催生海量高价值岗位。放眼未来，AI领域的职业发展前景广阔无垠，正涌现出大量高潜机遇，堪称一片值得深耕的**“人才蓝海”**。

脉脉数据显示📊：
2026年1-2月，AI岗位数量同比增长约12倍，增速远超新经济行业整体增幅；AI岗位在全部新经济岗位中的占比也从2025年同期的2.29%跃升至26.23%，几乎占据新经济招聘市场的四分之一。

与此同时，AI新发岗位平均月薪高达60738元，较新经济行业整体平均月薪48189元高出约26%。

这一切都说明一件事：2026年，正是入行AI大模型的黄金窗口❗️❗️

最佳学习路线

只要你真心想学习AI大模型技术，这份精心整理的学习资料我愿意无偿分享给你，但是想学技术去乱搞的人别来找我！

在当前这个人工智能高速发展的时代，AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长，真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料，能够帮助更多有志于AI领域的朋友入门并深入学习。

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

大模型全套学习资料展示

自我们与MoPaaS魔泊云合作以来，我们不断打磨课程体系与技术内容，在细节上精益求精，同时在技术层面也新增了许多前沿且实用的内容，力求为大家带来更系统、更实战、更落地的大模型学习体验。

希望这份系统、实用的大模型学习路径，能够帮助你从零入门，进阶到实战，真正掌握AI时代的核心技能！

01 教学内容

• 从零到精通完整闭环：【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块，内容比传统教材更贴近企业实战！

• 大量真实项目案例： 带你亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事‌！

02适学人群

应届毕业生‌： 无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。

零基础转型‌： 非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界‌。

业务赋能突破瓶颈： 传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型‌。

vx扫描下方二维码即可
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

本教程比较珍贵，仅限大家自行学习，不要传播！更严禁商用！

03 入门到进阶学习路线图

大模型学习路线图，整体分为5个大的阶段：

04 视频和书籍PDF合集

从0到掌握主流大模型技术视频教程（涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向）

新手必备的大模型学习PDF书单来了！全是硬核知识，帮你少走弯路（不吹牛，真有用）

05 行业报告+白皮书合集

收集70+报告与白皮书，了解行业最新动态！

06 90+份面试题/经验

AI大模型岗位面试经验总结（谁学技术不是为了赚$呢，找个好的岗位很重要）

07 deepseek部署包+技巧大全

由于篇幅有限

只展示部分资料

并且还在持续更新中…

人工智能大潮已来，不加入就可能被淘汰。如果你是技术人，尤其是互联网从业者，现在就开始学习AI大模型技术，真的是给你的人生一个重要建议！

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】