当 AI 给你一巴掌
Source: Dev.to
当 AI 给你当头一棒：在 Adama 中调试 Claude 生成的代码
有没有让 AI “即兴写代码” 一个复杂特性，结果花了好几个小时调试它漏掉的细微 bug？作为一名构建 Adama——一个面向有状态无服务器应用的平台的开发者，我一直在使用 Claude 加速开发。它在宏观上表现出色，但在 async 时序、pipeline 配置等底层细节上会出错。下面是三个真实的调试“战争故事”，以及让 AI 乖乖听话的经验教训。
WebSocket 激活：Netty Pipeline 噩梦
我让 Claude 在 Adama 中构建一个 MCP（Message Control Protocol）服务器，以便让 AI 在运行时编译 Adama 文档。它交付了一个相当完整的第一版：“书生成器”，能够解析并校验文档中的每段代码片段，并通过 Netty 提供 WebSocket 实时交互。
但单元测试直接炸了。Claude 的代码在 Netty pipeline 中使用了 多个 WebSocketServerProtocolHandler——这是不可能的，因为 Netty 只允许出现一次。我提示它修复，但情况愈演愈烈：代码被回滚、又加入抽象层、测试仍然失败。
真正的致命点是：测试没有在握手之前等待 channel 写入完成。日志显示了 async 不匹配。Claude 在没有运行代码的情况下耗尽了我的上下文窗口，未能发现这个问题。
教训： AI 擅长生成样板代码，却缺乏运行时的自省能力。快速的本地构建和丰富的日志是必不可少的。修复后，MCP 的核心功能运行得非常顺畅，Claude 能够无缝编译 Adama 代码片段。
教学 Adama：构建时间与上下文丢失
接下来，我让 Claude 重写 Adama 文档并生成示例。我的新 Markdown‑to‑site 引擎报告编译成功：第一次通过率 80 %，并从源码自动优化。
但 monorepo 的完整构建需要 10 分钟——对人类 IDE 通过单元测试进行探索还算可以，但对 AI 的迭代来说致命。Claude 在处理部分特性（例如未完成的类型系统）时失控，因为它没有完整的上下文。
教训： 为 AI 镜像你的 IDE。优化构建速度，为编译错误添加文档提示。使用 “主线 + 实验” 的摘要进行提示，以模拟团队交接。先发布 > 再实验。
大规模重构：上下文溢出
Adama 的类型系统非常密集——即使是精简的提示也会在转录时产生幻觉。超过 1 万个 token 后，输出仍然是破碎的。AI 在没有专门“代理”的情况下难以完成全语言的重构。
教训： 将任务拆分为微任务。把提示组织成类似组织结构图的形式：为子系统配备专职的“专家”。开发者们，这将是你们的新技能——像管理分布式团队一样管理 AI。
让 AI 受控：可操作的要点
只有在你强制执行以下条件时，AI 才能真正加速开发：
- 快速反馈循环： 子分钟级的构建/测试。
- 丰富信号： 日志、错误即文档。
- 范围限定的提示： 不要一次性塞入巨型提示，合理分块。
- 人工监督： 审查所有输出。
巨大的收获包括：完整的文档生成器、用于 AI 自我改进的 MCP、80 % 的编译成功率。但调试把我从梦中惊醒——AI 并非魔法，它只是一个被强化的初级开发者。
试用 Adama 并给 adama‑core 点星，以支持有状态的开发工具。你最糟糕的 AI 调试故事是什么？