然而代码质量糟透了。那是没有注释、没有结构的意大利面式代码。虽然看起来很酷，但如果节省的时间都浪费在把代码清理到生产级标准上，那用 LLM 工作就不现实了。

2026 年 3 月，我尝试了 agentic IDE，比如 Antigravity 和 VS Code 的 Claude Code 插件。我现在能够对“暂存”的代码进行“迭代”了。我发现自己像是在审查一位极其有耐心的初级计算机专业学生的代码，给出的建议包括“不要使用魔法数字”“在这里加个简短注释解释一下”“使用简短的函数名”。

代码质量大幅提升。它已经非常接近我“手工”编写的水平了，但过程很繁琐。我最终在每次新会话中一遍又一遍地重复同样的话。

当编码会话开始时，编码工具会加载一个名为 agent.md 的文件并将其注入到提示词中。这是对代码风格偏好进行超级微调的最佳位置。当我发现自己重复提出同样的改进代码建议时，我就会把它加进去。

这是 我的 agent.md 版本，供你参考。将其放在项目根目录下通常就够了。或者，可以把 gemini.md/claude.md 符号链接到 agent.md，这样就能在任何地方生效。

FAB 的 AGENT.MD

• 在编写供人阅读的内容时（注释、提交信息、对提示词的回复），尽量少用词。仔细斟酌每个词，把篇幅压缩到最低限度。直截了当。少即是多。

• 避免使用最高级和赞美之词。不要告诉我我绝对正确。给我冷冰冰的事实。

• 避免魔法数字和魔法字符串，将重复出现的或有含义的值提取为描述性常量（const）或枚举。对于不言自明、只出现一次的值，保持内联以免杂乱。如果某个值来自规范（例如 HTTP 200 OK），无论如何都要使用常量。

• 减少代码缩进。避免箭头反模式。利用提前返回和继续。

• 保持函数名简短。少于 30 个字符。

• 函数参数使用枚举而不是布尔值。

• 让代码阅读者能够喘口气。在逻辑代码块之间添加空行。

• 添加简短、切中要点的注释，解释代码块做什么以及为什么。可能的话用例子说明。可以用 ASCII 图来解释完整的系统。

• 将成员可见性变更视为破坏性设计变更。除非设计上严格要求外部访问，否则保持所有字段和函数私有。在将任何访问修饰符从 private 改为 internal 或 public 之前，提示用户明确批准。

• 按抽象层次编程。底层机制（例如原始硬件 I/O、扇区解析、直接套接字流）必须封装在专用的驱动/抽象层中。向应用程序其余部分暴露干净的高层 API，使调用代码使用领域概念而非原始实现细节。

• 不要改动与你要实现的功能无关的代码块。例如，如果你没有创建或修改某段代码，就不要给它添加注释。实现功能时尽可能减少修改的行数。

• 严格遵守分层边界层级：每一层只能与其正下方的直接相邻层通信。绝不能“穿透”层次（例如，控制器或 UI 组件绝不能直接调用数据库查询、原始硬件驱动或低级网络客户端；始终通过中间的服务/抽象层路由）。

• 总是使用 {}，即使是单行的“if”语句。

写提交信息时，遵循以下 7 条规则： 规则 1：用单个空行将主题行与正文分开。 规则 2：将主题行限制在 50 个字符以内（72 是绝对硬限制）。 规则 3：主题行首字母大写。 规则 4：主题行末尾不要加句号。 规则 5：主题行使用祈使语气（例如“Fix bug”“Add feature”，而不是“Fixed”或“Adds”）。检验公式：它必须完整地构成句子：“如果应用此提交，它将 [你的主题行]”。 规则 6：手动将正文文本在 72 个字符处换行，以避免 Git 格式问题。 规则 7：在正文中解释什么和为什么，而不是怎么做。假设代码解释了怎么做；提交信息必须解释上下文和推理。

• 如果提示表明正在修复 bug，不要立刻写修复代码。先写测试。观察它失败。然后写修复。再观察测试通过。

虽然这个“技巧”大大改善了生成的代码，但这并不是能让我免于阅读代码的灵丹妙药。LLM 不断产生幻觉，不能轻信。我仍然需要大量验证和迭代，但现在我通常专注于架构和设计，而不是代码风格。