在 RobustMQ 中我和 AI 是如何协作的
开发 RobustMQ 这一年多，AI 辅助编程成为了我工作流程的重要部分。坦白说，AI 给我的编码效率带来了很大的提升，我建议每个开发者都尝试使用。但使用过程中我也发现，需要把握好边界，建立自己的使用方式。接下来想和大家分享一下我的一些经验和感悟。
我的协作方式
我和 AI 的协作模式可能和很多人不太一样。我不是让 AI 帮我写代码，而是让它帮我检查代码。
具体来说，当我要实现一个新功能时，会先花时间思考设计。梳理清楚模块的结构、接口的定义、数据流的走向。然后开始写代码，从核心的数据结构开始，逐步实现主要的方法和逻辑。这个过程完全是我自己在写，AI 不参与。
写完后，我会把代码给 AI，让它检查潜在的问题。AI 会指出逻辑错误、边界条件遗漏、错误处理不当、可能的性能隐患。这些反馈通常很有价值，能发现我容易忽略的细节。比如某个函数可能返回 None 但我没处理，某个边界条件下会 panic，某个资源没有正确释放。
看完 AI 的反馈后，复杂的逻辑问题我会自己分析和修复，简单的语法或风格问题可以让 AI 直接处理。这个分工对我来说很自然：需要理解设计意图的问题我负责，机械性的修复工作 AI 负责。
为什么不让 AI 写核心代码
刚开始用 AI 时，我也尝试过让它帮我写一些功能模块。但很快发现，AI 写出来的代码我都不太满意。不是说功能不对，而是代码冗余、逻辑啰嗦、不符合我的设计意图。
这个问题的根源我后来想明白了。AI 只能看到我给它的上下文，看不到我脑子里的完整架构。它写出的代码可能功能正确，但和其他模块配合得不好，抽象层次不一致，命名风格也不统一。更关键的是，它不理解我对这个项目的长期规划，写出的代码可能会阻碍未来的扩展。
在 Rust 中这个问题更明显。AI 写 Rust 代码时，经常到处 clone、到处 Arc<Mutex>、到处 unwrap_or_default。它不太理解 Rust 的 ownership 语义，只是用最保险的方式让代码编译通过。但这不是好的 Rust 代码。好的 Rust 代码应该利用类型系统和所有权模型，做到零成本抽象。
RobustMQ 的存储引擎、并发控制、offset 管理这些核心模块，我需要的是极致的简洁和性能。每一行代码都要有明确的意义，每一个抽象都要有清晰的价值。AI 生成的代码达不到这个标准，而且这些核心代码会被反复修改优化，如果一开始就是我看不懂的 AI 代码，后期维护会很痛苦。
所以我选择了核心代码必须自己写。这不只是保持编码能力的问题，更重要的是保证项目的长期可维护性。
测试用例的处理
测试用例是 AI 帮助最大的地方。写完核心代码后，我会让 AI 生成测试。AI 生成的测试通常很全面，覆盖了很多场景，能快速建立基础的测试覆盖。
但 AI 的测试有个毛病：太啰嗦了。它可能为每个小细节都写一个单独的测试，结果测试代码比实现代码还长。我经常要告诉它"简洁点，简洁点"，但效果有限。所以通常我会在它生成的基础上做删减，保留必要的测试，删掉重复的部分。
更重要的是，我会检查 AI 是否遗漏了关键场景。比如并发安全、极端边界条件、异常恢复，这些场景 AI 经常想不全。我会根据对系统的理解，手动补充这些测试。对于存储层、并发控制这些核心模块，我会特别仔细地检查测试是否覆盖了所有重要场景。
有时候我会用个小技巧：让一个模型生成测试，让另一个模型 review。两个模型互相检查，能发现一些明显的遗漏。但我清楚这只是辅助手段，关键测试还是要自己把关。对测试用例的 review，我投入的时间确实比对实现代码少，但不代表我不重视。关键场景的测试，我会认真检查。
实际效果
这种协作方式让我的开发效率提升了很多。AI 承担了大量重复性的检查工作，我可以专注于设计和核心实现。写完代码立即检查、立即修复、立即测试，这个快速反馈循环让 bug 很少能逃过早期阶段。
更让我满意的是代码质量。因为核心都是我自己写的，代码风格统一，逻辑清晰，我随时能理解和修改。因为有 AI 帮忙检查细节，实现的可靠性也很高。到目前为止，RobustMQ 的核心模块基本上短时间内看不出 bug。
这个过程中，AI 指出问题、我分析修复的循环，实际上也在持续提升我的编码能力。我会发现自己容易犯什么错误、什么场景容易遗漏，然后在下次写代码时主动避免。这种学习效果，比单纯让 AI 写代码要好得多。
我的一些原则
用了这么久 AI，我给自己定了一些原则。
架构和设计，绝对自己做。这是项目的灵魂，不能交给 AI。我可以把想法讲给 AI 听，让它提问题，但决策必须我自己做。
核心代码，必须自己写。存储层、并发控制、协议实现，这些代码要简洁、高效、可理解。为了开发速度而让 AI 写，会在未来付出代价。
检查和测试，AI 可以大量参与。但我会 review，特别是关键场景。AI 可以提高效率，但不能替代我的判断。
对 AI 的建议，保持独立思考。AI 指出的问题不一定都是真问题，它的修复方案也不一定是最优的。我需要理解每个问题的本质，然后决定是否接受建议、如何修复。
一些感悟
AI 是个很强大的工具，但它是工具，不是合作伙伴。工具的价值在于帮你更高效地完成工作，而不是替你做决策。
我发现很多人用 AI 时，容易陷入两个极端。一种是完全不用，觉得"AI 写的代码不靠谱"。另一种是过度依赖，让 AI 写大段代码甚至整个模块。前者错过了提高效率的机会，后者会损害代码质量和自己的能力。
我的方式在中间：核心自己掌控，细节让 AI 辅助。这个平衡点对我来说刚刚好。我保持了对代码的理解和控制，同时利用了 AI 的检查效率。
对于开发基础设施软件的人，我想说的是：不要指望 AI 能帮你写出高质量的核心代码。AI 可以写出"能用"的代码，但基础设施需要的是"优雅"的代码。这个差距需要人的深度思考和反复打磨才能弥补。
但也不要排斥 AI。用对了地方，它确实能显著提高效率。检查逻辑、生成测试、修复简单问题，这些都是 AI 的强项。关键是找到合适的边界，让 AI 做它擅长的事，你做你擅长的事。
RobustMQ 的一个目标是代码质量追上 Kafka，这需要时间，也需要代码质量的积累。我选择的方式是：坚持核心代码自己写，保持简洁精炼的标准，利用 AI 提高检查和测试的效率。这个方式到目前为止效果不错，我会继续坚持下去。
工具要为人服务，而不是相反。这是我在 AI 辅助编程中最深的体会。