引子:一个非典型全栈故事

先放一组数据:

• 项目名

  :monitoring(内部代号)

• 代码量

  :183 个 TS/TSX 源文件、~2 万行业务代码、跨 4 个 package 的 monorepo

• 提交数

  :198 个 commit,横跨 feature / fix / chore / refactor / perf 五大类型

• 核心模块

  :Agent 监控、知识库检索、日志聚合、服务总览、告警面板、Workspace 切换

• 数据后端

  :Loki + Prometheus + Thanos + Dify + RAG + CAS,六套异构系统的统一封装

• CI/CD

  :GitLab CI → Docker Buildx(amd64)→ 内部镜像仓库 → TKE 自动部署 → Nginx 反向代理 /api 同源

• 作者本人写的代码

  :0 行

这是 2026 年 7 月耗时2周时间,我用 peaks-loop(一套 AI Agent 全流程开发方法论)从 0 到 1 完整交付的内部可观测性平台。这篇文章不是炫技,而是把整个交付过程的技术选型、踩坑记录、架构决策,以及「为什么最终 0 手写代码还能交付生产级系统」这件事,完整复盘出来。

如果你也在评估「AI 能否交付生产级代码」「如何让 Agent 不只写 demo,还能跑完整工程链路」,这篇文章应该会有点用。

---

一、为什么选择 peaks-loop

1.1 背景:为什么这次必须用 AI 写

我们公司内部一直在跑一套 AI Agent 平台 —— 智能体托管、知识库、RAG 检索、监控告警,但监控这一层是空白。原本指望开源方案(Grafana + Promtail + 自研面板)能撑半年,实际跑了两个月就发现:

• 现有 Grafana 看板只覆盖 K8s 基础设施层,完全不感知业务侧(Loki 里 logql 写到怀疑人生)
• 自研面板只展示指标,看不到 agent 单次请求的链路
• 智能体数量上 50 个后,跨工作空间(workspace)的资源隔离、token 计费、错误归因全靠人工捞日志

真实诉求:一个能跨数据源聚合、按业务维度切片、覆盖「基础设施 + 智能体 + 知识库 + 用户操作日志」的可观测性平台。

按照传统估算,这至少需要:

• 1 个前端 + 1 个后端 + 1 个 SRE,合作 2-3 个月
• 期间还要处理 Dify / RAG / CAS 各家 API 兼容问题、CAS 鉴权嵌套会话、跨域反代、K8s 灰度发布 ……

资源紧张,deadline 不允许。这时 peaks-loop 进入了我的视野。

1.2 什么是 peaks-loop

peaks-loop 是一套多 Agent 协作 + 全流程可追溯的开发方法论,核心思想是:

阶段	角色	产出
PRD	peaks-prd	自然语言需求 → 结构化产品需求
RD	peaks-rd 蜂群	PRD → 切片 → 实现 → 代码
QA	peaks-qa	RD 产物 → 测试用例 + 验收报告
UI	peaks-ui	设计 token + 组件 + shadcn 包装
SC	peaks-sc (secrets/config)	环境变量、密钥、部署清单
TXT	peaks-txt (text/translate)	文档 / 翻译 / 注释
Edit	peaks-edit	代码 review + 重构
Final	peaks-final-review	发布前最后一轮审计
Sediment	peaks-memory extract	把约定 / 教训沉淀到 .peaks/memory

最重要的是 Karpathy 守门员(karpathy-reviewer)在每个 RD 阶段做 4 条硬约束检查:Think Before Coding / Simplicity First / Surgical Changes / Goal-Driven Execution。任何一条不通过就回炉。

简单说:peaks-loop 不只是「让 AI 写代码」,而是把整个软件交付流程拆成可独立验证的子环节,每个环节都有 reviewer / auditor 兜底。这才是它和「让 ChatGPT 写个 CRUD demo」的本质区别。

1.3 为什么我敢把生产系统全压上

三个判断标准:

1. 可追溯

   — 每个 commit 能精确指回 PRD 章节、RD 切片、QA 用例、UI 设计稿。这是审计合规的底线。

2. 可回滚

   — peaks-loop 强制走 git worktree + 分阶段提交,任何一处 regression 都能 5 分钟回滚。

3. 可解释

   — 代码旁边永远挂着「为什么这么写」的记忆文件(.peaks/memory/),新人接手不用从 0 读代码。

满足这三点,我就敢签下交付责任。

---

二、架构选型:不是 AI 选的,是我定的

这里要先澄清一个误区:用 peaks-loop 不代表 AI 替你做架构决策。架构选型必须由人主导,AI 只能填实现。

最终落地的技术栈:

2.1 前端 — apps/web

React 18 + Vite 5 + TypeScript 5.4
路由:TanStack Router (1.78,file-based)
数据:TanStack Query (5.x) + axios
UI 体系:Radix UI primitives + 自封装 shadcn 包装
图表:Recharts 2.15
动效:GSAP 3.15(总览 hero 区)
样式:Tailwind 3.4 + tailwind-merge
辅助:zod / es-toolkit / date-fns / lucide-react / sonner / clsx / cva

核心决策记录:

• 不选 Next.js

  :这是内部系统,SEO 不重要;SSR 反而让 CI 镜像从 200MB 涨到 400MB。Vite + SPA 足够。

• 不选 Material UI / Ant Design

  :定制空间太小。Radix UI 提供无样式可访问性 primitive,我们在它上面包一层 shadcn 风格组件,既保持可访问性又能 100% 控制视觉。

• 必须 TanStack Router

  :文件路由 + 类型安全 + loader 模式,比 React Router v6 更适合「schema 驱动」的页面。

• 必须 Recharts

  :不是为了酷,而是它在 shadcn 生态里有现成 theme provider 模式(我们封装了 chart-theme-provider.tsx)。换 ECharts 会破坏整套主题体系。

2.2 后端 — apps/api

NestJS 10.4 + Express session + TypeScript 5.4
依赖注入:@nestjs/core 原生 DI
校验:zod 4.x(注意:不是 class-validator,跨端 schema 共享)
HTTP:axios 1.7(上游 Loki/Prometheus/Thanos/Dify/RAG)
Session:express-session + cookie-parser + Redis(ioredis)
配置:@nestjs/config + chokidar(热重载 yaml)
文档:@nestjs/swagger + swagger-ui-express
序列化:class-transformer
辅助:fast-xml-parser / js-yaml / reflect-metadata

核心决策记录:

• NestJS 而不是 Fastify/Hono

  :内部系统 80% 时间花在写 controller / service / module 这层「企业级脚手架」。NestJS 把这套脚手架规范化,AI 生成代码的契合度比 Fastify 高一个数量级。

• 不用 ORM

  :监控数据全部走 HTTP 上游 + PromQL/LogQL,不落库。唯一持久化是 Redis session + 几份 yaml 配置。

• zod 而不是 class-validator

  :监控前端要复用后端 schema(zod-to-typescript 生成类型),class-validator 不行。

• 多数据源 = 多 module

  :loki / prometheus / thanos / dify / rag / cas 每个一个 NestJS module,通过 SourceRegistry 统一注册(关键模式:sourcesRegistry-single-mutation-point-for-datasource-state)。

2.3 Monorepo 编排

pnpm 10.28 workspaces
turbo 2.3
TS project references + tsconfig.base.json
共享包:packages/shared(给 web + api 复用的类型 / 常量 / 工具)
Docker:Dockerfile.api + Dockerfile.web(分阶段构建,node 20-alpine)
反向代理:apps/web 内置 nginx 把 /api/* 反代到 monitoring-api:3000(同源)

为什么不拆仓库:内部系统 4 个 package 互相 import 频繁,跨仓库调试是地狱。pnpm workspaces + turbo 完全够用。

---

三、0 手写代码怎么做到

接下来是大家最关心的部分。

3.1 工作流:从一句话到生产部署

我用 peaks-loop 跑这个项目的完整链路是:

PRD 输入(中文自然语言,约 600 字)
↓ peaks-prd
结构化 PRD(20 个 feature slice,每个带验收标准)
↓ peaks-slice-decompose
切片清单(每个 slice 一个 PR,独立可合并)
↓ peaks-rd 蜂群(prd → rd → ui → sc → txt → edit)
每个 PR 含:代码 + 测试 + UI 组件 + 配置 + 文档
↓ peaks-qa
QA 验收报告(test cases + e2e + perf baseline)
↓ peaks-final-review
最终放行(Karpathy + security + perf + code review 4 重门)
↓ GitLab CI → Docker Buildx → TKE
生产部署
↓ peaks-memory extract
所有约定 / 教训沉淀到 .peaks/memory

整个过程我没写过 1 行业务代码。我能确认这一点是因为:

• 我对每个 PR 的 MR 描述是「读懂这次改了什么」而不是「写这次改了啥」
• 我对 git log 的反应是「哦这个 fix 是这个 issue」而不是「我刚改的」
• 我对每个新模块的入门方式是「问 peaks-memory 它是怎么设计的」而不是「我自己翻代码找」

3.2 PRD 是怎么写的

举一个具体例子:「服务监控总览页」(对应 overview.services.id``depends_on: [F-AUTH-01, F-DS-LOKI-01, F-DS-PROM-01]``non_functional:``perf_budget: 3s SLA``a11y: WCAG 2.2 AA``data_sources:``- thanos (CPU / mem / net)``- prometheus (QPS / P99)``- otel collector (calls_total fallback)

整个 PRD ~20 个 feature slice 都按这个粒度写。然后 peaks-slice-decompose 把它们排成 6 周的实施计划,每个 PR 一个 slice,3-5 天一个 PR。

3.3 RD 阶段发生了什么

peaks-rd 不是「一个 AI 一把梭」,而是 5 个 sub-agent 并行 / 串行的蜂群:

1. code-architect — 设计模块接口、数据流、build order
2. code-explorer — 摸清现有 codebase patterns、import 关系、convention
3. code-reviewer — 评审生成代码(简单 / 安全 / 复用 / altitude)
4. karpathy-reviewer — 4 红线检查(必须 4/4 通过才能进 qa-handoff)
5. security-reviewer — OWASP Top 10 + 内部 secrets 检查

举一个真实案例:「agents 页面 statsQ 必须等 appsQ」(对应 monitoring-agents-statsq-waits-for-appsq.md)。

最初版本的 agents 页面是这么写的:

// ❌ 错误示范 — AI 第一版生成
const appsQ = useQuery({ queryKey: ['apps'], queryFn: fetchApps });
const statsQ = useQuery({ queryKey: ['stats'], queryFn: fetchStats });
// statsQ 立刻发请求,不依赖 appsQ 是否完成

跑起来发现:stats 接口需要根据 apps 接口的 workspace 状态选 Dify 调用路径,但 statsQ 早早发出去后,Dify 那边 workspace 还没切,返回 0 apps → 后端拿不到 apps → 拿不到正确 stats → 整个面板 zeroResponse。

peaks-rd 蜂群的修复路径:

1. code-explorer 摸清:appsQ 是 useQuery 默认配置,fetchApps 是 async
2. code-architect 提议:statsQ 改成「等 appsQ 完 + 没在 refetch」才发
3. code-reviewer 复用现有模式:已经在 workspace 切换逻辑里用过类似依赖
4. karpathy-reviewer 检查:4 红线全过(Simplicity First ✓、Surgical Changes ✓、Goal-Driven Execution ✓)
5. 写入 .peaks/memory/monitoring-agents-statsq-watts-for-appsq.md,这条经验被永久记录

最终修复代码:

// ✅ peaks-rd 修复版
const appsQ = useQuery({ queryKey: ['apps'], queryFn: fetchApps });
const statsQ = useQuery({
queryKey: ['stats', appsQ.data],
queryFn: () => fetchStats(appsQ.data),
enabled: !!appsQ.data && !appsQ.isFetching,
});

这条经验后来在新加的「RAG 知识库 KPI」页直接复用 — 这就是 peaks-memory extract 的价值。

3.4 一些被永久记录的关键记忆

跑完这个项目,.peaks/memory/ 沉淀了 30+ 条记忆,挑几条对后来人最有用的:

记忆	解决的问题
monitoring-cas-actual-port-8080	平台的 CAS 真实端口是 8080,8088 是 Dify webapp 别误用
monitoring-frontend-no-direct-upstream	apps/web 禁止直连上游,所有数据走 :3001 后端
monitoring-rag-base-url-rag-func	RAG 反代 URL 必须是 rag-func 域名,别用 IP 直连
monitoring-web-nav-chinese-labels	sidebar 中文标签要跟 nav 配置一致,改一处全改
monitoring-business-api-promise-allsettled-pattern	业务 API 多源聚合用 Promise.allSettled,失败不阻断
monitoring-overview-api-wire-contract	总览 API 字段命名规范(下划线 ↔ 驼峰约定)
monitoring-3s-sla-baseline-action-plan	资源聚合页 3s SLA 调优路径(warmup → 聚合 endpoint)
monitoring-effective-role-min-sortorder	多角色权限用 min(sortOrder) 取最小有效角色

这些不是文档,是 codified muscle memory。下一个新模块加进来,直接 read 这些 memory 就知道「哦这个坑别人踩过,这么绕过去」。

---

四、最难啃的几块骨头

4.1 跨工作空间(workspace)权限

Dify 的 /console/api/workspaces/current 必须在 header 携带 workspace id,否则一律 503。但我们的 RBAC 是基于 CAS 拿 role 排序后取最小 sortOrder 决定可见 workspace。

最终方案:

前端 → 后端取 (user, roles[]) → 后端按 sortOrder 升序取第一个 role →
调 CAS 拿 workspace token → 用这个 token 调 Dify /workspaces/switch →
Dify 才返回正确 workspace 的 apps / agents

这条流程跑了 3 个 PR 才稳定,中间被 Dify 那边的 503 坑了好几次(monitoring-dify-8081-workspace-endpoint-503 这条记忆就是那段时间写的)。

4.2 PromQL / LogQL 多源聚合

总览页要同时查:

• Thanos(系统指标)
• Prometheus(应用指标 + OTel calls)
• Loki(日志)
• Dify(智能体维度)
• RAG(知识库维度)
• CAS(用户行为)

每个数据源有自己的 query language、自己的 rate 函数、自己错误码语义。最初我们做成「每个数据源一个 REST endpoint」,前端 N+1 query,首屏 8 秒。

最终方案(对应 monitoring-3s-sla-baseline-action-plan):

1. 后端聚合层增加 /overview/resources``/overview/services 等聚合 endpoint,内部 Promise.allSettled 拉所有上游
2. 单个上游失败不阻断整体,前端用 partial state 渲染
3. Redis 缓存 + TTL = 5s,前端 TanStack Query stale time = 4s
4. CI 阶段加 perf_baseline_review 门禁,任何接口 > 3s 自动 fail

调优后:services 首屏 3.1s → 30ms(103 倍提升),resources 1h 5.4s → 89ms(60 倍提升)。

4.3 OTel calls_total fallback

最离谱的一个坑:Dify 的 OTel HTTP counter 只有 exported_job 级别,service_tenant_id 全集群只有 1 个值(对应 monitoring-dify-otel-no-per-app-label)。

意思就是:aggregate 和 single 实际拿的是同一份数。

peaks-rd 的处理:

• 后端明确知道这俩数一样,不在前端做差异化尝试
• 前端聚合面板用 otel_calls_total 兜底(对比 monitoring-overview-resources-rag-otel-calls-fallback-landed)
• 稀疏错误也能命中(对比 monitoring-agent-kpis-fallback-must-use-1h-increase)

这条经验对未来类似项目极有用:AI 帮你拆穿「这个开源组件的功能描述」,告诉你哪些标签其实没注入、哪些数据永远拿不到。

4.4 shadcn 化的代价

我们强制要求 apps/web 严禁任何裸 DOM input/select/checkbox(对比 monitoring-web-ui-shadcn-only-no-native-dom)。理由:

• 统一 a11y
• 统一主题系统(theme-provider 三态:light / dark / system)
• 统一键盘交互(Radix primitive 已经处理)

代价是每个表单字段都要装 radix primitive + 自己包一层 shadcn wrapper。前期慢,但后面做主题切换、做无障碍审查、做 design system 全都免费。

4.5 CI/CD 那点事

我们的 CI 经历过 4-5 次大改:

1. 第一版:GitLab CI shell executor → docker buildx 多架构 → 内部 registry
2. 第二版:加缓存层(BuildKit layer cache) → install 改 npmmirror
3. 第三版:加 deploy 阶段(HTTP hook 触发 monitoring-func) → 端到端 tag → TKE
4. 第四版:拆分 buildx cache tags 与 image tags → 只推 :TAG-amd64 不推 :TAG root tag
5. 第五版(当前):web 内置 nginx 把 /api 反代到 monitoring-api:3000,完全同源

每一步都被 peaks-final-review 卡了至少一轮 —— 这是好事。AI 写的 CI 不一定对,reviewer 一定要兜底。

---

五、踩坑清单(给后来人)

如果你也想用 peaks-loop 跑类似项目,这份 checklist 应该能省你 2-3 周:

5.1 必须做的

• 架构选型必须人定

  。AI 适合填实现,不适合选型;选型错了全盘皆输

• 每个 PR 一个 feature slice

  。别 AI 一口气给你写 50 个文件

• Karpathy 4 红线是底线

  。任何一条不通过就回炉,不要心软

• 每个 PR 都要沉淀 memory

  。哪怕是「这个文件不要用 lodash」这种小事

• CI 要有 perf baseline 门禁

  。否则 AI 写的代码可能 T = O(n²),跑 8 秒你才发现

• 测试覆盖度 ≥ 60%

  。我们对纯逻辑 module 要求 80%,对 UI component 要求 40%

• 环境变量走 yaml + dotenv,不在代码里写

  。CAS / Dify / RAG 各家 URL 必须 env 注入

5.2 不要做的

• 不要让 AI 选框架

  。它会给你最新最酷的,但不一定是生产稳定

• 不要把测试交给 AI 一把梭

  。AI 写的测试经常是「为了覆盖率」而不是「为了抓 bug」

• 不要忽略 a11y

  。Radix UI 已经处理 80%,剩下 20% 你自己 review

• 不要把 secrets 写进 git

  。即使 .gitignore 也要 peaks-sc 单独跑一遍扫描

• 不要在 monorepo 里跨 package 引用 dist/

  。只引 src/,走 TS project references

5.3 文化层面

• 每周 1 次 peaks-memory extract

  :把这一周发现的约定 / 教训沉淀进去

• 每月 1 次 peaks-memory audit

  :清理过期记忆,合并相似记忆

• 每个新模块都要先看 memory

  :不是先看代码

• PRD / RD / QA 三方互相 challenge

  :不是 AI 单方面输出

---

六、数据:这套方法论真的能 scale 吗

回答:能,但有前提。

6.1 数字层面

指标	数值
总提交数	198
业务 PR 数	60+
平均 PR review 轮数	2.4
平均 PR cycle time	3.2 天
线上事故数	0 P0,2 P3(均为配置类)
测试覆盖率	核心 module 78%,UI 38%
文档完整度	.peaks/memory 30+ 条,CLAUDE.md + PROJECT.md 同步

6.2 隐性收益

• 新人入职 1 天就能上手

  :只需要读 .peaks/memory/ 关键 10 条 + PRD 摘要

• 跨模块改动 0 恐惧感

  :karpathy-reviewer 兜底,surgical changes 强约束

• AI 工具替代率 100%

  :我已经 6 个月没自己写过业务代码了(只写 review 反馈)

6.3 局限性

• 架构选型仍需人主导

  。AI 适合填实现,不适合选型

• 跨域业务知识需要人提供

  。例如 Dify 的 503 行为,AI 必须从你给的 memory 里读

• 复杂 UI 设计仍需人

  。我们用 Figma 出设计稿,AI 照着填

• 运维 / 故障定位 / oncall

  仍需人。AI 生成的监控面板能呈现,但解读仍需 SRE

---

七、写在最后:0 手写 ≠ 0 思考

最后想分享一个不那么酷但很重要的观点:

0 手写代码不代表 0 思考。

整个项目交付过程中,我花在「想清楚要什么」上的时间,比传统开发还多。具体体现在:

• PRD 阶段

  :每个 feature slice 我都要写清楚 acceptance criteria、non-functional 需求、depends_on 关系

• Review 阶段

  :每轮 PR 我都要读 diff、判断、改 spec,这部分时间比写代码多

• Architecture 阶段

  :每个技术选型我都要调研、写 ADR、跟 AI 讨论边界

• Sediment 阶段

  :每条 memory 我都要写清楚「为什么这么选」「踩了什么坑」「下次怎么避免」

AI 把「实现」变成了廉价品,但「思考」反而变成了奢侈品。

这是我用 peaks-loop 跑完整项目后最大的认知转变。生产级软件从来不是「写代码快」就赢,而是「想清楚要什么 + 让代码诚实地表达那个意图」才赢。AI 帮我们把后者变得可规模化,这是真正的杠杆。

如果你也对「用 AI 做生产级全栈」感兴趣,欢迎一起交流。peaks-loop 这套方法论我打算开源(等我把 doc 写完),敬请期待。

---

最后

对于正在迷茫择业、想转行提升，或是刚入门的程序员、编程小白来说，有一个问题几乎人人都在问：未来10年，什么领域的职业发展潜力最大？

答案只有一个：人工智能（尤其是大模型方向）

当下，人工智能行业正处于爆发式增长期，其中大模型相关岗位更是供不应求，薪资待遇直接拉满——字节跳动作为AI领域的头部玩家，给硕士毕业的优质AI人才（含大模型相关方向）开出的月基础工资高达5万—6万元；即便是非“人才计划”的普通应聘者，月基础工资也能稳定在4万元左右。

再看阿里、腾讯两大互联网大厂，非“人才计划”的AI相关岗位应聘者，月基础工资也约有3万元，远超其他行业同资历岗位的薪资水平，对于程序员、小白来说，无疑是绝佳的转型和提升赛道。

如果你还不知道从何开始，我自己整理一套全网最全最细的大模型零基础教程，我也是一路自学走过来的，很清楚小白前期学习的痛楚，你要是没有方向还没有好的资源，根本学不到东西！

下面是我整理的大模型学习资源，希望能帮到你。

👇👇扫码免费领取全部内容👇👇

最后

1、大模型学习路线

2、从0到进阶大模型学习视频教程

从入门到进阶这里都有，跟着老师学习事半功倍。

3、 入门必看大模型学习书籍&文档.pdf（书面上的技术书籍确实太多了，这些是我精选出来的，还有很多不在图里）

4、 AI大模型最新行业报告

2026最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

5、面试试题/经验

【大厂 AI 岗位面经分享（107 道）】

【AI 大模型面试真题（102 道）】

【LLMs 面试真题（97 道）】

6、大模型项目实战&配套源码

适用人群

四阶段学习规划（共90天，可落地执行）

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型

• 带你了解全球大模型

• 使用国产大模型服务

• 搭建 OpenAI 代理

• 热身：基于阿里云 PAI 部署 Stable Diffusion

• 在本地计算机运行大模型

• 大模型的私有化部署

• 基于 vLLM 部署大模型

• 案例：如何优雅地在阿里云私有部署开源大模型

• 部署一套开源 LLM 项目

• 内容安全

• 互联网信息服务算法备案

• …

  👇👇扫码免费领取全部内容👇👇

  

3、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

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