使用 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. 性能问题N1 查询、缺少索引等 3. 边界情况处理并发、空值、非法输入等 4. 代码可维护性 请对每个发现给出问题描述、风险等级、修复建议、修改后的代码。 [paste code]为什么要主动指定审查维度如果你只说帮我 reviewAI 可能只给你改改变量命名指定维度意味着你在告诉 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 AIs 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 辅助开发的效率会随着你的经验增长而持续提升。