Acai.sh 这次开源的东西，看起来很朴素：把功能需求写进 feature.yaml，给每条验收标准一个可追踪 ID，再让代码、测试和评审围着这些 ID 转。
有意思的地方不在 YAML。
真正反常的是，AI agent 已经能很快写出一大坨代码，但团队反而更难回答一个老问题：这次改动到底满足了哪些需求，哪些只是模型顺手补出来的？
我的判断是，AI 编程越快，软件开发里更值钱的资产会从 prompt 和代码片段，转向可验证、可追踪的验收标准。Acai.sh 不是证明这条路已经跑通了，但它把这个问题摆得很清楚。
AI 编程的真实瓶颈：不是不会写，而是需求会丢
作者有一个判断：Peak Slop 已经过了。
这句话不用理解成 AI 代码质量已经没问题。更准确地说，最粗糙、最失控的那段体验正在改善。Claude、Cursor、OpenCode 这类工具，已经能把很多局部编码任务做得很快。
但另一个问题冒出来了：上下文不稳定。
一次会话里说过的边界条件，换个窗口可能就没了。某个临时 prompt 里补过的约束，交给同事 review 时未必还看得见。agent 改了十几个文件，reviewer 面对的常常不是“需求清单”，而是一屏又一屏 diff。
这就是 Acai.sh 想切的口子：不要只追着模型补 prompt，而是把验收标准变成工程流程里的对象。
它的核心组件并不复杂：
| 对象 | 作用 | 解决的问题 |
|---|---|---|
feature.yaml | 记录功能、组件、约束和编号验收标准 | 把临时对话变成可保存的需求清单 |
| ACID | Acceptance Criteria ID，用来标记每条验收标准 | 让需求能被代码和测试引用 |
| CLI | 接入本地、CI 或 agent 流程 | 让追踪动作进入开发流程 |
| Dashboard / JSON REST API | 汇总 spec、代码引用和评审状态 | 让 reviewer 从需求项看进度和风险 |
项目采用 Apache 2.0 许可证。CLI 可通过 npm 或 GitHub release 获取。作者也提到 hosted version 暂时免费，甚至可能一直免费。
但这里要压住期待：这还是早期工具，不是一个已经被大规模验证的商业平台。
Acai.sh 的关键变化：review 不只看 diff，也看 ACID
Acai.sh 把每条验收标准编号，作者称为 ACID，也就是 Acceptance Criteria ID。
比如一条登录需求可以叫 AUTH-1。agent 在实现代码和测试注释里引用它。评审时，团队看的就不只是某个文件改了什么，还可以看 AUTH-1 有没有对应实现、有没有验证线索、有没有被遗漏。
这会改变 review 的入口。
传统 AI 编程流程里，需求往往散在 prompt、README、聊天记录和 PR 描述里。到了评审阶段，reviewer 要靠经验从 diff 里倒推意图。人少、改动小还行；一旦 agent 生成的 PR 变大，就很容易顾此失彼。
Acai.sh 想把入口换成需求项。
| 评审问题 | 传统做法 | Acai.sh 的做法 |
|---|---|---|
| 这次要实现什么 | 看 prompt、PR 描述、diff | 看 feature.yaml 的验收项 |
| 某条需求落在哪里 | 人肉搜索代码 | 用 ACID 连接需求、代码、测试 |
| 测试是否足够 | 看 test coverage 和测试文件 | 看 acceptance coverage |
| 大 PR 怎么审 | 按文件逐段看 | 按需求项逐条核对 |
这里最容易误解的是 acceptance coverage。
它不是传统 test coverage 的替代品。test coverage 关心代码路径有没有被执行。acceptance coverage 关心需求项有没有实现和验证线索。
前者回答“代码跑到了哪里”。后者回答“承诺有没有被覆盖”。
两者不能互相冒充。一个需求写错了，coverage 再高也只是把错误执行得更完整。一个测试体系很薄，ACID 标得再整齐，也只能说明追踪更清楚，不能说明质量更好。
这也是我不太买账“spec 工具能解决 AI 代码质量”的地方。它解决的是追踪和评审问题，不是替团队做架构判断、安全审计和端到端验证。
谁该现在用：开发者先改习惯，负责人先选场景
对用 Claude、Cursor、OpenCode 写代码的开发者，Acai.sh 的现实意义不是多装一个工具，而是少把关键约束塞在聊天框里。
更可行的动作是：
- 新功能开始前，先写 5 到 10 条验收标准；
- 每条标准给一个稳定 ID；
- 让 agent 实现时引用这些 ID；
- review 时按 ID 核对，而不是只问“这段代码看起来对不对”。
这不会让开发变轻松到哪里去。它只是把一部分返工，提前挪到写 spec 的时候。前面多花一点力气，后面少猜一点意图。
对负责代码评审、测试和工程流程的技术负责人，动作应该更谨慎。
不建议一上来全团队迁移，也不建议把它包装成流程革命。更现实的是挑高风险场景试：权限、计费、数据迁移、关键业务状态机，或者 agent 容易生成大 PR 的模块。
这些地方最怕的不是代码少写几行，而是某个边界需求没人记得。
Acai.sh 和 GitHub SpecKit、OpenSpec 等方向有相近的问题意识：把开发从临时 prompt 拉回 spec-first。作者也承认，spec-driven development 并不是新概念。敏捷、BDD、PRD、测试用例，早就讲过需求要可验证。
差异在于，过去 spec 主要给人看。现在 spec 还要给 agent 执行、引用、回传状态。
接下来我会看三个变量，而不是看它口号有多顺：
- ACID 标注能不能长期维护，还是几周后就变成新债务；
- Dashboard 能不能适配多仓库、多分支和真实 PR 流程；
- QA、CI、线上告警触发 agent 自动修复时，是减少噪音，还是制造更多不确定改动。
作者把后面这个方向叫 Testmaxxing 和 reactive software factories。翻成直白话，就是测试失败、告警出现、QA 反馈进来后，agent 自动尝试修复。
这个设想并不遥远。一些工程能力强、预算充足的团队已经在做类似内部系统。
但门槛也在这里。spec 如果含糊，测试如果不可信，自动修复只会把问题跑得更快。工欲善其事，先利其器；但器具磨快之前，尺子要先准。