切换外观
01｜AI 能写代码，你为什么还要学开发流程？
这一章要做什么：先看清一个项目大概要走哪几段路，路上哪些事得你自己拿主意。
读完你会得到：一份自己的起点记录，知道下一步该干什么。
能跑起来，只是刚开头
图解：成功画面只能证明你看到的那一次。 查看大图
假想一下这个场面。
甲方给你发来一句话：「帮我做个活动报名系统，手机上能用就行。」
你把这句话原样丢给 AI。过了一会儿，页面出来了，按钮也能点，看着挺像那么回事。
第二天甲方说：报名得审核一下吧？而且不同的人登进后台，不该都能看到所有人的名单。报名截止以后，也不该再改了。
你让 AI 接着改。改完发现，原本好好的「取消报名」反而点不动了。AI 说「建议把数据表重建一下」，你不知道重建会丢什么，也只能硬着头皮点同意。
到这个地步，问题已经不在 AI 身上了。
真正缺的是：你手里没有任何东西，能回答「甲方到底要做成什么样」和「凭什么说它现在是对的」。
直接把需求丢给 AI 让它写，和「项目真的做完了」，中间还隔着一段路。
这一段路里，有几件事必须你来：说清楚它到底要解决谁的什么问题、哪些规则是甲方亲口确认过的、你用什么证明它真的做到了。
代码可以写得不多，也可以看不懂全部，但这几件事不能一起交给「AI 说完成了」。
一个项目大概会走过这几段
我把整个过程拆成 12 章。现在不用记细节，只要先有个印象：哦，原来要经过这些地方。
| 走到哪 | 你心里要回答的问题 | 手里会多出什么 |
|---|---|---|
| 准备（01—02） | 电脑、工具、以及「改坏了能不能退回去」，都弄好了吗？ | 一份环境记录，还有一个能退回去的旧版本 |
| 问清楚（03—04） | 到底要做什么？做成什么样算合格？ | 一份问题清单，一份甲方确认过的规则 |
| 定方案（05—06） | 页面长什么样？技术上怎么实现？ | 页面原型、开发方案 |
| 开工之前（07） | 资料给全了吗？哪些能改、哪些不能动，说清楚了吗？ | 一份「当前资料 + 改东西的规矩」 |
| 动手做（08） | 这次做的这一小段，做完能马上试吗？ | 一个能真正跑起来的小功能 |
| 检查（09—10） | 真的行吗？坏了怎么找原因？ | 测试记录、修好之后留下的证据 |
| 交出去（11—12） | 换台电脑还能跑吗？你自己讲得明白吗？ | 交付说明、验收记录、你自己的理解 |
这份顺序是会来回走的。
比如你正在做页面原型，甲方突然说「其实审核不是一个人审，得两个人都同意」。那你就得退回第 4 章，重新把这条规则问清楚，而不是假装没听见，继续往下画。
反过来也一样。比如你发现要对接的那个登录接口根本连不上，那方案就得改。
流程不是一条只能往前的直线。它更像是：你一边做，一边回头看看前面是不是还站得住。
这件事里，三个人各管一摊
图解：甲方确认业务，你记录事实与未知。 查看大图
甲方管「要什么」。
他得说清楚业务上到底怎么走：谁能报名、谁来审核、什么情况下不能报。他说的可能前后不一致，也可能今天这么说、下周又改主意——这很正常。
所以你要把他确认过的话记下来，而不是记在脑子里。
你管「靠不靠谱」。
把资料收齐、把不清楚的信息问清楚、把该试的试一遍、把有危险的操做拦住。
你不可能什么都懂。但你可以做到：不知道就去查、就去问、就去小范围试一试，而不是凭感觉猜。
AI 管「帮你干活」。
帮你提问、帮你看懂看不懂的东西、帮你比较几种做法、帮你写代码、帮你检查、帮你在报错里找线索。
它也会出错：理解偏了、漏掉了、编出一个根本不存在的接口，或者给你一个「看着能跑、其实是错的」改法。
这些错误，不会因为它说得很自信就消失。
所以要求你一眼看出所有问题，这不现实。你需要做到的是三件事：
- 让它带着你做检查，而不是它说完了你就信；
- 看懂它给的结论靠不靠谱；
- 把做过的检查留下记录。
真遇到拿不准、又要动真东西的时候，停下来比继续试更省事。 停下来不是失败，是这一步确实该找人看看了。
项目里要一直留着三样东西
这三样听起来有点虚，其实特别具体。我拿「活动报名系统」举例。
图解：先照规则做，再照说好的标准去试。 查看大图
第一样：跟甲方确认过的话，编上号存起来
一个项目做久了，甲方说过的话能有三四十条。
你记不住，AI 也记不住。而且每次跟 AI 解释一遍「审核通过才占名额，但提交的时候不占」，特别费劲。
解决办法很土，但特别管用：把确认过的规则一条条写下来，从头编号。
像这样：
- 第 1 条：提交报名后是「待审核」，这时候不占名额。
- 第 2 条：只有审核通过了，才占掉一个名额。
- 第 3 条：报名截止之前，待审核的、已经通过的，都可以取消。
- 第 5 条：后台不同账号，只能看到自己负责的那些活动。
编完号，你说话就省事了：
- 写代码时说「这段是按第 2 条做的」。
- 测的时候说「第 5 条还没验过」。
- 甲方改主意时说「好，那第 3 条要改」。
为什么一定要编号？ 因为「审核通过才占名额」这句话，你复述十遍就会走样十遍。编了号，它就是一个固定的东西，你和 AI 指的都是同一个。
号码本身一点都不重要。重要的是：每一句「我们说好了」的话，都能被指出来、被找到、被检查。
第二样：每次改动，顺手写清楚为什么
你让 AI 修一个 bug，它改完了。你要是只记一句「修好了」——过两周同样的问题再冒出来，你完全不知道从哪查起。
所以要养成一个特别小的习惯：每次改动，顺手记三句话——为什么改、改了哪里、怎么确认改对了。
比如：
为什么改：取消报名以后，页面上还显示「已报名」，其实后台已经取消了。 改了哪里：取消成功之后刷新数据的那段。 怎么确认：拿测试账号取消一次，页面马上变成「已取消」，刷新以后还是「已取消」。
三句话，一分钟。但下次出问题，你能一眼看出来「哦，那次改动碰过这里」。
第三样：检查过的结果，要能拿出来
「我试过了，没问题」——这句话在项目里几乎不算数，因为它没法核对。
你要留下的是能拿出来给人看的玩意儿：一张截图、一段日志、一次测试的结果。
但这里有个特别容易搞混的地方：不同的证据，能证明的事是不一样的。
- 一张页面截图，能证明「这个页面长这样」。它证明不了「别人偷不到数据」。
- 一次测试通过，能证明「这个情况下没问题」。它证明不了「所有情况都没问题」。
所以别拿「页面能打开」去证明「安全没问题」。证据要和你想证明的事对得上。
小项目可以简单点，但这几件事别省
不是每个项目都要准备一大摞文档。
你自己练手做个小东西，用一页纸写清楚「要做什么、怎么算做完」就够了，不用照着大公司的规范来。
但有几件事，无论项目多小都别省：
- 清楚自己在做什么、是给谁做的；
- 改坏了，能退回上一个能用的样子；
- 关键的地方，真的自己试过一遍。
反过来也一样：别因为「看起来专业」就硬往里加东西。
用户没几个的小项目，一上来就加缓存、加消息队列，只会让你多维护一堆用不上的东西。真出问题时，你还多几个地方要查。
这本指南从头到尾用的例子，都是一个虚构的「活动报名与审核系统」：能看活动、能提交报名、后台能审核、能看到结果。
里面的名额、取消、登录这些规则，都是为了讲清楚而编的，不是标准答案。别把例子当成「所有项目都得这样」。
怎么读这本指南
第一次做项目，从第 1 章顺着往下走，每章都动手做一次。
别打算一口气读完。 读完了基本什么都记不住，做一遍才记得住。
学到哪了，你自己记一下——写在笔记里、或者把那页收藏起来都行。下次直接从那儿接着看。
每章开头会写「这章要做什么、你会得到什么」，中间是案例和步骤，最后有「怎么判断这章做完了」。
看到不懂的地方，先看正文里的解释和例子；还想再深入一点，就去查提示词专题和检查清单。
关于提示词： 书里出现的提示词都只是例子，每一处都标了「仅作为示例，不建议作为实际项目中的提示词使用」。
你要学的是「怎么把自己的真实情况说清楚」，不是背句子。别人的项目、别人的工具，抄一段话过来是没用的。
现在，写下你的起点
找个地方（记事本、笔记软件都行），回答四个问题。别写得漂亮，写得真实就行。
- 你想做什么？现在手里有没有甲方给的原始需求——哪怕只是聊天里的一句话？
- 哪些工具你用过？哪些完全没碰过？
- 现在的代码、资料、数据都存在哪？有没有备份？
- 万一遇到你判断不了的事，你打算找谁问？
怎么算这一章读完了：
- 你能说出接下来第一步该干什么；
- 你知道「页面能打开」不等于「做完了」；
- 你知道 AI 的检查结果，代替不了你自己去确认、去试。
留个小练习：「报名按钮点下去有反应」这件事，能证明什么？又不能证明什么？至少想出一条「还需要再确认」的。
下一章，我们先把工具和「改坏了怎么退回去」准备好，然后再去问需求。