aidlc-workflows 是 AWS 官方 awslabs 发布的 AI-DLC（AI-Driven Development Life Cycle）方法论规则集——一套用 Markdown 写的「steering rules」，给 Claude Code、Cursor、Cline、Amazon Q、Copilot、Codex、Kiro 等编码 agent 装上一个 Inception→Construction→Operations 三阶段自适应工作流，用文件里的结构化多选问题驱动需求/设计/实现，并支持安全、测试等可选扩展规则作为阻塞约束。
来源：README 首段 + Three-Phase Adaptive Workflow + Platform-Specific Setup 查看 GitHub 仓库 →「让 AI agent 写代码」容易，「让它按一套可控、有质量门禁、可审计的流程写」难。AI-DLC 是 AWS 把自己的 AI-Driven Development Life Cycle 方法论（配套官方 blog + Method Definition Paper）落成可直接装进主流编码 agent 的规则集：不是又一个工具，而是一层 steering rules，强制 agent 走 Inception（搞清 WHAT/WHY）→ Construction（HOW）→ Operations 三阶段，且自适应——简单改动保持高效、复杂改动才上全套，问题以文件内多选题形式提出（而非聊天），每阶段都要人审批。它踩中企业团队「想用 agent 但要可控、可合规、可审计」的真实诉求，AWS 官方背书 + MIT-0 宽松协议 + 7 个平台适配，是「agentic SDLC 方法论」这条线上最有分量的开源实现。
来源：README 首段 blog/paper 链接 + Key Features + TenetsINCEPTION 定 WHAT/WHY：需求分析与验证、用户故事、应用设计、拆分可并行开发的 units of work、风险与复杂度评估；CONSTRUCTION 定 HOW：组件详设、代码生成、构建配置与测试策略、QA；OPERATIONS（future）做部署与可观测。自适应意味着只执行对当前请求有价值的 stage，简单请求不强制走全套。
来源：README 'Three-Phase Adaptive Workflow' + Key Features（Adaptive Intelligence）结构化多选问题以文件形式提出而非聊天（Question-Driven），让决策可追溯、可版本控制；每个阶段的执行计划都需要用户 review 并逐阶段 approve（Always in Control）。Risk-Based：复杂改动获得全面处理、简单改动保持高效。
来源：README Key Features 表（Question-Driven / Always in Control / Risk-Based）扩展是 aws-aidlc-rule-details/extensions/ 下按类别（security/、testing/）组织的 markdown：每个扩展由 rules 文件 + opt-in 文件（一道多选题）组成。工作流启动时只加载 *.opt-in.md，需求分析阶段呈现给用户；opt-in 才加载对应 rules，opt-out 则永不加载；无 opt-in 文件的扩展始终强制。一旦启用，扩展规则是阻塞约束——每阶段模型先验证合规才放行。内置 security/baseline 和 testing/property-based。
来源：README 'Extensions / How Extensions Work / Built-in Extensions'aidlc-rules/ 分两个子目录：aws-aidlc-rules/（核心 AI-DLC 工作流规则）+ aws-aidlc-rule-details/（被核心规则条件引用的详细规则）。这种「核心常驻 + 细节按需引用」的拆分让 agent 上下文保持精简、详规则按 stage 触发加载。
来源：README 'Common' 安装说明 + aidlc-rules/ 目录结构scripts/aidlc-evaluator/ 是验证 AI-DLC 工作流改动的自动化测试与报告框架：Golden Test Cases（基线用例）、执行编排、Semantic Evaluation（AI 评估输出正确性/完整性）、Code Evaluation（lint/安全扫描/重复检测）、NFR Evaluation（token 用量、执行时间、跨模型一致性）、CI/CD 集成。`uv sync && uv run python run.py test` 启动。
来源：README 'Supporting Tools / AIDLC Evaluator'scripts/aidlc-designreview/ 是实验性 AI 设计评审工具，用 AWS Bedrock 上的 Claude 模型分析 AIDLC 设计产物（aidlc-docs/）。把「设计评审」也纳入可自动化的环节。
来源：README 'Supporting Tools / AIDLC Design Reviewer'从 Releases 下载 ai-dlc-rules-v
这是一个「方法论即规则」的项目，不是代码框架。核心资产是 aidlc-rules/（43 文件）的 Markdown steering rules，分核心层（aws-aidlc-rules/，工作流主干）和细节层（aws-aidlc-rule-details/，条件引用的详规则 + extensions/）。运行机制是把这些规则装进各编码 agent 的规则/记忆位置，agent 据此走三阶段工作流：启动扫 extensions/ 只读 *.opt-in.md，需求分析阶段呈现多选题，按用户选择动态加载对应规则；每阶段产物落到项目内 aidlc-docs/，并要人审批才进下一阶段；启用的扩展规则在每阶段做阻塞式合规校验。scripts/（593 文件）是支撑工具，主要是 aidlc-evaluator（用 uv 管理的 Python 评测框架，含 golden cases + semantic/code/NFR 评估 + CI/CD）和实验性的 aidlc-designreview（走 Bedrock Claude）。仓库带 AWS 级别的工程纪律：.bandit/.checkov/.gitleaks/.grype/.semgrep + pre-commit + cliff.toml（changelog 生成）。设计判断：把 SDLC 方法论拆成「核心规则 + 条件引用细节 + opt-in 扩展」三层、并配独立评测框架来回归规则改动，是相当成熟的「prompt/规则工程化」做法；但本质上整套东西的有效性依赖目标 agent 对长篇规则的遵循度，规则越细、跨平台一致性越难保证，这是方法论类项目固有的张力。
来源：tree（aidlc-rules / scripts）+ README Extensions/Supporting Tools + 安全工具配置文件中心为项目本体，内环 = 核心功能模块，外环 = 关键技术依赖；按 deep.json 中的 core_features 与 tech_stack.key_deps 自动生成
各编码 agent 的规则/记忆机制（Claude Code / Cur…uvAWS Bedrock（Claude 模型）— aidlc-design…安全/质量工具链：bandit / checkov / gitleaks…cliff.toml1. 团队想用 AI agent 写代码但要「可控、可审批、可审计」：用 AI-DLC 强制 agent 走三阶段、每阶段人工审批、决策以文件多选题记录，避免 agent 一把梭；2. 需要在 agent 工作流里嵌入安全/合规门禁：用 opt-in 扩展把 security-baseline、property-based-testing 等规则作为阻塞约束，每阶段先验证合规再放行；3. 跨多个编码 agent 统一开发方法论：同一套规则装进 Claude Code / Cursor / Amazon Q / Copilot / Codex，团队不论用哪个 agent 都遵循一致流程；4. 复杂项目的需求拆解与并行开发：Inception 阶段产出可并行的 units of work；5. 验证/演进自己的 agent 规则：用 aidlc-evaluator 的 golden test + semantic/NFR 评估回归规则改动。
来源：README Key Features / Extensions / Supporting Toolsv0.1.8（2026-04-20）。最近 5 个 release：v0.1.4 (2026-02-24) → v0.1.5 (2026-02-24) → v0.1.6 (2026-03-05) → v0.1.7 (2026-04-02) → v0.1.8 (2026-04-20)。规则集以 ai-dlc-rules-v
如果你的团队想用 AI agent 做开发、但需要一套可控、有质量门禁、可审计的流程，aidlc-workflows 是目前最值得参考的方案：AWS 官方方法论、三阶段自适应工作流、逐阶段审批、opt-in 扩展做合规约束，还罕见地配了评测框架。务实建议：1) 先在一个编码 agent（如 Claude Code）上跑通三阶段，体验「文件内多选题 + 逐阶段审批」的节奏，再考虑跨平台铺开——不同 agent 对长规则的遵循度差异需实测；2) 把内置 security 扩展当「方向性参考」而非可直接上生产的合规规则，README 明确要求各组织自建并充分测试自己的规则；3) 复杂任务会有明显 token/往返开销，简单改动靠自适应短路但要留意误判，跑 aidlc-evaluator 的 NFR 评估量化成本；4) 它是方法论 + 规则，不产出运行时能力，价值在「让 agent 按流程走」而非「替你写代码」；5) 仍是 0.1.x、Operations 阶段未完成、design reviewer 实验性，生产引入先锁 release 版本并跑通自己的 golden test。
来源：综合分析