先说个可能有点反常识的结论AI 辅助开发这件事真正的门槛从来不是选哪个工具、用哪个大模型而是你愿不愿意把自己的工作方式拆开重新审视一遍。我身边不少朋友问我说现在 AI 这么火是不是以后不用写代码了。我的回答一直是恰恰相反以后写代码的人更值钱因为你要从写代码的人变成定义问题、拆解任务、验收结果的人。这篇文章不聊那些虚的就讲讲我在实际项目里怎么用 AI 干活哪些地方真的提效哪些地方是坑以及我踩过之后总结出来的工作流。先说清楚这个内容适合谁。如果你是一个独立开发者、小团队的技术负责人或者在大厂里被业务需求追着跑的工程师这篇文章应该能给你一些可以直接抄作业的思路。如果你是刚入行的新人也能从中看到 AI 辅助开发这条路上有哪些弯道哪些地方必须靠自己的基本功兜底。我尽量把话说得直白把踩过的坑和验证过的方法都写出来。1. AI 辅助开发的定位它不是搜索引擎也不是自动程序员很多人对 AI 辅助开发的理解是两个极端。一个极端是把 AI 当成高级版 Google问一句答一句用完就扔另一个极端是期待 AI 能直接丢给你一个完整项目你只需要按回车。这两个极端我都试过结果都不理想。1.1 AI 真正擅长的事模式匹配与上下文联想我自己的理解是现在的 AI 编程助手本质上是一个极其擅长模式匹配和上下文联想的工具。你给它一段代码和一句话需求它能根据海量训练数据里的相似模式生成一段大概率正确的代码。这就像你带了一个读过百万个开源项目的实习生他可能不知道你项目的业务背景但他见过太多类似的代码写法。所以 AI 辅助开发的第一个正确用法是把它用在有标准答案的场景。比如写一个日期格式化函数、实现一段常见的分页逻辑、生成一套 CRUD 接口、写正则表达式、做数据清洗。这些场景在 GitHub 上不知道出现过多少次AI 生成的代码质量往往相当高甚至比我自己手写的还要严谨因为它吸收了大量的边界处理经验。但反过来如果你让它处理我们公司特有的订单状态机流转逻辑或者这个老模块里那个诡异的兼容性 hack 为什么存在AI 就只能给你一本正经地胡说八道。它不是在骗你它只是真的不知道你们项目里那个if (userId admin)后面藏着多少历史债务。1.2 AI 不能替代的东西业务理解和系统设计我见过最惨烈的翻车现场是一个同事让 AI 帮他重构一个支付回调的模块。AI 确实把代码结构理得干干净净但把签名校验和幂等处理给优化掉了——因为在 AI 眼里那几行代码看起来冗余。结果测试环境里直接出现了重复入账。这不能怪 AI因为代码的正确性不只是语法层面的正确还包含业务语义的正确。所以如果你把 AI 当自动程序员用你把需求说清楚它就能交付完整功能那大概率会出事。真正靠谱的用法是系统设计、模块划分、数据模型设计、关键算法选型这些事必须由人来完成AI 负责的是把大方向确定后的那些体力活做得又快又好。说白了AI 是放大你能力的杠杆不是替代你思考的拐杖。2. 我在实际开发中验证过的 AI 工作流以前讲 AI 辅助开发大家聊的都是AI 能帮我写什么。但我现在更关注的是AI 在我整个开发流程的哪个环节介入效率提升最明显。为此我把自己日常开发的流程拆成六个环节逐个试了一遍最后沉淀下来一套固定的工作流。2.1 需求分析阶段用 AI 当提问对象来澄清思路我发现 AI 在需求分析阶段最大的价值不是帮你写需求文档而是当你对练的对象。很多人写需求的时候脑子里其实是一团浆糊自己都没想清楚就开始动手。我的做法是先把粗略的想法丢给 AI让它以产品经理的口吻质问我这个功能解决谁的什么问题用户会在什么场景下使用成功标准是什么有没有边界情况这一招特别有效。因为它逼着我把模糊的想法转成成型的描述过程中我自己会想清楚很多以前忽略的细节。有一次我要给客户做一个数据看板的模块一开始我脑子里只有一个大概的框架。跟 AI 来回对了三轮之后我发现原来我连时间范围默认选什么和数据刷新策略是什么都没想过。这些如果等到开发中后期才想到改起来就是牵一发动全身。现在我会在动手写代码前先花半小时和 AI 把需求盘明白这个时间花得很值。2.2 方案设计阶段用 AI 做多方案对比和风险评估以前做方案设计习惯是自己先拍一个方案然后找同事评审。现在我会先让 AI 基于同样的需求给出三个候选方案并且列出各自的优缺点、复杂度、维护成本。注意我不是直接采纳 AI 的方案我是把它当成一个快速出草案的架构师用它的输出作为讨论的基础避免自己陷入单一思路。比如上面说的数据看板我让 AI 给出技术选型建议。它列出了三个方案服务端渲染表格、前端渲染加虚拟滚动、分页加载加缓存。每个方案都附带了性能预估和适用场景。虽然这些信息我大多知道但 AI 把这些组织成一份可对比的清单省了我不少整理的时间。更重要的是它会提到一些我想不到的细节比如大数据量下的表格要警惕合计行和排序的性能陷阱。这种交叉验证的价值在复杂项目中体现得特别明显。2.3 编码实现阶段按模块对话而不是一次性甩需求这是我花了最长时间优化的一步。一开始我的用法很粗糙就是把整个需求往对话框里一贴让 AI 写完整项目。结果 AI 生成的东西乍看像模像样细看全是问题。后来我摸索出来的方法是把大任务拆成小任务逐个对话严格控制上下文。我现在的编码流程是这样的先把项目背景和整体结构告诉 AI然后把一个大功能拆成若干个独立的函数或模块每次只让它写一个模块。每完成一个模块我会人工 review 一遍确认没有问题后再带着前一个模块的结论去问下一个模块的问题。这样 AI 的上下文始终清晰生成的代码质量和上下文相关性强得多。举个例子我最近写一个批量导入导出的工具。我没有让 AI帮我写一个导入导出功能而是拆成了四个子任务定义统一的数据模型、写解析不同类型文件的方法、写数据校验逻辑、写导入结果的反馈机制。每个子任务单独对话单独审查最后再合到一起。整个过程下来我大概手动修改了三分之一左右的代码但整体效率还是比从零开始写快了不少。2.4 测试阶段把单元测试的重复劳动交给 AI测试是我觉得 AI 投入产出比最高的环节没有之一。以前写单元测试是最让我头疼的事尤其是那种要覆盖各种边界条件、异常分支的测试用例写起来枯燥但还不能省。现在我的做法是先把要测试的函数粘贴给 AI附上函数的输入输出说明和关键分支逻辑让它生成测试用例。AI 生成测试用例有个好处就是它不会被你的思维定势带偏。你自己写测试很容易只覆盖自己想到的路径遗漏一些隐蔽的边界条件。AI 会从数据维度、异常维度、边界维度去补全用例。有一次我写的日期范围计算函数我只考虑了正常跨月和跨年的场景AI 生成的用例把闰年、时区、跨年、大小月全都覆盖了甚至在注释里提醒我注意夏令时对时间计算的影响。我检查后发现这个提醒还真不是废话。当然AI 生成测试用例也需要 review特别是 assert 的部分。它有时候会为了让测试通过而写出不够严格的断言这本质上是一个迎合倾向。我会习惯性地把 AI 生成的断言改得更严格一些确保测试的价值不被稀释。2.5 代码审查阶段让 AI 当你的第一道防线我自己 code review 的习惯分成两轮。第一轮让 AI 审第二轮自己做。AI 审代码的角度和人类不一样它更擅长发现一些客观问题比如变量命名混乱、重复代码、缺少空指针处理、潜在的内存泄漏、不够友好的错误提示。这些是可以通过规则判断的东西AI 审起来又快又准。我曾经让 AI 审查一个同事提交的代码它很快就发现了一个问题一个从外部 API 获取数据的函数没有设置超时时间如果上游服务接口挂掉整个服务会被拖死。这个点我同事没意识到因为本地测试时上游接口一直很稳定。AI 基于它见过的海量代码知道这类外部调用必须考虑容错所以会主动提出来。不过要特别说明AI 的审查结果绝对不能直接当成终审意见尤其是涉及业务逻辑的修改一定要自己判断。AI 有时候会因为过度谨慎建议你加一些完全没必要的判断逻辑有时候又会因为过度自信忽略一些复杂业务场景。所以我的习惯是AI 负责过滤掉低级的、规则性的问题我负责处理高层的、需要业务判断的问题。2.6 文档和重构AI 是强迫症的福音写文档这件事我相信绝大多数开发者的态度都是能不写就不写。但说实话文档的价值往往在项目交接和维护阶段才体现出来。以前写文档是纯消耗现在我会让 AI 先根据代码生成一个初稿我再花几分钟把里面的表述调整得更准确补充一些背景决策和注意事项。重构也是一样。让 AI 做重构的前提是先给它讲清楚约束条件比如不能改变现有接口的行为不能改动这些公共方法签名必须保持和旧的兼容逻辑然后让它在一个小范围内做。我一般会限定在单个函数或单个类内部做重构同时跑一遍测试来保证没改坏。大范围的重构我只敢自己来因为那种改动往往牵扯到业务语义和隐性约定AI 根本看不见那些藏在注释和命名里的潜规则。3. 提示词工程把话说清楚是 AI 辅助开发的必经之路我看到很多人在吐槽AI 生成的东西没法用但点开对话记录会发现他们给 AI 的指令往往是帮我写个登录功能这种一句话需求。这不叫 AI 辅助开发这叫许愿。AI 辅助开发的核心技能之一就是学会把需求描述得足够清晰和专业。3.1 高质量提示词的层次结构我自己总结了背景-任务-约束-验收四层结构按这个结构组织提示词AI 生成结果的可控性会大大提升。第一层是背景告诉 AI 你在做什么项目、用的什么技术栈、目标用户是谁。比如我在做一个面向中小商家的进销存系统后端是 Spring Boot 3 MySQL前端是 Vue3 Element Plus。背景信息决定了 AI 的输出风格和用词习惯。第二层是任务必须具体到可以执行的程度。不要只说写一个库存管理功能而是说写一个库存扣减的方法入参是商品 ID 和扣减数量需要检查库存是否充足不足时抛出自定义异常扣减成功返回剩余库存。第三层是约束把雷区提前标出来。比如不要用数据库悲观锁用乐观锁、异常处理统一抛业务异常不要返回裸状态码、方法命名遵循项目现有的驼峰规范。这些约束你不说AI 就按它自己的习惯来最后风格一定和你项目原有代码对不上。第四层是验收标准告诉 AI生成之后你自检一下确认边界条件都处理了把实现思路和完整代码分开输出。这一层是为了让 AI 在输出前自己过一遍能有效减少一些低级错误。3.2 上下文管理的几个实操技巧除了提示词本身上下文管理也很关键。我用 AI 辅助开发一段时间后最大的感受是AI 的上下文窗口再大也不如你把上下文精简到 500 字以内。技巧一按功能模块开新会话。我见过很多人一个会话从头用到尾聊了几百轮之后 AI 已经完全不知道在干嘛了。正确做法是每个功能模块开一个会话会话里只保留这个模块相关的上下文。技巧二先让 AI 复述需求再动手。我会在任务描述后面加一句先用三句话总结一下你理解的开发任务和实现思路我确认无误后你再开始写代码。这个步骤看着多了一轮交互实际能省下大量返工的时间。AI 的理解和你想要的不一样时这一步能最快暴露问题。技巧三粘贴代码时带上文件和依赖的信息。让 AI 改代码的时候如果不告诉它在哪个文件、依赖什么模块它就只能瞎猜。我通常会把相关的 import 语句、函数签名、数据模型定义一起贴给 AI这样它生成的代码在集成时不会出现变量未定义这种低级问题。3.3 一个完整的提示词模板最后分享一个我存下来的通用模板你们可以直接复制去改背景我在开发一个 [项目类型]使用 [技术栈]项目已有 [关键模块/约定]。任务请编写一个 [功能描述] 的 [函数/模块/接口]入参是 [列出参数]出参是 [列出返回格式]。约束[列出需要遵守的规则如命名规范、异常处理方式、性能要求等]。验收请先简要说明实现思路再输出完整代码并自检边界情况。代码里关键逻辑请加中文注释。这套模板看起来简单但实际执行起来效果和我以前一句话甩需求完全不在一个量级。4. 多 AI 协作工作流不同模型干不同活最近我越来越倾向于一个做法不把所有的任务都押在同一个 AI 上而是根据任务类型选择不同的模型来配合形成一个多 AI 协作的工作流。这听起来有点折腾但实际用下来效率和稳定性都比单模型强不少。4.1 谁适合做规划谁适合写代码谁适合审查先说我目前的配置和理由。规划类任务——比如拆解需求、设计方案、梳理步骤——我会用推理能力比较强的模型。这种模型的好处是它能从几个维度去分析问题、权衡方案给出的规划更周全。它的缺点是生成速度偏慢而且输出往往过于啰嗦不适合用来快速生成代码。编码类任务我用的是生成速度快、代码质量稳的模型。这种模型不需要想太多为什么直接把见过最多的写法给你生成出来效率极高。我实测下来这种模型在生成 CRUD、工具函数、数据转换逻辑的时候速度和准确率都很顶。代码审查类任务我会用第三类模型。它更擅长挑刺能够发现单元测试没覆盖到的分支、异常处理的遗漏、甚至性能隐患。这三类模型各自分工不同我按任务类型去切换模型而不是一个模型从头用到尾。4.2 多 AI 协作的实际流程示例给你们看看我最近做一个内部运营工具时的实际操作流程。第一步我先用规划型模型把整个工具需要实现的功能拆解成 12 个任务并排好优先级和依赖关系。第二步我从中抽出两个核心模块让编码型模型分别生成原型代码我再统一 review 和调整。第三步我把两段代码合并之后丢给审查型模型做一轮全面的代码评审然后针对审查意见逐个修改。整个过程没有哪个环节是在等待 AI 慢慢思考的每个模型做它最擅长的事速度是单模型串行执行的数倍。这一套流程跑下来我的体感是多模型协作的本质不是更聪明而是更专。你让一个模型面面俱到它必然在某个维度上妥协你让它在一件事上钻到极致效果反而更好。这和找人干活是一样的道理你不能指望一个全栈工程师在架构设计、编码速度、代码审查三个方向上都做到顶级但你可以让三个偏科的人组成一个全能的团队。4.3 协作中的沟通成本多 AI 协作也有代价就是你要在不同模型之间传递上下文这个传递过程需要你手动整理。比如我在编码型模型那儿拿到了代码丢给审查型模型之前我得先把需求文档里的验收标准摘出来附上项目技术栈说明这样审查型模型才知道该按什么标准来审。这个整理上下文的环节其实就是你在主动提炼任务的核心诉求对个人能力是有锻炼价值的。你整理得越清楚模型协作的效率就越高最后沉淀的这套方法论是你自己的不是某个模型的。5. 常见翻车现场AI 辅助开发的六大坑AI 辅助开发不是没有坑相反它的坑比传统开发的坑更隐蔽因为 AI 犯错的表面形式是言之凿凿很容易让人放下戒心。我把自己踩过、以及身边的同事踩过的坑做了一个总结希望能帮你们少走一些弯路。5.1 AI 幻觉一本正经地胡说八道AI 会编造不存在的 API、不存在的函数签名、不存在的配置项。我印象最深的一次是 AI 让我在配置文件里加一个enable_cache参数说这样能提升性能。但我去翻官方文档根本没这个参数。它把另一个框架的配置项混进来了。对策AI 输出的代码里出现了任何你不认识的 API、类名、配置项无条件回去查文档。不要因为 AI 的语气自信就放弃校验。这个习惯必须养成因为它能在关键时刻救你一命。5.2 上下文遗忘聊着聊着就变傻这个问题在多轮对话里尤其严重。你可能前五轮聊得挺好第六轮的时候 AI 突然忘了前面定义过什么变量、用什么技术栈、有哪些约束条件然后输出一份和你需求完全对不上的代码。对策大任务拆小任务小任务尽量控制在五轮对话以内完成。如果发现 AI 开始变傻不要试图在现有会话里把它纠正回来果断开新会话把上下文重新梳理一遍再继续。很多时候新会话比在旧会话里掰扯半天效率高得多。5.3 代码风格漂移AI 生成的代码单独看没什么问题但放进你的项目里会和原有代码风格格格不入。比如你项目里用的是ResultT统一封装返回AI 偏偏生成一个直接返回T的方法你项目里异常处理用的是if (xxx) throw new BizException(...)AI 却写了个return null。这种不一致在长期维护时很让人抓狂。对策在提示词里明确说明项目的代码风格约定。更有效的做法是把你项目里某个典型模块的代码片段直接喂给 AI 作为风格参考告诉它按这个代码的风格写。这比任何口头描述都管用。5.4 过度重构AI 天生有优化癖它看到一段不够优雅的代码就会忍不住动手优化。但在真实项目里不够优雅不等于可以随便改。很多看起来冗余的代码背后可能是线上事故的补救、历史数据的兼容、或者是某个不知道什么时候才会触发的隐藏逻辑。对策涉及重构时明确告诉 AI保持现有行为完全不变仅做结构调整。更重要的一点是AI 完成重构后一定要跑全量测试不只是相关模块的测试。因为我遇到过 AI 把 A 模块重构好了但顺带改了 B 模块的一个公共方法的行为导致 B 模块的测试直接飘红。5.5 盲目信任测试结果前面说过 AI 生成的测试代码可能有迎合倾向。还有一个常见情况是AI 生成的测试代码测试的数据恰好都在正常范围内根本没测到压力边界和异常情况。你看着测试全都通过了以为功能稳了其实只是测了个寂寞。对策AI 生成的测试代码你要自己补几条边界用例和异常用例。特别是对于时间、数值、字符串长度、并发这几个方向一定要手动测试覆盖到。5.6 安全漏洞这个坑的专业门槛比较高但水也最深。AI 受过大量安全最佳实践的训练但它并不清楚你代码运行的具体安全环境。比如它会生成一段解析上传文件的代码却可能忽略文件类型的白名单校验它会写一段拼接 SQL 的逻辑如果不明说它不会默认用参数化查询。对策凡是涉及用户输入、文件上传、数据库操作、权限校验的 AI 生成代码必须人工严格审查安全相关的逻辑。这也是我为什么一直强调 AI 辅助开发的底线是工程师必须自己兜底安全。6. 关于成本和收益什么时候该用 AI什么时候不该用讲了这么多实操最后聊聊一个不太被提起但很重要的话题成本和收益。AI 辅助开发不是在所有场景下都划算的有些任务用 AI 反而更亏。6.1 适合用 AI 的场景我总结下来适合用 AI 的场景有三个特征。第一任务有明确的标准答案比如实现一个常见的算法、调用一个知名的 API、写一段标准的配置。第二任务的价值密度低但体量大比如给几百个接口补注释、生成单元测试骨架、批量写枚举对照表。第三任务需要快速出能看的版本来验证思路比如写一个临时脚本、做一个原型 demo、模拟一批测试数据。这类场景我用 AI 的体感非常爽。以前写 50 个测试用例要花一整个下午现在可能半小时就出完初稿我再用半小时 review 修正。效率提升不是一倍两倍是十倍往上的。6.2 不适合用 AI 的场景不适合用 AI 的场景也有三个特征。第一业务逻辑复杂且没有现成模式可以参考比如一个牵扯多方状态流转的审批系统状态之间的跳转全是有实际业务含义的。第二代码涉及高并发、高可用、数据一致性这类硬核问题AI 给出的方案往往过于理想化缺乏对真实压力的考量。第三老代码维护。老项目通常有大量历史包袱代码的实际行为和注释描述完全对不上AI 没有足够的信息做出正确判断。这些场景下强行用 AI 辅助反而会增加你的工作量先花时间鉴别 AI 输出是否正确再把错误部分改回来一来一回比直接从零手写还要慢。6.3 成本账除了时间和效率还有一笔经济账。付费的 AI 编程工具和 API 按量计费大规模使用之后账单不一定便宜。我自己用下来的经验是建立预算观念很有必要。像那些快速验证想法、随手写个临时脚本的任务我用免费版就足够了真正复杂的编码任务我才会用到更贵的模型。另外还有一个隐形成本上下文整理的成本。如果你自身的表达能力、逻辑拆解能力不够强你会在把需求描述清楚这一步耗费大量时间这个成本甚至会超过 AI 帮你省下的编码时间。所以我的建议是在投入学习 AI 辅助开发之前先确保你自己的基本功是扎实的。不然你不是在用 AI 提效你是在给自己找新麻烦。7. 最后几个真心话写了这么多最后分享几个我最近在想的东西。AI 辅助开发这一波浪潮和以前那些新框架、新语言的出现本质是一样的它会淘汰一批人也会奖励一批人。被淘汰的是那些觉得AI 能搞定一切所以我可以不用学了的人被奖励的是那些把 AI 当成杠杆、同时拼命巩固自己基本功的人。我个人在实际操作中最大的体会是AI 辅助开发的中线不在工具上而在人上。你的设计能力越强、逻辑越清晰、代码品味越好你用 AI 干活的效率就越高。AI 不会主动帮你把烂需求变成好代码它只会把你给的模糊需求翻译成模糊代码。所以与其焦虑AI 会不会替代程序员不如想想我能用 AI 把更难的活干得多快。最后再分享一个小技巧每天花十几分钟做一件事把当天写的最满意的一段 AI 辅助代码拿出来对着它反思一下——哪些部分 AI 写得比你好哪些部分是你改出来的你为什么改。这个复盘的习惯我坚持了大半年收获比看任何 AI 教程都大。AI 辅助开发这条路说到底是一个持续和工具磨合的过程你的判断力会随着你的使用次数慢慢变得精准最后你会在信任 AI和质疑 AI之间找到一个恰到好处的平衡点。到那个状态AI 才真正是你的队友而不是一个时灵时不灵的玩具。