在禁AI的开源社区里“装傻”，反而成了我进阶开发者的捷径

最近在参与一个开源游戏开发工具链项目，这个项目的复杂度极其离谱，代码库里混杂了多种编程语言，逻辑链路深得让人绝望。在进入这个项目之前，我面对这种跨语言的调用栈几乎处于“失明”状态，想要提交一个像样的 PR（Pull Request）简直是天方夜谭。

但到了 2026 年，大模型的工程能力已经进化到了一个恐怖的程度。现在的 LLM 不仅能无缝切换语言，最强的地方在于它能通过调试追踪（Debug Trace）精准定位 Bug 在每一层传递时的状态，甚至能自动生成复现测试用例，然后直接给出修复补丁。在这种效率面前，原本需要啃一周的文档，现在几秒钟就能理清楚。

然而，这个社区有一个非常硬核的文化：他们明令禁止直接提交 LLM 生成的代码。这意味着如果你提交的代码带有明显的“AI 味”——比如过于完美的对齐、毫无个性的标准注释，或者那种典型的 LLM 冗余表达——你的 PR 极大概率会被维护者直接 Close 掉。

为了能把代码合入，我采取了一个看似“不诚实”的策略：假装这些代码全是我手写的。

但为了圆这个谎，我被迫进入了一种极高强度的学习模式。我不能直接 Copy-Paste，因为一旦被问到某个逻辑细节我答不上来，这个谎就穿帮了。于是我的工作流变成了：先让 LLM 详细解释修复思路 → 将生成的代码逐行审查 → 检查是否符合项目既有的编码风格 → 手动修改注释措辞 → 完全手写提交信息（Commit Message）和 PR 描述。

在这个过程中，我发现了一个反直觉的现象：这种“伪装”过程，竟然比直接使用 AI 效率更高，且学习效果好得多。

因为我知道这段代码一旦合入，我就成了它的唯一责任人。为了确保在 Review 阶段不露馅，我必须强迫自己理解 LLM 为什么这么写，以及它是否在某些边缘 case 上产生了幻觉。这种“必须能交代”的压力，逼着我把那些复杂的工具链内部机制给啃了下来，这种理解深度远超之前盲目阅读文档的阶段。

如果我图省事，让 AI 把 PR 描述也一起写了，我大概率会陷入一种“认知错觉”——以为自己懂了，其实只是 AI 帮我总结了。而现在，我坚持在提交前重新组织语言，用自己的话把“代码为什么这么改”写清楚。我发现，如果一个设计方案我无法用自己的话讲清楚，那么即便代码运行通过了，我也并没有真正吃透它。

现在回看，这种“假装不用 AI”的克制，实际上是在构建一个人工的反馈闭环。AI 提供了极速的答案，而“伪装”过程则提供了必要的反思时间。

这种经验给我的启发是：在 AI 时代，真正的竞争力不再是你能否通过 Prompt 得到答案，而是在于你是否具备“审计”这个答案的能力。当你把 LLM 当成一个需要你审核的初级程序员，而不是一个直接给出结果的黑盒时，你的成长速度才会真正加快。