毫秒级反馈：静态分析与代码规范

Agent 写下一行代码，最快能多久知道这行代码有没有问题？

如果答案是"等测试跑完"，那可能是几秒到几分钟。但有一类问题根本不需要等测试：类型不匹配、未使用的变量、格式不一致、导入缺失。这些问题 linter 和类型检查器在代码写下的瞬间就能捕获，反馈延迟接近零。

对人类程序员来说，linter 是"锦上添花"的工具，没有它也能写代码，只是体验差一点。对 Agent 来说，linter 是成本最低的反馈通道。Agent 每次执行一个工具调用就消耗 token，如果一个类型错误要等到跑完整个测试套件才发现，中间可能已经基于错误的假设写了十几个函数。linter 在源头拦截这类问题，直接缩短了偏差的存活时间。

实践中需要注意几个配置原则。

规则要写进代码库，不要依赖开发者本地环境的配置。.eslintrc、pyproject.toml、rustfmt.toml 这些文件必须存在于仓库中，Agent 拿到代码库就能直接使用，不需要任何额外设置。如果 linter 配置散落在各个开发者的 IDE 里，Agent 根本看不到这些约束。

规则要严格但稳定。频繁变动的 lint 规则会产生噪音：Agent 上一轮循环通过的代码，下一轮因为规则变了突然报错，它无法区分这是自己的问题还是环境的问题。规则一旦确定，不要在 Agent 工作期间调整。

formatter 应该自动执行而非提示执行。Agent 不需要被告知"你的缩进不对"，它需要的是 prettier --write 或 gofmt 直接把格式修好。把格式化从"反馈"变成"自动修复"，减少一轮不必要的循环。

最后，静态分析的价值在 Agent 时代发生了一个微妙的变化。过去关于代码风格的争论（tab vs space、命名规范、行长度限制）很大程度上是关于人类可读性的。当代码越来越多地由 Agent 生成、由 Agent 消费时，"代码是否对人类美观"这个维度的重要性在下降，而"代码是否对机器一致"的重要性在上升。高内聚低耦合这类结构原则依然重要，但命名风格之类的审美规则，其价值主要在于保持代码库的一致性，而非取悦某个人类读者。