克隆能做到的最好程度，就是打平
Perplexity 刚推出一个叫 /reverse-engineer 的功能。你把 Perplexity Computer 指向某个应用，它就能“在没有源代码的情况下分析这个应用如何运作，然后构建出一个可用的版本”。发布帖里展示了五个克隆作品，最抢眼的是 Figma：图层、自动布局、多人协作，一应俱全。听起来很疯狂？其实不止他们一家。自 9 月 30 日以来，一家叫 ArtCraft 的工作室已经上线了 13 个开源克隆项目，涵盖 Photoshop、Premiere、Word、Excel、Pro Tools、AutoCAD、Figma 等等，这些项目在 GitHub 上总共收获了约 17.2 万颗星。与此同时，成千上万人正在 PC 上原生运行 Switch 和 PS5 游戏，因为智能体从游戏的编译代码中把它们重建了出来。今年 5 月，我写过 SaaS 的未来是可以被克隆的。我也写过：“让 AI 去实现一个 SaaS 克隆，不该是‘嘿，帮我逆向工程一下这个’。”五个月后，“嘿，帮我逆向工程一下这个”已经成了一个产品功能。那么，如果一个智能体能在几周内重建你的功能，客户到底在为什么付钱给你？我不认为答案是律师。复制软件现在很便宜。把它做好，可不便宜。
每个克隆体都需要一个裁判
如果每次都能明确告诉智能体（agent）它做对了没有，它就能在一个问题上反复打磨数周之久。给智能体一个它无法争辩的检查标准，即便是小模型也能走得很远。
克隆体天生自带这种检查机制：反编译拥有最严格的裁判。重建出来的函数，要么编译后与原版字节完全一致，要么就不一致。有位开发者的智能体团队在约五个月里重建了《使命召唤：现代战争2》中 99% 的函数，其中 83% 达到了逐字节一致。到最后，他同时运行着 14 个小型 Luna 智能体和 2 个 Opus 智能体。
重写则可以利用原项目自带的测试套件。Cloudflare 用这种方式重建了 Next.js API 的 94%，花费约 1,100 美元的 token 费用。（前提是该测试套件是公开可用的。）
从外部重建，则以原版应用的行为作为答案。ArtCraft 的智能体规则要求它们“通过使用应用来观察行为”，然后依据公开规格说明来构建匹配的功能。
在上述每一种循环中，裁判都是原版，所以最高分只能是“一模一样”。克隆体最多只能打平。这个循环无法奖励“更好”，因为更好就意味着不匹配。它会像忠实保留原版的优点一样，忠实拉向原版的错误。而且，即便是打平也还差得远。PhotoCraft 自己的对等度追踪器评估，它在实际工作场景中大约只有 45% 的可用度（对标 Photoshop），并估计还需要 2,300 到 4,100 个 Opus 智能体小时才能达到完全对等。而每次 Adobe 发布更新，目标就又变了。
这些做法合法吗？
大体上取决于你怎么做的。以下不构成法律建议，但可以给个简要版本，文末 FAQ 还有更多内容：应用“做什么”通常是可以自由复刻的。版权保护的是代码、美术和文字，不保护想法、工作流或操作方法；自 1995 年 Lotus 诉 Borland 案以来，法院一直认为菜单布局不受保护。专利是例外。专利可以覆盖交互本身，从头自建也没用，因为独立发明不构成抗辩。Alias 的标记菜单——Maya 里那种甩一下就能选的环形菜单——从 1997 年到 2015 年一直受专利保护。Adobe 持有一项调整参数化色调曲线的专利（类似 Lightroom 的做法），有效期到 2031 年；2016 年上诉法院维持了陪审团关于三星侵犯苹果滑动解锁专利的裁决。自 2014 年 Alice 诉 CLS Bank 案以来，软件专利越来越难获得、也越来越难执行，但最大的几家现有厂商手里仍握着成千上万件专利。
你点过“同意”的那些条款，通常就不那么自由了。这才是关键。比如 Figma 的《可接受使用政策》规定，不得用 Figma“与 Figma 竞争，或复制服务的任何想法、功能、特性或图形”。Figma 起诉 Motiff 时，除了版权还主张违约；2025 年的和解要求 Motiff 停止在中国大陆以外所有地区销售其编辑器。Perplexity 的 Figma 演示正好撞在这条线上。它的技能基于 REA——一个开源工具，在浏览器里打开目标应用并记录看到的一切：页面结构、脚本、网络流量和截图。发布视频里，智能体在 Figma 内部做的正是这件事。用 Figma 复制 Figma 的功能，正是政策所禁止的，所以这个演示和 Motiff 面临同类的合同风险。
技术锁是明确红线。即使你什么都没复制，破解 DRM 或绕过许可证校验，本身就违反 DMCA。把克隆开源也没用：如果你本来就不被允许做它，免费送人也不能解决问题。
不过，假设你一切都按规矩来。那你最终到底得到了什么？
复制能带来什么
每个应用背后都是一堆决策。有些支撑着整个产品，有些只是偶然为之，还有些是团队恨不得明天就能推翻的妥协。从外面看，这些决策长得都一样，所以克隆者会照单全收。你拿到了决策，却没拿到背后的理由。你拿到用户喜欢的功能，也拿到用户抱怨的功能，比例一点不差。等你要改点什么的时候，团队里没人知道哪些选择是关键，因为没人参与过当初的决策。
这背后还有人力成本。有人花了好几年才搞明白那个面板为什么放在那里，什么时候该打破规则。一个智能体把每种行为都精确复制，等于拿走了答案，却丢掉了那个知道何时该变通的人。艺术家们为图像模型争论了三年，说的就是这件事。现在，同样的抱怨落在了另一门手艺上。
原创一直在往前走
克隆只是一个快照。做出原创的团队还在继续做决策，下一个版本照常发布，不管有没有人抄了上一个。有些公司更愿意用合同来保护自己。1982年，威斯康星大学教授 David DeWitt 发表了数据库基准测试，结果显示 Oracle 速度很慢。据说 Larry Ellison 打电话给 DeWitt 的系主任，要求把他开除。没成功，Oracle 就在许可协议里加了一条，禁止公开发布基准测试结果，大多数数据库厂商随后效仿。这条款后来被称为 DeWitt 条款，以他的名字命名。这里的基准测试说白了就是速度测试：让两个产品跑同样的任务，计时比较。你想跑多少测试都行，只是未经许可不能告诉任何人结果。Oracle 的许可协议至今仍写着，未经 Oracle 事先同意，不得“披露任何程序基准测试的结果”，这句话和禁止逆向工程的条款写在同一句里。2021年，Databricks 取消了自家的 DeWitt 条款，并呼吁其他厂商跟进。这才是一个自信的公司该有的样子：来吧，比一比。
话说回来，复制有时确实能赢，前提是复制者的覆盖面比原创者更广。Instagram Stories 2016 年上线，一年内日活用户就超过了 Snapchat。微软把 Teams 捆绑进 Office，直到欧洲监管机构介入：Slack 在 2020 年提出投诉，2025 年微软承诺在不含 Teams 的情况下销售其套件。但如今大多数 agent 克隆产品属于另一类：没有分发渠道的小团队，发布一个从上线当天就开始过时的快照。
现在什么才算好
那么，这些 agent 能力应该投向哪里？我会先从人们想完成的事情出发，而不是先看别人的应用。
有人录制 Loom 视频，是希望队友不用开会就能看到问题。有人在 Figma 里设计，是希望做出来的东西跟自己设想的一致。这些任务比任何一个应用的界面都更持久，所以应该瞄准它们。
有些东西值得原样复制。块、斜杠菜单、评论和大家都熟悉的快捷键，是用户期望的通用模式，软件一直在互相借鉴。没人会因为用了 Ctrl+Z 就付版税。
文件格式是另一个以精确复制为目标的地方。当有人把 Figma 文件或 PowerPoint 演示文稿导入你的应用，或者把作品导出回去时，它必须看起来跟原来一样。对于导入 Agent-Native Design 和 Slides，我们给 agent 设了一个像素对比循环：渲染原文件，渲染我们的导入结果，标出每个有差异的像素，然后持续修复被标出的部分。
在其他地方，跟原作比分数最多只能打平，所以要针对任务本身来评分。选一个真实任务，衡量人们完成它的效果：比如队友从录像里理解一个 bug 需要多久，或者把大纲变成一份能拿得出手的演示文稿需要改多少次。这些数字可以超过现有产品，这样「更好」才成为循环能够真正达到的分数。
然后，把省下来的精力花在现有产品不做的事情上。以下是 Agent-Native 的两个例子：
Clips 能让你的 AI 代理看到并听到屏幕录制内容。录制时，浏览器扩展会同步记下控制台报错和失败的网路请求，所以提交 bug 报告时证据一并附上。像 Loom 这类工具会把证据留在 DevTools 里，如果用 Loom 来评分，这个循环永远不会主动去要这些信息。
Design 是一块由代码构成的画布，你的代理可以直接使用。它不生成静态设计稿，而是基于你自己的设计系统，搭出一个能跑的 HTML 原型。如果用 Figma 的克隆来评分，标准会是画布跟 Figma 有多像。但真正的任务是让设计落地，交付能跑的代码，比交付一个矩形框强得多。
研究别人产品的时候，把每一处你选择做出差异的地方记下来，连同原因。产品团队有个现成的分类框架：Kano 模型，由质量研究者狩野纪昭在 1980 年代提出。它把功能分成三类：基础功能，缺了才会被注意到；性能功能，越多越好；惊喜功能，没人要求过，但一旦拥有就离不开。代理很擅长做基础功能，因为原产品就是完美的参考答案。惊喜功能则来自你那张清单。
一旦产品上线，任何人都能复制你做出来的东西。但那张清单更难复制。克隆能看到你改了什么，却看不到你为什么改、试过什么又扔掉了、清单下一步指向哪里。只要这套推理还留在你的团队里，它就是品味显现的地方，也是克隆拿不走的部分。
为无法克隆的东西收费
如果代理能重建功能，功能就不再是能收费的东西了。剩下的是克隆带不走的一切：团队、下一个版本、持续运行，以及出问题时人们得到的帮助。
这就是我们在 Agent-Native 软件套件上下注的方向。它采用 MIT 许可证，你今天就可以 fork 全部代码：Content、Mail、Calendar、Slides、Clips、Design，以及底层的框架。可以在本地构建、托管到任何地方，也可以在线构建和部署，用 Builder.io。我们更愿意为合理的东西收费，比如替你运行，而不是为任何人都能在几天内克隆出来的功能收费。
克隆产品最好的结果，也就是打平。
复制本就是 Agent-Native 的核心。其中的每一个应用，都希望你能 fork 过去、改造成适合自己工作方式的样子，底层的框架则用来帮你构建我们还没做出来的应用。如果有人把 Agent-Native 拿走、闭源，那他们卖的版本恰恰是谁都改不了的那一个——而偏偏这时候，别的一切都在变得更容易改。MIT 许可证确实允许别人这么做。但历史经验表明，只要原项目保持开源，这么干就长久不了。
2014 年，Node.js 的一些核心贡献者对当时运营该项目的公司 Joyent 的管理方式不满，于是把 Node.js 分叉成了自己的项目 io.js。后来 Node 交给了一个开源基金会管理，2015 年两个项目重新合并。只要上游还是最适合干活的地方，分叉终究会回来。
更棘手的问题是托管服务。AWS 开始售卖托管版 Elasticsearch 之后，Elastic 在 2021 年更改了许可证，AWS 随即分叉代码，做出了 OpenSearch。HashiCorp 2023 年改许可证，催生了 OpenTofu。Redis 2024 年改许可证，催生了 Valkey，而 Redis 也失去了大部分外部贡献者：改之前，12 名非雇员贡献了 54% 的提交；一年之后，没有任何非雇员的提交超过五次。Elastic 和 Redis 后来都重新加回了开源许可证。闭源并没有挡住复制，挡住的是贡献。
所以，我们的想法是这样的
如果有人能把 Agent-Native 托管得比我们更好，用户就能得到更好的产品，那我们就得加把劲跟上。我们宁愿在这个层面上竞争，而不是在许可证上较劲。
最让我兴奋的其实是贡献。当有人把自己的品味、自己 agent 的 token 投入到一个功能里，再把它提交回来，所有人就都能用上这个功能。开源让每个人花在 AI 上的钱，变成了共享的改进。
我们难道不想做出好东西吗？
我们现在所处的世界是：哪怕一个东西是闭源的，别人照样能克隆出来。既然如此，我们宁愿让克隆变得简单又免费，然后换回你的想法。
不管你是抄别人，还是被别人抄，最后赢的其实是同一样东西：一支能持续做出好决策的团队。一个智能体（agent）可以复制你已经做出来的东西，但复制不了你接下来会做什么决定。所以，尽管来 fork 我们吧。然后拿出更好的东西，再把它送回来，让所有人都能用上。
常见问题
反向工程软件合法吗？
多数情况下要看你想复制什么、怎么拿到手。在美国，从外部重新实现一个 App 的行为，在版权上通常是没问题的；法院也曾把“反汇编代码以理解其工作原理”认定为合理使用（Sega 诉 Accolade 案）。不过，大多数许可协议都禁止反向工程，而美国法院通常会支持这类条款，所以更大的风险其实是违约。绕过 DRM 或绕过许可证校验，本身就是违法行为。在欧盟，对于你已获授权使用的软件，你保留观察、研究和测试它的权利，合同不能把这项权利拿走。
如果我把克隆版开源，是不是就能克隆一个 App 了？
开源不会让克隆变得合法或非法。如果克隆版复制了别人的代码、美术资源或文字，就算免费分享，也仍然构成侵权；如果你在构建过程中违反了原版的条款，这个责任也依然在。变的只是追责的路径：版权方可以向 GitHub 发下架通知，而合同索赔则意味着要起诉那些同意了条款的人。
什么是洁净室（clean room）？这是一种在不复制原作的前提下，做出兼容产品的方法。一个团队研究原作并写出规格说明，另一个从没看过原作的团队，按照这份规格来构建。Phoenix 在 1980 年代就用它重建了 IBM 的 PC BIOS，Wine 和 ReactOS 等项目如今也遵循类似规则。现在有些 agent 项目也把工作拆给不同的 agent，用同样的方式分工，但还没有法院裁定过“AI 洁净室”算不算数。
不过，洁净室只能解决版权问题。如果原作的交互方式受专利保护，那么即便独立构建，也仍然构成侵权。
现在，agent 已经可以从外部重建 App 了。但每一个克隆都是拿原版来打分的，所以它能做到的最好结果，就是打平。下面说说你该去构建什么。