我完全同意，我认为LLM工具可能会成为推动小团队采用一些最佳团队/组织实践的动力，而这些实践之前可能无法得到合理化。

我认为如果有几百名工程师却没有代码检查工具，那你简直是疯了。然而，如果你只有两到四名工程师，可能就永远无法激发出那种动力，反而会在编码风格上进行无谓的争论。 但如果加入了Claude Code，a) 你会想要那个代码检查工具。

b) 设置这个 linter 现在只需五分钟的边际提升，而不是“一个人陷入经典的 tarpit 任务中，试图将其与所有 IDE 等集成。”

对于我观众中不知情的部分：linter 是一种自动化工具，可以强制执行比语言可能允许的更严格的编码规范标准。例如，您可以采用一条内部规则，禁止某些特定的法律结构。

例如，在许多语言中，有一个非常简洁的法律表达式，称为三元运算符。 三元运算符因容易导致错误而臭名昭著，工程团队可能会决定，尽管简洁，但从风险调整的角度来看，它们并不是一个可接受的特性。

作为一个可以通过 linter 明智地进行规范的例子，你不想与 Claude Code 进行重复争论的事情：在 Rails 中，something_id 意味着 something 表的外键。 Claude 偶尔会忘记这一点，把许多其他东西称为 ids。

如果你愿意，可以编写一个 linter 规则，每次代码被修改时执行，并向 Claude 和全世界标记： “你命名了一个变量 box_id，但 _ids 仅用于引用数据库键。考虑使用 box_code 或其他名称。”

关于 linter 规则的一件好事是，它们可以内置任意项目特定的知识。 一位日本上班族曾经被迫与（同为）非母语者进行过一次反复的争论，讨论大学网络应用时：你绝对不能使用“subject”。

Why not? Because Japanese universities divide academic subjects into 教科 (kyouka; a subject like “math”) and 科目 (kamoku; a subject like “linear algebra”), and since subsubject is appalling to read in code, these were referred to by romanized Japanese to be always unambiguous.