课程来源：AI 工程化实战笔记 作者：jimmy 投影片：待补充
前提： AI 已经具备在提供完整、清晰 Prompt 的前提下，完成复杂架构项目的开发执行，并且错误很少。
核心结论： 先立业务架子，用 AI 铺开设计 / 业务 / 技术；人的位置在提升（取舍与创造性），价值低的工作交给 AI；技术是底座，不是唯一身份。
#一、总览
| 图 | 主题 | 一句话 |
|---|---|---|
| 图 1 | 传统业务系统架构 | Client / 前端 → 业务 → Data → 中间件与存储 |
| 图 2 | 先定业务架子 | 先理解业务与工期，再做技术选型 |
| 图 3 | AI 辅助落地 | Prompt ↔ 模型 + 文档 / 知识库 / Skills |
| 图 4 | 角色演进 | 人向产品 / PM / 前后端 + Agent 扩展 |
| 图 5 | AI 与人的分工 | AI 参与各环节；人往上提；低价值工作交给 AI |
#二、图 1：传统业务系统架构
┌─────────┐
│ 前端 │
└────┬────┘
│
client ───────────► 【业务】
│
▼
三方 ─────────────► 【Data】
│
┌──────────┼──────────┐
▼ ▼ ▼
接近/接入 处理 engine
│ │ │
└──────────┴────┬─────┘
▼
┌─────────────────┐
│ 存储与中间件 │
│ · Kafka（多个） │
│ · Redis 热点 │
│ · MySQL / CK │
│ · ES（工作+双写）│
└─────────────────┘
左侧可补充能力：
· 小功能 · 任务 · 可配置
· 任务细化 · Pool
请求从 Client / 前端进入业务层，业务读写 Data；经接入、处理、engine 后，落到 Kafka / Redis / MySQL·ClickHouse / ES 等。
#三、图 2：做项目时先定「业务架子」
AI 100% ──► 理解业务
工期 ──► 时间约束 ──► 排期
技术选型（✓）
┌─────────────────────────────────────────┐
│ gdk · MySQL · CK · Redis │
│ Data · QPS │
│ client / Data / 分阶段推进 ✓ │
└─────────────────────────────────────────┘
│
▼
【架子】业务
先尽量把业务和工期搞清楚，再按 Data、QPS 等约束做中间件选型，先立业务架子，而不是先堆技术名词。
#业务架子是什么？
业务架子 = 在写具体代码、堆中间件细节之前，先立起来的那套「业务骨架」。
它回答的是：系统要办什么事、边界在哪、按什么节奏推进——技术选型要挂在这副骨架上，而不是反过来用技术名词硬套业务。
可以拆成三块：
| 块 | 要定清楚的内容 | 例子 |
|---|---|---|
| 业务理解 | 核心对象、关键路径、约束与边界 | 谁在用？主流程是什么？哪些不做？ |
| 工期与排期 | 时间约束下能做到哪一步、如何分阶段 | 1 个月出什么；MVP vs 后续 |
| 选型服从业务 | 按 Data、QPS、读写形态选底座 | 要不要 CK、Redis、Kafka，因业务负载而定 |
和「技术底座」的分工：
技术底座：gdk · MySQL · CK · Redis · Kafka · ES …
│ （能跑、能存、能扛量）
▼
业务架子：对象 / 流程 / 边界 / 分阶段目标
│ （做什么、做到哪）
▼
再用 AI 铺开：设计 · 细节 · 实现
- 不是：一上来列一堆中间件名词，再找业务去填
- 而是：先立架子（业务 + 工期），再选底座，再用 AI / Prompt 往里填设计和代码
架子立稳之后，才进入下一节的 Prompt 闭环。
#四、图 3：AI 辅助落地（Prompt 闭环）
技术底座（已选型）
gdk · MySQL · CK · Redis · Data · QPS
│
▼
【架子】业务
│
▼
┌─ prompt ─┐
│ ↓ │
│ AI │──► 理解流程（步骤 7、8…）
│ ↓ │
│ prompt │◄─────────────┐
└──────────┘ │
│ │
┌───────────┼───────────┐ │
▼ ▼ ▼ │
工作.md 知识库 Skills │
│ │ │ │
└───────────┴───────────┴───────┘
业务架子定好后，用 prompt ↔ AI 循环理解流程；配合工作文档、知识库、Skills 产出实现，再落地到具体算法或代码。
#五、图 4：分工演进
① 当前路径
────────────────────────────────────────
产品 ──► 想 ──► PM / QA
一线 ──► PM + 前后端
② 未来路径
────────────────────────────────────────
AI-Agent ──► AI ──► 具体落地
↑
（能力/经验积累）
右侧仍需碰的能力：
· 前后端
· Data
· 计算相关
────────────────────────────────────────
协作上用 AI 优化并提取问题；职业上从纯实现扩展到 产品理解 + PM/前后端 + Agent，同时仍要具备前后端与 Data 的基础。
#六、图 5：AI 参与各个环节，人的位置在提升，价值低的工作交给 AI
AI
│
▼
┌─────────────────────┐
│ 设计 · 业务 · 技术 │
│ 取 舍 │
└──────────┬──────────┘
│
▼
创 造 性 ←── 人
闭环： AI ──► 人 ──► AI
前提： 人要有能力（判断 / 整合）
结构示意：
┌────┐
│ │
├────┤
│ 人 │ ──► ┌───┐
├────┤ │ × │ ← 可替代环节拿掉
│ │ └───┘
└────┘
#七、一张图串起来（端到端）
┌──────────────────────────────────────────────────────────┐
│ 1. 理解业务 + 工期 │
│ 2. 技术选型：MySQL / CK / Redis / Kafka / ES · Data·QPS │
│ 3. 立【业务架子】 │
└────────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ 4. Prompt ↔ AI + 工作文档 / 知识库 / Skills │
└────────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ 5. AI 参与各个环节（设计 · 业务 · 技术） │
│ 6. 人的位置提升：【取舍】──►【创造性】 │
│ 7. 闭环：AI → 人 → AI；价值低的工作交给 AI / 拿掉 │
└──────────────────────────────────────────────────────────┘
▼
角色：产品 / PM / 前后端 + Agent
（技术是底座，不是唯一身份）