使用 AI-DLC 和 Amazon Q Developer 进行构建 | AWS DevOps 和开发人员生产力博客
AI驱动的开发生命周期（AI-DLC）方法论通过将常规任务策略性地分配给AI，同时保持人类对关键决策的监督，标志着软件开发的重大变革。Amazon Q Developer 是一款生成式AI编码助手，支持整个软件开发生命周期，并提供 Project Rules 功能，允许用户在平台内定制他们的开发实践。
最近，AWS 将其 AI-DLC 工作流开源，使开发人员能够使用这种方法论创建软件。该工作流通过其 Project Rules 定制功能在 Amazon Q Developer 中实现。在本文中，我们将通过一个示例用例来演示 AI-DLC 工作流如何在 Amazon Q Developer 中运行。
AI-DLC 工作流概述
AI-DLC 工作流是 AI-DLC 方法论执行软件开发任务的实践实现。正如《AI-DLC 方法定义论文》所述，该工作流包含三个阶段：启动（Inception）、构建（Construction） 和运营（Operations）。启动阶段涉及规划和架构，构建阶段侧重于设计和实现，运营阶段涵盖部署和监控。每个阶段都包含不同的阶段，这些阶段处理特定的软件开发生命周期功能。
该工作流会根据项目需求进行自适应。它分析请求、代码库和复杂度，以确定必要的阶段。简单的错误修复会跳过规划，直接进入代码生成。复杂的功能则需要需求分析、架构设计和详细测试。
工作流通过结构化的里程碑和透明的决策来保持质量和控制。在每个阶段，AI-DLC 会提出澄清性问题，创建执行计划，并等待批准。每个决策、输入和响应都被记录在审计跟踪中，以确保可追溯性。无论是构建新的微服务、重构遗留代码还是修复生产错误，AI-DLC 都会根据需求调整其严谨性：复杂时全面，简单时高效，并且始终处于控制之下。图1显示了自适应 AI-DLC 工作流中的阶段。绿色框中的阶段是强制性的，黄色框中的阶段是有条件的。
图1. AI-DLC 工作流中的 SDLC 阶段
先决条件
在开始演练之前，我们必须拥有用于 Amazon Q Developer 身份验证的 AWS 账户或 AWS Builder Id。如果您没有，请注册 AWS 账户或创建 AWS builder id。您可以使用任何 Amazon Q Developer 支持的集成开发环境（IDE），并按照 AWS 文档安装扩展。在本文中，我们将使用 VS Code IDE 中的 Amazon Q Developer 扩展。插件安装完成后，您需要使用 AWS 云后端对 Q Developer 进行身份验证。请参考 AWS 文档获取 Q Developer 身份验证说明。
AI-DLC 工作流会在 Markdown 文件中生成各种 Mermaid 图表。要在 IDE 内查看这些图表，您可以安装 Mermaid 查看器插件。
让我们开始构建！
让我们使用 AI-DLC 构建一个简单的“过河谜题”作为 Web UI 应用程序。通过选择一个简单的应用程序，我们可以将更多精力放在学习 AI-DLC 工作流上，而不是项目的技术细节上。
以下部分概述了使用 Amazon Q Developer 进行 AI-DLC 开发过程的各个步骤。我们将展示带有 Amazon Q Developer 插件的 IDE 截图，并演示如何与工作流交互。
虽然我们在本文中使用了 Amazon Q Developer IDE 插件，但您也可以使用 Kiro 命令行界面（CLI）来构建 AI-DLC，无需任何额外设置。工作流保持不变，只是您将通过命令行而不是 IDE 中的图形界面进行交互。
随着我们在工作流中的进展，您的 AI-DLC 体验将根据您的具体问题陈述进行定制。您还会注意到大型语言模型（LLM）的概率性质，因为对于相同的问题陈述，每次运行生成的问题和工件都会有所不同。例如，如果您尝试复制我们在本文中使用的相同问题陈述，您的体验可能会有所不同。这是预期的，也是可取的。尽管存在这些细微差异，我们最终将找到解决最初提出问题的方案。
步骤 1：克隆包含 AI-DLC Q Developer Rules 的 GitHub 仓库
克隆包含 AI-DLC Q Developer Rules 的 GitHub 仓库：
|
|
步骤 2：在项目工作区中加载 Q Developer Rules
步骤 3：在 IDE 中安装并验证 Amazon Q Developer 扩展
在 VS Code 中打开您在步骤 2 中创建的项目文件夹。在 IDE 中打开 Amazon Q 聊天面板，确保 AI-DLC 工作流规则已加载到 Q Developer 中，如图 2 所示。如果您看不到图 2 所示的内容，请仔细检查您在步骤 2 中执行的步骤。
图 2：在 Amazon Q Developer 中启用 AI-DLC 规则
步骤 4：输入高级别问题陈述以启动 AI-DLC 工作流
我们的开发环境现已设置完毕，可以开始使用 AI-DLC 进行应用程序开发了。在我们的 Q Developer 聊天会话中，我们输入以下问题陈述：
|
|
请注意，我们在问题陈述前加上了“使用 AI-DLC …”，以确保 Q Developer 启动 AI-DLC 工作流。图 3 显示了接下来发生的情况。AI-DLC 工作流在 Q Developer 中被触发。它向我们发出欢迎消息，并简要概述了 AI-DLC 方法论。
图 3 左侧显示了 AI-DLC 工作流规则文件夹结构的展开视图。您会注意到，单个 aws-aidlc-rules/core-workflow.md 文件被放置在指定的 .amazonq/rules 文件夹中，而其余的规则文件则放置在普通的 aws-aidlc-rule-details 文件夹中。这种安排旨在优化模型效率。通过将 aws-aidlc-rules/core-workflow.md 文件放在 .amazonq/rules 文件夹中，它作为附加上下文，确保核心工作流结构始终可访问，而不会产生额外的令牌消耗。相反，详细的阶段和行为级别规则存储在 aws-aidlc-rule-details 文件夹中，并根据需要动态加载。这种方法通过在任何给定时间仅在上下文中保留必要的信息，从而节省 Amazon Q 的上下文窗口和令牌使用量，从而提高模型效率。
aws-aidlc-rule-details 文件夹下的规则文件组织成三个子文件夹，每个子文件夹代表 AI-DLC 的一个阶段。在每个阶段内，都有特定于阶段的文件。一个公共文件夹存放适用于所有 AI-DLC 阶段和阶段（例如“人在回路”）的跨领域规则。
AI-DLC 工作流是自引导的，并为我们提供了接下来会发生什么的清晰理解。它告知我们接下来将进入 AI-DLC 启动阶段，从其中的工作区检测阶段开始。
图 3：用户在 Amazon Q 中输入高级别问题陈述。AI-DLC 工作流被触发。
步骤 5：工作区检测
我们进入启动阶段内的工作区检测阶段。在此阶段，AI-DLC 分析当前工作区，并确定它是绿地（新）应用程序还是棕地（现有）应用程序。由于 AI-DLC 是一个自适应工作流，它会决定下一个阶段是逆向工程（针对棕地项目）还是需求分析（针对绿地项目）。
由于我们正在构建一个绿地应用程序，并且工作区中没有现有代码需要进行逆向工程，工作流接下来将引导我们进入需求分析。如果我们正在处理一个棕地应用程序，工作流将首先执行逆向工程，然后进入需求分析。这展示了工作流的自适应性质。
图 4 说明了我们进入此阶段时 IDE 中的过程。工作流请求我们允许在项目根目录下创建一个 aidlc-docs 文件夹。该文件夹将作为工作流执行期间 AI-DLC 生成的所有工件的存储库。随后，工作流在此文件夹中生成两个文件：aidlc-state.md 和 audit.md。这些文件的目的在图 4 中解释。
图 4：工作区检测
工作区检测将很快完成，因为这是一个绿地项目。工作流接下来将引导我们进入启动阶段内的需求分析阶段。
步骤 6：需求分析
工作流已进入需求分析阶段，我们将在此定义应用程序需求。AI-DLC 工作流向 Q Developer 呈现了我们的高级别问题陈述，然后 Q Developer 用几个需求澄清问题进行回应，如图 4 所示。
在此阶段，有几个 AI-DLC 规则发挥了作用。一条规则指示 Amazon Q 避免代表用户做出假设，而是提出澄清问题。由于 LLM 倾向于做出假设并急于得出结论，必须明确指示它们与 AI-DLC 方法的工程严谨性保持一致。为了实现这一点，Q Developer 在 requirement-verification-questions.md 文件中提出了几个需求澄清问题，并要求我们在线回答这些问题。
另一条 AI-DLC 规则指示 Q Developer 以多项选择格式提出问题，并始终包含一个开放式选项（“其他”），以增强用户便利性并提供回答的灵活性。
如图 5 所示，Amazon Q 询问了我们期望的谜题变体，例如经典的“农夫、狐狸、鸡和谷物”谜题或其他流行的变体。此外，它还询问了有关用户交互方法、跨多个玩家的分数持久性以及创建排行榜的问题。
这些问题对于实现我们期望的应用程序结果至关重要。我们对这些问题的回答将决定最终产品。虽然我们在高级别问题陈述中没有明确指定这种详细程度，但 AI-DLC 已将详细需求阐述委托给 Amazon Q，但我们仍然控制构建的内容。
图 5：需求分析
我们在 requirement-verification-questions.md 文件中回答所有问题，并在聊天窗口中输入“完成”。
Amazon Q 处理我们的回答。AI-DLC 工作流旨在识别人为错误。它检查我们是否回答了所有问题，并识别我们回答中的任何矛盾或模糊之处。任何混淆、矛盾或模糊之处都将被标记出来，以便进行后续提问。AI-DLC 遵循高标准，并确保在我们与 Amazon Q 之间就需求完全达成一致之前，不会进入下一步。
由于我们回答了所有问题，并且我们的回答中没有矛盾，工作流继续并生成一个全面的 requirements.md 文档，如图 6 所示。
图 6：需求审查
工作流提示我们审查 requirements.md 文档并决定下一步。如果我们对需求不一致，可以提示 Amazon Q 帮助我们达成一致。然后，我们可以迭代需求，直到完全达成一致。一旦我们完全一致，我们提示 AI-DLC 进入下一阶段。
鉴于 AI-DLC 工作流的自适应性质，Amazon Q 建议该应用程序足够简单，我们可以跳过用户故事阶段。如果我们认为并非如此，我们将覆盖模型的建议。在这种情况下，我们同意 Q 的建议，因此将在聊天窗口中输入“继续”。
工作流接下来将进入工作流规划阶段。
步骤 7：工作流规划
在需求确立之后，我们进入工作流规划阶段。在此阶段，我们利用需求上下文和工作流的智能，来规划执行 AI-DLC 工作流中的特定阶段，以根据需求规范构建我们的应用程序。
图 7 说明了 Q Developer 中的工作流规划阶段。工作流生成了一个 execution-plan.md 文件，概述了建议执行的阶段以及应跳过的阶段。
工作流规划过程与需求高度相关。在需求分析期间，我们决定开发一个简单的过河谜题应用程序，仅包含一个 HTML 文件，没有后端、排行榜或持久性。因此，Amazon Q 建议我们跳过所有有条件的阶段，例如用户故事、应用程序设计、工作单元规划等，并直接进入构建阶段的代码生成计划阶段。
图 7 以图形方式表示了建议的工作流，指示了将要执行的阶段和将要跳过的阶段。
图 7：工作流规划
由于我们在本文中为了简洁起见选择了简单的 Web UI 应用程序，AI-DLC 建议的工作流执行计划与我们的目标无缝契合。如果我们不同意 AI-DLC 推荐的工作流执行计划，我们将请求 Q Developer 修改该计划以符合我们的偏好。
既然我们已经同意了工作流计划，我们将在 Q 的聊天会话中输入“继续”。如果我们不同意推荐的工作流执行计划，我们将向 Q 提出我们的疑虑，并迭代修改后的执行计划，直到它与我们的偏好一致。按照推荐的执行计划，工作流将过渡到构建阶段，并直接进入该阶段的代码生成计划阶段。
步骤 8：代码生成计划
AI-DLC 优先规划而非急于求成。这种方法与“人在回路”行为的概念相一致，使我们能够及早发现问题，对计划提供反馈，并防止错误的假设进一步传播。在我们进行实际代码生成之前，我们进行了代码生成计划。
在代码生成计划期间，AI-DLC 创建一个详细的、编号的计划。它分析需求和设计工件，将过程分解为生成业务逻辑、API层、数据层、测试、文档和部署文件的明确步骤。
该计划记录在 {unit-name}-code-generation-plan.md 文件中，并带有复选框。这确保了透明度，允许用户看到将要构建的内容。它还提供了控制，允许用户修改计划。此外，它通过确保全面覆盖代码、测试和文档来保持质量。
图 8 说明了 AI-DLC 的代码生成计划。建议的工作流包括八个步骤，从创建 HTML 结构开始，逐步进行样式添加、游戏逻辑，最后以测试和文档结束。
图 8：代码生成计划
代码生成计划对我们来说似乎是合理的。我们将在 Q 的聊天会话中输入“继续”，进入代码生成阶段。
步骤 9：代码生成
代码生成阶段执行我们在上一步批准的代码生成计划。它逐步生成实际的代码工件，包括业务逻辑、API、数据层、测试和文档。已完成的步骤用复选框标记，进度被跟踪，并且在向用户展示生成的代码以获取批准之前，确保故事的可追溯性。
图 9 说明代码生成阶段已完成。我们现在正在审查生成的单个 index.html 文件，其中包含嵌入式样式和 JavaScript，与我们在 requirements.md 中指定的偏好一致。
工作流提供了代码生成阶段执行的活动摘要。
图 9：代码生成
我们很快就要测试我们新创建的应用程序。虽然现在测试这个简单的谜题应用程序可能很简单，但对于复杂的应用程序，我们会使用 AI-DLC 生成构建和测试说明。
我们将在工作流中输入“继续”，进入构建阶段的最后一个构建和测试阶段。
步骤 10：构建和测试
我们已到达 AI-DLC 构建阶段的最后阶段，即构建和测试阶段。在此阶段，我们创建全面的指导文件，指导项目的构建和打包，并记录必要的测试层次。这些层次包括单元测试（验证生成的代码）、集成测试（检查单元交互）、性能测试（负载/压力测试）以及根据需要进行的其他测试（安全性、契约、端到端）。
生成的构建说明包括依赖项和命令、具有预期结果的测试执行步骤，以及提供整体构建/测试状态和项目部署准备情况的摘要文档。
图 10 说明了在此阶段生成的文档。
图 10：构建和测试
AI-DLC 工作流现已结束。
让我们来解谜！
我们在 Web 浏览器中打开 index.html 来访问我们新创建的过河谜题应用程序。如图 11 所示，我们看到了图形化的 Web 用户界面。
在需求评估期间，我们选择了一个使用 HTML、CSS 和 JavaScript（没有任何框架）的简单用户界面，这在图 11 的显示中是显而易见的。由于 LLM 的概率性质和您为需求做出的选择，您的显示可能会有所不同。
我们尝试解谜，发现它按预期工作。
图 11：过河谜题 Web 应用
结论
本文展示了 AWS 开源的 AI-DLC 工作流，在 Amazon Q Developer 的 Project Rules 功能引导下，如何帮助开发人员以结构化的监督和透明性构建应用程序。
通过一个过河谜题 Web 应用程序的例子，演练说明了 AI-DLC 方法论如何根据项目复杂性调整其严谨性，为简单应用程序跳过不必要的阶段，同时为复杂项目保持全面的流程。在每个阶段，AI-DLC 都强制执行“人在回路”行为，要求在关键检查点获得用户批准，提出澄清问题，并维护完整的审计跟踪以确保可追溯性。
本次练习成功展示了 AI-DLC 如何在 AI 自动化和人类监督之间取得平衡，在不牺牲质量或控制的情况下提高生产力。通过遵循这种结构化、可重复的方法论，开发团队可以利用生成式 AI 的能力，同时确保人类在架构决策和实施方法上保持主导。该框架为不同复杂度的项目提供了负责任和有效的 AI 辅助软件开发所需的护栏。
清理
我们在本次演练中没有创建任何 AWS 资源，因此不需要进行 AWS 清理。您可以自行决定清理项目工作区。
准备好开始了吗？访问我们的 GitHub 仓库下载 AI-DLC 工作流，并加入 AI 原生构建者社区，为软件开发的未来做出贡献。