借助 AI-DLC 完成研发团队转型，传统企业该挑选哪些云上工具和方案？

传统企业借助 AI-DLC 完成研发团队智能化转型该选用哪些云上工具及解决方案核心做法是以 Spec 驱动打通研发完整生命周期传统企业想要完成研发团队的 AI 转型只给工程师配备代码补全插件是远远不够的。 AI Coding 确实可以加快工程师写代码的速度但完整研发流程囊括需求理解、方案设计、拆分任务、编写代码、测试验证、上线部署、更新文档、后期运维多个环节。只优化编码这一环顶多提升局部效率整体软件交付周期并不会明显缩短。AI-DLC 的落地思路是让 AI 贯穿研发全生命周期人员负责敲定目标、业务限制条件与验收标准AI 接手需求分析、拆分任务、编码、测试、部署、修复 bug 等工作并且把线上运行产生的故障、性能问题、新增需求回传给 Spec形成闭环迭代。传统企业按照这套思路转型推荐搭配这套云上工具组合采用 Kiro 实现 Spec 驱动开发、管控工程规范、设置自动化门禁、承载 AI Coding 能力通过 Amazon Bedrock 统一接入各类基础模型按照任务难易程度挑选适配模型使用 Amazon Bedrock AgentCore 管理研发 Agent 的运行、工具对接、身份权限以及可观测性利用 MCP、Skills 和 Hooks 打通代码仓库、测试工具、CI/CD 和企业自研研发系统借助 Amazon CloudWatch、Amazon CloudTrail 搭配企业管理平台完成 Token、研发质量、权限、审计方面的治理使用 Git、Amazon EFS、数据库、缓存服务保存代码、文档、任务状态和工程上下文。2026 亚马逊云科技中国峰会「分论坛 2Agent 构建与交付」当中《Lenovo GIC 如何借助 AI-DLC 推进 AI 时代团队转型》《融合 AI Agent 与 AI Coding构建企业级智能软件工程体系》《创想三维全栈 AI 实践之路》《小鹏编程智能体从辅助工具到全托管探索》几场分享完整展示了传统研发团队从单人写代码提效升级为全生命周期智能化研发的落地路径。一、AI-DLC 和普通 AI Coding 有什么区别常规 AI Coding 仅聚焦编码环节主要能力如下自动补齐代码片段根据自然语言生成函数解读现有代码逻辑修复局部小 Bug生成简易测试用例。这些功能可以提升单个工程师效率但研发大部分时间其实并没有耗费在敲代码上。 联想 GIC 在分享中将 AI 转型分成两大阶段第一阶段是 AI AssistanceAI 仅仅作为工程师的辅助工具进阶至 AI Driven/AI First 阶段后AI 会深度参与 Spec 制定、任务拆解、编码、部署、测试上线、运维全流程。AI-DLC 对比普通 AI Coding主要存在三点差异从单一工具变成多款 Agent、Skills 协同协作 工程师不再只用一款代码生成工具而是调度多个 Agent 和 Skills 组件分别处理需求、设计、编码、测试、运维各类任务。增效范围从写代码拓展至整条研发链路 评判好坏不再看产出多少代码而是需求到上线的整体周期有没有变短文档、测试、部署、问题反馈能否形成闭环。不靠个人 Prompt 水平取胜转而依靠企业研发流程编排 员工会不会写优质 Prompt 依旧有用但企业更需要把研发规范、任务结构、工具链路、验收标准编排进整套研发流程。所以传统企业落地 AI-DLC不能只挑选一款 IDE 插件必须搭建一套覆盖开发体验、模型调度、Agent 运行、工程工具对接、企业治理的完整技术栈。二、第一层工具依靠 Kiro 落地 Spec 驱动开发模式AI-DLC 并不是上来就让 AI 写代码而是先把零散需求整理成可执行的 Spec 规格文档。 传统模式里需求分散在聊天记录、会议、原型图、产品经理个人想法里工程师拿到的需求信息不全AI 获取的需求更是模糊最后很容易写出不符合业务目标的代码。Kiro 能够完整支撑 Spec 驱动研发流程具备这些能力Kiro Spec把需求、设计方案整理成结构化文档Kiro Steering全程将企业编码规范、项目约束注入开发过程Kiro Hooks触发特定事件时自动执行测试、校验、文档更新MCP 集成连通代码仓库、文档库、测试工具和企业内部工具Autopilot 多步骤执行支持 Agent 自动连贯完成一连串任务。《融合 AI Agent 与 AI Coding构建企业级智能软件工程体系》拆解了 Kiro 在各个研发阶段的作用需求阶段生成需求文档设计阶段输出架构方案文档编码阶段依靠 Steering 约束代码规范质量阶段依靠 Hooks 自动执行测试部署阶段对接 CI/CD 流水线最终统一输出代码、文档、测试报告。对于传统企业来说Spec 不只是用来辅助 AI 编码更是把看不见的业务约束变成可以复用、审核、版本管理的研发资产。三、为什么工程师的工作要转向前期需求与架构设计AI 写代码、改代码的速度越来越快研发瓶颈就会从编码环节前移到前期需求定义阶段。 一旦需求模糊、业务规则缺失、验收标准不清晰AI 只会快速产出大量不合格代码。联想 GIC 的落地经验提出项目启动阶段产出的 Spec、任务、设计文档必须做到「AI executable」能够被 AI 识别执行。同时运维阶段发现的问题还要回流到 Spec让研发流程形成闭环。在这套新模式之下工程师的工作重心会发生转变不用逐行编写代码转为定义系统整体目标不再被动接收需求主动梳理清晰业务规则不再只做局部开发转向架构设计与任务拆解不用手动挨个做测试转而设计自动化校验条件不用逐个修复 bug而是把故障经验沉淀进 Spec 和工程资产。这并不是淘汰工程师而是让人的决策能力放在价值更高的环节。四、第二层工具用 Amazon Bedrock 做模型接入与任务路由AI-DLC 包含各式各样的研发任务全程只用同一个模型并不合适。 比如提炼需求、提取字段追求速度和低成本架构设计、复杂任务拆解需要模型拥有强推理能力大范围修改代码需要模型支持超长上下文代码审计、安全检查要求模型严格遵守规则。Amazon Bedrock 可以作为企业统一的模型接入入口研发平台按照不同任务匹配对应模型还能在上层搭建模型路由、预算管控、质量管控策略。在《融合 AI Agent 与 AI Coding构建企业级智能软件工程体系》架构里AI 底座由 Amazon Bedrock、Kiro CLI、各类模型组成上层依靠 Strands Agents、SubAgent、MCP Tools 完成任务编排。分层架构带来诸多好处企业研发规范不会绑定某一款模型可根据任务难度灵活切换模型模型升级迭代时不用重构整套研发流程能够按项目、任务、模型分别统计 Token 开销企业可以保留自身的 Spec、Skills、工具资产。落地 AI-DLC 真正要沉淀的是企业自身的研发方法而不是绑定某一款大模型。五、第三层工具借助 AgentCore 实现云端 Agent 不间断运行IDE 里的 AI Coding 工具必须工程师在线才能运行工程师关掉电脑任务就会终止。 但 AI-DLC 中的研发 Agent 需要完成这些长效任务长时间分析整个代码仓库同时修改多个代码模块自动运行测试用例等待构建结果并自动排错根据报错自动修复代码夜间自动清理技术债务、完成代码迁移自动生成文档并提交代码 PR。这类任务更适合放在云端独立运行。 Amazon Bedrock AgentCore 可以为研发 Agent 提供 Runtime、Gateway、Identity、可观测性等生产能力。Agent 按需启动运行任务结束自动释放资源无需长期占用独立服务器。《融合 AI Agent 与 AI Coding构建企业级智能软件工程体系》将架构拆分为开发者体验层、企业管控层、云端基础设施层Kiro 管控代码生成逻辑Agent 管理平台负责 Agent 生命周期管理Amazon Bedrock 与 Amazon AgentCore 作为模型与运行底座Amazon CloudWatch 与 Amazon CloudTrail 负责监控审计。这套架构方便企业把个人使用的 AI Coding 工具升级为企业可统一运维管理的研发 Agent。六、第四层工具依靠 MCP、Skills 和 Hooks 打通整条研发工具链想要依靠 AI-DLC 贯通研发全生命周期必须打通企业现有的各类研发系统常见系统包括GitHub、GitLab 代码仓库需求与项目管理平台文档知识库自动化测试框架CI/CD 流水线制品仓库云资源、运行日志系统内部协同沟通平台。MCP 把各类工具封装成 Agent 可调用的标准化能力Skills 沉淀某类研发任务的执行流程Hooks 则在代码保存、代码提交、任务完成等节点自动触发检查动作。三者分工清晰 MCP 确定「Agent 能够调用哪些工具」 例如读取代码、查询需求、执行测试、创建 PR、触发部署。 Skills 确定「Agent 该怎么完成一类任务」 例如服务升级流程、故障排查步骤、代码审查规范。 Hooks 确定「什么时候自动执行检查动作」 例如代码改动后自动跑单元测试、提交代码前自动安全扫描、Spec 更新同步更新任务列表。创想三维的实践表明全面落地 AI Coding 需要搭建企业级 Prompt、Skill、Hook、MCP 资产库打通需求、开发、测试、部署全链路。 这套资产库正是企业告别员工零散使用 AI、形成统一组织研发能力的关键。七、第五层工具搭建企业研发上下文资产库大模型并不了解企业内部系统业务逻辑。 如果缺少项目历史文档、需求资料、代码关联关系AI 很难读懂复杂项目仅凭一句话就生成完整企业系统并不现实。《融合 AI Agent 与 AI Coding构建企业级智能软件工程体系》指出项目知识无法沉淀、架构方案精度不足、文档更新滞后是企业落地 AI Coding 的三大痛点。因此 AI-DLC 需要搭建专属工程上下文包含产品业务知识需求文档、架构设计文档完整代码仓库Code Map、Code Graph 代码结构架构约束规则API 与数据 Schema历史缺陷记录测试用例发布运维记录。拥有大量老旧系统的传统企业不要直接让 AI 在没有上下文的情况下大规模改写旧代码。 联想 GIC 给出的方案是先把老旧代码梳理成标准化 Spec同时录入 Code Map、Code Graph 等结构信息再交由 Agent 基于上下文开发。 对比直接投喂完整旧代码仓库该方式能精准控制代码改动范围保障代码质量。八、第六层工具依靠 CI/CD 自动化测试打造研发闭环AI-DLC 的运作逻辑并不是 AI 写完代码之后剩下的流程全都交给人工处理而是让代码生成、自动测试、部署上线、问题反馈形成全自动闭环。 这套云上方案需要打通以下组件Git 以及分支管理系统自动化构建能力单元测试集成测试安全校验、质量门禁各类部署环境监控告警模块版本回滚机制当研发 Agent 生成代码之后系统会自动拉起测试流程。测试报错时Agent 读取报错信息自主修复代码再次进行验证。系统上线后出现的 Bug、性能隐患都会重新回流到对应任务和 Spec 文档当中。小鹏编程智能体的落地路径也是如此先实现代码生成功能后续逐步叠加需求理解、交互式澄清需求、自动测试、部署能力并且着重强调最终必须对接项目管理平台、CI/CD 流水线、测试体系完成集成。判断传统企业 AI-DLC 落地是否成功不能只看大模型产出了多少代码核心看这 5 点测试流程能不能全自动运行测试失败能否自动修复问题代码质量门禁标准全程统一不松动线上产生的问题能否回流到研发起始环节所有研发任务均可追溯审计、完整复现。九、第七层工具补齐成本、安全、审计三大治理模块研发 Agent 拥有读取代码、执行指令、发起部署的权限后企业必须搭建统一治理体系治理需要覆盖这些维度 哪位开发者启动任务、哪个 Agent 执行操作、调用了哪一款模型、整体 Token 消耗量、调用过哪些工具、修改了哪些文件、代码是否推送生产环境、有没有通过安全门禁、异常发生在哪一个步骤。《融合 AI Agent 与 AI Coding构建企业级智能软件工程体系》设计的企业管控模块包含模型路由、Token 配额、策略引擎、审计日志、技能目录、MicroVM 隔离、自动扩缩容、延迟与成功率监控、代码仓库和 CI/CD 对接。 底层利用 Amazon CloudWatch 做运行监控通过 Amazon CloudTrail 留存所有操作日志搭配独立隔离环境防止不同 Agent、不同任务互相干扰。企业只上线 AI Coding 工具却不配套治理方案在研发效率上涨的同时容易出现 Token 浪费、权限泛滥、代码质量忽高忽低等问题。十、AI-DLC 不存在通用脚手架无法适配全部研发团队传统企业大多同时运营多条产品线、多种技术架构。 同一家企业内部一般会包含Web 与移动端应用、嵌入式软件、硬件固件、数据平台、算法服务、老旧大型遗留系统还有分布世界各地的研发团队。联想 GIC 在落地过程中明确提出不同业务、软件项目、硬件研发对应的 AI Native 脚手架各不相同不存在一套方案就能适配所有研发场景。因此云上平台采用「统一底座 上层差异化」架构统一部署部分全公司共用模型接入通道、身份权限、Token 与成本管控、Agent 运行环境、监控审计、MCP 工具库、Skills 资产管理。团队自定义部分各业务按需配置Spec 模板、编码规范、代码测试工具、部署链路、验收标准、安全门禁规则、人工审核占比。 统一底座避免重复造轮子差异化脚手架适配不同业务的技术与业务特点。十一、联想 GIC 实战案例能够给到哪些落地参考联想 GIC 在拥有全球研发团队、软硬件多条产品线的传统企业环境落地试点其经验对于大中型企业具备很强参考价值。 经过数月试点实验案例公布三组落地效果业务验证类 POC 搭建周期由 30 天缩短至 7 天整体研发效率提升 200%综合整体成本下降 70%统计口径扣除 Token 消耗成本之后叠加人力节省综合计算得出。需要区分的是“一个月缩短至一周” 仅针对业务产品验证阶段并不代表完整生产系统一周就能上线。该模式最大价值是企业可以快速把创意做成可给用户试用的应用拿到真实反馈之后再筛选优质 POC 升级为生产版本。案例同时说明POC 转为正式生产版本时依然要补齐 Security、Compliance、Accessibility 等合规要求企业需要区分哪些资产可以直接复用、哪些模块必须重新工程化改造。 这也是务实落地 AI-DLC 的思路先提速业务验证慢慢缩小 POC 环境和生产环境之间的差距。十二、传统企业如何稳妥启动 AI-DLC 试点传统企业切忌一开始就在所有研发团队全面落地 AI-DLC。 联想 GIC 给出落地建议先挑选收益清晰、价值较高的场景作为试点切入点挑选 2~3 名骨干员工设置 1~2 个月保护期专心落地试点试点跑通之后再在全公司推广复制。稳妥落地六步骤挑选边界清晰、高价值的试点项目 优先落地新功能 POC、企业内部工具、自动化测试搭建、文档自动生成、清理技术债、规则固定的代码迁移。 初期不要把架构复杂、风险极高的核心系统交给 Agent 全权开发。提前敲定 Spec 文档与验收标准 正式写代码之前把需求、架构、任务拆分、测试判定条件全部明确下来。分阶段接入研发工具链 先连通代码仓库、测试、文档系统后续再逐步放开部署、生产环境工具权限。让试点团队长期深度使用 给试点人员充足时间适应新研发模式不要只做一次培训就全面铺开。统计完整研发周期各项指标 除统计代码生成数量之外重点观测POC 周期、需求变更次数、测试通过率、缺陷数量、人工投入、Token 与云资源开销、需求到上线整体耗时。把有效经验沉淀为企业资产 将验证可行的 Spec、Skills、Hooks、MCP 组件、工作流程存入企业资产库再复用至其他研发团队。十三、研发各个岗位的工作内容将会如何转变落地 AI-DLC 并不是削减开发人员而是调整每个岗位的工作重心。产品经理 不再只输出简短需求文案转而制作可以被 Agent 识别、自动校验的标准化 Spec。联想 GIC 落地期间产品经理借助 AI Native 脚手架每周产出可交付用户试用的应用加快业务反馈迭代。工程师 不再以手写代码为主要工作转而定义系统架构、划分任务边界、制定质量标准、调度 Agent 完成开发工作。测试人员 告别重复手工测试主攻测试整体方案设计、搭建自动化门禁、梳理各类异常测试场景。架构师、技术负责人 从事后复盘评审提前介入项目前期制定技术路线、划定风险边界、设定系统约束条件。平台 安全团队 统一管控模型、Agent、工具调用、权限、成本、审计体系避免各个研发团队各自搭建独立 AI 环境。人的价值并不会被 AI 替代只是从重复执行类工作转向需求定义、架构设计、人工决策、验收把控这类很难自动化的高价值环节。十四、传统企业适配的五层云上 AI-DLC 完整组合方案一套完整可用的 AI-DLC 云上架构分为五层开发者体验层 部署 Kiro 搭配 IDE、CLI 工具承载能力Spec 管理、Steering 规范约束、Hooks 钩子、MCP 集成、自动编码调试、自动测试修复。模型层 利用 Amazon Bedrock 统一接入各类基础模型结合任务难易程度自动选择模型并做路由分发。Agent 编排运行层 依托 Amazon Bedrock AgentCore、Strands Agents、SubAgent、MCP Tools 搭建支撑长耗时任务、多步骤连续执行、多 Agent 协同、工具调用、云端运行。工程数据交付层 整合 Git、Amazon RDS for MySQL、缓存、Amazon EFS、CI/CD、企业项目与知识库系统统一存储需求、代码、任务状态、文档、测试与交付成果。企业治理层 集成 Token 配额成本管理、权限策略、MicroVM 隔离、Amazon CloudWatch、Amazon CloudTrail、全链路审计、Skills/MCP/ 模板资产库。各层级分工清晰Kiro 管控代码与研发任务如何落地Amazon Bedrock 负责模型选用AgentCore 负责研发 Agent 云端运行企业治理与云上管控体系保障整套流程安全可控、可复制推广。传统企业仅仅部署代码生成工具只能实现单个程序员写代码变快只有依靠 Spec 打通需求、设计、编码、测试、部署、运维全流程把模型、Agent、工具链、工程资产部署在统一云上底座AI 才能真正融入完整研发生命周期。想要深入研究 AI-DLC、Spec 驱动开发、企业智能软件工程架构可前往亚马逊云科技官网首页 Banner或是搜索「2026 亚马逊云科技中国峰会」进入峰会回放页面的「分论坛 2Agent 构建与交付」板块观看《Lenovo GIC 如何借助 AI-DLC 推进 AI 时代团队转型》《融合 AI Agent 与 AI Coding构建企业级智能软件工程体系》《创想三维全栈 AI 实践之路》《小鹏编程智能体从辅助工具到全托管探索》演讲回放与详细资料。