AI Tutorial

课程来源：AI 工程化实战笔记作者：jimmy 投影片：待补充

Vibe Coding 让「写出来」变得便宜：描述意图，Agent 就能吐出能跑的代码。
真正拉开差距的，不是谁让模型多写几行，而是谁能把输出送进可测、可控、可上线的闭环。

从 Vibe Coding 到 AI 工程，中间最重要的是四项能力。

#一、总览：四项能力各管什么

#	能力	一句话	稀缺点
1	构建并上线 AI 应用	会调模型，更会让输出可测可控	Eval、错误分析、持续监测
2	软件工程基本功	知道取舍，才能判断「能上线」还是「只能演示」	架构 / 安全 / 成本 / 扩展性
3	驾驭 coding agent	让 Agent 稳定完成闭环，而不是多写代码	上下文、规格、验证器、检查点
4	塑造产品	「怎么实现」变便宜后，上游判断更稀缺	问题定义、边界、砍需求、MVP

Vibe Coding                    AI 工程
─────────                      ──────
能跑的 demo          →         可上线的系统
「看起来对」         →         可测、可控、可监测
Agent 多写代码       →         Agent 稳定完成闭环
怎么实现变便宜       →         判断「做什么」更值钱

AI 会让执行越来越快，也会让错误的方向被更快地执行。下面四项，就是减慢错误方向、加快正确方向的杠杆。

#二、构建并上线 AI 应用

不只是会调 API，还要懂模型、上下文工程、RAG、Agent 工作流。
更关键的是：会做 eval、错误分析和持续监测，把不可预测的输出变得可测、可控。

#2.1 从「能调通」到「能上线」

层次	你会什么	还缺什么
调 API	发请求、拿回复	延迟、失败重试、成本上限
懂链路	Prompt / Context / RAG / Agent	哪一步在漏信息、幻觉从哪来
可测可控	Eval 集、错误分类、回归门禁	线上漂移、坏案例回流
可持续	监测、告警、抽样人审	把「感觉变差了」变成指标

#2.2 Eval 不是锦上添花

没有 eval，每次改 Prompt、换模型、调检索，都是在黑暗中调参。

最低限度要回答三个问题：

测什么：正确性、拒答率、引用是否落地、工具是否误调
怎么判：规则 / 参考答案 / LLM-as-a-Judge + 少量人工抽查
何时拦：合并前、发布前、线上抽样——哪一级失败必须回滚

#2.3 错误分析比平均分更重要

平均分好看，往往掩盖某一类致命失败。
把 bad case 分桶（检索错、上下文丢、工具失败、格式漂移、安全绕过），比再刷一个排行榜更能指导改哪里。

#2.4 持续监测

上线不是终点。监测至少覆盖：

质量：抽样评分、关键任务成功率
行为：工具调用分布、拒答 / 越权是否异常
成本与延迟：P95、单次 Token、失败重试率

目标不是消灭不确定性，而是把不确定性关进可观测的笼子里。

#三、软件工程基本功

架构、存储、测试、安全、隐私、成本、扩展性。
你得知道工程里存在哪些取舍，才能判断 coding agent 写出的东西是能上线，还是只能演示。

#3.1 Agent 很会写「能跑的」，不一定会写「能养的」

维度	Demo 常见样子	上线要问的
架构	单文件、全局状态、硬编码密钥	边界清晰吗？失败会不会拖垮整条链路？
存储	本地 JSON / 内存	一致性、备份、迁移、多租户隔离
测试	手动点几下	单元 / 集成 / 契约；AI 路径有没有回归集
安全	「先通再说」	注入、越权、密钥泄露、供应链
隐私	日志里全量落 Prompt	脱敏、留存、合规、谁能看
成本	无限重试、无缓存	预算上限、缓存、降级策略
扩展性	单机够用	队列、幂等、限流、水平扩展点

#3.2 取舍意识才是基本功

没有银弹，只有权衡：

强一致 vs 可用性
实时 RAG vs 索引新鲜度成本
人审（HITL）vs 吞吐
自建模型服务 vs 托管 API

Agent 可以帮你实现某一侧；选哪一侧，必须是你的判断。

#3.3 审查清单（给 Agent 产物用）

合并 / 上线前至少过一遍：

有没有把密钥、内网地址写进仓库或 Prompt
写路径是否幂等；失败重试会不会重复扣款 / 重复发消息
权限：谁能读、谁能写、Agent 能不能越权
有没有测试覆盖关键路径；AI 相关路径有没有 eval 门禁
成本与超时有没有硬上限

#四、驾驭 coding agent

会管理上下文，判断先规划还是直接做，写清必要规格，提供测试与验证器，设置人工检查点，并划清生产环境边界。
真正的能力不是「让 Agent 多写代码」，而是让它稳定完成闭环。

#4.1 闭环长什么样

目标 / 规格
    ↓
规划（要不要先 plan）
    ↓
实现（小步提交）
    ↓
验证器 / 测试 / eval  ←── 失败则回修
    ↓
人工检查点（关键路径）
    ↓
合并 / 发布（生产边界内）

#4.2 驾驭要点

能力	具体做什么
管理上下文	只塞相关文件与约定；避免把半个仓库当 Prompt
先规划还是直接做	陌生域、多文件改动 → 先 plan；局部修 bug → 可直接做
写清规格	输入输出、边界、非目标、验收标准；模糊处宁可先问
测试与验证器	给可执行检查（单测、lint、脚本、eval），别只靠「看起来对」
人工检查点	权限、钱、数据删除、对外发布——必须人批
生产边界	Agent 不能直连生产写库 / 发版；用沙箱、只读、或审批后执行

#4.3 反模式

无限改到「感觉好了」：没有验证器，就会在局部最优里打转
一次扔巨型任务：上下文腐烂，错误复利增长
把生产当游乐场：速度换来的是不可逆事故
规格全靠口述：Agent 补全的是它的默认假设，不是你的产品意图

驾驭的本质：你负责目标、约束与验收；Agent 负责在约束内加速执行。

#五、塑造产品：判断什么值得做，以及做到什么程度

当「怎么实现」越来越便宜，真正稀缺的能力会往上游移动：把问题定义对，把边界划清楚。

至少反复问这五件事：

该解决哪个真实问题
用户痛点是否可验证？还是团队自己觉得酷？
用户要的是功能，还是最终结果
要的是「又一个聊天框」，还是「报告已生成 / 工单已关闭」？结果导向会改变整条 Agent 工作流。
哪些需求应该直接砍掉
砍掉不是偷懒，是保护焦点。每个「顺便做一下」都在稀释闭环质量。
什么时候先用 MVP 换反馈
不确定价值时，用最小可测路径换真实信号，而不是先把架构做满。
什么时候不能拿速度牺牲质量
安全、合规、资金、声誉相关路径：慢一点，比快速做错更便宜。

执行变便宜
    ↓
错误方向也会被更快执行
    ↓
上游判断（问题 / 边界 / 砍需求）变得更值钱

#六、四项能力怎么一起用

一次真实上线，大致是这样叠起来的：

④ 塑造产品     定问题、划边界、砍需求、定 MVP / 质量底线
        ↓
① 构建 AI 应用  选链路（RAG / Agent）、建 eval、上监测
        ↓
③ 驾驭 Agent    规格 + 验证器 + 检查点，稳定出实现
        ↓
② 工程基本功    审查架构 / 安全 / 成本，决定能否进生产

缺任何一项，都会卡在某一层：

缺什么	典型症状
缺 ①	Demo 很炫，一改就崩，线上质量说不清
缺 ②	能演示，不能养；事故与成本迟早爆
缺 ③	Agent 越帮越乱，返工比手写还慢
缺 ④	方向错了还加速，功能很多但没人用

#七、一句话收束

Vibe Coding 解决的是「写得出来」。
AI 工程要解决的是：「写对的东西、写到能上线、写完还能持续变好」。

四项能力里，执行会被 AI 加速；判断、约束与验收，仍然要人扛住——否则更快的只是把错误方向跑穿。