如果只看演示视频，AI 编程几乎是完美的。

输入一句：

帮我做一个后台管理系统。

几分钟以后：

页面有了
接口有了
数据库有了
测试也有了

看起来开发效率直接提高十倍。

但真正把 ChatGPT、Plus、Pro、Codex 放进日常开发以后，会发现事情没有这么简单。

AI 确实能显著提高开发效率。

但与此同时，它也会带来一批新的工程问题。

例如：

代码写得太快

可能导致：

Review 跟不上

Agent 修改文件太方便，可能导致：

一个小需求改了几十个文件

模型非常自信，又可能导致：

代码看起来正确
实际上没有运行

所以到了 2026 年，我认为开发者真正需要掌握的已经不只是：

怎么让 ChatGPT / Codex 帮我写代码？

还包括：

怎么避免 AI 把项目越改越乱？

下面整理 15 个我认为非常常见的 AI 编程坑。

如果已经开始使用 ChatGPT Plus、Pro、Codex 做真实项目，这些问题基本迟早都会遇到。

---

一、坑 1：一句话就让 Codex 开始改代码

这是最常见的情况。

比如：

帮我优化一下登录系统。

然后 Agent 直接开始：

修改 auth.ts

接着：

修改 session.ts

再：

修改 middleware.ts

最后：

顺手重构 API

问题是：

“优化”到底是什么意思？

可能是：

性能优化

也可能是：

安全优化

也可能只是：

修一个登录超时问题

任务越模糊，Agent 自由发挥越多。

更好的方式

先写：

先不要修改代码。

请分析当前登录系统，并说明：

1. 当前认证流程；
2. 主要模块；
3. 已知问题；
4. 可能的改进点；
5. 哪些修改风险最高。

等我确认以后再实施。

核心原则：

Explore
↓
Plan
↓
Implement

不要：

Prompt
↓
直接改

---

二、坑 2：以为 AI“看懂了项目”

AI 输出：

我已经理解当前项目架构。

很多人就真的默认：

它理解了。

其实未必。

尤其项目比较大时，Agent 可能只看了：

几个入口文件

然后根据经验推测整个系统。

例如它看到：

auth.ts

就假设：

所有认证逻辑都在 auth.ts

结果真正权限判断其实还藏在：

middleware
service
database trigger

里面。

我的习惯

不要问：

你理解了吗？

而是让它证明。

例如：

请告诉我：

登录请求从浏览器发出以后，
完整经过哪些文件和函数，
最终在哪里生成 Session。

列出真实调用链。

如果它能准确列出：

login page
↓
api/login
↓
AuthService.login
↓
verifyPassword
↓
createSession
↓
Redis

那才说明它至少真正调查过。

所以：

不要相信 AI 说“我懂了”，要让它展示理解过程的结果。

---

三、坑 3：一次让 AI 修改太多文件

这是 Coding Agent 特别容易出现的问题。

例如一个需求：

修复订单页面金额显示错误。

正常可能修改：

1～3 个文件

Agent 最后：

Changed 19 files

包括：

订单组件
价格工具
API
数据库模型
类型定义
UI组件
测试
配置

这时候就应该警惕了。

因为：

Change Surface 越大

通常意味着：

潜在回归风险越大

推荐规则

在 AGENTS.md 或 Prompt 里加入：

Prefer the smallest reasonable change.

Do not refactor unrelated code.

If the task requires touching more than 5 files,
explain why before proceeding.

虽然“5 个”不是绝对标准，但这种限制可以强迫 Agent：

先思考修改范围

而不是：

想到哪里改到哪里

---

四、坑 4：AI 为了修 Bug，顺便把架构重构了

例如原本只是：

修复用户退出后页面没有跳转

AI 看到代码以后说：

当前认证逻辑耦合度较高，我将顺便进行结构优化。

然后：

拆 Hook
改 Context
重写 AuthProvider
改变 Router

最后 Bug 修好了。

但是 Pull Request：

+1300
-900

这种修改特别难 Review。

原则

Bug Fix 应该尽量满足：

Bug Fix ≠ Refactor

可以直接告诉 Codex：

This is a bug-fix task.

Do not perform architectural refactoring.

If you identify architectural problems,
report them separately after fixing the bug.

这句话非常实用。

---

五、坑 5：测试通过，就认为功能正确

这是非常危险的一个误区。

Agent 最后告诉你：

Tests: 43 passed

看起来很完美。

但可能存在两个问题。

第一：

测试本来就没覆盖这个 Bug

第二：

Agent 修改了测试

让测试适配新代码。

结果就是：

100% tests passed

但业务已经发生错误变化。

正确做法

要求它告诉你：

哪些测试原来就存在？
哪些是新增的？
哪些已有测试被修改？
为什么修改？

例如：

List separately:

Existing tests executed

New tests added

Existing tests modified

For every modified existing test,
explain why its expected behavior changed.

尤其 Legacy 项目，非常重要。

---

六、坑 6：为了消灭 TypeScript 报错，疯狂使用 any

这个我相信很多人都遇到过。

原本：

const response = await api.getUser()

TypeScript 报错。

AI 修改：

const response: any = await api.getUser()

完成。

或者：

// @ts-ignore

错误没了。

但问题没有解决。

只是：

TypeScript 不再提醒你了

推荐规则

直接加入：

Do not use:

- any
- @ts-ignore
- @ts-nocheck

unless explicitly approved.

Fix the underlying type mismatch instead.

真正目标应该是：

Type Safety

不是：

0 TypeScript Errors

这两件事情不是一回事。

---

七、坑 7：AI 特别喜欢增加依赖

例如你说：

帮我格式化一个日期。

AI：

npm install date-fns

你说：

实现一个简单重试。

AI：

npm install p-retry

你说：

生成 UUID。

又来一个包。

最后：

package.json

越来越长。

实际很多能力：

项目现有依赖

或者：

运行环境原生 API

已经可以完成。

建议写入项目规则

Before adding a dependency:

1. check whether an existing dependency already supports it;
2. check whether the runtime provides native support;
3. estimate implementation complexity without the dependency.

Do not install new packages for trivial functionality.

依赖不是免费的。

每一个依赖都有：

升级成本
安全风险
Bundle Size
维护风险

---

八、坑 8：让 Agent 直接接触生产环境

Coding Agent 最大的区别是：

普通 ChatGPT：

建议你运行命令

Codex 一类 Agent：

可能真的执行命令

所以权限问题必须认真对待。

例如：

生产数据库

AWS Key

服务器 SSH

支付系统 Secret

没有必要就不要暴露。

特别是下面这种需求：

帮我看看生产数据库为什么慢。

更稳妥的方式往往是：

日志
Query Plan
脱敏 Schema
测试环境
只读环境

先给 Agent 分析。

核心原则还是：

Least Privilege

即：

最小权限原则

Agent 需要什么，就给什么。

---

九、坑 9：把 .env、Token、API Key 全部放进上下文

这个问题和前一个类似。

为了让 AI：

帮我配置项目

很多人会直接复制：

.env

里面可能有：

DATABASE_URL
OPENAI_API_KEY
STRIPE_SECRET_KEY
AWS_SECRET_ACCESS_KEY

这不是好的工程习惯。

即使是在受控环境里，也应该保持：

Secrets 最小暴露

推荐把：

真实 Secret

替换成：

占位符

例如：

DATABASE_URL=<DATABASE_URL>
STRIPE_SECRET_KEY=<STRIPE_SECRET_KEY>

让 AI 理解结构通常就已经足够。

---

十、坑 10：让 AI 同时“Review + 自动修改”

比如：

Review 代码并把发现的问题全部修好。

看起来效率非常高。

但问题是：

Agent Review
↓
发现问题
↓
直接修改
↓
产生新的 Diff
↓
继续 Review
↓
继续修改

最后你很难判断：

哪些是原问题

以及：

哪些是 AI 后来产生的问题

我更推荐：

Review

和：

Fix

分开。

第一步：

Review the current Git Diff.

Do not modify files.

Report findings only.

人工判断。

然后：

Fix findings 1, 3 and 4 only.

Do not address other findings.

这样可控很多。

---

十一、坑 11：Prompt 写得特别长，但没有边界

很多人学 Prompt Engineering 后，会写：

你是一位拥有20年经验的世界顶级架构师，
精通Java、Python、Go、Rust……

写 1000 字。

最后真正需求只有：

修一下接口超时。

真正重要的其实不是：

角色设定

而是：

Goal
Scope
Constraints
Verification

例如下面这段反而更有效：

Goal:

Reduce /api/orders P95 latency.

Constraints:

- API response must remain unchanged.
- No database schema changes.
- No new dependencies.
- No caching in this iteration.

First investigate the bottleneck.

Do not modify code until you identify the likely cause.

这就是我现在越来越认可的思路：

少一点角色扮演，多一点工程边界。

---

十二、坑 12：让 AI“优化整个项目”

以下 Prompt 建议慎用：

帮我全面优化这个项目。

因为“优化”可以包含：

性能
架构
目录
命名
依赖
数据库
安全
UI
测试

基本等于：

请自由发挥

最终很容易变成：

巨型 Pull Request

更好的方式

分阶段。

例如：

阶段 1：
只做性能 Audit，不修改。

阶段 2：
只处理最高优先级数据库查询问题。

阶段 3：
补对应性能测试。

阶段 4：
Review。

复杂项目永远优先：

Small Task

而不是：

Big Bang

---

十三、坑 13：忽略 AI 的“幻觉文件”和“幻觉 API”

即使 Agent 可以访问仓库，也不代表完全不会出现错误推断。

例如它可能告诉你：

修改 src/services/userService.ts

但项目根本没有这个文件。

或者：

使用框架的 XXX API

实际上当前版本并不存在。

所以尤其涉及：

框架 API
SDK
云服务
第三方库
数据库

最好要求：

Inspect the actual installed version before using an API.

例如：

Before implementing,
check package.json and the installed framework version.

Do not assume APIs from another version.

这个习惯在：

Next.js
React
Prisma
Python 库
SDK

更新很快的生态里尤其重要。

---

十四、坑 14：AI 写了代码，但根本没运行

这是最经典的问题之一。

AI：

功能已经完成。

你问：

测试了吗？

它说：

根据代码逻辑应该可以正常运行。

注意：

应该

和：

已经

差别很大。

开发里真正需要的是：

Evidence

所以可以明确写：

Do not say "completed" unless the relevant verification
commands have actually been executed.

Report the exact commands executed and their results.

例如最终应该看到：

pnpm test
PASS

pnpm typecheck
PASS

pnpm lint
PASS

而不是：

代码应该没问题。

---

十五、坑 15：最后完全不看 Git Diff

这是我认为最危险的一个习惯。

因为 AI 写代码太快以后，人很容易出现：

反正测试通过了
直接 Commit

但最后人工 Review 仍然非常必要。

至少应该自己看：

git diff

重点检查：

它改了什么？

有没有删东西？

有没有加依赖？

有没有碰数据库？

有没有改变 API？

有没有修改测试？

有没有把 Secret 写进去？

我现在更喜欢的方式是：

Codex Self Review
↓
Human Review
↓
Commit

而不是：

Codex
↓
Commit

---

十六、一个比较稳妥的 AI 编程流程

综合这 15 个坑，我现在比较推荐下面这套流程：

需求
↓
明确 Goal
↓
明确 Scope
↓
明确 Constraints
↓
Explore Repository
↓
Implementation Plan
↓
Human Review
↓
Implement
↓
Test
↓
Type Check
↓
Lint / Build
↓
Codex Review
↓
Human Git Diff Review
↓
Commit

看起来步骤多。

实际长期使用以后反而更快。

因为大量 AI 编程时间浪费在：

先乱改
↓
发现不对
↓
回滚
↓
重新修改

真正提高效率的方式不是：

第一次写得最快

而是：

第一次方向就是对的

---

十七、我建议直接写进 AGENTS.md 的 10 条规则

如果长期使用 Codex，可以直接保存下面这一段：

# AI Development Rules

1. Prefer the smallest reasonable change.

2. Do not modify unrelated code.

3. Inspect existing implementations before creating new ones.

4. Do not introduce new dependencies unless necessary.

5. Preserve existing public APIs unless explicitly requested.

6. Do not use `any`, `@ts-ignore`, or equivalent shortcuts
   to hide real type problems.

7. Do not modify existing tests merely to make them pass.

8. For complex tasks, inspect and plan before implementation.

9. Run relevant tests and checks after modification.

10. Review the final Git Diff before declaring completion.

再增加：

Security
Database
Testing
Project-specific rules

就已经是一份非常实用的基础版本。

---

十八、一个我现在很常用的“防失控 Prompt”

复杂任务开始之前，可以直接给 Codex：

Before starting this task:

1. inspect the related implementation;
2. identify the minimum set of files that need to change;
3. identify backwards compatibility risks;
4. identify relevant tests.

Do not modify code yet.

After inspection, provide:

Goal
Root Cause / Current Behavior
Files To Change
Implementation Plan
Risks
Verification Plan

Rules:

- Prefer the smallest reasonable change.
- Do not refactor unrelated code.
- Do not add dependencies unless necessary.
- Preserve public APIs.
- Preserve existing behavior unless the task requires otherwise.

Wait until the implementation path is clear before coding.

这段 Prompt 的目的不是让 AI：

更聪明

而是：

更有纪律

我越来越觉得：

Coding Agent 最重要的能力之一，就是纪律。

---

十九、Plus、Pro、Codex 越强，越需要工程纪律

这是一个看起来有点反直觉的事情。

很多人会觉得：

模型更强
↓
我可以管得更少

实际可能正好相反。

模型越强：

能操作的文件越多

能完成的任务越复杂

能够连续执行的步骤越长

那么一旦目标或边界错了，

它也可能：

更快地朝错误方向走很远

所以：

Capability ↑

往往也意味着：

Control ↑

这就是为什么使用 ChatGPT Plus、Pro 和 Codex 这类工具时，我越来越看重：

AGENTS.md
Task Scope
Permissions
Tests
Git Diff
Human Review

这些东西。

---

二十、不要追求“100% AI 编程”

我不太赞同一种说法：

以后所有代码都应该完全让 AI 写。

实际软件工程里，人仍然负责很多非常关键的事情：

业务判断

产品取舍

架构边界

风险判断

是否值得修改

是否允许 Breaking Change

什么时候上线

这些东西并不是简单生成代码可以替代的。

所以我更愿意把未来的开发模式理解成：

Human
↓
定义目标和边界

AI Agent
↓
调查、实施、测试

Human
↓
Review 和最终判断

而不是：

Human
↓
一句 Prompt

AI
↓
整个项目自动完成

---

二十一、结语：AI 编程最大的风险，不是它不会写代码

如果总结这 15 个坑，会发现大部分问题其实不是：

AI 不会写代码

相反，

很多问题恰恰来自：

AI 太会写代码

它能非常快速地：

加文件
改文件
重构
加依赖
补测试
运行命令

所以开发者新的挑战变成：

如何控制修改方向和范围。

真正稳定的 ChatGPT + Codex 开发工作流应该是：

Understand
↓
Plan
↓
Constrain
↓
Implement
↓
Verify
↓
Review

而不是：

Prompt
↓
Generate
↓
Commit

如果你正在使用 ChatGPT Plus、Pro 或 Codex 做真实项目，我认为最值得养成的三个习惯就是：

修改前先让 AI 解释它准备怎么改

修改后必须让它真正运行验证

提交前自己再看一遍 Git Diff

这三个动作看起来非常基础。

但可能比收藏几十个所谓的：

“神级 Prompt”

更加重要。

因为 AI 编程真正进入工程化阶段以后，

开发效率的竞争已经不只是：

谁生成代码更快。

而是：

谁能让 AI 在正确的边界内，稳定地完成正确的事情。

这可能才是 2026 年使用 ChatGPT、Plus、Pro、Codex 最值得掌握的核心能力。