前阵子带一位开发者完整做了一次 AI 编程实践辅导，从最初的原型验证一路走到前后端联调跑通。整个过程下来，我对“AI 辅助写代码”这件事有了更具体的判断：它确实能把入门门槛压低一大截，但与此同时，它对开发者自身的判断力要求反而更高了。AI 生成的代码可以很快，但业务规则的理解、边界条件的补齐、跨端字段的一致性，这些环节依然需要人一层层去盯。
这篇实录把整个项目按阶段拆开写一遍，重点记录两件事：AI 在哪些环节真能帮你省时间，以及它在哪些环节会“看似正确实则埋雷”。如果你正准备用 AI 做一个小项目，或者正在带别人做技术辅导，这篇内容应该能给你一些参考。
1. 这次辅导的起点：需求拆解与 AI 编程的“先决条件”
1.1 为什么选这个项目作为辅导样本
辅导用的项目是一个社区活动报名后台，需求很常规：管理员可以创建活动，普通用户能浏览活动列表、提交报名、查看自己的报名记录。技术栈定为 FastAPI 加 SQLite，前端用原生 HTML 加 JavaScript 做成单页应用。选这个题不是因为功能有多新鲜，而是它的规模足够适中，能完整覆盖从原型、接口设计、后端实现、前端对接再到联调上线的全过程，又不会因为业务太复杂而让初学者被细节淹没。
辅导对象是一位有前端基础、但后端经验不多的开发者，这里不写具体人名，就称他为 A 同学。A 同学之前已经能用 AI 工具写一些零散脚本，比如抓数据、改格式之类，但对“如何把一个完整项目组织起来”没有太多概念。这恰恰是 AI 编程实践里最有意思的地方：工具大家都会打开，但把脑子里模糊的想法拆成 AI 能听懂、能落地的步骤，才是真正的门槛。
1.2 辅导第一课：让 AI 听懂需求的提问方式
一上来 A 同学就尝试直接对 AI 说“帮我写一个活动报名系统”，结果得到的代码是一个看起来全功能、实际完全跑不起来的大杂烩。后端、前端、数据库的建表逻辑全部堆在一个回答里，改一处就牵连所有地方。这个失败过程非常典型，基本每个用 AI 做项目的人都会经历一次。
我让他换个思路：先别让 AI 写代码，而是把需求拆成业务对象和状态流转，一层层问清楚。比如先确认“一个活动有哪些字段，哪些字段是报名时必须有的”，再确认“报名时遇到重复提交怎么处理”“活动截止之后接口应该返回什么形态”。每次只让 AI 处理一个决策点，而不是一次性要求它输出全部代码。最终我们整理出了一个包含角色、字段、状态流转的设计文档，再把这个文档作为上下文喂给 AI，后续生成的代码才开始真正可用。
提示：让 AI 编程的前提，是你已经知道自己要什么。业务规则没理清，AI 只会把混乱固化得更完整。
这个环节花了大概一个小时，但后面节省下来的时间是它的数倍。所有联调阶段的问题，几乎都能追溯到需求阶段没说清的地方。
2. 原型阶段的玩法：用对话式 AI 快速把想法变成可点击页面
2.1 原型不是“画图”，而是把业务规则可视化的过程
我们的原型没有用专业设计工具，而是让 AI 直接生成一个单页 HTML 文件，里面用 mock 数据展示三个核心界面：活动列表、报名表单、报名成功回执。A 同学一开始不理解为什么要做原型，他觉得“反正最终也要做正式的页面，何必多走一步”。我的解释是：原型存在的意义不是演示外观，而是把“用户如何完成一个完整任务”的流程提前验证一遍。
在 AI 的辅助下，原型大概 20 分钟就出来了。但出来的只是初稿，接下来更重要的是有人站在用户角度从头到尾点一遍。点击报名之后页面发生了什么？活动已经结束时，报名按钮是直接隐藏，还是点下去以后提示失败？这些交互细节决定了后端接口要设计成什么形态，也会直接影响后续联调的工作量。
这一步可能看起来“不够技术”，但我在多次项目里验证过：原型阶段多花的时间，永远能在联调阶段加倍省回来。因为原型是最便宜的错误暴露工具，改一行 HTML 比改后端接口再加前端调用成本低得多。
2.2 AI 生成原型时的“三个必须人工确认的位置”
原型代码虽然简单，但 AI 生成时有三个位置是经常遗漏的，也是我们在辅导中反复检查的地方：
- mock 数据结构是否与未来 API 对齐。比如原型里用的是
activityId，还是activity_id？前端代码里读的字段名，必须和后端将来返回的字段名保持一致，否则到联调阶段全是对不上。 - 空状态和错误状态是否齐全。活动列表为空时页面显示什么？提交报名失败时有提示吗？AI 生成的原型默认展示数据都存在、操作都成功的场景，异常分支基本全靠人工补充。
- 核心流程能否闭环。从进入页面到报名成功，完整链路是否能走通？每一步的数据变化是什么？这个流程走一遍，往往能发现好几个逻辑漏洞。
这三步验证下来，我们把确认好的字段名整理成一张清单，作为后面接口设计的输入。这是我的强制要求，也是整个 AI 编程实践里最不能跳过的步骤。跳过它，后面联调就等着反复改字段名吧。
3. 后端实现阶段：AI 生成代码后必须做的信任度审查
3.1 从原型到接口：先定义可验证的接口契约
在让 AI 写后端代码之前，我和 A 同学先确定了四个接口：
| 接口 | 方法 | 作用 | 关键返回 |
|---|---|---|---|
| /api/activities | GET | 获取活动列表 | { list } |
| /api/activities/{id} | GET | 获取活动详情 | { detail } |
| /api/activities/{id}/register | POST | 提交报名 | { ok } |
| /api/my-registrations | GET | 查看我的报名记录 | { list } |
字段约定上，活动至少包含id、title、start_time、end_time、max_people、current_people；报名记录包含id、activity_id、user_name、created_at。定义契约的意义在于：前后端可以用它作为共同参考，AI 生成的代码一旦偏离契约，我们扫一眼就能发现，而不是等到运行时才暴露。
这一步还有一个隐藏的好处：接口契约本身就是给 AI 的提示词。当你要问“帮我实现报名接口”的时候，直接把字段表加上去，AI 输出的字段命名就不会乱飘。很多人觉得 AI 生成接口代码时命名不稳定，其实是因为你没给它一个稳定的定义。
3.2 最容易出问题的地方：生成错了但看起来像是对的
第一次让 AI 写报名接口，A 同学贴过来的代码表面上很完整：有路由、有参数校验、有数据库写入。但仔细审查后发现几个问题：
- 没有检查活动是否已经截止；
- 没有检查当前报名人数是否已达上限；
- 没有校验同一用户是否重复报名；
- 用户输入直接拼接进 SQL 语句，存在注入风险。
这些都不能算“代码写不出来”的问题，而是 AI 只满足了你说出口的那句话，没有补全你没说出口的边界条件。辅导中的做法是：我不直接指出全部问题，而是让 A 同学对照接口契约，把“用户调用这个接口可能出现的所有场景”列出来，再回来对比 AI 的代码。结果他自己发现了大部分问题，剩下少部分由我补充。
这个过程的重点不是把代码改对，而是把审查能力练起来。AI 编程实践中最核心的能力，不是“让它写出来”，而是“确认它写对了”。如果只会贴代码、跑一下、看结果，那遇到不报错的逻辑错误时，基本只能卡住。
3.3 辅导中的纠错示范：如何引导 AI 自己发现问题
发现 AI 代码有问题之后，不要直接说“你帮我改”，而是用“代码审阅”的方式继续问。我们实践下来比较有效的一种问法是：
请检查这个报名接口在以下场景下的行为： 1. 重复提交报名 2. 活动已截止 3. 报名人数已满 4. 非法参数（如用户名为空） 请逐个说明当前代码会发生什么，并指出需要修改的位置。AI 会自己列出它可能忽略的问题，并且通常能直接给出修正方案。这种方法比自己硬找快得多，因为它实际上是让 AI 对同一段代码做多轮自检。每次纠错，本质上都是一次小型的测试驱动开发——由人给出测试场景，AI 负责对照实现找漏洞。
经历过这个环节后，我确认了一个判断：AI 编程实践真正考验的，不是你会不会敲代码，而是你会不会给 AI“下测试用例”。你提供的场景越具体，AI 找出的问题就越准。反过来，如果你只说“这个接口不对”，AI 大概率只会帮你重写一遍，问题原封不动。
4. 前端实现阶段：从静态原型到真实接口的对接
4.1 组件拆分与状态管理：AI 生成的代码需要重新组织
前端从原型升级到真实接口调用时，AI 又是几秒钟就生成了一大段 JavaScript。但这段代码把所有逻辑都堆在一个<script>标签里——接口请求、页面渲染、表单校验、按钮事件全混在一起。对原型来说这样没问题，但到了要对接真实接口、要处理错误场景的阶段，这种代码基本没办法改。
我让 A 同学做了一次“被动重构”，就是按职责把代码拆成三个模块：接口请求层、页面渲染层、事件交互层。拆分的依据很简单，就问两个问题：如果后端字段发生变化，你希望只改哪个文件？如果页面样式变动，你又希望只改哪个文件？分割之后，AI 再生成新的模块代码，就可以只针对对应文件提问，不用整块重来。
这个重构工作对 AI 编程实践特别重要。因为 AI 擅长的是生成“一个完整的东西”，而不是“一个可维护的结构”。如果你任它自由发挥，项目稍微大一点就会进入“改哪里都怕带崩别处”的状态。主动做结构拆分，才是人应该接管的职责。
4.2 接口联调中的命名与字段不一致问题
前后端第一次真正对接时，页面上出现了好几个undefined。后端返回的是 Python 习惯的snake_case字段，前端 JavaScript 里读的是camelCase字段，两边对不上。比如后端返回max_people，前端写的是maxPeople，渲染出来就是空值。
这个问题的麻烦之处在于它不是直接报错，而是静默失败。表格一样显示，字段位置一样占着，只是数据是空的。排查起来非常费劲，你会先怀疑数据是不是没查到，再怀疑接口是不是没返回，最后才发现只是字段名不对。
后来我们定了一条规则：前端拿到的数据统一做一次字段映射，命名转换集中放在一个文件里处理，不在业务代码里到处rename。AI 写单个请求很擅长，但跨前后端的命名一致性，必须由人来把关。这种问题一次可以靠运气修好，但不想每次都靠运气的话，就得立规矩。
4.3 错误处理与加载态：AI 最容易忽略的“看不见的代码”
AI 生成的前端代码默认假设“请求总是成功、数据总是存在、用户操作总是合法”。这对原型够用，对真实应用远远不够。我让 A 同学在页面里补了三类东西：请求过程中的 loading 状态、接口异常时的提示、空数据时的占位页面。
这些代码加在一起不到 100 行，但却是整个里最容易被忽略的部分。原因很简单：AI 只会基于你给出的信息输出，你没提 loading，它就认为不需要 loading。辅导到这里我明确告诉 A 同学一个经验：以后向 AI 提需求时，要把“异常分支”作为显式条件写进去，比如“加载中显示 loading，请求失败显示提示，列表为空显示空状态”。否则 AI 永远优先给你展示顺利路径。
这个习惯其实反映了一个更底层的认知：AI 编程实践不是把“怎么写代码”外包出去，而是把“定义清楚代码要覆盖哪些场景”这件事做得更认真。场景定义得越细，AI 的价值才越能发挥出来。
5. 前后端联调的翻车现场：完整复盘的排查链路
5.1 第一次联调跑不通的三个具体报错
把前后端代码拼起来之后的第一次联调，几乎是预期中的翻车现场。三个问题按出现顺序记录如下。
第一个是 CORS 预检失败。前端页面和 API 服务跑在不同端口，浏览器直接拦截了跨域请求。AI 生成的后端没有配置 CORS，补上之后，普通 GET 请求没问题，但带 JSON 的 POST 请求在 OPTIONS 预检阶段又报错。第二个是报名表单提交后，后端拿到的user_name字段是 null。原因很隐蔽：前端表单序列化时带的是userName，后端接口定义的却是username。第三个是时间格式问题：前端把活动时间转成了自己拼接的字符串，后端按 ISO 格式去解析，直接抛了异常。
这三个问题单看都不复杂，但叠加在一起时非常打击士气。A 同学当时的第一反应是“把全部代码贴给 AI 让它看看哪里错了”，结果 AI 扫了一遍回答说“看起来没问题”。其实问题不在 AI 的判断能力，而在于人在没有明确方向时，给 AI 的信息粒度太粗了。
5.2 排查链路：从页面往前端代码再往后端
我让 A 同学改用分段定位法。第一步，先在浏览器开发者工具里打开 Network 面板，确认请求有没有发出去、发出去的内容长什么样。第二步，看请求体的字段名和后端接口定义是否一致。第三步，确认请求到达后端之后，后端日志里收到了什么、返回了什么。
这个顺序听起来很简单，但是遇到问题的人最容易跳步。如果你连请求是否真的到了后端都不确定，就跑去看后端日志，那等于在错误的位置找证据。我们把每次排查都记录成一张表，方便对照：
| 现象 | 可能原因 | 定位手段 | 最终结论 |
|---|---|---|---|
| POST 请求被 CORS 拦截 | 后端未配置跨域 | Network 面板查看预检请求 | 后端补充 CORS 并放行 OPTIONS |
| user_name 字段为 null | 前后端字段命名不一致 | Network 面板查看请求 Payload | 前端统一改用 username |
| 时间解析抛异常 | 数据格式不一致 | 后端打印收到的原始值 | 前端提交前统一转 ISO 格式 |
这张表最大的价值，是让 A 同学看到“报错现象”与“真正原因”之间往往还隔着两层。你不去逐层确认，就只能像无头苍蝇一样乱试。
5.3 每次改完 AI 代码，都要重新跑一次最小闭环
联调阶段我们踩过最大的坑，是改完一处之后直接跑全套流程，然后被另一个问题卡住，于是忘了刚才改的东西到底有没有生效。到中后期，我强制要求 A 同学执行一个规则：每次只改一个变量，然后立刻跑一遍最小闭环。
所谓最小闭环，就是“创建活动 → 提交报名 → 查看列表”这一条链路。改动小，定位自然快。这样即使 AI 生成的代码有错，也能确认它错在没有改动过的地方，而不是怀疑刚改的 CORS 配置又引入了新问题。
这个习惯看起来不够炫酷，但它才是联调效率提升的关键。做过几个项目的人会明白，AI 编程实践的最大风险从来不是代码写不出来，而是项目改动之后，你无法判断当前系统处于什么状态。有了一条随时可以验证的最小路径，这个风险就被牢牢按住了。
6. 这次 AI 编程实践结束后，我复盘出的几条经验
6.1 AI 擅长的和人类必须接管的职责边界
一次完整辅导下来，我对 AI 编程实践的边界判断清晰了很多。AI 在以下环节确实高效：按清晰描述生成样板代码、把一段逻辑翻译成另一种语言、根据测试反馈快速修改版本。但在业务规则梳理、异常场景设计、前后端命名契约定义，以及“代码看起来正确但实际错误”的判断上，AI 目前明显替代不了人类。
用 A 同学最后总结的一句话来说：“AI 让我从‘怎么写’里解脱出来了，但‘该不该这么写’‘写了之后怎么证明它是对的’，还是要自己想。”这句话我记了很久，它基本概括了 AI 编程实践的真实价值——不是让你不用思考，而是让你把思考的重心转移到更值得的地方去。
6.2 给准备尝试 AI 编程的人三条可执行建议
结合这次辅导的完整经历，我给准备尝试的人三条具体建议：
- 起步项目选“规模适中的完整业务”，别选算法题，也别选大型系统。只有完整业务才能暴露协作、命名、异常处理这些实际问题。算法题 AI 直接能写对，大型系统 AI 又撑不住，都会让你误判它的能力。
- 把“给 AI 写测试用例”当成核心技能。与其等 AI 写完代码你再人工审，不如让 AI 先写实现，再用异常场景清单让它自检。效率高很多，你自己也能更快建立对代码的掌控感。
- 每天保留一段完全不依赖 AI 的通读代码时间。如果连自己项目里的逻辑都不能通读，出了问题你根本无法判断是业务设计错了，还是 AI 生成的代码错了。这个区别，在排错时是方向性的。
6.3 导师视角：让 AI 变成“思考放大器”而不是“代码代笔”
作为辅导者，我在整个过程中刻意避免替 A 同学直接向 AI 要答案。每当 AI 给出一版代码，我会反过来问他三个问题：这段代码在什么假设下成立？假设不成立时会发生什么？你怎么验证这个假设？这三个问题不需要 AI 回答，需要项目负责人自己想清楚。
我个人的体会是，AI 编程实践最终培养的是一种“带着代码思考”的能力。它让动手周期变短了，但让思考密度变高了。到辅导结束时，A 同学已经能独立完成“梳理需求 → 定义接口 → 让 AI 生成 → 自检异常场景 → 联调修复”的完整流程。看到这个过程，我觉得这比任何一次“AI 帮我写完整个项目”的炫技都更有意义。
如果只让我分享一个最值得记住的细节，那就是每次改完 AI 生成的代码后，都立刻跑一遍最小闭环。这个习惯在本次联调中救了无数次场，后来也成为 A 同学独立开发时保留的第一个工作习惯。AI 编程实践有很多种打开方式，但“先有一个可验证的最小闭环，再让 AI 帮你扩展”这条路，是目前我验证过最稳妥的走法。
