AI 写代码后，如何自己检查有没有问题？

上一期我们用 AI 完成了一个简单的待办事项页面。

流程大致是：

明确需求
  ↓
让 AI 制定计划
  ↓
让 AI 生成代码
  ↓
在浏览器中运行
  ↓
测试添加、完成和删除

代码能够运行之后，很多新手会产生一个疑问：

页面能打开，按钮也能点击，是不是就说明代码没有问题？

答案是：不一定。

代码没有报错，只能说明它暂时没有触发明显错误。

它仍然可能存在：

• 没有满足完整需求。
• 某些输入会导致结果错误。
• 页面刷新后数据丢失。
• 删除一条数据时影响了其他数据。
• 引入了不必要的依赖。
• 修改了项目中原本正常的功能。
• 存在安全或隐私风险。

所以，AI 写完代码后，我们还需要完成一个重要步骤：

对 AI 生成的代码进行验收。

今天我们从零开始学习一套简单的检查方法，帮助你判断一段 AI 代码是否真的可以使用。

一、代码检查不是只看有没有报错

很多初学者检查代码时，只关注下面两件事：

• 编辑器有没有红色提示。
• 浏览器能不能打开页面。

这两个检查当然有用，但还不够。

我们可以把代码质量检查分成 5 个层次：

第一层：语法是否正确
  ↓
第二层：代码是否能够运行
  ↓
第三层：功能结果是否正确
  ↓
第四层：边界和异常是否处理
  ↓
第五层：是否适合项目和真实使用

越靠后的检查，越接近真正的交付。

二、第一层检查：语法是否正确

语法错误是最容易发现的一类问题。

例如下面的 JavaScript 少了一个右括号：

function greet(name {
  return `你好，${name}`;
}

运行时通常会直接报错，代码无法执行。

常见语法问题包括：

• 括号没有成对出现。
• 引号没有闭合。
• 大括号缺失。
• 关键字拼写错误。
• JavaScript、HTML 或 CSS 语法混用。
• 代码块嵌套关系不正确。

新手怎么检查语法

可以使用：

• 编辑器的错误提示。
• 浏览器开发者工具的 Console。
• 项目自带的检查命令。
• 语言或框架提供的格式化工具。

如果是一个简单的 HTML 文件，直接在浏览器中打开，按 F12 查看 Console 就可以发现很多问题。

让 AI 帮你检查语法

可以这样提问：

请只检查下面代码中的语法问题。

要求：
1. 列出具体错误位置。
2. 解释为什么这是语法错误。
3. 给出最小修改建议。
4. 不要顺便重构代码。

代码：
[粘贴代码]

注意"只检查语法"这句话。

如果你直接说"帮我检查代码"，AI 可能同时修改命名、结构、性能和样式，让你无法判断到底改了什么。

三、第二层检查：代码能不能正常运行

语法正确，不代表代码一定能运行。

例如：

const button = document.querySelector("#saveButton");

button.addEventListener("click", () => {
  console.log("保存成功");
});

这段代码语法没有问题。

但如果页面中不存在 id="saveButton" 的元素，button 就可能是 null，执行监听方法时会报错。

运行检查要看什么

运行代码时，重点检查：

• 页面是否能正常打开。
• 程序是否能正常启动。
• 依赖是否都已经安装。
• 文件路径是否正确。
• 导入的变量和方法是否存在。
• 按钮、表单和接口是否真的触发。
• 控制台是否出现错误。

对照运行环境检查

AI 可能使用了你的环境不支持的写法。

例如：

• 代码使用了较新的 JavaScript 语法。
• 项目使用 Vue 2，但 AI 按 Vue 3 的写法生成。
• 项目使用 Node.js 16，但代码依赖更高版本能力。
• AI 使用了一个项目中没有安装的第三方库。

因此，向 AI 提供环境信息很重要：

请基于以下环境检查代码是否可以运行：
- 操作系统：macOS
- Node.js：20
- 项目框架：Vue 3
- 包管理器：npm
- 不允许新增第三方依赖

四、第三层检查：功能结果是否正确

这是最重要的一层。

代码没有报错，也可能把事情做错。

例子：待办数量统计

假设需求是：

显示当前未完成的待办数量。

AI 生成了：

todoCount.textContent = `未完成：${todos.length}`;

这段代码可以运行，但它统计的是全部待办事项，不是未完成事项。

正确的逻辑应该是：

const unfinishedCount = todos.filter(
  (todo) => !todo.completed
).length;

todoCount.textContent = `未完成：${unfinishedCount}`;

如何判断功能结果正确

不要只凭"看起来对"来判断。

应该把需求转换为可以操作的测试步骤。

例如需求是：

用户可以添加待办事项。

可以转换成：

操作：输入"学习 AI 编程"，点击添加。
预期：列表中出现"学习 AI 编程"。

需求是：

用户可以标记待办事项为已完成。

可以转换成：

操作：点击某条事项前面的复选框。
预期：文字出现删除线，未完成数量减少 1。

需求只有转换成"操作"和"预期结果"，才容易真正验证。

使用验收表

可以先列出一张简单的验收表：

功能	操作	预期结果	实际结果
添加待办	输入内容后点击添加	列表出现新事项	待填写
空输入校验	不输入内容直接点击添加	不新增事项并提示	待填写
标记完成	点击复选框	文字出现删除线	待填写
取消完成	再次点击复选框	恢复未完成状态	待填写
删除事项	点击删除按钮	事项从列表消失	待填写
数量统计	完成一条事项	未完成数量减 1	待填写

测试时逐项填写"实际结果"。

如果实际结果和预期结果不一致，就找到了需要修改的问题。

五、第四层检查：边界和异常是否处理

很多 AI 生成的代码，只演示最顺利的情况。

但真实使用中，用户可能输入空内容、错误类型或超长文本。

常见边界情况

对于一个普通函数，可以检查：

• 输入为空。
• 输入只有空格。
• 输入为 null。
• 输入为 undefined。
• 输入类型错误。
• 输入为 0。
• 输入为负数。
• 输入达到最大值。
• 数据数组为空。
• 数据字段缺失。

对于待办事项页面，可以检查：

1. 输入框为空时点击添加。
2. 输入框只有空格时点击添加。
3. 连续添加很多条事项。
4. 添加很长的待办内容。
5. 连续点击添加按钮。
6. 添加后立即完成。
7. 添加后立即删除。
8. 删除列表中的最后一条事项。
9. 删除后数量是否正确。

让 AI 帮你生成边界测试

下面是一个待办事项功能的需求和代码。

请不要修改代码，只生成测试清单。

请分成 3 类：
1. 正常场景。
2. 边界场景。
3. 异常场景。

每个场景请包含：
- 操作步骤。
- 输入数据。
- 预期结果。
- 如果失败，可能说明什么问题。

AI 很适合帮助我们补充"可能没有想到的测试场景"。

但测试清单仍然要结合真实需求调整。

六、第五层检查：是否适合当前项目

一段代码功能正确，也不代表适合直接放进项目。

还需要检查以下内容。

1. 是否符合项目结构

例如项目已经规定：

页面放在 pages 目录。
请求方法放在 api 目录。
业务工具放在 utils 目录。

但 AI 把所有代码都写进了页面组件中。

即使能运行，也会导致项目越来越难维护。

2. 是否重复实现已有能力

项目中可能已经有：

• 通用请求方法。
• 日期格式化函数。
• 表单校验方法。
• 权限判断工具。
• 统一错误提示组件。

如果 AI 没有看到这些内容，可能会重新写一套。

这会增加重复代码和后续维护成本。

3. 是否新增了不必要的依赖

一个简单的日期格式化，AI 可能建议安装一个很大的第三方库。

新增依赖前应该确认：

• 项目中是否已经有类似依赖。
• 这个功能是否可以用现有代码完成。
• 新依赖是否维护正常。
• 是否会增加构建体积和安全风险。

可以要求 AI：

请优先使用项目已有的方法。
如果需要新增依赖，请说明理由、替代方案和潜在影响。
不要默认安装第三方库。

4. 是否修改了无关代码

AI 有时会顺手修改：

• 无关组件。
• 全局样式。
• 配置文件。
• 其他接口。
• 不属于当前需求的工具函数。

修改范围越大，回归风险越高。

七、检查安全和隐私风险

初学者容易忽略安全检查，但 AI 代码尤其需要关注这一点。

1. 不要把敏感信息写死

不推荐：

const apiKey = "真实的 API Key";

不要把下面内容直接写进代码并提交：

• API Key。
• 数据库密码。
• 登录 token。
• 私钥。
• Cookie。

2. 检查用户输入

如果代码直接把用户输入拼到页面中，需要注意安全风险。

例如：

element.innerHTML = userInput;

如果 userInput 来自用户或外部接口，可能带来脚本注入风险。

在待办事项案例中，使用：

title.textContent = todo.title;

通常比把内容写入 innerHTML 更稳妥。

3. 检查权限

对于涉及用户数据、订单、文件和管理功能的代码，要确认：

• 谁可以调用。
• 是否需要登录。
• 是否检查数据归属。
• 普通用户能否访问管理员功能。

不要因为 AI 没有提到权限，就认为权限不重要。

八、让 AI 进行一次代码验收

当你自己完成初步检查后，可以把需求、代码和测试结果交给 AI 进行辅助审查。

建议使用下面的 Prompt：

请帮我验收下面这段代码，但不要直接重写。

需求：
[粘贴明确的功能需求和验收标准]

代码：
```[语言]
[粘贴代码]

我已经完成的测试： 列出操作和实际结果

请按以下结构回答：

1. 需求是否都已经覆盖。
2. 哪些功能可以从代码中确认。
3. 哪些功能需要实际运行才能确认。
4. 可能存在的语法或运行问题。
5. 可能遗漏的边界和异常情况。
6. 可能存在的安全或隐私风险。
7. 修改范围是否超出了需求。
8. 按严重程度列出问题：
   • 必须修复
   • 建议修复
   • 可以暂不处理
9. 最后给出一份人工复测清单。

如果无法根据现有信息判断，请明确标记为"无法确认"，不要自行假设。

### 为什么不要直接让 AI 重写

如果你一开始就说：

```text
帮我把这段代码改好。

AI 可能直接修改大量内容。

你反而无法知道：

• 原来的问题是什么。
• 哪些修改是必须的。
• 哪些修改只是 AI 的个人偏好。

先让 AI 验收和列问题，再决定是否修改，更容易掌握过程。

九、使用 Git 或备份保护修改

如果代码属于正式项目，修改前建议保留可恢复版本。

可以使用：

• Git 提交。
• 新建备份分支。
• 复制一份文件。
• 保存修改前后的差异。

这样即使 AI 的修改不合适，也可以快速恢复。

检查改动范围

每次让 AI 修改后，都要查看：

哪些文件发生了变化？
每个文件改了什么？
有没有出现需求之外的修改？
有没有删除原来的逻辑？

如果使用 Git，可以重点查看代码差异，而不是只看最终文件。

十、一个完整的检查流程

以 Day 11 的待办事项功能为例，完整检查可以这样进行：

第一步：检查语法

打开 index.html，确认：

• HTML 标签能够正常解析。
• CSS 没有明显错误。
• JavaScript 没有语法报错。

第二步：检查启动

直接用浏览器打开页面，确认：

• 页面能够显示。
• 输入框和按钮存在。
• Console 没有红色报错。

第三步：检查正常功能

依次测试：

添加一条事项
  ↓
添加第二条事项
  ↓
完成第一条事项
  ↓
删除第二条事项

每一步都观察列表和数量变化。

第四步：检查边界

测试：

空输入
只有空格
超长内容
连续快速点击
删除最后一条

第五步：检查需求范围

确认代码没有额外引入：

• 登录。
• 数据库。
• 第三方框架。
• 与待办功能无关的配置。

第六步：记录问题

发现问题时，不要只记"不能用"。

可以按照下面的格式记录：

问题：
输入空格后仍然新增了一条事项。

复现步骤：
1. 在输入框中输入 3 个空格。
2. 点击添加。

预期结果：
不新增事项，并提示输入不能为空。

实际结果：
列表新增了一条空白事项。

有了清晰的问题记录，再让 AI 帮助修复，效率会更高。

十一、常见误区

误区一：只检查代码，不检查需求

代码写得很漂亮，但如果没有实现真正的需求，仍然是不合格的。

先问：

它解决的是我真正要解决的问题吗？

误区二：只测试一次成功场景

一次成功只能说明一个输入有效。

还要测试：

• 空输入。
• 边界值。
• 错误输入。
• 重复操作。
• 多次连续操作。

误区三：把 AI 的自我检查当作最终验收

AI 可以列出风险，但它不一定真正运行了你的代码，也不一定掌握全部业务背景。

AI 的检查结果只能作为辅助。

最终仍然要靠：

• 本地运行。
• 自动化测试。
• 人工操作。
• 代码审查。

误区四：发现问题就让 AI 全部重写

大范围重写可能引入新的问题。

更好的方式是：

先定位一个问题
  ↓
说明复现步骤
  ↓
只修改相关部分
  ↓
重新测试

十二、一份可收藏的代码验收清单

每次使用 AI 生成代码后，可以复制下面的清单：

需求检查
[ ] 代码实现了需求中列出的所有功能。
[ ] 没有把不需要的功能一起加进来。
[ ] 输入、输出和业务规则符合预期。

语法和运行
[ ] 代码没有语法错误。
[ ] 项目或页面可以正常启动。
[ ] 依赖和导入路径都存在。
[ ] 控制台没有未处理的错误。

功能测试
[ ] 测试了至少一个正常场景。
[ ] 测试了至少一个边界场景。
[ ] 测试了至少一个异常场景。
[ ] 实际结果和预期结果一致。

边界和异常
[ ] 空值可以正确处理。
[ ] 错误类型可以正确处理。
[ ] 重复操作不会产生错误结果。
[ ] 数据为空时页面不会崩溃。

项目检查
[ ] 目录和代码风格符合项目规范。
[ ] 没有修改无关文件。
[ ] 没有重复实现已有工具。
[ ] 没有新增不必要的依赖。

安全检查
[ ] 没有提交密码、token 或 API Key。
[ ] 用户输入经过合理处理。
[ ] 权限和数据归属已经确认。
[ ] 没有把敏感数据打印到日志。

交付确认
[ ] 我理解代码的主要逻辑。
[ ] 我知道如何复现和验证功能。
[ ] 我保留了可以恢复的版本。

十三、总结

AI 写完代码后，真正重要的不是马上发布，而是完成一次有条理的验收。

今天我们学习了 5 个检查层次：

1. 语法检查：代码能不能被正确解析。
2. 运行检查：项目、页面和依赖能不能正常启动。
3. 功能检查：代码结果是否符合需求。
4. 边界检查：空值、异常和重复操作是否处理。
5. 项目检查：是否符合结构、规范、安全和修改范围。

可以把这套方法浓缩成一句话：

先确认代码能运行，再确认结果正确，最后确认它适合真实项目。

AI 可以帮助你写代码，也可以帮助你列测试清单和发现风险。

但真正的验收必须回到实际环境：

需求
  ↓
代码
  ↓
运行
  ↓
测试
  ↓
审查
  ↓
交付

下一篇文章，我们继续学习：

代码报错怎么办？正确使用 AI 排查错误。

---

✍坚持原创，求关注，点赞，收藏