AI 课程

有两个习惯比任何工具都重要。第一，核实结果：AI 给出的回答、图片或代码修改，在你阅读、测试或与资料对照之前，都只是草稿。第二，保护机密：绝不要把密码、API 密钥或他人的个人信息粘贴到聊天、提示词或要分享的文件里。API 密钥（程序使用 AI 服务时出示的秘密钥匙）应该放在环境变量里，或放在 .env 文件（只保存在你自己电脑上的设置文件）中，绝不能保存（提交）到 Git。Git 会在第 13 章学到。

还有几个词：

• 幻觉——说得很肯定、却是错的或编出来的回答，所以你一定要核实。
• API——一扇门，让你自己的程序发送提示词并拿回回答，通常需要一个秘密的 API 密钥。
• 聊天机器人和智能体——聊天机器人只会回答，而智能体还能行动：读取文件、运行命令、使用工具，一步步朝着目标前进。
• 开放模型和闭源模型——开源模型，或公开了权重的模型（开放权重），都可以下载到你自己的电脑上运行。闭源模型只能通过公司的应用或 API 使用。

• Google — Machine learning glossary

大语言模型（LLM）只是 AI 的一种。许多文本生成 LLM 根据可用上下文预测下一个词元。图像生成器、分类器和规则系统可以采用不同机制。语言流畅不证明系统有生命，也不证明内容正确。

• NIST — Generative AI profile

角色设定可以引导语气，但不赋予专业能力，也不保证遵从指令。必要时要求来源，并核对它是否支持结论。用相同案例比较两种提示词。只提供必要信息；清晰的提示词有帮助，但无法消除模型的全部局限。

• Transformers — LLM tutorial

把提示词当作草稿。读一读回答，找出缺了什么或错在哪里，然后把正好那一点加进提示词：“用更简单的词”“给出三个选项”“注明来源”。

• 遇到难的任务，让模型先计划，再回答。
• 或者把任务拆成几个小提示词。
• 对于编程智能体，把长期不变的部分（规则、命令、风格）放进 CLAUDE.md 或 AGENTS.md 这样的项目文件里。这样就不用每次都重复。

• Anthropic — Prompt engineering overview
• OpenAI — Prompt engineering

实验室使用简单的词级分割，不是生产级 LLM 分词器。ID 只是标签：ID 8 的含义不是 ID 4 的两倍。上下文窗口限制模型可处理的词元数，应用可能选择、摘要或舍弃材料。

• Transformers — Tokenizers

现代语言模型（Transformer）用注意力机制把上下文中其他词元的信息混合进来（第 33 章会学到），因此同一词元的表示可随句子变化。相似度不保证事实正确或意义相同。“国王 − 男人 + 女人”只是某些词嵌入的示例结果，不是通用等式。检索时应在兼容的嵌入空间中比较查询与文档向量。

• Attention Is All You Need

微调会改变模型权重；LoRA 可冻结基础权重，只训练较小的适配矩阵。RAG（检索增强生成）检索资料并作为上下文提供，不必更新权重。BM25 使用词项匹配、词频饱和与文档长度归一化；嵌入检索比较学习得到的向量。两者都可能漏掉证据或检索到误导文本。一次聊天不会自动等于一次训练更新。

• Attention Is All You Need
• Retrieval-Augmented Generation
• LoRA

在构建器中多次比较贪心与采样。采样也可能重复同一结果。真实系统的模型版本、上下文、工具及数值计算也有影响，因此温度为零不保证完全相同的输出。再比较模糊问题与包含目标、背景、检查方式的问题。用原始来源核实事实，并借助提示用自己的话解释结果。

• Transformers — Generation strategies
• PyTorch — Reproducibility

语言模型预测的是“可能出现的文字”，所以回答再流畅也可能是错的。请它给出来源并亲自打开看，把数字和原文对照，并让模型列出它做了哪些假设。重要的事实，要再找一个独立的来源核对。保存的指令和项目功能能让 ChatGPT 记住你的偏好，但那仍然只是指令，不是保证，所以要一直核实。

• OpenAI — Prompt engineering

生成的图片里常藏着小错误：写错的字母、多出来的手指、不可能出现的影子。一定要放大检查。不要用生成的图片假装某件事真的发生过；未经许可，不要模仿在世艺术家或真实人物；在需要说明的场合，要说明图片是用 AI 做的。商业使用前，请先阅读工具的使用条款。

• OpenAI — Image generation
• Google — Gemini image generation

在 AI 工具里面，以斜杠开头的命令用来控制工具本身：

• /init——写一个项目指令文件。
• /help——列出所有命令。
• /clear——开始一段新的对话。
• /exit——退出工具。

Shell 课程的第 11 单元讲怎样安装 AI 编程工具，并用 --version 检查它们。安装命令会变，所以要和官方页面对照。按 Ctrl+C 可以停止还在运行的命令。当 AI 智能体提出要运行一条命令时，先读一遍再允许。rm 会立即删除，没有回收站；rm -rf 会不经询问就删除一个文件夹里的所有内容。

• The Linux command line for beginners

在 GitHub 上，用 issue 描述任务，用分支在不影响主代码的情况下做事，用拉取请求进行审查。含有私人内容的仓库要设为私有，绝不要提交 .env 文件或密钥；一旦推送上去，就要当作已经泄露，并立即更换密钥。Codex 和 Claude Code 也能发起拉取请求，但合并之前必须由人来读一遍 diff。

• GitHub — Hello World

有三个 NumPy 概念贯穿整门课：

• shape — 有几行几列
• 广播（broadcasting）— 运算会自动扩展到整个数组
• 向量化运算 — 直接对整个数组计算，而不是写 Python 循环

本章的示例都在浏览器里运行。如果要在自己的电脑上运行，请安装 Python 3，用 python3 -m venv .venv 创建虚拟环境，用 source .venv/bin/activate（Windows 上是 .venv\Scripts\activate）启用它，再用 pip install numpy 安装 NumPy。

• NumPy — the absolute basics for beginners

下面的例子执行人写的规则。修改分数或阈值，并在运行前预测结果。return 向调用者返回值，print 只显示值。测试分数恰好等于阈值等边界情况。这个规则程序没有学习步骤。

• Python tutorial

你仍然是开发者。接受每处修改之前都要读一遍，每完成一个能用的步骤就提交到 Git，这样随时可以退回去，还要用真实的手机宽度测试。绝不要让智能体把密码或 API 密钥放进页面——主页是公开的，里面的一切都能被人看到。页面能用了，就可以发布了：下一章会用 Cloudflare 把它放到互联网上。

• MDN — Your first website

你发布的一切都是公开的，所以要检查文件夹里没有密钥、私人笔记或 .env 文件。

每次部署都有自己的预览地址，正式地址显示的是最新的一次，所以你可以先测试再分享。像 myname.com 这样的自定义域名，以后可以在控制台里添加。

你可以让编程智能体去运行部署命令，但要先读一遍，而且绝不要把你的 Cloudflare API 令牌粘贴到聊天里。

• Cloudflare Pages — Direct Upload
• Cloudflare Pages — Git integration

发布要经过几条测试轨道：内部测试、封闭测试、开放测试和正式版。新的个人开发者账号必须先进行一次封闭测试，至少 12 名测试者连续 14 天保持参与，之后才能申请正式版发布权限，所以要早点安排测试者。每次发布都要经过 Google 审核，每次更新都需要更高的版本代码。规则和界面会变，所以请对照本章旁边的 Play Console 官方帮助操作。

• Play Console Help — Testing requirements for new personal developer accounts
• Flutter — Build and release an Android app

每个上传的构建版本都可以先进入 TestFlight，让测试者在公众之前安装。当你提交发布时，Apple 的 App 审核会按照它的准则检查应用。常见的被拒原因：

• 应用崩溃，或者有占位内容。
• 缺少隐私详情。
• 有登录，却没给审核人员测试账号。
• 用了第三方登录，却没有同等的、保护隐私的选项，比如 Sign in with Apple。
• 应用只是把网站包进一个 App 里，几乎没什么可做的（最低功能规则，准则 4.2）。

读一读被拒的消息，正好修好那一点，再重新提交。

• App Store Connect — Workflow
• App Review Guidelines — 4.2 Minimum functionality
• Flutter — Build and release an iOS app

子智能体是主智能体为工作中的某一部分启动的帮手。它有自己全新的上下文窗口。所以它可以读很多文件或大范围搜索，只把结论报告回来，让主对话保持简短。子智能体也可以在互不相关的部分上同时运行。

• 放在哪里 — 在 Claude Code 里，子智能体是 Markdown 文件，写有名称、说明、允许使用的工具和指令。放在 .claude/agents/（项目用）或 ~/.claude/agents/（你自己用）里。
• 怎么用 — 给子智能体一个范围很窄的任务，只给它需要的工具。它的报告仍然是需要你核实的草稿。

• Anthropic — Building effective agents
• Claude Code — Subagents

好的编程请求要具体：改什么、在哪些文件里改、改完之后应该怎样运行，以及怎样核实（一个测试、一条命令、一组示例输入和输出）。任务比较大时，先让它给出计划。Codex 完成后，阅读 diff，自己运行测试，只提交你看得懂的内容。codex exec 可以不打开交互界面直接执行任务，在脚本里很好用。

• OpenAI — Codex
• AGENTS.md

Claude Code 在编辑文件或运行命令之前会先询问你，你可以决定某个操作只允许一次、在本次会话中允许，还是始终允许。权限规则保存在 .claude/settings.json 中；计划模式（plan mode）让 Claude Code 只读取并提出计划，不做任何修改。一开始设得严格一些，只放开你信任的操作，绝不允许你看不懂的命令。

• Claude Code — Overview
• Claude Code — Memory (CLAUDE.md)

给智能体自我核实的手段：测试、一条必须成功的命令，或一个正确输出的示例。如果会话走偏了，按 Esc 停下，说明哪里不对，或者用 Git 撤销后重新提出请求；会话太长会积累让人混乱的上下文，用 /clear 可以从头开始。对于经常重复的工作，把步骤保存成一个技能（见“智能体技能”一章）。

• Claude Code — Common workflows

了解三个智能体很有用，因为每个模型都有不同的长处和盲点。一个好习惯是交叉检查：让一个智能体做修改，让另一个审查；或者让几个智能体分别分析同一个问题再比较——它们意见不一致的地方，你就亲自打开文件来判断。把所有智能体共用的项目规则放在 AGENTS.md 里，很多智能体都会读它，这样它们就会遵守同样的指令。

• Antigravity — Getting started (CLI)

• Agent Skills
• Claude Code — Skills
• Agent Skills — Specification
• Agent Skills — Quickstart
• Agent Skills — Example skills
• SONUB skills — gp
• GitHub Docs — About Projects
• GitHub CLI — gh project

智能体能做的事越多，你的指令就越重要：

• 只给它需要的文件夹。
• 说明它不能做什么（删除、发送、购买）。
• 让它在不确定时停下来问你。
• 把结果和原件对照检查。

软件团队有一个很有用的习惯叫交叉核对：把同一个问题交给两个或更多 AI 工具，比较它们的回答，根据证据而不是多数意见来做决定。SONUB 自己的开发者就是这样工作的——一个问题同时交给好几个 AI 模型，然后在源文件中逐条核实每个说法。

• Claude — Get started with Cowork

循环好不好，全看终点线。“让它更好”永远没有尽头；“tests/ 里的所有测试都通过，页面加载没有错误”就能检查。

一定要设上限，否则循环可能整夜运行，白白花钱：

• 最多几轮
• 一个只有在真的完成时智能体才能说的完成语
• 一个词元预算

在一个新的 Git 分支上启动循环，把项目规则放在 CLAUDE.md 或 AGENTS.md 里，并亲自检查结果。智能体说“完成了”只是一个说法，不是证明。

• OpenAI Cookbook — Using goals in Codex
• Claude Code plugin — Ralph Loop

整夜运行的智能体需要护栏：

• 给它一个有终点线和上限的明确目标。
• 让它在一个分支上运行并提交，这样你第二天早上就能审查它的工作。
• API 密钥放在环境变量里，绝不放进仓库，并在你的 AI 服务商那里设置消费上限。
• 保护好服务器：只用 SSH 密钥、开防火墙、定期更新。

用 tmux attach 或读 Git 日志来查看会话情况，用 Ctrl+C 或 tmux kill-session -t agent 来停止它。

• tmux — Getting started

神经元可先计算 z = w·x + b，再应用激活函数。sigmoid 将有限实数映射到 0 与 1 之间，但它只是一种激活函数，并不是所有神经元的定义。其他网络也使用 ReLU 或 GELU。实现 sigmoid 只是实现一个部件，不等于训练好了网络。后续任务引入从数据拟合的模型，通过示例只是检查点，不是泛化能力的证明。

• scikit-learn — Linear regression

邻居数 k 和树深是拟合前选定的超参数，回归系数则可由训练学习。用验证集或交叉验证选择设置，将测试集留作最终评估。反复根据测试结果调参，会让评估过于乐观。报告划分方式、基准模型、分数和错误案例。一个小型 Iris 实验只是入门项目，不证明模型适用于所有群体和任务。

• scikit-learn — Common pitfalls
• scikit-learn — Iris dataset

损失衡量的是模型对真实的下一个字符有多“意外”——也就是它给出的概率取对数后再取负的平均值。完美的模型损失为 0。真正的 LLM 使用由多个字符组成的词元，并且会看长得多的上下文，但循环是一样的：文字 → ID → 下一个词元的概率 → 挑一个 → 重复。

• Andrej Karpathy — makemore

看着损失随步数增加而下降：网络正在学习。生成的文字现在能组成真正的单词，因为它看到了更多上下文。温度控制生成时有多“大胆”——小于 1 会选更稳妥的字符，大于 1 会更冒险。大型 LLM 有数十亿个权重，用 GPU 在海量文字上训练，但每一步训练都是同样的思路。

• Bengio et al. — A Neural Probabilistic Language Model

这段代码完全用 NumPy 训练一个上下文为八个字符的注意力头，并打印最后一个字符的注意力权重，让你看到它依赖前面哪些字符。真正的 Transformer 会堆叠很多层，每层有很多个头，还会加上前馈层和归一化，并用 Adam 这类优化器在多得多的文字上训练。其余的一切——词元、嵌入、softmax、损失、梯度下降和采样——你现在都已经亲手做出来了。

• Attention Is All You Need

训练就是重复同一个步骤：

• 取一批文字。
• 预测每一个下一个词元。
• 衡量误差（损失）。
• 把每个参数稍微调一调，让损失变小。

盯住两个数字：训练损失，以及在模型没见过的文字上的验证损失。如果只有训练损失在下降，说明模型在死记硬背。训练结束后，你会得到一个保存了所有参数的检查点文件。

在 Mac 上用 mps 设备，在 NVIDIA 显卡上用 cuda，其他情况就用 cpu 并把模型做小一点。本章之前的浏览器章节已经用 NumPy 亲手搭过同样的部件；在这里，你会按真实的规模使用它们。

• Andrej Karpathy — nanoGPT
• Andrej Karpathy — nanochat
• OpenAI — Language Models are Unsupervised Multitask Learners (GPT-2)

运行器的区别在于它们在哪里运行、能读哪些文件格式：

• PyTorch——直接运行你的训练检查点。
• llama.cpp——在电脑和手机上运行 GGUF 文件；Ollama——在电脑上运行。
• 浏览器和手机——还可以使用 ONNX（很多工具都能读取的模型格式），或 Apple（Core ML）和 Google（LiteRT）自己的运行时。

很多运行器都提供本地 API，所以你自己的应用可以和你电脑上的模型对话，就像和云端 API 对话一样——不需要密钥，数据也不会离开这台机器。你的 nanoGPT 检查点经过一步转换后，就能在这些引擎里运行，下一章就做这件事。

• llama.cpp
• Ollama — API

要在手机上用它，有两种方法：

• 快捷的方法 — 把 GGUF 文件复制到一个已经内置运行器的应用里，比如 PocketPal AI，然后离线聊天。
• 开发者的方法 — 把运行器放进你自己的应用。例如在 React Native 应用里用 llama.rn，或在 Flutter 应用里用 llama.cpp 的绑定。随应用附带或下载模型文件，再从你的代码里调用它。

一切都留在手机上，所以没有网络也能用，数据也能保持私密。但它比云端慢，还耗电，所以要让提示词短一些、模型小一些。还有一种方法是把运行器留在你的电脑上，让手机通过同一个 Wi-Fi 调用它的本地 API。这样更简单，但只有在那台电脑附近才能用。

不要把“把模型嵌入应用”和嵌入向量（也就是嵌入那一章讲的向量）搞混。手机上的小型嵌入模型也可以用来搜索你自己的笔记。

• llama.cpp — quantize
• PocketPal AI
• llama.rn

展示和代码一样重要：展示你的计划、AI 出错的一个时刻以及你是怎样发现的、你做过的测试或核查，以及你下一步打算做什么。要如实说明——哪些部分是你写的，哪些是 AI 写的，你又是怎样核查它们的。