我完全同意，我認為 LLM 工具可能會成為推動小型團隊採用一些最佳團隊/組織實踐的力量，這些小型團隊之前可能無法證明這些做法的合理性。

我認為如果有幾百名工程師卻沒有使用 linter，那你真是瘋了。然而，如果你只有兩到四名工程師，或許就永遠無法達到啟動能量，並且大多數時間都在為編碼風格進行無效的爭論。 但如果加入 Claude Code，a) 你會想要那個 linter。

b) 設定那個 linter 現在只需五分鐘的邊際提升，而不是「一個人陷入經典的泥潭任務，將其整合到所有的 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.