像会被人类维护的方式写代码

注释、命名与可读性

• 许多人更偏好少量注释和清晰命名，而不是大量注释。
• 那些冗余的“解释代码做了什么”的注释被视为噪音，而且很可能会过时；注释应该解释“为什么”，而不是“是什么”或“框架如何工作”。
• 有些人倡导类似文艺编程的工作流（先写散文/意图，再写代码），但也承认这往往会退化成重复复述代码。
• 共识是：好的命名、简单的结构，以及偶尔的“此处有龙 / 设计理由”注释最理想。

LLM 生成的注释与风格

• 人们强烈不满 LLM 产出冗长、低价值的注释、历史笔记，以及有关实现过程的闲话。
• 模型常常会描述语言基础、周边代码的怪癖，或调用方行为，破坏封装，并且很快过时。
• 通过 CLAUDE.md / AGENTS.md 规则来约束这一点有一定帮助，但执行并不稳定；负向指令（“不要做 X”）尤其不可靠。

AI 的生产力与可维护性

• 有些人声称，只要先把能通过测试的东西发出去，让 AI “以后再处理烂摊子”，就能实现 10 倍的功能/修 bug 吞吐量。
• 也有人警告，这种糟糕代码会不断累积：重复逻辑、分叉的业务规则，以及层层嵌套的防御性设计，会让未来的 AI 和人类工作都更慢、更危险。
• 大家争论的是，短期速度是否会被长期复杂性抵消，尤其是在大型代码库中。

提示词、检查清单与审查流程

• 许多人使用项目级 CLAUDE.md / AGENTS.md，再配合显式的“/review”命令和长检查清单（DRY、风格、重复、死代码、测试、文档）。
• 有些人会把审查拆成多个专门的流程（安全、可访问性、性能、简化），甚至进行多模型对抗式审查。
• 另一些人则表示，随着指令列表变长，收益会递减；模型仍然会忽略基本规则（例如 git 的使用），因此需要系统级护栏。

传统工具与护栏

• 静态分析器、linter、代码格式化器、重复检测器，以及 pre-commit/CI 检查，被广泛推荐为非随机的基线。
• 有些人会编写自定义 linter 或编译器级检查，以强制执行 LLM 经常违反的规则（不允许魔法数字、不允许动态导入、文档/测试要求）。

人类与 AI 的角色

• 现在不少开发者主要用 LLM 来做探索、重构和审查，但核心代码仍由人工编写。
• 也有人接受 AI 密集型工作流，承认人类可能不再持有系统的完整心智模型，而是依赖强大的测试夹具和工具链。
• 归根结底，许多人强调：可维护的结构、DRY、以及清晰的抽象仍然重要——无论是对人类，还是对之后读取代码的智能体而言。