同样是做中文平台自动化，有的团队一周后就停了：Token 成本飙升、登录态反复失效、脚本一改版就崩。基于 opencli 仓库与 opencli.info 的实测，我把“高频任务低成本落地”的路径拆成可执行步骤：安装连通、中文平台命令验证、插件扩展、CDP 远程执行、退出码分流与报错修复。按文中命令操作，你今天就能把 B 站/知乎/微信公众号流程接进脚本和 CI。

大家好，我是 iDao。10 年全栈开发，做过架构、运维，也在落地 AI 工程化。这里不搞虚的，只分享能直接跑、能直接用的代码、方案和经验。内容包括：全栈开发实战、系统搭建、可视化大屏、自动化部署、AI 应用、私有化部署等。关注我，一起写能落地的代码，做能上线的项目。

1. 场景与问题现象

冲突就发生在同一个需求上：你要的是“每天稳定抓取中文平台数据”，但常见做法给你的却是“每次都重新推理、每月持续烧 Token、结果还不稳定”。再叠加账号登录态过期、平台页面改版、脚本输出字段漂移，很多自动化项目不是死在技术深度，而是死在长期可维护性。opencli 的价值点是把“站点能力”收敛成命令，统一输出 table/json/yaml/md/csv，并复用本机 Chrome 登录态，让高频重复任务回到可预测、可复用、可审计的轨道。

2. 根因分析

自动化项目不稳定，核心通常不是“命令不够多”，而是工程边界没定义清楚：第一，未知网站探索和已知站点批量任务混在一起；第二，认证链路散落在 Cookie 文件、环境变量和浏览器 profile 之间；第三，失败状态没有统一退出码，CI 很难做重试和分流。opencli 在仓库文档里明确了定位：它擅长“有适配器的站点 + 可重复任务 + 结构化输出”，不擅长未知站点的一次性探索。这个边界反而让它适合生产脚本。

3. 解决步骤

3.1 步骤一

先完成最小可用链路：安装 CLI、装 Browser Bridge、检查 daemon 与扩展连通，再跑一个公共命令和一个中文平台命令。这样可以把“环境问题”和“站点问题”快速分离。

npm install -g @jackwener/opencli

# 浏览器扩展安装后执行
opencli doctor
opencli daemon status

# 公共 API（无需登录）
opencli hackernews top --limit 5 -f json

# 中文平台（需要 Chrome 已登录）
opencli bilibili hot --limit 5 -f json
opencli zhihu hot -f yaml

3.2 步骤二

把“中文平台采集 + 文章归档”做成可复用脚本，并加插件能力。对于微信公众号和知乎，opencli 已提供 Markdown 导出命令，适合接入知识库或日报流水线。

# 下载公众号文章为 Markdown
opencli weixin download --url "https://mp.weixin.qq.com/s/xxx" --output ./weixin

# 下载知乎专栏并可选抓图
opencli zhihu download "https://zhuanlan.zhihu.com/p/xxx" --output ./zhihu
opencli zhihu download "https://zhuanlan.zhihu.com/p/xxx" --download-images

# 安装插件（示例：掘金热榜）
opencli plugin install github:Astro-Han/opencli-plugin-juejin
opencli plugin list

4. 关键参数说明

• -f/--format：建议在自动化链路里固定为 json 或 yaml。表格输出适合人工查看，结构化输出适合脚本解析和 AI 二次处理。
• OPENCLI_CDP_ENDPOINT：当你在远程服务器跑任务、无法加载本地扩展时，用该变量接入 CDP 端点（如 http://localhost:9222 或反向代理地址）。

5. 验证方式

建议按“连通性 -> 认证态 -> 命令稳定性 -> 退出码”四层验证。只要这四层都过，基本可以进入定时任务或 CI。

# 1) 连通性
opencli doctor

# 2) 认证态（中文平台）
opencli xiaohongshu search "AI 编程" --limit 3 -f json

# 3) 输出稳定性（重复两次比对字段）
opencli bilibili hot --limit 5 -f json > run1.json
opencli bilibili hot --limit 5 -f json > run2.json

# 4) 退出码分流
opencli bilibili hot 2>/dev/null
case $? in
  0)   echo "ok" ;;
  69)  echo "Browser Bridge 未连接" ;;
  77)  echo "账号未登录或登录过期" ;;
  75)  echo "临时失败，建议重试" ;;
esac

预期结果：公共命令稳定返回；中文平台命令在登录态有效时返回非空结构化数据；异常情况下退出码可用于自动化分流。

6. 常见报错与修复

• Extension not connected -> 去 chrome://extensions 检查扩展是否启用；再执行 opencli doctor 与 opencli daemon status。
• Unauthorized 或返回空数据 -> 在同一个 Chrome 用户里重新登录目标站点，刷新页面后重试命令。

7. 常见坑

• 把 opencli 当成“任意网站自动化”工具使用。它更适合有适配器的高频任务，未知站点建议先用 Browser-Use/Stagehand 探索，再沉淀适配器。
• 忽略退出码，只看 stdout。生产环境必须按 69/75/77 等退出码做重试或告警，不然排障会非常慢。
• 在 CI 容器里直接跑浏览器命令却没有 CDP 端点或扩展链路，导致本地可跑、服务器失败。

8. 快速自检清单

• Node.js 是否 >= 20，并且 opencli 已升级到最新版本。
• Chrome 是否已登录目标中文平台账号（B 站/知乎/小红书/微信）。
• opencli doctor、opencli daemon status 是否通过。
• 关键命令是否固定使用 -f json/-f yaml 供脚本消费。
• CI 是否按退出码设置了重试、降级与告警。

9. 今天就能做的下一步

1. 先把你最常用的 3 个中文平台命令跑通，并把输出统一成 JSON，接入现有脚本。
2. 把“未知站点探索”与“已知站点批处理”拆成两条流水线：前者用通用浏览器 Agent，后者用 opencli 做稳定执行。

实测下来，opencli 最有价值的不是“命令多”，而是把登录态、输出格式、退出码和扩展机制统一成工程可控面。对中文平台自动化尤其友好，因为它把大量重复动作前置成适配器能力。你可以把它作为 Agent 工具链里的“稳定执行层”，把 LLM 预算留给真正需要推理的环节。

关注 【iDao技术魔方】，获取更多全栈到AI可落地的实战干货。

前端做聊天气泡、瀑布流、富文本卡片和动态排版时，最难的往往不是把字显示出来，而是提前知道文本会占多高。传统方案通常依赖 DOM 读值，性能和准确性都容易出问题。Pretext 把这件事拆成可预计算和可复用两段，给出了可跑、可测、可验证的文本布局方案。本文会把它的核心思路、关键 API、适用场景、边界条件和落地方法一次讲透。

大家好，我是 iDao。10 年全栈开发，做过架构、运维，也在落地 AI 工程化。这里不搞虚的，只分享能直接跑、能直接用的代码、方案和经验。内容包括：全栈开发实战、系统搭建、可视化大屏、自动化部署、AI 应用、私有化部署等。关注我，一起写能落地的代码，做能上线的项目。

一、为什么这个项目突然被大量前端盯上了

问题现象

你只要做过下面这些界面，基本都碰过同一类问题：

• 聊天消息高度要先算出来，虚拟列表不能靠猜
• 标题要绕开图片或障碍物，CSS 做不到业务想要的效果
• 多语言按钮文案切换后，偶发换行导致布局抖动
• 瀑布流卡片高度依赖真实渲染结果，滚动时频繁读 DOM

根因分析

很多项目现在还在用 getBoundingClientRect()、offsetHeight 这类 DOM 读值去拿文本高度。单次看没什么，一旦和样式写入、状态更新交错，浏览器就可能被迫同步做 layout 和 reflow。这类开销在长列表、富文本、响应式场景里会非常明显。

Pretext 的定位很直接：它不是一个简单的排版小工具，而是一个“绕开 DOM 测量热路径”的文本布局库。它的核心目标不是把文字画出来，而是让你在不依赖实时 DOM 读值的前提下，稳定预测文本布局结果。

解决步骤

官方仓库给出的描述是：

• 纯 JavaScript/TypeScript 的 multiline text measurement 与 layout 库
• 支持多语言、emoji、混合双向文本
• 核心目标是绕开 DOM 测量，例如 getBoundingClientRect、offsetHeight

安装很简单：

npm install @chenglou/pretext

验证方式

这个项目当前 GitHub 星标已经超过 24k，说明它击中的不是边缘需求，而是前端长期存在、但一直没有被优雅解决的问题。

---

二、它最值钱的设计，不是“算宽度”，而是把热路径拆干净了

问题现象

不少文本测量方案也能算宽度、算高度，但一到窗口 resize、容器宽度变化、多语言切换，性能就开始掉。原因通常不是算法本身，而是每次变化都把整段文本重新测一遍。

根因分析

文本布局其实包含两类成本：

• 一次性成本：分段、空白处理、Canvas 测宽、缓存
• 高频成本：容器宽度变化后重新计算行数和高度

如果这两类成本混在一起，任何 resize 都会把重活重新做一遍。

解决步骤

Pretext 的核心 API 是两段式：

import { prepare, layout } from '@chenglou/pretext'

const prepared = prepare('AGI 春天到了. بدأت الرحلة 🚀', '16px Inter')
const { height, lineCount } = layout(prepared, 320, 20)

console.log(height, lineCount)

这里的分工很重要：

• prepare()：做一次性分析和测量
• layout()：只基于缓存结果做纯算术布局

官方文档明确说明，不要在同样的文本和配置上反复执行 prepare()。例如窗口宽度变化时，应该只重新执行 layout()。

关键参数说明

有 3 个参数必须认真对齐：

• font 这里不是随便传一个字号字符串，而是要和真实 CSS font 简写保持一致，包括字号、字重、字体族
• maxWidth 传入的是文本真实可用宽度，不是父容器的大概宽度
• lineHeight 必须和页面里真实使用的 line-height 一致，否则高度一定会偏

验证方式

官方 README 给出的当前基准快照里：

• prepare() 处理共享的 500 段文本，大约是 19ms
• layout() 对同样批次大约是 0.09ms

这个数据最关键的意义，不是“某个绝对值很快”，而是它把重活放在前面，把热路径做轻了。

---

三、真正让它和普通测量库拉开差距的，是第二组 API

问题现象

很多业务不是只想知道“这一段文本多高”，而是想知道“每一行怎么断、怎么排、能不能自己控制”。

比如：

• 消息气泡希望在不增加行数的情况下尽量缩窄宽度
• 标题要绕开图片走不同宽度的路径
• Canvas、SVG、WebGL 场景要自己控制逐行绘制
• 富文本里 inline chip、链接、代码片段要一起参与布局

根因分析

传统 DOM 方案通常只能拿到最终结果，很难把布局过程作为业务可用的 API 暴露出来。你能拿到高度，但拿不到每一行的断点、宽度、游标位置，更别说按变化宽度逐行布局。

解决步骤

Pretext 额外提供了一组更强的 API：

• prepareWithSegments()
• layoutWithLines()
• walkLineRanges()
• layoutNextLine()

例如逐行按变化宽度布局：

import { prepareWithSegments, layoutNextLine } from '@chenglou/pretext'

const prepared = prepareWithSegments(
  'A floated image changes each line width',
  '16px Inter'
)

let cursor = { segmentIndex: 0, graphemeIndex: 0 }
let y = 0

while (true) {
  const width = y < 120 ? 240 : 360
  const line = layoutNextLine(prepared, cursor, width)
  if (line === null) break

  console.log(line.text, line.width)
  cursor = line.end
  y += 24
}

这类能力意味着它不只是服务 DOM，也能服务 Canvas、SVG，甚至未来更适合服务端布局场景。

验证方式

案例站点已经把这些能力做成了可直接观察结果的页面，包括：

• Accordion
• Bubbles
• Dynamic Layout
• Editorial Engine
• Masonry
• Rich Text
• Justification Comparison

这点很重要。它不是 README 里的纸面 API，而是已经对应到具体可见的布局效果。

---

四、这个项目最厉害的地方，不是“有想法”，而是它做了足够重的验证

问题现象

文本布局最怕的，不是功能不够，而是看起来能用，实际一上多语言、多字体、多浏览器就开始错。中文、日文、阿拉伯文、泰文、缅甸文、emoji、软连字符、混合双向文本，一旦混在一起，很多局部优化都会失效。

根因分析

文本布局不是一个单纯算法题。它背后混着：

• 浏览器字体引擎差异
• 各语言的断行规则
• 空白处理
• 标点粘连规则
• emoji 和 grapheme 行为
• 浏览器特定 quirks

也正因为这样，很多“看起来更准”的方案，在真实浏览器和真实语料里并不一定成立。

解决步骤

Pretext 的研究日志里有几个结论非常有参考价值：

1. layout() 必须保持 arithmetic-only也就是热路径里不回头做 DOM 读值，不回头重测完整字符串。

2. 更可靠的修正，优先放在 prepare()包括预处理、标点 glue 规则、空白处理、分段策略，而不是把逻辑越堆越多地塞回热路径。

3. 有些路线试过之后被明确放弃了比如：

   • 在 layout() 中重建字符串再测量
   • 用隐藏 DOM 做准备阶段测量
   • 用 SVG getComputedTextLength()
   • 把更多“聪明逻辑”塞回高频路径

4. system-ui 不是安全选择 官方研究明确指出，在 macOS 上，Canvas 和 DOM 对 system-ui 的解析可能不一致。要追求准确性，应使用命名字体。

验证方式

这个项目并不是“作者说它准”，而是把验证体系做出来了。开发脚本里能看到一整套校验流程：

bun install
bun start
bun run check
bun run accuracy-check
bun run benchmark-check
bun run pre-wrap-check
bun run corpus-check

这意味着：

• 有浏览器准确性校验
• 有性能基准校验
• 有语料回归校验
• 有特定模式，例如 pre-wrap 的专项验证

这类工程化验证，才是这个项目真正值得高看一眼的地方。

---

五、它最先适合落地的，不是“花哨排版”，而是三类高回报场景

问题现象

很多人第一次看到 Dynamic Layout、Editorial Engine 这种 demo，会先被视觉效果吸引。但大多数团队最先能吃到收益的，并不是这些高级排版，而是那些本来就会频繁测量文本高度的普通业务组件。

根因分析

高回报场景的共性很简单：

• 文本多
• 尺寸变化频繁
• 现在依赖 DOM 读值
• 一旦卡顿，用户感知很强

解决步骤

我更建议优先从下面 3 类场景试：

1. 虚拟列表和消息流

例如 IM、评论流、通知流。文本高度如果能提前算出来，就能减少滚动过程中的实时测量和反复布局。

2. 聊天气泡和多行卡片

案例页里的 Bubbles 非常典型。它展示的不是“消息能换行”，而是“能在保持行数不变的前提下，把宽度收得更紧”。

3. 富文本卡片和编辑器周边布局

例如标签、链接、代码片段、chips 和正文混排。Pretext 的 richer layout API 更适合做这类需要细粒度控制的场景。

验证方式

最简单的验证方法，不是先接整个项目，而是拿一个你现在最依赖 DOM 测量的组件做 A/B 对比：

• 旧方案：getBoundingClientRect() 或 offsetHeight
• 新方案：同一字体和行高下，预先 prepare()，宽度变化时只 layout()

对比下面这些行为：

• resize 时是否更稳
• 长列表滚动时是否更顺
• 多语言切换时布局抖动是否减少
• 是否更容易做高度预测和虚拟化

---

常见报错和解决建议

报错 1：测出来的高度和真实页面不一致

原因

• font 参数和真实 CSS 不一致
• lineHeight 传错
• 在 macOS 上用了 system-ui

解决

• 用命名字体，例如 16px Inter
• 确保 line-height 用真实值
• 不要用模糊估算值替代真实样式参数

报错 2：textarea 内容里的空格、Tab、换行被吞掉

原因

默认模式是面向 white-space: normal 的，不会保留普通空格和硬换行。

解决

const prepared = prepare(textareaValue, '16px Inter', {
  whiteSpace: 'pre-wrap',
})

这个模式是 0.0.2 版本新增的，专门用于 textarea-like 文本。

报错 3：项目接上以后还是慢

原因

你把 prepare() 放进了高频路径，每次宽度变化都重新做一次。

解决

同一份文本和字体配置只做一次 prepare()，后续宽度变化只调用 layout()。

---

常见坑

• 把它当成完整字体渲染引擎。不是。它当前目标明确是常见网页文本布局，而不是全量字体引擎替代品。
• 用 system-ui 追求精确测量。官方研究已经明确提示，在 macOS 上这并不可靠。
• 忽略默认断行前提。它当前对齐的常见文本模型包括 white-space: normal、word-break: normal、overflow-wrap: break-word、line-break: auto。
• 把 demo 当成唯一价值。项目真正最先能落地的地方，往往是虚拟列表、卡片高度预测、消息流和富文本布局。
• 只看 README，不看研究日志。这个项目真正稀缺的部分，不是 API 名字，而是它公开了哪些路试过、哪些路放弃了。

---

快速自检清单

• 你的 font 是否和真实 CSS 完全一致
• 你的 lineHeight 是否来自真实样式值
• 同一段文本是否只 prepare() 了一次
• textarea 类内容是否开启了 whiteSpace: 'pre-wrap'
• macOS 场景是否避免使用 system-ui
• 是否先用小组件试点，而不是一次性重构整套排版逻辑

---

今天就能做的下一步

今天不要先想着“重构整个排版引擎”。更现实的动作是：

1. 找出一个现在最依赖 DOM 测量的组件例如消息气泡、卡片摘要、按钮文案校验
2. 保持视觉层不动只替换“文本高度预测”这一层
3. 做一次小范围对比 看 resize、滚动、多语言切换时是否更稳

如果这一步能跑通，你再考虑把它逐步扩到消息流、虚拟列表或富文本卡片场景。

收尾

Pretext 这波真正值得关注的，不是“又一个排版库”，而是它把文本测量从浏览器临时求值，拆成了可预计算、可缓存、可验证的工程模型。对做复杂前端的人来说，这个方向比一个新 API 更重要。它未必会替代所有布局方案，但已经足够成为高性能文本 UI 的一个底层能力候选。

关注 【iDao技术魔方】，获取更多全栈到AI可落地的实战干货。

上周三晚上十一点，一个朋友发我消息，说他的项目刚上线三小时，服务直接崩了。

他排查到凌晨两点，最后发现问题出在一段「AI帮他生成的查询代码」上——循环里套了个没加限制条件的数据库查询，本地测试五条数据完全没问题，生产环境一跑，几千条数据直接把服务打趴下了。

他说了一句话我印象很深：「我以为AI比我严谨，没想到它比我还粗心。」

说实话，这种事我身边不止他一个。

用AI写代码这件事，大家现在基本上分两个阶段：

第一阶段，觉得AI是神，什么都敢往里扔，写完直接用；
第二阶段，被坑过一次之后，开始明白——AI生成的代码，跑通只是起点，能不能上线是另一回事。

我自己也踩过坑。今天这篇，就把我收集到的、程序员被AI代码坑得最惨的5个bug类型，一个一个说清楚，每个都附修复方案，最后给一个可以直接拿去用的校验清单。

---

🪤 坑一：边界条件像不存在一样

AI写代码有一个特点：它给你的往往是「教科书版本」的逻辑，也就是输入都合法、网络永远不断、用户不会乱操作的理想版本。

举个真实场景：

有人让AI写了一个解析用户上传文件的函数，逻辑很流畅，代码也很干净。但文件为空呢？文件格式不对呢？文件超过大小限制呢？

一个都没判断。

本地跑了个正常的文件，没问题，上线了。然后用户传了一个0字节的文件，直接报 NullPointerException，整个上传模块崩掉，还把后台日志刷成了红色。

修复思路：

每次拿到AI生成的函数，脑子里跑一遍：

• 入参为空/null/空字符串时，会发生什么？
• 列表为空时，会发生什么？
• 网络超时/接口返回错误时，会发生什么？

把这几个场景加进去，基本能堵住90%的边界问题。

// AI原版（没有任何边界处理）
function parseFile(file) {
  const content = fs.readFileSync(file.path, 'utf-8');
  return JSON.parse(content);
}

// 加完边界判断之后
function parseFile(file) {
  if (!file || !file.path) {
    throw new Error('文件对象无效');
  }
  if (file.size === 0) {
    throw new Error('文件内容为空，请重新上传');
  }
  const content = fs.readFileSync(file.path, 'utf-8');
  try {
    return JSON.parse(content);
  } catch (e) {
    throw new Error('文件格式错误，请上传合法的JSON文件');
  }
}

---

🐌 坑二：性能陷阱藏在看不见的地方

这个坑更隐蔽，因为它在本地完全没有症状。

最经典的一种：循环里查数据库。

AI写批量处理逻辑的时候，特别容易生成这种代码——遍历一个列表，列表里每个元素都查一次数据库，逻辑完全正确，但查询次数和数据量成正比。

数据量小的时候，没感觉。等到真实用户数据进来，一个请求发出去，后端发了一百多条SQL，响应时间直接从200ms变成20秒。

// AI生成版（N+1查询，数据量一大就崩）
async function getOrderDetails(userIds) {
  const result = [];
  for (const userId of userIds) {
    const orders = await db.query('SELECT * FROM orders WHERE user_id = ?', [userId]);
    result.push({ userId, orders });
  }
  return result;
}

// 正确版（一次查完，内存里分组）
async function getOrderDetails(userIds) {
  const orders = await db.query(
    'SELECT * FROM orders WHERE user_id IN (?)',
    [userIds]
  );
  return userIds.map(userId => ({
    userId,
    orders: orders.filter(o => o.user_id === userId)
  }));
}

review这类问题的习惯： 看到循环就问自己「这里有没有数据库操作或者网络请求」，有的话，基本就要改。

---

🔓 坑三：安全漏洞，AI不会主动告诉你

这是最严重的一类。

AI对安全问题的默认处理态度是：不处理。它给你一个能跑的方案，安全防护得你自己加。

最常见的两个：

1. SQL注入

# AI生成版（直接拼接字符串，典型的SQL注入漏洞）
def get_user(username):
    query = f"SELECT * FROM users WHERE username = '{username}'"
    return db.execute(query)

# 安全版（参数化查询）
def get_user(username):
    query = "SELECT * FROM users WHERE username = ?"
    return db.execute(query, (username,))

如果有人传入 username = "'; DROP TABLE users; --"，第一种写法这个表就没了。

2. XSS（跨站脚本攻击）

前端项目里，AI经常生成 innerHTML = userInput 这种写法，看起来没问题，但你不知道用户会在输入框里塞什么内容。

// 有漏洞
container.innerHTML = userInput;

// 安全版
container.textContent = userInput;
// 或者用成熟的转义库处理富文本

凡是和用户输入相关的代码，一定要专门过一遍安全检查，别指望AI主动提示你。

---

🧱 坑四：业务逻辑全靠魔法数字撑着

这个坑当时不疼，三个月后会让你想哭。

AI写出来的业务逻辑，里面经常有一堆「魔法数字」——比如状态码直接写 if (status === 2)，折扣直接写 price * 0.85，超时直接写 timeout = 30000。

这些数字是什么意思？2 代表什么状态？0.85 是哪个活动的折扣？30000 是哪个接口的超时？

代码里没有任何说明。

三个月后需求一变，你看着一堆裸数字，完全不知道哪个能改、哪个不能改，只能一行一行看逻辑、一个一个猜。

// AI版（魔法数字，半年后改不动）
function calcPrice(price, userType) {
  if (userType === 2) {
    return price * 0.85;
  } else if (userType === 3) {
    return price * 0.75;
  }
  return price;
}

// 可维护版
const USER_TYPE = {
  NORMAL: 1,
  VIP: 2,
  SVIP: 3
};
const DISCOUNT = {
  [USER_TYPE.VIP]: 0.85,   // VIP会员九折
  [USER_TYPE.SVIP]: 0.75,  // SVIP会员七五折
};

function calcPrice(price, userType) {
  const discount = DISCOUNT[userType] ?? 1;
  return price * discount;
}

改动很小，但三个月后的你会感谢现在的你。

---

📄 坑五：注释和代码讲的不是同一件事

这个坑我觉得是最无语的。

AI写注释有时候是根据函数名「猜」逻辑写的，代码实现换了，注释还是老的。或者注释说「返回用户列表」，代码里其实返回的是分页对象，里面才有列表。

这类问题上线当时不会崩，但后续维护的人（可能就是一个月后的你）会被这些注释完全误导，在错误的方向上排查半天。

// 注释说返回boolean，代码里其实返回number状态码
/**
 * 验证用户权限
 * @returns {boolean} 是否有权限
 */
function checkPermission(userId, resource) {
  // 实际上返回 0/1/2 代表不同权限等级
  return db.getPermissionLevel(userId, resource);
}

检查方法很简单：生成完代码之后，单独让AI「对照代码重新生成注释」，别直接用第一次生成的。

---

✅ AI代码校验3步法（用完再提交）

说了这么多坑，给一个提交前可以直接用的检查流程：

第一步：边界 + 异常覆盖检查（2分钟）

• 函数入参为空时有没有处理？
• 异步操作有没有 try/catch？
• 列表操作前有没有判空？

第二步：性能热点扫描（1分钟）

• 循环内有没有数据库查询或网络请求？
• 大数据处理有没有分页或流式处理？
• 是否有不必要的重复计算？

第三步：安全敏感点过筛（2分钟）

• 用户输入有没有做过滤/转义？
• SQL查询有没有用参数化？
• 接口返回有没有暴露不该暴露的字段？

整套流程5分钟不到，能挡掉绝大多数上线前的定时炸弹。

---

写在最后

AI写代码这件事，我现在的态度是：用，但不完全信。

它是一个效率工具，不是一个质量保证。代码能跑是它的工作，代码能上线是你的工作。

这5类bug，是我收集到的大家被坑最多的场景。你踩过哪类，欢迎评论区聊聊。

我把完整的《AI写代码10条避坑清单+校验模板》整理好了，包含前端/后端/AI应用全场景的对照表，后台回复**「避坑」**直接发给你，复制就能用。

公众号关注 【iDao技术魔方】 ，每天一篇可落地的AI/前端实战干货。