把 AI 当工程工具用：工具、上下文与开发范式入门

写在前面

先给你看个画面。

一台机器人摆在桌上，底盘要走得稳，云台要转得准、还得跟手。搞过的人都懂，把它调到这个状态有多磨人——改一个控制参数，编译、烧录，盯着看它抖不抖、跟不跟得上；不行，再改一个数，再烧录，再看……眼睛粘在曲线上，手在那几个数字之间来回试。光一个 PID 调到满意，一下午就搭进去了。这活我干过太多遍：枯燥、靠手感、没完没了。

但最近这台机器人，是它自己调好的。

我把底盘和云台的控制逻辑、怎么测、还有「什么算调到位」的标准，一股脑交给 AI。然后它自己跑了起来：改参数 → 跑测试 → 读数据 → 判断好坏 → 再改 → 再测……一圈一圈自己迭代，最后停在一组比我手调还稳的参数上。

我干的，就剩在旁边看着，偶尔拍个板。

这就是这篇文章最后想带你抵达的地方——AI 早就不只是陪你聊聊天、帮你写段网页代码了；它能真钻进嵌入式这种又硬又苦的活里，自己测、自己调、自己验证，把人从「无限次重复」里捞出来。这块我放在后面专门讲，网上写得很少，应该能给你些别处看不到的料。

不过，要看懂它是怎么做到的，得先从头说起。

所以，如果你现在还只会打开网页版 AI 聊两句——问点东西、让它写段话、顺手翻译一下，那这篇正是写给你的。我想带你从「会跟 AI 聊天」走到「会让 AI 替你干活」，最后看明白开头那台机器人是怎么回事。这中间差的，不是什么花哨的提问技巧——那玩意儿网上一搜一大把、换个场景又不灵了——差的是你脑子里对 AI 的那点底层认识，和几样能把它接进日常活儿里的工具。

先做个自我介绍

三句话说完。

我是搞嵌入式的——开头那台机器人就是我的。2024 年起认真用 AI，从编辑器插件（Cline、Continue）、AI IDE（Cursor、Trae、Windsurf、Antigravity）到终端 CLI（Claude Code、Codex），市面上每类工具我都真用过、真踩过坑。

这篇就是把这两年的学费换成经验，讲给刚上手的你听。

这篇大概讲什么

我没打算写成那种「50 个提问模板」的合集。想讲清楚的是这么几件事：

AI 到底是个什么东西——这点想岔了，后面全是白费劲；
插件、IDE、CLI 都是干嘛的，以及我为什么最后主要用 CLI；
用 AI 绕不开的两件事：给它喂什么（上下文），和让它想多深；
怎么让 AI 从「图一乐」变成真能帮你干活的——SDD、TDD、上下文工程这些。

压轴是我的本行：拿 AI 干嵌入式的实战经历。这块网上讲得少，应该能给你点别处不太看得到的东西。

致谢

这篇里提到的不少资料，是从 linux.do 上 timerring 那两篇《学 AI，上 L 站！》（2026.03 和 2026.04 版）里翻出来的。看完我这篇，建议你再去啃那两篇原帖，料很足。

第 1 章 · 先搞懂 AI 到底是个什么东西

小白用不好 AI，十有八九不是不会写 prompt，而是脑子里对它的认知就错了。所以这章是全文的地基——先别急着上工具，把「它到底是个啥」想明白。

1.1 先搞明白：AI 到底在干嘛

先问你个事——有没有过这种经历：问 AI 一个具体的技术问题，它答得头头是道，函数名、参数、用法样样齐全，你照着敲下去，结果那个函数压根不存在？

我刚上手那阵子，被这么坑过好几回。后来才想明白：这不怪它「使坏」，是它本来就不按「查资料」那套来工作的。

大模型（LLM，Large Language Model）说到底只干一件事——顺着你给的内容，猜下一个最可能蹦出来的字。它不是翻一本百科全书找答案，而是一个字一个字「算」出一段最通顺的话。把这条吃透，它那些古怪脾气你就全能解释了：

它的特点	说人话	对你意味着什么
猜字，不是查库	答案是「算」出来的，不是「查」出来的	别拿它当标准答案机
会一本正经地胡说（幻觉，hallucination）	不懂也不说「不知道」，直接编个像模像样的	它给的事实、代码、引用，都得你核
知识有「保质期」	训练截止之后的事，它原生不知道	最新版本、刚发生的事，得你喂给它
不擅精确，极擅模式	算术、记事实容易翻车；总结、改写、找规律强得离谱	让它干「理解和改写」，别让它当计算器

一句话记住它的人设：它是个语言天才，不是一本百科全书。

1.2 一个能用到底的比喻：把它当实习生

上面四条记不住没关系，记住一个画面就够——

大模型就像一个聪明、博学、反应飞快，但健忘、没有长期记忆、而且只能「瞄一眼」你递过去的材料的实习生。

聪明、博学 → 它确实能帮你扛不少活；
健忘、没长期记忆 → 对话一关，它就把你忘得干干净净；你不说，它压根不知道你的项目长啥样；
只能瞄一眼你递的材料 → 它当下的判断，全看你这一刻喂给它什么。

这个实习生的比喻，后面几章我会反复用——上下文、思考深度、怎么交代任务，全能往里套。

1.3 顺着这个比喻，你要操心的就三件事

既然它是个「健忘、只看你递的材料」的天才实习生，那「用好它」说穿了就三件事：

给它什么材料 —— 也就是上下文（context）。这是用好 AI 的胜负手，第 3 章专门讲。
让它想多深 —— 简单活让它张口就答，复杂活逼它「先打草稿再下结论」。这个旋钮，后面讲 CLI 实战时细说。
拿什么家伙把它接进你的活里 —— 插件、IDE，还是 CLI？下一章就是这张工具地图。

记住这三件事，后面所有内容都是围着它们转的。

1.4 最该端正的心态：你拍板，它干活

最后定个调，这条比任何技巧都重要：

AI 是副驾驶、是执行者；你才是那个拿主意、并且要对结果签字的人。

它能帮你写、帮你查、帮你改，但它不为结果负责，你负责。所以甭管它说得多笃定：

它给的代码，你得 review；
它给的事实，你得核；
它说「搞定了」，你得真跑一遍、测一遍。

说白了，把它当个需要你审稿的高效实习生，别当成可以闭眼信的专家。光这一条心态摆正，后面一大半的坑你都能绕开。

第 2 章 · AI 工具地图：插件、IDE、CLI，到底怎么选？

搞懂了 AI 是什么，下一个问题马上就来：用什么把它接进你真正的活里？ 市面上的工具看着五花八门，其实就四种形态，从轻到重排一排，逐个拆。

2.1 先把四种工具摊开看

形态	它在哪	代表工具	一句话
网页聊天	浏览器	ChatGPT / Claude / DeepSeek 网页版	复制粘贴，最轻
编辑器插件	你现有的 VS Code / JetBrains	Cline、Continue、Copilot、Augment	在原编辑器里加个 AI
AI IDE	一个独立的编辑器	Cursor、Trae、Windsurf、Antigravity、Qoder	AI 深度缝进整个编辑器
终端 CLI	命令行	Claude Code、Codex、Gemini CLI	能自己读文件、跑命令、改代码

打个比方：网页聊天像隔着窗户问专家；插件像请了个助手坐你工位边上；AI IDE 像把你整个工位换成 AI 工作台；CLI 则是干脆把工程的钥匙交给 AI，让它自己进车间开工。

越往下，AI 能碰到的东西越多、能替你扛的活越重；当然，你要花的学习成本、和「把活交出去」的风险，也跟着变大。

2.2 网页聊天：起点，但别停在这

人人都从这儿起步，零门槛。但它有个迈不过去的坎：AI 看不见你的代码和文件。所有材料靠你复制粘贴喂进去，它改完，你再手动贴回来。

学概念、问问题、写个独立的小片段，它够用；可一旦是真刀真枪的工程——文件一多、改动一大，复制粘贴这套立马就崩。

拿它当 AI 启蒙挺好，别把它当终点。

2.3 AI 插件：最轻的一步「接进来」

在你已经在用的编辑器（VS Code / JetBrains）里装个扩展，AI 当场就能看见你的项目，不用再复制粘贴。

常见的几个：

Cline（开源，自带 Plan / Act 两档——先规划再动手，用你自己的 API Key）
Continue（开源，补全 + 对话，能接任意模型）
GitHub Copilot（最老牌，补全起家，现在也有 Agent 模式）
Augment（主打超强的代码库理解，自研了 ACE 上下文引擎）

还有一类浏览器插件，不写代码，但日常提效很猛：cose（一键把文章同步到 20 多个平台）、md2card（Markdown 转小红书封面）、各种「去 AI 味」的 skill、Kami（GPT 排版）。

好处是几乎不动你现有习惯、轻、大多免费或用自己的 Key。代价是：本事被宿主编辑器框死，自动化和批处理偏弱，多文件大改不太顺手。

说点我的真实感受：Cline、Continue 这类插件，工具太少、生态也不够完善，用起来更像是把网页版 AI 原样搬进了代码环境——它总算能看到你的文件了，但也就到此为止，离”帮你把活干完”还差得远。当个补全和问答工具凑合，真要它挑大梁，撑不住。

2.4 AI IDE：把整个编辑器换成 AI 工作台

不是装插件，而是一个从头就为 AI 设计的独立编辑器。它们大多是 VS Code 的 fork，所以你原来的快捷键、插件、习惯基本能平移过去。

几个代表：

Cursor：这一类的标杆——Tab 智能补全、Composer / Agent 模式，还会给整个代码库建索引做语义检索。
Trae：字节出品，国内访问友好，主打 Builder 模式。
Windsurf：主打 Cascade 智能体和顺滑的「心流」体验。
Antigravity：Google 出品，Gemini 驱动，agent-first，带一个「代理管理」面板。
Qoder：阿里出品，干脆把 TDD + SDD 做成了内置实践（第 5 章会再提）。

它比插件强在哪？一句话：它读的是你整个项目，不是只盯着你当前打开的那个文件——给全库建索引、做语义检索，所以更「懂」你的代码。

对小白它最友好：可视化强、补全顺手、上手快，改了什么 diff 摆在眼前。短板也实在：交互上还是「你坐驾驶座、一步步带它走」，重自动化和批量的活偏弱，订阅一般不便宜，而且你能用到多少本事，得看这家厂商替你封装了多少。

下面是我自己一路用下来的真实复盘，给你避避坑。

AI IDE 本该最大的优点，是”把全球最强的一堆模型集中起来，每个开发环节挑最顺手的那个用”——扬长避短。 可现实是：Claude、GPT 两家几乎独大，多数时候光一个 Claude 就把活全干了，没人真会来回切别的模型。这个”多模型”的卖点，就有点虚。

Cursor 确实是把生态、工具链、可视化做得最漂亮的一个。但最劝退的是价格：Pro 一个月 20 刀，给的就是 20 刀的 API 额度，我用过一阵，真肉疼。

Trae 我算元老级用户了——2025 年 2 月它一发布我就预约进去了，当时图的就是首月 3 刀、额度还和 Cursor 一样。但 Trae 的问题在定位：它瞄的明显不是资深开发者，而是小白。2025 年 7 月推出的 solo 模式我也是第一批内测，那套界面一眼就是给纯新手准备的，想做点定制化的改动反而处处别扭。

真正的转折点，是 Claude Code、Codex 这些 CLI 出来之后——可定制程度高了一个量级，IDE 那点”可视化、上手快”的优势，一下就没那么香了。具体我下一节说。

2.5 AI CLI：终端里的「智能体」

一个跑在命令行里的 Agent。它跟上面三种最大的不一样：它不光是「回答你」，而是能自己读文件、跑命令、改代码、看报错、再回头改，这么一圈圈自检，直到把活干完。

代表是 Claude Code、Codex，还有 Gemini CLI、Aider 等等。

一句话点出区别：前三种，多数时候是你「一句一句指挥它」；CLI 是你「交代一个任务，它自己埋头干一长串」。

我第一次用 Claude Code 那种「次元壁碎了」的感觉，就来自这儿——你交代一句，它自己去翻文件、敲 bash 命令、跑编译、看报错、再回头改，一整套下来不用你插手。前三种工具你还得一步步喂；到了 CLI，它是真能”自己上手把活干完”。

2.6 为什么我最后主推 CLI？

这是这篇里我最想讲清楚的一个判断。不是 IDE 不好（我自己 IDE 和 CLI 混着用），而是当你动真格、把 AI 当工程工具使的时候，CLI 有几样东西是图形界面给不了的：

能编程、能拼装：它是纯文本接口，能写进脚本、塞进构建流程、挂上 CI、用管道跟别的命令串起来。图形界面点不出「自动化」。
跟现有工具链无缝：git、编译器、构建工具、测试框架、调试器……CLI 和它们本来就是一个世界的，拼起来天然顺。
上下文攥在你手里：项目规则文件（CLAUDE.md）、@文件 精确投喂、子代理隔离上下文——它到底看到了什么，你能管得很细（正好接上第 3 章）。
那一整套工程化玩法落地最全：MCP、Skills、Hooks、斜杠命令、SDD / TDD，CLI 这边生态最齐、跑得最顺（第 4、5 章重点讲）。
不被一家绑死：随时换模型，用 MCP 把外部能力（数据库、文档、各种服务）插进来，不绑死在某一个 IDE 上。
每一步都看得见：它跑了什么命令、改了哪些 diff，全摊在终端里——出了岔子好回溯。

除这六条，还有两点小白能立刻体会到的好处。一是轻：一个命令就启动，不用开一个沉甸甸的客户端，可定制程度还高。二是省钱，这笔账值得单算——前面说 Cursor Pro 一个月 20 刀、给的就是 20 刀额度；而现在 GPT Pro 同样 20 刀，Codex 的额度能到 300 刀以上，还白送你一个 GPT 网页版。同样的价钱，一个给 20 刀、一个给 300 刀还带赠品，Cursor 自然就没人留了。这也是 CLI 生态起来之后，天平彻底倒过去的一个现实原因。

顺一句：我是做嵌入式的，上面这些在「重脚本、重工具链、重自动化」的场景下尤其值钱，具体案例放到后面嵌入式那章讲，这里先按下。

不过对小白我得说句实话：CLI 的代价是上手门槛更高、纯文本不如图形界面直观，而且放权一多，新手容易翻车——一口气改乱一大片、把上下文聊爆。所以第 4 章我会专门讲怎么用好它、怎么不翻车。

2.7 一句话选型

你的场景	选什么
纯学习、问概念、写独立小片段	网页聊天
日常写代码、想要补全和可视化、上手快	AI IDE（Cursor / Trae…）
工程化、自动化、批量、重工具链	AI CLI（Claude Code…）

别把这三个当单选题。我自己就是 IDE 写日常、CLI 啃硬骨头，混着来。给小白的推荐路线是：先用网页摸清 AI 的脾气 → 用 IDE 写点小功能 → 再上 CLI。

2.8 上手 CLI：斜杠命令速查（以 Claude Code 为例）

真正开始用 CLI 后你会发现，除了”用自然语言交代任务”，还有一类以 / 开头的斜杠命令（slash commands），专门用来管理会话、上下文、模型、权限这些”元操作”。它们是你驾驭 CLI 的方向盘。

不同 CLI 的命令名略有差异，但思路相通。下面以 Claude Code 为例讲最常用的一组；官方完整列表点下面两个链接直达，强烈建议收藏：

📖 官方斜杠命令完整列表

Claude Code：Commands across a typical workflow

Codex CLI：Slash commands

下面按使用场景分六组。表格第三列「作用」帮你快速记住每个命令”到底在干嘛”。

会话管理

命令	什么时候用	作用
`/help`	不知道有什么命令时	打开帮助和命令列表
`/clear`	想开始一个新任务	清空当前上下文，开始新对话；旧会话还能用 `/resume` 找回
`/compact`	聊太长了，快爆上下文时	把前面的对话压缩总结，腾出上下文空间
`/context`	想看上下文占用了多少	查看当前上下文使用情况和可能的优化建议
`/resume`	回到之前的会话	恢复历史会话
`/exit`	退出 Claude Code	结束 / 退出当前 CLI 会话

最常用的是 /clear 和 /compact。区别是：/clear 是”新开一局”；/compact 是”保留当前任务，但把历史压缩一下”。官方也特别说，如果只是想释放上下文但继续当前会话，用 /compact；如果是开始新任务，用 /clear。

项目初始化与记忆

命令	什么时候用	作用
`/init`	第一次在某个 repo 里用 Claude Code	生成项目用的 CLAUDE.md 指南
`/memory`	想修改 Claude 对项目的长期记忆	编辑 CLAUDE.md 等 memory 文件
`/status`	想看当前状态	查看版本、模型、账号、连接状态等
`/usage`	想看用量 / 成本	查看 session 成本、计划限制和活动统计

/init 很重要。它相当于让 Claude Code 先读你的项目，然后生成一份”这个项目应该怎么协作”的说明文件，之后做任务时会参考它。官方建议首次进入 repo 时先 /init，再用 /memory 调整。

模型、思考强度和计划

命令	什么时候用	作用
`/model`	想切换 Claude 模型	选择或切换模型
`/effort`	想调整推理力度	设置 low、medium、high、xhigh、max 等思考强度
`/plan`	做大改动前	进入计划模式，让 Claude 先规划再动手
`/ultraplan`	超大任务或复杂设计	开一个更深入的计划流程

实际开发时建议你记住：大改动先 /plan，复杂 bug 或架构问题提高 /effort。官方文档也把 /plan 放在”任务执行期间”的常用命令里，用于大改动前先进入计划模式。（这里的 /effort、/plan 其实就是在调”思考深度”——这个旋钮第 4 章里还会细讲。）

权限、工具和外部能力

命令	什么时候用	作用
`/permissions`	Claude 老是问你能不能执行命令时	管理工具权限规则
`/mcp`	要连接 MCP server 时	管理 MCP 服务连接和 OAuth
`/agents`	要用子 Agent 时	管理 agent / subagent 配置
`/skills`	查看可用 skills	列出当前可用技能
`/reload-skills`	新增或修改 skill 后	重新扫描本地 skills / commands

/permissions 非常常用，因为 Claude Code 涉及读文件、写文件、跑命令等操作。你可以通过它配置哪些操作自动允许、哪些要询问、哪些拒绝。官方命令表里也说明 /permissions 用来管理 allow、ask、deny 规则。

看改动、评审代码、回滚

命令	什么时候用	作用
`/diff`	想看 Claude 改了哪些文件	打开交互式 diff 查看器
`/code-review`	提交前检查代码	检查当前 diff 的 bug、简化点、效率问题
`/code-review --fix`	想让 Claude 直接修 review 问题	评审后自动应用修复
`/review`	看 PR	对 Pull Request 做本地 review
`/security-review`	安全敏感改动	检查注入、鉴权、数据泄露等安全风险
`/rewind`	改坏了想回退	回滚对话或代码到某个 checkpoint

这里最实用的是 /diff、/code-review、/rewind。典型流程是：Claude 改完代码后，先 /diff 看变更，再 /code-review 检查，发现改坏了就 /rewind。官方也把 /diff、/code-review、/review、/security-review 放在”发布前”相关工作流里。

后台任务和并行工作

命令	什么时候用	作用
`/background` 或 `/bg`	想让当前 session 后台跑	释放终端，让任务继续跑
`/tasks`	想看后台任务	查看和管理后台任务
`/batch`	大规模代码库改造	把任务拆成多个独立单元并行执行
`/branch`	想从当前对话分叉	基于当前点创建一个 conversation branch

这一组偏进阶，小白初期用不太到，知道”有这么回事”就行：长任务用 /background 丢后台、/tasks 盯着；超大改造用 /batch 拆成并行；想另起一条路又不想弄乱当前对话，就用 /branch 分叉。

你可能注意到了，上面好几个命令——/clear、/compact、/context——都在围着同一个词转：上下文。这恰恰是用好 AI 的胜负手。下一章我们就专门讲它。

第 3 章 · 上下文：用好 AI 的胜负手

先说个你八成遇到过的场景。

跟 AI 聊一个问题，头几轮答得挺好。你接着追问、补需求、改方案，聊到二三十个来回，突然发现它开始犯傻——你前面明明交代过的约束，它忘了；让它改 A，它把好好的 B 给改坏了；甚至重新提起你几轮前就否掉的方案。

不是模型突然变笨了，是它的上下文乱了。

这一章我想说服你一件事：用 AI，七成功夫花在上下文上。 提示词技巧是锦上添花；喂给它什么、怎么喂、什么时候清，才是决定它聪不聪明的那只手。

3.1 先搞懂：什么是「上下文窗口」

回到第 1 章那个实习生比喻——它健忘、没长期记忆、只能「瞄一眼」你递过去的材料。这「一眼能看多少」，就是 上下文窗口（context window，模型一次能读进去的内容量）。

衡量它的单位是 token（词元，模型眼里的最小文字单位）。粗略记：一个 token 约等于半个到一个汉字，或三四个英文字母。一次对话里，你的问题、它的回答、你贴的代码和文档、系统给它的规则——全都挤在这个窗口里，一起算 token。

打个比方：上下文窗口就是它的工作台。台面就那么大，你把资料一摞摞往上堆，堆到放不下了，要么挤掉旧的，要么它就开始手忙脚乱。

3.2 三个反直觉的现象（最容易踩的坑）

知道有个窗口还不够。真正坑小白的，是下面三件和直觉相反的事：

现象	说人话	对你意味着什么
不是塞得越多越好	资料堆太多，夹在中间的反而被读漏	精准喂料，别一股脑全倒进去
它会「失忆」	窗口满了，前面的对话被压缩或丢弃	长对话定期清，别指望它永远记得
重复的前缀更快更便宜	一样的开头能被「缓存」复用	固定内容放前面，别老改开头

一条条说：

现象一：塞太多，中间会被读漏。 这事有个专门的名字，叫 lost in the middle（迷失在中间）——把一长串信息丢给模型，它对开头和结尾记得清楚，正中间那段最容易被忽略。就像你一口气听人念五十条待办，最后能复述的，往往是头几条和最后几条。所以关键信息别埋在一大坨材料的正当中。帖子里那篇《为什么 AI 会”忘记”中间的信息》讲的就是这个。

现象二：窗口满了，它会「失忆」。 对话拖长、超出窗口，系统就得把前面的内容压缩成摘要、或者干脆截掉。表现就是：聊到后头，它把你开头定的规矩忘得一干二净。这不是 bug，是工作台堆满了在清桌子。所以长任务别一条道聊到黑，该 /clear 重开就重开（第 2 章那几个命令正是干这个用的）。

现象三：重复的前缀，又快又便宜。 这条偏底层，但很实用。模型处理你给的文字时，会把算过的部分缓存下来（这套机制叫 KV Cache / Prompt Caching）。要是你每次的开头都一样（比如同一份项目规则），这段就能直接复用缓存，更快，还更省钱；反过来，你老在开头改来改去，缓存就白费了。chaofa《用代码打点酱油》里的《理解 KV Cache 与 Prompt Caching》把这个原理讲得很透。

一句话记住：喂得准，比喂得多重要；喂得稳，比喂得勤重要。

3.3 上下文工程：把「喂料」当门手艺

既然喂什么、怎么喂这么要紧，它就值得被当成一门正经手艺——这就是这两年越来越火的词：上下文工程（context engineering，有意识地组织喂给模型的内容）。

别被这词唬住，对小白来说它就是几条朴素习惯：

只放相关的：这个任务用得上的才放，无关的别塞；
结构化：用标题、列表、分段把材料理清楚，别甩一大坨；
长资料拆开、按需取用：几百页的文档别整本丢，挑相关章节给；
及时清理：一个阶段干完，清掉旧上下文再开新的。

这些不是我拍脑袋想的。做出 Manus 那个 AI Agent 的团队专门写过一篇《构建 Manus 的经验教训：上下文工程》，把「怎么给 agent 组织上下文」掰开揉碎讲了一遍——帖子也把它列为重点推荐。有余力，强烈建议读原文。

3.4 「记忆」不等于「上下文」

讲到这你可能会问：那让 AI 记住我不就行了？建个数据库，把聊过的全存起来，要用再捞——不就有「长期记忆」了吗？

听着很美，但比想象中难得多。

最常见的做法是 向量库 + embedding（把文字转成一串数字，按相似度检索）。问题在于：相似 ≠ 相关，更 ≠ 这一刻该用。光靠「语义相似」去捞记忆，经常捞回一堆看着像、其实没用的东西，反而把上下文搞脏。帖子里那篇《AI Memory 的真正难点：为什么 Vector Store + Embedding 远远不够》专门讲了这个坑。

对小白，记住一个判断就够：「记忆」目前还是个没被很好解决的难题。 别指望 AI 真能像人一样记住你。你能信赖的，永远是当下这个窗口里、你亲手喂进去的东西。

3.5 那到底怎么管上下文？（先点名，第 4 章细讲）

道理说了一堆，落到手上有哪些招？先给你一张「它们各是干嘛的」清单，具体用法放到第 4 章 CLI 实战里讲：

手段	一句话作用
项目规则文件（CLAUDE.md）	把项目的固定规矩写成文件，每次自动喂、还能吃缓存
`@文件` 精确引用	要它看哪个文件就 `@` 哪个，而不是全塞
及时 `/clear`、`/compact`	清理 / 压缩上下文，给工作台腾地方
子代理（subagent）	把支线任务丢给一个独立上下文的「分身」去干，不挤占主线

这几样，正是我后面主推 CLI 的原因之一——它把「管理上下文」做成了你能亲手拧的旋钮，而不是藏在某个黑箱里。

3.6 嵌入式视角：上千页的手册怎么喂？

最后留个我自己领域的钩子。

嵌入式这行，资料动不动就是一份几百上千页的芯片手册（datasheet）。要是把整本 PDF 丢给 AI，正好同时踩中前面两个坑：token 撑爆窗口、关键寄存器说明迷失在中间。

我的做法是反过来——绝不整本丢，只切相关的那几节喂进去，或者让它按需去手册里检索对应章节。具体怎么搭这套流程，我放到后面嵌入式实战那章细讲。

上下文这把「胜负手」讲完了。可光知道喂什么还不够，你还得有把趁手的家伙去喂、去管它——接下来，咱们就动手把 AI CLI 真正用起来。

第 4 章 · AI CLI 实战：把 Claude Code 用起来

前面三章是「想明白」，这章开始「动手干」，以 Claude Code 为主。这章真正的重头戏是「四件套」——CLAUDE.md、MCP、Skills、Hooks，它们才是把 CLI 从「能用」变「好用」的关键，我会一个个掰开讲。前面认识它、跑起来只是热身，后面思考深度、避坑是收尾。

4.1 先认清：CLI Agent 到底是什么（热身）

先把一个误会掐掉：CLI Agent 不是”终端里的聊天框”。

聊天框是你问一句、它答一句，材料你喂、活你自己干。CLI Agent 是另一种东西——你交代一个目标，它自己去跑整个过程：读文件、敲命令、改代码、跑编译、看报错、再回头改，一圈圈自检，直到把活干完才回来交差。

这就是第 2 章那句话落到实处：前三种工具多半是「你一句一句指挥它」，CLI 是「你交代一个任务，它自己埋头干一长串」。 你管”要什么”，它管”怎么弄”。

这种”能自己跑一长串、还自己纠错”的底座，有个专门的名字叫 harness（代理运行框架）。想弄明白它凭什么能稳稳跑完长任务，Anthropic 官方那篇 Effective harnesses for long-running agents 专门讲了这套机制，有兴趣可以啃一啃。

4.2 先跑起来 & 一条铁律（热身）

道理够了，动手。以 Claude Code 为例，上手就三步：

装上：一行 npm install -g @anthropic-ai/claude-code（需要 Node 环境）；
进项目：在你的项目目录里敲 claude 进去，第一件事先 /init，让它把项目扫一遍、给你立一份 CLAUDE.md（就是下面 4.3 那份）；
派个真活：别上来就让它改要紧的逻辑，挑个小而具体的——“把这个文件的报错处理补全""给这个函数加注释”——看它怎么读文件、怎么动手、怎么自检。

跑起来之后，先把一条铁律立住，它比任何技巧都重要——还是第 1 章那句：你指挥、它干活，但验收这一关，永远在你手里。

它改完，先 /diff 看它到底动了哪儿，别无脑点”全部接受”；
它说”搞定了”，你得真跑一遍、测一遍才算数；
拿不准的大改动，先让它 /plan 出方案，你点头再动手。

至于权限模式，新手记住一句：别一上来就开”全自动放行”。 先用”每步问一下”的模式，看清它每个动作再点头；等你摸熟了它的脾气、也信得过某类操作了，再把那些操作慢慢设成自动。手松得太早，是新手翻车第一名。

下面是本章的肉：四件套。 它们一层层把 AI 焊进你的项目——CLAUDE.md 让它懂你的项目、MCP 让它连得上你的工具、Skills 让它会你的流程、Hooks / 子代理让它能自动跑、并行干。

4.3 四件套㈠ · CLAUDE.md：给项目立一份「协作说明书」

先说痛点。 你每开一个新对话，AI 都是”失忆”的：这项目用什么框架、什么编码规范、哪些文件碰不得，它一概不知，你得从头交代一遍。聊一次交代一次，烦不烦？

CLAUDE.md 就是给项目立的一份”协作说明书”——放在项目根目录，每次对话 AI 自动先读它，把”这项目该怎么跟你配合”一次性写明白，往后它一进来就懂。

它还顺手省钱。 这份说明每次都摆在最前头、内容固定，正好吃上第 3 章说的缓存（重复前缀更便宜）。帖子里有人实测，一份组织得当的 CLAUDE.md 能省掉 63% 的输出 token——又快又省。

怎么用 + 怎么构建。 不用手写：在项目里敲 /init，AI 会自己把项目扫一遍、起草一份；之后用 /memory 随时改。里面写什么？就几类：项目结构、编码规范、常用命令、绝对别碰的禁区、还有你想让它用的口吻。一条要诀——写得短而准，别堆成长篇，否则它每次读一大坨，反而把重点稀释了（还是第 3 章那句”喂得准比喂得多重要”）。

（嵌入式一句） 我那个机器人项目也一样，用一份规则文件把”改控制代码前必须先讲方案”这种铁律钉死，AI 想越界都不行——第 6 章细说。

4.4 四件套㈡ · MCP：给 AI 接上「外部世界」

CLAUDE.md 让 AI 懂了你的项目，可它还困在”文本”里——你的数据库、文档、网页、画图工具，它都够不着。MCP（Model Context Protocol）就是给 AI 开的一排标准接口，把这些外部世界一个个插上来。

把它想成 AI 的 USB 口。 插上文档平台，它能直接检索 wiki；插上浏览器，它能自己翻网页查资料；插上数据库，它能查表。在这之前，这些都得你手动搬——切过去看一眼、复制、贴回对话框。MCP 干掉的，就是这趟”复制粘贴的搬运工”。

能插些什么（看几个帖子里的真实用法）。 timerring 那两篇里收了一大把好用的 MCP：有让 AI 画架构图的（用 mcp-chrome 自动控制 Excalidraw 画图），有做代码语义检索、帮它在大项目里精准找相关代码的（morphllm），还有人做了逆向研究专用的……这类合集帖子里一抓一把，直接抄。

怎么用 + 怎么接。 /mcp 管理连接。多数情况你不用自己写——找个现成的 MCP，照说明配一下就接上了。真正进阶的玩法是自己造一个，把 AI 接到你独有的工具、甚至硬件上。

（嵌入式一句） 我就没去找现成的”读手册 MCP”，而是反过来自己写了个 stm32-telemetry-mcp，让 AI 能直接读我单片机的实时数据、在线改参数——等于把它的手伸进了硬件。那台机器人怎么靠它一分钟调好参，第 6 章细讲。

4.5 四件套㈢ · Skills：把一套流程教会 AI 一次，往后它自己会

先别急着抠定义，看几个别人拿 Skill 干的真实活，你就有感觉了——有人封了个 skill 让 AI 一键把写好的文章排版、发上公众号（wewrite），有人封了自动发 X 推文的（x-article-publisher-skill），有人封了文生图（gpt_image_2_skill）、做 GSAP 网页动画的（gsap-skills），还有人整了一整套做 UI 设计、把 Markdown 转成小红书封面的。

一句话：凡是你会反复走同一套步骤的活，都能封成一个 skill，往后一句话让 AI 替你跑完整套。

它到底是什么。 Skill 不是给 AI 灌新知识，而是把你脑子里”碰到这种活、就按这几步走”的隐性经验，写成 AI 能读、能执行的明文流程——等于给它一套”标准动作”，让它别每次即兴发挥，按你的章法来。

怎么用。 /skills 看当前有哪些。你甚至不用记命令——每个 skill 自带一句”什么时候该用我”，AI 一听你的需求撞上关键词，自己就把它调起来了。

怎么自己构建一个（这才是你该学会的）。 说穿了就是写一个 SKILL.md 文件，两部分：

开头一句 description：一身二用——既让人看懂这技能干嘛，又是 AI 判断”该不该触发我”的依据。所以触发场景的关键词一定要写进去（“当用户要发公众号、排版文章时使用”）。
正文一套步骤：第一步、第二步、有什么死规矩，一条条列清——写得越像给新人的操作手册，AI 跑得越准，因为它就照着这个走。

上手就从最小的封起：封个”提交前自检”skill，描述写”当用户要 commit、提交代码时使用”，正文三步——先跑测试、再跑 lint、有问题先报告别急着提交。封这一次，往后每回提交它都自动走一遍。要是懒得从头写，直接把帖子里那些现成 skill 抓来改，比从零写快得多。

（我自己的一点用法） 嵌入式里我封 skill 反着来：装的不是”能力”是”纪律”——比如一个 review 技能，硬性规定它审代码时只准看、不准动手。这类后话留到第 6 章。

4.6 四件套㈣ · Hooks / 子代理 / 斜杠命令：让它自动跑、并行干

前三件让 AI 懂你的项目、连得上你的工具、会你的流程。最后这件，是让它不用你盯着也照规矩跑、还能分头干活。三样东西，挨个说。

Hooks（钩子）：到点必触发，AI 没得商量。

CLAUDE.md、Skill 这些都是”软约束”——规矩写了，但听不听多少要看 AI 自觉。Hook 不一样，它是焊在动作上的开关：你指定”某个事件一发生，就自动跑这条命令”，时间一到就触发，AI 想绕都绕不过。

常挂的几个事件：动手前（PreToolUse）、动完手（PostToolUse）、一轮收工（Stop）。最实用的两个场景——

存了就格式化：AI 一改完文件，自动跑一遍 prettier / black，代码风格永远齐整，不用你提醒；
提交前自动闸一道：要 commit 时自动跑 lint / 测试，没过就拦下来，挡住”带病提交”。

一句话记住它跟 Skill 的分工：Skill 是 AI「想起来用」，Hook 是机制「逼它用」。 真要钉死一条铁律，别只写进 CLAUDE.md 求它自觉——挂个 Hook 最稳。

子代理（subagent）：另开一张桌子干脏活。

回到第 3 章那个工作台——台面就那么大，最怕被一堆中间垃圾占满。子代理就是再支一张桌子：把一件支线脏活（翻遍全库找某个函数在哪被调用、跑一长串搜索）丢给一个”分身”，它有自己独立的上下文，埋头干完，只把结论端回你主桌。中间翻过的几十个文件，一点不占你主线的地方。

/agents 配置，或者直接说”开个子代理去查 X”。它的价值全压在第 3 章那句话上：上下文是稀缺资源，子代理替你把它省下来。

斜杠命令（自定义）：把常走的流程缩成一条命令。

第 2 章 2.8 讲的是内置的 /clear、/diff 这些。这里说的是自己造：把一段你三天两头要走的流程，写成你自己的 / 命令，往后一敲就跑完整套。

怎么造？在 .claude/commands/ 下丢个 md 文件，文件名就是命令名，里头写好给 AI 的指令模板。比如封个 /pr，里面写”看 diff → 按规范写提交信息 → 建 PR”，往后发 PR 一个 /pr 搞定。它跟 Skill 很像，区别在谁来按按钮：Skill 是 AI 撞上关键词自动召唤，斜杠命令是你手动敲——一个被动触发，一个主动调用。

（嵌入式一句） 我那个机器人项目最头疼的，就是长对话聊着聊着 AI 突然”犯蠢”、把前面好不容易得出的结论丢了、反复犯同一个错。后来我靠”独立上下文跑支线 + 把易失结论落盘成文档”这套，让下一个会话秒级恢复现场——背后正是子代理和 Hook 这层思路。第 6 章细说。

4.7 顺手两个旋钮：思考深度 & 上下文

四件套之外，还有两个你天天要拧的旋钮。一个管它想多深，一个管它看见多少——后者就是第 3 章那套，在 CLI 里的落地。

旋钮一：思考深度——该快答的快答，该死磕的死磕。

同一个模型，可以”张口就来”，也可以”先在草稿纸上推演一通再开口”。后者就是扩展思考（extended thinking）：让它把推理过程摊开、想得更深，慢一点、贵一点，但难题上靠谱得多。

怎么拧？

/effort 调推理力度（low → max）：简单活给低档，又快又省；硬骨头给高档。
/plan 让它先出方案再动手：大改动、容易翻车的活，先看方案，别让它直接上手。
模型分层：重活上 Opus（架构、难 bug），日常上 Sonnet，高频小事上 Haiku——好钢用在刀刃上，别拿最贵的模型去干贴标签的活。

一句话：别无脑全开 max。 想得深是有代价的（慢、烧 token），全程拉满，简单任务也陪着你磨叽。

那到底什么时候该开深？给你一个比”难不难”好使的判断——看症状和根因隔了几层。一眼能对上的（写段代码、改个配置）直接干；症状和病根隔着好几层的（查个时序 bug、定位一个偶发崩溃），就得把思考深度拉上去，还得逼它拿数据说话。

旋钮二：上下文——第 3 章那套的落地抓手。

第 3 章讲的”喂得准、喂得稳、及时清”，在 CLI 里就落成三个动作：

@文件：要它看哪个文件，就 @ 哪个，别让它瞎翻、也别一股脑全塞；
/clear：一个任务干完，清桌子再开下一个，别一条道聊到上下文爆掉；
/compact：想接着当前任务、又嫌聊太长了，压缩一下腾地方。

这俩旋钮加上四件套，CLI 才算真”用顺”了。

（嵌入式一句） 我调云台时栽过一个典型：pitch”一推就打到限位”，我让 AI 连诊三轮（先怪 PID、再怪遥控灵敏度）全错，真根因是陀螺仪轴用错、速度环根本是开环的——这种隔了好几层的病，就得开深思考 + 拿实机数据顶；而生成个寄存器赋值这种一一对应的活，开深反而是浪费。第 6 章细说。

4.8 不翻车纪律：新手最容易栽的几个坑

把前面散落的”别翻车”叮嘱收拢成一张表，照着躲就行：

坑	长什么样	怎么不翻车
失控的大改动	一句”重构一下”，它哗哗改了一大片，全乱了	小步走；大改先 `/plan`，看完方案再放行
上下文聊爆	聊太长，它开始忘事、改坏 B 来修 A	勤 `/clear`、`/compact`（第 3 章那套）
幻觉造假	编出一个不存在的函数 / API，还言之凿凿	让它给出处，事实和代码你来核（第 1 章）
不验证就喊 done	它说”搞定了”，你一跑全是错	它说完不算，你真跑一遍、测一遍才算

这几条说到底是同一件事：放权可以，但别撒手。 AI 越能干，你越得守住”验收”这道闸。

（嵌入式一句） 这道理我是拿车换来的——有阵子 AI 一个 pitch 下冲问题修不好，就一个劲儿”再加一层防御判断”，连堆四轮，越堆越乱。最后我把”不准不定位根因就堆补丁”直接写成项目铁律，才摁住它。这种”把 AI 的坏习惯写成制度”的故事，第 6 章有一堆。

4.9 实用周边（知道有这么回事就行）

最后扫一眼周边，新手不急着上，先混个眼熟：

监控面板：像 claude-hud 这类小工具，能把上下文占用、正在跑的工具和 agent、todo 进度摆出来，长任务时盯着心里有数；
省 token：组织好 CLAUDE.md、勤清上下文，本身就是省钱（第 3、4 章都提过）；
模型”降智”鉴别：偶尔你会觉得”它今天怎么变笨了”——可能是上下文聊太长，也可能纯是错觉。有个网站 aistupidlevel.info 专门持续测各家模型的状态，拿不准时可以去对一眼，学会区分是真降智还是自己把料喂乱了。

第 5 章 · 范式开发（Vibe Coding → SDD → TDD → 上下文工程）

大家可以认真看一下链接原文比如vibe-coding-cn，腾讯 [AI Native 研发实战手册]，《从第一性原理思考 Agentic Engineering》，TDD + SDD 实操 Workshop等等优秀文章和视频，这些都是大厂的最新的一些ai一线使用经验，不需要照搬整个体系，但可以先学习一些优秀思路，比如vibe-coding-cn里的道法术器方法论和胶水编程， [AI Native 研发实战手册]利用mcp调用外部知识库等等，内容有很多，我刚刚提到的只是很小一部分。

你心血来潮想做个小工具。不写一行代码，全程跟 AI 说人话：“做个网页，能上传图片、自动压缩、再打包下载。“它哗哗就给你写了出来，一跑还真能用。那一刻你觉得自己会编程了。

然后你说：“再加个批量处理吧。“它又哗哗改了一通——批量是能批量了，可原来好好的单张压缩，悄没声地坏了。你让它修单张，它又把下载整没了。改到第五十个来回，你已经分不清哪儿是对的了。

Vibe Coding 爽在前五分钟，崩在第五十轮。

这一章讲的就是：当你想让 AI 干真活——不是图一乐的小 demo，而是要交付、要维护、不能说崩就崩的东西——人们摸索出了几套越来越”讲规矩”的开发方式，一层层把 AI 从”随手糊”逼成”靠谱交付”。一条线串下来：Vibe Coding（随性）→ SDD（先定规格）→ TDD（用测试焊死）→ 上下文工程（喂料的手艺）。

别被这几个英文缩写唬住，它们说的都是同一件朴素的事：怎么把”我到底要什么”讲得越来越清楚，让 AI 越来越不容易跑偏。

5.1 Vibe Coding：凭感觉，但老手早把它玩出了纪律

先说这个词是什么。 Vibe Coding（凭感觉编程）这词是 Andrej Karpathy 带火的：你基本不碰代码，全程用自然语言”凭感觉”指挥 AI——它写、你看、你说、它改，跟着感觉走。

它的好，是真好：门槛几乎为零，不会写代码也能做出能跑的东西；出活还快，做个 demo、写个一次性脚本，半小时搞定。

它天生缺的，也很要命，就一样：没有标准。 你没说清”做成什么样算对”，AI 每一轮的理解都会飘一点；项目一大、轮次一多，它改 A 坏 B，而你连”对”长什么样都讲不出来——自然没法判断它到底改好了没。

但”凭感觉”不等于”瞎来”。 玩得久的人，早把这件事总结出了章法。GitHub 上有份很火的中文指南 vibe-coding-cn，干脆用”道 / 法 / 术 / 器”四层把它讲透，开篇就甩一句狠话：“规划就是一切。谨慎让 AI 自主规划，否则你的代码库会变成一团无法管理的乱麻。” 摘几条感受下它的味道：

层	讲什么	挑两句
道（心法）	跟 AI 协作的根本态度	”上下文是 vibe coding 的第一性要素，垃圾进垃圾出”；“先结构，后代码”
法（方法）	怎么组织一个项目	”一句话目标 + 非目标”；“接口先行，实现后补”；“文档即上下文，不是事后补”
术（招式）	具体怎么跟 AI 说话	”明确写清能改什么、不能改什么”；“测试可交给 AI，断言人审”；“代码一多就切会话”
器（工具）	拿什么家伙	IDE、终端、版本管理那一套

你品品这几句——它们其实已经悄悄指向了后面三节：“规划就是一切”说的是 SDD，“测试交给 AI、断言人审”说的是 TDD，“上下文是第一性要素”说的是上下文工程。换句话说，Vibe Coding 玩到深处，自己就长出了规矩；下面三套，无非是把这些”经验之谈”进一步讲清楚、做扎实。

所以记住：Vibe Coding 不是错，是用错地方才错。小的、短的、坏了也无所谓的活，拿它飞；要交付、要长期养着的活，就得往下走，把规矩一条条立起来。

5.2 SDD：先把”要什么”写清楚，再让它动手

GitHub 官方那套 SDD 工具 Spec Kit 有句话点得特别准——它说自己是要让你”专注于产品场景和可预期的结果，而不是 vibe coding 每一块、从头乱糊”。这正好接上一节：Vibe Coding 缺的那个”标准”，SDD 就是来补的。

先说这个词是什么。 SDD = Spec-Driven Development，规格驱动开发。一句话：动手写代码前，先和 AI 一起把”要做成什么样”写成一份规格文档（spec）——要哪些功能、边界在哪、什么情况怎么处理、什么算”做完了”。规格敲定，再让 AI 照着它实现。

这事反的是一个老习惯。Spec Kit 说得好：过去几十年”代码为王”，规格文档只是开工前搭一下、写完就扔的脚手架；SDD 把这个剧本翻了过来——让规格变成”活的、可执行的”东西，直接驱动出实现，而不只是写在那儿当摆设。

打个比方：这就像装修先出图纸再施工，而不是让工人凭感觉砌墙——砌歪了砸掉重来的成本，比改一张图纸高得多。

往深一层，写 spec 这个动作偷偷替你做了两件好事：

把”决策”和”执行”拆开了：先想清楚做什么（你主导、跟 AI 反复讨论敲定），再谈怎么写（AI 照着干）。这俩搅在一起，正是 Vibe Coding 乱的来由。
那份 spec 本身就是顶好的上下文：内容稳、结构清，每次喂给 AI 都让它不跑偏——正是第 3 章说的”喂得准、喂得稳”。

怎么上手？ 最轻的做法：用 /plan 让它先出方案，或者直接让它先写一份 design.md，你 review 通过了再放它去写代码。想更系统，就上现成的工具和样板——

Spec Kit：GitHub 官方开源工具包，配一个 specify 命令行，把”写规格 → 出计划 → 拆任务 → 实现”做成了一条能照着走的流程，新手照搬就行。
腾讯 AI Native 研发实战手册：里头讲的 Openspec 思路，是这套在团队级别跑起来的真实样子。
美团《DDD 在点评交易系统演进中的应用》：那么复杂的业务，它把”用例规约”写得明明白白——这种用例规约放到今天，就是一份绝佳的 spec。
Qoder 的 TDD + SDD 实操 Workshop：直接把”规格”做进了自家 Coding Agent，能看到工具厂商是怎么落地的。

绕回那份 vibe coding 指南的话——这一节就是在认真兑现它那句”规划就是一切”。

（嵌入式一句） 我那台机器人就死磕这套：改任何控制代码前，AI 必须先写方案、跟我讨论清楚，“先方案、后代码”被我写成了铁律，它想直接上手都不行——为啥这么死板，第 6 章细说。

5.3 TDD：用测试给 AI 焊一道赖不掉的红线

SDD 解决”做对的事”，紧接着的问题是”把事做对”——怎么保证 AI 写出来的真没毛病？

先说这个词是什么。 TDD = Test-Driven Development，测试驱动开发。它的做法听着有点反直觉：先写测试，再写实现。 先用一段测试代码把”什么样算对”钉死（喂这个输入，就得给那个输出），然后让 AI 去写实现、跑测试，红了就改，直到全绿才算完。

这套跟 AI 简直是天作之合。为啥？回想第 1、4 章反复念叨的 AI 两大毛病：爱自信地交付错东西、没真跑就敢说”搞定了”。测试恰好是一把不吃它嘴炮的尺子——它说 done 不算数，测试绿了才算数。

测试，就是你给 AI 立的、它赖不掉的验收标准。

这事有多大威力，看个数：快手技术团队那篇《采纳率从 3% 到 80%》，讲的就是把智能单测生成这套打磨好之后，AI 生成的测试被开发者真正采纳的比例，从 3% 一路拉到了 80%。

怎么用？ 三步：

让 AI 先写测试，你先把关测试本身对不对——这步千万别偷懒，测试写歪了，下面全白搭；
再让它写实现，自己跑测试；
红了让它自己改，绿了才算交付。

再配上第 4 章那个 Hook——提交前自动跑一遍测试、没过就拦下——这道红线就彻底焊死了，AI 想蒙混都过不去。这一节，也正好兑现了那份指南的”术”：测试可交给 AI，断言人审。

顺带一提，AI 和测试的关系还在往前走：测试不只能”驱动”AI 写代码，AI 还能反过来当测试员——美团那篇 Multi-Agent 驱动的 UI 自动化测试就是这个方向，有兴趣可以深挖。

一句话收一下这俩的分工：SDD 管”做对的事”，TDD 管”把事做对”，俩搭一块儿用最稳。

5.4 上下文工程：这几套底下，是同一件事

讲到这儿，你或许咂摸出味来了——

Vibe Coding 缺的，是上下文里没有”标准”；
SDD 干的，是把”标准”写成 spec 喂进上下文；
TDD 干的，是把”验收”写成测试喂进上下文。

绕了一圈，它们底下是同一件事：有意识地管理你喂给 AI 的东西。 这就是第 3 章那个上下文工程，落到开发流程里的样子。所以这几套不是各自为政的招式，是同一个道理的不同切面——也正是那份 vibe coding 指南最看重的那句：“上下文是第一性要素，垃圾进，垃圾出。”

想把”为什么”想得更透，推荐读一篇硬的：《从第一性原理思考 Agentic Engineering》——它把”跟 agent 协作到底在跟什么打交道”从根上捋了一遍，读完你会更明白这几套规矩为啥不是瞎讲究。再配两篇落地的：做出 Manus 的团队那篇《构建 Manus 的经验教训：上下文工程》（第 3 章也推过），还有 Stripe 的 AI 工程最佳实践。

说到底，从 Vibe 到 SDD 到 TDD，看着是”越来越麻烦”，其实是你在一点点把”我要什么、什么算对、怎么才不跑偏”从脑子里掏出来、写下来、交给 AI。AI 越强，这件事越值钱——模型一代代换，但”把要求说清楚”这门手艺，不会过时。

5.5 一张表收尾：到底该用哪套

玩法	适合干什么活	一句话
Vibe Coding	demo、一次性脚本、试想法、坏了也无所谓的小东西	图快，别图稳
SDD	功能稍大、要维护、要跟人 / 跟多轮协作	先把”要什么”写清楚
TDD	逻辑必须正确、不能改着改着就回退	用测试焊死对错
上下文工程	上面全程都要	喂得准、喂得稳

给小白的话，别一上来就全套伺候、把自己累垮。一步步加规矩就行：先用 Vibe Coding 找找跟 AI 协作的感觉 → 活儿大一点了，试着先写两句 spec 再让它动手 → 等碰上要紧的逻辑，再补上测试。一步一个台阶，你和 AI 的配合就从”图一乐”慢慢变成了”靠得住”。

—— 未完待续 ——

后续章节：

第 6 章 · 我的嵌入式 AI 实战。
第 7 章 · Markdown 文档与 Git 的使用。
第 8 章 · 使用 Obsidian 构建知识库。
第 9 章 · 避坑清单 & 上手路线。
第 10 章 · 资源索引（致谢 + 分难度精选）。