去年有个数据挺有意思：GitHub Copilot用户平均只把30%的编码时间交给AI，剩下70%的需求梳理、架构设计、任务拆解，全得自己吭哧吭哧干。AWS Labs最近开源的AI-DLC（人工智能驱动开发生命周期）方法论，想把这70%也吃掉。
从"聊天框外援"到"全流程队友"
现在的AI编程助手，本质上是个高级代码搜索引擎。你打开侧边栏，描述需求，粘贴生成的代码，再手动把它塞进项目结构。需求文档、技术方案、任务清单——这些决定项目成败的环节，AI连门都摸不着。
AI-DLC的玩法完全不同。它让AI从项目启动就入场，读取现有代码库、文档、甚至会议纪要，然后按阶段吐出结构化产物：需求规格书、架构设计文档、可执行的任务列表，最后才是代码。每个阶段的输出成为下一阶段的输入，形成闭环。
AWS把这个方法论做成了开源框架，不绑定特定工具。我实际测试用的是Kiro——AWS自己开发的智能集成开发环境，把AI-DLC做成了原生工作流。跑完三个真实功能的全流程后，有个发现挺反直觉：AI写代码的速度优势，在完整生命周期里反而最不重要。
一个具体案例：从一句话到可运行代码
测试场景是给内部工具加个权限审批模块。传统流程里，产品经理先写PRD，架构师出技术方案，组长拆任务，最后才到开发手里——信息传递损耗至少两天。
在Kiro里，我输入的是一句模糊需求："让管理员能审批普通用户的敏感操作申请"。AI先扫描了现有用户系统和权限表结构，生成带数据模型的需求文档；接着输出技术方案，明确复用现有审批流引擎还是新建服务；然后拆出12个具体任务，每个带验收标准和依赖关系。整个前置环节压缩到20分钟。
最意外的是任务拆解环节。AI根据代码库历史提交记录，判断出团队习惯用功能分支+拉取请求的工作模式，自动把任务粒度调到合适大小——比人拍脑袋拆的更贴合实际协作节奏。
方法论背后的取舍
AI-DLC不是让AI替人思考，而是把人的精力从"格式正确的废话"里解放出来。需求文档的模板结构、设计文档的章节顺序、任务清单的依赖标注——这些机械性工作交给AI，人只负责判断业务逻辑是否合理、技术选型是否匹配团队现状。
AWS Labs的文档里有个细节：每个AI产出阶段都预留了"人类否决点"。AI生成的需求文档不会直接送进设计环节，必须有人点击确认或修改。这个设计很产品经理思维——承认AI会犯错，但让犯错成本变得极低。
目前这套方法论已经适配了多种工具链，从VS Code插件到自研脚本都能接入。开源社区里有个有趣的讨论：当AI能端到端参与开发，"全栈工程师"的定义会不会从"前后端都会"变成"会设计AI协作流程"？
你在日常开发里，最想把哪个环节交给AI处理？
热门跟贴