如何在 AWS Quick 中用 AI-PDLC 加速产品开发生命周期

AI-PDLC 是 AWS 博文介绍的一套产品开发框架，运行在 AWS Quick 中，由一个统筹智能体和五个专业智能体组成。它要解决的不是怎样更快写代码，而是怎样从分散的客户反馈中判断该解决什么问题，并把判断依据逐步整理成可供设计和工程使用的材料。

文章属于配置与操作教程，展示如何搭建和运行这套智能体流程，并非宣布所有企业已取得实际生产成效。其重点覆盖发现、决策、设计和原型四个前期阶段；后续工程、发布、运营和学习阶段交给编码智能体等工具处理。

团队主要与 Orchestrator（统筹智能体）对话。它在运行时读取各专业智能体的问题框架，按当前阶段提问，再把材料生成任务交给 Discovery、Prioritize、Working Backwards、Spec Generator 和 Designer。来自 Slack、Outlook、Jira、Salesforce、SharePoint、ServiceNow 等已连接来源的信息，可以成为分析依据；产物集中保存在共享 Quick Space 中。

整个流程保留人工决策权：团队确认痛点、批准优先级和规格、允许进入构建，并验收审查结果。每个专业智能体在产物中记录评分、理由和决定，统筹智能体还会检查这些记录并维护跨阶段日志。

发现阶段收集问答、网址和企业系统中的信息，按严重程度与出现频率整理痛点。决策阶段用公开的 0—10 分框架比较候选用例；智能体类用例考察大语言模型能力匹配、工具可用性和用户接受度，传统应用则考察可行性、业务影响和投入。选定方向后，Working Backwards 智能体生成包含客户与内部常见问题的 PR/FAQ，用来提前审视成本、失败方式、监管风险和竞争情况。

设计阶段把已确认的用例转成包含验收标准、用户流程、约束和来源信息的规格。原型阶段再生成用户旅程图、线框图和可点击 HTML 原型，供利益相关者验证概念。这里的原型是前期验证材料，不等同于已经发布或投入生产。

各阶段最终汇总为 prototype_spec.md，其中可包含验收标准、用户角色、界面和数据模型，并保留需求来源。AWS Quick 可通过开放的 Agent Client Protocol（ACP，基于 JSON-RPC 2.0）把开发任务交给 Kiro、Claude Code 等编码智能体。验收标准同时作为编码时遵循的约定和后续审查依据。

这种衔接并不取消人工确认。原文明确要求规格批准后才交给工程团队，并称没有明确签字就不会发布；因此它描述的是受人工审批约束的协作方式，而非全自动产品交付。

按教程实践需要安装 Desktop 客户端的 AWS Quick 工作区、创建自定义智能体的权限，以及已经配置好的企业连接器。仓库提供六个智能体的指令、问题框架示例、配置文件和设置指南；用户还要建立共享的产物空间，然后从统筹智能体启动流程并逐关审阅结果。

流程有两种节奏：Deep Discovery 每阶段询问 8—12 个问题，适合探索陌生问题；Fast Track 缩减为 3—5 个关键问题，并根据已有上下文建议可确认或修改的默认答案。原文称耗时可能从数周降到数天甚至数小时，但明确取决于问题复杂度，应视为教程作者提出的可能效果，而不是稳定保证。