意图驱动开发IDD全解析：从AI写代码到AI做开发

1. 什么是意图驱动开发IDD从“让AI写代码”到“让AI做开发”最近这大半年我一直在折腾各种AI编程工具从最初的代码补全到后来的AI Agent自动改Bug再到现在的意图驱动开发Intent-Driven Development简称IDD整个过程有点像从“开手动挡”到“开自动挡”再到“给车装个导航”的转变。早期我们用AI本质上是把AI当成一个更聪明的自动补全器你告诉它函数名、注释、类型签名它帮你把函数体填出来后来AI Agent出现你给它一个Issue描述它能自己翻代码、改文件、跑测试而到了IDD这个阶段玩法彻底变了——你不再直接描述“代码长什么样”而是描述“你想要什么”剩下的拆解、设计、编码、验证全部交给AI那条流水线。我记得第一次真正体验到IDD的威力是在做一个内部数据看板项目的时候。当时产品经理丢过来一句话“我想看每个销售团队近30天的签单趋势要能按区域筛选最好还能导出Excel。”放在以前这句话到开发手里要经过一轮需求评审、一轮技术方案、一轮任务拆分然后才能进入编码前后至少两三天。那次我直接把这句话原封不动丢给了AI编程工具几秒钟后它开始自己分析数据模型、生成查询接口、搭前端图表、再加了一个导出按钮。当然结果不是一次就完美的中间我让它改了两次筛选逻辑、调了一次日期格式但整个上线过程从“两三天”压缩到了“一下午”。这就是IDD给我最直观的感受交付的不是代码而是意图被满足的结果。那IDD到底是什么简单说它是一种以“意图”为第一输入、以“AI Agent自动执行”为手段、以“验证反馈闭环”为质量保障的新的开发范式。它的核心链条可以概括为四步意图提炼 → 任务拆解 → 自动编码 → 验证交付。第一步开发者和业务方把需求高度浓缩成一段清晰的意图描述第二步AI Agent把这段意图拆解成可执行的子任务包括数据模型设计、接口定义、页面布局、测试用例等等第三步Agent根据拆解结果逐项生成代码并自动串联第四步系统通过编译、测试、静态检查等手段验证产物把失败信息反馈给Agent继续修正直到通过为止。这句话对做敏捷开发的朋友来说应该很耳熟。IDD并没有推翻敏捷反而像是在敏捷的骨架上长出了一层肌肉。敏捷开发强调“响应变化优于遵循计划”而IDD把“响应变化”的成本降到了一个前所未有的低位。以前改一个小需求可能要涉及前后端联调、回归测试、部署流程现在AI Agent可以在几分钟内完成一轮“改代码→跑测试→给结果”的循环。换句话说IDD让敏捷真正“敏”起来了。那这篇文章适合谁看我建议这几类人重点读一是被需求反复变更折磨的研发人员IDD能帮你把变更的边际成本打下来二是技术管理者或技术负责人你能从中看到研发流程重构的可能性三是产品经理和业务方你会理解为什么以后提需求的方式也需要升级。当然如果你完全没接触过AI编程也能读我会把关键概念掰开揉碎讲清楚。2. 核心思路拆解为什么“意图”比“代码”更重要2.1 代码只是中间产物意图才是最终需求我在带团队的时候经常和开发同学说一句话“你写的代码不是公司的资产你解决的问题才是。”这句话放在IDD语境下尤其成立。传统开发流程中需求到代码之间要经过一个漫长的翻译过程业务语言翻译成产品语言产品语言翻译成技术方案技术方案翻译成代码。每一步翻译都可能失真这也是为什么很多项目做到最后和最初的设想完全两样。IDD的逻辑是尽量减少翻译层级让业务意图直接成为驱动力。AI Agent需要的输入不再是“用Java写一个接口入参是userId和startDate返回一个list”而是“我需要知道某个用户在某段时间内的订单总数供后台统计页面展示”。前者是解决方案的描述后者是业务意图的描述。Agent拿到意图后会自己决定用什么语言、什么框架、什么表结构来实现。这听起来有点“反工程师直觉”但实际用下来这种方式反而让技术选型更合理因为它不受你预设思路的约束常常能给出更简洁的解法。2.2 IDD的完整工作闭环我梳理了一个比较标准的IDD工作闭环分六个环节第一意图收集与提炼。这一步是由人来完成的。你需要从原始需求中抽取出“用户是谁、要做什么、输入是什么、输出是什么、有什么约束”。越清晰越好但不需要提具体技术。比如“要求响应时间小于200毫秒”属于约束应该写“要求用Redis缓存”属于方案不建议写除非你有特别理由。第二上下文构建。AI Agent不是凭空生成代码的它需要理解你现有的项目结构、技术栈、代码规范、数据库设计。这一步通常通过Agent读取项目文档、扫描代码仓库、分析依赖文件来完成。如果项目有良好的README和技术文档Agent的理解准确率会高很多。第三自动任务分解。Agent会把一个较大的意图拆成若干子任务并形成依赖关系。比如“实现用户订单统计接口”这个意图可能被拆成“设计订单表的查询索引”“编写统计SQL”“实现Controller层”“定义返回VO”“编写单元测试”等子任务。部分工具会把任务列表展示给你确认你可以增删调整然后再让它继续。第四编码与实现。Agent按照任务清单逐个实现。它能读写文件、执行命令、运行测试甚至自己启动项目验证。如果这一步用的是单一文件级AI补全工具比如传统的AI自动补全插件那是做不到的这也是IDD和普通AI编程助手的核心区别。第五自动验证与修复。代码生成后Agent会主动执行编译、跑测试、进行静态分析发现错误就自动修复再来一轮直到通过或达到迭代上限。这个“自主验证-修复”的循环是IDD质量保障的关键。第六人工审查与合并。最后一道关口留给人。代码虽然由AI生成但引入到主分支之前必须有真人Review。我会在后面的章节专门讲审查时重点看什么。2.3 IDD对敏捷开发流程的改造以前我们开Sprint计划会要花大量时间估算用户故事的复杂度因为每个故事背后都有真实的编码工作量。到了IDD阶段编码工作量的占比大幅下降取而代之的是“意图清晰度”的评估这个用户故事能不能被AI理解上下文是否完整验证标准是否明确如果这三个问题都能回答“是”这个故事就可以被标记为“可交给Agent执行”优先级评估的重点也从“要写多少行代码”变成了“业务价值有多高”。这一点对敏捷开发来说是非常大的效率杠杆。敏捷主张拥抱变化但过去的变化成本阻断了我们真正拥抱它的勇气。需求改一个字容易改一个流程要命。IDD把这种“改流程”的成本也压下来了——因为改完意图描述后AI会重新拆任务、重写代码、重跑测试整个周期可能在小时级别甚至分钟级别。我会在第四部分用一个完整案例来演示这个过程。3. 工具链选型与AI环境搭建当前阶段我踩过的组合3.1 从VS Code插件到独立Agent工具IDD能不能落地工具链选型占了六成权重。我目前主力用的是VS Code加Codex插件这一套组合原因很简单零成本上手、和现有开发环境无缝衔接、对项目上下文的感知能力足够强。Codex插件在VS Code里的工作方式是让你在侧边栏用自然语言描述需求它会读取当前打开的工程把相关代码加载进上下文然后生成修改方案、直接改文件、跑命令验证。如果你还没体验过IDD我建议从这条路切入先装好VS Code和Codex插件用自己的一个中小型项目做试验不要一上来就挑战大型遗留系统——后面我会讲为什么。试验的姿势也很重要不要问“帮我写出一个电商系统”这种意图对当前模型来说还是太大了大概率会输出一个玩具级代码。正确的姿势是从“横切一个小功能”开始比如“把订单列表接口增加按状态筛选的能力并补充对应的测试用例”这种意图足够聚焦模型容易理解也方便你检查产物的质量。3.2 企业级落地Spring AI Alibaba如果你所在团队用的是Java技术栈而且需要把IDD能力整合进现有的企业级应用中我建议关注一下Spring AI Alibaba这个项目。它是Spring AI生态的阿里系实现核心价值在于把大模型接入和Agent编排做成了Spring Boot风格的组件。打个比方VS Code加Codex是“个人作坊式”的IDD你一个人和AI聊天、让它改代码Spring AI Alibaba则是“工厂流水线式”的IDD你可以把意图接收、任务规划、模型调用、结果输出包装成标准化的服务嵌入到自己的平台里甚至做成一个内部的“需求转代码”门户让业务人员提交意图、研发人员审核产物。Spring AI Alibaba比较实用的几个能力包括支持多模型接入包括本地部署的模型提供了统一的ChatClient和Agent接口有相对完整的Prompt模板管理和输出解析机制对函数调用Function Calling的支持做得比较顺手Agent可以自己决定调用哪个业务接口来获取数据。这些能力组合起来可以在企业内部搭建一套“意图驱动开发平台”的骨架而不是停留在每个开发者自己的IDE里。3.3 大模型本地部署与选型取舍做IDD绕不开一个灵魂拷问用云端模型还是本地模型我的建议是分场景。如果你处理的是开源项目、Demo、学习项目直接用云端大模型效果最好省心。但如果你是在公司内部处理核心业务代码代码本身就是核心资产那本地部署就是必要选项。当前比较主流的选择是Qwen系列特别是Qwen2.5-Coder系列、DeepSeek-Coder这类代码专项模型显存需求根据参数量从16GB到100GB不等至少要一张24GB显存的消费级显卡如RTX 4090才能跑得像样团队预算充裕直接上多卡A100/H100也没毛病。本地部署的框架我推荐vLLM和Ollama两个方向。Ollama胜在部署简单适合个人和小团队快速验证vLLM是生产级推理引擎吞吐量和并发能力强适合团队共用。部署后要注意设置好上下文长度context length代码类任务对上下文长度的需求极其夸张——一个真实的工程里AI需要同时看到项目结构、关键源码、接口定义、配置文件没有32K以上的上下文根本转不开。这也是为什么本地部署时模型选型上要优先看它的context窗口而不是只盯着跑分看。4. 实操过程与核心环节实现一个IDD功能的完整落地记录4.1 从一句模糊需求到高精度意图空谈误国实干兴邦我还是用一个真实案例来完整走一遍IDD流程。前阵子我帮朋友改造一个社区团购后台有一个特别小但很烦的需求运营每天要在后台一个个核对“异常订单”包括超时未支付、支付后超时未发货、用户申请退款后商家超时未处理这三种情况。传统实现方案是写一个列表页加三个Tab每个Tab一个查询接口。这个需求本身不难但很琐碎特别适合拿来做IDD实验。我首先做的不是让AI写代码而是把需求“提纯”成一段高质量的意图描述。最后形成的意图是在后台管理系统的“订单管理”模块下新增一个“异常订单”子页面提供三个分类标签超时未支付、超时未发货、退款超时未处理。每个分类下展示订单列表包含订单号、用户手机号、下单时间、当前状态、异常原因、操作按钮查看详情、标记处理。列表要支持按时间范围筛选和分页。整个页面要适配现有的后台UI风格权限上仅对运营角色开放。注意我这段描述里包含了几个层次的元素业务背景订单管理模块的异常订单、用户角色运营人员、功能列表三个分类、列表字段、操作、筛选、分页、约束条件适配现有UI、权限控制。我没有写“建一张新表”、没有写“用哪个前端组件库”、没有写“接口路径叫什么”这些是实现细节Agent自己会决定。事实证明意图描述得越场景化、越具体约束产出越靠谱一旦你在里面掺入“我觉得应该用Redis缓存”这类方案级指令反而会干扰Agent的自主判断。4.2 AI Agent的拆解、编码与自动修复把意图丢给Codex之后我观察了它的执行过程这个观察本身很有意思。Agent先是扫描了整个项目目录结构确认了这是Spring Boot加Vue的工程读取了现有的订单实体类、Controller、前端路由和权限配置。接着它把任务拆成了五块数据库查询层新增三个统计/查询方法、Controller新增三个端点、前端新增一个异常订单页面、路由注册、权限注解添加。这个拆解结果和我预想的基本吻合甚至比我想得更细——它还自己决定在查询层用枚举区分异常类型而不是写三个独立方法这个设计比我原本的思路更简洁。编码过程中我基本没有干预但有一个细节值得关注Agent在写“退款超时未处理”这个查询时第一次生成的SQL逻辑有误它把“商家超时未响应”直接等同于“当前时间超过某个阈值”漏掉了“用户已发起退款申请”这个前置条件。有意思的是Agent执行了项目里已有的单元测试测试失败后它自己反查了订单状态机的定义然后修正了查询条件第二次测试通过。这个“自动发现错误、追溯业务规则、修正逻辑”的循环就是IDD和普通代码补全最大的区别——它有验证机制不是一次性输出就完了。整个过程的产出包括后端3个接口方法、2个新增DTO、1个工具类、前端1个Vue页面、若干样式的调整还有配套的单元测试。我从发出意图到全部代码落盘大约用了40分钟其中大部分时间是Agent自己在跑测试、查文档、改代码。而在传统方式下这个需求至少要半天到一天。4.3 验证环节人机协作的边界代码生成完不等于活干完了IDD流程里最后一道关永远是人工审查。我的审查清单有三条第一检查意图覆盖度——它有没有漏掉我明确提出的筛选、分页、权限控制第二检查业务规则正确性——三种异常订单的判定逻辑是否符合状态机的真实含义第三检查代码风格与项目一致性——命名、格式化、异常处理方式是否和团队规范一致审查的结果是意图覆盖度没问题但代码风格上有两个地方需要调整。一是Agent在Controller层直接使用了Entity对象返回给前端而项目的既有约定是使用VO对象防止序列化内部字段二是Agent没有处理并发场景下“订单状态刚变更、查询结果还没刷新”的边界在列表接口上少了一个可选的状态过滤参数。这些细节不是AI能力不足而是它缺少对团队“隐性约定”的感知而这些约定往往只存在于老员工的脑子里和历次Code Review的记录里。所以我的结论是IDD能干80%的活剩下20%的“团队语境适配”必须靠人。我把这两个问题反馈给Agent它很快就修正了把Controller返回值改成了VO并补上了状态过滤参数。整个“人指出问题→AI修改→再验证”的循环两轮就收敛了。最终代码合并到主分支运行一天无异常这个需求就算真正交付了。5. 常见问题与排查技巧实录5.1 意图描述太抽象Agent给出的实现跑偏这是IDD最常见的坑。绝大多数第一次使用的人会写“帮我做一个订单管理功能”然后抱怨AI做得太简陋。这不怪AI怪意图本身缺少边界。比如“订单管理”在不同项目里含义完全不同可能是纯后台CRUD可能是包含订单状态流转的工作流可能是带数据分析的看板。Agent面对这种高度模糊的意图只能按它训练数据里的“常见订单管理”来猜猜错的概率自然高。解决办法只有一个把抽象名词翻译成具体动词和具体对象。不要写“管理订单”要写“运营人员需要能够查看订单列表、筛选订单状态、修改订单备注、取消未付款订单”。如果你自己都说不清楚一个功能具体要做什么先做需求澄清而不是急着让AI开写。这个原则和传统开发的需求评审一模一样只是过去评审对象是人现在评审对象变成了模型。5.2 Agent上下文不足导致改错文件AI Agent的上下文窗口是有限的即使支持128K上下文的模型也不可能把一个大型工程的每个文件都读进来。实际使用中Agent通常只加载项目结构、关键配置、和你本次编辑相关的文件。如果你的工程模块很多、依赖关系复杂Agent可能会“只见树木不见森林”改了一个文件却忽略了它在另一个模块的调用方。应对办法有两个层面的。第一在意图描述里主动“圈定范围”比如明确说“本功能只涉及order-service这个模块相关的接口定义在order-api模块的OrderController中”给Agent划定工作边界。第二把大型工程拆分成更内聚的子项目让每个子项目成为一个独立的IDD工作单元这其实和微服务的设计哲学一脉相承。实测下来在5万个文件级别的巨型单体仓库里不要让Agent自由探索一定要给它导航信息。5.3 Agent频繁踩到同一类业务规则我在实验中也遇到过一个典型情况Agent在生成代码时总是忘记“软删除”过滤条件导致查询结果误包含已删除的数据。第一次出现我手动改了第二次出现另一个接口又犯了同样错误。这说明Agent并没有从我的反馈中进行“长时记忆”学习它每次生成都像是“失忆症患者”从头开始。针对这类反复出现的规则问题我建议在项目根目录维护一个“AI开发规范”文档把项目里的核心业务约束写清楚比如“所有查询必须排除deleted1的记录”“创建时间的字段名统一用created_at”“金额字段一律用Long类型存储分单位”。然后在每次给Agent下达意图时明确要求它“先阅读项目根目录下的AI开发规范文档再开始编码”。这个习惯养成后Agent犯常识性错误的频率会大幅下降。5.4 AI生成的测试可信度存疑Agent生成的单元测试往往是为“覆盖而覆盖”经常存在两种问题一是断言写得太宽松只验证不报错不验证业务逻辑二是测试只覆盖了它自己写的代码对存量代码没有回归效果。我遇到过最典型的案例是Agent为一个工具类写了10个测试用例全部通过但仔细一看只有一个用例真正校验了输出值其他都是“断言不为null”这种空壳断言。这种测试不仅没有质量保障作用还会给人虚假的安全感。我的经验是不要直接用Agent生成的测试作为验收标准。要么人工补充关键断言要么用覆盖率工具检查核心分支是否被执行要么用变异测试工具比如Java生态的PIT去测这批测试的有效性——变异测试会故意往代码里种Bug如果你的测试发现不了这些变异Bug说明测试本身是无效的。这一步不能省。5.5 安全审查与隐私红线最后必须郑重提醒把业务代码交给AI Agent处理本质上是把你的知识产权和核心数据喂给了大模型。如果你用的是云端公共模型代码会经过第三方服务器如果你处理的是金融、医疗等强合规领域的数据这个风险是不可接受的。所以IDD落地到企业中我强烈建议优先考虑本地部署模型并在代码仓库层面做好权限分级核心算法模块不要开放给AI Agent修改只有非核心业务模块才允许AI干预。另外AI生成的代码可能存在安全漏洞尤其是SQL注入、越权访问、敏感信息硬编码这几类。Agent生成代码后建议自动跑一遍SAST静态安全扫描工具再进入人工代码审查环节。从我的实践看Agent生成的代码在功能性上表现不错但在安全性上需要比人工代码更高的警惕——因为它有时候会“一本正经”地给出一个有漏洞的实现而且解释得头头是道。5.6 IDD的落地节奏建议如果你决定在团队里推行IDD我建议用“温水煮青蛙”的节奏不要搞运动式的一刀切切换。第一步选一个非核心、低风险的中小型模块做试点团队里挑两名接受度高的开发先行尝试跑通以后再总结内部最佳实践。第二步把AI编程工具的权限、私有化部署方案、代码审查规范、安全合规评审流程都固化下来形成制度而不是依赖个人自觉。第三步再逐步扩大适用范围把研发效能数据需求交付周期、缺陷率记录下来做前后对比。我见过一些团队一上来就要求全员使用IDD结果老员工抵触、项目质量滑坡、最后草草收场。工具是好工具但推进节奏比工具本身重要得多。从我个人的体会来说IDD最打动我的不是“代码生成速度变快了”而是它让研发人员把注意力重新放回了“理解问题”和“定义问题”上。以前写代码占据了大部分工作时间以至于我们很少认真思考“这个需求到底要解决谁的什么问题”现在编码的活交出去了反而逼着人去把意图想得更透彻。如果你准备尝试IDD我希望你从今天开始把提需求的方式从“帮我写一个xx功能”改成“我希望实现xx效果面向xx用户满足xx场景遵循xx约束”。这个习惯一旦养成你的开发效率会有一个质的提升而且你会发现AI远比你想象中更能干前提是——你清楚地知道自己要什么。