前阵子带一位开发者完整做了一次 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/activitiesGET获取活动列表{ list }/api/activities/{id}GET获取活动详情{ detail }/api/activities/{id}/registerPOST提交报名{ ok }/api/my-registrationsGET查看我的报名记录{ 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 并放行 OPTIONSuser_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 帮你扩展”这条路是目前我验证过最稳妥的走法。
