AI Code Reviewer

编辑器插件通常基于本地规则和静态分析，检查的是格式、语法和部分已知缺陷模式，规则明确、可预期。这类在线工具走的是模型判断，会给出一段话的解释和修改方向，更适用于逻辑层面的建议。两者可以叠加使用：插件负责风格与语法，它负责逻辑自查。

只提交一个函数时，模型看不到调用方和数据来源，给出的建议容易停留在表面。把自己关心的调用逻辑、相关数据结构和输入来源一并贴上，得到的意见通常更贴近实际问题。改动较大时，建议拆成几段分别提交，而不是一次性全部丢进去。

不建议全部照搬。判断依据只有提交上去的那段内容，可能不掌握项目里的约定、依赖版本和运行前提，因此会给出在实际工程里并不适用的改法。合理的做法是逐条看，能复现的才改，拿不准的先用测试验证，再决定是否采纳。

这属于合规问题，需要先确认所在公司对代码外发的规定。把代码提交到第三方在线服务，意味着内容会离开本地环境，涉及商业机密或客户数据的项目尤其要谨慎。若规定不允许，就不要用它处理这类代码。

不适合作为最终关卡。它只能给出基于所提交内容的建议，无法覆盖运行时行为、依赖变更和实际业务场景，真正的把关要靠测试用例、代码评审和发布流程。把它放在提交前那一步做基础过滤，才是比较合适的用法。

当问题出在架构设计、并发时序、性能瓶颈或与外部系统的交互上时，片段级的审查很难给出有效判断，因为这些结论需要完整的上下文和实际运行数据。这类问题仍然要靠评审讨论、压测和线上观测来定位。