AI-DLC 这套流程适合谁

AI-DLC Workflows 2.0 这套 AWS 的 AI 驱动开发流程，现在默认 main 分支 GA，正式可用，适合已经在多个编码智能体之间切换、且愿意把流程规则当成工程资产维护的团队。如果只是想让 Copilot 补全几行代码，它可能显得重。

我上周把 awslabs/aidlc-workflows 的 main 分支拉下来试了一轮。界面不花哨，仓库里主要是 harness 文档、规则文件和扩展目录。第一次卡住是在“harness”这个词上。简单说，harness 指的是模型跑在哪套开发壳子里，Claude Code、Kiro CLI、Kiro IDE、Codex CLI、Cursor、opencode、GitHub Copilot 都算不同 harness。我拿最熟的 GitHub Copilot 试了一下，大概用了一个月，所以接进来没有太大陌生感。

跑小需求时，我丢了一个“给已有接口加限流并补测试”的任务。它没有直接吐代码，先让智能体出计划，再追问边界。限流维度是什么，返回码怎么定，测试要不要覆盖并发。这个体验有点惊喜，因为平时 Copilot 太容易顺着提示直接写，写快但容易漏。踩的坑也有。规则文件是 Markdown，改起来轻，但多人维护后容易变成谁也不敢删的长文档。我加了一条“外部调用必须有超时”的扩展规则，结果旧提示和新规则打架，智能体开始反复解释，不直接改代码。

好处是一套核心规则能复用到不同智能体，多人协作时这个方案更省事，流程有闸门，需求、计划、实现、验证不是一锅炖。坏处是前期定义规则的成本省不掉，也不太适合急着交 demo 的单人项目。之前我用 WorkBuddy 做信息抽取，日期字段还要自己核对；AI-DLC 给我的感觉类似，自动化不能替你把验收标准写清楚。

我会建议先拿一个真实小模块试，不要一上来全团队推广。它能不能把 AI 编码从生成代码变成可审查的工程流程，还得看规则会不会被认真维护。我下一步会拿一个小模块继续跑，看规则维护成本能不能压下来。

---

📌 本文编译自 Hacker News，原文 https://github.com/awslabs/aidlc-workflows/tree/main

版权归原作者所有，本文为基于公开报道的编译与独立分析。