第八部分 · 学会指挥 AI 开发
前面七部分，我们一路「边做边学」，从一个静态页面做到了会拆解任务的 AI Todo。你可能一直有种感觉：好像每一步都在用同一套「套路」跟 AI 打交道，但说不清那套路到底是什么。这一部分，我们回头把这套手艺说透——它不是 Todo 专用的，而是可以复用到你以后任何项目上的一套工作流。
关于这一部分怎么用
前面你学的是「怎么做出 AI Todo」，这一部分学的是「怎么指挥 AI 做出任何东西」。所以这里几乎不出现新代码，我们做的事情是复盘：把你前面已经反复用过的动作，一个个拎出来，讲清楚它为什么有效、怎么做才更好。
贯穿这一部分的，还是那句老话——选择题 + 判断题：
- 描述需求、拆分功能，是在做选择题：从脑子里模糊的一堆想法里，选出清晰的一条路交给 AI。
- 看结果、反馈错误、验收功能，是在做判断题：AI 交货了，你判断对不对，不对就打回。
读完这一部分，你大概会有个恍然大悟的感觉：原来我前面一直在用的，就是这么一套东西。
42. 如何描述需求
这一章要解决什么问题
指挥 AI 的第一步，是开口说清楚你要什么。这听起来简单，却是初学者最容易翻车的地方——不是 AI 不够聪明，而是你没把话说清楚。这一章教你，把脑子里那团模糊的想法，说成 AI 能直接执行的清晰需求。
这是什么：把「模糊的想法」翻译成「清晰的需求」
你脑子里想的，往往是一种感觉：「我想要一个能帮我管任务的东西」。但 AI 不能执行「感觉」，它需要具体。描述需求，就是把感觉翻译成具体：要什么页面、放什么按钮、点了之后发生什么。
💡 打个比方：你去理发店，只说「给我剪个好看的」，多半会失望；说「两边推短、上面留长、刘海不要盖眼睛」，才更可能得到你想要的。跟 AI 说需求，就是跟理发师说要什么发型——越具体，越不会翻车。
为什么需要认真对待这一步
因为 AI 是「你说什么，它做什么」。你说得含糊，它就只能猜；它一猜，就可能猜偏。你把含糊的需求丢给它，它给你一个含糊的结果，然后你俩来回返工好几遍——这些返工，本来在你把需求说清楚的那一刻就能省掉。
一个关键点：说清「要什么」，也要说清「不要什么」
初学者常常只说「要什么」，忘了说「不要什么」。而在 AI 开发里，「不要什么」往往和「要什么」一样重要。
还记得我们做第一个 Todo 页面吗？那次的需求里有一句关键的话：「先不要实现任何点击功能，不要接后端，不要加数据库。」
这句「不要」为什么重要？因为如果不说，AI 很可能「热心」地一口气帮你把功能、后端、数据库全做了——结果就是一次给你一大坨你还没准备好验收的东西。你说清了「这次不要碰这些」，它才会乖乖只做你这一步想要的。
在 Todo 里怎么用：好需求 vs 坏需求
我们拿「给 Todo 加一个添加任务的功能」举例，感受一下差别。
坏需求（含糊，AI 只能猜）：
帮我把这个 Todo 做得能用一点。「能用一点」是什么意思？加任务？删任务？存起来？AI 完全摸不着头脑。
好需求（具体，还划了边界）：
在现有的 Todo 页面上，加一个「添加任务」的功能：
在输入框里打字，点「添加」按钮后，这条任务出现在下面的列表里，输入框清空。
这次只做「添加」，先不要做删除和标记完成，也先不要接后端存储。看出来了吗？好需求把「要什么」（打字→点添加→出现在列表、输入框清空）和「不要什么」（不做删除、不接后端）都说清了。AI 拿到这样的需求，几乎不用猜。
如何做好这一步
给你三个自检问题，说需求前对着问一遍：
- 要什么：我想要的结果，用一句大白话能说清吗？（「点添加，任务出现在列表里」）
- 不要什么：这次有没有我故意不做的部分？说出来。（「这次不接后端」）
- 有没有具体到能验收：说完之后，我能不能一眼判断出「做到了没有」？如果不能，说明还不够具体。
本章小结
描述需求 = 把模糊的感觉翻译成具体的、能验收的话，并且同时说清「要什么」和「不要什么」。这一步多花一分钟，后面能少返工半小时。
43. 如何拆分功能
这一章要解决什么问题
需求说清了，但如果需求太大，照样会出问题。这一章讲一个贯穿全课的核心手艺：把大功能拆成一次一小步。
这是什么：把「一个大目标」切成「一串小步骤」
拆分功能，就是别指望一口吃成胖子，而是把大目标切成一小步、一小步，每次只让 AI 做一小步。
回想我们整门课的路线图——静态页面 → Vue 应用 → 后端 API → 数据库 → AI 拆解……这本身就是一次大拆分。我们从没在第一天就想做出完整的 AI Todo，而是先只做一个静态页面，先不接后端。
为什么需要小步走：一个反面例子
来看一个初学者最爱犯的错误——把所有东西塞进一个需求里：
帮我做一个完整的 AI Todo 系统，要有前端界面、后端接口、数据库、
用户登录、AI 自动拆解任务，最后还要部署到云上让别人能访问。这个需求本身没写错，问题是它一次做了太多。会发生什么？
- AI 给你哗啦啦生成一大堆文件和代码，你根本没法验收——出问题了都不知道是哪一块出的。
- 中间任何一环有 bug，整个东西都跑不起来，你连「先看到一点结果」的机会都没有。
- 你想改其中一小块，牵一发动全身，越改越乱。
对比一下我们真正的做法——先只做一步：
先只做一个静态的 Todo 页面：有标题、输入框、添加按钮、几条示例任务。
这次先不接后端、不做数据库、不加 AI。一步做完，浏览器里能看到、能验收、能建立信心，再走下一步。
小步走的两个真正好处
💡 为什么小步走这么关键？两个字：好验收、好修改。
- 好验收：一次只加一个功能，做完你一眼就能判断「这个功能对不对」。一次加十个，你根本分不清是哪个坏了。
- 好修改：小步的代码量小、牵扯少，想改、想推翻重做，成本都很低。大步一旦做歪，改起来能让你崩溃。
在 Todo 里怎么用
还记得「AI 帮你拆解任务」那个功能吗？我们当时也没有一口气做完，而是拆成了更小的步：先让 AI 能接收一句话、再让它返回拆好的子任务、再把子任务显示到页面上、最后才考虑分类和优先级。连「让 AI 拆任务」这件事本身，我们都是一小步一小步做的。
这就是拆分的精髓：当你觉得一步「有点大、有点虚」的时候，就再把它拆小一点，直到每一步都小到你能轻松验收为止。
如何做好这一步
拆功能时，对着这三个问题检查：
- 这一步能单独看到结果吗？（能，就是好的一小步；不能，可能还是太大）
- 这一步做完，我能一眼验收吗？（能验收才算合格的一步）
- 我是不是想一次做太多了？（如果需求里出现好几个「还要」「并且」，警惕，该拆了）
本章小结
大功能一定要拆成一次一小步。判断一步拆得够不够小的标准就一条：做完能不能单独看到结果、能不能一眼验收。小步走，是初学者最该守住的纪律。
44. 如何给 Claude Code / Codex 下任务
这一章要解决什么问题
需求想清了、功能拆好了，接下来就是正式把任务交给 AI。前面每一章我们都在用一个「任务提示词模板」，这一章把它正式讲透——为什么长这样，每一项该怎么写。
这是什么：一个五段式的任务模板
回看前面，你会发现我们发给 AI 的任务，几乎都是同一个格式：
任务目标：<这次要做成什么>
当前状态：<现在是什么情况>
限制条件：<这次不要碰什么、用什么方式>
期望结果：<做完之后我应该看到什么>
验收标准：<我拿什么来判断做到了没有>这五段，就是我们全程指挥 AI 的「标准公文格式」。别嫌它啰嗦——正是这点结构，让 AI 少猜、让你好验收。
为什么每一项都重要
一项一项拆开说，你就明白它们不是凑数的：
- 任务目标：告诉 AI 这次要做成什么。它是整个任务的方向，写不清，后面全跑偏。（对应「做选择题」：你选定了这次要走哪条路）
- 当前状态：告诉 AI 它接手时是什么情况。「现在页面只有标题」和「现在已经能添加任务了」，AI 的做法完全不同。不说清现状，它可能重复劳动，甚至把你已有的东西覆盖掉。
- 限制条件：告诉 AI 这次不要碰什么、用什么方式。这就是上一章说的「不要什么」，它帮你守住「小步走」的边界，防止 AI 热心过头一次做太多。
- 期望结果：告诉 AI 做完之后你应该看到什么。它是你和 AI 之间的「验收约定」——你俩先说好「怎样算做完」。
- 验收标准：把「期望结果」变成一条条能打勾的清单。这一项是你做「判断题」的答题卡，做完照着逐条核对。
💡 你发现没有？前三项（目标、现状、限制）是在帮你做选择题——把这次要走的路选清楚；后两项（期望结果、验收标准）是在为判断题做准备——提前写好答案，等会儿好对答案。一个模板，把选择题和判断题都安排上了。
在 Todo 里怎么用：一个完整范例
我们以「给 Todo 加删除功能」为例，写一份规范的任务：
任务目标：
给现在的 Todo 应用加一个「删除任务」的功能。
当前状态：
页面已经能添加任务、任务能显示在列表里，也能标记完成，但还不能删除。
限制条件：
这次只做删除，不要改动添加和标记完成的现有功能；
先不用接后端，删除只需在当前页面生效即可。
期望结果：
每条任务右边有一个「删除」按钮（或叉号），点了之后这条任务从列表里消失，
其他任务不受影响。
验收标准：
1. 每条任务都有删除按钮。
2. 点某条的删除，只有这条消失，别的还在。
3. 添加、标记完成这些老功能还能正常用，没被弄坏。
4. 页面不报错。对照上一节看：目标（加删除）、现状（能加能标记、不能删）、限制（不动老功能、不接后端）、期望结果（点删除→这条消失）、验收标准（四条可打勾）——五段齐活，AI 几乎不用猜，你也拿到了现成的验收清单。
如何做好这一步
- 五段尽量都写，哪怕某段只有一句话。缺了「当前状态」，AI 容易搞错起点；缺了「验收标准」，你验收时容易漏。
- 验收标准里，一定放一条「老功能没被弄坏」。AI 改新功能时偶尔会碰坏旧的，这条帮你兜住。
- 写完自己念一遍：「如果我是 AI，照这段话我知道该干嘛、也知道怎样算干完了吗？」 答得上来，就是一份好任务。
本章小结
给 AI 下任务用五段式模板：目标、现状、限制、期望结果、验收标准。前三段帮你把选择题选清楚，后两段帮你把判断题的答案先写好。这个模板，值得你背下来。
45. 如何看运行结果
这一章要解决什么问题
任务交出去，AI 干完了，接下来轮到你看结果。这一章告诉你：结果都藏在哪几个地方、每个地方该看什么、什么信号代表成、什么代表出了问题。
这是什么：「看结果」就是在做判断题
前面反复说「你负责判断结果对不对」，具体怎么判断？就是去看。而 AI 开发的结果，主要藏在三个地方：
- 浏览器页面：你能用眼睛看的那个界面。
- 命令 / 终端输出：那个黑框里 AI 或程序打印出来的文字。
- 功能行为：你实际去点、去操作，看它反应对不对。
学会看这三处，你就有了做判断题的「三只眼睛」。
三种结果分别怎么看
① 浏览器页面（前面「在浏览器查看结果」那章练过）
- 成功的信号：页面正常打开，该有的标题、按钮、列表都在，布局整齐。
- 出问题的信号：页面空白、元素错位、内容不对。这时按
F12打开控制台，红色报错就是线索。
② 命令 / 终端输出
你启动服务、跑命令时，黑框里会滚出一堆字。你不需要看懂每一行，只要认几个关键信号：
- 成功的信号：出现类似
running on http://localhost:xxxx、Server started、Compiled successfully这样的字样，通常代表跑起来了。 - 出问题的信号：出现
Error、Failed、Traceback、大段红色文字，通常代表出错了。
💡 一个超实用的经验：终端里红色一般是坏消息，绿色 / 白色一般是好消息。你现在不必读懂报错内容，只要看到红色，就知道「这里要复制给 AI」。
③ 功能行为
页面能打开、终端不报错，还不等于功能对。你得真的去用一下：在输入框打字、点添加、看任务有没有真的出现；点删除、看它是不是真的消失。
- 成功的信号：你操作后，页面按你的期望变化了。
- 出问题的信号：点了没反应、反应错了（比如点删除，结果整个列表都没了）。
在 Todo 里怎么用
拿「添加任务」验收举例，三只眼睛一起上：
- 页面：输入框、添加按钮在不在？（看页面）
- 终端：启动服务时有没有红色报错？（看终端输出）
- 行为：打一条「买菜」点添加，它有没有出现在列表里、输入框有没有清空？（看功能行为）
三处都对，这个功能才算真的过了。
如何做好这一步
- 别只看一处。页面好看不代表功能对，终端不报错也不代表页面对。三处都扫一眼，才踏实。
- 记住「看结果」不需要懂代码。你判断的是现象——看到了没、动了没、对不对，这些人人都看得懂。
本章小结
看结果 = 做判断题，看三处：浏览器页面、终端输出、功能行为。红色报错是坏消息的信号，功能要亲手点一遍才算数。三处都对，才叫真的做好了。
46. 如何反馈错误
这一章要解决什么问题
看结果时发现不对，怎么办？这一章讲一个极其核心、又极其容易做错的技能：把问题准确地反馈给 AI，让它帮你修好。反馈得好，一次就修；反馈得差，来回折腾还修不对。
这是什么：把「哪里不对」讲清楚，让 AI 能对症下药
反馈错误，本质就是给 AI 一份「病情报告」。AI 是医生，它没法亲眼看你的屏幕，全靠你把症状描述清楚。你描述得越准，它诊断得越快。
三条铁律，先记住
在讲怎么做之前，先立三条纪律——违反任何一条，你的反馈都会大打折扣：
⚠️ 铁律一：报错要原样复制，不要自己转述。 终端或控制台里那段红色报错，一个字一个字原封不动地复制给 AI。不要自己概括成「它说什么找不到」——报错原文里藏着 AI 定位问题的关键信息，你一转述就丢了。
⚠️ 铁律二：不要自己瞎改。 看到报错，初学者容易手痒去动代码。别动。 你看不懂代码，瞎改多半是越改越乱，最后 AI 都理不清你到底改了啥。正确做法是：保持现场，原样反馈给 AI，让它来改。
⚠️ 铁律三：不要只说「报错了」。 只甩一句「报错了」「不行」「打不开」，等于什么信息都没给。AI 只能反问你，一来一回浪费时间。有报错就贴报错，有现象就描述现象。
一个好用的反馈结构：我做了什么 → 期望什么 → 实际发生了什么
描述问题，套这三段就够清楚了：
- 我做了什么：我执行了哪个操作 / 命令。
- 我期望什么：我以为会发生什么。
- 实际发生了什么：真实结果是什么（报错原文贴在这里）。
这三段合起来，AI 就能还原出你的现场，快速定位。
在 Todo 里怎么用：好反馈 vs 坏反馈
场景：你给 Todo 加了添加功能，点「添加」却没反应。
坏反馈（AI 没法下手）：
添加不好使，你再看看。哪里不好使？报错了吗？页面什么样？AI 只能一头雾水地反问。
好反馈（照着三段式，还贴了报错）：
我做了什么：我在输入框里打了「买菜」，点了「添加」按钮。
我期望什么：这条「买菜」出现在下面的任务列表里。
实际发生了什么：点了完全没反应，列表没变化。
我按 F12 打开控制台，看到一段红色报错，原文如下：
<把控制台里的红色报错原样粘在这里>
请帮我找出原因并修好，然后告诉我怎么验证修好了。高下立判。第二种给了 AI 现场、期望、症状、报错原文——它几乎能一击命中。
一个可以直接套用的反馈模板
其实这个模板你早就见过，我们从环境准备那部分就在用它，这里把它作为「通用反馈模板」正式收下：
任务目标：<我本来想做成什么>
我做了什么：<我执行的操作 / 命令>
期望结果：<我以为会发生什么>
实际发生：<真实结果，报错原文原样粘贴>
请帮我定位原因、给出修复，并告诉我怎么验证修好了。如何做好这一步
- 报错原文 > 你的转述，永远。
- 反馈完，别忘了加一句「修好后告诉我怎么验证」——这样你就能立刻做判断题，确认真的修好了，而不是 AI 说好了就信。
- 如果一次没修好，就把新的现象和新的报错再按模板反馈一遍。修 bug 常常要来回几轮，这很正常，别慌。
本章小结
反馈错误 = 原样贴报错 + 讲清「我做了什么→期望什么→实际发生什么」。三条铁律：报错原样复制、不要自己瞎改、不要只说「报错了」。把现场交给 AI，它才能帮你修。
47. 如何验收 AI 生成的功能
这一章要解决什么问题
这是这一部分、也是全课「验收思想」的收口。前面每做一个功能，我们都在验收；这一章把散落各处的验收方法，汇总成一张你能随身带走的「万能验收表」——以后不管做什么项目，都能拿它来对。
这是什么：验收就是「先确认这一步对了，才敢走下一步」
验收，就是每做完一步，都停下来确认「这一步真的做好了没有」，确认了再继续。它是「判断题」的最终形态。
💡 一个必须养成的习惯：先验收，再继续。 初学者最容易犯的错，是 AI 说「做好了」，自己没验就急着做下一步。结果错误一步步累积，等发现不对，早就不知道是哪一步埋的雷了。每一步都验收通过再往前，你才能始终站在踏实的地面上。
为什么验收这件事，比你想的更值钱
因为你不懂代码，验收是你唯一能守住质量的关口。你没法从代码层面判断对错，但你完全可以从结果层面判断——而结果，恰恰是所有人都看得懂的语言。会验收，你就有了指挥 AI 的底气；不会验收，AI 给你什么你都只能照单全收。
万能验收表：五张清单，带走即用
下面这五张清单，覆盖了这门课里所有类型的验收。做完一个功能，挑用得上的对照打勾即可。
① 页面验收（前端界面）
- 页面能正常打开，不空白、不报错？
- 该有的元素（标题、输入框、按钮、列表）都在？
- 布局整齐，不重叠、不溢出，窄屏也不乱？
② 功能验收（交互行为）
- 该点的都能点，点了有预期反应？
- 操作后页面按预期变化了（加了出现、删了消失）？
- 老功能没被弄坏？（改新功能后必查）
- 输入奇怪的东西（空的、超长的）不会崩？
③ 数据验收（存储 / 后端）
- 数据真的存进去了？
- 刷新页面 / 重启后，数据还在？（这一条专治「假的保存」）
- 增删改之后，数据的变化和页面显示一致？
④ AI 输出验收（AI 功能）
- AI 真的返回结果了，不是空、不是报错？
- 结果格式对（该是列表就是列表，能正常显示到页面上）？
- 结果内容合理（拆解出的子任务，是不是真的和你输入的那件事有关）？
- 输入一句刁钻的，AI 会不会崩或胡说？
⑤ 部署验收（上云之后）
- 换一台设备 / 用手机能打开吗？（不只是你自己电脑上能开）
- 线上版本的核心功能（增删改、AI 拆解）都还正常？
- 线上的数据能正常保存吗？
在 Todo 里怎么用
比如验收「AI 拆解任务」这个功能，你会同时用到好几张清单：输入「下周办一场 50 人沙龙」——看 AI 有没有返回（AI 输出验收）、子任务有没有正常显示到列表里（页面 + 功能验收）、刷新后这些子任务还在不在（数据验收）。几张清单一叠，这个功能到底行不行，你心里就有底了。
如何做好这一步
- 对照清单，别凭感觉。感觉「差不多对了」最容易漏掉「假的保存」这类坑；清单帮你把该点的都点到。
- 每类功能配一张主清单：做页面主要看①，做后端 / 数据库主要看③，做 AI 功能主要看④——但②「老功能没弄坏」几乎每次都要顺手查一下。
- 把这张表存下来。它不是 Todo 专用的，你以后做任何 AI 项目，都能照着它验收。
本章小结
验收 = 对照清单做判断题，五张表覆盖页面、功能、数据、AI 输出、部署。养成「先验收，再继续」的习惯，你就能始终踩在踏实的地面上往前走。
这一部分的收尾
这一部分没教你任何新技术，但如果你回头看，会发现我们把前面一直在用的手艺，正式收成了一套工作流：
- 描述需求：把模糊的想法说成具体的、能验收的话，要什么和不要什么都讲清。
- 拆分功能：一次只做一小步，小到能单独验收为止。
- 下任务：用五段式模板（目标 / 现状 / 限制 / 期望结果 / 验收标准）指挥 AI。
- 看结果：看三处——页面、终端、功能行为。
- 反馈错误：原样贴报错，讲清「做了什么→期望什么→实际发生什么」。
- 验收功能：对照万能验收表，先验收再继续。
把它们串起来，就是那个你从第一天就在跑的核心循环：下任务 → AI 执行 → 看结果 → 验收 / 反馈。而这一切的总纲，还是那句话——描述和拆分是选择题，看结果和验收是判断题。
💡 这套「指挥 + 验收」的手艺，比任何一门具体技术都值钱。 技术会过时——今天的 Vue、Flask，明天可能换成别的。但「把需求说清、把任务拆小、把结果验准」的能力，换到任何工具、任何项目上都成立。你真正带走的，是这套永不过时的手艺。
你的 AI Todo 现在功能已经不少了。但项目一大，新的问题就来了：代码越来越多、越来越乱，改一处怕碰坏另一处。是时候让它变得更专业、更好维护了。下一部分 第九部分：工程化升级，我们就来聊聊，怎么把这个越长越大的项目，收拾得干净、稳当、经得起继续折腾。