AI编程使用避坑指南｜附配置文件

适用人群：正在使用 Cursor、Trae、Claude Code、GitHub Copilot、Codeium、通义灵码、豆包 MarsCode、ChatGPT 等 AI 编程工具的开发者、技术负责人、独立开发者和产品工程师。
核心目标：不是教你“让 AI 写代码”，而是教你如何让 AI 稳定、可控、可维护地参与软件开发，避免项目越写越乱、Bug 越修越多、上下文越聊越崩。

一、为什么你用 AI 编程越用越累？

很多人第一次使用 AI 编程工具时，会有一种强烈的惊艳感：

• “帮我写一个登录页。”
• “帮我封装一个请求库。”
• “帮我写一个后台管理系统。”
• “根据这个接口文档生成前端代码。”

AI 往往能在几分钟内生成大量代码，速度远超人工。但随着项目推进，问题也会逐渐暴露：

• 代码风格前后不一致；
• AI 经常重复造轮子；
• 修改一个 Bug 又引入三个新 Bug；
• 文件结构越来越混乱；
• 上下文一长，AI 开始胡说；
• 生成代码能跑，但不好维护；
• AI 不理解业务边界，擅自改动核心逻辑；
• 项目依赖版本混乱，配置文件被随意改写；
• 安全、权限、异常处理经常遗漏；
• 测试缺失，后期不敢重构。

这就是 AI 编程最常见的陷阱：它很擅长“生成代码”，但并不天然擅长“维护工程”。

AI 可以是强大的编程助手，但前提是你要给它清晰的规则、边界、上下文和验收标准。否则，它就像一个非常勤奋但缺少项目经验的初级工程师：写得快，改得也快，但可能越改越偏。

二、AI 编程的正确定位：不是替代程序员，而是放大工程能力

在实际开发中，AI 最适合承担以下工作：

1. 重复性代码生成

例如：

• CRUD 页面；
• 表单校验；
• API 调用封装；
• 单元测试模板；
• 类型定义；
• 数据转换函数；
• 文档注释；
• Mock 数据。

这些内容规律性强、上下文边界清晰，非常适合交给 AI。

2. 代码解释与快速熟悉项目

面对陌生项目时，可以让 AI 帮你解释：

• 某个模块的职责；
• 某个函数的调用链；
• 某个异常可能的原因；
• 某段 SQL 的查询含义；
• 某个组件的状态流转。

这类任务可以极大降低阅读成本。

3. 小范围重构

例如：

• 将重复逻辑提取为函数；
• 优化变量命名；
• 拆分过大的组件；
• 将 JS 改成 TS；
• 将回调改成 async/await；
• 补充错误处理；
• 增加边界条件判断。

但要注意：AI 不适合在没有完整上下文的情况下进行大范围架构重构。

4. 辅助排查问题

AI 可以帮助你分析：

• 报错堆栈；
• 构建失败；
• 类型错误；
• 接口异常；
• 性能瓶颈；
• 依赖冲突。

但它的结论需要你验证，不能盲信。

三、AI 编程常见大坑

下面是实际使用 AI 编程工具时最容易踩的坑。

坑一：不给规则，直接让 AI 写代码

很多人一上来就输入：

帮我写一个用户管理页面。

AI 确实会写，但问题是它不知道：

• 你使用 Vue 还是 React？
• UI 库是 Ant Design、Element Plus 还是 Tailwind？
• 接口请求工具是 axios 还是 fetch？
• 是否使用 TypeScript？
• 目录结构如何？
• 权限校验在哪里做？
• 表单校验规则是什么？
• 状态管理用什么？
• 代码风格有没有要求？

于是 AI 只能根据自己的“默认习惯”生成代码。它可能会引入你项目里没有的依赖，可能会使用错误的写法，也可能会创造一个看似合理但完全不符合你项目规范的结构。

正确做法

在项目根目录放置 AI 规则文件，例如：

• .cursorrules
• CLAUDE.md
• AGENTS.md
• .github/copilot-instructions.md
• ai-rules.md

让 AI 在每次生成代码前都遵守统一规范。

例如，你可以明确告诉它：

• 项目技术栈；
• 目录结构；
• 命名规范；
• 不允许随意新增依赖；
• 修改前必须先阅读相关文件；
• 输出代码必须包含错误处理；
• 生成接口调用必须复用已有 request 工具；
• 不允许修改公共类型定义，除非明确要求；
• 修改后需要说明影响范围。

AI 不是不聪明，而是你没有给它项目规则。

坑二：让 AI 一次性改太多文件

很多开发者喜欢这样提问：

帮我把整个项目的登录、权限、路由、菜单、接口请求都重构一下。

这类请求极容易失控。

AI 一旦同时处理太多文件，就会出现以下问题：

• 忽略已有业务逻辑；
• 误删关键代码；
• 修改范围不可控；
• 生成大量未验证代码；
• 前后逻辑不一致；
• 难以 Code Review；
• 出错后很难定位原因。

正确做法

把任务拆小，采用“逐步推进”的方式。

错误示例：

帮我重构整个权限系统。

推荐示例：

请先阅读 src/router、src/store/auth 和 src/utils/permission 相关文件，
总结当前权限系统的实现方式，不要修改代码。

然后再继续：

基于刚才的总结，只修改 src/utils/permission.ts，
补充按钮级权限判断函数 hasButtonPermission。
要求：
1. 不修改现有函数签名；
2. 保持向后兼容；
3. 补充 TypeScript 类型；
4. 给出使用示例。

这样 AI 的输出会稳定很多，也更容易审查。

坑三：只看能不能跑，不看能不能维护

AI 生成的代码经常有一个特点：短期能跑，长期难改。

常见表现包括：

• 一个函数几百行；
• 组件里塞满业务逻辑；
• 类型定义随处写；
• 魔法字符串到处出现；
• 错误处理只有 console.log；
• 同一个请求封装了多遍；
• 命名模糊，例如 data1、list2；
• 注释解释“做了什么”，但不解释“为什么”。

正确做法

你应该要求 AI 按照工程规范生成代码，而不是只追求结果。

推荐指令：

请按照可维护性优先的原则实现，不要只追求代码最短。
要求：
1. 函数职责单一；
2. 避免重复代码；
3. 使用清晰命名；
4. 补充必要类型；
5. 对异常情况做处理；
6. 不引入未使用代码；
7. 不改变现有公共 API。

如果是前端组件，可以进一步要求：

请将组件拆分为：
1. 页面组件；
2. 表单组件；
3. 表格组件；
4. API 请求模块；
5. 类型定义模块。

如果是后端接口，可以要求：

请按照 controller、service、repository 三层结构实现，
不要在 controller 中直接写数据库查询逻辑。

坑四：没有让 AI 先读代码，就让它直接改代码

AI 工具虽然可以读取项目文件，但并不代表它一定会主动完整理解上下文。

如果你直接说：

修复这个 Bug。

AI 可能只看当前打开文件，然后凭经验修改。结果可能是表面修好了，实际破坏了其他调用方。

正确做法

要求 AI 先分析，不要直接改。

推荐流程：

请先不要修改代码。
请阅读以下文件：
1. src/pages/User/index.tsx
2. src/services/user.ts
3. src/types/user.ts

然后回答：
1. 当前用户列表的数据流是怎样的？
2. 可能导致分页异常的原因有哪些？
3. 你建议修改哪些文件？
4. 每个修改点的风险是什么？

等 AI 给出分析后，你再确认：

同意方案二。
请只修改 src/services/user.ts 和 src/pages/User/index.tsx。
不要修改类型定义文件。

这一步非常重要：先理解，再修改。

坑五：盲信 AI 的依赖和 API

AI 经常会写出看起来很合理、但实际上不存在的 API。

例如：

import { useAdvancedForm } from 'antd';

或者：

router.beforeEachAsync(...)

这些 API 可能是 AI “幻想”出来的。尤其是在以下场景更常见：

• 新版本框架；
• 小众库；
• 私有 SDK；
• 公司内部组件库；
• 文档不足的 API；
• 版本差异较大的依赖。

正确做法

明确禁止 AI 编造 API：

禁止使用项目中不存在的依赖、函数或组件。
如果不确定某个 API 是否存在，请先搜索项目代码或说明不确定，不要直接假设。

同时，让 AI 优先复用已有实现：

请优先搜索项目中已有的请求封装、表格组件、弹窗组件和权限函数。
如果已有类似实现，请复用，不要重新实现。

坑六：不写测试，后期完全不敢改

AI 让写代码变快了，但如果没有测试，风险也会变大。

尤其是当 AI 参与以下工作时，测试很重要：

• 工具函数；
• 权限逻辑；
• 金额计算；
• 订单状态流转；
• 登录鉴权；
• 数据转换；
• 表单校验；
• 复杂条件分支；
• 重构旧代码。

正确做法

让 AI 在实现功能时同步补充测试。

示例：

请为刚才新增的 parseUserStatus 函数补充单元测试。
要求覆盖：
1. 正常状态；
2. 未知状态；
3. 空值；
4. 非法输入；
5. 边界情况。

如果你使用 Vitest：

请使用 Vitest 编写测试，不要使用 Jest。
测试文件放在同目录下，命名为 xxx.test.ts。

如果是后端：

请为该 service 方法补充单元测试，mock repository 层，
不要连接真实数据库。

坑七：让 AI 直接处理敏感信息

不要把以下内容直接发给 AI：

• 生产数据库连接串；
• 用户隐私数据；
• access token；
• secret key；
• 内部接口密钥；
• 未脱敏日志；
• 商业合同；
• 公司内部敏感文档；
• 客户真实数据。

即使你使用的是本地 IDE 插件，也要确认数据是否会上传到云端模型。

正确做法

使用脱敏数据。

错误示例：

{
  "phone": "13812345678",
  "idCard": "110101199001011234",
  "accessToken": "eyJhbGciOiJIUzI1NiIs..."
}

推荐示例：

{
  "phone": "138****5678",
  "idCard": "110101********1234",
  "accessToken": ""
}

并在规则文件中加入：

禁止输出、记录或请求任何真实密钥、Token、密码、身份证号、手机号等敏感信息。
示例数据必须使用脱敏值或占位符。

四、推荐的 AI 编程工作流

一个相对稳定的 AI 编程流程可以分为六步。

第一步：建立项目规则

在项目根目录创建规则文件，让 AI 了解项目基本情况。

如果你使用 Cursor，可以使用 .cursorrules。

如果你使用 Claude Code，可以使用 CLAUDE.md。

如果你使用 Copilot，可以使用 .github/copilot-instructions.md。

建议至少包含：

• 项目简介；
• 技术栈；
• 目录结构；
• 编码规范；
• 提交规范；
• 测试规范；
• 安全要求；
• 禁止事项；
• 常用命令。

第二步：先让 AI 阅读，再让 AI 修改

在复杂任务中，不要直接说“帮我改”。

你可以先说：

请先阅读相关代码并总结，不要修改任何文件。

然后让它输出：

• 当前实现；
• 数据流；
• 问题点；
• 修改方案；
• 风险分析。

最后再授权它修改指定文件。

第三步：限制修改范围

每次让 AI 修改代码时，最好明确：

• 可以修改哪些文件；
• 不可以修改哪些文件；
• 是否允许新增文件；
• 是否允许新增依赖；
• 是否需要兼容旧逻辑；
• 是否需要补充测试；
• 修改完成后需要说明什么。

示例：

你只能修改以下文件：
1. src/pages/User/index.tsx
2. src/services/user.ts

不能修改：
1. src/types/user.ts
2. src/router/index.ts
3. package.json

修改完成后请说明：
1. 修改了什么；
2. 为什么这样改；
3. 如何验证；
4. 是否有兼容性风险。

第四步：小步提交

不要让 AI 一次完成一个巨大功能。

推荐拆成：

1. 补类型；
2. 补 API；
3. 写 UI；
4. 接入状态；
5. 补异常处理；
6. 补测试；
7. 优化样式；
8. Code Review。

每一步都可以单独提交，便于回滚。

第五步：强制运行检查

AI 写完代码后，你需要运行：

npm run lint
npm run typecheck
npm run test
npm run build

如果是后端项目，则可能是：

go test ./...
cargo test
mvn test
pytest

AI 的输出不等于正确，通过本地检查才算第一步合格。

第六步：让 AI 做 Code Review

当 AI 完成修改后，可以继续让它自查：

请对刚才的修改做一次 Code Review。
重点检查：
1. 是否存在未处理异常；
2. 是否有重复代码；
3. 是否有类型漏洞；
4. 是否有潜在空值问题；
5. 是否引入未使用变量；
6. 是否影响已有逻辑；
7. 是否存在安全风险。

AI 自查不能代替人工 Review，但能帮你提前发现一部分低级问题。

五、附：通用 AI 编程配置文件

下面给出几份可直接复制使用的配置文件。你可以根据自己的项目进行删改。

1. Cursor 配置文件：.cursorrules

# Project Rules for AI Coding

你是本项目的 AI 编程助手。你的目标是帮助开发者高质量、可维护地完成代码开发，而不是简单生成能运行的代码。

## 一、基本原则

1. 使用中文回答，代码和专有名词保持英文。
2. 修改代码前，必须先理解现有实现，不要凭空假设。
3. 优先复用项目已有工具函数、组件、类型、请求封装和样式规范。
4. 不允许随意新增依赖；如确需新增，必须说明原因、替代方案和影响范围。
5. 不允许删除已有业务逻辑，除非用户明确要求。
6. 不允许修改与当前任务无关的文件。
7. 不允许编造不存在的 API、组件、函数、Hook 或配置项。
8. 如不确定，应明确说明不确定点，并建议用户确认。
9. 生成代码应优先保证可读性、可维护性、类型安全和边界处理。
10. 不要输出真实密钥、Token、密码、手机号、身份证号等敏感信息。

## 二、技术栈

请根据项目实际情况修改以下内容：

- 前端框架：React / Vue / Next.js / Nuxt
- 语言：TypeScript
- 包管理器：pnpm
- UI 组件库：Ant Design / Element Plus / 自研组件库
- 请求库：axios，统一使用 src/utils/request.ts
- 状态管理：Zustand / Pinia / Redux Toolkit
- 测试框架：Vitest
- 代码规范：ESLint + Prettier

## 三、目录约定

- src/pages：页面级组件
- src/components：通用组件
- src/services：接口请求
- src/types：类型定义
- src/utils：工具函数
- src/hooks：自定义 hooks
- src/store：状态管理
- src/assets：静态资源
- src/router：路由配置
- tests：测试文件

## 四、编码规范

1. TypeScript 代码禁止使用 any，除非有充分理由并添加说明。
2. 函数命名应表达业务含义，避免使用 data、item、temp 等模糊命名。
3. 单个函数不应过长，如逻辑复杂应拆分。
4. 公共逻辑应抽取到 utils、hooks 或 services。
5. UI 组件中不要直接写复杂数据转换逻辑。
6. 接口请求必须复用统一 request 实例。
7. 所有异步操作需要考虑 loading、error 和 empty 状态。
8. 表单需要包含基础校验。
9. 金额、权限、状态流转等关键逻辑必须补充测试。
10. 删除代码前，需要确认没有其他引用。

## 五、修改代码前的要求

在复杂任务中，请先输出以下内容，不要立即修改：

1. 你理解的需求；
2. 涉及的文件；
3. 当前实现方式；
4. 修改方案；
5. 潜在风险；
6. 是否需要用户确认。

只有在用户确认后，再进行修改。

## 六、提交后说明

完成修改后，请说明：

1. 修改了哪些文件；
2. 每个文件的修改目的；
3. 是否新增依赖；
4. 如何验证；
5. 是否存在风险或待确认事项。

## 七、安全要求

1. 禁止硬编码密钥、Token、密码、数据库连接串。
2. 示例数据必须脱敏。
3. 对用户输入进行必要校验。
4. 注意 XSS、SQL 注入、权限绕过、越权访问等问题。
5. 权限判断不要只放在前端，后端也必须校验。

## 八、测试要求

1. 工具函数、权限逻辑、金额计算、状态转换必须补充单元测试。
2. 测试需要覆盖正常情况、异常情况和边界情况。
3. 不要连接真实生产环境。
4. Mock 数据必须使用脱敏数据。

2. Claude Code 配置文件：CLAUDE.md

# Claude Code Project Instructions

你是本项目的 AI Coding Agent，请严格遵守以下规则。

## 工作方式

- 在修改代码前，先阅读相关文件。
- 对复杂需求，先给出计划，不要直接改代码。
- 每次修改应尽量小而清晰。
- 不要修改与任务无关的文件。
- 不要自动新增依赖。
- 不确定时先询问，不要猜测。
- 修改完成后，说明变更内容和验证方式。

## 项目技术栈

- Language: TypeScript
- Package Manager: pnpm
- Frontend: React / Vue
- UI Library: Ant Design / Element Plus
- Test: Vitest
- Lint: ESLint
- Format: Prettier

## Code Style

- Prefer readable code over clever code.
- Avoid `any`.
- Use explicit types for public functions.
- Keep functions small and focused.
- Reuse existing utilities and components.
- Do not duplicate business logic.
- Handle loading, error and empty states.
- Keep API calls in services layer.
- Keep business types in src/types.

## Security

- Never output real secrets.
- Never hardcode tokens or passwords.
- Sanitize user input when necessary.
- Consider permission checks and data ownership.
- Use placeholders like `` for sensitive examples.

## Testing

Please add or update tests when changing:

- permission logic
- money calculation
- data transformation
- status transition
- authentication
- utility functions

## Response Format

After changes, respond with:

1. Summary
2. Changed Files
3. Validation
4. Risks
5. Next Steps

3. GitHub Copilot 配置文件：.github/copilot-instructions.md

# Copilot Instructions

请在本项目中遵守以下约定：

## General

- 使用中文解释代码修改。
- 代码优先使用 TypeScript。
- 不要使用项目中不存在的依赖。
- 不要随意修改 package.json。
- 优先复用已有模块。
- 不要生成与当前任务无关的代码。

## Architecture

- 页面组件放在 `src/pages`
- 通用组件放在 `src/components`
- API 请求放在 `src/services`
- 类型定义放在 `src/types`
- 工具函数放在 `src/utils`
- Hooks 放在 `src/hooks`
- 状态管理放在 `src/store`

## Coding Rules

- 禁止滥用 `any`
- 禁止硬编码敏感信息
- 禁止重复实现已有工具函数
- 异步请求必须处理错误
- 表单必须包含校验
- 复杂逻辑需要拆分函数
- 公共函数需要补充测试

## Review Checklist

生成代码时请检查：

- 是否有类型错误
- 是否有未使用变量
- 是否有重复代码
- 是否有空值风险
- 是否有权限漏洞
- 是否影响已有调用方
- 是否需要补充测试

4. 通用 Prompt 模板：需求开发

你是一个资深软件工程师，请协助我完成以下需求。

## 背景

项目技术栈：
- 前端框架：
- 后端框架：
- 语言：
- UI 库：
- 状态管理：
- 请求封装：
- 测试框架：

## 需求描述

请实现：

## 约束条件

1. 不允许新增依赖，除非我明确同意。
2. 不允许修改与需求无关的文件。
3. 优先复用项目已有组件、类型、工具函数。
4. 保持现有代码风格。
5. 需要处理 loading、error、empty 状态。
6. 需要考虑边界情况。
7. 修改完成后，请说明影响范围。

## 请先执行

请先阅读相关文件并输出：
1. 当前实现总结；
2. 涉及文件；
3. 修改方案；
4. 风险点；
5. 是否需要我确认。

在我确认之前，不要直接修改代码。

5. 通用 Prompt 模板：Bug 修复

请帮我分析并修复一个 Bug。

## Bug 描述

现象：

期望结果：

实际结果：

复现步骤：
1.
2.
3.

相关报错：

## 要求

1. 请先分析原因，不要直接修改代码。
2. 请指出可能涉及的文件。
3. 请给出至少两个可能原因，并说明如何验证。
4. 修复时尽量缩小修改范围。
5. 不要修改无关逻辑。
6. 修复后请补充或更新测试。
7. 最后说明如何验证修复结果。

6. 通用 Prompt 模板：代码审查

请对以下代码或本次变更进行 Code Review。

重点关注：

1. 类型安全；
2. 空值处理；
3. 异常处理；
4. 权限校验；
5. 数据一致性；
6. 可维护性；
7. 性能问题；
8. 安全风险；
9. 是否存在重复代码；
10. 是否需要测试。

请按照以下格式输出：

## 总体评价

## 主要问题

## 建议修改

## 风险等级

## 是否建议合并

六、不同场景下的 AI 使用建议

1. 从零开发项目

如果你想让 AI 从零生成项目，不建议一上来就让它“写完整系统”。更好的方式是：

1. 先让 AI 生成项目结构；
2. 再确定技术栈和规范；
3. 生成基础配置；
4. 实现一个最小闭环功能；
5. 补充测试和文档；
6. 再逐步扩展模块。

推荐指令：

请先不要写业务代码。
请为一个中后台管理系统设计项目目录结构，
技术栈为 React + TypeScript + Vite + Ant Design + Zustand + Vitest。
要求说明每个目录的职责。

2. 接手老项目

老项目最大的问题是上下文复杂。此时 AI 最适合帮你做“阅读助手”。

推荐指令：

请阅读 src/router、src/store、src/services 目录，
总结这个项目的路由、状态管理和接口请求方式。
不要修改任何代码。

之后可以继续：

请生成一份项目维护文档，说明：
1. 如何启动项目；
2. 主要目录说明；
3. 登录流程；
4. 权限流程；
5. 新增页面的步骤；
6. 常见问题。

3. 重构代码

重构是 AI 编程的高风险场景。必须控制范围。

推荐做法：

• 先让 AI 识别重复代码；
• 再让 AI 给出重构方案；
• 人工确认；
• 小范围修改；
• 补测试；
• 跑检查；
• 再进入下一步。

不要说：

帮我优化整个项目代码。

而要说：

请分析 src/pages/Order/index.tsx 中是否存在可拆分的逻辑。
先只输出分析和重构建议，不要修改代码。

4. 生成测试

AI 写测试的效率很高，但要注意测试质量。不要只让它追求覆盖率，而要关注关键路径。

推荐指令：

请为 calculateOrderAmount 编写单元测试。
要求覆盖：
1. 普通商品；
2. 优惠券；
3. 满减；
4. 运费；
5. 退款；
6. 金额为 0；
7. 非法金额；
8. 精度问题。

5. 写技术文档

AI 很适合根据代码生成文档，但文档必须及时更新。

可以让 AI 生成：

• README；
• 接口说明；
• 组件使用说明；
• 部署文档；
• 故障排查文档；
• 开发规范；
• 变更日志。

推荐指令：

请根据当前项目结构生成 README。
要求包含：
1. 项目简介；
2. 技术栈；
3. 环境要求；
4. 安装依赖；
5. 本地开发；
6. 构建部署；
7. 目录结构；
8. 常见问题。

七、AI 编程验收清单

每次使用 AI 完成代码后，建议用以下清单检查。

功能正确性

• [ ] 是否满足需求？
• [ ] 是否覆盖主要业务流程？
• [ ] 是否处理异常情况？
• [ ] 是否处理空数据？
• [ ] 是否考虑边界条件？

工程质量

• [ ] 是否符合项目目录规范？
• [ ] 是否复用已有工具函数？
• [ ] 是否存在重复代码？
• [ ] 是否引入不必要依赖？
• [ ] 是否有未使用变量？
• [ ] 是否存在过长函数？
• [ ] 命名是否清晰？

类型与测试

• [ ] TypeScript 类型是否准确？
• [ ] 是否滥用 any？
• [ ] 是否补充测试？
• [ ] 测试是否覆盖异常和边界？
• [ ] 是否通过 typecheck？
• [ ] 是否通过 lint？
• [ ] 是否通过 build？

安全与稳定性

• [ ] 是否硬编码敏感信息？
• [ ] 是否存在权限绕过？
• [ ] 是否存在 XSS 风险？
• [ ] 是否存在 SQL 注入风险？
• [ ] 是否正确处理用户输入？
• [ ] 是否影响已有接口或公共函数？
• [ ] 是否有回滚方案？

八、结语：AI 编程的关键不是“会提问”，而是“会管理”

很多 AI 编程教程都在强调 Prompt 技巧，但真正决定项目质量的，不只是你会不会写一句漂亮的提示词，而是你是否具备工程管理意识。

AI 编程的本质，是把一个强大的代码生成器纳入你的工程流程中。你需要给它：

• 明确的项目规则；
• 清晰的任务边界；
• 足够的上下文；
• 可执行的验收标准；
• 严格的安全约束；
• 稳定的测试体系；
• 可回滚的小步提交。

如果没有这些约束，AI 会把项目写得越来越快，也可能把问题积累得越来越深。

最好的使用方式不是让 AI “替你写完所有代码”，而是让 AI 成为你的结对程序员：它负责提高速度、提供方案、生成初稿、补充测试、辅助排查；你负责判断方向、控制质量、把握架构、验证结果。

记住一句话：

AI 可以帮你写代码，但不能替你承担工程责任。

当你开始用规则文件、任务拆分、测试检查、Code Review 和安全边界来管理 AI，它才会真正从“玩具”变成“生产力工具”。