从 SDLC 到 AIDLC：CI&T 对 AI 驱动软件开发模式的探索及Kiro最佳实践

摘要：本篇文章带你了解 AIDLC 的演进脉络，以及我们如何利用前沿的 Agent 框架重塑整个研发流程的实践和经验。

01 一、引言

02 二、什么是 AIDLC？

03 三、从辅助到编排：CI&T 对 AIDLC 的认知演进

04 四、CI&T基于Kiro的AIDLC实践

05 五、挑战与未来展望

06 六、结语

一、引言

随着生成式 AI 和 AI Agent 技术的爆发，软件工程正在经历一场深刻的范式转移。如果说传统的 SDLC（软件开发生命周期）代表的是“人类编写软件”的时代，那么如今我们正在全面迈入“人类与 AI 共同构建软件”的新纪元

作为这一领域的先行者，CI&T 正在积极探索并落地 AIDLC（AI-Driven Development Lifecycle，AI 驱动的开发生命周期）。本篇文章将带你了解 AIDLC 的演进脉络，以及我们如何利用前沿的 Agent 框架重塑整个研发流程的实践和经验。

二、什么是 AIDLC？

AIDLC 是一种 AI 原生的软件开发方法论。它不再仅仅将 AI 视作代码补全的辅助工具，而是将 AI 深度嵌入到需求分析、架构设计、代码生成、测试、部署和运维的全流程中，使其成为开发过程中的核心“协作者”。

与传统 SDLC 相比，AIDLC 带来了几个根本性的改变：

1. 角色的根本转变：开发人员从传统的“主要编码者”，转变为“意图定义者与结果验证者”。
2. AI 的深度参与：AI 不再是被动响应，而是能够自动生成代码、测试用例和架构文档，甚至主动向人类提问以澄清需求。
3. 极致的迭代速度：需求、设计和实现之间的反馈循环被显著缩短，交付周期大幅压缩。

对于技术团队而言，拥抱 AIDLC 意味着研发模式从“人力驱动”向“AI 驱动”的全面升级，在更小规模的团队配置下，实现更强大的创新与交付能力。

三、从辅助到编排：CI&T 对 AIDLC 的认知演进

在 CI&T看来，AI 对软件开发的重塑并非一蹴而就，而是一个效能不断翻倍的演进过程。我们将这一过程划分为四个阶段：

传统软件开发 (Traditional Software Development)：通常依赖阶段性的人为交接和顺序执行流程，在复杂项目中可能导致迭代周期较长。

[图1]

AI 增强的软件开发 (AI-Augmented – 2X 效能)：在这个阶段，人类利用 AI 助手（如 Copilot）提升个人的局部编码效率。尽管单点效率提升了，但时间往往又消耗在其他流程的等待中。

[图2]

AI 协调的软件开发 (AI-Coordinated – 5X 效能)：此时，AI 开始驱动端到端的创建工作，人类则退居幕后，负责引导方向和验证成果，大大消除了环节间的等待浪费。

[图3]

AI 编排的软件开发 (AI-Orchestrated – 20X 效能)：这是未来的终极形态。AI 能够自主驱动系统的演进和开发，人类仅需设定高阶目标，并确保系统符合商业伦理与合规要求。

[图4]

未来团队阵型的变化： AI驱动的软件开发模式可能会对团队结构产生影响。传统的产品经理、架构师、开发、测试角色仍然存在，但同时也会出现新的角色，或推动现有角色的转型，例如负责 AI 协同编排和治理的工程角色：

AI 协同编排领导者 (AI Coordination Leader)：他们无需深入编写每一行代码，而是负责设定目标、映射整个 SDLC 规则、协调人机并行协作流，并在 AI 产出偏离预期时进行仲裁和纠偏。
AI 工程师 (AI Engineer)：负责定制和调整 AI 平台及 Agent 的工作流，建立质量验证检查点（Guardrails），并整合内部知识库，确保 AI 的输出安全、合规且高度可用。

四、CI&T基于Kiro的AIDLC实践

理念需要强大的工具链支撑。在日常项目中，CI&T引入了如 Kiro 这样的 Autonomous Agent 框架来实现 AIDLC。

为了解决大模型容易“产生幻觉”和缺乏企业内部上下文的问题，我们在实践中深度应用了规范驱动（Spec-Driven）的模式。例如，我们会使用 Kiro的Feature Specs（功能规范）和 Bugfix Specs（修复规范）来锁定 AI 的工作边界；同时，通过 Powers/Skills 将跨团队的集成指南和基础组件打包为子模块，让 AI 在生成代码时能直接读取企业级最佳实践，而Hooks则用于在特定生命周期阶段触发自动化校验。

接下来我会基于一个真实项目里的需求，完整记录如何在 Kiro 中实践 ALDLC（AI-Driven Lifecycle）。整个过程将覆盖从需求理解（Jira Task）→ Spec 生成 → 任务拆解 → 自动编码 → 代码规范约束 → PR 提交的端到端流程。

相比传统软件开发依赖大量文档评审、会议沟通和人工编码的方式，ALDLC 的核心变化在于：

用对话替代文档会议
用 Spec 驱动开发替代人工拆解任务
用 AI 自动编码 + 人工 Review 替代纯手工开发
将代码规范前置到生成阶段，而不是事后 Code Review

最终实现的是一种以 AI 为核心执行者、开发者转为“设计者 + 审核者”的全新开发模式。

案例：用 Kiro 从零搭建一个 OAuth 认证代理服务

下面以我们实际交付的一个项目为例，这是一个 OAuth 2.0 认证代理服务，需要同时对接两个不同的企业 SSO 系统，并为上游应用提供统一的认证接口。整个项目从立项到核心功能交付，全程使用 Kiro 作为主要开发工具。

第一步：用 Steering 文件建立”团队规范”

在动第一行代码之前，第一件事是在 `.kiro/steering/` 目录下建立四个规范文件，把团队的约定”喂”给 Kiro：

– `tech.md`：技术栈约定

– `structure.md`：项目目录结构和分层架构规范

– `product.md`：产品定位和功能边界

– `codeRule.md`：代码规范

这些文件会在每次对话中自动注入上下文。这意味着 Kiro 生成的每一行代码，都天然符合团队规范，不需要反复提醒。

[图5]

第二步：从 Jira Task 到 Spec，用对话代替文档会议

拿到 Jira 工单后，直接在 Kiro 的聊天窗口里把需求描述给它，Kiro 会自动生成一套完整的 Spec，包含三个文件：

– `requirements.md`：用 User Story + 验收标准（Acceptance Criteria）格式描述”做什么”

– `design.md`：系统架构、组件接口、数据模型、错误处理策略

– `tasks.md`：可执行的子任务清单，每条任务关联对应的需求编号

以 OAuth 核心功能为例，Kiro 生成的 `requirements.md` 把”统一认证接口”这个模糊需求，拆解成了带有明确 WHEN/THEN 格式的验收标准；`design.md` 则直接输出了包含 Mermaid 架构图、TypeScript 接口定义和错误类型枚举的完整设计方案。

整个项目我一共建了 9 个 Spec，覆盖了从项目初始化、OAuth 流程、JWT 签发、Key Vault 集成、Microsoft Graph 用户同步，到 Azure Function 部署的完整功能链路。

[图6]

第三步：执行 Tasks，Kiro 自主完成编码

Spec 确认后，切换到 Tasks 视图，点击执行。Kiro 会按照 `tasks.md` 中的子任务顺序，逐步完成代码编写。

在整个执行过程中，开发的角色是”验证者”而不是”编码者”——Kiro 写代码，开发负责 review 生成的文件是否符合预期，必要时在聊天窗口里纠偏。

[图7]

第四步：Steering 规范的实际效果

这里有一个细节值得分享。在 `codeRule.md` 里，我明确写了要避免 Sonar 扫描的几类问题，比如”函数嵌套不超过 3 层”、”认知复杂度不超过 15″。Kiro 在生成代码时会主动遵守这些约束，把复杂逻辑拆分成独立函数，而不是写出一个嵌套五层的大函数。

这相当于把 Code Review 的部分工作前置到了代码生成阶段。

第五步：让 Kiro 提交代码并发起 Pull Request

代码写完之后，直接在聊天窗口里告诉 Kiro：”帮我提交代码并发起 PR”。Kiro 会通过终端依次执行：

git checkout -b feat/jwt-token-signing
git add .
git commit -m "feat: implement JWT token signing service"
git push origin feat/jwt-token-signing
gh pr create \
--title "feat: implement JWT token signing service" \
--body "## Summary\n- Add JWT signing service\n- Integrate with TokenExchanger\n- Add JWT config validation on startup" \
--base main

整个过程不需要离开 IDE，也不需要手动打开浏览器去 GitHub 上操作。Kiro 执行完后会把 PR 链接直接输出在聊天窗口里。

这里用的是 GitHub CLI（`gh`），如果是 Bitbucket 或 GitLab，同样可以通过对应的 REST API 调用实现，原理完全一样，只是命令换一下。

至此，从 Jira Task 到 PR 创建，整个流程全部在 Kiro 里完成，开发者几乎不需要切换任何工具。

五、挑战与未来展望

尽管 AIDLC 展现出了惊人的潜力，但在实际落地中，行业与我们也面临着不少亟待解决的挑战。

首先是规范驱动（SDD）带来的摩擦。如果要求 AI 每次都生成冗长的 Markdown 规范文件，不仅会让开发人员感到繁琐，而且审查这些纯文本规范有时比直接审查代码还要耗时。其次，由于大型语言模型的非确定性 (Non-determinism)，AI 偶尔会忽略规范中的某些细节，这使得人类的持续监督依然不可或缺。同时，面对由 AI 瞬间生成的超大体积 Pull Request，传统的代码 Review 流程极易成为新的瓶颈。

此外，在通过大型客户项目实践过程中，我还发现了以下挑战

安全与隐私风险：企业级代码库交由第三方大模型处理时，可能存在知识产权泄露的隐患。
开发者技能退化：当 AI 包揽了绝大部分实现工作后，初中级开发者可能失去在“踩坑”中积累底层架构经验的机会。
上下文窗口的极限：对于极其庞大的存量项目（Brownfield），即便使用了 RAG 和上下文工程，如何让 AI 在百万行代码中精准定位逻辑关联，依然是个工程难题。

AI 驱动的 SDLC 仍在高速演进中。工具和工作流会不断迭代，甚至推翻重来。但它在研发速度、质量和扩展性上带来的指数级收益已是不可逆的趋势。

对于企业而言，继续观望意味着错失良机。只有尽早投资于人员转型，构建强大的 AI 协同编排与治理机制，才能在这个 AI 定义软件的未来中占据领先高地。

六、结语

➡️ 下一步行动：

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客