使用 AI 工具辅助开发
使用 AI 工具辅助开发的完整指南
一、核心原则：AI 是「副驾驶」，你是「主驾驶」
在开始之前，必须建立一个根本认知：
AI 不是替你思考的工具，而是放大你思考能力的工具。
你给 AI 的信息质量，直接决定了它的输出质量。这个原则贯穿整个开发过程。
二、完整开发流程与场景分析
阶段一：需求分析与拆解
正确做法
先自己理清需求，再让 AI 帮你补充和完善。
场景举例：你要开发一个在线书店
正确的提示方式：
我想开发一个在线书店系统，核心功能包括：
1. 用户注册和登录
2. 浏览和搜索书籍
3. 购物车功能
4. 下单和支付
请帮我：
1. 梳理这个项目的技术选型建议
2. 列出核心功能模块
3. 分析可能被我遗漏的需求点
4. 给出开发优先级排序建议
为什么这样做是对的？
- 你提供了明确的业务背景
- 你已经做了初步思考，AI 在你的基础上补充
- 你让 AI 做它擅长的事：补充遗漏、结构化整理、提供经验参考
错误做法
帮我做一个在线书店网站
问题分析：
| 问题 | 后果 |
|---|---|
| 没有任何业务背景 | AI 只能猜，输出泛泛而谈 |
| 没有说清技术栈 | 可能给你用你不熟悉的技术 |
| 没有说清规模和目标用户 | 个人练习项目和商业项目差 10 倍工作量 |
| 一步到位的懒人心态 | 得到的一定是质量最差的通用方案 |
教训：你省掉的思考时间，后面会加倍还回来。
阶段二：技术架构设计
正确做法
把 AI 当成架构评审会上的同事，向它提出具体的架构问题。
场景举例：
我打算用以下技术栈开发在线书店：
- 前端：React + TypeScript
- 后端：Node.js + Express
- 数据库：PostgreSQL
- 部署：Docker + 阿里云
预计用户量初期在 1000 人左右，后期可能增长到 10 万。
请帮我：
1. 评审这个技术选型是否合理
2. 给出数据库表结构设计建议
3. 设计 API 接口的 RESTful 规范
4. 指出这个规模下哪些过度设计是可以避免的
为什么这样做是对的？
- 你提供了明确的技术约束（团队熟悉什么技术）
- 你给出了规模预期（决定架构复杂度）
- 你主动问"什么不该做"（防止过度设计，这比问"该做什么"更有价值）
错误做法
请给我设计一个高并发、高可用、微服务架构的在线书店系统
深入分析这个错误：
一个初期 1000 用户的项目，用微服务架构是严重的过度工程：
- 你需要维护多个独立服务的部署、通信、数据一致性
- 你需要配置服务发现、API 网关、负载均衡
- 一个 3 人小团队会被运维工作压垮
- 项目还没上线，就已经被架构成本拖死了
AI 的危险之处在于：它不会主动拒绝你的要求。 你说微服务，它就给你设计微服务，哪怕这完全不合理。所以「判断什么该做、什么不该做」的决策权，必须握在你手里。
阶段三：编码实现
这是 AI 辅助最多，也是最容易出问题的阶段。
场景 1：写具体功能模块
正确做法 —— 小步前进，逐模块推进：
我正在开发在线书店的购物车功能。以下是我的数据模型：
[贴出你的 User、Book、Cart 相关的表结构或接口定义]
请帮我实现购物车的后端 API，包括：
1. 添加商品到购物车
2. 修改购物车中某本书的数量
3. 删除购物车中的商品
4. 获取当前用户的购物车列表
要求：
- 使用 Express + TypeScript
- 使用我已有的数据库连接层（贴出示例代码）
- 遵循我项目中已有的代码风格（贴出示例代码）
关键要素拆解：
| 你提供的信息 | 作用 |
|---|---|
| 数据模型 | 让 AI 知道数据结构，不会瞎编字段 |
| 明确的功能清单 | 避免遗漏或多余 |
| 技术栈细节 | 确保输出和你项目兼容 |
| 已有代码风格 | 让新代码和旧代码保持一致 |
| 已有的数据库连接层 | 避免 AI 重新发明轮子 |
错误做法：
帮我写一个购物车功能
或者更糟糕的：
帮我写一个完整的电商平台
这种写法的问题远比表面看到的严重：
- 代码风格不一致：AI 不知道你用分号还是不用、用 tab 还是空格、命名用驼峰还是下划线
- 架构冲突：AI 可能用 class 组件而你项目全部用 hooks，或者用 callback 而你项目用 async/await
- 依赖冲突：AI 可能引入你项目中没有的库
- 数据结构不匹配：AI 编造的字段名和你数据库对不上
场景 2：复用已有代码的上下文
正确做法：
以下是我项目中已有的用户认证中间件代码：
[paste auth middleware code]
以下是我现有的路由结构：
[paste route files]
请基于这两部分代码，为购物车模块添加路由，保持和现有代码完全一致的风格和模式。
核心原则：给 AI 足够的上下文。 AI 看不到你的整个项目，它只知道你告诉它的那部分。
场景 3：遇到不会写的新技术
正确做法：
我需要在 Express 项目中集成 Stripe 支付，但我之前没用过 Stripe。
请先给我讲解 Stripe 支付的基本流程和核心概念，
然后给出集成到 Express 中的最小可行方案，
最后列出生产环境需要注意的安全事项。
为什么先要概念讲解？
- 如果你直接让 AI 写代码，你拿到的是一个黑盒
- 出了 bug 你不知道哪里错了，因为你不懂原理
- 先理解，再编码 —— 这个顺序不能颠倒
错误做法：
帮我接入 Stripe 支付
这样你会得到一堆"能跑但看不懂"的代码，后续维护和排错将极其痛苦。
阶段四：调试与排错
这是 AI 最能体现价值的场景之一。
正确做法
我在实现购物车 API 时遇到了一个 bug。
现象：添加商品到购物车时，如果同一个用户重复添加同一本书，
数据库里会出现两条记录，而不是更新数量。
以下是我的相关代码：
[paste the route handler code]
[paste the database query code]
以下是我的数据表结构：
[paste schema]
以下是我已排查过的方向：
1. 确认前端没有重复发送请求
2. 确认数据库唯一索引没有生效
3. 打印了请求参数，确认 userId 和 bookId 都是正确的
请帮我分析可能的原因。
这种提示的精妙之处：
- 描述了现象：AI 知道"不对"的表现是什么
- 贴了相关代码：AI 有具体的分析对象
- 列出了已排查方向：AI 不会浪费时间在你已经排除的可能性上
- 给了表结构：AI 可以帮你发现索引设计的问题
错误做法
我的代码报错了，帮我看看
或者：
报错信息是 "TypeError: Cannot read property 'id' of undefined"
帮我修
只贴报错信息的问题：
- 报错信息只是一个症状，不是病因
- 没有上下文代码，AI 只能瞎猜
- 没有你的排查过程，AI 可能重复你已经试过的方案
- 最终你需要反复沟通很多轮才能定位问题
经验法则：你给 AI 的调试信息越多，定位问题越快。 把你花了 30 分钟排查的过程写出来，AI 可能 1 分钟就找到根因。
阶段五：代码审查与优化
正确做法
请审查以下购物车 API 的代码，重点关注：
1. 安全性问题（SQL 注入、XSS、权限校验等）
2. 性能问题（N+1 查询、缺少索引等）
3. 边界情况处理（并发、空值、非法输入等）
4. 代码可维护性
请对每个发现给出：问题描述、风险等级、修复建议、修改后的代码。
[paste code]
为什么要主动指定审查维度？
- 如果你只说"帮我 review"，AI 可能只给你改改变量命名
- 指定维度意味着你在告诉 AI “这些是我最关心的”
- 这也体现了你自己对代码质量的理解
错误做法
这段代码有问题吗？
AI 大概率回答"看起来基本没问题，但可以做一些优化"然后给几个无关痛痒的建议。
阶段六：编写测试
正确做法
以下是我的购物车服务层代码：
[paste service code]
以下是我的数据模型：
[paste models]
请帮我编写单元测试，要求：
1. 使用 Jest 框架
2. Mock 掉数据库层
3. 覆盖以下场景：
- 正常添加商品
- 添加重复商品时应该更新数量
- 删除不存在的商品应该返回 404
- 并发修改购物车的情况
- 数量为 0 或负数的非法输入
4. 给出测试覆盖率的目标建议
你注意到"覆盖场景"是你自己列的了吗？
这就是"你是主驾驶"的体现 —— 你知道业务逻辑中的关键场景和边界情况，AI 帮你把想法转化为可执行的测试代码。
错误做法
帮我写单元测试
AI 会给你写测试，但它不知道你项目中的关键业务场景、哪些路径是高风险的、哪些边界情况最容易出 bug。
阶段七：文档编写
正确做法
以下是我的项目代码结构和核心模块：
[paste project structure]
[paste key modules]
请帮我生成：
1. README.md，包括项目简介、技术栈、本地开发环境搭建步骤、部署方式
2. API 文档，使用 OpenAPI/Swagger 格式
3. 关键模块的设计决策文档（为什么这样设计，考虑了哪些权衡）
错误做法
帮我写个项目文档
三、高级技巧与实战经验
技巧 1：让 AI 扮演不同角色
请你分别从以下三个角色审查我的代码：
1. 安全工程师：关注安全漏洞和攻击面
2. 高级架构师：关注设计模式和可扩展性
3. 初级开发者：看看代码是否容易理解和上手
每个角色分别给出审查意见。
原理：不同角色的"知识侧重点"不同，迫使 AI 从不同角度思考。
技巧 2：让 AI 先给方案对比，再选择
我想实现在线书店的搜索功能，在以下两种方案中犹豫：
A. 直接用 PostgreSQL 的全文搜索
B. 引入 Elasticsearch
请从以下维度对比分析：
- 实现复杂度
- 性能表现（基于我的数据规模）
- 维护成本
- 扩展性
最后给出你的推荐，以及推荐的前提条件。
关键：你要 AI 给出"推荐的前提条件"，而不是无条件的推荐。 因为没有绝对好的方案，只有在特定条件下更合适的方案。
技巧 3：渐进式开发，而非一次性生成
正确的节奏：
第一步：先帮我搭建项目骨架和目录结构
→ 你检查、调整
第二步：实现数据库模型和迁移文件
→ 你检查、调整
第三步：实现用户认证模块
→ 你检查、测试
第四步：实现书籍 CRUD 模块
→ 你检查、测试
第五步：实现购物车模块
→ 你检查、测试
...
错误的节奏：
帮我把整个在线书店写出来
渐进式的根本原因：
- 每一步你都能理解和验证 —— 出了问题你知道在哪
- 每一步的上下文都是可控的 —— AI 不会因为上下文太长而遗忘前面的约定
- 你可以随时调整方向 —— 发现设计不对就改，不用推翻整个项目
- 你在过程中持续学习 —— 而不是拿到一堆看不懂的代码
技巧 4：处理 AI 的错误输出
AI 一定会犯错。 你的工作是发现和纠正这些错误。
当 AI 的代码有 bug 时：
你上次给我的购物车接口代码有一个问题：
当两个请求同时修改同一个购物车项的数量时，
会因为竞态条件导致数量计算错误。
你上次给的代码：
[paste AI's previous code]
我的日志显示：
[paste logs]
请修复这个并发问题，使用数据库事务或乐观锁。
当 AI 的设计不合理时：
你建议的方案我理解了，但我有一个顾虑：
你让我在每个路由里都手动检查用户权限，
但我的项目有 30 多个路由，这样做会有大量重复代码。
有没有更好的方式？比如中间件或者装饰器模式？
关键心态：不要盲信 AI，也不要因为 AI 犯错就否定它的价值。 把它当成一个能力很强但偶尔粗心的同事。
四、常见陷阱与反模式
陷阱 1：「一次性巨无霸」提示
❌ 帮我写一个完整的用户管理系统，包括注册、登录、
权限管理、角色管理、日志记录、邮件通知、密码重置、
OAuth2 集成、双因素认证……
后果：
- AI 输出的代码很长，你根本看不完
- 里面的错误和不合理之处你发现不了
- 各模块之间的关系你理不清
- 最终你拿到的是一个你无法维护的怪物
正确做法：拆成 5-8 个小提示，逐步推进。
陷阱 2：「没有上下文的切换」
❌ [新对话]
帮我修复购物车的一个 bug
后果：AI 完全不知道你的项目背景、技术栈、已有的代码。
正确做法：要么在同一个对话中继续，要么在新对话中重新提供必要的上下文。
陷阱 3：「盲目复制粘贴」
拿到 AI 生成的代码后，不做任何检查直接用。
你应该检查的清单：
| 检查项 | 原因 |
|---|---|
| 变量名是否和你的项目一致 | AI 可能用不同的命名 |
| 导入路径是否正确 | AI 不知道你的目录结构 |
| 依赖是否已安装 | AI 可能引入新依赖 |
| 是否有硬编码的值 | 端口号、URL、密钥等 |
| 是否处理了错误情况 | AI 经常遗漏错误处理 |
| 逻辑是否符合你的业务 | AI 对你的业务理解有限 |
陷阱 4：「对话上下文溢出」
一个对话进行太久，AI 开始遗忘前面的约定。
解决方案：
到目前为止，我们确定了以下设计决策：
1. 使用 PostgreSQL，表结构包括……
2. 使用 Express + TypeScript
3. 认证方式使用 JWT
4. 代码风格：ESLint Airbnb 规范
现在请基于以上决策，帮我在新对话中可以参考的项目摘要，
然后我们继续开发订单模块。
定期总结，把关键决策固化下来。
陷阱 5：把 AI 当搜索引擎
❌ Java 的 HashMap 怎么用？
AI 不是文档查询工具。 文档查询你直接看官方文档更准确。AI 的价值在于：
- 帮你做决策（用 HashMap 还是 LinkedHashMap？）
- 帮你解决问题（为什么我的 HashMap 在并发下出 bug？）
- 帮你生成代码（基于我的数据结构生成一个缓存实现）
五、AI 擅长与不擅长的事情
AI 擅长的
| 场景 | 说明 |
|---|---|
| 生成样板代码 | CRUD、路由配置、数据模型 |
| 解释代码 | “这段代码在做什么” |
| 调试辅助 | 给出可能的排查方向 |
| 代码转换 | “把这段 Python 转成 Go” |
| 文档生成 | API 文档、README、注释 |
| 学习新技术 | 概念讲解 + 示例代码 |
| 方案对比 | 多种技术方案的优劣分析 |
| 代码审查 | 发现常见的安全和性能问题 |
AI 不擅长的
| 场景 | 说明 |
|---|---|
| 理解你的业务上下文 | 它不知道你的业务规则细节 |
| 做架构决策 | 它可以给建议，但最终判断需要你 |
| 保证正确性 | 生成的代码必须经过你的测试验证 |
| 处理最新的技术版本 | 可能有知识截止日期的限制 |
| 理解非技术需求 | 用户体验、商业目标、团队政治 |
六、完整开发流程总结
┌─────────────────────────────────────────────────┐
│ 使用 AI 辅助开发的正确流程 │
├─────────────────────────────────────────────────┤
│ │
│ 1. 需求阶段 │
│ 你：理清需求、列出功能清单 │
│ AI：补充遗漏、结构化整理、评估可行性 │
│ │
│ 2. 设计阶段 │
│ 你：确定技术约束、规模预期 │
│ AI：给出技术选型对比、架构建议 │
│ 你：做出最终决策 │
│ │
│ 3. 编码阶段 │
│ 你：拆解为小模块、提供上下文 │
│ AI：生成代码 │
│ 你：审查、调整、测试、集成 │
│ （循环往复，逐步推进） │
│ │
│ 4. 调试阶段 │
│ 你：描述现象、提供代码和日志、列出已排查方向 │
│ AI：分析可能原因、给出修复方案 │
│ 你：验证修复、确认解决 │
│ │
│ 5. 测试阶段 │
│ 你：定义测试场景和覆盖目标 │
│ AI：生成测试代码 │
│ 你：审查测试覆盖率是否合理 │
│ │
│ 6. 审查阶段 │
│ 你：指定审查维度（安全/性能/可维护性） │
│ AI：给出审查意见和修改建议 │
│ 你：评估并实施改进 │
│ │
│ 7. 文档阶段 │
│ 你：提供项目结构和关键决策 │
│ AI：生成文档 │
│ 你：审核准确性 │
│ │
└─────────────────────────────────────────────────┘
七、最后一段话
使用 AI 辅助开发，本质上是一种协作能力。和任何协作一样，它需要：
- 清晰的表达 —— 你能把需求说清楚，AI 才能做对
- 合理的期望 —— 不指望 AI 替你思考，也不低估它的辅助价值
- 持续的验证 —— 每一行 AI 生成的代码，你都应当理解并测试
- 迭代的耐心 —— 小步快跑比一步到位更可靠
AI 让你写代码更快，但它不能让你从"不会做软件"变成"会做软件"。 基础功底（数据结构、算法、系统设计、调试能力）依然是不可替代的。AI 是你已有能力的放大器，而不是替代品。
把这当成一个长期磨合的过程，你会发现 AI 辅助开发的效率会随着你的经验增长而持续提升。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
3
0- 0
已为社区贡献1条内容
所有评论(0)