浅谈 Amazon AIDLC

最近，我们团队有人浅浅体验了 Amazon 的 AIDLC。这是亚马逊基于软件工程流程开发的一套 AI 开发规范，它利用 Hook、Skill、CLI、Plugin、Marketplace 等特性，实现了一套方便上手、利于协同、持续沉淀的工作流程。引用 AI 总结的一句话介绍就是：

AI-DLC 将 LLM 的灵活能力嵌入严格定义的流程阶段（启动、构建、运营）和仪式（群体精化、群体构建），通过动态 AI 推理、半静态执行框架和人类监督的有机结合，实现可控的自动化。

私以为，这个实践有很多值得参考的地方。

为什么？

为什么出现了 AIDLC

为什么我们需要 AIDLC？并不是说，传统的软件工作流程不再适用了。相反，这套抽象出来的开发流程是高度泛化的一个工作流程，无论是传统，还是 AI First 的开发流程，都应该有需求确认、开发、测试、发布的过程。 只不过是工程师，在 AI First 的软件开发流程里，工作内容发生了变化。

为什么需要统一开发工具和流程？

但是我作为开发，我有一套自己使用的工具，我有一套自己工作的流程，不是就行了，为什么我还需要跟团队的其他同学统一开发的流程呢？ 原因很简单，减少返工，复用经验。 假设工程师 A 用 Claude Code，工程师 B 用的是 Codex，两个人相互设置的 agent 都不在一个文件里，工程师 A 对工作流程有更深的研究，并且加入了很多实用的 harness 约束，那么工程师 B 还需重新踩一遍所有工程师 A 踩过的坑吗？答案必须是否定的，在一个成熟的团队里，一个坑只允许遇到一次。我们对错误的容忍度阈值是很低的。 统一了工具、流程之后，只需要在一个流程上持续地优化和迭代，大家就能轻松复用团队里不同人的经验。 当然，统一开发工具和流程还有很多其它因素，不一一赘述了：

• 成本
• 为进一步的动作准备

为什么是 Amazon AIDLC？

我认为这个点纯粹是巧合，不必一定是 Amazon AIDLC。这件事只不过就像谈恋爱一样，这个方案在合适的时间点，遇到了我们，它的社区还算活跃，那么 why not？

AIDLC 做了什么？

1. specs + 状态管理

对于每个任务，AIDLC 都会把任务、planning、上下文进行收集和管理，放入 spec。 Kiro 作为 spec driven development 鼻祖之一，这方面只是沿用他们一直以来的 practice。

另外每个任务的 spec 定义了任务的状态，无论何时终止，你的任务都还能继续。

2. 项目 workflow，和所需的一切

包括但不限于 workflow、agent、审批门等等。 值得关注的一点是，AIDLC 内置的流程并不是每个任务都会全盘 go through 一遍，而是根据开发团队对 scope 的定义来动态拉取的。 如果是简单的任务只会走简单的流程，如果是 0-1 的项目，则会走更多的流程，甚至包括了“市场调研”这种远离软件工程的流程。 当然，它是允许不同团队，对它进行定制化的定义的。

3. 可迭代

AIDLC 定义了 hook，会在合适的时候回访用户，在关键的时候记录记忆和知识，也会严格区分业务知识、项目知识，或者是组织的记忆，简单地说，如果是全团队都在应用这个工作流程，它将会很快地自我累积、越用越好用。

尚存的问题有什么？

上下文爆炸

我们尚未深度使用此工具，我想它会在某个节点遇到上下文爆炸的问题。或许这是关于 knowledge 如何集成的问题，AIDLC 很聪明地把这部分解耦了，一切的 memory 放在 /knowledge 文件夹下即可，无论你用的是什么技术，RAG、graphify、mem0，都不关它的事，这是行业的事情。

变臃肿

是的，每个人每天，因为一些特定的需求，都会往里面不停地叠加各式各样的规则、知识、约束，但是有些约束，可能只会用到一次，随着一切变得臃肿之后，又会开始污染上下文。 之后，定期维护 AIDLC 变成了一件不得不去做的事情了。这个问题我觉得也是一个无解的问题。

模型的迭代，会逐渐吃掉它

或许在不久的将来，这些高度泛化的软件开发流程，会被模型完全 cover，因为这些内容和过程是共识。如果有使用它的一个绝对的理由，那就是我能用更具备性价比的模型，来执行一个复杂任务，对于企业来说，这是合理且必须要走的一步。 但是如果将来，token 像便宜的自来水一样，这一套大可不必。

边界和期待的模糊

或许有人会觉得，只要我上了这套 AIDLC，所有的开发工作，都应该全自动地交给 AI，这是大错特错的，无论是设计得多么完美的 loops，现在也没办法 100% cover 所有的开发流程，因为总有藏在人们脑海里的 background 是没有体现在文档里的。 甚至选择本身，都隐藏了上下文，比如我不以 xxx 决策来实现 xxx 需求，这件事本身就蕴含了大量上下文，这些上下文并不是白纸黑字地写在某一篇文档里的，是个人，都需要反应半天，如何能期待模型秒懂？ 所以这个方案，总是有一个人与 agent 的边界，我们只是期待它能够优秀地完成某些结果明确的任务，而不是 100% cover 各种任务。 这个边界和期待，是需要人与 agent 长期磨合才能逐渐清晰的边界。AIDLC 并不解决这件事。

难以量化和评估其效果

是的，到目前为止，我并没有一个 100% 有力的理由能够说服每一个开发来使用这个框架，我能想到最简单的方式，就是在一个 task 里，使用两种方法，然后比较它的结果。 然后使用更弱的模型，对其结果继续做评估，直到它展现出明显的缺陷为止。 或许这就是某些基准测试的目的。我并没有明确地做过类似的测试，也拿不出一定要使用它的理由。

其它尚未证实的缺点

• 批评文章（Peter Tilsen）指出 AI-DLC 在学习和反馈机制里，存在一定问题，比如混淆 “learning” 和 “calibration”。它所描述的自我进化和自我学习，并不存在。
• 有人提出，SDD 本质是一个 waterfall 的开发流程，错误地假设了开发流程是确定的。
• 框架过重，缺少透明性。参见 Scott Logic 基准测试：SDD 慢 10 倍、仪式繁重却同样多 bug。

上手

第一次上手

作为 Claude Code 用户来说，只需要通过 Marketplace 安装插件的形式来安装 AIDLC。它同时还支持 Codex 和 Kiro 的那一套 IDE。 单单安装并不够，这是一个相对重的框架，作为团队，第一次引入它的时候需要将自己团队的一些背景告诉它。就是：

• 定义 team.md
• 导入知识库，knowledge/
• 根据团队需要，定义 scope
• 定义 sensor
• 定义技术栈等：project.md
• 组织方面的 memory：org/team/project 方面的信息

当然我也可以直接让它上手执行任务，通过交互的模式，一点一点地完善这些上下文。

第一次上手之后

当团队里某个人把框架设定好之后，其他人简单地设置自己的 idea 就可以开始使用了，只需要在 TUI 里输入：

/aidlc

接下来的一切都不复杂，只需要按照提示，一步一步往下走即可。

anyway

我们团队会继续探索和使用这个工具，往后或许会给大家更多具有参考价值的结论。