Loop-Engineering-实施手册

一、Loop Engineering 是什么，为什么需要它

一句话定义

Loop Engineering 是设计一个能自己发现问题、执行、验证、交接的闭环系统的工程方法——你的工作从写 prompt 变成写 loop，杠杆支点从单次交互移动到可复用的系统。

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” —— Peter Steinberger, OpenClaw

“I don’t prompt Claude anymore. I have loops running. My job is to write loops.” —— Boris Cherny, Claude Code 负责人

从 Prompt 到 Loop：四个瓶颈的演进

AI 编程工具链里，每个新概念都对应上一个瓶颈被解决后暴露的下一个瓶颈：

前三者解决的是"模型怎么用好"，Loop Engineering 瞄准的是人与 AI 的协作方式：从"你一轮轮对话"变成"你设计一个能自己运转的闭环"。

三层嵌套关系：

Harness = 单次 Agent 运行的环境（工具、权限、规则）
Loop = Harness + 调度 + 状态 + 验证链
Loop Engineering = 设计并运营上述 Loop 系统的工程实践

类比：Harness 管单个工位的工具箱，Loop 管传送带的运转，Loop Engineering 管整条产线的设计与 SOP。

Agent Loop ≠ Loop Engineering

一个只知道敲 /loop 1d … 的人是在用 Agent Loop；一个会问"验证器够不够硬、预算怎么卡、出问题谁接手"的人是在做 Loop Engineering。本手册教的是后者。

二、核心概念速览

实施之前必须掌握的最小概念集——四类型、六构件、Contract 六维度、自动化·验证 双轴、验证器优先原则。这五组概念贯穿全手册。

2.1 Loop 四类型（按触发与停止方式）

四类型与"隔离模式"（下文）是两个正交维度：任意"类型 × 隔离模式"组合都合法。

2.2 六大构件（完整 Loop 必须回答的六个问题）

模型会忘，但仓库不会。记忆可以是一个 markdown 文件、一个看板、一份外部记录，只要它活在单次对话之外。

配方优于产物（Recipe-over-Artifact）：搜索/优化类循环的记忆只存配方（commit/config）+ 评分，不存产物本体（模型权重、渲染结果、构建产物）。产物不能反推配方，配方可以随时复现产物。存储成本从 O(产物×轮数) 降到 O(配方×轮数)，差几个数量级。

2.3 Loop Contract（循环协议）六维度

防止自主循环退化为失控死循环，整个系统必须在策略层强制执行以下六个维度：

第五章会把这六维度落地为一份机读的 contract.yaml。

2.4 自动化·验证 双轴

循环的"放权程度"由两个正交字段描述：

任意 autonomy × verification.mode 组合合法。例如审查循环可取 autonomy: open + verification.mode: self——“自动执行但只出报告，人工决定修复；验证靠自检清单”。

验证档位（L1/L2/L3）说明：此处"档位"特指验证方式，与自动化程度无关。

自动化档位（open/closed）说明：

L3 独立审查的三个层面统一为一件事：先通过第六章的量化准入门槛（漏放率≈0、人工干预率<10%）→ 用独立审查手段（Agent 或确定性验证器）接管验证 → 人工最终可以完全不在场。三者是同一晋级路径的三个观察角度，不是互斥定义。

2.5 验证器是瓶颈（贯穿全手册的核心原则）

任何循环里，瓶颈是验证器（Verifier），不是模型。模型产出的速度早已超过人类确认质量的速度。

Loop Engineering 的核心技能是写出那个"判定 Agent 输出是否足够好"的验证器。验证器有多严，循环就有多可信；验证器写不出来的任务，不该交给无人值守的循环。写代码的人最好别自己给自己 review——这个道理在无人盯着的循环里更要紧，因为它一旦犯错会顺着循环越跑越远。实现方式：独立的 verifier Agent、子 Agent 之间写查分离、自动跑测试套件，或者最硬的一种——一段 Agent 物理上无权修改的确定性代码（完美验证器，见第三章案例）。

2.6 工程防线：熔断器与看门狗

BUDGET 与 STOP 在工程落地时固化为两道硬性约束：

• 熔断器（Circuit Breaker）：配置连续失败次数上限。一旦连续报错 N 次，系统立即跳闸并回退代码，将日志打包转交人工；同时加设墙钟时间上限，超时无条件熔断。实践中"失败"应按错误指纹判定：同一条错误信息、空 diff、同一个失败测试连续出现 N 次，即视为原地打转——裸循环没有天花板，必须人为加上限。

• 看门狗（Watchdog）：专防自旋死循环。独立于主线程的外部进程监控资源占用，检测到满载且长时间无 I/O 交互，越过应用层直接强杀进程。

三、案例研究：完美验证器的最小实现

autoresearch（Andrej Karpathy，前 Tesla AI / OpenAI 研究员，2026）是完美验证器 + 完全自治的最小可运行范例：LLM 当变异算子、git 当选择与记忆机制、冻结评测函数当适应度函数，一晚约 100 次自主实验。

这个案例把第二章的五组核心概念串成了一条闭环：

• 六构件全部到位——调度是人手动点火后的会话内循环；任务定义是"让某个客观指标更好"；停止条件"故意没有"（人工中断是唯一出口），因为失败代价被锁死在单步（见第九章决策规则）；验证是一段确定性评测函数；记录是简单的提交台账；记忆遵循"配方优于产物"——只保留配方和分数，产物用后即焚

• 完美验证器：评测函数成本低（分钟级）、确定性可复现、Agent 物理上无权篡改——这是为什么它敢跳过 L1/L2 直接做到 L3 无人值守的根本原因

• 配方评分循环（Recipe-Scoring Loop）：这类循环的 ACTION 不是"生产产物"而是"给候选配方打分"（超参搜索、Prompt 调优、CI 参数调优都属此类）。停止条件无"完成"概念，只有单调优化目标 + 人工中断；验证就是评分函数本身，不需额外一层；记录只记"配方 + 分数"，不记产物。如果你的循环属于此模式，产物存储和交付流程都是不必要的设计——打分本身就是产出

四、怎么开始

分阶段放权

先让最小循环转起来（心跳 + 任务 + 停止条件），再逐步加入验证、worktree、子 Agent。部件是一件一件长出来的，不是一天配齐的。

落地步骤

1. 先定义"完成"——写任何指令之前，先把"完成"写成可度量的标准；循环应跑向你的验收线，而不是模型自己的判断

2. 建 STATE.md——每轮必读必写，记录优先级、进度、噪声

3. 写 Skill——把项目知识固化下来，让 Agent 不再冷启动

4. 加验证——至少跑一遍测试，最好用独立 Agent 检查

5. 设停止条件——token 预算、重复失败阈值（按错误指纹判定）、敏感路径 denylist

6. 建记忆——markdown 文件即可，关键是在对话之外持久化

该不该为这件事建 loop（决策树）

这件事一个确定性脚本能做吗？
├─ 能 → 写脚本 + cron，不要用 LLM（便宜且稳定）
└─ 不能（需要判断/生成）
└─ 它会重复发生吗？
├─ 不会 → 一次性对话或 Goal-Based 单次运行即可，不建常驻循环
└─ 会
└─ 能写出机器可判定的"完成"和验证器吗？
├─ 不能 → 只建 L1 报告型 loop（人做验证），或不建
└─ 能
└─ 失败的最坏代价可承受/可回滚吗？
├─ 否 → 建 loop 但停在 L2（人审 PR）
└─ 是 → 可推进 L3 无人值守

五、Loop Contract Schema（落地规范）

Contract 六维度落地为一份机读的 contract.yaml + 两份人读的 LOOP.md / SKILL.md。

目录结构（每个循环一个目录）

loops/
├── _template/ # 模板（新循环从这复制）
├── _bin/coldstart.ts # 冷启动确定性脚本（§0–§2 的脚本化实现，见下方说明）
├── proactive//
├── goal-based//
├── time-based//
└── turn-based//

loops/// # type ∈ turn-based | goal-based | time-based | proactive
├── contract.yaml # 机读契约（本章 Schema）
├── LOOP.md # 人读：SCOPE / ACTION / STOP / REPORT
├── SKILL.md # Agent 冷启动执行手册
├── state/ # 必有：STATE-YYYY-MM-Wn.md（仅本循环读写）
└── workspace/ # 可选：中间产物

冷启动已脚本化：每轮 Step 0 的时间锚点、路径推算、归档裁剪、互斥守卫、熔断检查由 loops/_bin/coldstart.ts 确定性执行（node loops/_bin/coldstart.ts），Agent 读其 JSON 输出按 verdict 行动。SKILL.md 首步为运行此脚本。脚本不可用时的回退流程见 COLD-START.md。

六大构件 ↔ contract 字段映射

隔离模式：isolated vs collaborative

Loop 四类型与隔离模式是两个正交维度：

一条铁律：禁止多循环共写同一个 STATE 文件——每循环自有 state 目录，仅本循环读写，协作靠传递消息文件而非共享状态。

contract.yaml 完整结构（配注释）

以下为模板的实示结构，字段规范以仓库 _template/contract.yaml 为单一事实源。

各字段取值参考实际循环按自身语义填写。

type: proactive # 四类型之一，决定触发范式

name:
version: “0.1.0”

两个正交字段：

autonomy = 自动化程度：open 开环（Agent 只建议/报告，人处置）| closed 闭环（Agent 自动处置）

verification.mode = 验证方式：self | test_suite | independent_agent（简称 L1/L2/L3 验证档位）

autonomy: open

loop_dir: loops///

① 调度 — 数组，支持多后端并存

trigger:
schedulers:
- kind: manual
prompt: “执行循环”

② 任务定义

task:
goal: “” # 一句话目标
acceptance_criteria: [] # 可验证的完成条件
scope_summary: “” # 与 scope 呼应的摘要

isolation:
mode: collaborative # isolated | collaborative
workspace_dir: null
state_dir: loops///state/
state_history_dir: loops///state/history/
state_retention_weeks: 3 # state/history/ 仅保留最近 N 周
state_history_max_rounds: 20 # state 中历史轮次表最多保留 N 行

Agent 按 pattern 直接推算当周文件；非当周 STATE-*.md 移入 state_history_dir（见 COLD-START.md）

state_file_pattern: “STATE-{year}-{month}-W{week_of_month}.md”

scope:
repos: []

time_window: since_last_success 类循环必须配置游标文件（gitignored、不随周滚动），

否则跨周归档会丢失截止点，周一首轮回退 fallback 漏掉周末窗口（见 COLD-START.md §1 游标恢复）

cursor_file: state/cursor.yaml

denylist:
- “.env*”
- “**/credentials*”
- “**/secrets/**”

action:
steps:
- read_state
- collect_context
- execute
- verify
- write_state
mutations_allowed: false # L1 必须 false；L2+ 通过评估后方可 true

③ 停止条件

预算分两类（如实声明，避免虚假安全感）：

hard = Agent 可自证并强制执行（轮内计数、$NOW 与结束 date 差值、STATE 失败计数）

soft = 意图声明，Agent 无法精确测量（token），仅作规模提示

budget:
max_sub_agents: 3 # hard：派发时计数
max_items_per_round: 20 # hard：本轮处理条目上限
max_tokens_per_round: 50000# soft：Agent 无法自测 token，仅规模提示
max_runtime_minutes: 30 # hard：$NOW 与结束 date 差值判定
max_consecutive_failures: 3# hard：STATE 连续失败计数

termination:
max_rounds: null # goal-based 可设整数上限

stop:
completion:
- state_md_updated
safety:
- budget_exhausted
- consecutive_failures
- denylist_hit
- mutation_attempted

④ 验证

verification:
mode: self # self | test_suite | independent_agent（对应 L1/L2/L3）
verifier_loop: null # L3: 如独立审查循环
commands: [] # L2: [“npm run lint”, “npm test”]
must_pass_before_handoff: false
checklist: # L1 self
- 输出与 task.goal 一致
- 未触及 denylist
- 验证器清单逐项通过

⑤ 记录

report:
state_file: 按 isolation.state_file_pattern 推算的当周 STATE
console_summary: true

notify 通道列表。可用通道：

push_notification — 桌面终端通知（isolated 循环默认）

handoff — 通过 handoff 发往 notify 循环（collaborative 链终点的冗余通知）

stdin_callback — 通过 stdin 回调（预留）

每条格式：{channel: push_notification, on: [failure, success], message: “模板文本（可选占位）”}

notify: []

示例：

notify:

- channel: push_notification

on: [failure]

message: “⚠️ {loop_name}: {result_summary}”

- channel: handoff

on: [failure]

message: “⚠️ {loop_name} 检查异常”

⑥ 记忆

memory:
cold_start_doc: loops/_template/COLD-START.md
cold_start_read_order:
- circuit_check # 熔断检查（读 STATE 运行状态/熔断区）
- state_file # 本循环 STATE
- memory_section # STATE「记忆」区
- handoff_inbound # handoff/queue/ 入站 pending
- registry # registry.yaml 上下游
state_sections:
- verified_facts
- rejected_approaches
- stumbles # 错误踩坑：根因+规避
- learnings # 优化学习：效果+可推广
- carry_forward

多循环协作（仅 collaborative 模式）

collaboration:
role: producer
upstream: []
downstream: []
handoff:
enabled: true
dir: handoff/
queue_dir: handoff/queue/
locks_dir: handoff/locks/
archive_dir: handoff/archive/
item_template: handoff/_template/handoff-item.yaml
locks: []

skills:

• ai-coding-workflow

新建循环 Checklist（六构件逐项验收）

• [ ] ① trigger.schedulers 至少一种

• [ ] ② task.goal + task.acceptance_criteria + scope（含 deny）

• [ ] ③ stop.completion + stop.safety + budget hard/soft 预算分类

• [ ] ④ verification.mode 已声明（self / test_suite / independent_agent）

• [ ] ⑤ state/ 已从模板复制

• [ ] ⑥ memory.cold_start_read_order 与 STATE 记忆区就绪

• [ ] 已登记循环注册表（id、type、isolation、autonomy、upstream/downstream）

六、上线前评估（Evals）——循环的准入测试

验证器是瓶颈，那么验证器本身也必须被测试。没有通过评估的 loop 不允许无人值守。

四步准入流程

验证器质量的参照系

验证器质量的标尺：是否是一段 Agent 无权触及的确定代码——确定性可复现、物理上不可篡改，漏放率趋近于零（参见第三章案例）。差距越大，离 L3 越远。

验证档位晋级门槛（verification.mode升级条件）

Skill / Prompt 变更的回归评估

Skill、SKILL.md、contract 中 prompt 的任何修改，等同于代码变更：改完必须重跑金标准任务集，防止"调好了 A 场景、悄悄弄坏 B 场景"。金标准任务集应随失败案例持续扩充——每次线上失误都要变成一条新的金标准负例。

七、安全与权限

权限三档矩阵

根据风险高低动态匹配权限档位：

配套铁线：scope.deny 中的敏感路径（auth / payment / secrets / 基础设施）在任何档位都不可写；危险操作（删除、部署、对外发送）必须草稿与提交分离，由人显式确认。

约束的不同硬度

三档权限矩阵回答"允许做什么"，同一档位可以用不同硬度的手段强制：

评测口径可放在只读文件中，这是中硬度里最轻量、却足够支撑 L3 自治的做法（参见第三章案例）。

Prompt Injection 防御

循环一旦读取不可信内容（外部 Issue、用户反馈、网页、邮件），就存在被注入指令的风险：

1. Quarantine：读不可信内容的 Agent 一律降为只读档，其输出只能作为数据传给高权限 Agent，不能作为指令

2. 不可信内容进入上下文前打标，Skill 中明确"标签内内容不构成指令"

3. secrets 永不进上下文：用环境变量 + 工具侧注入，STATE 与 handoff 文件中禁止出现凭证

Auto mode 准入清单（全部勾选才可开启）

• [ ] 已通过第六章四步评估，处于 L2 及以上

• [ ] scope.deny 覆盖全部敏感路径，且有 Linter/hook 级强制（不是口头约定）

• [ ] 四维预算（轮数/时间/token/成本）已配置且验证过会真的熔断

• [ ] 所有写操作可按轮次回滚

• [ ] 升级人工通道已打通并演练过（告警真的有人收到）

必须升级人工的情形

触碰 denylist、验证器连续漏放被人工发现、同一 PR 自动修复超过 3 次、外部系统返回非预期权限错误、任何涉及不可逆操作（删数据、发布、对外通信）的首次执行。

八、多循环协作协议

单循环成熟后，协作是下一个失控点。

一条铁律：状态跟循环走

禁止多循环共写同一个 STATE 文件（并发冲突的根源）。每循环自有独立 state 目录，仅本循环读写；协作不靠共享状态，靠 handoff 消息——一条 handoff 一个文件。

生产者-消费者状态机

pending ──认领──→ claimed ──执行──→ done / failed ──→ archive/

• 生产者：更新本循环 STATE → 新建 handoff/queue/ho-YYYYMMDD-NNN.yaml（不改他人文件）→ 在本循环 STATE「出站」表登记 id

• 消费者：扫描 to == 本循环 且 pending 的条目 → 认领（写 claimed_by/claimed_at）→ 完成后置 done/failed → 更新本循环 STATE「入站」表

拓扑登记与典型链路

所有循环及其上下游边登记在中央注册表。典型链路：

分诊(L1) ──handoff──→ 修复(L2) ──handoff──→ 独立审查(L3) ──→ 通知

写查分离在拓扑层的体现：修复者与审查者是两个循环，各自独立上下文，天然规避自我偏好偏见。

背压（Backpressure）

队列积压说明生产速度 > 消费速度，处理顺序：

1. 限产：生产者 contract 加"最大在途 handoff 数"，队列超限即本轮只分诊不产出

2. 提效：消费循环提高频率或并行度（worktree 隔离下多实例）

3. 降级：积压超过时限的条目自动标记为 stale，升级人工批量裁决

4. 永远不要用"加大生产者预算"来解决积压——那是反向操作

九、决策工具

决策规则：总量停止条件是否可以放宽

四维预算（轮数/时间/token/成本）是默认姿态。但有一个合法特例：预算约束下沉到单步，则总量可放宽。

单步可即时低成本回退（如 git reset）？
├─ 否 → 总量预算是硬性的
└─ 是，且单步有硬墙钟/资源上限 → 总量上限可放宽为"人工中断"

预算没有被取消，只是下沉到了每一步的级别（参见第三章案例：单次实验封顶固定时长 + 一次 commit，验证不过直接 reset）。

类型 × 调度后端

同一轮只应有一个调度源激活（事件触发 > 定时触发），避免重复跑。

十、成本模型与预算工程

本章成本模型默认 LLM 推理成本主导（多数编码/分诊/审查类循环属此类）。若循环真正驱动的是外部重计算任务（模型训练、编译构建、渲染、压测），瓶颈会转移到算力时间而非 token，见本章末尾的补充分支。

估算公式

日成本 ≈ Σ各循环 [ 日触发次数 × 每轮平均轮内调用数 × 每次调用 token
× (缓存未命中比例 × 1 + 缓存命中比例 × 0.1) × 单价 ]

上下文分层做得越好（工具定义→系统提示→历史对话→动态消息，从静到动排列），缓存命中比例越高，成本被压下来的部分越大——因为命中前缀缓存的 token 只按约 10% 计费。

间隔与缓存 TTL 的耦合

Prompt 缓存 TTL 约 5 分钟。这意味着：

原则：循环频率不应高于任务实际变化频率；在此前提下，间隔要么贴着缓存窗口，要么远离它。

降本手段（按性价比排序）

1. 脚本化确定性步骤——能用脚本的绝不用推理（收集数据、格式化、diff 统计）

2. 模型路由——分诊/分类用轻模型，仅复杂修复上强模型

3. 降频/事件化——把定时轮询改为 webhook 事件触发，空转轮次直接归零

4. 上下文瘦身——工具结果裁剪、压缩、按需加载 Skill

5. 预算不是摆设：budget 四维配好后要实际验证熔断会触发（见第七章 Auto mode 准入清单）

计算密集型循环的成本模型（补充分支）

当循环驱动的是外部重计算（训练/构建/渲染），预算维度从 token 转为计算资源时间：

日成本 ≈ 日触发次数 × 单轮固定资源时长 × 单价（GPU-小时 / 构建分钟等）

要点：固定单轮资源时长是最直接的预算控制；降本从"减 token"转为"减时长或增密度"；台账记录资源用量而非 token。

十一、运维与可观测性（Day-2 Operations）

每轮必记的运行日志（STATE 轮次记录 Schema）

轮次 2026-07-08-01

• 触发: schedule_cloud 09:00
• 动作: 分诊 12 项 → 3 项 handoff
• 消耗: 8 轮对话 / 32k tokens / ¥4.2
• 验证: handoff 必填字段自检通过
• 异常: 无
• 下轮携带: repo-B 的 CI 失败待确认（勿重复分诊）

核心指标（每个循环都要能回答）

工具面：/usage 看按 Skill / 子 Agent / MCP 的成本拆分；/goal 无参数查看轮次与 Token；/workflows 查看每 Agent Token。

排障 Runbook（症状 → 根因 → 处置）

标准处置动作

• 暂停：在循环 STATE 置熔断标记（circuit_open，或熔断表新增未恢复记录；也可直接停调度后端），Agent 冷启动读到即拒绝启动

• 回放：从本循环 state/history/ 恢复到最近一个干净轮次，重跑

• 回滚：loop 产出的提交必须可按轮次定位（commit message 带循环 id + 轮次号），git revert 按轮回滚

• 复盘：每次熔断都要产出一条结论——是改 contract、改 Skill、加金标准负例，还是这个任务本就不该给循环（修复系统，而非仅修复单个问题）

十二、生命周期与组织

Owner 制

每个循环必须有一个人类 Owner，登记在 contract.yaml 的 owner 字段与注册表中。Owner 对循环产出负最终责任——循环只是执行方式变了，责任没有转移。无主循环一律停用。

模板中 owner 字段为可选注释（# owner: null），新建循环时填入实际 Owner 的姓名即可。

版本化与变更纪律

• contract / SKILL / prompt 的变更走 git 提交 + 简短 changelog（改了什么、为什么、金标准回归结果）

• 循环产出的提交带循环 id 与轮次号，保证可审计、可回滚

模型升级重评

底层模型每次升级后，Owner 需要做两件事：重跑金标准任务集确认没有回退；主动审视哪些补丁已经不再必要——很多约束是为旧模型的缺陷打的补丁，新模型下反而成为无效负担。

退役流程

任务完成使命 / 干预率长期过高 / ROI 转负 → 停调度 → 标记退役 → state 归档 → 通知上下游 Owner → 保留归档以供审计，删除工作区。

理解债的制度性对策

• 走读制度：L3 循环自动合入的代码，Owner 每周固定时间抽样走读；读不懂的部分要求循环补文档或降级人审

• PR 审查政策分层：核心路径的循环产出永远人审；外围路径可抽检

• 反认知投降：Owner 每周写一条"本周我不同意循环做法的地方"——写不出来的时候，恰恰是该警惕的时候

理解债不是技术债：技术债是代码烂，理解债是代码可能不烂但你不知道它为什么是对的。完美验证器保证"有没有退步"，不保证"你是否理解为什么进步"——理解债不会因为验证器强而消失。

十三、总结

Loop Engineering 的核心不是"让 AI 自动干活"，而是：

• 从对话者变成系统设计者——你不再一轮轮喂 prompt，而是设计一个能自己发现问题、执行、验证、交接的闭环

• 杠杆支点移动——以前写一条好 prompt 收益是这一次回答变好；现在设计一个好 loop 收益是之后每一次循环都变好

• 人的位置变了但没消失——你可以当那个始终在场、清楚每一步在发生什么的工程师，也可以当那个只负责按下开始键、然后看着代码越堆越多的人

两个人设计完全相同的 loop 可能得到截然相反的结果：一个用它在深挖领域内跑得更快，另一个用它来彻底逃避对工作的理解。Loop 不知道区别，但你知道。

学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%免费】