事件概述

OccupySaaS 是一个自称“用代码写成的抗议运动”的项目，2026 年 10 月上线，采用 Apache-2.0 许可。它的主张很直接：在一轮又一轮科技裁员之后，被裁掉的工程师用 AI 和公开文档，为那些按席位收费的商业 SaaS 平台构建**清洁室（clean-room）、开源、可直接替换（drop-in）**的实现。

网站上的核心口号包括“We are the 1,000,000”“Fork the 1%”“Spec, not stolen code”，并把 2011 年 Occupy Wall Street 的“1% 与 99%”叙事迁移到云计算订阅经济上：认为按席位定价是对增长的“税”，专有 API 与导出壁垒构成锁定，而平台在持续涨价的同时裁掉了构建它们的人。

首批公开的两个项目分别对应身份认证与 CRM 这两个几乎每家公司都在付费的品类：

  • ZeroAuthy：用 Go 编写的自托管身份服务器，目标是兼容 Auth0 Authentication API。现有 Auth0 SDK 把域名指向 ZeroAuthy 租户即可工作，无需改代码。已列出的能力包括 OIDC discovery、JWKS、多租户域名、托管登录页、authorization code + PKCE、client_credentials、轮换 refresh token、revoke 与 logout，并用 auth0-spa-js、auth0-react、nextjs-auth0 验证。
  • SalesCompel：Salesforce 的开源替代，Go + PostgreSQL 的多租户核心，Vue 记录编辑器，配套一个对照 Salesforce 公开 API 契约做行为校验的兼容性实验室。已列出的能力包括 Account/Contact 的持久化 CRUD、对象 describe 与受限查询、External-ID upsert、bearer 认证，以及 OpenAPI 3.2 REST 契约与离线测试实验室。

路线图上还挂着文档/wiki、工单系统、Feature Flags、可观测性、客服台等“拟议”品类，并明确标注这些只是开放讨论、不构成承诺。

需要说明的是：原文未说明两个项目的代码成熟度、性能数据、安全审计情况、贡献者规模与资金来源；ZeroAuthy 与 SalesCompel 均被标注为 “Early”。

关键技术点

1. 清洁室流程被工程化为一套可检查的制度

OccupySaaS 明确划出一条信息防火墙：允许的输入是公开 API 文档、开放标准与 RFC、公开 SDK 的可观察行为、黑盒测试结果；禁止的是泄露或专有源码、反编译二进制、前雇主的保密信息、复制的 UI 资产与商标。

执行层面有两条设计：一是规格撰写者与实现者分离；二是每个仓库携带 CLEAN_ROOM.md 策略文件，并对每个 fixture 与参考材料记录来源（provenance）。对于曾在该公司任职的贡献者，原文的立场是：可以参与，但绝不能带入前雇主的保密知识；具备相关内部知识的人应留在防火墙的“公开规格”一侧，或干脆回避该项目。

2. 规格先行、契约优先的 AI 实现流水线

原文描述的构建方式是：先把公开 API 参考、OAuth 2.0 / OIDC / REST 等开放标准、已发布的 SDK 行为写成书面规格；然后由 AI Agent 仅依据规格实现——先写契约（openapi.yaml），再写代码，再写测试，且每一次合并都有人工评审。AI 承担的是“防火墙构建侧”的重活。

这也是该运动最值得关注的方法论主张：把 AI 编码从“让模型猜需求”改造成“让模型在封闭输入下满足一份可验证的规格”。

3. 兼容性实验室作为验收标准

项目的完成定义不是“功能差不多”，而是：用厂商自己公开发布的客户端 SDK 去打自己的服务端，如果现有调用方代码不能原样跑通，就不算完成。SalesCompel 直接把这一实验室开源（Node 客户端 + npm run check）。这个思路把“兼容”从主观描述变成了可回归测试的工程门禁。

4. 部署与许可姿态

Apache-2.0、可自托管、可插拔存储（ZeroAuthy 列出 SQLite / PostgreSQL / MySQL 与 gRPC 插件）、无未告知的遥测、无席位计数器。这实际上是产品定位的一部分：把“你的数据在你的服务器上”作为对锁定策略的直接回应。

对数据科学或 AI Agent 落地的意义

这个项目对 AI 工程实践的参考价值，可能大于它对 SaaS 市场本身的冲击：

  • AI Agent 的可信落点在于“受约束的输入 + 可验证的输出”。规格由人写、代码由 Agent 写、验收由厂商公开 SDK 跑，三者构成闭环。这比“Agent 自主决定做什么”更接近企业愿意付费的形态。
  • 契约优先是 Agent 协作的接口层。先产出 openapi.yaml 再生成实现，使多个 Agent（或人与 Agent）可以在同一份机器可读契约上并行工作，评审点也自然落在契约与测试上。
  • 来源追溯（provenance）正在成为 AI 生成代码的合规基础设施。清洁室要求逐条记录参考材料来源，这与当下对训练数据、生成代码来源的审计需求是同一类问题。
  • 对数据科学的直接意义有限但间接明确：原文未说明任何数据分析、模型训练或指标体系建设方面的内容；其价值主要在工程流程与合规框架层面，而非算法层面。

我的技术点评

第一，清洁室 + AI 的组合是一个聪明的法律—工程折中，但风险并未消失。清洁室实现本身是长期存在的合法路径，原文也说明“与 API 互操作不等于复制产品”，并提示这不是法律意见。真正的新变量是 AI：当实现由模型依据规格生成时，“独立编写”这一主张需要有足够细的 provenance 记录来支撑，否则在争议中很难自证。项目把 CLEAN_ROOM.md 和 fixture 来源写进仓库，方向是对的，但原文未说明是否有第三方审计或代码相似度检测机制。

第二，drop-in 兼容的难度被口号掩盖了。Auth0 的“兼容”不只是 OIDC discovery 和 JWKS，还包括多租户语义、refresh token 轮换的边界条件、错误码与限流行为等大量隐性契约；Salesforce 的对象 describe 与查询语言更是深水区。用公开 SDK 做回归测试是正确起点，但“通过公开 SDK 测试”与“生产环境可替换”之间仍有距离。项目自己标注 Early，这个判断是诚实的。

第三，per-seat 定价确实是最容易被攻击的靶子，但开源替代的商业闭环不在代码里。自托管省掉了席位费，换来了运维、升级、合规与安全响应的成本。历史上这条路径的成功案例（如数据库、可观测性领域）往往依赖一家商业公司提供托管服务；OccupySaaS 目前呈现的是运动式协作 + 捐赠（Buy Me a Coffee），原文未说明长期治理与维护模式，这是比技术更难的题。

第四，对 AI Agent 落地而言，这是“Agent 作为受限实现者”的一个清晰样本。它没有宣称 Agent 能自主做架构决策，而是把 Agent 放在规格之后、人工评审之前。这种保守定位反而更容易在企业内复制——尤其是那些已经有公开 API 契约、又想做内部替代或迁移的团队。

最后提醒一句：这是一个带有强烈叙事色彩的运动型项目，站点上的数字与口号（如“1,000,000”）属于动员语言，不应视为统计事实；评估其代码时应以仓库实际状态与兼容性测试结果为准。

原文链接