现在稍微认真用智能体写代码的人，电脑里多半不止一个工具。Claude Code写重构、Cursor改前端、Codex CLI跑批处理，各有用得顺手的地方。麻烦也跟着来：每个工具的规矩文件格式都不一样，CLAUDE.md、.cursor/rules、AGENTS.md、.codex/下面那一套，你只要换一次工具，就得把项目约定重写一遍，写到最后自己都不知道哪份是最新的。这种情况在小团队里尤其明显：三个人各自用不同工具，项目根目录下堆着四五份规矩文件，内容互相矛盾，改一份另外几份就过期。新人进来第一件事不是读代码，是猜“到底以哪份为准”，猜错了写出来的东西又得返工。
这个问题在10月被AWS Labs的一个项目正面回答了。仓库叫awslabs/aidlc-workflows，10月15日上了Hacker News，版本2.11.0，MIT-0许可，当时五千四百多星。它做的事说起来不复杂：把一套软件交付流程写成一个与工具无关的内核，再给每个工具配一层薄薄的适配外壳，让同一套规矩能在七个不同的编程智能体上跑。这个思路在软件工程里不新鲜——把业务逻辑和具体平台解耦，是几十年的老办法。新鲜的是有人把它用在了“给智能体立规矩”这件事上，而这个领域此前基本是靠各家的配置文件各自为政，谁也没想过抽一层出来。
七个是哪七个：Claude Code、Kiro CLI、Kiro IDE、Codex CLI、Cursor、opencode、GitHub Copilot。选择的办法是在项目根目录跑一条命令，指定你用哪个工具，之后在这个工具里用/aidlc开始干活，Codex CLI里则要写成$aidlc。内核在core/目录里，适配层各自负责“审批怎么渲染、子代理怎么派发、会话事件怎么触发、配置放哪儿”这些外壳差异。目录结构上还有个细节：core/是手写的、与工具无关的方法论和引擎，harness/是每个工具一层薄适配，plugins/是可选的扩展，能往里加stage。这个分层的好处是工具换代的时候你只需要等适配层更新，方法论那部分不用跟着动。
项目自己的README给了一组数字：5个阶段、33个stage、14个代理（11个领域专家、2个审查者、1个自适应编排者）、11种工作流配置、119类事件审计。需要说明的是，这些数字全部来自项目文档，没有第三方复测，把它当成“项目自述”看比较稳妥。数字大不代表好用，33个stage对一个小改动来说可能是负担。不过它自己也提供了调节手段：scope、depth、test strategy三个维度都能在流程中途改，还有一组命令行工具可以跳转、重做、查状态。所以“33个stage”更像个上限，实际跑的时候按任务裁，别被数字吓住，也别真的一路走完。
真正有价值的设计是另外两条。第一条是每个stage都有审批闸口，人点了头才往下走，不是让它一口气把活干完。第二条是学习回路：你纠正它的地方会被转成持久的规则，下一轮同类任务它就记住了。这两条加起来，等于把“人的判断”也变成了可积累的资产，而不是每次重来一遍。学习回路这一条值得单独说。它记的不是“你说了什么”，是“你改了什么”——你把它的输出从A改成B，这个差异被抽成规则，下次遇到同类场景它直接按B来。这类机制在别处也有，通常叫“从反馈中学习”，难点在于怎么避免把一次偶然的偏好固化成永久规则。
它想解决的三个毛病，其实每个用过智能体的人都有体会。一是所有任务套同一套流程，改一个错别字也要走需求分析；二是没有深度档位，小活被过度工程化；三是自动化过头，人彻底被挤出审查环节。它的做法是让智能体先判断这个请求属于哪一类，再决定走哪些stage、每个stage挖多深，最后停在闸口上等人。11种工作流配置覆盖了新功能、缺陷修复、基础设施、安全、概念验证、企业交付这些场景。听起来很多，落到日常其实常用的就那么两三种。真正省心的地方不是选择多，是它不再要求你用同一套流程对待所有事——改个错别字和上一个新服务，本来就不该走同一个流程。
安装上有个细节值得提前知道：官方推荐用校验过哈希的原生安装脚本，装完会有个aidlc命令，正常路径不需要你自己装Bun或者Node。只有在“不能装可执行文件、必须手动复制文件”这条备用路径上才需要Bun。Windows下的安装会写到当前用户的PATH里，用管理员权限打开的窗口反而会弹警告，因为以管理员身份装不够安全。还有个坑要提前知道：Codex CLI那边要求目标项目必须是个Git仓库，否则项目级的钩子发现不了。这个条件不满足的话，装了也跑不起来，而且报错信息不一定直白，容易让人以为安装本身失败。
对站长来说该不该用？判断标准很简单：你要它干的是“改一行CSS”，这套东西太重，光装载流程的注意力成本就超过任务本身。你要它干的是“改生产站点的模板和配置”，那审批闸口就值钱——它至少能保证每一步你都看过，而不是早上起来发现三十个文件被改了。一个折中的用法是：只在“要动生产环境”的任务上用它，日常小改还是直接对话。这样既拿到了审批闸口，又不用为改一个按钮走一遍完整流程。工具的价值在于“该严的时候能严”，不是“永远严”。
最后说回那个更根本的判断。这类项目真正的贡献不是“33个stage”，是把“工程规矩”从“某个工具的配置文件格式”里解放出来。工具会一直换，今天用Claude Code，明年可能换别的，但一个团队怎么定义“完成”、什么时候必须停下来问人、什么算不可接受的改动，这些东西应该留在自己手里，而不是每次跟着工具一起搬家。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
