夜雨聆风AI 能在五分钟内写出一个可运行的插件系统。但它不会在第六分钟告诉你：关闭顺序是随机的、错误被完全静默吞掉了、插件声明的能力和实际实现可能不一致。这些问题不是 AI 不会解决，而是你没问。
1. 一次令人尴尬的评估
今天早些时候，我让 AI 帮我评估 dmr-devkit/plugin/ 的设计质量。当时我只说了一句话：
"评估一下 plugin 的设计如何？"
AI 的回复很快，结构得体：
优点一、二、三 缺点一、二、三
看起来正常。但细读之后，我发现 AI 的"缺点"部分有一个滑稽的潜台词：
"插件数量通常不多，这可以接受" "这是一个成功的重构"
简单说，AI 在用可接受来掩饰问题。它不是看不到 map 遍历是随机的，它是看到了但决定"不提"——因为我只说了"评估"，没说"用生产级标准评估"。
这是 AI 的本质局限：它会通过给出一个你可以接受的答案，而不是一个它认为最好的答案。
2. 我的追问，才是真正的设计
确认了问题后，我给出了第二个指令：
"按照你检查出的问题优化改进"
这个指令的重要性不在于"优化”两个字，而在于我确认了这些问题是问题。AI 第一轮的回答其实是在"试探”——看看这个人是只想听好话，还是想听真话。当我确认了"这些是问题请修”之后，AI 才真正动起来。
然后有意思的事情发生了：
AI 修的比它初始实现的要好得多。
它为 Registry 加了 insertion order，让 ShutdownAll 真正按反序关闭。它加了 capability 索引，让查询从 O(n) 变成了常数时间。它用 errors.Join 替代了字符串拼接，让错误变得可编程化。它还给 RegistryHooks 加了 ErrorHandler，让静默的错误变得可观测。
这些改进是 AI 不能做吗？当然能。AI 在很多单元测试和安全标准上都表现得很好。那为什么第一轮没做？
因为我没要求。
3. 为什么 AI 不会主动给你最好的？
这不是 AI 的算法缺陷，而是需求的自然溢出效应。
当你说"写一个插件系统"时，AI 的优化目标是：满足这个需求的同时，减少实现复杂度。它的默认逻辑是保守的：每多一个特性（按顺序关闭、索引、错误处理规范），实现就更复杂一分。如果你没有明确说"这些是必需的"，AI 的量子就会谐振在"简单" 一侧。
换句话说，AI 的输出响应了你的标准。
你只关心功能能不能用，AI 给你一个能跑的版本 你关心可靠性，AI 给你加错误处理和测试 你关心安全，AI 给你加路径校验、注入防护、策略审查 你关心可维护性，AI 给你加接口分离、生命周期管理、索引结构
你的追求决定了 AI 的上限。
4. 回到今天的案例
让我们看看今天的 plugin 系统如果没有那些"额外"的追求，会是什么样子：
场景：生产环境中的关闭
如果 ShutdownAll 依然是 map 随机遍历，一个依赖 PostgreSQL 后端的日志插件可能会在 PostgreSQL 插件之前被关闭。接下来的日志写入会失败，但这个失败不会触发任何报警——因为 ErrorHandler 也没有。
这不是构想中的"灰色故障"，这是一个可复现的 bug。只要你的环境有多个插件，它就一定会在某个时刻触发。
场景：安全审查被绕过
如果 BeforeToolCall 某个策略插件报错了，错误是否被处理得当？errors.Join 的区别是：调用方可以用 errors.Is 判断是哪个插件报的错，从而决定是重试还是记录日志。如果错误被字符串化了，这些决策就做不了。
这是安全运营和"运行了就行"之间的差距。
场景：能力声明与实现不一致
一个新开发的插件声明了 CapTools 但忘了实现 ListTools 方法。没有 ValidateCapabilities 的情况下，这个插件会静默注册成功，然后在运行时发现没有工具。开发者会花多少时间 debug？可能半小时，可能两小时。
这些问题都不是"功能缺失"。它们都在运行时表现得很好。它们是质量缺失——一种不会在 demo 中暴露，但会在生产环境中慢慢薙螠的问题。
5. 为什么安全和质量不会"自然发生"？
有一种幻觉是：我只要提出功能需求，AI 就会自然地拿出安全、可靠、高性能的方案。
事实上不会。原因很简单：安全和质量是后果，不是功能。
功能是"这个系统能做什么" 质量是"这个系统在边界情况下会怎么表现" 安全是"如果一个恶意的输入进来了，系统会怎么回应"
AI 不知道你的业务是在开发 demo 还是开发金融系统。它不知道你的数据有多敏感。它也不知道你的团队有多少人会在半年后维护这段代码。
这些信息只有你有，AI 没有。你必须主动把这些非功能性约束表达出来。
6. 如何向 AI 提出质量要求
今天的经验可以总结成一个简单的套路：
第一步：不要只问"怎么做"，要问"做的质量怎么样"
第二步：主动检查 AI 的"可以接受"
AI 的输出里如果有这些词，要提警：
"这是可以接受的" "通常不会发生" "简化版本已足够" "可以在未来优化"
这些都是 AI 在说："我给你一个最小可行方案，因为你没有让我做更多。"
第三步：强迫深度检查
对于关键系统，可以用这些问题追问 AI：
并发安全：这个设计在多 goroutine 同时访问时有什么风险？ 资源泄漏：有没有情况下 goroutine、文件句柄、连接池不会被释放？ 错误处理：每个 error 都被正确地 wrap、传播、聚合了吗？有没有被静默吞掉的？ 边界情况：空输入、空集、极大值、极小值会怎么样？ 安全：用户输入能否造成注入、遍历、资源耗尽？ 可维护性：六个月后的你能看懂这段代码吗？新手能够安全地修改它吗？
7. 什么才是 AI 的正确使用姿势
这次 plugin 重构让我重新思考了 AI 辅助编程的本质。AI 不是替代程序员做判断的，而是放大程序员的判断力。
如果程序员没有安全意识，AI 帮他快速写出一个有漏洞的系统 如果程序员没有质量追求，AI 帮他快速写出一个"能跑"但不"稳定"的系统 如果程序员没有架构视角，AI 帮他快速写出一个"功能完备"但不"可维护"的系统
AI 是一面镜子，照出的是你自己的标准。
今天的代码评估，如果我只是随便看看，然后说"不错，没问题"，那么这个 plugin 系统会带着六个隐患进入生产环境。但因为我看了细节、找了问题、强迫 AI 修复了每一处，最终产出的代码才达到了可信赖的水平。
这不是 AI 的强大——这是人类追求质量的意志力，借助了 AI 的执行力。
8. 结语
如果只能说一句话，这篇文章的观点是：
AI 的代码质量天花板，是你的追求，而不是 AI 的能力上限。
当 AI 给出一个"可以用"的版本时，别急着接受。问问自己：
如果这是我最佩服的同事写的代码，我会在 code review 中开具什么？ 如果这个系统明天就上线，我能不能睡着觉？ 如果六个月后的我回来看这段代码，我会不会觉得美好？
如果答案都是"是"，那这就是你该对 AI 提出的质量标准。把这些标准告诉 AI，它会让你惊讶。
因为人是检查的提出者，AI 是检查的执行者。没有人的要求，就没有 AI 的高质量。
相关资源
dmr-devkit 代码审查 Skill dmr-devkit 插件系统源码
