省流：MaaEnd 是一个游戏自动化工具。仓库里有两套地图导航——我的 MapNavigator（C++）和 isHarryh 的 MapTracker（Go）。两套不是同时立项的。我先完成了整套系统的研究且已准备好合并，对方以研究纯 CV 为由取得素材和技术细节，随后另起一套竞争实现并推动先行合并。从推动先行合并，到替换业务代码，再到形成单向的 AI 入口，是同一条链上的逐步升级。

核心问题：Go 侧的导航方案及后续操作，是正常的多方案共存，还是有目的性的持续性恶意竞争？

时间线

• 02/04 — 我发布了 C++ 定位寻路方案（#352）的第一个演示视频。
• 02/05 — 提交 PR #352，在群内公开技术细节和性能数据。
• 02/14 — isHarryh 在群内索取我的地图素材和技术路线。当晚基于取得的同一素材启动纯 CV 实现与批测，次日建立 #560，连夜提交测试集，并以”为什么选择我们”的对比宣传文案将其包装为不需要训练数据的替代。
• 02/15 — 两份 PR 被放在负责人面前。isHarryh 发布题为”为什么选择我们”的对比宣传卡片。负责人两次要求”等等 cpp agent”。一小时后，#560 被合并进主线。
• 02/16 — #352 被关闭。

以上是起始节点。此后五个多月里，以下节点上出现了同方向的重复行为：

• 测试邀约 — C++ 侧排障用户被分钟级定向拉去试用 Go 方案。
• 特性跟进 — 点名的功能当晚紧急补齐，与关于 ADB 顺序的明确表态直接矛盾，削弱了”不内卷”的可信度。
• 亦步亦趋 — NavMesh 和 Web 化两次事件中，Go 侧在十天尺度内跟随 C++ 侧的实施方案。
• 故障拉踩 — 竞品卡死时发起对比。
• AI 被提示词引流到其中一边 — 项目级 AI Agent SKILL 文件仅配置 Go 方案，持续 52 天，影响开发者使用 AI 工具的初始检索方向。

结论先行

这不是偶然的多方案共存，而是有目的性的持续性恶意竞争。

02/14 对方已获取 C++ 方案全部技术细节，02/15 #560 在负责人两次要求等待后被先行合并。公开场合给出的”没法用”三条理由，被压测数据、代码审查和 26 条讨论记录逐一推翻。#1283、03/16–17 的即时宣传 Go 方案发生在 C++ 排障期间，03/22 Go 侧在 C++ 公开特性后当晚补齐对应功能，当事人的公开自述与 Git 提交记录直接矛盾。#3125 建立兼容层后仅 27 小时，#3155 建立反向兼容层；NavMesh #3084 → #3359 和 Web 化 #4172 → #4461 间隔分别为 13 天和 10 天。#3830 引入 TurnNode 后 #3855 直接替换业务代码中的 C++ 动作。#3208 单独加入 Go Skill，52 天后才出现对等入口，同提示词复现的首轮选择随入口配置变化方向。

在已知 C++ 方案（MapNavigator）存在且可审查的情况下，Go 侧（MapTracker）持续建立功能重叠的另一套实现。#1283 与 03/16–17 在 C++ 测试排障时即时宣传 Go 方案；03/22 在 C++ 特性公开后当晚补齐；#1487 在公开承诺 C++ 先行之后仍抢先合并 Go ADB。#3125 建正向兼容层 27 小时后即出现反向入口 #3155；NavMesh 和 Web 化均以 10–13 天延迟跟随 C++ 方案。#3830 引入 TurnNode 后 #3855 直接替换业务代码中的 C++ 动作。#3208 单独加入 Go Skill，52 天后才出现对等入口，同提示词复现的首轮选择随入口配置变化方向。

不建立在代码抄袭或恶意推断之上。项目管理端在选型评估与合并监督上的缺位，同样是导致这场长期内耗的重要因素。

一、明知已有，另起一套 — #352 建立后，对方获取了核心素材、技术路线、性能数据和地图参数，随后才立项 #560。

二、抢先合入 — #560 建立当天即与 #352 并排置于负责人面前，通过对比性宣传文案推动优先合并，当晚合入主线；#352 次日关闭。

三、方案能用 — 事后说法是原方案”写了但没法用”。压测数据与后续 26 条公开讨论记录均不支持这一说法。

四、定向引流 — #1283 创建后 60 秒内 @正在排障 C++ 的用户，合入同一分钟再次 @通知；03/16–17 在 C++ 排障线程中直接宣传 Go 方案；04/08 用户求助 MapNavigator 的具体报错、作者已被 @ 到场，回应是“操作是换成 MapTracker”。宣传方与方案作者为同一人。

五、言行不一 — 2 月至 7 月，四个独立节点上出现同一方向的行为。关于 ADB 支持顺序的明确表态与后续 Git 合并次序直接矛盾，“保持良性竞争，不内卷”这一自我描述的可信度被削弱。

六、公开对质 — 04/19 对质中对方的三项辩解，逐一被平台时间戳推翻。在场成员确认客观上形成了竞争；对其主观动机，看法不一。

七、亦步亦趋 — 兼容层：C++ 建 #3125，仅 27 小时 Go 建反向兼容层 #3155。NavMesh：C++ 原生实现 #3084 公开 13 天后 Go 侧提交同名 PR #3359。Web 化：C++ 提方案 #4172 10 天后 Go 侧跟进 #4461。TurnNode：#3830 引入后 #3855 将业务路径切换至 MapTracker TurnNode。同方向的跟随模式在四次事件中仍然成立。

八、引流用户 — 项目级 Skill 文档仅配置 Go 侧方案，持续 52 天（05/28—07/20）。以 #3208 末位提交加入，对称性恢复后对方反向指责”抄袭”。

---

1. 明知已有，另起一套

要验证 #560 是否属于独立开发，先确认一件事：#560 建立前，其作者是否已经知道 #352 的存在、技术路线、核心素材和开发进度。

如果事先知情，“互不知情”这个理由就站不住。

记录

02/04 19:30 — 运行成果首次公开展示。

Lemon-miaow 在群里发送游戏内实机运行视频及带路径点标注的地图截图。群成员讨论“原来是玛丽在拉”、“这下只需要路径点了”。isHarryh 在同一对话序列中发言。

02/05 15:45—16:21 — #352 建立并公开解答技术细节。

定位运行结果截图公开，包含坐标 (985.5, 1125.0)、Score=0.86 及 Time=612.9ms。15:46，Lemon-miaow 贴出 PR #352 链接。

在群内讨论中，Lemon-miaow 解答了关于特征过滤的提问，并公开了性能数据：“目前大概差不多平均一次 120ms”。

02/14 19:26 — 介入同一命题并提出否定评价。

isHarryh 引用 Lemon-miaow 前一日发送的网格图，发表意见：“这种小地图匹配不应该直接模板匹配”、“高度同质化的小地图送到图像分类模型效果应该是不行的”。

02/14 19:39—19:45 — 直接索取素材并获知架构路线。

• isHarryh 提出：“能给我发一下解包图吗？我研究一下纯 CV”。Lemon-miaow 在群内发送了 map.zip（134.07MB） 压缩包。
• isHarryh 发言：“先立个 flag 在这，我感觉纯 CV 是可以定位的”。
• Lemon-miaow 详细说明了自身使用的底层架构：“总之我确信上 yolo 匹配哪张模板图再去 SAD 又稳又快”、“我现在做的就是这套”，并贴出耗时日志（第一轮搜索 152ms 后进精搜，后续帧 33-46ms）。
• isHarryh 当即回应：“哇 还有分级搜索”。

核心素材由对方打包提供，架构路线在同一对话中被完整披露。

02/14 20:33—20:38 — 地图缩放系数双边核对。

isHarryh 询问拼接规律；Lemon-miaow 说明系手写脚本拼接，并需缩放为 0.16x。isHarryh 回复：“对，我比较过了”、“我测的是 0.1625”。

02/14 21:13 — 03:51 — 获取素材后连夜启动同类实现与批测。

• 21:31，isHarryh 宣布“我寻思纯 CV 定位是可行的”。23:50，发布 159 张测试集的压测结果（平均 15ms，成功率 91.82%），并断言“理论上现在已经具备实现自动走路送货的条件了”。
• 02/15 01:10，Go 方案提交测试集 PR。01:15，Lemon-miaow 再次贴出 #352 链接并声明：“我都写完了”。isHarryh 随后追问 Accuracy，并提出“举办一个 YOLO vs CV 定位识别大赛”。
• 03:35—03:51，Go 侧上传演示视频，并在说明中进行对比宣传：“与 yolo 相比的优势，小地图定位无需搜集数据集、无需训练模型”。同时自述局限：“但是这些小地图方案很难处理高度”。

推论

四条事实：

1. 知道 PR 存在：#352 于 02/05 公开，02/15 被当事人直接引用并追问。
2. 知道技术路线：YOLO 前置、SAD 精搜、分级搜索的架构在 02/14 被完整交代。
3. 拿到核心素材：map.zip 由对方直接提供，缩放参数经过核对。
4. 知道开发进度：“我都写完了”与对方追问同屏，#352 标记为 Ready。

反方的解释检验

反方的解释	对应的记录
“不知道有这个 PR”	02/05 在群内公开，02/15 01:15 被当事人直接引用。
“不知道对方进度”	“我都写完了”与对方追问同屏，#352 处于 Ready 状态。
“碰巧同期做了相同的事”	核心素材由对方提供，缩放系数经双边对齐，架构路线在同一对话中被完整披露。

小结

“互不知情独立开发”被客观记录否决。 后续所有争议均发生在 Go 侧已充分掌握 C++ 侧方案信息的前提下。

注：知情本身不构成违规。本章只确认信息对称前提，行为性质在下一章展开。

---

2. 抢先合入

确认事先知情后，核查合并流程：#560 是作为常规技术验证接受评估，还是在负责人明确要求等待的情况下，通过竞争性包装和群内推动促成 #560 先行合并，并由此导致 #352 被关闭。

记录

02/15 17:54—19:12 — 并排对比与宣传。

项目负责人在群里贴出两个 PR（#560 与 #352）询问区别。 isHarryh 在群里发布宣传卡片并 @项目负责人，标题为“为什么选择我们🔥——对比 Yolo 方案的七大优点💡”。

项目负责人当场提出质疑：“不对啊，另一个 PR 也不是 yolo 啊？”Lemon-miaow 澄清：“yolo 仅返回 zoneid，本质还是 cv”。宣传卡片将对方描述过度简化。

在此屏截图中，项目负责人已在 GitHub #560 页面留下明确评论：“等等 cpp agent 啊”。

19:27—19:29 — 管理者重申等待评估。

项目负责人明确说明准备搞两个 agent：“就是我准备搞两个 agent，现在不是只有一个 go 吗，我准备再搞一个 cpp 的”、“等我晚点看看（）”。isHarryh 发布修改后的卡片（六大优点），并向负责人承认：“不行，我这个 CV 有魔改”、“不是标准实现”。

20:09—20:34 — 催促合并。

在负责人两次要求“等一等”后，isHarryh 在群内发送 #560 链接，连发“准备完毕”、“测试无误”，并在 20:30 发言：“合完立即开干送货”。群内随后出现“合！”、“加速！”等催合言论。面对有人询问“那檬喵的怎么办”，isHarryh 回复：“也可以合，爱用哪个用哪个”。

代码于 20:34:21 被合并（操作人：dongwlin）。此时距离负责人要求“等等 cpp agent”仅过去约一小时。

20:40—20:51 — 先行合并的既成事实。

20:40，项目负责人回到群里表示：“草，怎么都已经和过了”。因先行合并已经造成主线上的既成事实，20:51，负责人告知 C++ 作者：“你的 PR 只能关了啊，这是是我的锅，cpp agent 拖了好几天，没想到还能再出一个 PR”。

20:54，isHarryh 承认：“我没有做分层地图”，21:01 确认：“Yolo 仍是目前唯一能分层的方案，不能丢”。

02/16 02:03 — PR #352 关闭。

页面定格为 Closed with unmerged commits。

推论

已获取细节 → 竞争性对比宣传 → 负责人要求等待 → 群内催合 → 第三方在等待评估尚未完成时执行合并 → 负责人事后发现 → #352 被关闭。

抢先合入的代码当晚即被确认缺少分层地图（Tier）功能。

反方的解释检验

当事人可能解释	平台记录客观反证
“只是做验证，没想替代”	发布题为“为什么选择我们🔥”的推广卡片并 @负责人。
“两份方案可以共存”	结果是 #352 闭案退场，因为负责人明确告知“你的 PR 只能关了啊”。
“方案功能更全面”	合并当晚本人承认缺少分层功能，确认“Yolo 仍是目前唯一能分层的方案”。
“合并按钮不是我按的”	合并由第三方操作属实，但推广卡片与“测试无误、合完立即干”等催合论调均出自本人。

小结

抢先合入事实确立。 一份 Ready 状态的方案，在负责人两次要求等待后，被一份已知存在功能缺口的方案抢先合并，导致前者退出主线。

---

3. 方案能用

事后流传的说法是“原方案写了但没法用，也没有文档”。用压测数据和代码审查结果核验这个说法。

记录

02/28 20:22 — 重新加入群聊。

Lemon-miaow 重新加入开发群。

02/28 — C++ 路线性能日志。

按各自公开日志样本，C++ 单帧耗时约在 10-15ms 区间；同期 Go 侧公开报告耗时约为 27-30ms。注意两套截图字段口径不完全相同，比较仅限这些公开样本与各自 PR 报告，不外推为所有场景下的绝对性能结论。

C++ 公开压测图中跟踪平均耗时 11.5ms（P99 25.0ms），Go 侧公开压测图中推理平均耗时 30.2ms（P99 40.0ms）。

02/28 21:32 — PR #867 提交与原始数据公开。

Lemon-miaow 提交 PR #867，公开了 600MB 测试视频及原始 CSV 压测文件。负责人指派 isHarryh 审查，isHarryh 发言：“我无权 review 该 PR”。

03/01 — Harry 回应 CV 组长称呼：表示已卸任。

isHarryh 在群内表示“现在不是 CV 组长了”“已卸任”。

03/02 — #912 分离 minicv。

#912 把 MapTracker 的 CV 逻辑抽为 minicv 独立包。

03/03凌晨 — Go 侧实机问题。

主线 Go 方案在测试中出现需要前台运行、原地跳跃、过桥失败等问题，isHarryh 要求用户手调 arrival_threshold 参数。

03/04 — 自动行走成果。 Lemon-miaow 展示自动行走录像，负责人调侃”给 cv 组长一点压力”，isHarryh 回应称 Go move 延迟主要在截图。

#867 审查与合并节点： 02/28 21:31:37 建立 → 03/02 17:36 MistEO 最终复核 → 03/02 19:47 合并（+2460 行）。

03/10 — C++ 寻路状态机合入主线。

PR #1170 将 C++ 寻路状态机正式合并（6 commits / 55 files / +7806 −43）。状态机包含 7 个闭环状态：Bootstrap（启动定位）→ AlignHeading（对齐朝向）→ AdvanceOnRoute（沿路点推进）→ WaitZoneTransition（等待区域切换）→ WaitRelocation（等待重定位）→ RecoverRejoin（恢复并重回路线）→ ExactTargetRefine（终点逼近）→ Finished / Failed。此时距 #352 关闭不到一个月，C++ 侧已具备从定位到寻路到状态控制的完整链路。

推论

后续 Benchmark、审查和主线合并证明 C++ 核心技术路线具备实际可用性；“技术路线本身没法用”不成立。它不能反向证明 #352 在 02/15 已不存在任何工程接入问题。C++ 方案后续通过压测数据、公开原始 CSV、经完整公开审查并留下 26 条讨论记录后合入主线。

反方的解释检验

反方的解释	对应的记录
“写了但没法用”	#867 公开全量 Benchmark 与原始 CSV，通过审查并合入 main 主线。
“没有文档”	#867 与 #1170 均包含完整性能报告与状态机指引，通过审查。
“Go 方案当时很稳定”	03/03 测试暴露强依赖前台、过桥失败卡死等问题。

小结

“技术路线本身没法用”的说法不成立。 后续 Benchmark、审查和主线合并证明了 C++ 核心技术路线具备实际可用性。这不能反向证明 #352 在 02/15 已不存在任何工程接入问题。

---

4. 定向引流

核查 C++ 方案测试排障期间，是否存在针对特定测试人员的即时定向宣传。

记录

03/14—15 — 分钟级邀测。

• 03/14 18:42，Lemon-miaow 发送 C++ 运行视频，并 @风归云冬 协助排障。
• 03/15 01:56:15，isHarryh 创建针对进近体验的 PR #1283。
• 03/15 01:57（创建不到 60 秒），isHarryh 在群里 @风归云冬 发送 PR 链接，提示其删除参数测试。
• 03/15 11:07:19，PR #1283 完成合并。
• 03/15 11:07（合并同一分钟内），isHarryh 再次 @风归云冬 宣布：“PR 严肃合并，欢迎试用优化版 go”。

03/16 — 排障线程内即时宣传 Go 方案。 风归云冬反馈 C++ 方案洞穴识别卡顿，Lemon-miaow 正与其分析日志。isHarryh 在同一线程介入问：“@风归云冬 go 新版试了吗”，并在 00:00 直接贴出现成 Go 配置文件。

03/22 — 特性点明后当晚紧急跟进。 10:45，Lemon-miaow 点明 C++ 方案具备无坐标 HEAD 终点朝向控制。当天 22:51，isHarryh 宣布也增加了该功能。Git 记录显示其 PR #1529 首次 commit 时间为当晚 23:18:55。

03/26 — 框架接入后的质问。 用户将 C++ 方案接入 maafw 框架后，isHarryh 发言质问：“客户调研：为什么没有用 go”。

04/08 — 用户求助 MapNavigator，被直接告知“操作是换成 MapTracker”。

07/19 — 质疑 C++ 路径的线程内即时展示 Go 工具。

uy/sun 贴出 MapNavigator（C++）的一段绕行路径，问“为什么不直接直走跳下去”；Lemon-miaow 回复“safe”并附路径对比图，群内跟进“起伏更小吧”。uy/sun 随后追问“能够判断这种断崖吗？”。超越一梦想提出“添加单向路径()”，并预期“我猜很复杂”。星光（isHarryh）随即接话“easy”“人工画一条就行”，并连发两张 MapTracker 路网编辑器的案例截图——均为在地图上手动摆点连线、以红框标注单向箭头。

讨论对象是 C++ 方案的能力边界，回应内容是 Go 侧工具的现成界面，与 03/16 排障线程中的介入模式一致。

07/29 — 时隔四个多月，isHarryh 仍出现在同一目标用户的提问下。

风归云冬在开发群提问 maaend_entities.json 中是否包含采集物坐标；Lemon-miaow（MapNavigator）随即回应可以编写脚本提供该数据，风归云冬表示”来一个”。同一问题下，isHarryh 也引用该提问作出回复，先答“应该有的”，随后再次引用同一提问，指引运行 map_tracker_master.py 后访问 http://127.0.0.1:8060/web/navmesh-editor 查看，并附工具截图演示。03 月的记录已显示该用户是持续引流对象；四个多月后，同一用户提出技术问题时，isHarryh 依然在场并作出回应。

08/05 — 用户抱怨 MapNavigator，isHarryh 引用后回复“冷知识跑不通可以换一个工具”，并自注“（明示）”。

推论

对象、时间、内容三点交叉，无法以巧合解释。

• 对象 — 指定正在帮 C++ 侧排障的单一用户，不是群发。
• 时间 — 创建后 60 秒内通知，合并同一分钟内再次通知。
• 内容 — 推送内容精准针对对方测试时暴露的参数痛点。

04/08 的记录连交叉推断都省了。 提问明确指向 MapNavigator，作者已被 @ 到场，回应是“操作是换成 MapTracker”——字面即为换用竞品，且不含任何排障内容。

反方的解释检验

反方的解释	对应的记录
“只是正常通知新版本”	通知不是群发。指定了正在协助竞品排障的单一用户，且卡在创建和合并读秒阶段。
“改进就该给用户试用”	推送本身没问题。但掐秒推送给“正在测试对手方案的唯一人员”，针对性明显。
“只是提供另一个选择”	04/08 的提问是 MapNavigator 的具体报错，管理员已 @ 作者到场处理。回应不含任何针对该报错的排查，内容是换用竞品；真正的解法五分钟后由 MapNavigator 作者给出。同日 11:45 再次出现“建议更换接口”。
“只是开玩笑”	是不是玩笑不改变记录本身：同一天、同一类线程内出现两次，方向一致。群内以“惨案了”“maa怎么这么坏”作回应，也说明它当时并未被当作普通的技术建议。

小结

定向导流事实成立。 精度达分钟级别，目标为正在协助竞品排障的单一用户。04/08 的记录最为直白：用户求助 MapNavigator 的具体报错、作者已被 @ 到场，得到的回应是“操作是换成 MapTracker”，同日再补一句“建议更换接口”。07/19 与 07/29 的记录显示，五个月后该模式仍在延续：C++ 方案被质疑、被求助或被提及的线程中，Go 侧工具随即被展示。

---

5. 言行不一

核查在不同场景下，同类行为是否重复出现，并比对公开言论与 Git 提交记录。

记录

03/18 — 公开自述与代码合并矛盾。

isHarryh 公开答复：“什么时候 cpp 支持了我再支持……保持良性竞争，不内卷”。 平台记录显示：Go 侧 ADB 支持 PR #1487 于 03/21 合并；C++ 侧 PR #1999 于 04/07 合并。Go 侧实际领先合并 17 天。

推论

公开自述与代码行为矛盾。 关于 ADB 支持顺序的明确表态与后续 Git 合并次序直接矛盾，“保持良性竞争，不内卷”这一自我描述的可信度被削弱。上述宣传与补齐行为进一步佐证了同类模式的持续性。

反方的解释检验

反方的解释	对应的记录
“ADB 的话只是随口说说”	公开答复承诺清晰，3 天后其提交的 Go ADB 支持先行合并。
“朝向控制本来就在做”	PR #1529 commit 显示核心代码首次写入于对方点明功能当晚 23:18:55。

小结

偶发解释被排除。 行为模式在四个独立节点重演，公开表态与代码提交记录直接冲突。

---

6. 公开对质

正面检验当事人在 04/19 对质中亲口抛出的辩解理由及现场群员评价。

记录

起因与辩解。

针对“为什么一个项目做两套”的质问，isHarryh 回复：“正在严肃垄断”，并给出三条理由：“进展太慢”、“功能没有涵盖所有需求”、“不认同设计理念”，补充称“写是写完了但没法用”。

当事人承认。

• 18:06 isHarryh：“那我素质可能有点差了，抱歉没有考虑你的感受。”
• 18:26 isHarryh：“现在看来，我承认结果从主观上看确实对你不尊重。”

第三方定性。

• 暗檬：“甲乙两个施工队同时开工。”
• issue小王：“你俩搁这竞标呢。”
• uy/sun：“确实客观上竞争了。”
• EeeMao：“没必要把人想得那么阴暗。”（本文接受此保留意见，不推定主观恶意）

反方的解释检验

反方的解释	对应的记录
“不知道 C++ 方案在开发”	02/14 本人向 C++ 作者索取素材、技术路线、性能数据和地图参数，当天同步的技术细节覆盖了整套方案的核心架构。群聊时间线（第一章）证明其完全知情。
“进展太慢”	实际为代理部署排期问题，项目负责人已明确承认责任在自身。
“功能没有涵盖所有需求”	合并当晚本人亲口承认自身缺少分层（Tier）功能，确认 C++ 是唯一可分层方案。
“不认同设计理念”	可解释另起一套的偏好，但无法解释绕过等待评估抢先合并的流程问题。
“写是写完了但没法用”	#352 在 #560 创建前已经转为 Ready，定位核心功能已完成，公开记录显示剩余条件主要是 cpp-algo 接入。现有公开记录也未显示项目存在必须在 02/15 当晚完成选型或立即合并寻路实现的明确期限。见第三章压测数据、原始 CSV、26 条讨论记录及合入主线记录。

小结

公开理由均无法在已披露的记录中无矛盾地成立。 当事人已承认结果上不尊重。在场成员确认客观上形成了竞争；对其主观动机，看法不一。

---

7. 亦步亦趋

核查 04/19 冲突后，Go 侧是否在 NavMesh、兼容层和工具 Web 化上重复了同方向的跟随模式。

记录

05/21 — C++ 原生 NavMesh 发布。

Lemon-miaow 提交 PR #3084，发布预烘焙多边形三角网格的全图及视频。

05/23—05/25 — 兼容层争夺。

05/23，Lemon-miaow 提交 PR #3125，创建 MapTrackerMove→MapNavigatorCompatible 正向兼容层，使既有 MapTracker 路线无需调整坐标即可切换到 C++ 方案。

约 27 小时后，isHarryh 提交 PR #3155（+1157 −27），反向建立 MapNavigateAction→MapTrackerMoveCompatible 入口，PR 正文明确引用 #3125。#3125 提供从 MapTracker 到 MapNavigator 的兼容路径，27 小时后 #3155 以反向兼容层回应，方向相反。

06/03 — 名字叫 NavMesh，内容完全不是。

C++ 发布 NavMesh 前，公开仓库记录中未见 Go 侧提交路网或 NavMesh 相关实现。C++ 发布 NavMesh 仅 13 天后，isHarryh 提交 PR #3359，命名为 MapTrackerNavMesh——与 C++ 侧的 MapNavigatorNavMesh 仅差一个单词。PR 正文自述为“一种基于文本的路网数据文件”，代码结构由离散点与连线构成（固定路网 Waypoint Graph），无多边形面。NavMesh 的技术定义是以多边形（通常为三角形）网格表示可行走区域，而这份 PR 的数据结构是点线图，不具备网格面的特征。名称与其自身文档描述矛盾。

能走到目的地，不代表它就是 NavMesh。 寻路的数据有两种常见做法，各有各的名字。一种是 NavMesh（导航网格）：用一片片多边形把能走的地面铺满，哪里能走、哪里是边界，看这片面就知道，没铺到的地方就是走不了的地方。另一种是 Waypoint Graph（路点图）：在地图上人工点几个点、连几条线，能走的只有这些线，线以外没有任何信息。

两种都能寻路，都能“说哪走哪”，走不走得到跟叫什么名字没关系。问题只有一个：MapTrackerNavMesh 存的是点和线，是第二种，名字却用了第一种的。

准确地说：NavMesh 与 Waypoint Graph 是路径规划中两类并列且各有定义的数据结构——前者的可行走性是多边形面本身的属性，面的边界即障碍边界；后者的可行走性只存在于人工摆放的点与边上。MapTrackerNavMesh 按定义属于后者，却使用了前者的名称。这不是功能强弱之争，是类别错配。

第四节 07/19 的对话正好印证了这点。被问到“能够判断这种断崖吗”，isHarryh 的回答是“人工画一条就行”，并贴出手动摆点连线、红框标注单向箭头的编辑器截图。断崖在哪、哪条路只能单向走，全都得靠人一条条画上去——真正的 NavMesh 里这些是面自己带的信息，不用人画。约束靠人工逐条标注而非从几何面推导，正是路点图的定义特征。此时距 06/03 命名矛盾被指出已过一个半月。

06/04 — 公开宣传。

isHarryh 在群内发布滑索寻路演示视频，配文“此视频您将看到我们最新成果的前瞻效果演示”，获群成员回应“强强！！！！”。宣传涵盖自动识别滑索、自动上滑索、容忍选错 / 阻挡、NavMesh 等要素。此时距离 PR #3359 提交仅过一天。

06/05—06/11 — 宣传与故障对比。

然而同期公开测试与开发者反馈中仍出现过桥、阻挡和运行稳定性等问题。在此前提下：

• 06/05，针对 C++ A* 路线提问，isHarryh 回复“用 MapTrackerGoal 就行了，包对”。
• 06/11，在用户反馈 C++ 编辑器卡死后，isHarryh 引用该报告发言：“看看我们的 nav mesh editor 会卡死吗”。
• C++ 作者指出其“连个面都没有”，被 Go 侧定性为“开始攻击了”。

07/13 — #4172 工具 Web 化。

Lemon-miaow 提交 PR #4172，将 MapNavigator 工具从 tk OpenCV GUI 迁移到 Web UI（Vue + Element Plus + FastAPI），形成统一的暗色地图编辑器。

07/23 — #4461 跟进 Web 化。

#4172 合并十天后，isHarryh 提交 PR #4461，同样将 MapTracker 工具从 Python OpenCV GUI 迁移到 Web UI，描述为”MapTracker Master Tools 聚合式 Web 工具现已可用”。

07/29 — 命名争议持续至今，未见更正。

命名矛盾指出后近两个月，文档未作调整。截至 2026-07-29 11:00（对应固定版本 MaaEnd/MaaEnd@0c7221a），.agents/skills/go-map-tracker-guide/SKILL.md 仍称 map_tracker_master.py 提供”NavMesh 编辑”功能；docs/zh_cn/developers/components/map-tracker.md 仍称 MapTrackerGoal 节点”基于 NavMesh 自动规划路径”，entity_id 参数说明仍写作”NavMesh 顶点关联的实体 ID”。底层数据结构未变，命名也未变。

07/30 — 隔了十一天，还是那句“自己画”。

19:11，用户明欣提问 MapTrackerGoal 可不可以指定目标的碰撞箱，并说明遇到的现象：“指定侧面的点位会在从另一侧寻路的时候卡住”。群成员 ocsin 的判断是“这应该是 navmesh 打点打少了”。isHarryh 随后回复“要什么路线自己画（”，并连发两张 MapTracker 编辑器截图；针对其中的路网放大图，他解释“你选择这个点（箭头所指）作为终点的话”“一般都会途径紫色线条，不会穿越中心的”。19:39，明欣自行确认了原因：“原来是填到演算台中间了”。

这段对话有三处值得看。

一是距 07/19 的“人工画一条就行”只过了十一天，同一个人对同一类问题的回答仍然是“自己画”。路线由人手工绘制，不是从地形几何算出来的——两次表述完全一致。

二是“打点打少了”这个说法本身。真正的 NavMesh 里不存在“点打少了”，面铺到哪里就能走到哪里，走不到只可能是面没铺；会因为“点少”而走不通的，只有路点图。群成员在排障时脱口而出的是路点图的那一套概念，用的却是 NavMesh 这个名字。名字张冠李戴的后果，不只停留在 PR 标题上，已经进入了使用者理解问题的方式。

三是 isHarryh 自己给出的解释：终点选在某个点上，路径“一般都会途径紫色线条，不会穿越中心的”。这句话就是路点图的定义——能走的只有人工连出来的那些线，线与线之间的区域没有任何可通行信息。NavMesh 的多边形面内部任意位置都可穿行，根本不会有“不会穿越中心”这一说。明欣把终点填在演算台中间就卡住，也正是因为那块地方没有人画过点。

距 06/03 命名矛盾被公开指出，已近两个月。

#3830 → #3855 — TurnNode 引入并替换主体业务。

isHarryh 在 PR #3830 中为 MapTracker 新增转向节点（TurnNode）。在此基础上，PR #3855 将该业务路径从 MapNavigateAction 切换至 MapTracker TurnNode，形成对既有 C++ 动作的实际替换。

反方的解释检验

反方的解释	对应的记录
#3155 只是正常兼容层	两个兼容层方向完全相反。#3125 把 Go 路线迁向 C++；仅 27 小时后 #3155 建立反向兼容层（+1157 行），且 PR 正文明确引用 #3125。这不像独立规划的功能需求，更像对竞争方动作的即时回应。
“NavMesh 是独立开发的”	同名 PR MapTrackerNavMesh，提交于 C++ 原生 NavMesh 公开仅 13 天后。代码底层仅为离散点连线，无三角面，不构成 NavMesh 的技术定义。时间线、命名和自身文档描述的”文本路网数据文件”三处矛盾。
“能用就行，名字不重要”	这里争的不是好不好用。NavMesh 和路点图是两种不同的东西，都能寻路；MapTrackerNavMesh 存的是点和线，是路点图，名字却用了 NavMesh。07/19 被问到能不能判断断崖，本人的回答是”人工画一条就行”；07/30 被问到寻路卡住，回答仍是”要什么路线自己画”，并解释路径”不会穿越中心”——能走的只有人工连出来的线，这正是路点图的定义。同一场对话里，群成员的排障用语是”navmesh 打点打少了”，混用已经从代码蔓延到了使用者。截至 07/30，文档、工具路由和日常使用里的这个名字都没改。
“Web 化是正常技术演进”	单独看，Web 化可以属于正常技术演进；但在同一仓库、同位竞争模块和既有持续跟进模式中，十天内出现相同迁移方向，构成方向一致的补充证据。该节点不单独作为独立证据。
“只是行业都在做 Web 工具”	同一仓库、同位竞争模块、同一迁移方向在十天内出现，难以仅用行业趋势解释。
“TurnNode 替换是正常重构”	#3830 引入 MapTracker 专属转向节点，#3855 将环境监测业务的原有动作路径切换至 MapTracker TurnNode。该切换将业务依赖单向指向竞争模块，两个 PR 均未通知 C++ 侧或提出迁移方案。

小结

亦步亦趋的模式再次出现。 兼容层、NavMesh 与 Web 化三个节点，均表现为 C++ 侧先行、Go 侧随后作出同方向回应；TurnNode 则进一步表现为从自己模块蔓延到了公共业务，并对既有 C++ 动作形成实际替换。

其中 NavMesh 这一项和其他几项不太一样：它不只是时间上跟得紧，而是在 C++ 的 NavMesh 公开 13 天后，把一份点线路网也叫成了 NavMesh。这跟谁做得好不好没关系——两种东西都能寻路；问题是名字张冠李戴。被公开指出后，这个名字到 07/30 仍挂在文档、工具路由和日常使用里，没改；同一天群内答疑时，本人对“怎么让它走某条路”的回答依然是“自己画”，群成员排障时说的则是“navmesh 打点打少了”。

---

8. 引流用户

核查仅配置 Go 侧 Skill 对开发者及 AI 工具初始选择的影响。

记录

末位提交与审查缺口。

05/28 03:01，UI 重构 PR #3208 在通过机器人审查后，追加最后一个 commit docs: 加个妙妙SKILL，写入 Go 侧配置 go-map-tracker-guide。

52 天仅 Go 侧有 Skill。

该文档包含强指令：“当你判断确实正在进行 MapTracker 的开发工作时，务必无条件地先读取……”。在此后 52 天内（05/28—07/20），项目中仅有 Go 侧 Skill 写入项目配置，AI 编码工具在此基础上优先检索 Go 方案。

实测对照显示：仅有 Go 侧 Skill 时，AI 首轮直接抓取 Go 文档并做优先推荐（在扫库 4 分钟后自行纠正）。

平权后的指责。

07/20 C++ 侧补齐 map-navigator-guide 后，isHarryh 于次日截图指责：“连 skill 都抄是有点好笑的”。

反方的解释检验

反方的解释	对应的记录
“只是随手加了个文档”	Skill 以 UI 重构 PR 的末位提交加入；两次自动审查均发生在该提交之前，之后未见新的正式审查记录。
“没有规定两边都要有 Skill”	没有。但结果就是单侧 Skill 持续 52 天，AI 实测首轮直接抓取 Go 文档优先推荐。Skill 以 UI 重构 PR 的末位提交加入，未见独立审查。
“Skill 只是辅助，不影响行为”	实测 AI 在单侧配置下首轮抓取 Go 文档并做优先推荐。本次对照样本中的首轮影响真实存在。

小结

#3208 以末位提交单独加入 Go Skill，52 天后才出现对等入口，干预了初始检索方向。对称性恢复后，当事人随即反向指责对方”抄袭”。

---

结论

这不是偶然的多方案共存，而是有目的性的持续性恶意竞争。

02/14 对方已获取 C++ 方案全部技术细节，02/15 #560 在负责人两次要求等待后被先行合并。公开场合给出的”没法用”三条理由，被压测数据、代码审查和 26 条讨论记录逐一推翻。#1283、03/16–17 的即时宣传 Go 方案发生在 C++ 排障期间，03/22 Go 侧在 C++ 公开特性后当晚补齐对应功能，当事人的公开自述与 Git 提交记录直接矛盾。#3125 建立兼容层后仅 27 小时，#3155 建立反向兼容层；NavMesh #3084 → #3359 和 Web 化 #4172 → #4461 间隔分别为 13 天和 10 天。#3830 引入 TurnNode 后 #3855 直接替换业务代码中的 C++ 动作。#3208 单独加入 Go Skill，52 天后才出现对等入口，同提示词复现的首轮选择随入口配置变化方向。

在已知 C++ 方案（MapNavigator）存在且可审查的情况下，Go 侧（MapTracker）持续建立功能重叠的另一套实现。#1283、03/16–17、03/22 在 C++ 测试或公开特性后宣传 Go 或补齐对应功能。#3084 → #3359、#4172 → #4461 以 10–13 天延迟跟随。#3830 → #3855 替换业务代码中的 C++ 动作。#3208 单独加入 Go Skill，52 天后才出现对等入口，同提示词复现的首轮选择随入口配置变化方向。

不建立在代码抄袭或恶意推断之上。项目管理端在选型评估与合并监督上的缺位，同样是导致这场长期内耗的重要因素。