按理说，

先说背景

我们团队接了一个内部需求：给运营团队做一个数据看板 + 工单程序。

需求不复杂。技术栈是 React + Node.js + PostgreSQL，正常排期两个人三周。但当时另一个同事被抽去救火了变成我一个人，排期不变。说起来，

我想，这不正好？上个月刚充了 Claude Code Max。Cursor 也续了费，这种 CRUD 项目，AI 写代码不是手到擒来？

于是我做了一个大胆的决定：全程用 AI 辅助开发，目标一周交付。

结果是——我确实一周写完了。代码量大概 万行，前后端 + 数据库 + 部署脚本，全套。

但上线后第一天就出了三个线上事故。说起来，

这篇文章。我会把这 天的真实经历和踩的 个坑完整地写出来。不是为了黑 AI，AI 确实让我效率提高了 倍以上。但那些"AI 写代码真香"的文章不会告诉你的暗面我来说。按理说，

坑 ：AI 生成的代码"看起来对"。但数据边界全是雷

第三天我让 Claude Code 帮我写了一个数据聚合接口，把工单按部门、状态、时间维度做分组统计。

AI 给的代码很漂亮：

async function getTicketStats {
const result = await db.query(`
SELECT
department,status。DATE_TRUNC as date,COUNT as count
FROM tickets
WHERE created_at BETWEEN $1 AND $2
AND
GROUP BY department,status,DATE_TRUNC
ORDER BY date DESC
`,);老实说，return result.rows;}

一眼看去，没问题。测试环境跑了一下数据出来了图表也渲染了。

上线后的表现：运营总监说"这个数据不对"。

• 时区问题: Date_TRUNC 默认用的是 UTC，但运营看的是北京时间。跨天的工单被归到了前一天。怎么说呢，
• 空值处理: 当 department 传 null 时“$ IS NULL”这个条件在 PostgreSQL 中的行为不是“忽略过滤”。而是匹配 department IS NULL 的记录。
• 大分页缺失: 没有 LIMIT。当时间范围选了一整年，直接返回万行数据，让前端图表库 echarts 卡死。按理说，

说到痛点。业务层面与技术实现脱节，一旦出现业务错误，即使 AI 写得“无错”，仍会导致线上故障。

再看修复后的代码，

async function getTicketStats {
const conditions =;const params =;if {
conditions.push;params.push，}
const result = await db.query(`
SELECT
department,status,DATE_TRUNC as date。COUNT as count
FROM tickets
WHERE ${conditions.join}
GROUP BY department,status,date
ORDER BY date DESC
LIMIT 1000
`,params);return result.rows;}

从教训来看。AI 不懂你的业务时区，不懂你的使用者是谁，不懂你的数据量级。这些上下文，它不会主动问你，你不说它就不管。

Pitfall: AI excels at “building wheels”。but never tells you re are existing ones.

痛点的观点是，把精力浪费在重复造轮子上，而非解决真正业务痛点，加重技术债务和开发成本。

# 第二天 - 文件上传模块

• Ai 写近千行代码：分片逻辑、MD5 校验、后端合并、进度回调等…，话说回来，
• "好厉害"。但可以用 TUS 协议搞定！
• Ai 默认从零实现，而不是搜索成熟方案；训练目标是生成代码，而非帮你少写代码。
• Ai 能做到快速实现，但缺乏环境视角与维护性考虑。

再看教训。 在让 AI 写代码之前先问它是否有成熟方案，并比较优缺点，可省掉大量重复工作与潜在风险！按理说，

Pitfall: Copy-pasting AI-generated env variables almost leaked DB password into Git.

• Ai 给出的 .env.example 包含占位符。却没有提醒要改为安全模式；提交前未检查缓存导致密码泄露风险极高！

DATABASE_URL=postgresql://admin:your_password_here@localhost:/dashboardJWT_SECRET=your-super-secret-key-change-thisREDIS_URL=redis://localhost:

• 永远不要在 AI 生成功能模板里直接填写真实密钥！老实说，
• 提交前必须 git diff --cached 检查暂存区！
• IDEs 或 CI 可集成 git-secrets 自动阻止密钥提交！如:

git secrets --install
git secrets --register-aws
git secrets --add 'password\s*=\s*.+'

Pitfall: AI-generated unit tests have % coverage but are self-hyping!

• Ai 写出的测试只验证 mock 的返回值是否与预设一致。本质上是“自嗨”，没有真正覆盖业务逻辑或边界场景；导致上线后 bug 滚雪球而来！

// AI generated test example
describe => {
it => {
const mockTicket = { title: 'Test Ticket'。description: 'Test Description',department:'Engineering',priority:'high' };db.query.mockResolvedValue;const result = await createTicket;话说回来，expect.toEqual;expect.toHaveBeenCalledTimes;})，});

• Ai 会先 mock 返回值。接下来断言相等——这永远不会失败，因为测试自己“骗”mock框架，而非真正执领域务流程；老实说，
• true unit tests should focus on boundary conditions and error handling;e.g.,empty title → validation error;老实说，invalid priority → rejection;DB failure → proper error propagation;concurrency → idempotence;
• If you want real coverage from an AI helper—ask it to list all potential edge cases and generate tests for those!}

Pitfall : Speed too fast == design skipped == technical debt explodes after a week.

• The hidden pitfall is that developer skipped any architectural design entirely because of rapid coding pace enabled by AI—no API contracts defined before coding;no ER diagram;怎么说呢，no component props planning;everything was written on--fly.
• This leads to problems when new requirements arrive – e.g.,“transfer” feature needs historical assignment chain;“approval flow” requires state machine logic—all of which would have been easier if designed upfront.
If you'd like help creating an architecture review before coding starts: txt Please help me do this design:
• Database ER diagram
• API contract
• Front-end page routing structure.
• Where do you think this system could hide technical debt?

复盘这方面。一周后的反思

AI 确实帮了我：

万行代码，如果纯手写至少要三周；
很多样板AI 一键生成；
对于陌生库，Ai 比翻文档快数倍；其实，

能力	AI 能做	AI 不能做
理解业务上下文	快速生成相应功能	理解整体商业价值及长期演进
编程能力	生成标准化代码	深度架构设计
快速识别边界场景	列出常见错误及测试框架	评估安全性与合规风险
可视化/配置生成	自动填充 UI 与数据库结构	判断哪些配置对项目最关键
Debug 分析日志	基于提示定位常见错误	整体分析线上复杂环境变化

我的最终版本工作流:

-        让 AI 做架构设计+自己评审 → 小时  

-        定义 API 契约和数据模型→ 小时 

-       & nbsp;A i 生成编码＋自己逐文件 Review → 主导开发时间

-&amp，amp;amp，-&amp，amp;amp，-&amp，amp;amp，-&amp，其实，amp spaces;-自寫主要業務邏輯測試 -A i 补充工具函数測試 - 上線前安全檢查清單 --- # 關鍵原則 AI 是副駕駛，不是自動駕駛。你可以讓它幫你打方向盤，但你不能閉著眼睛。--- ## 寫在最後 我要說的是的观点是。「如果這些代碼，你敢不看直接上線嗎？」 如果答案是不是——那麼利用 A i 所節省下來的時間就應該投放到 Review 上。如果你也正在使用 A i 編程。那麼歡迎留言分享自己的踩坑經驗，我會持續更新實戰心得。老实说，--- ©2026 A i 開發者社群 | 保留所有權利 <\/footer>'