以下是您要求的英文文章的中文翻译，已按照要求保留原文结构、技术术语和代码块，并输出为 Markdown 格式。
Specsmaxxing – 论克服 AI 精神病，以及我为何用 YAML 编写规格说明
acai.sh [跳转到主要内容] Acai.sh 主页 文档 API 参考 博客 搜索... 搜索... 导航 Specsmaxxing 应用 (登录) GitHub 博客 博客 博客首页 本页内容 这看起来眼熟吗？ 巅峰垃圾 边飞边规划飞机 用 Markdown 做梦 AI 验收标准 (ACAI) Acai.sh - 一个开源工具包 工作原理 第一步 - 指定 第二步 - 交付 第三步 - 审查 第四步 - 迭代/重复 未来展望 思想实验 -> 从 Specsmaxxing 到 Testmaxxing -> 从 Testmaxxing 到反应式软件工厂 与其他规格驱动开发工具的对比 GitHub SpecKit OpenSpec Kiro Traycer.ai 你可能不喜欢 acai.sh 的原因 讨厌它？ Specsmaxxing 论克服 AI 精神病，以及我为何用 YAML 编写规格说明（外加开源一个工具包供你尝试）
文档索引 获取完整文档索引，请访问：https://acai.sh/llms.txt 在进一步探索前，请使用此文件发现所有可用页面。
这看起来眼熟吗？
哇。Claude。令人惊叹。整个功能运行得很好。但我忘了提一个非常重要的边界情况。
你说得完全正确！让我修复它。
啊，我刚刚注意到。你为表格 UI 使用了偏移分页。显然游标分页更适合这里？
你说得完全正确！让我修复它。
还有，这是不是 N+1 查询？为表格中的每一行都去获取数据？为什么不一次往返完成？
你说得完全正确！让我修复它。
这就是为什么我还能保住工作，对吧？
…
巅峰垃圾
我见过这种场景很多次，但频率正在下降。我的工具，以及我使用它们的方法，都在不断改进。我认为“巅峰垃圾”时代已经过去。我们正在进入后垃圾时代。我的软件比以往任何时候都更健壮、测试更充分、集成更好、可观察性更强。而且我的速度还在不断提升！有些日子感觉天空才是极限。其他日子，我被痛苦地提醒，天空并非极限。上下文窗口才是极限。
当我填满上下文窗口时会发生什么？或者结束一个会话？切换机器？把项目交给别人？我们已经知道会发生什么。AI 代理会偏离轨道，需求会丢失，至关重要的细节会被压扁。
所以我们适应并缓解。我们编写文档。我们列出需求。是的，数以百万计的人正在得出同样的结论：我们应该把更多需求写下来。当需求变化时，我们应该更新这些需求。看！我写了一份规格说明！我是在做规格驱动开发吗？也许吧，但这并非新鲜事。几十年前，我们的导师就试图教我们这些习惯。
边飞边规划飞机
你最喜欢的规格说明风格是什么？一个 README.md 和 AGENTS.md 是个好的开始。别忘了 testing-guide.md。也许还需要一个 architecture.md、一个 PRD.md 和一个设计文档。你考虑过 md.md（用来教你的 AI 代理如何编写 .md 文件）吗？.md 文件越多越好，对吧？不开玩笑，是的。文档和非结构化的规格说明可以带你走得很远、非常远。远胜于仅仅使用提示词。如果你还没写任何文档，你应该就此打住，从那里开始。记住，垃圾进，垃圾出。没有什么能比得上有机的、牧场散养的、手写的规格说明。编写规格说明才是软件工程真正发生的地方。
所以几周前，我开始问自己，我能把这件事做到什么程度？我应该做到什么程度？
用 Markdown 做梦
故事是这样的，我陷入了 AI 精神病，我成了一个“规格最大化者”，我花了无数小时编写你见过的最漂亮的 PRD 和 TRD。我起草了模板、技能和角色，想着也许我的 AI 代理也能编写规格说明！我组建了一支军队，像一个小型黑暗工厂一样协同工作，把我的规格说明变成现实。我的任务变得越来越雄心勃勃，有一次我打破了“氛围编码”的音障：一个 AI 代理无监督运行了 1.5 小时！令人兴奋。
但那支军队为我交付了什么？嗯，不是垃圾，实际上它能工作，这比我对其他公司强迫我每天使用的垃圾的评价要高。但它仍然有点马虎。我远非完美主义者，而且比大多数人更喜欢走捷径，但这 somehow 还不够好。AI 精神病的一个典型症状是使用 AI 来构建用于构建产品的 AI 工具，而不是直接使用 AI 来构建该死产品本身。我接受了自己的病症，扔掉分支，废弃了我所有的 Markdown，然后从头开始。
AI 验收标准 (ACAI)
几天后，我注意到一个雄心勃勃的小型子代理在做一些意想不到的事情。
# 需求
AUTH-1: 接受 `Authorization: Bearer ` 头部
AUTH-2: Token 是用户作用域的，提供对用户任何资源的访问
AUTH-3: 拒绝时返回 401 Unauthorized
// AUTH-1
const authHeader = req.headers["authorization"];
// AUTH-2
const isAuthorized = verifyBearerToken(authHeader);
// AUTH-3
if (!isValid) return res.status(401).json({ error: "Unauthorized" }); 这个小家伙竟然把我的需求编号了，然后在我的整个代码库中引用了它们。为什么？我并没有要求这样做！我感到厌恶。这是代码与规格说明、规格说明与代码的紧耦合，这很糟糕，对吧？你真的指望我每次修改规格说明时都重构所有代码？哦。我想这也许是件好事？有趣。我想知道……也许这些标签可以帮助我浏览这些庞大的 PR？也许它们可以指出需求具体在何处被满足或测试！也许我可以用注释和状态（待办、已分配、已完成）来标注它们！也许我可以开始跟踪验收覆盖率，而不是测试覆盖率！
我深入研究了。我把这些标签命名为 ACID（验收标准 ID）。但仍有一些问题。我的 ACID 能否自动编号和标记？保持它们对齐是否繁琐？我如何在不同的沙箱、分支、功能和实现之间共享规格说明和进度？
Acai.sh - 一个开源工具包
我构建了 Acai.sh 来解决其中一些新发明的问题。而且我正