前言：写给新时代的AI原住民

你可能已经用ChatGPT、DeepSeek写过作业，用Seedance生成过图片，用Claude Code、Trae帮你写代码。你已经是AI的熟练使用者了。

但我要告诉你一个你可能已经隐隐察觉的事实：你“调Prompt”的方式，已经过时了。

不是说AI过时了，恰恰相反，AI正在以惊人的速度渗透进每一个行业。过时的，是我们跟AI打交道的方式——那种凭感觉写一段指令、碰运气看结果、改坏了也不敢动的手工作坊式做法。

这套教程要教你的，是下一代人机协作方式：像造产品一样“造”智能体，而不是像写日记一样“写”指令。

这是本套教程的第一篇，后续内容会通过本账号陆续发布在CSDN。

本教程的“三不原则”

在正式开始之前，我要和你做一个坦诚的约定。这本教程：

• 不涉及底层模型原理——没有Transformer结构讲解，没有注意力机制推导，没有微调教学。
• 不要求复杂编程能力——你只需要会写基础Python，会运行脚本，会新建文件。所有代码都有模板。
• 不绑定特定AI模型——教给你的是工程方法，换一个模型同样适用。

这不是一本“原理书”，这是一本“工程书”。我们的目标不是让你理解AI，而是让你驾驭AI。

本书的“双轨并行”设计

读这本书，你会同时走在两条线上：

• 故事线：跟着“评论甄别神器”的完整开发故事走，从遇到痛点、到尝试解决、再到最终掌握方法，就像在看一本技术小说。
• 项目线：每一章你都有明确的产出物——第4章产出一份评测规范文档，第5章产出一个测试数据集，第6章产出一个可运行的智能体和评测报告……学完这本书，你手里攒下的不是零散笔记，而是一整套可以迁移到任何项目的工程资产。

这就是你的个人工程资产库。

你将学到什么

学完这本书，你将具备三项核心能力：

1. 独立开发一个可评测、可迭代的单智能体系统——从规范定义到自动化评测，完整走完五步工程流程。
2. 协作完成一个多智能体企业级项目——模拟产品、研发、测试、运营四角色协同评审产品需求，直接可作为课程设计或求职作品集。
3. 建立一套不依赖任何工具的工程化思维——哪怕明年出现新的AI开发工具，你也能迅速上手，因为范式是通用的，工具只是载体。

如何使用本教程

如果你是在校学生，建议按章节顺序阅读，每章的课后练习一定要动手做——工程能力不是看出来的，是练出来的。如果你已经有一定基础，可以直接跳到第4章开始实战，遇到概念不清时再回头查阅第2章。

配套资源包括所有示例代码、数据集、Prompt模板，获取方式见附录H。

好了，让我们开始吧。

---

第一篇：破局——为什么我们需要工程化方法？

---

第1章 一次“失败”的智能体开发体验

本章你将学到：

• 用传统方式开发一个“评论甄别智能体”的完整过程
• 为什么这种开发方式会让你陷入“改一处坏十处”的困境
• 工程化方法要解决的根本问题是什么

本章你将产出：一个初版评论甄别智能体的Prompt（以及一次深刻的“挫败感”）

---

1.1 场景：我想做一个“评论甄别神器”

打开外卖App，想找一家好吃的店。第一条评价：“太好吃了！五星好评！”——配图是一张模糊的餐盒照片。第二条评价：“难吃死了，千万别来！”——没写具体哪里难吃。第三条评价：洋洋洒洒二百字，但有一半在抱怨昨天下雨导致配送慢，跟食物本身毫无关系。

你翻了五分钟，还是不知道哪家值得下单。

这是每个大学生每天都会遇到的场景。刷单好评、情绪发泄式差评、毫无信息量的废话评论——它们像垃圾信息一样，塞满了我们日常使用的每个平台。

如果有一个智能体，能自动帮我们甄别这些评论，判断它是否“真实有效、有参考价值”，那该多好？

这就是我们要做的项目：评论甄别智能体。输入一段用户评论，输出一个判断——这条评论是“有效”还是“无效”。

听起来很简单，对吧？让我们用最传统的方式开始。

---

1.2 传统做法：写好Prompt，直接开干

打开你熟悉的开发环境，写一段Python脚本，调用大模型API。核心就是那段Prompt：

你是一个专业的评论审核员。请判断以下用户评论是否“有效”。
有效的评论应该包含具体信息，具有可参考价值。
无效的评论通常内容空洞、情绪化、或与商品无关。

用户评论：{comment}

请以JSON格式输出：
{
  "valid": true/false,
  "reason": "判定理由"
}

你找了几条评论试了试：

输入评论	AI判断	你觉得
“这家店的红烧肉特别软烂，肥而不腻，分量也足，值得回购。”	✅ 有效	判断正确
“还行吧。”	❌ 无效	判断正确
“太难吃了，里面的肉咬都咬不动，而且服务员态度超差。”	✅ 有效	判断正确

效果不错！初版就对了三条。你心里开始盘算：再修一修，就可以发给朋友炫耀了。

---

1.3 噩梦开始：无休止的“打补丁”

你把测试扩大到二十条评论，问题开始出现了。

第一个问题：平台刷单的“水文”被漏掉了。
输入：“这家店真心不错，味道好，环境好，服务好，下次还来！”
AI输出：{"valid": true, "reason": "表达了正面评价"}

——全是套话，说了等于没说，怎么能算有效？你赶紧在Prompt里加了一条规则：“如果评论全是笼统形容词堆砌，没有具体描述，判定为无效。”

第二个问题：真实的差评被误伤了。
输入：“这顿饭毁了整个周末。点了糖醋里脊，端上来全是面粉，咬开里面不到指甲盖大的肉。退了也不让，说我已经吃了两块。我是吃了两块才确认全是面粉的好吗！”
AI输出：{"valid": false, "reason": "包含过多情绪化表达"}

——等等，人家确实写得很具体啊！有菜品描述、有事实细节，这恰恰是一条高质量评价。你又加了一条规则：“情绪化表达和具体事实并存时，只要事实细节充分，仍判定为有效。”

你开始感到不安。每发现一个新问题，你就加一条规则。现在Prompt已经变成了密密麻麻的一长段，而测试结果呢？

好消息：之前那两个问题修好了。
坏消息：原来三条正确的判断中，有一条现在被判错了。你不知道是新增的哪条规则跟旧规则冲突了，你也不敢删，因为每条规则都对应着一个曾经被你“修好”的问题。

改了一处，坏了十处。你的Prompt变成了不敢碰的“祖传代码”。

---

1.4 停下来，思考：我们到底缺了什么？

你不是一个人。每一个刚开始做AI开发的人，都会经历这个阶段。

对比维度	传统开发方式	工程化开发方式
评测方式	肉眼一条条看结果	自动跑批，一键出报告
修改风险	改一处不知道影响多少	跑回归测试，立刻看到全部影响
问题定位	凭感觉猜原因	错误分类统计，精准归因
知识积累	经验和直觉在人脑里	规范和数据集在文件里
迭代效率	越改越怕，越怕越不敢改	每次迭代都有据可查，可持续改进
复现能力	换个人重做一遍，结果完全不同	按同样流程，结果可控

这不是你能力不够，是方法本身有天花板。

我们的做法——写Prompt、试几条、看到错误就改规则——本质上是手工作坊。它有三个致命缺陷：

• 不可测：没有自动化测试，每次修改只能手动抽几条看效果，你不知道什么被修好了，什么被修坏了。
• 不可靠：规则靠人想，问题靠人找，每次迭代质量完全依赖你当时的状态。
• 不可持续：这次的开发经验存在你脑子里，下次做新项目从零开始。你的工作没有留下可复用的资产。

你需要一套完全不同的方法。不是“更好的Prompt技巧”，而是软件工程级别的系统化方法。用规范代替直觉，用数据代替拍脑袋，用自动化评测代替人眼检查，用可追溯的迭代代替“碰运气式”修改。

这就是下一章要介绍的Harness工程化方法。但在开始之前，不妨先亲手感受一下手工作坊的痛苦——那是理解新方法价值的前提。

---

1.5 本章小结

• 我们设计了一个“评论甄别智能体”，目标是判断用户评论是否有效。
• 用传统方式开发：写Prompt → 测试几条 → 发现问题 → 加规则 → 引入新问题 → 不敢再改。
• 传统方式的核心缺陷：不可测、不可靠、不可持续。
• 解法方向：用工程化方法系统性地“驾驭”AI的不确定性。

---

课后练习

1. 拿出你在1.2节写的初版Prompt，找20条你身边真实出现过的评论（外卖、电商、App Store都可以），逐条手工测试，记录正确和错误的数量。你发现了哪些“被误判”的模式？
2. 尝试用“加规则”的方式修好其中一个错误。修好之后，重新测试全部20条。有没有哪条之前正确的现在反而错了？
3. 如果你在修复过程中感到“越改越不敢动”，把这个感受记下来。下一章我们要彻底解决它。

---

本章配套资源

• 初版Prompt模板（可直接复制使用）
• 20条模拟评论数据集（包含多种典型类型）
• 获取方式见附录H