GPT 写代码不爱写注释，写前端怎么这么啰嗦？教你治好它

最近在搞 AI 辅助开发的时候，不知道大家有没有发现一个特别扎心的现象：

GPT 在写后端代码时惜字如金，注释少得可怜；一转头让它写前端页面，它那“废话文学”的DNA就动了。

具体表现就是那个万年不变的公式：页面左上角一定要给你整一个一级超大标题（H1），紧接着下面必须跟一行说明性的小注释。无论是早期的 3.5，还是后来的 4.0，哪怕是现在的 5.6 本，这个毛病似乎只是标题变小了点，那个“爱解释”的习惯依然稳如泰山。

典型的 AI 生成页面：左上角 H1 标题搭配解释性小注释，这种固定的模式困扰着很多开发者。

对于我们追求极简主义或者直接套用组件库的开发者来说，这种代码简直就是“屎山”的开端。每次生成完都得手动去删这些多余的文本节点，或者去调整样式，实在让人上头。

为什么 AI 这么爱“加戏”？

其实这不能全怪模型。从大模型的训练原理来看，它本质上是在做“完形填空”。在它的训练数据里，绝大多数的 Demo 页面、教学案例或者 UI 原型，为了展示清晰，都会配上显眼的标题和说明文字。

当模型收到“生成一个登录页”或“写一个设置面板”的指令时，它预测出的“最完美”答案，自然就是带着标题和说明的那个标准模板。它觉得这是在帮你完善用户体验，而在我们看来，这是在往项目里塞垃圾代码。

引入独立子 Agent 进行质检的工程化流程：静态扫描与规则审计相结合，将“废话文学”扼杀在摇篮里。

怎么治？工程化手段来压制

既然知道这是模型的一种“人格特性”，光靠 Prompt（提示词）去磨它，效果往往时好时坏。我们需要更硬核的工程化手段来约束它。

方案一：引入“独立子 Agent”做质检

如果你的工作流离不开 GPT/Codex 这种模型，那就不要指望它一次性能写对。

我们可以构建一个“独立子 Agent”，它的任务不是写代码，而是专门找茬。当主 Agent 生成完前端代码后，这个子 Agent 会介入工作：

1. 静态扫描：检查代码中是否存在静态文本的 H1 标签或特定的注释类元素。
2. 规则审计：配合 CLI 工具，在编译甚至生成阶段直接报错或发出警告。比如配置 Eslint 规则或者自定义脚本，一旦检测到非组件化的硬编码文本，直接驳回重写。

就像给代码配了个严厉的 Code Review 导师，哪怕它是 GPT 生成的，不符合规范也得改。

方案二：术业有专攻，换个模型做前端

这就好比你不会让做后端的去切复杂的 UI 图一样，选对模型非常重要。

有些模型在逻辑推理上是强者，但在设计感和“克制”上就差了点火候。实践发现，如果你把前端任务交给 GLM、Opus 或者 Fable 等这些对界面设计更有感觉的模型，效果会好很多。

这些模型在生成 UI 时，往往更倾向于使用组件化的思维，而不是堆砌文本。它们生成的代码结构更清晰，更符合现代前端框架（如 React、Vue组件库）的最佳实践，直接能省去大半后续修改的工作量。

总结

GPT 的“注释人格”是训练数据带来的惯性，靠嘴劝是劝不住的。要么用一套强硬的自动化审计流程把它“管”住，要么干脆换个更懂审美的模型来干前端的活。

毕竟，我们的目标是优雅的代码，而不是让 AI 在页面上写日记。