1. 你每天用的 AI 编程可能只是冰山一角这两年 AI 编程几乎是技术圈最热的话题从 GitHub Copilot 到 Cursor再到国内各种模型和插件几乎每个开发者的编辑器里都装了一两个 AI 工具。但有个挺有意思的现象很多团队和个人用 AI 编程实际提效效果差别巨大。有的人用 Copilot 只是把注释变成代码觉得“也就那样”有的人却把 AI 嵌进了需求分析、架构设计、编码、测试、重构、评审、文档、运维的整个研发链路交付效率翻倍还不止。问题出在哪我个人的判断是——大多数人只把 AI 当成“自动补全工具”而没有把它当成“一条完整的辅助研发流水线”。AI 编程提效提的绝不只是“打字速度”而是覆盖研发全流程的脑力外包、信息检索、模式复用和质量兜底。这篇文章我就基于自己这一年多在真实项目里折腾 AI 编程的经历把 AI 编程提效这件事拆成十个模块每个模块都讲清楚它到底提了哪部分效率、具体怎么落地、有哪些坑要避。内容不吹不黑都是实测过的方案。适合谁看如果你是独立开发者、技术 leader或者团队里正在推 AI 编程落地的人这篇文章应该能给你一张相对完整的路线图。如果你是刚接触 AI 编程的初级开发者前面几节也能帮你建立正确的使用心智——用 AI 编程不是“抄代码”而是“和 AI 结对编程”。2. 全局认知AI 编程提效的本质是什么2.1 提效的不是“生成代码”而是“减少上下文切换”先说一个经常被误解的点AI 编程最核心的提效点其实不是代码生成速度而是减少了开发者在不同认知任务之间的切换成本。举个例子你正在写一个订单模块突然需要查某个 Java 时间处理的 API 用法。传统做法是切到浏览器、打开搜索引擎、翻几篇博客、找到代码片段、再切回 IDE 改代码。这一来一回看着只有五分钟但注意力被打断后重新进入深度工作状态往往要十分钟以上。用 AI 编程工具你直接在编辑器里输入问题几秒钟得到答案根本不需要离开当前的代码上下文。这种“状态保持”带来的效率提升远比那几行自动生成的代码更有价值。再往深一层看AI 编程提效的本质是把“如何做”的检索成本降为零把“做什么”和“为什么”的判断留给人类。AI 可以三天三夜不睡觉地帮你翻文档、写样板代码、适配接口但它不会告诉你业务场景到底该选哪种方案。提效的前提是你对自己要解决的问题有清晰认知AI 越强这个前提越重要。2.2 提效分布在研发全生命周期不只在编码阶段很多人以为 AI 编程就是“写代码的时候用”但我实测下来编码阶段只是 AI 施展拳脚的一小部分。真正的提效大头分布在这些环节需求理解和澄清阶段AI 能帮你从一段含糊的产品描述中提取需求点、识别边界条件、生成测试用例清单。技术方案设计阶段AI 能基于约束条件快速给出多种候选技术路线省去大量资料调研。编码实现阶段AI 自动生成样板代码、单元测试、接口对接代码。测试与质量保障阶段AI 能辅助生成测试数据、边界用例甚至自动修复部分静态检查问题。重构与维护阶段AI 能分析代码结构、识别坏味道、给出重构建议。知识沉淀与文档阶段AI 能把散落的决策记录整理成结构清晰的文档。把这六个阶段的效率提升加起来才是 AI 编程真正的杠杆。只盯着编码阶段那一小段等于买了个高配电脑只用来打字浪费。3. 基础设施准备模型选择与提示词基本功3.1 模型怎么选不是越强越好要匹配场景用 AI 编程第一个要解决的问题是“用什么模型”。很多人的直觉是“最强的一定最好”实操下来还真不一定。模型的选择要同时看四个维度代码理解能力、上下文长度、响应速度、成本。我目前的经验是分场景选模型日常补全和简单问答用响应速度快的轻量模型比如各家 IDE 插件内置的默认模型这类任务对深度推理要求不高但很吃延迟。你等两秒出结果和等十秒出结果体验天差地别。复杂架构分析、跨文件重构用推理能力更强的重量级模型上下文最好能覆盖整个项目的主要文件。这类场景等三十秒甚至一分钟都可以接受但答案质量必须高。测试数据生成、文档整理用中等能力的模型就够了重点看它对上下文的遵循程度。还有一个选型建议优先选和你的 IDE 深度集成的产品而不是单独开网页版去复制粘贴。深度集成的意思是模型能看到你当前打开的文件、选中的代码、甚至整个项目的结构和编译错误。这种“全上下文感知”带来的效果提升比模型本身参数大一个量级还明显。国内开发者还要额外考虑网络和服务稳定性问题选型时把这部分纳入评估别光看 benchmark 分数。3.2 提示词的核心心法给模型“角色、上下文、任务、约束”AI 编程的提示词和通用写作提示词不太一样它更接近“给一个经验丰富但对你项目一无所知的远程同事发消息”。我调试了很长时间总结出一套相对稳定的提示词结构四个要素缺一不可角色告诉模型它是什么身份。比如“你是一名有十年经验的 Java 后端工程师精通 Spring Cloud 微服务体系”。上下文把当前任务相关的信息全部交代清楚。项目是什么、用的是什么技术栈、相关的类或文件叫什么名字、要对接的接口签名是什么。任务一句话说清楚要做什么。越具体越好——“写一个方法”永远不如“写一个方法入参是 userId 和 pageNum返回该用户的订单分页列表按创建时间倒序”效果好。约束明确告诉模型不要做什么。比如“不要改变现有方法的签名”“不要引入新的第三方依赖”“返回结果只包含核心代码不要解释”。把这四个要素写清楚AI 输出的代码质量会提升一个档次。很多人觉得 AI 写代码“不靠谱”八成是提示词给的信息不够等于让一个高级工程师在完全不了解背景的情况下瞎猜需求换真人来也干不好。4. 从需求到设计AI 帮你做需求拆解和方案比选4.1 用 AI 做需求澄清几分钟生成一份需求 checklist实际项目中最耗时的往往不是写代码而是搞清楚“到底要做什么”。你拿着产品经理的三行描述去写代码写到一半发现理解偏了这种返工成本极高。AI 在需求澄清阶段的用法非常实用把原始需求文本直接丢给模型让它做三件事列出所有隐含的需求点和边界条件。针对模糊的地方提出澄清问题。生成一份验收标准清单。我举一个实际例子。某次接到需求给现有后台系统加一个“用户导出报表”的功能。这句话看起来很简单但落地时全是坑导出格式是 Excel 还是 CSV数据量上限是多少是异步生成后下载还是同步流式返回权限怎么控制导出历史记录要不要留存字段列表由谁决定如果直接写代码至少得踫两次壁才能搞清楚。但把这段需求丢给 AI它能在几秒内把这些未知问题全部列出来。你拿着这份问题清单去找产品经理逐项确认沟通效率提高了一倍不止。4.2 方案设计阶段的 AI 用法从“自己踩坑”到“信息平权”传统技术方案设计最耗时的环节是资料调研。以前要评估“接入一个消息队列到底选 RabbitMQ 还是 Kafka”你得看文档、查性能对比、翻社区踩坑帖至少花半天到一天。现在可以把约束条件直接丢给 AI“我们团队熟悉 Java日均消息量预计百万级对消息丢失敏感需要延迟队列能力比较一下 RabbitMQ、Kafka、Pulsar 的选型”。AI 能给出一个相对全面的对比分析包括性能差异、运维复杂度、学习成本、社区生态。你基于这个分析再对自己关心的特定点做交叉验证调研效率能提升一个数量级。但这里有个重要提醒AI 的技术方案只能作为候选不能作为最终决策依据。AI 给出的信息偶尔会过时或张冠李戴尤其在框架版本、API 变化比较快的领域。我的习惯是让 AI 负责“生成候选方案和分析框架”自己负责“验证关键事实”两者结合才是最稳妥的做法。5. 编码实现的核心AI 补全、代码生成和自然语言转代码5.1 用 AI 补全的正确姿势写注释比写代码更高效我见过很多人用 AI 补全方式是先写一个函数名然后看模型能猜出什么。这种用法效率极低因为模型接到的信息量太少猜出来的代码往往不是你想要的。更好的做法是用注释描述意图让注释成为 AI 的“需求文档”。举个例子你想写一个把驼峰命名转下划线命名的函数。如果你只写一个toUnderScoreCase()模型可能给你一个非常基础的实现边界情况一个没处理。但你如果写这样一段注释/** * 将驼峰命名字符串转换为下划线命名 * 例如: userName - user_name * 处理连续大写: userID - user_id * 字符串可能包含数字数字前不需要添加下划线: user2Name - user2_name */模型生成的代码会直接覆盖所有边界情况基本不用改就能用。这背后的逻辑很简单AI 补全本质上是在“理解意图”后生成代码你给它的意图越明确它输出的代码就越准确。写注释本身也是在帮你自己理清思路一举两得。5.2 用对话方式生成完整函数三步法如果补全不够用需要生成一个较完整的功能模块我推荐用对话式生成但不要一上来就让它“生成整个模块”。三步走更稳第一步先让模型给出实现思路。不要代码只要逻辑步骤。比如实现“限流器”你让模型列出几种可选算法、每种算法的适用场景和优缺点。确认思路没问题后再进入下一步。这一步的作用是帮你判断方向是否正确避免在错误方案上深入。第二步让模型按思路生成骨架代码。把第一步讨论确定的思路粘贴给模型让它实现一个“只有主要流程、没有细节”的版本。检查这个骨架是否符合你的预期。第三步逐段补齐细节。针对骨架中的关键函数让模型补充异常处理、边界检查、日志输出等细节。每一步的改动范围都很小容易审查也容易纠错。三步法看似多花了几轮对话但实际总耗时反而更短。因为一步到位生成的代码通常会有隐藏的编译错误和逻辑漏洞调试成本远高于多花两轮对话的成本。5.3 大批量代码生成的关键分批次 保持接口一致做后端开发时经常会遇到大批量类似的 CRUD 代码比如新增一个数据表后要生成 Entity、Mapper、Service、Controller 四个层次的全部代码。这种场景用 AI 能省大量时间但策略非常关键。我的经验是分批次生成先让 AI 根据表结构生成 Entity 和 Mapper 层审查没问题后再基于 Mapper 接口生成 Service 层最后生成 Controller。每一批次生成时都明确告诉 AI“前面已经生成了哪些文件、接口签名是什么”并要求“新生成的代码必须基于已有的接口签名”。这里最容易踩的坑是一次性让 AI 生成所有层次代码结果各层的方法命名、参数类型完全对不上改起来比手写还慢。分批生成的好处是每批的上下文范围小AI 出错的概率低而且每批完成时你都能立即检查接口一致性把问题消灭在早期。5.4 自然语言转代码的边界要会判断“什么时候不该用 AI”虽然 AI 编程工具越来越强但它并不是所有场景都好用。根据我的经验以下几类任务目前不适合交给 AI核心算法且对性能要求极致敏感的代码比如底层数据结构实现、高频热路径的性能优化AI 生成的方案往往不够极致人工优化空间很大。需要深度业务领域知识才能写对的代码如果一段业务逻辑依赖你对公司内部规则的理解而这段理解没有写成文档AI 是猜不准的。复杂的并发调优和分布式一致性处理这类问题即便 AI 给出看起来合理的代码你也需要极其仔细地推敲才能确认正确性而推敲的时间可能比手写还长。代码风格需要与现有老旧系统完全一致的场景老系统的风格可能充满历史包袱AI 很容易生成“更现代”但格格不入的代码。判断标准其实很简单如果你对这段代码的期望结果都描述不清楚就别用 AI。AI 是放大器你的理解清晰它帮你放大效率你的理解模糊它帮你放大错误。6. 测试提效AI 帮你把测试用例生成做到“批量生产”6.1 单元测试生成别贪多要有策略AI 写单元测试的能力这两年进步非常快但直接让它“给这个类生成完整的单元测试”通常得到的是一堆没有意义的用例。我的做法是给 AI 提供四个信息被测类的代码、依赖的 mock 方式、希望覆盖的分支场景、代码风格要求。比如你可以这样说“这是 UserService 类的 loadUser 方法依赖 UserRepository 和 RedisTemplate。请生成单元测试覆盖以下场景用户存在、用户不存在、缓存命中、缓存未命中但数据库有数据、数据库查询抛异常。使用 Mockito 做 mockJUnit 5 风格。”这样生成的测试用例直接可用率会大幅提高。我还发现一个规律给 AI 看代码比给它讲需求有效得多。与其用自然语言描述“一个方法在用户不存在时应该抛异常”不如直接把方法体丢给它让它分析所有分支条件并生成用例理解会更精准。6.2 测试数据生成从手工造数到一键铺底测试最耗时的环节之一就是造测试数据。曾经为了造一个“用户下有 1000 个订单其中 30% 已支付、30% 待支付、20% 已取消、20% 退款中”的测试场景我得写一长串 SQL 往测试库里插数据。现在直接把表结构和字段规则告诉 AI它能快速生成一段符合规则的 SQL 或代码。这里的小技巧是给 AI 提供“真实字段枚举值”而不是让它瞎编。比如数据库里order_status字段只有 0/1/2/3 四个值你得明确告诉它否则它会凭“常识”猜一个 4 出来你的业务代码可能显示异常。6.3 AI 测试提效的更高阶用法让 AI 帮你写测试计划除了生成单个用例AI 还可以帮你做更高维度的测试设计。把需求文档和接口定义给 AI让它列出完整的测试场景矩阵包括正常流、异常流、边界值、权限校验、并发场景、幂等性验证等。这一步帮很多团队补上了“总是忘记测边界条件”的短板。我实测过的用法是在需求评审阶段就让 AI 参与让它基于需求描述生成一份“测试要点清单”测试人员拿着这份清单去写详细用例基本不会漏场景。7. 重构提效AI 辅助代码分析、坏味道识别与重构建议7.1 让 AI 做代码 review第二双眼睛的价值在于“反面意见”AI 编程工具不只会写代码还能帮助做代码评审。把一段刚写完的代码贴给模型让它从这几个角度挑毛病可读性、潜在 bug、边界情况、异常处理、性能隐患、命名规范。你会惊讶地发现AI 能找出很多真人 review 时容易忽略的问题。尤其是边界情况比如空指针、并发访问、超大输入等AI 的“考虑周全度”往往高于人肉审查。但它的 review 结果需要人工二次确认因为它偶尔会给出“看似正确但实际不合理”的建议尤其在对业务背景不了解时。7.2 识别坏味道与提议重构方案把“要不要改”的判断留给自己接手一个遗留系统时AI 的价值尤其明显。把一段几百行的老代码丢给 AI让它分析这段代码存在哪些坏味道过长函数、过深嵌套、重复代码、职责不单一等。如果要重构建议拆成哪几个类和哪几个方法每个方法的职责是什么。重构过程中有哪些风险点容易引入 bug。AI 输出的重构方案往往相当靠谱相当于一个资深工程师快速浏览了你的代码并给出 suggestion。但我要强调AI 可以告诉你“怎么改”但“要不要改、什么时候改”必须你来判断。重构是最容易引入回归风险的操作如果测试覆盖不足再好的重构方案都可能把线上搞挂。7.3 跨文件影响分析让 AI 当你的“代码考古学家”日常开发中经常遇到一个头疼的问题要改动一个公共方法的签名但不知道哪些地方调用了它、影响面有多大。传统做法是全局搜索然后逐个点击查看费时费力。现在可以用 AI 辅助做影响面分析把公共方法的定义和所有调用点贴给 AI让它判断每个调用点的调用方式、是否需要跟随修改、修改的话变量名和参数应该怎么调整。我用这个方式在某个中型项目中做过一次公共方法重构原本预计要花两天逐个人工排查结果半天就搞定了而且修改完跑测试一次通过。AI 做这种“静态分析 建议生成”的工作比人肉翻代码快太多。8. 文档与知识沉淀AI 编程的隐藏提效点8.1 从“写完代码再补文档”到“边写边生成”写文档是大多数程序员最抗拒的事情之一——写完代码后还要费劲回忆思路、组织语言、画流程图。AI 把这件事变成了“白拿的福利”。我现在的习惯是在一个功能开发完成后把核心代码和设计思路一起贴给 AI让它生成接口文档、调用说明、部署注意事项。它生成的初稿也许不够完美但至少有七八十分稍微润色就能用。和从零写文档相比省的时间非常可观。8.2 让 AI 维护代码间的“知识关联”大型项目里最难维护的其实是“隐性知识”某个接口为什么这样设计、某个参数为什么必须传特定值、某个地方为什么不能改。这些知识通常只存在老员工脑子里没有文字沉淀一旦人员流动就彻底丢失。AI 可以在一定程度上缓解这个问题。你可以定期把关键代码片段和对应解释做成 markdown 文档用 AI 脚本建立索引后续问 AI“为什么这个接口要加 userId 参数”时它能直接从索引中检索到相关说明。这等于给项目建了一个会自动维护的“活文档”成本极低收益长远。8.3 文档代码一致性检查AI 的价值不止于“生成”也在于“校验”很多项目存在文档和代码不同步的问题——代码改了接口文档没更新。过往靠人工 review 很难彻底解决因为文档几百页人不可能逐一对。现在可以用 AI 做一致性校验把接口代码和对应文档段落丢给 AI让它找出不一致的地方。实测下来的效果很好能揪出很多“参数名变了但文档没变”“新增了字段但文档没提”之类的问题。把这种检查做成 CI 流水线的常驻任务文档漂移的问题基本能控制住。9. AI 测试自动验收质量保障的闭环9.1 让 AI 写集成测试和端到端测试的关键思路AI 写单元测试相对容易因为输入输出边界清晰mock 思路明确。但集成测试和端到端测试涉及多个模块、外部依赖、真实数据库AI 生成起来难度大不少也更需要人工干预。我实测下来的经验是先让 AI 生成测试的“骨架流程”而不是完整代码。比如端到端测试“用浏览器自动化框架打开登录页、输入账号密码、点击登录、断言跳转到首页”这条链路可以让 AI 先生成完整的操作步骤列表确认每一步的顺序和预期结果无误后再让它按步骤生成具体代码。这样做的好处是流程设计错了代码写得再好也是白搭流程对了代码生成往往相当快。9.2 通过 AI 补全异常场景分支提升代码覆盖率很多项目的代码覆盖率上不去不是因为核心逻辑没测到而是“小概率异常场景”没人想得到。AI 在发现这些异常分支方面有天生的优势。把被测方法贴给 AI让它列出“所有可能抛出异常的位置”以及“对应的触发条件”再让它逐个生成测试用例。它通常会找出开发者和测试人员都忽略掉的角落比如一个空字符串输入、一个超出范围的索引、一个突然返回 null 的依赖对象。这些用例补上去之后覆盖率的提升非常明显。9.3 一个真实案例用 AI 在两周内把接口自动化覆盖率从 30% 拉到 70%今年早些时候我们接了一个老项目的自动化回归改造。存量接口四十多个原本的接口自动化覆盖率只有三成多靠测试团队手工补用例两周内很难做完。我们的做法是把每个接口的 Controller 代码、请求参数定义、业务分支说明整理好统一交给 AI 批量生成接口测试用例再人工做两轮 review 和修整。结果是两周内补了 200 多个接口测试用例覆盖率从 32% 拉到了 71%。当然并非所有用例一次通过大概有 20% 左右需要人工调整断言逻辑或数据准备方式但整体效率依然远高于纯手工编写。这个案例说明AI 测试提效不是停留在 PPT 上的概念它是能切切实实落地的。10. AI 编程的常见问题与排查技巧10.1 模型“胡说八道”怎么办验证策略三件套AI 生成代码偶尔会出现一种让人头大的情况代码看起来完全合理但跑起来就是不对甚至编译都过不去。根本原因是模型在“编造”一些不存在的 API 或语法。遇到这种情况不要试图和它辩论直接用这三个手段验证编译器和静态检查工具优先。把 AI 生成的代码交给编译器或 IDE 的静态检查编译错误会立刻暴露大部分问题。针对 AI 提到的 API 做官方文档核对。如果 AI 说自己用了某个库的某个方法去官方文档里搜索确认这个方法是否真实存在、参数签名是否正确。用更小的样例验证逻辑。如果代码运行结果不对抽离最小复现样例单独测试定位是逻辑问题还是 API 误用问题。遵守这条原则之后AI 生成代码的可用率会大幅提升。AI 不是神它也会一本正经地胡说八道你必须有验证意识和验证手段。10.2 上下文窗口不够怎么办分段对话策略项目到后期一个文件可能上千行AI 的上下文窗口装不下完整内容。这时强行把整个文件塞给它它会忽略一部分信息导致输出质量明显下降。我的处理策略是“分段对话”先让 AI 阅读关键的一个函数或一个类基于这个小上下文完成局部改动。涉及跨文件时只粘贴必要的接口签名和数据结构定义不要粘贴无关的实现细节。把大任务拆成一系列小任务每次只让它“理解一小块、修改一小块”。分段对话的代价是需要频繁“喂”上下文但好处是每次的准确率都很高。在上下文受限的现实条件下这是产出质量最稳定的策略。10.3 AI 编程引入的安全与合规风险最后必须提醒一个很多人忽略的风险面AI 生成的代码可能引入安全隐患和合规问题。安全隐患方面AI 可能在你没注意的情况下生成了不安全的代码——SQL 拼接、硬编码密钥、缺失输入校验、不安全的反序列化等。虽然这些“坏习惯”在 AI 训练数据里正在减少但依然存在漏网之鱼。我的做法是所有 AI 生成的代码都必须经过一轮“安全视角 review”重点关注数据出入参、外部输入处理和敏感信息管理这三个环节。合规方面要关注公司对 AI 工具的准入要求。很多企业要求内部代码不能发送给外部 AI 服务处理这里涉及商业机密和数据隐私。团队在引入 AI 编程工具前最好先和法务、安全团队确认清楚哪些代码可以交给 AI 处理、哪些必须脱敏或完全禁止。踩过这个坑的团队都知道事后补救的成本是事前预防的上百倍。11. 团队落地 AI 编程的实操建议11.1 分阶段推行不要一刀切如果团队要推 AI 编程我的建议是分三步走不要一刀切要求所有人必须使用。第一步是“试点期”挑 2-3 名对新技术接受度高的同学让他们在自己的项目里用起来沉淀出团队的 best practice。第二步是“推广期”把试点期的成功案例和踩坑记录整理成文档组织一次内部分享让其他人看到“这东西确实有用”逐步扩大使用范围。第三步是“规范化期”把 AI 编程的用法和限制写入团队开发规范比如哪些场景鼓励用 AI、哪些场景必须人工编写、AI 生成代码的最低 review 要求是什么。这个推行节奏最平滑也最容易让团队成员接受。强行从上往下推往往会遭遇大量抵触情绪最后工具一大堆但没人真正用起来。11.2 积累团队的 AI 编程提示词库团队协作时比个人技巧更重要的是知识共享。我强烈建议团队维护一个提示词库把高频场景的优质提示词沉淀下来比如“生成接口文档的提示词模板”“生成规范单元测试的提示词模板”“重构遗留代码的提示词模板”。这样做的好处有三层第一层新人加入团队时不用从零摸索提示词写法直接拿库里的模板就能上手第二层团队积累下来的提示词已经踩过坑生成质量有保障第三层提示词库本身就是团队对“AI 编程最佳实践”的沉淀后续迭代时可以持续优化。这个提示词库不需要很复杂用 Git 仓库维护 markdown 文件就够了重点是持续积累、持续迭代。11.3 明确底线哪些场景不允许用 AI推行 AI 编程最忌讳的是“什么任务都丢给 AI”。我的建议是团队需要明确列出“禁止使用 AI”的场景清单通常包括涉及敏感业务数据和用户隐私的代码。核心支付、交易链路中的关键逻辑。需要满足特定合规审计要求的代码。算法和性能优化的核心部分。设定底线的目的不是为了限制 AI 使用而是为了控制风险。AI 编程提效的前提是风险可控把高风险场景排除在外团队才能放心大胆地在其他领域追求效率。12. 最后分享一个小技巧让 AI 成为你的“第二大脑”整个 AI 编程的实践下来我最大的体会是AI 帮我们省下来的时间一定要花在更有价值的思考上。如果只是把省下来的时间用来写更多的代码那就失去了提效的意义。我个人现在的习惯是每做完一个功能都会留一点时间让 AI 帮我生成“设计决策记录”——为什么用这个方案、为什么不用另一个方案、遇到了哪些坑、有什么替代方案。这些记录积累起来就是项目最宝贵的技术债务档案和知识库。半年后再回看这些记录你对项目架构的理解会远超当初埋头写代码的自己。从编码补全到测试生成从重构助手到文档沉淀AI 编程的提效是全方位的。但说到底它还是一个工具你的工程判断力、业务理解力和架构能力才是真正决定效率天花板的东西。把这篇文章里的方法用起来结合实际项目不断调试你会找到最适合自己的一套 AI 编程工作流。