北京
“创建一款网页应用，让用户可以查看可预约时段并完成就诊预约。”
当产品经理玛丽亚提出这个意图后，人工智能并没有立刻生成代码。它首先提出的是一连串问题：“用户是否需要注册账号？预约确认后是否要发送邮件通知？管理员是否需要后台查看预约数据？”
这是亚马逊云科技（AWS）所描绘的AI-DLC（人工智能驱动开发生命周期）的典型场景。在传统的AI辅助编程中，人向AI提问，AI给出答案，人再去组织流程、判断下一步该做什么。AI-DLC把剧本翻了过来——AI分析目标、提出问题、制定计划、给出备选方案，然后等着人点头，才动手执行。
一套方法论背后的逻辑转变
该方法论由AWS首席解决方案架构师Raja SP及其团队创建。Raja SP在AWS内部主导开发者转型项目，他认为当前多数团队使用AI的方式，本质上仍是将AI当成加速器：分析需求时用AI快速梳理要点，写代码时让它补全片段，测试时请它生成用例，报错时让它解释原因。这些动作确实变快了，但串联流程、判断时机、决定下一步的工作，依然是人在做。
AI-DLC的核心主张是，把“判断下一步该做什么”这件事也交给AI。在人类审核通过的范围内，AI持续推动开发进程：分析目标、提出问题、准备计划、给出替代方案、获得人类许可后执行任务，然后再次分析结果、再次提问、再次等待许可。这个循环贯穿整个软件开发生命周期。
谁来负责什么
在新的分工里，AI的角色是提案者和执行者，人的角色是上下文提供者、审查者和决策者。AI负责设计路径并完成被批准的作业，人负责注入业务理解、审视产出、做出关键判断。
以预约挂号应用这个假设项目为例，AWS的实践演示引入了三个角色：产品负责人迭戈负责定义业务边界，开发工程师迭戈代表技术实现端，何塞对接与医院系统和排班数据的后续集成。此外，解决方案架构师有时也会介入——不是必须参与每一项活动，但在涉及技术架构决策的关键节点，AWS建议团队实时澄清这些决策，而不是事后补文档。
从意图出发，而不是从需求文档出发
AI-DLC的起点叫做“意图”——一段关于要达成什么目标的高层级陈述，而不是一份详尽的需求规格说明书。玛丽亚的意图只有一句话。AI接到意图后不发散不乱做，而是先向团队抛出问题。
随着玛丽亚解释期待的用户行为、迭戈指出实现层面的约束、何塞提出未来的系统对接需求，AI才逐步生成一系列制品，包括功能需求列表、用户故事映射、技术约束记录等。这些制品不会自动生效，团队必须逐项审查、反复要求修改，直到达成一致。
把项目拆成可独立构建的单元
当团队对方向达成共识后，AI不会一股脑开工。它将项目拆分为多个“工作单元”，每个单元是解决方案中一部分内聚的、可相对独立构建的模块。在这个预约挂号项目里，AI建议的单元划分包括了用户注册与登录模块、医生排班查询模块、预约创建与管理模块、管理员后台模块等。
这种拆分方式让团队可以逐步交付、逐步验证，也让AI在每一个单元启动前都能重新审视当前状态、重新提出问题。AI-DLC的建立者认为，这种循环式的提问许可机制，是比一次性生成庞大代码库更符合工程现实的做法。
目前，AWS尚未公布AI-DLC的具体工具链和落地时间表，但这一方法论的提出已揭示了其对AI与开发者关系的长期判断：AI不会停留在“辅助”角色，而是朝“调度者”的方向演进——而人，需要习惯在每一个AI提案面前说“同意”或“回去改”。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
