企业官网建设流程全解析

开源社区里最让人血压升高的事，不是功能被别人“借鉴”了，而是代码被整个搬走，翻到 README 和 LICENSE 一栏，一个字都没提你。最近闹得沸沸扬扬的 Minitap 与 Google Artemis 之争，就是典型一例。Minitap 团队发声明指控谷歌的 Artemis 项目盗用了他们维护的开源项目 mobile-use 的代码，而且没有注明出处。对不熟悉开源规则的人来说，这可能只是“两家公司吵架”；但如果你自己维护过项目，或者在公司里写过依赖第三方代码的模块，就会明白这事的分量：它触及的不只是道德问题，更是开源许可证和整个协作体系的底线。

这篇文章我不打算急着做立场宣判，谷歌到底有没有“盗用”，最终要看双方摆出来的证据。我更想借这个案例，把“开源代码被复用但不署名”这件事拆开，讲清楚什么样的行为算违规，判断依据是什么，大公司为什么也会踩这种坑，以及我们作为开发者，怎么在平时就给自己上几道保险。无论你是个人项目维护者、企业开发者，还是刚入行不久、准备参与开源的新人，这篇应该都能给你一些实实在在的边界参考。

1. 这起争端的主角：mobile-use 和 Artemis 分别是什么

既然要聊这起争端，得先搞清楚两边各自是什么来头。很多圈外读者可能跟我一样，第一反应是：Artemis 我听过，谷歌的；但 mobile-use 是什么？Minitap 又是谁？

1.1 mobile-use：一个典型的移动端 AI 代理开源框架

mobile-use 是 Minitap 团队维护的一个开源项目，定位非常明确：让大模型像人一样操作手机。你给它一句自然语言指令，比如“帮我在备忘录里建一个明天的日程提醒”，它就能通过视觉识别、界面解析和动作回调，在 Android 设备上完成点击、滑动、输入等一系列操作。

从技术架构上看，这类项目通常由几个核心模块组成：界面信息提取模块，负责把屏幕上的控件转成结构化文本或坐标；动作执行模块，负责把模型决策映射成真实的触摸事件；还有规划模块，负责让大模型决定“下一步做什么”。mobile-use 在这条赛道里不算最早的，但胜在代码组织清晰、文档齐全，在 GitHub 上积累了不少关注，也吸引了一批开发者参与贡献。

这种项目有个特点：它的核心逻辑非常“可迁移”。界面解析、坐标映射、无障碍服务调用、模型 prompt 模板，这些部分几乎是任何移动端 AI 代理项目都绕不开的“基础设施”。换句话说，mobile-use 提供的不是某个具体功能，而是一整套“让 AI 操作手机”的基础方案，谁拿过去都能快速起一个相似的产品。

1.2 Artemis：谷歌在移动 AI 代理方向的布局

Artemis 是谷歌在移动端 AI 代理领域的项目。从公开信息来看，它同样瞄准了“AI 在设备端自主完成多步操作”这个方向，和 mobile-use 在能力面上有明显重叠。谷歌作为 Android 生态的主导者，做这类项目有天然优势，可以更深度地调用系统能力，也能和自家的语音助手、系统级 AI 服务联动。

问题就出在“能力重叠”和“代码重叠”是完全两回事。两家都做手机自动化，这不叫抄袭；但如果一个项目里出现了另一个项目的实现细节、命名习惯甚至注释原文，那性质就变了。Minitap 团队这次的指控，显然不是“你也做手机操作”这么空泛，而是指向了更具体的代码复用。

1.3 Minitap 的指控点：不是“用了”，而是“拿走了却没说”

从社区流传的对比信息和 Minitap 团队的声明来看，核心指控有两个层面：第一，Artemis 项目的部分代码与 mobile-use 高度相似，已经超出了“巧合撞车”的范畴；第二，更关键的是，谷歌在使用这些代码时，没有保留 mobile-use 的版权声明，也没有在项目文档中注明出处。

这里我要特别强调一下“用了代码”和“拿走代码不署名”之间的区别。开源不等于放弃版权，不等于“随便用”。绝大多数开源许可证都允许你复制、修改、再分发代码，但前提是你要履行相应的义务，其中最基础的一条就是保留原始版权声明和作者署名。如果你把代码搬走了，然后把自己的名字一贴，从法律上讲这叫“删除版权管理信息”，在多个司法管辖区都是明确违规的。

这也是为什么这个事件能在开源圈迅速发酵。大厂和小团队之间的代码纠纷本来就容易引发共情，更何况“吃相难看”的程度——如果指控属实，那就不是技术判断失误，而是基本合规意识的缺失。

2. 代码撞脸还是真抄袭：判断“盗用”需要看什么

很多人一看到“代码相似”就喊打喊杀，但作为从业者，我得说一句公道话：代码相似本身不一定等于盗用。同一个功能，成熟的开源写法就那么几种，尤其是处理 JSON、解析 XML、调用系统 API 这类标准化操作，十个开发者能写出九份差不多的代码。那到底怎么判断是“英雄所见略同”还是“复制粘贴”？这里有一套相对客观的判据。

2.1 开源许可证下的“合法借用”与“违规挪用”的边界

要理解“盗用”的边界，先得明白开源许可证的层级逻辑。不同许可证对使用者的约束完全不同，我把最常见的几种列成一张表，方便对照：

注意看表格里的第二列和第三列。MIT 和 Apache 2.0 这类“宽松许可证”给了使用方很大的自由：你可以拿去商用，可以改完以后不发源码，唯独有一条不能省——保留原始版权声明。这句话看着简单，但在真实项目里经常被忽略：从 GitHub 上拉了一个仓库下来，改了改就合进自己的代码库，版权声明文件要么没拷，要么被后来者的 LICENSE 覆盖了。

回到 mobile-use 事件上，如果 mobile-use 用的是 MIT 或 Apache 2.0 这类宽松许可证，那谷歌“复用代码”这件事本身可能并不违法，但“未注明出处”这一条，直接踩中了许可证最核心的义务线。

2.2 维护者通常靠什么证据锁定“复制粘贴”

看一个项目是否真的“盗用”了另一个项目的代码，不能靠感觉，得靠证据。我在社区里围观过不少类似的纠纷，维护者摆出来的证据一般集中在这么几类：

• 命名指纹：某个项目里有一个不常见的函数名、类名、变量名，在另一个项目里原样出现。命名这东西最诚实，如果extract_screen_forest这种带个人风格的函数名出现在两个人各自的代码库里，巧合的概率基本为零。
• 注释残留：开发者复制的往往不只是代码，还包括注释。有时候原作者会在注释里写一句很个人化的吐槽，或者写一个错别字，结果被原封不动搬过去。很多“实锤”就是从这种细节里扒出来的。
• 代码结构指纹：两个文件的行数接近、函数顺序一致、空行位置一致、甚至某段奇怪的空格缩进都一模一样。这种结构化相似度靠肉眼可能看不全，但用 diff 工具一比对，一目了然。
• 提交时间线：mobile-use 的某个提交记录显示代码在 2024 年 3 月就存在了，而 Artemis 项目的首次提交晚于这个时间点，再加上名称和结构的高度吻合，时间线就成了最有说服力的证据。

Minitap 团队这次的指控，按社区常见的“实锤”套路看，大概率也是从这些角度切入。不需要逐行 100% 相同，只要出现一两个“独占性指纹”，就足够把“撞车”变成“复制”了。

2.3 我见过的一些“低劣但真实”的复制场景

说句实话，我在这个行业里见过不少“复制代码”的案例，水平参差不齐，有些真的让人啼笑皆非。

一种是“全量搬运型”。整个文件拷过去，连文件头部的版权注释都没删，只是把作者名字改成自己的。这种属于最懒的，也是最容易实锤的，因为只要原项目方一搜文件名，立刻就能找到。

另一种是“局部改造型”。把变量名改一圈、删几行注释、换一下函数顺序，以为这样就不算抄了。这种稍微费点劲，但核心逻辑、边界条件处理、异常分支几乎原样保留，用相似度检测工具一跑还是能看出来。

还有一种最隐蔽，叫“二次创作型”。A 项目抄了 B 项目的核心逻辑，B 项目抄了 C 项目的界面设计，最后 C 维护者去质问 A，A 一脸无辜说“我是从 B 那里学的”。这种追责链路长、证据容易断，往往最后不了了之。

说这些不是为了嘲讽，而是想说明一个事实：代码盗用在这个行业里并不罕见，只是大多数时候没闹到明面上。这次 Minitap 和谷歌的争端能公开化，对开源生态来说反而是一件有正面价值的事，至少它把“复制代码不署名”这个问题重新放到了聚光灯下。

3. 为什么谷歌这种体量的公司还会在这个坑里翻车

很多人不理解：谷歌啊，世界级的科技巨头，内部各种合规培训、代码审查流程，怎么会犯这么低级的错误？这恰恰是普通人对大公司流程的误解。大公司的“合规”通常做在最容易被审计的地方，比如法务会盯着你用了什么付费软件的授权，安全团队会检查你集成了哪些有已知漏洞的第三方库。但“从 GitHub 开源项目里复制了一段代码，合入内部项目时没保留版权声明”，这种事情在体量庞大的组织里，监管起来远比想象中难。

3.1 大公司开源流程的普遍盲区

大公司的代码库是海量的，一个项目动辄几百万行代码，分布在几百个仓库里。谁来保证每一行代码都手续齐全？实际上没人能保证。各个团队为了赶进度，从 GitHub 上找现成代码是常态，尤其是一些“基础设施类”的工具函数，大家默认“网上都是这么写的”，随手复制粘贴进代码库。

真正的问题在于，很多开发者把“开源”理解成了“无主”。他们没有恶意，就是单纯缺乏许可证意识。看到一段代码，试了一下能跑，就直接用了。至于这段代码是什么许可证、要不要保留版权声明、能不能用在商业项目里，很多人压根没想过。这不是某一个人的问题，而是整个行业在培训和教育层面长期缺失的结果。

谷歌内部的代码审查系统确实很严格，会包头到接口设计、性能、安全性，但对“知识产权痕迹”这一项的自动化检查，其实非常有限。系统很难自动判断“这段代码跟 GitHub 上某某仓库的某段代码一致”，尤其是经过变量重命名、函数拆并之后，静态扫描工具的作用就更有限了。

3.2 内部复制粘贴与“顺手搬运”的文化

还有一个容易被忽略的因素：内部复制粘贴。谷歌这种体量的公司，内部有大量的共享代码库和通用组件库。一个工程师在某个内部仓库里看到一段现成的代码，这段代码其实是两年前某个人从外部开源项目里带进来的，版权声明早就被层层传递弄丢了。这位工程师不知道这段代码的外部来源，以为是自家团队写的，就拿去用了。

这种“二级传播”特别可怕。原始来源的开源项目作者，找谷歌算账的时候，谷歌自己可能都查不清这段代码到底是从哪个内部仓库流出来的。每一层复制都会把版权信息抹掉一层，几层之后就完全看不出来了。

更有意思的是，这种文化并不限于底层工程师。有些项目负责人为了赶工期，会直接授意团队“先拿开源方案改造一下，后面再整理版权”，结果“后面”永远没有来。deadline 一到，代码合并，这件事就被遗忘了，直到若干年后原作者来敲门。

3.3 团队扩张、外包与收购带来的历史包袱

谷歌也不是所有的代码都出自自家工程师之手。移动端 AI 代理这个赛道这两年中厂、大厂都在抢人，团队扩张速度极快。新来的工程师把上一家公司的代码风格、使用习惯带来，是很自然的事。有些甚至在跳槽前把自己上一家公司的项目“顺手”复制了一份，作为“个人参考资料”带到了新环境。

还有一种常见路径是收购。大厂收购小型创业团队，直接把对方整个代码库接过来。被收购团队的项目里可能本身就有一部分代码来自其他开源项目，而且没有做到完整合规。收购完成之后，这些“隐藏债务”就自动转移到了大厂头上。一旦原作者维权，承担舆论压力和法律责任的是谷歌，而不是那个已经解散的创业团队。

看到这里你应该能理解，大厂翻车不是“因为它是谷歌所以不该翻车”，恰恰相反，正是因为体量太大、链路太长，出了这种事反而更不稀奇。Minitap 这次选择把问题公开化，某种程度上也是被逼无奈，邮件、法务函在大厂内部流转几个月没有回音，往往是常态。

4. 从 mobile-use 事件看开源合规的核心常识

聊完了八卦和背景，这一节我想认真讲讲正事：开源合规这件事，到底牵扯哪些常识？不管你是个人开发者还是公司员工，这些内容都该刻进脑子里。

4.1 署名到底怎么署才算“注明出处”

“注明出处”这四个字看着简单，实际做起来很多人把握不住分寸。以 Apache 2.0 为例，标准做法是这样的：

• 复制代码文件时，保留文件头部的版权声明和许可证声明，原样不动；
• 如果你的项目整体使用了某开源项目代码，应该在项目的 LICENSE 或 NOTICE 文件中列出该项目名称、作者、原始许可证类型；
• 如果修改了原作品，需要在修改文件处显著标注“基于 XX 项目修改”，说明你不独占代码贡献。

很多开发者以为“在 README 里提一句感谢”就算注明出处了，这是不对的。感谢和许可证义务是两回事：感谢可以随便写，想写多诚恳都行；但从许可证角度，你需要的是“可追溯”的署名，当别人拿到你的项目时，能通过你保留的信息找到原始作者，这才是合规的完整闭环。

我在实际项目里见过一个比较规范的示例，对方在自己项目的根目录下放了 THIRD_PARTY_NOTICES.md 文件，里面列出所有依赖的开源项目，每一条都包含项目名、作者/组织名、许可证全文链接、以及“是否修改”的说明。这种文件在合规审计时可以直接作为证据，避免了“你说你用了，但查无实据”的尴尬。

4.2 给个人维护者的自我保护清单

回到 mobile-use 事件，我可以想象 Minitap 团队现在的心情。自己辛辛苦苦写出来的东西，被人拿走用了，反而要反过来证明“这是我的”，这个过程非常耗人。所以，给所有个人项目维护者一条最真诚的建议：不要等到被抄袭了才开始整理证据，平时就要把“自我保护”做进项目里。

我从自己的实践里总结了一份清单，分享给大家：

• LICENSE 文件永远是第一步：项目创建第一天就要定好许可证，并写进仓库。没有许可证的项目在法律上默认“保留所有权利”，别人不能用，但也不能证明你授权了什么。明确定下 MIT 或 Apache 2.0，是后续所有维权的地基。
• 保留完整的 git 提交历史：从第一个 commit 开始就带上作者信息和时间戳。commit 历史是你的“最早的发表记录”，一旦发生争议，它就是最客观的证据。
• 不要在代码里混入无法说明来源的片段：你自己用别人的代码也要注明出处，不然某天你反过来维别人的权，对方翻你的仓库也能找到“你也抄了”的反击点。
• 发布 release 时生成哈希值：针对核心文件保存一份 SHA-256 校验值。如果某天别人把你的代码原样拿走，你可以在维权材料里直接贴出“我的这段代码哈希是 A，你发布版本里的这段代码哈希不是 A 就是 B，对比一下就知道”。
• 记录版本发布时间并做好存档：GitHub 的 release 记录、npm 包发布时间、PyPI 上传时间，都能证明你在某个时间点已经公开了代码。这些时间戳会被后续审计经常用到。

这些工作看着零碎，实际做一遍花不了多少时间。但真到了需要维权的时候，它们就是你手里最硬的牌。

4.3 给企业开发者的合规自查清单

企业开发者的处境和个人维护者不一样，你手里通常没有项目的完整决策权，但你写出去的每一行代码，都代表着公司的法律风险。不管你在什么公司，都应该养成一个习惯：在使用第三方代码前，花一分钟确认它的许可证，并在代码提交信息里注明来源。

我自己在公司里做项目时会遵守一套简单的清单：

合并外部代码之前，确认这三件事：

• 来源项目的许可证是什么？如果是 MIT、Apache 2.0，可以放心用，但必须保留版权声明；如果是 GPL/AGPL，就要立刻停下来，确认它是否会“感染”你的商业闭源项目。
• COPYING、LICENSE 或 NOTICE 文件是否被一并复制？如果只是 copy 了源码文件，没拷许可证文件，严格来说已经不合规。
• 是否在项目的根目录或 README 中记录了第三方依赖清单？公司项目不比个人项目，人员会流动，三个月前“大家都知道的”第三方来源，三个月后可能没有人说得清，所以书面记录是唯一可靠的交接介质。

日常开发中养成两个习惯：

• 把“确认许可证”变成条件反射，每一次从网上复制代码都追一句“这是什么许可证”，这也是我推荐给所有新人的习惯。
• 在代码审查时留意可疑的外部代码痕迹，比如不常见的命名风格、突兀的注释、无出处的工具类函数块。一旦团队成员提交了源代码中没有版权信息的片段，要主动追问“这段代码哪来的”。

听起来像是在公司里给自己找麻烦，但换个角度想：如果你的代码让公司吃了一场开源侵权的官司，那才是真正的大麻烦。前期的多问一句，永远比后期的解释十句更划算。

4.4 自动化工具能帮你做什么

人难免有疏忽，且大型项目的第三方依赖数量动辄上百个，单靠人工去查许可证，不现实。好在业界已经积累了不少成熟的自动化扫描方案。像 FOSSA、Snyk、Black Duck 这类工具，可以扫描项目依赖树，自动匹配每个依赖的许可证类型，并在发现有冲突的许可证时发出警告。GitHub 本身的依赖图功能也能显示仓库中依赖项的许可证信息。

我的建议是：不管公司有没有强制要求，个人项目也都跑一遍这类扫描，免费额度对开源项目基本够用。扫描结果不仅能让你知道自己用了哪些“有版权负担”的代码，还能在项目页面上展示一个徽章，证明你是“合规友好”的。这在社区里是加分项。

5. 事件可能的走向与对 agent 开源生态的影响

最后，我们来聊聊这起事件接下来可能怎么走，以及它对整个移动端 AI 代理开源生态会有哪些影响。这部分更多是我个人基于经验推演的趋势判断，仅供参考。

5.1 Minitap 的诉求路径

从以往类似事件的处理惯例来看，Minitap 方面的诉求通常会经历三个层次。

第一个层次：要求公开承认并补充署名。这是在开源社区最常见的第一步。维护者的核心诉求一般是“你可以用我的代码，但你必须告诉大家这段代码是从哪来的”，方式是修改项目仓库，补上版权声明和 NOTICE 文件，并在发布声明里致谢原始作者。

第二个层次：要求删除侵权代码。如果双方沟通不畅，或者使用方拒绝承认，那诉求就会升级为“请删除所有涉事代码”，恢复到独立开发的状态。这一步对使用方代价极高，因为你要在短时间内在不影响项目进度的前提下，重写自己已经迭代过一段时间的关键模块。

第三个层次：正式法律途径。这一步成本最高、周期最长、对双方消耗也最大，但在 License 明确且证据链完整的情况下，原告的胜率并不低。所以通常在这个阶段，大厂更倾向于庭前和解，毕竟打官司的律师费往往高于“重新招人把代码重写一遍”的费用。

根据我的观察，像 Google 这种体量的公司，对外回应通常会走“道歉 + 补署名 + 加强内部流程审查”的路线，承认存在个别团队合规疏漏，然后强调公司整体尊重开源的立场。Minitap 这边大概率也能得到自己想要的形式上的说法——包括在项目文档中补上 credits，以及一篇有诚意的致歉声明。至于更进一步的赔偿，围绕代码许可纠纷的案例里不是没有，但比例相对有限。

5.2 谷歌可能的回应与项目后续

谷歌应该不会因为这件事就砍掉 Artemis 项目，毕竟放眼全球，几乎所有头部科技公司都在快速布局移动端 AI 代理。这个方向的战略价值太大了，不太可能因为一次开源合规纠纷就放弃整条赛道。更可能的是，团队会切割掉有争议的部分，在内部做一次彻底的代码审查，把与 mobile-use 相关的模块换成自己独立实现或基于其他合规第三方的替代方案。

除此之外，谷歌大概率会在内部强化一轮“开源许可证合规”培训和工具落地。实际上这类事件之后，大厂都会做一轮流程补课，一方面是真为了降低法律风险，另一方面也要给外界一个“我们改进了”的信号。比较讽刺的是，类似的事件在这几年并不少，每次发生后都能短暂地引起行业对合规的重视，但热度一过，又会回到原来的状态。

5.3 对整个开源协作体系的警示

如果让我说这起事件真正的价值，我觉得不是“谷歌如何回应”，而是它给整个行业敲了一声警示钟。

移动端 AI 代理是过去一两年增长最快的开源赛道之一。大量新项目像雨后春笋一样出现，很多团队为了快速入场，会去研究甚至直接借鉴头部项目的实现。从 mobile-use 这类基础框架被大规模复用的概率来看，类似“未署名使用”的情况可能不少，只是绝大多数没有浮出水面。

这起事件之后，预计会有两个层面的正向变化。在维护者层面，更多项目负责人会开始认真对待许可证版权声明，不会再把“开源”两个字当成“无版权”的同义词。在企业层面，技术决策者会在引入外部开源代码前加入更严格的许可证审查流程，尤其是在那些会被用于商业产品和对外发布的项目上，一步都不该省。

开源的本质是协作，不是掠夺。协作的前提是彼此尊重版权，这也是 mobile-use 事件最值得被记住的一点。

最后再分享一点个人的体会。我自己的小项目也曾经被人整段搬走过，对方把 LICENSE 文件删了，然后冒充成自己的东西挂到另一个平台。我当时气得好几天睡不着，但后来想明白了：与其生气，不如把项目做得更好、更独特，让后来者一眼就能看出谁才是正主。同时，我也更加坚定地在每一个新项目里把 LICENSE、NOTICE、CONTRIBUTING 和 release 记录做得完整，不是为了炫耀什么，就是为了哪天真要上场对质的时候，手里有牌可打。

希望 mobile-use 事件最终能有一个体面的结局，也希望每一位开发者的劳动成果都能得到应有的署名。毕竟，代码可以被复制，但署名是创作者该有的尊严。