深入 · 怎么读懂 AI 写的代码

一句话：它会补全它认为「该有」的代码，而不是你项目真实需要的代码。所以它假设了很多没跟你确认的前提。

它是怎么工作的

AI 写代码时，它看到的是一个片段——你的几句描述、加上现有的几个文件。它会按「一个规范的、完整的、教科书式的实现」去补全。问题是：「教科书式的完整」不等于「你这个项目需要的完整」。

入口就是「这个项目从哪开始跑」。找到入口，才有地方开始读。不找入口直接全文搜索，是最慢的方式。

Node / Express 后端

"scripts": {
  "dev:server": "npm run dev -w @delimao/server",
  "db:migrate": "npm run db:migrate -w @delimao/db"
}

// apps/server/src/index.ts 大致长这样
app.use('/trpc', trpcRouter)        // ← 所有接口都在这一个挂载点
app.use(express.json())             // ← 中间件：解析请求体
app.listen(3000)                    // ← 端口在这

React / Vue 前端

以「查一个型号的报价」为例——这是你 delimao-system 里最核心的功能。追完这六站，你就懂了这个项目最值钱的那部分。

依赖是你看不懂但正在运行的代码。追它只需要三层，每层一个命令。

# 看它的目录结构
ls node_modules/<包名>/

# 看它的入口文件是谁（从 package.json 的 main / exports 读出来）
cat node_modules/<包名>/package.json

# 直接看它的入口文件在干什么
head -50 node_modules/<包名>/<入口文件>

N+1 = 本该一次查完的东西，代码在循环里查了 N 次。名字里的 N 是「条数」。这是 AI 生成代码里最常见、也最隐蔽的性能问题——因为它在数据少的时候完全看不出来。

坏例子和好例子对照

// ✗ 坏：3 条数据 = 1 + 3 = 4 次数据库往返
const orders = await db.select().from(orders)      // 1 次
for (const order of orders) {
  // ✗ 在循环里 await 查询！
  const items = await db.select().from(items)
    .where(eq(items.orderId, order.id))             // 每条1 次
  order.itemCount = items.length
}

// ✓ 好：2 次查询，用一条 IN 把所有 id 打包查回来
const orders = await db.select().from(orders)      // 1 次
const ids = orders.map(o => o.id)
const allItems = ids.length
  ? await db.select().from(items).where(inArray(items.orderId, ids))  // 1 次
  : []
const countMap = new Map()
for (const it of allItems) {
  countMap.set(it.orderId, (countMap.get(it.orderId) ?? 0) + 1)
}
for (const order of orders) {
  order.itemCount = countMap.get(order.id) ?? 0
}

异常处理是 AI 生成代码里问题最集中的地方，因为它「看起来处理了」。三种坏味道，按危险程度排。

坏味道 ① catch {} 空吞——最危险

// ✗ 吞掉异常：出错了，但我假装没发生
try {
  await saveOrder(order)
} catch (e) {
}

// ✗ 只记个日志就完事：记了，但没恢复，也没往下报
try {
  await saveOrder(order)
} catch (e) {
  console.log('出错了', e)
}

// ✓ 至少要说清楚发生了什么，并让它能被注意到
try {
  await saveOrder(order)
} catch (e) {
  logger.error('保存订单失败，orderId=' + order.id, e)
  throw new Error('保存订单失败，请稍后重试', { cause: e })
}

为什么空吞最危险：它把「崩溃」变成了「静默失败」。崩了你会看到界面报错、会去查；吞掉了，程序继续往下跑，然后返回一个错的结果——你可能一个月后在客户对账时才发现数据没存上。

坏味道 ② catch 之后返回默认值——最隐蔽

// ✗ 调用方以为成功了，其实拿到的是假数据
async function getPrice(modelNo) {
  try {
    return await calcPrice(modelNo)
  } catch (e) {
    return 0        // ← 0 会被当成「 legitimately 价格为 0」
  }
}

// ✓ 要么明确失败，要么明确说「这是默认值」
async function getPrice(modelNo) {
  try {
    return await calcPrice(modelNo)
  } catch (e) {
    logger.error('算价失败，modelNo=' + modelNo, e)
    throw new Error('算价失败')    // ← 明确失败，让调用方知道
  }
}

SQL 注入 = 把用户输入直接拼进 SQL 字符串里。攻击者可以通过输入内容，改变这条SQL 的含义，从而读到或改掉他不该碰的数据。

// ✗ 危险：字符串拼接
const sql = "SELECT * FROM users WHERE id=" + id
const sql2 = `SELECT * FROM orders WHERE name='${name}'`
// 如果 name 是：' OR '1'='1
// 拼出来是：SELECT * FROM orders WHERE name='' OR '1'='1'
//        → 条件永远成立 → 整表数据全被读出来

// ✓ 安全：参数化查询（占位符 + 单独传值）
const rows = await db.execute(
  sql`SELECT * FROM users WHERE id = ${id}`
)
// 或者用 ORM / query builder，让参数自动被转义
const rows = await db.select().from(users).where(eq(users.id, id))

装依赖就是把别人写的代码放进你的系统。它现在能读你的数据、能往外发请求。所以它需要定期看一眼。

# 一条命令看全项目的已知漏洞
npm audit

# 更详细（能看到每个漏洞的严重程度和影响范围）
npm audit --json

# 自动修复能修的（修完一定要跑一遍测试）
npm audit fix

三个现实做法

你现在全盘 0 个测试文件（*.test.* / *.spec.* 一个都没有）。这是最该补的一件事，而且它没有你想象的那么难。

最小起步路径（不要求上全套）

import assert from 'node:assert/strict'

// 断言 1：真实型号能解析出正确的关键字段
const r = parseModelNo('DL-2409-1')
assert.equal(r.series, 'DL')
assert.equal(r.width, 2409)

// 断言 2：非法型号要明确报错，而不是返回垃圾
assert.throws(() => parseModelNo('乱写的型号'))
//            ↑ 这一条特别重要：它验证「异常是抛出来的」，
//              正好挡住第 06 节的坏味道 ②

用 -w @delimao/server 这种包名执行命令时，实际工作目录是那个包，不是根目录。你在根目录搜 src/index.ts 可能什么都搜不到，因为文件在 apps/server/src/ 里。对策：先确认 cwd（当前目录）是什么，再决定搜哪里。

README 会过期，scripts 一般不会。AI 生成的项目里，README 经常是「看起来很完整但命令是编的」。以 scripts 为准。

追到第三站发现「怎么这么绕」，就改成全文搜索。那你永远不知道是哪一环断了。链子的价值就在于它完整——断在哪一环，就是问题所在。

有些包几十万行代码，从头读是浪费时间。你只需要看它的入口文件和README——看它的「对外承诺」是什么，而不是它的内部实现。大多数包你永远不需要读源码，只需要知道它对外做什么。

这是这一篇最重要的一条。
AI 会非常自信地告诉你「我已经加了测试，覆盖了主要路径」——它可能只是「打算加」，或者测试文件里只有一个空的 describe，或者测试跑起来全是空的断言（什么都不检查，直接通过）。
你必须亲眼看到三样东西：① 测试文件真实存在（不是它说的，是你在磁盘上看到的）；② 里面有真实的断言（有具体的输入和具体的期望值，不是空跑）；③ 你把它改坏，它真的会失败——最后这条是唯一的验证方式：你故意把被测的那行代码改错，跑一次测试，看到它红了，才算确认这个测试是有用的。
你项目现状就是最好的例子：测试 0 个。如果当初AI 说「已测试」，你信了，那这个数字会比你以为的更难发现。所以这条红线不是理论问题，是你已经遇到过的模式。

• ✓我能解释 AI 补全代码的机制：它补它认为该有的，不补我项目真实需要的
• ✓我知道审查的本质不是「找 bug」，是「把它的假设挖出来」
• ✓我知道生产 400 单 97% 无尺寸，是因为「有没有尺寸」是业务规则，不是类型校验能挡的
• ✓我会按项目类型定位入口：Node 看 scripts → main → app.use；前端看 package.json → 路由配置 → 页面组件
• ✓我知道 -w @delimao/server 的工作目录是那个包，不是根目录
• ✓我能画出报价的六站调用链：组件 → tRPC client → server router → engine → db → 返回
• ✓我知道 tRPC 前后端同名是追链子最省力的原因（追库那 2 个项目都靠它）
• ✓我会依赖三层追法：package.json 声明 → node_modules 实际做的 → 在我代码里被怎么调
• ✓我知道0 个 Redis / 0 个消息队列 / 0 个 WebSocket 是好事——依赖少=攻击面小=能读懂
• ✓我能解释 N+1 是什么，以及为什么 100 条没事、10 万条卡死
• ✓我知道 N+1 的三个发现方法，最可靠的是看 Network 面板同一接口请求了几十次
• ✓我能说出异常处理三种坏味道：空吞 / 只 log 不恢复 / 返回默认值
• ✓我知道判断标准：catch 之后有没有把「我出错了」传出去
• ✓我知道静默失败的代价不是不好看，是失去了发现问题的能力（LumenX 两天重启 482 次）
• ✓我能识别 SQL 拼接，也知道 tRPC + zod + ORM 已经挡了一层但不能全靠它们
• ✓我知道动态排序字段和表名是重灾区（列名不能参数化，必须白名单）
• ✓我知道 npm audit 怎么用、^ vs固定版本的区别、单项目内部版本要统一
• ✓我知道我的测试起步路径：挑纯函数 → 用 node:assert → 改 bug 先补复现测试
• ✓我知道 packages/engine/test/run.ts 的 6 个型号断言已经是正确起点，不用等学完框架
• ✓我守住的红线：不把「AI 说它测过了」当证据，要看真实测试文件，并验证「改坏了它真的会失败」