AI 课程 03｜成为 AI Builder：把工作流、文档和自动化接起来

这篇先讲什么

• 核心问题：怎样把“会用 AI”推进成“能持续交付结果”的 Builder 能力。
• 适合谁：已经用 AI 做过一些零散任务，想进一步做自动化、做工作流、做项目的人。
• 读完你会得到：从 GUI 到 API 的过渡、自动化思维、文档和评估机制，以及把 AI 接入日常工作的操作框架。
• 在系列中的位置：这是第 3 篇，重点从“理解 Agent”转向“把 Agent 真正用起来”。

课程定位：66节课、400页教材。从Simple User变成Real Builder——不只是会用AI聊天，而是能用AI设计并运行真实的自动化工作流。面向需要通过AI交付高质量工作成果的专业人士。

模块1：生成式AI的力量

核心议题：AI辅助编程到底改变了什么？

传统视角（错误的）：AI写代码，我负责提需求。

Builder视角（正确的）：AI降低了编程门槛，让每个人都能把"重复性操作"委托给计算机。这是一种思维方式的升级，不只是工具使用。

Technical Insight 1：批处理——从点击到批量

核心洞察：在AI之前，批量操作需要写程序；现在，你用自然语言告诉AI你要什么，AI替你写程序。

实际例子：

• 过去：给100个JIRA ticket逐个添加评论 → 手动点击100次
• 现在：告诉AI"给这100个ticket都加上评论’已评审’"→ AI写脚本一键完成

这就是批处理（Batch Processing）：把重复性的手工操作，变成一行代码触发的自动化。

Technical Insight 2：GUI vs API——计算机交互的本质

这是整个课程最重要的概念之一，理解它才能理解AI为什么是革命性的。

GUI（图形用户界面）：

• 为人类设计，靠眼睛看、手操作（鼠标点击、键盘输入）
• 易用，但无法自动化——“委托"必须委托给人类
• 例子：Excel界面、浏览器、手机App

API（应用程序接口）：

• 为计算机设计，靠代码调用
• 难用（需要记住大量参数和规则），但可以完全自动化
• 一个for循环就能处理1000个任务
• 例子：JIRA API、Gmail API、Stripe支付API

AI带来的第三种交互方式——自然语言：

过去：GUI（人操作）→ 效率低，不可批量
      API（代码调用）→ 效率高，但需要编程能力

现在：自然语言 → AI翻译 → API调用 → 自动化执行

一句话：AI = 用自然语言打开了API的大门。非开发者第一次可以享受API带来的批处理、自动化、委托等所有好处。

Technical Insight 3：从用户到Builder

三个阶段的演进：

Builder的核心思维：主动从计算机中提取价值，而不是被动消费AI功能。

模块2：GenAI 内部原理与最佳实践

LLM如何工作：记忆、知识与上下文窗口

LLM的本质：预测下一个token（词）的概率分布机器。它"知道"的一切都来自训练数据，它"记得"的一切都在上下文窗口里。

三种"记忆"的区分：

• 知识：训练数据里学到的，固定不变（截止日期之前）
• 上下文：当前对话里你给的信息，对话结束就消失
• 工作记忆：模型处理当前请求时的临时状态

常见坑1：AI的"懒惰”——输出长度限制

现象：让AI翻译/重写一篇长文，它开头做得很好，后面越来越"偷懒"，开始跳段。

根本原因：GPT模型不是因为"故意偷懒"，而是训练数据里很少有超长输出的样本，导致模型不擅长持续生成长内容。

技术证据：

• GPT-4-Turbo：128k输入上下文 vs 只有4k输出上限
• 这个不对称说明：模型被训练成"读很多、说少一点"

解决方案：拆分任务

错误做法：翻译这5页文章 → AI翻到第3页开始跳段

正确做法：
- 翻译第1-2段
- 翻译第3-4段
- ……（分批处理，最后合并）

验证方法：直接调用GPT API（绕过ChatGPT产品层），测试是否还懒惰。如果API也懒，说明是模型本身的问题，不是ChatGPT的设置。

常见坑2：AI的"遗忘"——上下文窗口限制

现象：长对话后，AI"忘记"了你开头说的要求，开始不遵守规则。

根本原因：

1. 上下文窗口有长度限制（旧模型如GPT-3.5只有4k token）
2. ChatGPT会主动丢弃早期对话来控制成本

实验验证：GPT-3.5在上下文超过4k时，会开始遗忘；GPT-4-Turbo的128k窗口大得多，但同样有极限。

解决方案：

• 重要规则放在对话开头（模型更重视开头）
• 长对话定期"提醒"AI关键规则
• 用.cursorrules或System Prompt固定核心规则

最佳实践：用"Edit模式"替代"Chat模式"

Chat模式的问题：对话越来越长 → 上下文越来越多 → AI越来越容易遗忘和混乱

Edit模式（如ChatGPT的Edit功能）：

• 直接编辑之前的回复
• 保持上下文干净
• 避免对话"膨胀"

实战建议：

• 短任务：Chat模式就好
• 长任务/多轮迭代：用Edit模式，或定期开新对话

自动化的力量：为什么不只是"节省时间"

自动化带来三大价值（超越时间节省）：

1. 减少错误：程序不会因为疲劳或情绪犯错，人会
2. 灵活性：可以7×24小时自动运行，在满足条件时自动触发
3. 降低认知负担：不用再记着去检查，系统自动帮你盯着

具体例子（Gmail优先级处理）：

• 不用它：你担心错过重要邮件 → 每隔10分钟查一次邮件 → 频繁打断工作
• 用它：AI监控收件箱，只有重要邮件才通知你 → 专注工作，不错过重要信息

这就是认知卸载（Cognitive Offloading）：把"持续监控"的认知负担转移给计算机。

模块3：打通 GUI 与 API——4个实战项目

项目1：抓取CVPR学术会议网站数据

问题：CVPR是计算机视觉顶会，论文数据分散在网页上，手动整理要几天。

Builder的解法：

1. 用浏览器开发者工具（F12）查看网页HTML结构
2. 让AI写Python脚本解析HTML，提取论文标题、作者、摘要
3. 输出为结构化CSV/JSON

核心认知：HTML是GUI和API之间的桥梁。网页看起来是给人看的，但本质是结构化数据。

关键代码思路：

import requests
from bs4 import BeautifulSoup

# 1. 请求网页
response = requests.get("cvpr网址")

# 2. 解析HTML结构
soup = BeautifulSoup(response.text, 'html.parser')

# 3. 提取数据
papers = soup.find_all('div', class_='paper-item')

# 4. 输出结构化数据
for paper in papers:
    print(paper.find('h3').text)  # 论文标题

时间对比：手动整理3天 → AI辅助2小时

项目2：从Instagram下载图片（Bookmarklet技巧）

场景：需要批量下载某账号的图片，但Instagram不提供下载API。

解法：Bookmarklet

• 把JavaScript代码存成浏览器书签
• 点击书签 → 在当前页面执行JavaScript → 自动完成操作
• 无需安装任何软件，纯浏览器实现

Bookmarklet的应用场景：

• 任何需要在网页上批量操作的任务
• 绕过没有官方API的网站
• 快速自动化GUI操作

项目3：图像内容分析（GPT多模态能力）

能力演示：GPT不只能处理文字，还能分析图片。

实际应用：

import openai
import base64

# 发送图片给GPT分析
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "描述这张图片里发生了什么"},
            {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_data}"}}
        ]
    }]
)

实际业务场景：

• 监控摄像头画面分析（异常检测）
• 气象图分析（天气预报辅助）
• 内容审核（图片合规检查）
• 产品图片自动打标签

项目4：GUI自动化——Pi Day挑战

场景：需要在某个不提供API的软件界面上操作（比如legacy系统）。

解法：PyAutoGUI（Python的GUI自动化库）

import pyautogui
import math

# 控制鼠标画一个圆
center_x, center_y = 500, 500
radius = 200

for angle in range(0, 360, 1):
    x = center_x + radius * math.cos(math.radians(angle))
    y = center_y + radius * math.sin(math.radians(angle))
    pyautogui.moveTo(x, y, duration=0.01)

适用场景：

• 需要操作没有API的旧系统
• 自动填写表单
• 批量截图
• 模拟用户操作进行测试

模块4：开源 LLM 与工具链

为什么要关注开源模型？（4类商业LLM无法满足的场景）

场景1：数据合规要求

• 涉及PII（个人身份信息）、医疗、金融数据，法律不允许发送给第三方服务器
• 企业内部文件不能上传到外部API

场景2：基础设施限制

• 带宽受限、低延迟要求（如远程地区）
• AWS Bedrock的Claude 3.5 Sonnet仅支持50 QPM（每分钟请求次数），高并发场景不够用

场景3：大规模成本

• 处理海量数据时，商业API成本不可承受
• 本地模型边际成本接近零

场景4：定制化需求

• 需要针对特定领域微调（如医学、法律专业术语）
• 需要提炼出更小的专精模型降低延迟
• 构建自有模型可提升在管理层和投资者眼中的技术竞争力

Ollama + Open WebUI：本地运行LLM

Ollama：一行命令在本地运行开源大模型

ollama run llama3  # 下载并运行Llama3
ollama run mistral # 运行Mistral

Open WebUI：给Ollama套上漂亮的ChatGPT风格界面

• 支持多模型切换
• 支持对话历史
• 支持文件上传

【重要洞见】为什么课程不教传统RAG？

这是课程最有深度的观点之一，揭示了一个大多数AI课程不会说的真相：

理由1：在重复造轮子，且造得不好 信息检索是搜索引擎的核心技术，已经发展数十年。但流行的RAG实现完全忽略了这些成熟方案，从非常基础的点重新开始。“语义分块”（Semantic Chunking）仅仅相当于十年前的搜索技术。

理由2：工作流静态割裂，智能有天花板 传统RAG的架构：

用户问题 → 向量检索 → 找到相关文档块 → 塞给LLM → 生成答案

这是单向的、线性的管道。搜索和LLM之间没有动态交互——不会追问、不会迭代验证、不会根据初步结果调整搜索策略。

理由3：建立在流沙之上 RAG最初是为了解决LLM上下文窗口太短的问题（2k、4k token放不下大文档）。但短短两年内：

• 上下文窗口从几千token激增至数百万token（Claude 3.7支持200k）
• API价格降至原来的1%
• 推理速度指数级提升

这意味着RAG的根本假设正在快速失效。

真正的机会在哪里：

1. LLM与搜索引擎的联合优化——不是简单管道，而是共生系统
2. Agentic RAG——AI自主决定何时搜索、用什么关键词、如何综合多轮检索结果

这就是为什么课程4（AI Architect）教的是Agentic RAG，而不是传统RAG。

本地RAG（检索增强生成）——无需编程

RAG是什么：让AI回答问题时，先从你的私有文档里检索相关内容，再生成答案。

没有RAG的问题：

• AI不知道你的内部文档
• 问公司内部规定 → AI乱答

有RAG后：

• 上传你的文档
• AI先搜索文档，再基于文档回答
• 答案有据可查

Open WebUI内置RAG：上传文档→开启→即可查询，真的无需编程。

实际应用：

• 公司内部知识库问答
• 合同文件快速检索
• 个人笔记智能查询

Agent：给本地LLM装上工具

Open WebUI支持给本地模型添加工具（搜索、计算等），让本地AI也能具备Agentic能力。

模块5：把 GenAI 融入日常工作

核心框架：用"管理思维"用AI

这是课程最重要的认知升级：用管理团队成员的方式来管理AI，而不是用使用工具的方式。

Step 1：识别工作流瓶颈

方法：找出你的核心竞争力 vs 限制你效率的因素

案例（TPM，技术项目经理）：

• 核心竞争力：大规模协调、沟通、谈判
• 效率杀手：
  • 无休止的会议
  • 消息轰炸（Email、Slack、各种IM）
  • 浏览器开了100个tab找不到

策略：

• 强化核心竞争力（更多时间用于战略判断）
• 用AI减轻效率杀手的负担

Step 2：选择性委托给AI

核心原则：不是所有任务都适合AI，AI不是万能的。

适合委托给AI的任务特征：

• 重复性高
• 规则明确
• 不需要独特判断
• 错了可以检测和纠正

不适合委托给AI的任务：

• 需要创造性和独特视角
• 高风险决策（错了代价大）
• 需要人际关系和情感理解

实战案例：Gmail优先级处理器

问题：邮件太多，担心错过重要邮件，频繁查收影响效率。

解决方案：

1. 给Gmail接入GPT API
2. 设定判断规则：“来自老板/客户/紧急词汇的邮件是重要的”
3. AI自动监控收件箱，只在重要邮件到达时发通知

效果：减少90%的无效邮件检查，专注时间大幅增加。

上下文切换的代价（重要认知）：

心理学研究显示，每次被打断后，需要平均23分钟才能完全重新进入深度工作状态。如果每10分钟查一次邮件……你基本永远进不了深度工作。

Step 3：文档管理——AI的效率倍增器

核心洞察：AI做得好不好，60%取决于你给它的文档质量。

什么是"AI友好的文档"：

• 明确说明背景和约束条件
• 用精确语言描述规则（不含歧义）
• 包含示例（好的/坏的各一个）

文档管理的复利效应：

• 第1个月：你维护文档，AI按文档执行
• 第6个月：你的文档越来越完善，AI做得越来越准确
• 第1年：整套流程高度自动化，你只需要审核结果

Step 4：评估机制——先定标准，再开工

核心原则（最常被忽视）：在让AI做任何任务之前，先定义"什么叫做好了"。

为什么重要：

1. 强迫你深度思考任务本质
2. 产生可重复使用的验证工具
3. 让质量检查变得客观、可自动化

实战：Gmail优先级处理的评估

# 先写测试用例（评估标准），再让AI实现功能
test_cases = [
    {"email": "老板说明天会议取消", "expected": "重要"},
    {"email": "某网站会员优惠通知", "expected": "不重要"},
    {"email": "客户说项目deadline提前", "expected": "重要"},
    {"email": "团队周报", "expected": "不重要"},
]

# 运行AI分类器
for case in test_cases:
    result = classify_email(case["email"])
    assert result == case["expected"], f"分类错误：{case['email']}"

Show, don’t tell：如果你没有写出对应的验证代码，你就没有真正完成这个功能。

Step 5：风险管理

AI的特殊风险（不同于传统软件）：

• AI可能会"幻觉"（说错但很自信）
• AI行为不确定（同样的输入，不同时间可能不同输出）
• 模型更新后行为可能变化

风险管理策略：

1. 快速失败原则：宁可早点发现错误，也不要让错误积累
2. 可观测性：至少要知道什么时候AI出错了（监控+告警）
3. 渐进式部署：先小规模测试，再全面铺开
4. 保留人工审核：高风险决策，AI辅助但人来决定

技术洞察：像管理者一样思考

管理者的四大技能 = AI使用的四大技能：

结论：提升AI使用效率的最好方式，不是学更多prompt技巧，而是学习管理学。

模块6：成为 Future Proof

关键研究：GenAI 是基于共识构建的

LLM的工作机制：通过大量文本训练，学会预测"下一个最可能出现的词"。

这意味着：

• AI擅长的 = 训练数据中出现频率高的内容（共识知识）
• AI不擅长的 = 训练数据中罕见的内容（非共识知识）

实际例子：

与幻觉共处（Work with Hallucination）

重要认知：幻觉不是bug，是LLM的基本特性，也是使它有用的必要代价。

幻觉的底层机制：Noisy Nudge（噪声微调）

要真正理解幻觉，需要理解LLM的训练过程。

训练时，模型不断被"微调"（nudge）去预测正确的下一个词。这个微调来自海量训练样本的累积影响。关键在于：频繁出现的知识能穿透噪声，罕见知识会被淹没。

具体例子：

训练数据里有大量"太阳从东方升起"的句子。同时也有少量描述"金星上太阳从西方升起"的句子（因为金星自转方向相反）。

结果：当你问"太阳从哪边升起？"，模型自信地说"东方"。这对地球是对的，但对金星是错的。模型不是在撒谎——它给出的是训练数据中概率最高的答案。

训练过程中从未有"这个答案是否正确"的显式目标。正确性只靠"共识"来保证：出现得足够多→AI会答对；出现得太少→AI就幻觉。

为什么AI特别不擅长数学？

同样是Noisy Nudge机制的结果：

1. 数学在训练数据中占比小——互联网内容中，自然语言文本远多于数学公式
2. 数学子领域极多——每个子领域（代数、几何、微积分、数论……）各自稀少，进一步摊薄了数据密度
3. 例外：100以内的加减法等超高频运算，AI表现良好——因为这类例子在训练数据中出现了无数次

这也是为什么ChatGPT集成了Python运行环境和计算器：不是让AI"学会"数学，而是把精确计算交给计算机，让AI专注于它真正擅长的推理和协调。

幻觉为什么是必要的（不只是缺陷）

“幻觉对于有用的GenAI系统是不可避免的，因为世界本身不是确定性的。只说正确废话是没用的。”

传统机器学习模型如果只优化"不出错"，会快速陷入局部最优（总是说废话安全答案）。GenAI必须允许"探索"，而这种探索的本质就是在概率空间里冒险——有时押中，有时押错，错了就叫幻觉。

软件 vs GenAI 的本质差异：

• 传统软件：精确输入 → 精确输出（deterministic）
• GenAI：模糊输入 → 模糊输出（probabilistic）

这不是缺陷，而是一种全新的计算范式。正是这种"模糊性"让AI能处理语言、创意、推理——这些本来就没有唯一正确答案的任务。

控制幻觉的实用方法

1. 搜索引擎增强（如New Bing/Perplexity）：先搜索事实，再基于搜索结果生成答案——把"记忆"外包给搜索引擎
2. 文档约束：提供文档上下文，要求AI只基于文档回答，不允许"自由发挥"
3. 外部工具验证：让AI调用计算器、数据库，而非靠"印象"给数字
4. 高风险任务人工复核：对于法律、医疗、财务决策，AI是起草工具，不是终审法官

有价值的观点必须是逆向的

GenAI的致命局限：它永远只能给出共识答案，无法给出真正独特的洞察。

真正有价值的见解：

• 与共识相反的正确判断（逆向正确）
• 还没有人发现的新趋势（超前认知）
• 基于独特经验的实践智慧

你的竞争优势公式：

有价值的工作 = 大量使用AI处理共识性任务
             + 你自己形成逆向且正确的判断

行动指南：

1. 把重复性、共识性工作委托给AI
2. 用节省下来的时间和精力，深度思考和形成你自己的独特判断
3. 通过实际构建来学习（Learn through building）

模块7：LLM 训练原理（Bonus）

第一阶段：预训练（Pre-Training）

目标：让模型学会"预测下一个词"

数据：互联网上的海量文本（书籍、网页、代码、论文……）

规模：GPT-4训练数据约1万亿token，需要数千块GPU训练数月

结果：模型学会了语言、知识、推理能力……但不知道如何回答问题

噪声干扰问题（Noisy Nudge）

问题：训练数据中错误信息会影响模型

例子：如果互联网上绝大多数人说"金星从东方升起"，模型就会认为这是对的，即使物理上金星确实从西方升起（在某些条件下）。

数学不擅长的原因：数学推导过程在训练数据中比例很小，且容错率低（一步错全错）。

解决方案：

• 接入外部工具（让AI调用Python计算器而非靠"记忆"计算）
• RAG（提供准确的外部知识库）

第二阶段：指令微调（Instruction Fine-Tuning）

问题：预训练后的模型只会"接龙"，不会"回答问题"

解决：用少量高质量的"问题-答案"对数据继续训练

训练格式：

User: 美国的首都是哪里？
Assistant: [让模型预测接下来的词]
正确答案: 华盛顿特区

关键认知：

• 指令微调不给模型增加新知识，只改变交互风格
• 模型知道Markdown格式和"不回答有害问题"，不是微调教的，是预训练就有的，微调只是"激活"了它
• 数据量远小于预训练（因为需要人工标注）

第三阶段：RLHF（人类反馈强化学习）

目标：让模型的回答更符合人类偏好

过程：

1. 模型生成多个答案
2. 人类标注员排序（哪个答案更好）
3. 训练"奖励模型"预测人类偏好
4. 用奖励模型指导主模型优化

效果：模型变得更有帮助、更诚实、更无害

副作用：RLHF训练导致模型"讨好"人类，有时会"太有礼貌"而说废话，有时为避免冲突而给模糊答案。

温度参数（Temperature）

含义：控制模型输出的随机性

模块8：掌握 Cursor——从注释到Agent

你的AI编程伙伴

Cursor的定位：不是代码补全，是你的AI编程协作者。

三种工作模式（详见课程2笔记）：注释驱动 → 提示词驱动 → 目标驱动

让AI填充缺口（Comment-Oriented）

最基础的用法：写注释 → AI补代码

# 读取 CSV 文件，跳过第一行标题，返回二维列表
def read_csv(filepath):
    # Cursor 会自动补全这里

进阶用法：先写函数签名和文档字符串，让AI实现具体逻辑

def calculate_moving_average(data: list[float], window: int) -> list[float]:
    """
    计算移动平均值

    Args:
        data: 原始数据列表
        window: 窗口大小

    Returns:
        移动平均值列表，长度为 len(data) - window + 1
    """
    # AI 实现这里

通过对话优化代码（Prompt-Oriented）

Chat模式的核心用法：

1. 解释代码：选中代码，Cmd+L，问"解释这段代码在做什么"
2. 优化性能：问"这段代码处理100万条记录会有什么性能问题？"
3. 重构：问"把这个函数重构成更面向对象的风格"
4. 生成测试：问"给这个函数写完整的单元测试，要包含边界情况"

Agent模式——Cursor的最强武力

Objective-Oriented Programming（目标驱动编程）：

你不说怎么做，只说要什么结果。

实战案例：日志分析流水线

目标提示词：
当前目录下有一个 raw_logs/ 文件夹，里面有若干日志文件。

请作为 Python AI Builder 帮我写一条自动化流水线 analyzer.py：
1. 读取 raw_logs/ 下的所有文件
2. 提取每个日志的：级别(ERROR/WARN)、日期、错误核心事件
3. 将结果保存为 Audit_Report.md（Markdown表格格式）
4. 代码必须包含详细的中文运行日志（print），告诉我正在处理哪个文件

Agent会：

• 创建 analyzer.py
• 自动运行（如果你允许）
• 如果报错，自动尝试修复
• 最终生成 Audit_Report.md

验证成功的标准：

1. 终端打印出处理进度
2. 左侧出现 Audit_Report.md
3. 文件内容是完整的结构化表格

用规则引导AI行为（.cursorrules）

详见课程2笔记中的详细说明。

用外部工具扩展Cursor能力

接入搜索引擎（让AI能搜索实时信息）：

1. 获取Tavily Search API Key
2. 在项目中定义搜索函数
3. 在.cursorrules中告知AI何时使用搜索

克服局限与最佳实践

Agent模式的局限：

• 目标太模糊时AI会迷失方向
• 遇到复杂错误时可能循环尝试
• 有时会"过度设计"，写出比必要更复杂的代码

最佳实践：

1. 目标要具体：不说"优化这段代码"，说"把这段代码的时间复杂度从O(n²)降到O(n log n)"
2. 提供验收标准：告诉AI"成功的标准是通过这些测试用例"
3. 分阶段进行：大任务拆成小步骤，每步验收后再继续
4. 不要盲目信任：AI生成的代码必须review，特别是涉及数据安全、金融计算的部分