文章总结： 作者暂停Xingrin星环更新四个月后选择用Go语言重写为LunaFox项目，主要解决原Python版本扩展性差、资源占用高和架构混乱问题。新版本采用DDD领域设计、类VSCode插件体系和Kafka式分布式任务调度，支持AI辅助开发。项目已消耗200-300亿token完成前后端重构，前端代码量达20万行，后端15万行，重点提升模块边界清晰度和AI协作稳定性。 综合评分： 85 文章分类： 安全开发,安全工具,解决方案,安全建设,技术标准

Xingrin星环暂停更新的四个月，我做了什么

洋洋 洋洋

塔罗安全学苑

2026年5月4日 18:04 江西

在小说阅读器读本章

去阅读

上一篇公众号里，我写过 Xingrin 星环下一个版本的更新打算。

但从 1 月份开始，我没有继续沿着原来的代码往下堆功能，而是选了一个更重的方向：重写。

为什么要开发 Xingrin

Xingrin 的开发，源于我平常漏洞挖掘时遇到的一个实际问题：信息收集过程中不断产生的资产，应该怎么管理。

一个常规的 Web 漏洞挖掘流程，通常会从子域名收集开始，再做存活站点探测，然后围绕站点、子域名、URL、指纹等外部资产继续扩展信息。

这个方向，我更愿意把它理解成“横向面”，也就是资产收集的广度。

另一条线，是对已经收集到的资产继续做深入挖掘。比如从页面、接口、参数、指纹、历史 URL、敏感路径等信息里，继续找可能的漏洞入口。

这个方向更像“纵向面”，也就是漏洞挖掘的深度。

市面上有很多优秀的信息收集工具，比如用于子域名枚举的 subfinder、amass，用于站点存活验证的 httpx，用于 URL 采集的各种爬虫，还有各种指纹识别、目录扫描、漏洞检测工具。

但在日常挖掘过程中，这些工具经常还是以命令行的方式被单独调用。跑完一个工具，把结果整理到表格，再继续跑下一个工具。

子域名收集、站点存活验证、指纹识别、URL 采集、资产持久化、漏洞验证，这些步骤串起来，其实就是一条工作流。

当然，已经有很多工具可以自动化一部分场景，比如 Linux 管道拼接、各种 CLI 脚本、可视化的 ARL 灯塔等。但我试过很多工具之后，还是发现它们和我自己的工作流有不少差异。

比如我想在子域名收集中加入 dnsgen 的变异能力，往往就需要改源码，还要先理解别人的项目结构。再比如有些工具在导入大量资产后，Web 页面会明显卡顿，这背后又涉及性能优化和技术栈选择。还有一些工具的分布式能力偏弱，后面想扩展也很难。

资产管理本身也很容易混乱，这属于业务层面的问题。

如果要把这些方向都改到自己顺手，基本就要大面积重构现成工具的代码了。

所以我后来干脆选择重新开发 Xingrin，把自己日常用到的工作流变成代码，沉淀到一个项目里。

为什么没有继续补功能，而是选择重写

暂停更新这几个月，并不是因为项目放弃了。

恰恰相反，是因为我发现继续在旧版本上堆功能，短期看起来很快，长期来看迭代速度反而会越来越慢。

Xingrin 已经有了一些基础能力，也积累了不少真实开发过程中的判断。但它的问题也很明显：很多设计是在功能推进过程中逐步长出来的，不是一开始就围绕长期演进设计的。

这很正常。很多项目的第一版，本质上都是用来验证方向的。它要回答的是“这个事情有没有价值”“核心流程能不能跑通”。

但当一个项目从验证阶段进入长期建设阶段，问题就变了。

它不再只是要把某个功能做出来，还要考虑模块边界是否清晰、任务执行是否稳定、工具能力是否容易扩展、工程结构是否适合长期维护。

这些问题如果不处理，继续加功能只会让技术债越来越重。项目表面上还在更新，后期维护成本却会被一点点放大。

如果只是代码风格不好，或者某几个模块写得乱，我可能会选择局部重构。但 Xingrin 当时的问题不是某一段代码的问题，而是系统模型的问题。

最直接的问题，是扩展性已经不够好了。

很多新功能并不是“加一个模块”就能完成，而是要先改旧逻辑、拆旧结构、调整调用关系，甚至先重构一部分代码，后面才能继续加。开发起来会越来越别扭。

这也是我后来比较明确的一个判断：如果一个项目每次加功能之前都要先大修原来的结构，那它已经不适合继续靠补功能往前走了。

还有一个很现实的问题，是 Python 任务运行时的资源占用。

Xingrin 早期为了把流程跑起来，任务部分做过很多取舍。我试过纯原生手写 worker，在不使用 Celery 这类调度框架的情况下，一个 Python 解释器启动后的最低内存占用也大概在 70MB 左右。

而 Xingrin 现在采用的 Prefect，虽然比 Celery 更轻量，但任务启动后的资源占用也在 300MB 左右。单看一个任务可能还能接受，但如果同时启动 10 个任务，差异就很明显。

自动化资产收集和漏洞挖掘并不是只跑一个任务。子域名收集、存活探测、指纹识别、URL 采集、漏洞验证，这些任务天然会并发，也天然会被频繁调度。

如果每个任务的启动成本都很高，系统规模一上来，运行时成本会反过来限制系统本身。

最后是旧项目的架构问题。

Xingrin 旧版本整体更接近 MVC 结构。MVC 在早期做业务功能很直观，但对于现在这种需要长期演进、模块边界越来越多、并且会大量使用 AI 辅助开发的项目来说，并不是特别友好。

AI 写代码很擅长补局部功能，但前提是项目边界要清晰、上下文要稳定、模块职责要明确。

如果代码长期堆在传统 MVC 分层里，业务逻辑、任务逻辑、数据处理和工具编排不断交织，后续不管是我自己维护，还是让 AI 参与开发，都很容易引入理解偏差。

所以我最后选择了重写。

为什么是 Go 版本

技术栈选择 Go，并不是单纯为了换一种语言。更重要的是，它和这个项目后续要解决的问题比较匹配。

自动化资产收集与漏洞挖掘系统里，有大量后台任务、网络请求、工具编排、并发执行、结果处理和服务端工程问题。Go 在这些场景里比较顺手。

先说并发。

工具任务、资产探测、批量请求、队列消费，这些能力在 Go 里实现起来比较自然，也更容易控制资源使用。

再说运行时成本。

同样是 worker 任务，Go 版本的启动内存大概只需要 20MB 左右。和 Python 原生 worker 的 70MB、Prefect 任务的 300MB 相比，差距在单任务时已经存在，在多任务并发时会被进一步放大。

如果只是一个小工具，这个差异可能没有那么重要。但 LunaFox 要处理的是一批任务的持续调度和执行。任务数量一多，运行时成本就会被明显放大。

还有一点，是 Go 对 AI 辅助开发更友好。

Go 是静态类型语言，代码天然更适合做静态解析。类型、接口、包依赖、函数签名这些信息都比较明确。

AI 在理解项目结构、补代码、改接口时，上下文会更稳定，也更容易通过编译阶段发现问题。

对于这种需要长期演进、后续会大量使用 AI 辅助开发的项目来说，这一点很重要。它不能保证没有 bug，但可以减少很多由动态结构、隐式约定和上下文理解偏差带来的问题。

当然，语言本身不是答案。

如果架构没有想清楚，换成 Go 也只是换一种方式写混乱代码。所以这次重构，不是简单的语言迁移。

LunaFox 目前开发到哪一步

这个新版本目前名称叫 LunaFox。

它不是把 Xingrin 换成 Go 重新写一遍，也不是简单把原来的功能复制过去。更准确地说，LunaFox 是对整个系统边界的一次重新拆分。

这几个月里，我最大的感受是：真正难的不是把某个功能重新写出来，而是把系统以后怎么长想清楚。

任务怎么调度，插件怎么接入，前端怎么保持易用，而不是只堆砌特效、组件和功能。让 AI 写前端时，怎么保证样式不漂移。AI 怎么参与长期开发，而不是制造更多问题。

这些问题看起来都不算“新功能”，但它们决定了 LunaFox 后面能不能继续演进。

还有一个变化，是去年年末开始 AI Agent 的爆发。

以前我写代码，更多是“人偶尔让 AI 帮一把”。比如补一段函数、生成一个页面、改一个接口。到了现在，开发方式已经变了很多，越来越多代码可以完全由 AI 生成。

这带来的问题也变了。

以前我要考虑的是怎么设计系统。现在除了系统本身，还要考虑怎么设计项目的 harness。换句话说，项目要怎么组织，AI 才能稳定理解上下文；测试、类型、目录结构、规范、约束要怎么放，AI 才不容易写偏；哪些地方可以让 AI 自由发挥，哪些地方必须用强约束把它限制住。

这也是我这次重构时很深的一个感受：以后做长期项目，不能只设计给人看，也要设计给 AI 看。

基础 CRUD 其实在重构前两个礼拜左右就已经完成了。后面真正花时间的，并不是把增删改查再写一遍，而是把代码结构、任务模型、插件体系、前端架构和 AI 协作方式慢慢整理出来。

目前粗略统计下来，前端代码量大概在 20W 行左右，后端代码量大概在 15W 行左右。这个数字里面有都是 AI 参与生成和重构出来的，所以还需要持续审计。

目前后端未审计文件大概还有 350 个左右。其中状态机逻辑，并发逻辑，调度逻辑，分布式逻辑复杂度很高，平均每天花5小时以上的时间都在做这个系统。

LunaFox 重写了哪些核心能力

后端架构是最先动的部分。

LunaFox 抛弃了原来偏 MVC 的代码组织方式，改成更强调高内聚、低耦合的设计方式。简单说，就是把资产、任务、插件、结果、调度这些核心能力拆得更清楚，让每个模块都有自己的边界。

这个方向更接近 DDD，也就是领域驱动设计。这种方式，更适合现在的 AI 辅助开发。

AI 写代码时最怕的一件事，就是上下文边界不清晰。它可能改着改着就开始漂移，把一个模块里的逻辑写到另一个模块里，或者为了完成眼前功能，引入一些后期很难维护的隐式耦合。

如果代码结构本身是按领域拆开的，模块职责更明确，AI 修改代码时就更容易被限制在一个相对稳定的范围内。

它知道资产应该在哪里处理，任务应该在哪里调度，插件应该在哪里接入，结果应该在哪里沉淀。这样可以减少很多 AI 开发里的“漂移”现象。

工作流这一块，也做了比较大的调整。

Xingrin 里有一些工作流代码是写死的。早期这样做很快，因为先把流程跑通最重要。但到后面，问题就很明显：每新增一段扫描逻辑，或者想改一段资产处理流程，都可能要动主项目代码。

LunaFox 会把这部分拆出去，插件系统的设计参考 VS Code 的插件机制。

也就是说，LunaFox 本身会尽量保持克制。它更像一个调度器和资产管理器，负责资产管理、任务调度、插件加载、结果回收和状态维护。具体的扫描逻辑、信息收集逻辑、漏洞验证逻辑，通过插件接入。

这样以后新增扫描逻辑时，不应该再是“改 LunaFox 的核心代码”，而是“导入一个插件”。

核心项目只负责提供稳定的运行环境和数据模型，具体能力由插件扩展。

这也是我希望 LunaFox 后面能走得更远的原因之一：它不应该是一个把所有能力都写死在里面的工具，而应该是一个可以持续挂载能力的底座。

分布式能力也会重新设计。

旧版本里，任务执行和工作流调度更多是围绕当前框架能力往前推。LunaFox 这次会把任务分发、worker 消费、状态回收这些问题拆得更清楚。

整体设计会参考 Kafka 的思路：核心系统负责把任务稳定地分发出去，agent 和 worker 负责消费和执行，结果再回到统一的数据模型里。

当然，这不是说我要在 LunaFox 里重新实现一个 Kafka，而是借鉴它在消息分发、消费模型、任务解耦上的设计思路。对于自动化资产收集和漏洞挖掘来说，后面任务量一多，分布式能力不是锦上添花，而是基础能力。

前端重构和 token 消耗

前端也重构了一轮。

我写了几个 AI loop，让模型不断分析代码结构、发现性能问题、提出重构方案，再进入下一轮修改和验证。这个过程连续跑了几天，消耗了非常多 token，当时一天大概 10 到 20 亿 token 用量。

后面我又整理了前端代码架构，做了性能优化，也把组件、状态、接口调用、页面结构这些部分重新规范了一遍。

到目前为止，粗略估算，整个重构已经消耗了 200 到 300 亿 token，主力模型从刚开始的 GPT-5.3 Codex 到现在的 GPT-5.5。

这些 token 主要花在前后端架构设计、DDD 拆分、插件体系设计、任务模型调整、代码生成和反复重构上。前端本身代码量很大，估计一半以上 token 都花在了这里：给 AI 做各种门控，防止它产生漂移，再反复重构。

这些前期花费是值得的。如果项目结构混乱，AI 只会把混乱放大。如果项目边界清晰、类型明确、模块职责稳定，AI 才能真正变成开发过程里的加速器。

所以 LunaFox 这次重写，除了语言和架构的变化，本质上也是一次面向 AI 辅助开发的工程重构。

接下来的文章，我会继续更新 LunaFox 的开发进度，也会分享一些开发过程中的思考。包括我怎么设计插件体系，怎么处理任务调度，怎么用 AI 设计前端和后端，以及这些过程中踩过的坑。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：塔罗安全学苑 洋洋 洋洋《Xingrin星环暂停更新的四个月，我做了什么》