AI 开发实战(下):核心功能、联调与修 bug
更新日期:2026-09-30 | 适用人群:正在开发中的 builder、卡在报错上的开发者、想让 AI 精准当 debugger 的人
开发和修 bug 是一体两面:功能是写出来的,更是调出来的。这篇文章覆盖四件事:核心功能怎么拆、AI 能力怎么接、联调怎么查、报错怎么读。
一、核心功能拆解:输入 → 处理 → 输出
不要对 AI 说「做核心功能」——太模糊。拆法是把核心功能变成 N 个「输入 → 处理 → 输出」的小功能,每个都是独立可开发、独立可验收的单元:
| 要素 | 回答什么 |
|---|---|
| 输入 | 用户给什么 |
| 处理 | 规则判断 / 调用 API / 查数据库 |
| 输出 | 用户看到什么 + 出错时给什么 |
课程示例(用户路径法):「用 AI 生成菜谱」= ①输入 3 种食材 → ②调用大模型 → ③输出结构化菜谱(菜名 / 步骤 / 时长)。同样,「加入购物车」= ①输入商品 + 数量 → ②查库存 + 写库 → ③返回购物车状态。
二、接入大模型 API 的完整流程
- 选平台与密钥:注册获取 API Key——密钥只放服务端环境变量,绝不放前端代码;
- 先直连调通:不写前端,先用 curl 或调试工具调一次 API,确认鉴权方式与响应结构,拿到一次真实返回;
- 让 AI 封装:把「输入消息列表、输出文本;超时 30 秒;错误分类(网络 / API / 限流)分别给友好提示;记录错误码日志」写成封装要求;
- 结构化输出:让模型按 JSON Schema 返回(如菜名 / 步骤 / 时长),前端直接绑字段——这是「AI 功能像成品」的关键;
- 限流与成本:加最小频率限制(如每用户每秒 1 次),后台记录调用次数,把成本算清。
三、错误处理:一张必做清单
| 情况 | 处理 | 提示语示例 |
|---|---|---|
| 网络超时 | 提示 + 重试按钮,不白屏 | 「网络开小差了,点这里重试」 |
| API 余额不足 | 提示服务忙碌,日志记录错误码 | 「服务暂时繁忙,请稍后再试」 |
| 输入为空 / 超长 | 表单校验,前端先拦截 | 「食材不能为空」 |
| 返回内容异常 | 降级(重试一次 / 回退默认) | 「生成失败,已重试 1 次」 |
| 重复提交 | 提交中禁用按钮 | 「正在生成…」 |
测试标准:普通 / 空 / 乱 / 长四组输入至少跑一遍。「乱输入」是质量的试金石——抛错就修到「友好提示」为止。
四、联调:跑起来再说
联调的本质是一条链路:UI 触发 → 调 API → 拿数据 → 渲染回来。核心心态:保持可运行状态——每加一个功能,先让整体还能跑再继续;大改必崩,小步必稳。
联调检查清单(每个核心功能都问 4 问):
- 能进入吗(入口可达)?
- 能完成吗(主流程走通)?
- 能退出吗(返回 / 取消 / 关闭)?
- 出错怎么办(有提示、有回退)?
五、报错阅读 5 步法
按顺序走,5 步定位问题:
- 看类型——先归大类:TypeError / 404 / 500 / Network / SQL / Build;
- 看位置——第一个「文件:行号」划定范围;
- 看上下文——堆栈最上 3 行,理调用链;
- 搜文档——把错误文本拿去搜,常见类型基本都有现成答案;
- 问 AI——按下方的公式提问,把报错全文和上下文一起给出。
常见报错速查表
| 报错关键字 | 先查 | 大概率根因 |
|---|---|---|
undefined is not... / TypeError | 变量 / 组件是否定义、拼写 | 引用未定义或空值取值 |
Network Error / Failed to fetch | 地址、跨域、网络 | 接口地址错 / CORS / 断网 |
401 / 403 / Auth | 登录态、token、权限策略 | 未登录、token 过期、RLS 拦截 |
SQL / table does not exist | 表名、字段、约束 | 忘建表 / 字段拼错 / 类型不匹配 |
Build / Module not found | 依赖、打包配置 | 包未装 / 路径错 / 配置项 |
让 AI 当 debugger 的提问公式
我做了 X(环境 / 工具版本),期望 Y(正常行为),实际 Z(报错全文)。
完整报错:【粘贴前 10 行】。涉及文件:a.js、b.js。
请先告诉我根因,再给修复方案(不要直接改代码)。要点:上下文齐全 + 只让 AI 先诊断再动手;一次只问一个 bug;不确认根因前不采纳修复方案。
六、回归意识:改一个不坏其他
- 改完功能 A,手动走一遍 B / C(至少点每个入口);
- 让 AI 检查:「改动只涉及某文件,请检查是否影响 a / b 功能的调用」;
- Git 保障:改之前先 commit;改坏了用
git diff看区别,或直接回滚; - 每周一次全量回归:把联调 4 问清单重跑一遍。
报错是最好的教材:每次报错记录「类型 → 位置 → 根因 → 修复」四行。一个月后,你就拥有一份自己的 bug 手册——比任何理论都真实。
功能调通、bug 可控之后,下一步是把它推到真实用户面前:部署上线与迭代:让 AI 写的东西真正跑起来。
📖 这只是基础。《AI 编程实战》课程覆盖 API 接入的直连到封装全程、五类报错的现场排查演示、以及提问公式的改写练习:查看课程详情 →
返回编程开发栏目 | 相关阅读:AI 开发实战(上):从项目初始化到前后端搭建
