《关于阡陌交通事件和CoreSwap事件的精确解析》

首先，我要明确几点：

• 本视频不带有情绪化；
• 本视频仅作理性批判；
• 本视频作者支持使用 AI 写项目；
• 本视频仅讨论行为而非人。

说在前面，我其实很看好阡陌交通和 CoreSwap 的功能。如果它们做得好，我会支持。 但问题在于，做得不好，却宣传“做得好”；被指出问题， 不正面回应，反而挂人、锁帖、转移话题。

第一：阡陌交通的争议

对于这个项目，由于时间已经过去很久了，我相信作者不会再回应这个项目的其他信息了，那我只能根据已知的公开信息总结。

这个模组，功能方向确实没问题。但问题出在维护者行为上。

第一，被指缝合 RoadArchitect 和 Countered's Settlement Roads。

MCBBS 上有用户发帖指出其代码抄袭 RoadArchitect 和 Countered's Settlement Roads，且未合规处理授权。

但 RoadWeaver 仓库从首次提交开始一直使用 MIT 许可证， README 里写的是“map inspired by RoadArchitect”。如果项目是独立编写的， MIT 是合法的；如果确实缝合了 RoadArchitect 的代码， 那 MIT 不能覆盖 Apache 2.0 的代码。这一点由于我暂时还无法从公开信息中确认，只陈述双方的说法。

第二，被指挂人、引导网暴。

有某位创作者指出模组存在问题后，作者将私人聊天记录公开挂出，以及疑似引导粉丝攻击。

第三，被指删道歉、小号带节奏。

作者曾在 2025 年 10 月道歉并承诺遵守协议，但被指实际上并未对项目做任何修改， 还删除了道歉说明。同时被指使用小号进行舆论操控。

第四，兼容性差却宣传成熟。

模组被用户普遍反映兼容性差、稳定性差。与 C2ME 等优化模组不兼容， 会导致道路上出现浮空树、道路生成极为缓慢等问题。但宣传中未说明这些限制。

第五，关于“找到其他人开发”的说法。

后续版本中，shiroha-233 提到找到了其他人参与开发。但根据公开信息：

• GitHub 仓库的贡献者列表只有 shiroha-233 和 Campione01 两人；
• Campione01 的贡献记录并不明确；
• shiroha-233 的个人账号仍在持续更新项目，最近的提交（如“修复 opencl”）仍由本人的账号完成；
• 从 2025 年 10 月到 12 月的 commit 历史看，所有提交都是 shiroha-233 一个人完成的，没有任何其他贡献者的痕迹。

所以我个人对这个说法存疑。没有公开证据表明有除 shiroha-233 之外的团队在持续维护 RoadWeaver。 项目仍然以个人账号为主进行更新。这有可能是 AI 开发的掩护，也有可能是真的有人参与但贡献未被记录。

第六，提交历史不规范。

commit 历史中存在大量无意义提交（如“1”、“.”、“添加装饰”），以及规范的英文 commit 与中文随手提交混杂的现象。 这可能说明开发过程比较随意，也可能是 AI 辅助开发的痕迹。这里无法进行判断，我只能陈述。

最后。

阡陌交通的功能方向没问题，shiroha-233 在新版中做了许多技术改进（多线程、Bezier 曲线、隧道桥梁系统等）。 但关于开源协议的争议、挂人网暴的指控、以及“找到其他人开发”的说法，都存在疑点。这些是我存疑的地方，需要你们自己判断。

当然，项目到如今仍在继续更新，且项目生态也逐渐庞大，说明作者已经修改了一部分东西。不过不管怎样，这件事都告一段落了。

第二：CoreSwap 的全 AI 回应

CoreSwap 的技术方向——根据其 Commit 记录，用 C++Rust 重写 Minecraft Java 版的世界生成核心——是有价值的。 （注：CoreSwap 最初宣称使用 C++ 重写，但是后续根据仓库，可知主要底层语言变为 Rust） 如果它做得好，我会支持。但问题出在执行和沟通上。

第一，性能宣传与实际严重不符。

CoreSwap 在宣传中写的是“世界生成快 10-20 倍”。

但在 Issue #7 中，用户轩某Rikka 在 i3-10105 + 1660s 平台上测试：

• 原版：2分42秒
• C2ME：2分10秒
• CoreSwap：6分59秒

CoreSwap 是原版的 0.3 倍，不是 10-20 倍。

作者将性能问题归因于 SMT 超线程和线程数配置。调整线程数后，CoreSwap 的表现是：

• -Dcoreswap.threads=4 时：平均 CPS 17.3（默认 8 线程时约 4 CPS）
• 对照：vanilla 约 10.4 CPS，C2ME 约 13 CPS
• 即 threads=4 时 CoreSwap = 1.66x vanilla、1.33x c2me

也就是说，优化后的表现也只是略超原版，远未达到宣传的“10-20 倍”。

另外，有用户指出“演示视频的区块生成速度比原版还慢”，作者回复“是的”。

第二，“100% 逐位一致”被证伪。

CoreSwap 宣传“100% 位级一致”。

在 Issue #9 中，用户指出 MC-55596：原版 Minecraft 自身跨运行就无法保证 100% 逐比特相同 （但是大多数情况下，MC 反映出来给玩家的是差不多相同）。作者回应称，其“100%”是指“同一运行环境内”的对比，并承认后续会修正宣传口径。

但问题不止于此。Issue #8 中，作者自己承认负坐标区域地形生成错误，影响所有种子。Issue #25 中， 作者自己报告 feedBeardifier 反射失败，导致结构地形塑形静默缺失。

即使在“同环境对比”的条件下，“100% 逐位一致”也存在多个未覆盖的 bug。

第三，稳定性差，多个版本崩溃。

从 Issue 列表看：

• #1：服务端 Chunky 预生成崩溃
• #10、#11、#16：进入世界崩溃
• #17：下界区块缺少层状结构
• #18：每个 chunk 无条件 STDOUT 打印

作者自己承认，崩溃问题是自己加的调试代码导致的，在用户报告后才被发现。

第四，AI 使用不透明。

在 Issue #13 中，有人问“有多少代码是你亲手写的、多少 AI 生成、哪些经你审查”。

作者的回应是：

“你有任何办法印证我说的比例吗？没办法。那你说个 J8？”

无法印证，不等于问题无效。透明度本身就有价值，不是因为它能被第三方逐一验证才有意义。

而且，unknowbug 的 GitHub 主页自我介绍写的是“Vibe coder”——这本身已经说明了他的开发方式。

第五，用 AI 回复 Issue 和评论。

Issue #25 中，三条回复全部标注：

—— AI triage assistant，人工维护者会最终确认。

连“已确认为有效的 BUG_REPORT”这句话也是 AI 说的。人工维护者“最终确认”是否真的发生了，从 Issue 里看不出来。

第六，自指验证闭环。

CoreSwap 的验证协议叫 Anchorlaw。Anchorlaw 的哲学基础是唯物实践论。唯物实践论被第三方审查指出是“自我免疫型伪理论”。

而 Anchorlaw 的成熟度表显示：除了 Scanner，其他所有组件都是 EXPERIMENTAL UNVERIFIED CONJECTURE——即定义了但没验证。

用一套大部分组件未经验证的协议，去验证 CoreSwap，再把这个过程写进 RE-Framework，再用来证明唯物实践论正确——这是一个完美的自指闭环。

第七，对质疑的处理方式。

• Issue #13（您的 Java 代码呢？）：38 条评论，最终被锁为“off topic”
• Issue #14（作者你如何 vibe coding 的？）：被锁为“off topic”
• Issue #4（Stop AI Slop）：被锁为“spam”
• Issue #6（性能质疑）：被锁为“too heated”

对质疑者的回复包括：“你 J8 谁啊”、“你曾经没 ma”、“看不懂代码”、“看不懂 README”。

技术质疑可以讨论，但锁帖和人身攻击不是讨论。

第八，Java 代码从公开仓库消失。

在 Issue #13 中，有人问“您的 Java 代码呢”。作者回应称“Java 层是胶水层，核心在 C++，release jar 里有”。

但问题是：公开仓库里确实没有 Java 代码。用户问的是公开仓库，作者答的是 release jar。这是两个不同的问题。

当然，现在的仓库里，Java 部分的确回来了，只是，

`# java-core — 跨版本共享的 Java 宿主适配核（260912-01 立项，用户已批准）

这是什么：1.20.1 与 1.21.6 两个 Java 模组工程共用的一份宿主适配实现。 与 Rust 侧的 worldgen-core/（跨版本共享引擎）+ versions/<ver>/rust/（版本薄壳）对称。 计划：.investigations/000-架构设计/架构计划-260912-01-共享Java适配核.md（D3 / 范围 A / 机制 M1）。 过程记录：.investigations/shared-java-core-260912-01/record-260912-01.md。

`## 铁律：一个类只有一个家

• 共享类 → java-core/src/main/java/wg/...
• 分版类（mixin / 版本 API 缝实现 / 构建接线） → versions/<ver>/java/src/main/java/wg/...
• 同一个类不得两处同时存在（会出现编译期歧义 + 双真相源）。核对工具：.tmp/shared-java-core-260912-01/class_home_check.py（V6）。

（README.md 1~12行）

可知这个是重写的版本，并且出现了很明确的 AI 才会用的措辞。

第九，提交模式本身就是 AI 比例的答案。

有人可能会说：拒绝回答 AI 比例，不代表就是全 AI 生成。那我们不看作者怎么说，看提交记录。

CoreSwap 在 9月17-20日四天约有 68 次提交，提交信息为：

• feat(diag)、docs(analysis)、perf(light)、test(b61)
• 反复引用 NEXT_SESSION、verdict-260919-02、user-confirmed、grant confirmed、judge review、pre-register criteria
• 人只出现在 user confirmed user granted 的位置

这些提交信息不是人类开发者描述代码改动，而是 AI 会话交接文档的标题。

第三：两个事件的共同模式

特征	阡陌交通	CoreSwap
AI 使用	未说明，被指缝合	拒绝回答比例
宣传	兼容性差却宣传成熟	10-20 倍、100% 逐位一致
被质疑时	挂人、引导网暴	锁帖、人身攻击、转移话题
开源合规	被指不遵守协议	自指验证闭环
对用户	不透明	不透明

两个独立项目，同一套行为模式，不能用偶然解释。

第四：我的立场

我看好阡陌交通的功能方向，也看好 CoreSwap 的技术方向。如果它们做得好，我会支持。

但我批评的是：不透明、不验证、夸大宣传、挂人网暴、用 AI 代替思考。

这些行为跟 AI 无关，用不用 AI 都可能发生。只是 AI 让它们更容易、更隐蔽。

我支持 AI 辅助开发。我自己就用 AI。但我会注明、会测试、会写清楚哪些能用哪些不能用。

这就是区别。

结尾

视频里提到的所有 Issue、commit、README 内容，都是公开可查的。大家自己判断。