夜雨聆风
最近在刷 GitHub，看到一个有点意思的项目——awslabs/aidlc-workflows。
1.6k Star，不多不少。点进去看了一圈，发现这玩意儿可能解决了我最近一直头疼的问题：
用 AI 写代码是爽，但怎么让它写出能真正用起来的代码？
AI 编程的「野蛮生长」时代
先说说现状。
你现在打开 Cursor、Claude Code、GitHub Copilot，让它们帮你写个功能，基本都能写出来。简单的 CRUD 甚至都不用怎么改。
但问题在哪？
你让 AI 帮你重构一个模块，它吭哧吭哧写完了，然后呢？
• 测试写了没？ • 边界情况考虑了没？ • 代码符合团队规范吗？ • 安全性有保障吗？
大多数时候，答案是「看运气」。
AI 编程助手像个很有天赋但没受过训练的实习生。活能干，但你需要花大量精力去 review、去改、去补锅。
AWS 这个项目的核心思路
aidlc-workflows 的全名是 AI-Driven Life Cycle (AI-DLC) adaptive workflow steering rules。
名字很长，但核心思想其实挺简单：
给 AI 编程助手一套「标准作业流程」，让它像正规军一样干活，而不是像个临时工一样东一榔头西一棒槌。
这个项目定义了一套三阶段的工作流：
第一阶段：启动（Inception）—— 先想清楚再动手
这个阶段解决的是「做什么、为什么做」的问题。
具体包括：
• 需求分析和验证 • 用户故事创建 • 应用架构设计 • 开发任务拆分 • 风险评估
说实话，这个阶段最容易被跳过。因为 AI 太「积极」了，你刚说个想法，它就开始噼里啪啦写代码。
但 aidlc-workflows 的做法是：先通过一系列结构化问题，把需求问清楚，然后再动手。
有点像你去找程序员干活，他先拉着你开个会，把需求聊透，而不是上来就写。
第二阶段：构建（Construction）—— 怎么把事儿做漂亮
这个阶段才是真正写代码的环节。
但它不是「写代码 → 结束」这么简单，而是包括：
• 详细的组件设计 • 代码生成与实现 • 构建配置与测试策略 • 质量保证与验证
关键区别在于：它要求 AI 生成的代码必须包含测试、必须考虑构建配置、必须有质量保障环节。
这就避免了「能跑就行」的尴尬局面。
第三阶段：运维（Operations）—— 还没完全实现
这个阶段规划的是部署和长期运营，目前还在开发中。
但方向是对的：代码写完了，还得能部署、能监控、能长期维护。
这个项目最让我眼前一亮的地方
翻完整个仓库，我觉得最有价值的不是那三阶段工作流（这个思路本身不新鲜），而是下面这几个设计：
1. 自适应智能
它不是让你每次都走全套流程。
如果你的需求很简单，比如「改个配置文件」，它就走个轻量级流程，快速搞定。
但如果你的需求是「重构整个支付模块」，它就会走全量流程，该有的环节一个不少。
这个设计很人性化。因为不是所有需求都需要按部就班，太死板反而会降低效率。
2. 问题驱动，而不是聊天驱动
这是我觉得最重要的一个设计。
现在很多 AI 编程助手的使用方式是：「你一句话，它干一堆事儿」。
但 aidlc-workflows 的做法是：通过预定义的结构化多选问题，引导你把需求说清楚。
为什么要这么做？
因为自然语言的「聊天」太容易遗漏信息了。你以为你说清楚了，但 AI 理解的可能完全不是那么回事儿。
而结构化问题就像一份 Checklist，确保关键信息的完整性和准确性。
3. 用户全程可控
所有阶段生成的计划、代码、文档，都需要用户手动审查批准后才能继续执行。
AI 只提建议，不做决策。
这个设计我给满分。因为一旦让 AI 有了「自作主张」的权力，出事儿的概率是 100%。
4. 厂商中立
这是最让我意外的一点。
这个项目不是给某个特定 IDE 或 AI 模型定制的，而是支持所有主流 AI 编程助手：
• Kiro IDE / Kiro CLI • Amazon Q Developer • Cursor IDE • Cline（VS Code 扩展） • Claude Code CLI • GitHub Copilot • OpenAI Codex
甚至任何支持项目级规则的 AI 代理都能用。
它的做法是：提供一套标准化的规则定义，然后针对不同平台生成对应的配置文件。
比如 Claude Code 用 CLAUDE.md，Cursor 用 .cursor/rules/，GitHub Copilot 用 .github/copilot-instructions.md。
但规则本身只有一份，不同平台的配置文件都是从这份规则自动生成的。
这个设计避免了「重复维护多份配置」的噩梦。
怎么用起来？
如果你感兴趣，使用方式很简单：
1. 去项目的 Releases 页面 下载最新规则包 2. 解压后，根据你用的 AI 编程助手，把规则文件放到项目对应目录 3. 在 AI 聊天框输入 Using AI-DLC, <你的需求>，就能激活工作流了
比如你用 Claude Code，就把 CLAUDE.md 放到项目根目录，然后把 .aidlc-rule-details/ 目录也放进去。
然后用的时候，开头加上 Using AI-DLC 就行。
适合什么样的团队？
我觉得这个项目最适合这几类团队：
1. 已经在用 AI 编程助手，但感觉「失控」的团队 —— 你们需要一套流程来规范 AI 的行为 2. 多人协作的项目，需要统一 AI 辅助开发标准的团队 —— 规则可以统一，避免每个人用 AI 的方式不一样 3. 对代码质量有要求的团队 —— 这套流程强制要求测试、强制要求质量保障，能有效提升 AI 生成代码的质量
但如果你就是自己写写 side project，那可能没必要搞这么复杂。毕竟流程本身就是一种成本。
一些思考
翻完这个项目，我最大的感受是：
AI 编程助手的发展，正在从「能不能写代码」向「能不能写好代码」转变。
早期的 AI 编程助手，能写出能跑的代码就算成功。
但现在，大家开始关注：代码质量怎么样？符合规范吗？有测试吗？能部署吗？能维护吗？
aidlc-workflows 就是这个转变的一个产物。
它不一定是最优解，但至少提供了一个可行的方向：用标准化的工作流，让 AI 编程助手的输出更可控、更高质量。
这个项目目前才 169 次提交，v0.1.8 版本，还在早期阶段。
但思路是对的，而且 AWS 团队在持续维护（最新发布是 2026 年 4 月 20 日）。
如果你也在关注 AI 编程的工程化问题，这个项目值得翻一翻。
项目地址：https://github.com/awslabs/aidlc-workflows
