我停止审查代码：后端开发者对 Google Gemini 的实验
Source: Dev.to
请提供您希望翻译的完整文本（除代码块和 URL 之外），我将把它翻译成简体中文并保留原始的格式和 markdown 语法。谢谢！
使用 Google Gemini 构建：写作挑战
Overview
🦄 我已经正式对 AI 产生了近一年的痴迷。这种痴迷既不是出于机器学习研究的角度，也不是从纯粹实现的立场出发。对我而言，刺激来自于作为用户去发现其极限，然后不断压榨，直到出现突破。Hunter S. Thompson 的一句名言提到“尽可能把它推到极限”，这一直是我全年遵循的操作原则。
这个项目最初是一次作品集实验。它却演变成了完全不同的东西。挑战在于，它成为了我迄今为止找到的最干净的环境，用来测试当你脱离实现循环，让模型自行构建世界时到底会发生什么。
我用 Google Gemini 构建的内容
当我看到 New Year, New You 投资组合挑战时，我知道它需要一个 UI。这并不令人惊讶。令人惊讶的是，我很快意识到，一旦它开始成形，我根本不明白自己在看什么。
我是一名后端开发者。给我一个分布式系统的问题，我会乐意花上数小时去理清。要我让浏览器中的 div 可见，我的大脑立刻就想找出口。只有一个周末的时间来构建，根本没有“眼睛划过去”阶段的余地。Google Gemini 将负责实现，我负责监督——这就是我的全部计划。
我以为 Antigravity（主要由 Gemini Pro 提供动力）会像我测试过的所有其他 AI 系统一样——可预测且相对容易在防护栏内控制。我以为我已经知道那些防护栏的样子：严格的类型、代码检查，以及熟悉的代码审查流程。
转折点：放弃代码审查仪式
起初，我遵循“负责任”的模式：提示、审查差异、运行测试、批准。感觉很有纪律性，也显得专业。
很快我意识到，在前端技术栈中，我对所审查的内容几乎没有任何有意义的上下文。我并没有提升产出，只是在参与仪式。因此，我彻底停止了代码审查。
与其验证代码行，我验证的是结果。只要 UI 正确渲染并通过功能测试，就算成功。我提升了自主性，教会 Antigravity 我的仓库期望，并让它自行运行。Copilot 代替我审查代码，Gemini 在闭环中作出响应。我从实现层面抽身，转而担任系统审计员的角色。
演示
本作品集迭代记录了在一个定义好的系统中释放代理后会发生的情况。
在此构建中，Antigravity 面板是主要的交互界面。我在其中定义了仓库规则和测试期望，Gemini 直接在该结构内实现。它成为整个循环的控制面板。
- V1 发行版: Preserved version v1.1.0
- 实时作品集: (原文中省略链接)
Replacing Trust With Systems
我并没有仅仅去掉监督；我用 Lighthouse 审计和扩展的测试覆盖来取代它。我的假设很简单：如果浏览器表现正常且测试通过，代码就是“安全”的。我以为我已经把对代码的信任换成了对系统的信任。但我错了——我把测试通过误认为是结构完整性。
我学到的
高级推理不是可选项
对于自主开发来说，推理深度是一个稳定性要求。使用低推理模式（例如 Flash）时，修改往往不完整——更新了三分之二的文件，却“忘记”了测试或文档。
切换到 Gemini Pro 的 High Reasoning 模式后，情况发生了改变。运行时错误减少，跨文件的一致性提升。Gemini 终于开始“记住”在代码变更时同步更新文档，而不需要不断提醒。
推理深度并不是单纯的智能水平——它关系到在自主环境下的可靠性。Gemini 更深的推理能力和上下文保持让闭环工作流变得可行；没有它，跨文件的一致性在自主运行时很快就会崩溃。
现实检验：Sonar
在成功构建的兴奋情绪消退后，我引入 Sonar 进行事后审计。UI 正常渲染，测试通过，一切看起来都很稳定。
Sonar 报告了 13 项可靠性问题，并给项目评定了 C 级可靠性评级。 其中 66 % 被归类为高严重性。安全审查发现了三个热点，包括一个以 root 身份运行默认 Python 镜像的容器，以及未固定完整提交 SHA 的依赖引用。
可维护性得分为 A，但仍存在 70 条可维护性问题——这些结构性模式虽未破坏行为，却增加了长期复杂度。
那一刻，信心转变为审视。
应用可以运行，测试通过。但可靠性、安全姿态和结构完整性却讲述了另一番故事。测试验证了行为；Sonar 验证了假设。而这两者并不相同。
# Son?
**AI 生成的测试可能会通过，因为它们是为满足实现而编写的，而不是去挑战实现。**
结构化验证需要在生成循环之外的独立审查层。Google Gemini 反馈
有哪些做得好的地方
- Cohesive Implementation: 高推理 Gemini Pro 产生了跨文件的更改，尊重了仓库的意图。
- Agentic Orchestration: 模型切换无缝，编排界面使得能够清晰定义期望并始终如一地强制执行。
出现摩擦的地方
- Cooldown Transparency: 虽然界面显示当前积分何时刷新，但下一个冷却时间的长度仍是未知。
- Tool Performance: MCP 的响应速度显著影响迭代速度，有时迫使我批量请求，而不是进行小幅、快速的增量工作。
💡 Pro Tip: 如果能在模型页面直接看到下一个冷却的确切时长（例如 “你的下一个冷却将持续 X 小时”），将是巨大的用户体验提升。了解锁定是 1 小时还是 96 小时对开发者规划至关重要。
最终结论：自主仍需审计
这次的教训并不是 Gemini 失败了；而是系统层面的信任需要的远不止通过测试。未来的版本中，自治功能在没有明确的对抗性审计之前是不会上线的。无论这意味着必须通过 Sonar 检查、红队提示通过，还是让第二个高推理模型被指示去寻找第一个模型的捷径——这个循环必须受到挑战。
该项目最初是一次周末实验，旨在摆脱前端开发的“瞬移”雾霾。最终却演变成对系统层面信任细线的探索。真正的成果并不是作品集，而是发现当你不断逼迫 AI 的极限直至它们崩溃时会发生什么。
把自己从实现环节中抽离并没有消除责任；而是重新定义了责任。赋予代理越多的自由，就必须对审计越严谨。
🛡️ 幕后工具
这篇文章由我酿造——加入了一点 Google Gemini 和一点 ChatGPT。如果你发现偏见或错误，请指出来。人工智能并不完美，我也一样。