12｜项目做完了，你真正掌握了什么？

本章任务：把项目怎样工作讲明白，找到对应代码，再试着改一点。
准备材料：现在的代码、甲方确认过的规则、检查记录和最近几次修改。
本章产出：你自己的项目说明、一次小改动的结果，以及接下来要补的知识。

会演示，还需要会解释

会演示，是知道先点哪里、再点哪里，最后出现什么。会解释，是知道点下去以后，程序做了什么，为什么会得到这个结果。

比如你会演示「提交报名」，却不知道记录存在哪。以后甲方让你加一个报名时间，你就不知道先找页面、查询代码，还是数据库，只能把整个项目再丢给 AI。

理解项目，关系到你下次能不能自己判断从哪儿改。 不用马上读懂全部代码，但要慢慢做到：能讲明白一件事，能找到它在哪里做，再能确认改动没有弄坏别处。

第一步：先用自己的话画项目地图

先别看 AI 给的总结。拿一张纸，写下报名系统有哪几块：能查看和报名的页面，处理审核的后台，真正判断和保存记录的程序，以及存数据的地方。

这就是最初的架构说明。架构只是「项目分成哪几块，各自干什么，怎么配合」。好比外卖有下单页面、接单处理和订单记录，不能只说用了什么框架。

部分	需要说清的问题	本项目中的例子
报名端	这里能看什么、填什么	看活动、提交报名、查结果
后台	这里能改什么、不能碰什么	发布、审核，只看允许看的名单
处理规则的程序	哪些情况要允许，哪些要拒绝	截止后不让报，重复报名要处理
存数据的地方	刷新以后，靠什么找回记录	活动、报名和账号的关系
要连接的外部服务	为什么要连，连不上怎么办	只有项目确实需要时才写

你画的是现在真的有的东西。方案里计划过、代码里没做的，要写「没做」，别为了让地图完整而画上去。

第二步：沿着一条请求跟到保存结果

图解：计划中的能力，不要写进当前架构。 查看大图

请求就是页面发给程序的一次消息。比如点「提交」，页面告诉后面处理报名的程序：哪个账号要报哪个活动。

后端就是接收并处理这些消息的程序。它要检查账号、截止时间和重复报名，再决定能不能保存。不是页面上显示成功，数据就一定存好了。

打开项目，真的走一次提交过程。请 AI 帮你找到每一步的代码，你再亲自看：按钮从哪发消息，哪里检查，哪里保存，哪里把结果返回页面。

函数可以先理解为代码里负责一件事的一段小程序，比如「检查是否过期」或「保存报名」。名字记不住可以查，重要的是知道它负责什么。

至少弄清这几个问题：身份从哪里来？活动编号能随便改吗？重复报名在哪挡住？保存失败会怎样？刷新后又从哪里取回记录？旧文件和没被调用的代码，不要当成正在用的实现。

第三步：请 AI 纠错，而不是替你完成全部理解

图中提示词仅作为示例，不建议作为实际项目中的提示词使用。

图解：复述 AI 的讲解，不等于理解实现。 查看大图

先写你自己的理解。写错没关系，错在哪里才是接下来要学的地方。如果一开始就抄 AI 的说明，你很容易把「读着顺」误当成「我懂了」。

仅作为示例，不建议作为实际项目中的提示词使用。

下面是我对提交报名过程的理解。请打开现在实际使用的代码，一条条核对。告诉我哪些说对了、哪些说错了、哪些还只是猜测，指出对应代码在哪里。先讲它在业务里干什么，再解释必须知道的技术词。没有做的功能不要补写。最后给我几个需要自己去代码或运行结果里找答案的问题，先别告诉我答案。

AI 也可能看错文件或解释错。拿不准时，看实际调用和运行结果；还判断不了，就带着具体问题找懂这部分的人问。不要用一句「AI 也是这么说的」结束调查。

第四步：抓住关键代码，不追求一次读完整库

先看决定事情成不成功的那几处。读不懂的语法，可以请 AI 拆成「什么条件下，执行什么，结果怎样」，再回去看原文。

关键位置	为什么值得理解
确认账号身份和允许范围	为什么这个账号能看，而另一个不能看
报名状态怎么改变	待审核、通过、取消之间能怎么走
名额和重复操作	两次同时审核会不会多占名额，点两次会不会存两条
保存和失败处理	页面说成功时是否真的保存，失败会留下什么
设置和外部服务	为什么你的电脑能用，换地方却不行

权限就是一个账号允许做哪些事。比如后台账号甲可以审活动一，但不能看活动二的名单。你要能找到允许和拒绝发生在哪里，不能只记「这里管安全」。

第五步：做一次受控的小改动

图解：用预测与实际的差异，确定下一步学习。 查看大图

这里的「受控」就是先留住能用的旧版，只在测试地方改一点，改完马上试。比如先改一句提示文字，不要拿真实报名记录练习。

接着可以试着显示报名时间。先猜要动哪些地方，再去查：数据库已经存了吗？程序取出来了吗？页面有没有显示？如果原来就有，就不用为了加一行展示重建数据表。

改完比较一下：你猜中了哪里，漏了哪里？再把提交、查看和取消试一遍。自己预测过，再看结果，才能知道自己是不是真的懂。

第六步：用变化问题检验掌握程度

别只问自己「懂了吗」。给自己出具体问题，先写答案，再找规则、代码和运行结果核对。

• 报名截止以后，旧记录还能不能看？
• 后台账号失去某项权限，已打开的页面还能不能审核？
• 快速点两次取消，会不会把一个名额还两遍？
• 提交时断网，再点一次会不会出现两条？

这些问题没有适合所有项目的固定答案。先看甲方怎么确认的；规则没说清，先记下来问，别在读代码时顺手替甲方作决定。

第七步：让能力逐步递进

阶段	可检验的能力	合适练习
刚开始	能讲功能，能照步骤试	提交一次，再故意漏填一项
慢慢熟悉	知道入口和出错记录在哪	跟着一次提交找到保存位置
真正理解	能解释为什么允许或拒绝	把甲方规则和判断代码对应起来
能改一点	能猜出影响，再自己检查	改一个字段显示，试试其他功能
能作判断	能比较两种做法的好坏	说明各自多花什么、有什么风险

可以一直借助 AI。目标是越来越能核实它，不是为了证明自己厉害而拒绝工具。做过三个项目但每次都只会点同意，也不等于比第一次懂得更多。

第八步：做一次有依据的项目复盘

复盘就是回头看看这次哪里做得好、哪里走了弯路，下次具体怎么改。比如「没问清名额规则，多改了两天」，就是值得回头看的事。

挑一次做对的决定、一次返工、一次故障，记当时知道什么、漏了什么、怎样发现、花了多少时间。别只写「以后认真沟通」。

可以写得更实在：「下次先问清 30 个名额、40 人申请怎么办，再开始画页面。」这句话下次拿出来就能照做。

某次办法有效，也要记住它当时的条件。小项目里够用的做法，不自动适合所有项目。

练习：不用 AI 总结，先完成一次说明

用自己的话解释：后台点了「通过」，为什么报名端能看到新结果？找到检查账号、修改记录、读取结果的代码，再各试一次允许和不允许的操作。

让 AI 核对你写的说明，记下最值得纠正的一处。再选一个能撤回的小改动，比较你预计动的地方和实际动的地方。

完成检查

• [ ] 不照着 AI 的总结，也能说清项目主要有哪几块。
• [ ] 能找到一次实际操作经过的关键代码。
• [ ] 至少能举例说明一个「为什么允许、为什么拒绝」。
• [ ] 改过一个小地方，也重新试过原来好用的功能。
• [ ] 知道自己这次哪里不懂，下次准备怎么练。

本章带走： 你自己讲得明白、查得到、试过的小部分。项目交出去以后，这些东西会让你下次修改时少一些盲猜。