01
DEV TEAM · AI CODING & AGENT ENGINEERING
AI 编程实战培训
从 会用 AI 写代码 · 到 · Agent 工程
AI Coding
→
Agent Loop
→
Agent Engineering
开场：欢迎大家。今天不教"怎么写 Prompt"，而是讲怎么把 AI 当作工程流程里的一环来使用。整场会先建立认知框架，再给可执行的四步工作流，最后落到 Agent 工程化与风险治理。建议讲师先用 2 分钟播放一段自己使用 AI 完成真实任务的录屏，形成直观感受。
开发人员的工作方式，正在被 AI 改写
写代码仍然重要，但"如何组织 AI 参与开发"正在成为更核心的能力
1 理解需求 → 查资料 → 设计方案
2 写代码 → 调试 → 测试 → 修改
3 几乎每一步都由开发人员亲手完成
1 AI 分析项目 → 查找代码 → 制定修改方案
2 AI 修改代码 → 执行测试 → 根据错误继续修复
3 开发人员负责 Review 与决策
CORE SHIFT
开发人员真正要掌握的，不是"怎么写 Prompt 让 AI 多生成代码"，而是——
怎么把 AI 正确地纳入软件工程流程。
对比过去与现在两条流水线：过去每一步由人完成；现在 AI 承担分析、写码、测试与自修复，人转向方案决策与 Review。抛出本场核心论点：我们缺的不是 AI，而是把 AI 纳入工程流程的方法。可停留在此页询问听众：你现在用 AI 主要做哪一步？
三层能力，逐级向上
培训结束后，希望大家具备三个层次的能力
1️⃣ 会用 AI让 AI 成为日常开发助手：补全、解释、写函数、查 Bug——能用对话完成任务。
↓
2️⃣ 会用 AI 完成工程任务在真实项目里按 Explore → Plan → Implement → Review 闭环交付，能控制影响范围与质量。
↓
3️⃣ 理解并能构建 Agent 工作流懂 Agent 的循环机制与工具调用，能用 Sandbox / Hooks / Evals 等工程手段治理它。
AI Coding
→
Agent Engineering
代码助手 → 任务闭环 → 自主循环 → 工程治理，是贯穿今天下午的主线。
1 会用 AI ：补全 / 解释 / 查 Bug —— 多数听众在这里
2 用 AI 完成工程任务 ：EPIR 闭环交付 —— 今天课程的重点
3 构建 Agent 工作流 ：理解机制，并能用工程手段治理
代码助手 → AI Coding → Coding Agent → Agent Engineering：不是四种工具，是同一条能力进阶链。
三层目标要讲清"递进关系"：先用会，再用于真实任务，最后能构建并治理 Agent。右上是演进主线，右下自检卡帮听众对号入座，从"自己正处在哪一层"自然带出后续 Agent Loop 与工程治理的进阶路径。
AI 编程 ≠ "让 AI 帮我写代码"
“帮我写个用户管理页面”“这个报错怎么解决”——没问题，但只是最初级用法
◈ ① 代码助手
补全代码 写函数 写 SQL
解释代码 查 Bug 生成正则 编写测试
开发人员仍负责所有操作 · AI Pair Programming 结对编程
◈ ② AI CodingAI 开始参与完整任务 ：搜索代码 → 分析原因 → 修改 → 自测 → 输出结果。
# 例如
◈ ③ Coding AgentAI 能自己循环执行 ：观察 → 分析 → 行动 → 读取结果 → 再分析 → 再行动。
这就是 Agent Loop
◈ ④ Agent Engineering进入工程环境后要解决：能看什么 / 能执行什么 / 改错怎么办 / 是否真过测试 / 如何追踪评估。
Code Assistant 人操作
→
AI Coding 任务级
→
Coding Agent 自主循环
→
Agent Engineering 工程治理
KEY INSIGHT
四个阶段不是工具升级，而是责任转移 ：从“人写好每一步”逐步到“人定义目标与边界、AI 自主执行、工程体系保障质量”。
统一全场的核心定义：AI 编程不止是聊天写码，它分四个能力阶段。这一页先把全景图立起来，后面两页分别拆解①/② 与 ③/④。注意向听众说明：多数人今天停留在阶段①，本培训目标是把团队推到②③，并理解④。
阶段① 代码助手 → 阶段② AI Coding
补全代码 写函数
写 SQL 解释代码
查 Bug 生成正则
编写测试
AI 是“聪明的建议者”，人是操作者与决策者 ——所有操作仍由人完成。
1 搜索代码
2 读取相关文件
3 分析原因
4 修改代码
5 运行 TypeScript 检查
6 运行测试 · 输出修改结果
FROM ASSISTANT TO COLLABORATOR
从"阶段一"到"阶段二"，AI 已不只是一个补全工具 ——它开始对一条完整任务链负责：定位 → 修复 → 验证。
阶段一强调"人操作、AI 建议"，也就是结对编程；阶段二的关键词是"任务闭环"：给一个目标（筛选条件丢失并修复），AI 自己完成搜索、分析、修改、验证。可现场演示：让 AI 修复一个预先准备好的小 Bug，正好展示从①到②的跃迁。
阶段③ Coding Agent → 阶段④ Agent Engineering
观察 Observe
↓
分析 Think
↓
行动 Act
↓
读取结果 → 回到观察
测试失败 → 读错误 → 定位 → 修改 → 重测
1 Agent 能看到什么？
2 Agent 可以执行什么？
3 是否允许删除文件？
4 Agent 修改错了怎么办？
5 是否真的通过测试？
6 任务过程如何追踪？
7 新版 Agent 真的更好吗？
DEFINITION
有了"自动循环"只是 Coding Agent；能回答上面七问、进入生产工程体系 ，才叫 Agent Engineering（智能体工程）。
阶段三是质变点：AI 开始自我循环——观察、思考、行动、再看结果。阶段四则说明：真实团队缺的不是"会循环"，而是"可治理"。七问可让听众逐条对照自己的项目，若答不上来，说明还没到工程化阶段。这也是整场课程后半部分的主线。
AI 编程核心概念：一张地图，七类知识
为后面的实践建立基本知识地图——知道“有什么、在哪儿”，比背定义更重要
01 模型基础LLM · Token · Context Window · Reasoning · Embedding · Structured Output
02 AI 编程方法Vibe Coding · AI Pair Programming · Prompt / Context Engineering
03 Agent 核心Tool Use · Agent Loop · Structured Output · MCP
04 Agent 能力扩展Memory · RAG · Skills · 多步推理
05 Agent 工程Sandbox · Permission · Hooks · Checkpoint · Harness Engineering
06 质量与评估Verification · Evals · Benchmark · Observability · Tracing
07 风险与安全Hallucination · Prompt Injection · Secret · Guardrails · 技术债
HOW TO USE THIS MAP
前三类（01–03）先搞懂原理 ，后四类（04–07）面向落地 ——本课程按地图顺序推进，并在每类结束时回到这张图标注当前位置。
这页是整场的"导航图"。不用逐条细讲，重点是让听众知道知识有七个板块及其先后关系。建议说明：01-03 属于"理解层"，04-07 属于"落地与治理层"；后面的内容都会回到这张地图上定位，避免听众在概念海洋里迷路。
先认识大脑：LLM 与 Token
🧠 LLM · 大语言模型AI 编程系统的大脑 ：GPT / Claude / Gemini / DeepSeek 等。它负责理解、推理、生成与“下一步决策”。
理解需求 阅读代码 推理
制定方案 生成代码 判断下一步
MISCONCEPTION
LLM 本身不会真的操作电脑 ——不能读文件、改文件、执行 Shell、运行测试、操作 Git；这些必须由 Tool 与 Agent Runtime 完成。
🔢 Token · 模型的“字数”模型不按“汉字/单词”理解内容，而是按 Token 处理。它决定了你能喂给模型多少内容、花多少钱。
项目代码 聊天历史 日志
文档 Tool Result
PRINCIPLE
给 AI 的内容不是越多越好 ，应尽量提供正确、相关、高信号 的信息。
两个最容易混淆的点：一是 LLM 只是大脑，动手能力来自工具（Tool）与运行环境（Agent Runtime），这解释"为什么 Agent 需要工具权限设计"；二是 Token 意识——上下文不是免费午餐，控制输入质量是成本与效果的关键。
Context Window：模型一次能看多远
以及 Inference 与 Reasoning——模型如何“想问题”
用户需求 AGENTS.md 相关源码
Git Diff Skills 历史对话
Tool Result 项目文档
DANGER
内容过多时，重要信息会被淹没 ——这正是后面 Context Engineering 如此重要的原因。
Inference ：模型实际运行推理的过程（调用即推理）。
Reasoning ：解决复杂问题的多步思考能力 。
# 一个 Bug 的推理链
复杂的软件开发任务，本质上高度依赖 Reasoning。
Context Window 是模型的“短期工作记忆”，一次能处理的信息有限；当塞满日志与历史，真正重要的项目约束反而会被淹没。Inference 是推理动作本身，Reasoning 是解决复杂问题的多步推理能力——后面讲的 Agent Loop 正是把这个推理链自动化。
Embedding 与 Structured Output：让 AI “找得到、答得规范”
🧭 Embedding · 语义坐标把文本 / 代码转换成“语义坐标” ，相近含义的内容在空间中距离更近。
语义搜索 代码库搜索
企业知识库 RAG
# 场景举例 Auth / Token / Session 相关代码。
📋 Structured Output · 结构化输出让模型按固定格式 返回，而不是一段口语描述。
// 不要返回口语，要求返回 JSON： "file" : "user.ts" ,"line" : 25 ,"severity" : "high" ,"suggestion" : "..."
Agent Tool Calling
工作流自动化 Agent 通信
Embedding 让搜索不依赖关键词字面匹配，而是语义匹配，是 RAG 和企业知识库的底层；Structured Output 让 AI 的输出可被程序消费，是 Agent、工具调用与自动化工作流的基础。建议强调：面向 Agent 的指令应尽量要求结构化返回。
Vibe Coding：快，但不等于工程
快速描述、快速生成、快速尝试——它能开始，却不能替代软件工程
做个页面
↓
运行 · 感觉不好
↓
告诉 AI 修改 · 继续运行
Demo 原型
小工具 技术验证
1 重复代码
2 架构混乱
3 依赖失控
4 无测试
5 技术债务
BOTTOM LINE
Vibe Coding 可以快速开始，但不能替代完整的软件工程。
先给听众"爽点"再泼冷水：Vibe Coding 适合 Demo、原型、小工具、技术验证，能极大提速；但若在大型项目里只靠"描述→运行→不满意→再描述"，会积累重复代码、架构混乱、依赖失控、无测试与技术债。结论：让它当起点，不要当终点。
最易上手：AI Pair Programming + 高质量 Prompt
🤝 AI Pair Programming目前大多数开发人员最容易使用的模式：开发人员负责决策，AI 辅助执行 。
从传统开发进入 AI 编程，这是最合适的第一步。
✍️ Prompt Engineering · 六要素解决的是：怎么把事情告诉 AI？ 开发任务最好说清六件事：
目标 背景 输入
约束 输出 验收标准
❌ 差： “帮我优化一下。”✅ 好： “保持现有公共接口不变，只修改用户列表分页逻辑。先分析分页重复请求原因，再给出最小修改方案。修改后执行 typecheck 和对应测试，不要修改无关文件。”
先给出"人决策、AI 建议"的结对模式作为安全起点；随后给出 Prompt 六要素：目标、背景、输入、约束、输出、验收标准。强调"好 Prompt 是可执行的任务说明书"，对比句中体现了接口不变、范围限定、验证要求等工程约束。
Context Engineering：给对上下文，而非堆砌超级 Prompt
用户需求 AGENTS.md REQUIREMENTS.md
当前代码 相似实现 Git Diff
Skill Memory RAG Tool Result
# 一句话对照 Prompt Engineering ＝ 把问题说清楚Context Engineering ＝ 把正确的信息给 AI
KEY INSIGHT
实际项目中，经常影响 AI 效果的并不是 Prompt，而是——AI 有没有拿到正确的项目上下文 。复杂项目里，Context Engineering 往往比不断优化一句 Prompt 更重要。
问： “用户列表刷新后筛选条件丢了，帮我修一下。”
没有上下文，AI 只能靠猜——“可能是状态没持久化，建议检查相关逻辑”，答得宽泛，定位不到文件。
✅ 直接定位： userStore.ts 第 42 行——筛选状态没有随分页参数一起持久化，并给出最小修改方案与对应测试。
本页是方法部分的"转折点"：很多人执着于超级 Prompt，但真正决定效果的是 AI 拿到的上下文是否正确、相关、完整。右侧静态对比把"同一句话、有无上下文"的差别直接摆在页面上，让听众记住 Context > Prompt：有 Context，AI 才能从"靠猜"变成"直接定位"。
Context Rot：为什么聊得越久，AI 反而可能越差
一开始明确告诉 AI：“不允许修改公共 API” 。经过几十轮操作后，这条规则可能被大量内容淹没——
源码 日志
Tool Result 错误信息
Compaction（压缩） Context Pruning（裁剪）
重新注入核心规则 Skill
AGENTS.md RAG
拆分任务
PRINCIPLE
AI 编程不是把整个 Repository 一次性塞给 AI ，而是——每一步给它最相关的信息 。
解释 Context Rot：随着对话变长，早期的重要约束被后期大量源码、日志、工具结果淹没，模型"忘记"规则。对策包括上下文压缩、裁剪、把核心规则写进 AGENTS.md、沉淀为 Skill、用 RAG 检索、以及把大任务拆小。核心心法：每次只喂最相关的信息。
SDD · TDD · BDD：三种开发方法如何配合 AI
S Spec-Driven · SDD先写清楚做什么，再让 AI 实现 ——复杂功能尤其适合 AI。
需求 → 功能规则 → 接口定义 →
T Test-Driven · TDDRed → Green → Refactor ，测试结果直接告诉 AI 对错。
PASS / FAIL 比“感觉应该没问题”可靠得多。
B Behavior-Driven · BDDGiven · When · Then ，强调业务行为，适合 需求→AI→自动化验收。
Given 用户拥有管理员权限When 用户删除成员Then 成员被删除并记录操作日志
WHY IT MATTERS FOR AI
三种方法共同点：把“模糊的意图”变成可判定、可验证 的规格——这正是 AI 最需要、也最擅长的输入形式。
SDD 先写规格再实现，把验收标准前置，AI 照着做即可；TDD 的红绿重构循环给 AI 提供了确定性的 PASS/FAIL 反馈；BDD 用 Given/When/Then 描述业务行为，能衔接需求与自动化验收。三者本质都是"把模糊意图转成可验证规格"，正好补齐 AI 的短板。
日常 AI 编程，最推荐四步工作流
RULE #1
不要一上来就让 AI 修改代码。
E
Explore
只分析，不修改。 读代码、定位、找根因。
P
Plan
只设计方案。 文件、改动、影响、风险、验证方式。
I
Implement
这时才改代码 ，并跑 lint / typecheck / test。
R
Review
Review 最终 Git Diff ，人机双重把关。
Explore
→
Plan
→
Implement
→
Review
今天最重要的一条实践规则，建议重读并让听众记下：不要一上来就让 AI 改代码。复杂任务统一走 E→P→I→R。E 只分析、P 只设计方案、I 才动手、R 检查最终差异。接下来三页分别拆解每一步的输入与输出。
第一步 Explore · 第二步 Plan
# 标准话术 不修改任何文件 。”
1 找到相关页面 → Store → Router → 初始化逻辑 → 分析根因
Bug 定位 阅读陌生项目
二次开发 影响分析
要求 AI 输出：修改哪些文件、每个文件为什么改/如何改 、影响范围、风险、验证方式。
# Plan 示例 1. UserList.vue — 修改筛选条件初始化逻辑2. userStore.ts — 保留现有筛选状态3. user-list.spec.ts — 增加刷新场景测试
CHECKPOINT
开发人员确认方案后，才进入下一步。
Explore 的目标是"把问题看懂"：只读不改，产出根因分析；Plan 则把修复路径写清楚——改哪几个文件、各自为什么改、风险与验证方式是什么。Plan 完成后必须由人确认。建议给听众一个口诀："先分析、再方案、后动手、终审查"。
第三步 Implement · 第四步 Review
1 严格按照 Plan · 尽量最小修改 · 不修改无关代码
2 执行 lint → typecheck → test → build
DEFINITION OF DONE
代码修改 + 验证通过 = 任务完成 写完代码不叫完成。
不要问“你改好了吗？”，而应让 AI Review 最终 Git Diff ，重点检查：
有没有 Bug 无关修改
重复代码 破坏公共接口
安全问题 过度设计
遗漏测试
HUMAN REVIEW
人工也应重点 Review 最终 Diff ——开发人员始终对代码负责。
Implement 阶段有两个硬约束：严格按 Plan 执行、尽量最小改动，并以 lint/typecheck/test/build 全绿为完成标准。Review 阶段强调"让 AI 审自己的 Git Diff"，用明确的检查清单（Bug、无关改动、重复、接口破坏、安全、过度设计、漏测）代替一句轻飘飘的"改好了吗"。
从零开始的新项目：先规定，再开发
核心原则：不先 AI 生成骨架，而是先规定需求与架构，再让 AI 在约束内开发
Idea
→
REQUIREMENTS
→
ARCHITECTURE
→
AGENTS
→
Skills
→
项目骨架
→
业务 Task
每个 Task 内部再走 EPIR
Explore → Plan → Implement → Review
新项目路线
Idea → 需求 → 架构 → 项目说明书 → 可复用流程 → 骨架 → 任务，逐层收敛、先文档后代码 。
常见错误
第一句就告诉 AI “帮我创建一个 React + NestJS 项目”——让 AI 边生成边决定核心设计 ，架构将不可控。
新项目最重要的原则：先规定，再开发。不要第一句就"帮我建个 React+NestJS 项目"，而是先写 REQUIREMENTS 明确要建什么系统，再写 ARCHITECTURE 定下技术决策，接着用 AGENTS.md 告诉 Agent 项目规矩，把重复流程沉淀成 Skills，最后才让 AI 搭骨架、拆任务执行。
先写清楚“做什么”与“怎么搭”：REQUIREMENTS / ARCHITECTURE
📄 REQUIREMENTS.md · 要建什么系统
项目目标 用户 业务流程
功能模块 数据 权限
页面 非功能需求 验收标准
明确不做什么
这样 AI 才知道：到底要建设一个什么系统。
🏗️ ARCHITECTURE.md · 技术怎么定
前端 后端 数据库
缓存 认证 权限
API 状态管理 目录结构
测试 部署
架构决策一旦确定，就不应让 AI 每做一个功能重新选一次 。
两份文档回答两个问题：REQUIREMENTS 定义"做什么"，把用户、流程、模块、数据、权限、验收标准写全，甚至明确"不做什么"来设边界；ARCHITECTURE 定义"怎么搭"，一次性锁定前后端、数据库、认证、API、目录结构等决策，避免 AI 每个功能都重新发明架构。
AGENTS.md：给 Coding Agent 的项目说明书
项目是什么 怎么安装 怎么启动
目录结构 编码规范 公共组件
禁止事项
lint 命令 typecheck 命令
test 命令 build 命令
价值：让 AI 每次进入项目都能快速理解基本规则 ，无需从零摸索。
团队经常做 CRUD / 页面 / 接口 / 修 Bug / 迁移 / Review，就可以逐步沉淀成 Skills。例如：
create-page 技能流程├─ 先搜索现有页面 → 优先复用组件├─ 创建路由 → 创建类型 → 创建 API└─ 创建页面 → 执行验证
MEMORY HOOK
AGENTS.md ＝ 这个项目应该怎么开发
MEMORY HOOK
Skill ＝ 这种任务应该怎么做
AGENTS.md 是给 Coding Agent 的项目说明书：讲清项目结构、启动方式、编码规范、命令与禁止事项，让 AI 每次进入项目都自动带上这些规则。Skills 是把高频任务（如建 CRUD、开页面）固化成步骤流程，让团队经验可复用。一句话记忆：AGENTS.md=项目怎么开发，Skill=这类任务怎么做。
二次开发项目，流程完全不同
核心原则：先理解，再修改——不要拿到项目就让 AI“给我加个功能”
Repository Scan
→
PROJECT_CONTEXT
→
CODEBASE_MAP
→
Reference
→
Impact Analysis
→
Plan
二开路线
先读懂 → 找参照 → 查影响 → 最小改 → 做回归 ，在“不破坏现有系统”的前提下完成需求。
常见错误
拿到项目直接说“给我增加某功能”——AI 不理解既有架构就开始改 ，极易破坏系统。
新项目可以"先规定再开发"，但二开项目面对的是已有代码库，原则变成"先理解，再修改"。完整流程：仓库扫描→建立项目上下文与代码地图→找最近的参考实现→影响分析→Plan→最小修改→回归→Review。强调二开的每个动作都以"不破坏现有系统"为前提。
Repository Scan + CODEBASE_MAP：先让 AI 读懂项目
🔍 Repository Scan第一条 Prompt：“阅读当前 Repository，只分析，不修改任何代码。” 要求识别——
技术栈 依赖 目录
模块 路由 状态管理
权限体系 API 数据库
公共组件 构建命令 测试方式
产出 → PROJECT_CONTEXT.md
🗺️ CODEBASE_MAP · 功能落点地图按“功能 → 前端 → API → 后端 → 数据库”整理落点，例如“用户管理”：
功能：用户管理
以后 AI 查找项目时，效率会明显提高。
第一步先让 AI 把仓库"通读"一遍，只分析不改代码，产出 PROJECT_CONTEXT.md（技术栈、模块、路由、权限、命令等）。第二步把功能与代码落点建立映射，形成 CODEBASE_MAP，比如"用户管理"这条链路从前端页面、API、后端模块一直到数据库表。地图越清晰，后续 AI 检索越高效。
二开优先“照着已有做”：Reference + Impact Analysis
比如要加“采购管理” ，不要先问"最佳采购模块怎么设计"，先问——
BETTER QUESTION
“项目里哪个模块与采购管理结构最接近？”
已有合同管理 List/Form/Detail/API/Permission/Dict
→
作为 Reference
→
新增采购模块
二开铁律：现有项目规范 > 个人偏好的理想架构
例：增加采购订单“退货”状态 ——先别改，先确认：
采购列表是否用 采购详情是否用
工作流是否用 配送是否用
统计是否用 字典是否用
数据库是否有限制
ORDER
确认影响范围之后，再制定 Plan。
Reference 思路：二开优先复用项目里已有的相似模块作为模板，而不是引入个人偏好的"理想架构"——先问"哪个模块最接近"再开发。Impact Analysis 强调任何改动前先枚举影响面（列表、详情、工作流、统计、字典、数据库约束等），确认范围后才允许进入 Plan。两件事都是为了控制风险。
二开的两个关键词：最小改动 与 回归验证
1 不无关重构
2 不随意修改目录
3 不随意升级依赖
4 不改变公共 API
5 优先复用已有实现
6 保持现有代码风格
新项目可以设计最优方案；二开首先要考虑如何在“不破坏现有系统”的前提下完成需求 。
新功能能用，不代表修改是正确的。必须验证——
新功能 + 受影响旧功能 = 完整验证
EXAMPLE
修改用户权限逻辑，不能只测"新增权限"，还必须验证：登录 · 菜单 · 按钮权限 · 用户角色 · 已有页面 。
这就是 Regression Testing（回归测试）。
最小改动六条纪律：不无关重构、不动目录、不升依赖、不改公共 API、优先复用、保持风格——尤其不要借小需求做大范围 AI 重构。回归的意义在于：新功能可用≠修改正确，必须把受影响旧功能一起验掉，例如改权限就至少回归登录、菜单、按钮权限、角色与旧页面。
什么时候，AI Coding 开始变成 Agent
当 AI 具备“目标 + 上下文 + 工具 + 循环执行”时，就逐渐进入 Agent
Agent ＝ LLM ＋ Context ＋ Tools ＋ Agent Loop
DISTINCTION
到目前为止我们主要是在使用 AI 参与开发 ；一旦目标、上下文、工具与循环四要素齐备，AI 就从"被调用的工具"变成"自主执行任务的 Agent"。
转折页：讲清 Agent 的判定条件不是"用了多强的模型"，而是四要素是否齐备——目标、上下文、工具、循环执行。给出公式 Agent=LLM+Context+Tools+Agent Loop，强调没有工具与循环，LLM 只是会说话的编辑器。用这张公式承接后面 Tool Use 与 Agent Loop 两页。
Tool Use：Agent 为什么能够操作项目
LLM 本身不能读文件——Agent 通常通过 Tool 完成：
readFile()
writeFile()
searchCode()
runCommand()
runTest()
gitDiff()
LLM 决定调用 Tool
↓
Runtime 执行 Tool
↓
得到 Result → 回传给 LLM
↓
LLM 决定下一步
▶ readFile(UserList.vue) — 定位筛选渲染处FAIL 一条断言不符PASS ✓
KEY MECHANISM
模型产生意图，Runtime 执行动作，结果再喂回模型 ——这是 Agent 能"动手改代码"的根本机制。
工具是 Agent 的"手"：readFile、writeFile、searchCode、runCommand、runTest、gitDiff 等。真正流程是模型决定调用什么工具，Runtime 执行并把结果回传，模型再决定下一步。右侧轨迹卡把这条闭环落到一条可见的工具调用链上，建议现场逐行点读，强调每一步都在读真实文件、跑真实测试。
Agent Loop：Agent 的核心引擎
Observe 观察
↓
Think / Plan 思考
↓
Act 行动
↓
再回到 Observe
1 修改代码 → 运行测试
2 测试失败 → 读取错误
3 重新分析 → 继续修改
4 再次测试 …… 直到通过
真正的 Coding Agent，就是这样工作的。
Agent Loop 是最小循环：观察→思考→行动→再观察。结合"测试失败自愈"的例子讲：改码、跑测试、失败、读错误、再分析、再修改、再测试。真正的 Coding Agent 就是把这个循环不断跑下去，直到任务完成或人工介入。这是理解 Agent 自主性的钥匙。
MCP · RAG · Memory：别混淆三件事
🔌 MCP · 连接协议Model Context Protocol ：Agent 接入外部工具和资源的标准化方式 。
Git Jira 数据库
企业文档 Design System 内部 API
解决：不同 Agent 如何以统一方式 接入这些能力。
📚 RAG · 检索方法Retrieval-Augmented Generation ：如何找到相关知识并放进 Context 。
问题
→
搜索知识库
→
内容入 Context
→
回答
🧠 Memory · 长期记忆Agent 的长期记忆来源，例如记住：
用户用 pnpm 项目用 React
组件用 Ant Design 禁止 any
不混淆 MCP ＝ 连接协议 （怎么接）
不混淆 RAG ＝ 检索方法 （怎么找）
不混淆 Memory ≠ Context ：存储 vs 当前真正看到的内容
三个概念经常被混为一谈：MCP 是"Agent 怎么统一接入外部工具"的协议（连接层）；RAG 是"如何检索知识并放入上下文"的方法（检索层）；Memory 是长期存储，而 Context 是模型当前真正看到的内容。记住三句话即可：MCP=连接协议、RAG=检索方法、Memory≠Context。
从 Agent 到 Agent Engineering：最大的变化是什么
# 真正进入生产项目后，会遇到更重要的问题 1. 它删错文件怎么办？2. 它执行危险 Shell 怎么办？3. 它测试没通过却说完成怎么办？4. 它访问生产数据库怎么办？5. 长任务中途失败怎么办？
允许犯错
↓
能够发现
↓
阻止危险行为
↓
能够回滚 / 重新执行
CONCLUSION
所以必须进入Agent Engineering（智能体工程） ——用工程体系，而不是靠运气与提示词，去保障 Agent 的可靠性。
承上启下的一页：写一个会循环调工具的 Agent 不难，难在它进入生产后可能删错文件、跑危险命令、谎报测试通过、触碰生产库、长任务中断。可靠性的来源不是"模型不犯错"，而是"允许犯错→能发现→能阻止→能回滚→能重跑"。由此引出 Harness 工程。
Harness Engineering：让系统更可靠，而不只是让 Agent 更聪明
Sandbox
Permission
Hooks
Checkpoint
Tests
Verification
Guardrails
Observability
Evals
ONE-SENTENCE
真正稳定的 Coding Agent，不依赖模型永远不犯错 ，而是依靠允许犯错 → 能够发现 → 能够阻止 → 能够回滚 → 能够重新执行 。
KEY IDEA
Harness 把"安全与可靠"从提示词里拿出来，变成系统级的工程组件 ——下面逐一展开 Sandbox、Permission、Checkpoint、Hooks、Verification、Evals 等。
Harness 是 Agent 的"安全带与仪表盘"：Sandbox 限制环境、Permission 控制权限、Hooks 自动触发规则、Checkpoint 支持回滚、Tests 提供基准、Verification 把关完成、Guardrails 兜底红线、Observability 记录行为、Evals 衡量好坏。这一页先把全景建立起来，后面分页详述。
Sandbox 与 Tool Permission：先划边界，再给权力
📦 Sandbox · 沙箱环境Agent 一旦拥有 Shell 权限，Sandbox 就非常重要。限制它——
1 只能访问当前项目
2 不能随意访问系统目录
3 不能直接操作生产环境
4 不能读取不必要的 Secret
🔐 Tool Permission · 工具分级
readFile → 自动writeFile → 自动runTest → 自动git push → 询问删除数据库 → 禁止 / 强制确认生产部署 → 强制人工确认
PRINCIPLE
Least Privilege · 最小权限
Sandbox 回答"Agent 能在什么环境里活动"——只能碰当前项目、不能乱闯系统目录、不能直连生产、不能读到多余密钥；Tool Permission 回答"每把工具能用到什么程度"——读文件写文件跑测试可自动，git push 需询问，删库/生产部署必须人工确认或直接禁止。核心原则：最小权限。
HITL · Checkpoint · Hooks：人控、存档、守则
👤 Human-in-the-loopAgent 工程不意味着全无人参与——高风险操作保留人工确认 ：
普通代码修改 → 自动运行测试 → 自动Git Push → 人工确认生产部署 → 人工确认生产库修改 → 人工确认
💾 Checkpoint · 存档点长任务执行前保存状态，失败可回滚——让 Agent 敢于做长时间自主任务。
Git Checkpoint
↓
AI 开始修改
↓ 严重失败
Rollback 回滚
⚙️ Hooks · 规则自动化把团队规则变成自动执行的动作 ：
代码修改后 → 自动 lint test 检查危险命令
比在 Prompt 里写一句“请记得运行测试”可靠得多。
三件工程组件：HITL 回答"哪些环节必须人点头"——改码测试可自动，Push/部署/动生产库必须人工确认；Checkpoint 在长任务前存档，严重失败直接回滚；Hooks 把团队规范变成事件钩子自动触发（改后 lint、提交前 test、执行 shell 前扫危险命令）。可靠性来自机制而非提示词。
Verification · Evals · Benchmark：不要相信“已完成”三个字
✅ Verification · 完成标准必须外部验证
lint
typecheck
unit
integration
e2e
build
Git Diff
PRINCIPLE
能够通过机器验证的事情，不依赖 AI 自己口头确认。
📊 Evals · 新版真的更好吗团队优化 Prompt / AGENTS.md / Skills / Model / Agent 后，用50 个真实开发任务 做对比：
修复 TS 类型错误 新增 CRUD
修改 API 补充测试
修复权限问题 处理 CSS Bug
成功率 测试通过率
执行时间 Token
Tool Calls 人工介入次数
🏁 Benchmark · SWE-benchCoding Agent 领域常见思想：给 Agent 一个真实 Repository 和 Issue，看它能否真正修复并通过测试 。SWE-bench 即此类软件工程 Benchmark。对企业团队更重要的是——根据自己项目建立内部 Benchmark 。
三件事层层递进：Verification 是任务级的"完成校验"（lint/typecheck/单测/集成/e2e/build/Diff）；Evals 是版本级的"质量回归"（用 50 个团队真实任务量化对比成功率、耗时、Token 等指标）；Benchmark 则是行业与内部的标准测试集，SWE-bench 是代表。原则：机器能验证的，就不听口头确认。
Observability · Tracing · Subagent：看得见，才管得住
🪟 Observability · 记录 Agent 做了什么
成功率 失败率 耗时
成本 Token Tool Calls
测试结果
🔬 Tracing · 还原一次任务的链路
Prompt
→
Search
→
Read
→
Edit
→
Test Failed
→
Edit
→
Passed
Agent 出问题时，非常容易定位到具体环节。
🧩 Subagent · Multi-Agent · 编排单个 Agent 稳定后，可派生子 Agent：
主 Agent├─ 前端 Agent ├─ 后端 Agent├─ Test Agent └─ Review Agent
WARNING
不要一开始就追求 Multi-Agent ，正确顺序：
Single Agent
→
做到稳定
→
Subagent
→
Multi-Agent
这就是 Agent Orchestration（编排）——过早引入，复杂度会迅速失控。
Agent 自动执行越多，越需要"看见它做了什么"：Observability 沉淀成功率、耗时、成本等指标，Tracing 还原单次任务的 Prompt→Search→Read→Edit→Test 链路，出问题能快速定位。编排方向上，强调次序：先把单个 Agent 做稳定，再 Subagent，最后才 Multi-Agent——别一上来就上复杂多智能体。
AI 编程中的风险，必须特别重视
随着 AI 权限越来越大，风险也越来越大——五类风险逐一识别
1 HallucinationAI 虚构不存在的 API、文件、版本、测试结果——表面自信，实则编造。
2 Prompt Injection外部内容（网页/README/Issue）中可能藏有恶意指令，Agent 读取即被劫持。
3 Secret ManagementAPI Key、密码、Token 被写进代码 / Prompt / Git / 日志。
4 Guardrails 缺失缺少提示规则、权限、沙箱、Hooks、人工确认与输出校验等保护组合。
5 Technical DebtAI 大幅提高代码产生速度——也可能大幅提高垃圾代码 产生速度。
ATTITUDE
风险不能靠"提醒 AI 小心"解决，而要落到流程、工具与制度 ——下一页给出每类风险的直接对策。
在讲完 Agent 的能力之后立刻讲风险，避免团队盲目上权。五类风险：幻觉（编造 API/文件/测试结果）、提示注入（外部内容≠可信指令）、密钥泄露（写进代码/日志/Git）、Guardrails 缺失、以及技术债被 AI 放大。态度上强调：治理靠机制不靠叮嘱。
每一类风险，都有明确的对抗手段
① Hallucination
不存在的 API 不存在的参数
不存在的文件 不存在的版本 不存在的测试结果
→ 对策：查代码、查文档、执行测试 ，不要只相信 AI 的说法。
② Prompt Injection
网页 README Issue
文档 日志 第三方内容
→ 记住：外部内容 ≠ 可信指令 。
③ Secret Management
API Key 密码
Token 数据库凭据
→ 不能写进代码 / Prompt / Git / 日志 。
④ Guardrails · 保护措施组合
Prompt Rules Permissions
Sandbox Hooks
HITL Output Validation
⑤ Technical Debt · 主动检查
重复实现 无意义封装
新依赖 无测试代码
绕过类型 无关重构
逐条给对策：幻觉靠"查代码、查文档、跑测试"来证伪；提示注入的核心戒律是外部内容不可信；密钥管理是四条红线（不进代码、不进 Prompt、不进 Git、不进日志）；Guardrails 是把前面所有保护组合成系统；技术债则要在 Review 中主动筛查六类坏味道。
公司开发人员：六层学习路径
不建议一上来就学复杂 Agent 框架——按层逐级进阶
Level 1 会使用 AI 写代码
Prompt Engineering AI Pair Programming Git Diff 代码 Review
目标：AI 成为日常开发助手
Level 2 会用 AI 完成任务
Context Engineering Explore Plan Implement Review
目标：AI 协助完成完整开发任务
Level 3 会管理项目 AI 上下文
AGENTS.md REQUIREMENTS ARCHITECTURE PROJECT_CONTEXT CODEBASE_MAP Skills
目标：让 AI 真正理解项目
Level 4 理解 Coding Agent
Tool Calling Agent Loop Structured Output Memory RAG MCP
目标：理解 AI 为何能自主执行
Level 5 进入 Agent Engineering
Runtime Sandbox Permission Hooks Checkpoint Verification Guardrails
目标：让 Agent 安全可靠地工作
Level 6 Agent 工程化
Evals Observability Tracing Benchmark Subagent Multi-Agent Orchestration
目标：对 Agent 质量进行系统化管理
给团队一条可执行的成长阶梯：Level1-2 是个人写码层面的"会用"；Level3 上升为"管理项目的 AI 上下文"；Level4 理解 Agent 自主执行原理；Level5-6 进入工程化治理与质量体系。每层都标注掌握点与目标，建议团队按季度规划，逐层打怪。
日常 · 新项目 · 二开：三条标准流程
🗓️ 日常开发任务（9 步）
1. 描述任务
🆕 新项目
需求 → REQUIREMENTS.md
口诀：先规定，再开发
🔁 二开项目
Repository Scan → PROJECT_CONTEXT.md
口诀：先理解，再修改
COMMON CORE
三条流程共享同一条内核：理解 → 方案 → 执行 → 验证 → 人工把关 。把流程固定下来，团队协作才有确定性。
把今天的流程收敛成三张可张贴的"作战卡"：日常任务 9 步（含两次人工确认点：确认方案、确认 Diff 后 Commit）；新项目 12 步（先文档后代码，先规定再开发）；二开 10 步（先理解再修改，最小改动+回归）。强调三条流程内核一致：理解→方案→执行→验证→人把关。
整个培训最希望大家记住的十条原则
1 不要一上来就让 AI 写代码 先让 AI 理解问题。
2 复杂任务走 EPIR Explore→Plan→Implement→Review，减少盲目修改。
3 Prompt 重要，但 Context 更重要 AI 不知道的信息，再聪明也无法正确处理。
5 二开项目先理解 Repository 不要让 AI 破坏已有架构。
6 二开优先找 Reference Implementation 让 AI 按项目已有模式开发。
7 尽量最小改动 尤其不要借小需求做大范围 AI 重构。
8 不要相信 AI 自己说测试通过 能自动验证的必须真正运行。
9 最终一定看 Git Diff 开发人员仍然对代码负责。
10 从"会问"升级到"会管理 Agent" 专业能力＝Context＋Tool＋Agent＋Harness＋Evals。
十条原则是今天培训的"带走物"。可按顺序快速带读，其中第 1、8、9 条最容易破功，值得着重强调：先理解再动手、验证以机器为准、人始终对最终 Diff 负责。最后一页给出专业能力公式，为进入 Agent 工程收尾。
AI 不会降低软件工程的重要性，反而会提高它
THESIS
AI 极大降低了写代码的成本 ，但同时也提高了管理代码质量的要求 。
把需求说清楚 设计合理架构
提供正确 Context 判断 AI 方案
控制修改范围 设计验证方式
Review AI 代码 建设可靠 Agent 工作流
BIG IDEA
AI Coding 并不是软件工程的替代品，而是软件工程能力的放大器。
1 AI 辅助编程 ：补全 / 解释 / 写函数
2 Coding Agent ：理解项目 → 分析 → 修改 → 自测 → 反馈迭代
3 Agent Engineering ：Context · Tools · MCP · Skills · Sandbox · Permissions · Hooks · Verification · Observability · Evals
EPIR Context AGENTS.md
先规定，再开发 最小改动 Harness
看 Git Diff Evals
NEXT STEP
回到团队，从三件小事开始：挑一个真实任务完整走一遍 EPIR；为仓库写一份 AGENTS.md，把规范交给 AI；给部署 / 推送设一道人工确认 ——先跑通，再谈规模化。
收束全场的论点：AI 降低了写码成本，却抬高了质量管理的门槛。开发者的价值正从"写得快"转向"说得清、设计对、管得住"。用三阶段图帮听众自我定位：多数人在阶段一，今天课程目标是把团队推向阶段二并理解阶段三。结尾用关键词卡回顾全课要点，以"三件小事"收束，让听众带着可执行的第一步离开。
★
NEW WAY OF BUILDING SOFTWARE
人 + AI / Agent + 工具 + Harness + Evals
一种新的开发协作方式
🤖 AI / Agent 搜索 · 分析
从传统开发，走向 AI 编程，再走向 Agent 工程
主讲：＿＿＿＿ 日期：＿＿＿＿ 单位：＿＿＿＿
结束页：把新的协作方式定格为五个角色——人负责需求、架构、判断与责任；AI/Agent 负责搜索、分析、执行与反馈；工具连接真实环境；Harness 负责限制与保护；Evals 衡量质量。可在此页留时间做 Q&A，并告知大家讲义资料会沉淀为团队内部分享。
‹
1 / 0 ›
☰
📝
🎤
⛶
← → 翻页 · N 备注 · P 演讲者 · G 目录 · F 全屏