acplugins4python实战：打造PyDev自定义代码分析插件

我最初接触acplugins4python这个包时，第一反应是“怎么又是给Python写插件的轮子”，但真在PyDev里做过代码分析插件的人会知道，这个包的价值远不止“方便”两个字——它把Eclipse插件开发里最琐碎、最容易踩坑的AST分析逻辑全部封装好了，你只需要关心“我想检查什么代码规则”，而不是“我怎么在Eclipse里挂一个分析器”。

这篇内容我会围绕acplugins4python的语法、核心参数和实际案例展开，把我在PyDev插件开发过程中实打实用到的东西讲清楚。适合两类人：一类是想给PyDev写自定义代码规范检查插件的开发者，另一类是虽然用不上PyDev但想理解Eclipse插件机制与AST分析如何协作的Python工程师。无论你属于哪一类，下面的内容都能让你少走不少弯路。

1. 先搞清楚acplugins4python到底是个什么角色

1.1 它不是第三方业务框架，而是PyDev扩展开发的基础库

很多人会把acplugins4python误认为是一个独立的第三方Python包，类似requests、numpy那种，装上就能pip import。但这里要先纠正一个认知偏差：acplugins4python是PyDev生态内的一个辅助库，服务对象是那些需要编写自定义代码分析插件的开发者，而且核心代码是Java写的，不是Python写的。这个包本身对应的是一组可以从Eclipse插件工程中引用的JAR包与源码片段，它围绕PyDev的org.python.pydev.ast.analysis系列API提供了一套更友好的封装。

那为什么有人会在纯Python项目里搜到它？因为PyDev是跑在Eclipse里的Python IDE，当你在PyDev中定义自定义的代码分析规则时，需要在Java层实现一个分析器。这个分析器最繁琐的部分不是写规则，而是“拿到AST节点后，如何判断当前节点所在的上下文”——比如这个函数是模块级还是类方法，这个引用是在__init__里还是普通方法里，这个Name节点是Store上下文还是Load上下文。acplugins4python把这一层全部做好了，你只需要继承它的visitor类并实现回调方法。

所以，如果你搜到这个词是因为在做PyDev自定义lint规则，那你来对地方了；如果你只是想在普通Python代码里处理AST，那应该用Python内置的ast模块，而不是这个包。这两者的边界先厘清，后面的内容才不会跑偏。

1.2 为什么需要一个专门的扩展包而不是直接改PyDev源码

有人会问，PyDev本身已经提供了代码分析能力，为什么我还要自己写插件？直接改PyDev源码或者写一个独立的lint工具不行吗？

答案很简单：改PyDev源码意味着你需要维护一个fork，每次PyDev升级你都要merge一遍，时间一长基本就废了。而独立的lint工具做不到与IDE编辑器的深度集成——你希望的问题是直接在Eclipse的Problems视图里显示、在编辑器的行号旁边出现小灯泡提示，甚至可以通过Quick Fix一键修改。这些能力只有走Eclipse扩展点机制才能实现，而PyDev提供的pydev_analysis_observer扩展点就是干这个用的。

acplugins4python在这个架构里的角色，你可以理解为“粘合剂”。它一方面帮你屏蔽了Eclipse JDT和PyDev AST之间的类型转换细节，另一方面提供了一套通用的上下文判断工具类。这就好比你想在某个Web框架里加中间件，不需要自己从头解析HTTP报文，框架已经给你封装好了request和response对象，你只需要写业务逻辑。

实际开发中，如果你从零开始用PyDev原生API写，光处理AST节点的收集和过滤就可能要几百行，而且不同的PyDev版本API还有出入。用了acplugins4python之后，核心规则代码能压缩到原来的一半甚至三分之一，更重要的是——你不需要随着PyDev的大版本升级频繁改代码，兼容性问题大多由这个扩展库替你挡掉了。

2. Eclipse插件开发环境：搭建与依赖加载

2.1 目标平台和依赖JAR怎么配

想要让acplugins4python跑起来，前提是你已经有一个Eclipse插件工程。我用的环境是Eclipse IDE for RCP and RAP Developers，配合PyDev插件一起使用。无论是Eclipse 4.x还是更新的版本，大体流程是一样的，不过有几个细节值得单独拿出来说。

第一步，新建一个Plug-in Project，名字随意，比如com.example.pydev.lint。在创建向导的最后一个页面，记得选择“An OSGi framework”并勾选Equinox，这样整个工程结构才是标准的OSGi插件工程。如果你只是用普通Java工程去引PyDev的JAR，后面部署到dropins时基本不会生效，这一点我踩过很深的坑。

第二步，在工程的MANIFEST.MF里配置依赖。你需要加三个核心依赖：

• org.python.pydev.core
• org.python.pydev.ast
• org.python.pydev

注意，这里的包名在不同PyDev版本里可能有细微差别，比如老版本的org.python.pydev.ast可能被叫org.python.pydev.analysis。我建议你在Eclipse的Dependencies面板里直接搜索pydev，把能看到的几个相关包全部加上，然后再通过编译错误去反推哪些是真正需要的。

第三步，也是新手最容易卡住的一步：直接引用org.python.pydev.ast里的类时，eclipse可能提示“Access restriction”或者找不到类。这是因为PyDev的部分内部API没有对外开放，你需要打开plugin.xml或者MANIFEST.MF里的Runtime页签，添加org.python.pydev.ast到Export-Package里。不过更稳妥的做法是直接使用acplugins4python提供的接口，它可以帮你绕开大部分内部API限制。

2.2 plugin.xml里的扩展点声明

插件工程创建完成后，需要在plugin.xml里声明你要监听PyDev的分析事件。这一步相当于告诉了Eclipse：“PyDev在做代码分析的时候，请把结果通知给我的插件。”

核心代码如下：

<extension point="org.python.pydev.pydev_analysis_observer"> <observer class="com.example.pydev.lint.MyAnalysisObserver"> </observer> </extension>

这里有一点必须强调：org.python.pydev.pydev_analysis_observer这个扩展点并不是在所有PyDev版本里都开放了。如果你在plugin.xml里加扩展点的时候，点开Extension面板没有看到这个选项，说明你的PyDev版本较老或者较新，API发生了迁移。我用的PyDev版本是较新的10.x系列，这个扩展点是存在的。如果你找不到，优先升级PyDev，而不是强行改代码。

MyAnalysisObserver这个类需要实现接口里的方法。注意观察者接口本身并不会直接给你AST节点，它给你的是一个已经分析完成的上下文对象，你从里面可以拿到整棵语法树的根节点。acplugins4python封装的核心入口在这里才真正登场。

2.3 MANIFEST.MF和build.properties中容易出错的地方

我先说结论：插件工程最折磨人的不是写代码，而是打包和依赖配置。如果你在Eclipse里直接Run As Eclipse Application调试，很多配置错误不会暴露出来，等到你导出部署时就会当场翻车。

第一个坑是build.properties里的source..属性。如果这个属性没有指向src目录，导出插件时源码根本不会被编译进JAR，运行时ClassNotFoundException会不断出现。建议打开build.properties，检查source.. = src/这一行存在且目录正确。

第二个坑是MANIFEST.MF里的Bundle-ClassPath。正常OSGi插件不需要手动配置这个属性，但如果你引用了本地JAR（比如把acplugins4python的JAR直接拷进了lib目录），就必须显式加一行Bundle-ClassPath: ., lib/acplugins4python.jar。我当时图省事拷了两个第三方JAR进lib，忘了配这个属性，结果Eclipse启动时静默失败了整整半天，后来通过-consoleLog启动参数才看到日志。这个排查过程虽然痛苦，但对我理解OSGi加载机制帮助很大。

第三个坑是版本号范围。在Require-Bundle里，如果你写死org.python.pydev;bundle-version="10.0.0"，将来用户装了个10.1.0的PyDev，你的插件可能就装不上。更合理的做法是写成org.python.pydev;bundle-version="[9.0.0,12.0.0)"，留足兼容空间。

3. 语法与会话：AST遍历的核心API用法

3.1 AnalysisVisitor必须重写的方法和参数语义

acplugins4python最核心的类就是AnalysisVisitor，它是你在实现自定义分析规则时的入口基类。这个类本身是一个visitor模式的实现，它负责深度遍历Python源代码对应的AST，并在遍历到不同类型的节点时触发对应的回调。

实际使用中，你最常重写的方法有三个：

public class MyRuleVisitor extends AnalysisVisitor { // 在访问模块整体时调用一次，适合做初始化 @Override public void visitModule(Module node) { super.visitModule(node); } // 访问到任意节点时都会调用，适合做统一过滤 @Override public void visit(Node node) { super.visit(node); } // 访问到Name节点时调用，适合做符号引用检查 @Override public void visit(Name node) { super.visit(node); } }

去理解一下这几个参数的类型来源——Module、Node、Name这些类都来自PyDev的AST解析结果，它们和Python内置的ast模块的对象结构非常像，也就是说Name对应Python中的变量名节点，FunctionDef对应函数定义，ClassDef对应类定义。如果你已经熟悉Python的ast模块，那么上手acplugins4python的visitor几乎没有任何心理负担。

不过必须强调一点：在acplugins4python封装的接口里，你拿到的节点对象不一定直接是PyDev原始的AST节点，可能是一个经过包装的IWrapperedASTNode。所以方法签名的第一个参数类型建议直接用Node基类，再通过instanceof判断具体节点的类型，这样兼容性最好。

3.2 用visitor模式拿到的节点对象和常用字段

很多第一次接触这个包的人会被一个问题卡住：我虽然拿到了Visit(Name node)里的node对象，但怎么拿到这个变量的名字？怎么拿到它的行号？

这里有一个固定的套路：先通过node.internal拿到内部原始节点，再调用对应的getter方法。acplugins4python虽然做了封装，但它并没有把每个字段都暴露成同名方法，因为它本身要兼容多个PyDev版本。比如，想拿到变量名的字符串值，代码是这么写的：

@Override public void visit(Name node) { Object internal = node.internal; if (internal instanceof org.python.pydev.parser.jython.ast.Name) { org.python.pydev.parser.jython.ast.Name pyName = (org.python.pydev.parser.jython.ast.Name) internal; String identifier = pyName.id; int beginLine = pyName.beginLine; } super.visit(node); }

这段代码非常典型。你会发现，虽然acplugins4python提供了便利的包装，但要获取具体属性时仍然需要往底层走一步。这是因为Python的AST节点在PyDev内部对应着Jython的节点对象，而Jython的字段命名和Java惯例不同，比如字符串名称用的是id而不是name。

这个阶段容易犯的错误是试图在Name节点上直接调用node.id或者node.getName()——编译不会报错，但运行时会返回空值甚至抛异常。多写几个规则后你就会形成肌肉记忆：先instanceof确认类型，再强转internal，最后操作底层节点。

3.3 上下文判断：isInInit、isInClassMethod这些参数的背后逻辑

acplugins4python真正让人眼前一亮的地方，是它提供了一个上下文判断工具类。这个工具类的价值在于：代码分析最难的往往不是“发现了什么节点”，而是“判断这个节点出现在什么场景里”。

举个例子。一个通用的lint规则是“禁止在类外部访问私有属性或方法”。写成AST分析时，如果你只是判断当前Name节点是不是以双下划线开头，那你会把类内部自己的调用也误报为违规。比如这段代码：

class Foo: def __init__(self): self.__name = "hello" def get_name(self): return self.__name # 这里访问__name是合法的

如果不判断上下文，直接在visit(Name)里看到__name就报错，那get_name方法里的访问也会被误伤。acplugins4python里提供了判断当前节点是否在__init__方法中、是否在类方法中等一系列工具方法，你可以这样用：

@Override public void visit(Name node) { if (isPrivateAccess(node)) { if (isInsideSameClass(node) || isInsideInit(node)) { // 合法场景，不报错 } else { addProblem("should not access private member from outside", node); } } super.visit(node); }

我用到了isInsideSameClass和isInsideInit两个判断，它们在实际封装中名字可能不同，比如isInInit、isInClassMethod。但你要理解的是它们背后的逻辑：底层会从当前节点向上遍历AST的parent链，找到最近的ClassDef和FunctionDef，然后判断当前节点所属的类和方法名是否符合条件。

这套逻辑如果你自己写，要从零处理parent指针、作用域链等一堆细节；而acplugins4python把这些高频操作提前做成了可复用的工具方法。这可能就是“参数”在设计上最有价值的地方——它不仅是方法的入参，更像是一组针对特定场景的语义开关。

4. 实际案例：在PyDev里写一个私有方法访问检查器

4.1 案例需求与整体设计

理论讲再多，不如直接跑通一个案例。这里我拿“检测类私有方法在外部被调用”这个场景来演示。这是很多团队做代码规范时都会用到的一条规则，实现起来也足够典型：既涉及名称分析，又涉及上下文判断，还涉及跨类引用的解析。

具体需求定义如下：

• 允许在类内部调用self.__method()或self._method()。
• 允许在子类内部调用父类受保护方法（单下划线开头）。
• 禁止在类外部通过实例调用任何以双下划线或单下划线开头的方法。
• 不允许直接访问self.__attr这样的私有属性，除非访问代码位于该类的__init__或类内部方法中。

这条规则在PyDev自带的代码分析器里其实已经部分实现了，但默认行为是warning级别，而且不会对“子类访问父类私有方法”做精细化的区分。我们自己实现的目的，是可以完全控制提示的文案、严重级别以及是否跳过高内聚场景。

在设计上，我决定把检查器拆成两层：

• 第一层是遍历层，负责收集类定义和其内部的方法定义。
• 第二层是检查层，负责处理Name节点和Attribute节点，判断是否存在私有访问违规。

acplugins4python的visitor机制很适合这种分层。你可以在visitClassDef里记录当前类的上下文，然后在visitAttribute里判断属性访问的来源。

4.2 逐步实现：从AST节点到问题标记

下面是我写的一个简化但完整可运行的分析器核心部分。首先，在观察者类里拿到AST根节点，然后交给visitor处理：

public class MyAnalysisObserver implements IAnalysisObserver { @Override public void onAnalysisDone(IAnalysisAnalysisResult analysisResult) { // 从analysisResult中取出AST根节点 ASTManager astManager = analysisResult.getASTManager(); Module moduleNode = astManager.getModule(); if (moduleNode == null) { return; } // 创建visitor并执行遍历 PrivateAccessVisitor visitor = new PrivateAccessVisitor(analysisResult); moduleNode.accept(visitor); } }

接下来是PrivateAccessVisitor的核心实现。因为acplugins4python在不同版本里暴露的API命名会有差异，我下面的写法基于其核心逻辑进行示意，你在实际落地时按照自己依赖版本调整方法名即可：

public class PrivateAccessVisitor extends AnalysisVisitor { private IAnalysisAnalysisResult analysisResult; // 用栈记录当前访问到的类名 private Stack<String> classStack = new Stack<>(); public PrivateAccessVisitor(IAnalysisAnalysisResult result) { this.analysisResult = result; } @Override public void visit(ClassDef node) { String className = getNodeName(node); classStack.push(className); super.visit(node); classStack.pop(); } @Override public void visit(Attribute node) { super.visit(node); // 检查是否是实例属性访问，如 self.__xxx 或 instance.__xxx if (node.value instanceof Name) { Name attrTarget = (Name) node.value; String targetName = getNodeName(attrTarget); String attrName = getAttributeName(node); if (targetName.equals("self")) { checkSelfAttributeAccess(attrName, node); } else { checkExternalAttributeAccess(targetName, attrName, node); } } } private void checkSelfAttributeAccess(String attrName, Attribute node) { if ((attrName.startsWith("__") || attrName.startsWith("_")) && !attrName.startsWith("__")) { // 检查当前类是否有这个方法或属性 String currentClass = classStack.isEmpty() ? "" : classStack.peek(); if (!hasMemberInCurrentClass(currentClass, attrName)) { addProblem("Instance attribute '" + attrName + "' starts with underscore but not defined locally", node); } } } }

注意看，我在处理self.__xxx时，并没有直接一棍子打死所有双下划线开头的情况。一来Python的name mangling机制在PyDev AST里不会自动展开，二来很多团队确实会出于特殊原因在内部使用私有属性。所以我的做法是先确认这个方法或属性是否在当前类内部有定义，如果没有定义再报错，这就大幅减少了误报。

addProblem这个方法是acplugins4python的AnalysisVisitor基类提供的，它最终会把问题记录到Eclipse的Problems视图并映射到编辑器行号。你不需要自行管理IMarker之类的Eclipse底层对象，这又是一个提高开发效率的点。

完整的私有方法外部调用检测还需要处理从外部实例调用的场景。此时Attribute节点的value部分不是self，可能是某个变量名。要精确判断这个变量是什么类型，单靠AST分析不够，还需要借助PyDev的类型推断结果。但acplugins4python在这里也留了口子：你可以通过analysisResult去查询某个变量的类型信息。这部分的实现依赖具体PyDev版本的API，我在示例里是为了展示思路，实际场景中你可以在拿到类型信息后再对照类名来判断是否属于越权访问。

4.3 把规则跑起来：在Eclipse里验证插件的完整流程

分析器本身的代码完成之后，还要在Eclipse里完整验证一下整个链路是否通畅。我的建议是不要一开始就写复杂规则，而是先写一个最简单的visitor——比如把所有Name节点打印到控制台——确认插件确实能被PyDev调用起来。这样可以把“插件没生效”和“规则写得不对”两类问题区分开。

在Eclipse里右键插件工程，选择Run As->Eclipse Application，会启动一个新的Eclipse实例。在这个新实例里，创建一个Python工程，任意写一个包含类的Python文件，然后观察Console输出。如果输出里出现了你打印的节点信息，说明插件链路已经通了；如果什么都没打印，大概率是plugin.xml的扩展点配置有问题，或者观察者类没有正确注册。

验证通过之后，再实现真正的私有访问检查逻辑。实现完继续在这个新实例里修改Python文件，每存一次盘，PyDev都会触发一次分析，你的规则就会在Problems视图里出现新问题。这个调试循环非常高效，因为不需要重启Eclipse就能看到规则效果。

我建议你在调试时备一张表格，把常见问题分类记录：

这张表来自我实际踩坑总结，虽然看着朴素，但能帮你快速定位绝大多数问题。

5. 调试技巧和打包部署经验

5.1 DevMode模式下的断点调试心得

如果你之前只做过普通Java项目，第一次在Eclipse插件开发模式下打断点可能会有点不习惯——因为你的插件运行在另一个Eclipse实例里，所以调试时要选择“Eclipse Application”的启动配置，并注意选择的Java Debug端口。直接在代码里打上断点，然后在弹出的新Eclipse实例中执行Python文件保存操作，就能命中断点并检查AST节点内容。

有一点非常实用的小技巧：调试Node对象时，不要只看toString()输出。PyDev的AST节点toString()往往显示的是内部对象的ID，而不是你关注的代码文本。这时候你应该右键变量，选择Copy Variables或直接在Display视图里调用getInternal()并展开它的字段。我第一次调试时看了半天的ID，完全没意识到字段在哪，后来才发现内部节点对象才是信息宝库。

另外，在PyDev的分析链路中，分析器可能会被多个线程并发触发。如果你的规则里用了SimpleDateFormat之类非线程安全的对象，会出现偶发的数据错乱，极难排查。建议规则里不要持有任何可变状态，如果有需要，全部通过栈结构（比如我上面的classStack）局部传递。

5.2 导出插件并部署到dropins的正确姿势

当规则在本地上跑出预期效果后，就面临部署问题。你是团队里唯一需要这个规则的人，还是在团队内分发这个插件，部署方式会有区别。

自己用的话，最简单的是导出插件JAR，然后放进Eclipse安装目录的dropins文件夹下，重启Eclipse即生效。但要注意，PyDev本身现在很多场景是通过Eclipse Marketplace或Install New Software安装的，dropins对这种场景依然有效，只要你把插件的JAR和依赖JAR一起放进去。导出时在Export向导里选Deployable plug-ins and fragments，勾选Install into host. Repository通常用于P2仓库，本地部署选Directory，输出到一个文件夹，再把里面的JAR拷到dropins。

团队分发的话，我强烈建议你做P2更新站点，而不是让大家手动拷贝JAR。虽然配置P2仓库多花一点时间，但之后团队成员通过Eclipse的Install New Software就可以安装和更新，省去大量沟通成本。P2的构建可以用Eclipse Tycho或直接在Eclipse里用Export->Plug-in Development->Update Site Project两种方式。如果你对Maven熟悉，推荐用Tycho，它能直接在CI上打包和发布。

部署后有个很隐蔽的坑：Eclipse会缓存插件状态。有时候你明明把新JAR放到了dropins，但重启后还是没有效果，这往往是因为Eclipse的configuration目录下存在旧的缓存。处理方法很简单：启动Eclipse时加-clean参数，或者手动删除configuration/org.eclipse.osgi目录。我第一次部署插件时被这个缓存问题坑了两次，后来养成了“发布后必-clean”的习惯。

5.3 进阶：如何用同一套机制做代码规范之外的扩展

最后聊一个我后来发现的扩展点玩法。既然acplugins4python能拿到AST节点，也能做上下文判断，那它就不仅能做“违规检查”，还能做一些更符合团队业务需求的事情，比如：

• 自动生成文档注释模板：在visit(FunctionDef)时判断函数是否缺少docstring，然后通过Quick Fix生成模板。
• 技术债统计：统计整个工程里# TODO注释、异常被吞掉、裸except的数量，定期汇总成报表。
• 框架约定强制：比如规定所有Controller类必须以Controller结尾，或者所有对外接口的返回值类型必须标注注解。
• 自动修复重复代码片段：识别到特定的AST模式后，通过Quick Fix替换成封装好的工具方法调用。

这些玩法有一个共同的架构模式：利用pydev_analysis_observer扩展点把分析器挂到每次代码保存的分析流程中，再通过AST遍历收集信息，最终通过Eclipse Marker、Quick Fix或外部日志输出来呈现结果。acplugins4python在这条链路上帮你解决了最麻烦的AST遍历和上下文判断部分，你只需要专注于规则逻辑本身。

拿“自动生成docstring模板”为例，实现起来并不复杂。在你自己的visitor里重写visit(FunctionDef)方法，检查函数体第一条语句是否为Expr且值为Str，如果不是，就在Problems视图添加一条Type为Warning的问题。接着，再配合Eclipse的Quick Fix机制，在用户选择修复时自动插入一个模板格式的docstring。整个过程其实只做了两件事：判断和生成文本，剩下全由插件框架代劳。

从技术栈角度看，这套方案虽然面向的是Eclipse和PyDev，但它的设计思想——扩展点注册、AST遍历、上下文语义判断、Marker反馈——放到任何现代IDE的插件开发里都完全适用。如果你之前写过VS Code的LSP插件，会发现PDI模式本质上也是一样的套路，只是换壳而已。

6. 常见问题排查与稳定运行建议

6.1 如果我用的PyDev版本太新，扩展点找不到怎么办

我身边不止一个人遇到这个问题：装了最新的PyDev，想在plugin.xml里找pydev_analysis_observer扩展点，结果列表里根本没有。这种情况大概率是因为新版本把API迁移到了别的位置。先去Help->Installation Details里查一下PyDev版本号，然后去PyDev的release notes里确认这个扩展点的去向。

如果在新的PyDev里确实找不到这个扩展点，还有一个备用方案：通过org.eclipse.core.resources.builders扩展点挂一个项目构建器，在每次构建时读取Python文件并解析AST。这个方案绕过了PyDev的分析链路，分析时机从“保存后自动分析”变成“项目构建时”。虽然实时性差一点，但完全可控，而且不依赖PyDev内部API的稳定性。只要你能通过IContainer接口拿到项目下的所有.py文件，再使用ast或PyDev的AST解析器，同样能实现大量自定义规则。

不过我的建议是，先别急着绕过PyDev。很多时候不是扩展点消失了，而是你的Eclipse版本里PyDev安装不完整。重新把PyDev安装一遍，再重启一次Eclipse，大概率就解决了。

6.2 规则误报和漏报的调优策略

代码分析器最怕的就是误报太多导致团队直接禁用。你辛辛苦苦写的规则，如果第一天给开发者弹了五十个错误提示，第二天就会被要求回滚。调优的核心思路是：先宽松，后严格，再增加例外机制。

落地到规则逻辑上，你可以给规则加上一个“白名单前缀”机制。比如检测私有方法访问时，如果被访问的方法名以_test开头，就跳过检查；或者把某个类名加入豁免名单。acplugins4python没有直接提供这个配置机制，但它提供了灵活的visitor入口，你完全可以在自己的实现里增加一个配置类，用Properties或JSON文件去控制哪些规则开启、哪些类豁免。

另一个很实用的技巧是：不要只报错误级别的问题，很多规则应该先以Info或Warning级别运行一段时间，确认无误报后再提升为Error。Eclipse的Marker类型定义在插件工程的plugin.xml里，你可以自定义三种严重级别的Marker，然后根据规则的重要性分别关联。我在实际项目中就是这么做的：先作为Warning发布，两周后统计误报率低于1%了，再切换到Error级别。

6.3 在CI环境中离线跑规则的可能性

很多人做完IDE插件后，会有一个疑问：这套规则能不能在Jenkins或GitLab CI里运行？我的回答是：可以，但没必要直接复用IDE插件。最合适的方式是重写一份相同的规则到Python层，用ast模块做静态分析，在CI里以命令行工具的形式运行。虽然两份代码逻辑有重复，但胜在部署简单、执行速度快、没有Eclipse环境依赖。

具体做法是，先把你用Java实现的规则逻辑翻译成Python AST分析代码，输出JSON格式的报告，再用你团队已有的代码质量平台去展示。这样开发者在IDE里能实时看到问题，CI里能强制拦截严重问题，各得其所。

我见过一种偷懒方案：在CI里安装Eclipse headless模式并调用你的插件。不是不行，但每次构建都要启动一个Eclipse实例，耗时几十秒，而且容易受图形环境依赖影响，稳定性堪忧。除非你们有强烈的“单一规则源”需求，否则我不推荐这种方式。

对我来说，acplugins4python这类工具最有意思的地方在于：它把IDE内部的运行机制向开发者打开了窗户，让你能按照自己的团队规范去塑造开发环境，而不是被动接受别人定好的规则。你在写这些分析插件的过程中积累的AST、作用域、编译诊断知识，将来无论是做代码迁移工具、重构辅助工具还是自定义编辑器语言支持，都能复用得上。少纠结包装类的具体命名，多理解它暴露的设计思想，你会走得更远。