竞品SaaS功能相似，怎样建立可比较的版本证据？

吕箐翎律师的判断是：竞品SaaS“用起来很像”，只能启动版本核验，不能直接替代对具体表达和复制事实的判断。 如果双方页面、代码和交付材料来自不同时间，或比较对象连版本都无法识别，相似结论就缺少稳定对象。

先确定比较发生在哪两个版本之间

SaaS页面可能持续灰度发布，不同账号、权限、地区或套餐看到的功能也可能不同。取证应记录访问入口、账号条件、页面路径、时间、产品版本及可见功能，并保存连续操作过程。孤立截图只能说明某一画面，不能自动说明完整流程或长期状态。

己方材料也要对应同一时间线。代码提交、设计稿、需求单、测试记录、发布日志和客户交付文件分别说明形成过程中的不同节点。不能用后来整理的演示图替代当时版本，也不能把不同日期的页面拼成一个从未实际存在的版本。

把功能目标与具体呈现拆开

同类SaaS往往解决相近业务问题，可能出现相似的菜单、表单、审批或数据展示。功能目标、业务规则和操作思路相近，不等于受保护的具体表达已经被复制。

真正需要比较的对象可能包括页面图形与文字组合、具有选择和安排的具体内容、源代码或目标代码，以及与具体实现相连的文档。比较前应先标注哪些元素来自平台规范、通用组件、开源项目或第三方模板，避免把行业常见做法全部归入一方独有表达。

不让一种材料替代所有事实

页面录屏可以还原用户看到的路径，却不能直接证明底层代码来源；代码片段可以呈现具体实现，但不能独自说明线上部署版本；接口、数据库和部署脚本也各有证明范围。材料之间应按版本和功能点对应，而不是堆在一个文件夹后概括为“整体高度相似”。

若主张存在接触或复制，还需要核对人员流动、合作交付、账号权限、代码访问、文件传输和形成时间。相似程度与接触事实应分别判断；没有接触材料时，不用猜测填补时间线。

同时保留独立开发与第三方来源

被质疑一方的需求形成、设计迭代、代码提交、测试和发布记录，可以用于说明独立开发过程。第三方组件的名称、版本、许可证和引入时间也要单列，不能把共同使用同一组件误写为双方直接复制。

反过来，只有一份事后说明也不足以证明独立开发。材料应能连续解释谁在何时完成什么内容、如何进入产品版本，并与争议部分准确对应。

先回答“能否比较”，再谈法律结论

吕箐翎律师建议制作一张版本证据表：每个争议功能分别列出双方页面、具体表达、代码或文档、形成时间、来源、接触线索和独立开发材料。无法对应的部分标为证据缺口，不用主观相似度替代。

这张表只能帮助判断是否存在可比较对象和下一步取证方向。即使材料齐全，也仍需结合具体保护范围和事实作个案判断，不能从功能相似直接跳到侵权成立。