摘要：研发团队用 AI 最大的障碍不是工具不好用，是代码要出门：核心算法、客户项目、未公开策略发给公有云，金融、量化、甲方外包的合同里就写着保密条款。马良 Harness 研发协作平台私有化部署在企业自有服务器：代码不出公司、会话留本地、账号账单归企业；一台服务器 all in one，需要外部协同或区分密级时接入多台，进工作区先选服务器，自有与合作物理隔离。一个入口，边界清楚。
AI 写代码的效率，技术老板们都认。但真要在全团队推开，很多人会在最后一步停下：代码要出门。
核心算法、还没公开的策略、带客户数据的项目文件，一旦贴进一个公有云服务，等于离开了自己的视线。厂商可以承诺一百遍安全合规，老板心里那道坎还是过不去——尤其金融和量化团队，一行策略就是钱；做甲方外包的团队，主合同里白纸黑字写着保密条款，代码出一次门就可能构成违约。
效率想要，家底不敢放。这道选择题，逼着大量团队要么咬牙冒险，要么让 AI 只在边角料上用，主力项目继续手工作业。
量化团队尤其如此：策略代码、因子库、回测数据是三条命，任何一条出现在外部服务器上，都可能意味着策略失效；做政务、军工类外包的团队更直接，招标条款里写明开发环境必须内网部署，根本不是选择题。团队并不是不信任某一家厂商，而是保密义务已经签在合同里——这种风险一旦发生，没有任何赔偿能对冲。
马良 Harness 研发协作平台给的不是折中，而是直接消掉题目本身：私有化部署，整套平台长在企业自己的服务器上。
一、私有化部署：工作发生在公司边界之内
部署完成之后，所有研发协作都在企业自己的机器上发生。
代码不出公司。项目的工作区就是企业服务器上的一个项目路径，工程师在浏览器里打开平台，左侧是团队与工作区，中间是会话窗口，右上角是批注模式，界面体验和任何云端产品一样顺滑，但底下跑的代码、存的文件，物理上都在企业机房或企业自有的服务器里。
会话记录留在本地。团队成员每天跟 AI 讨论了什么、AI 读过哪些文件、方案怎么一步步改出来的，这些研发过程中最敏感的上下文，沉淀在企业自己的磁盘上，不沉淀在任何外部平台的数据库里。
AI 账号是企业自己的。各家 provider 的账号由企业注册、企业充值，额度池在自己的平台里调度；连用量账单都不经过第三方平台，企业用了多少 token、花了多少，直接跟 provider 结算，中间没有任何人经手。平台不赚 token 差价——它连看账单的位置都没有，自然谈不上在用量上做文章。
对一个给银行做系统的十人外包团队，这意味着什么？意味着他们终于可以让 AI 进入真正的主力项目：需求拆解、代码生成、测试用例、评审辅助，十倍效率照拿，而交付审计时，他们可以指着自己的服务器说，客户的每一行代码都没有出过这道门。
工程师自己其实也别扭：用公有云 AI 时，帮助最大的恰恰是"把真实代码完整贴进去"，可越真实越不敢贴，只能贴脱敏片段、讲抽象问题，得到的帮助也跟着打折。保密约束最终没有惩罚到谁，只是让团队自己的 AI 效率长期只用了一半。私有化部署之后，他们第一次敢在主力代码上放开用——效率的闸门和安全的闸门，原本就该一起打开。
二、一台服务器 all in one：小团队的默认形态
对绝大多数十人左右的团队，一台服务器就够了。
worktree 隔离、release 主干与管理员合并、项目级权限、多 provider 账号额度池、会话与批注——整套能力 all in one 地跑在一台机器上。团队不用先搭一个平台研发组，不用集成五六个工具，私有化部署一次，立刻拥有一个完整的 AI 研发协作环境：每个人在自己的 worktree 里干活，发布要过管理员，谁能看哪个项目由勾选决定，多个 AI 账号在池子里统一调度。
对小团队来说，这才是私有化真正的门槛所在：不是愿不愿意花钱，而是有没有能力自建。让十个工程师里抽出两个人去维护一套自研协作平台，多数团队养不起，也不该养——他们的主业是把客户的项目做好，不是给程序员造工具。部署一次，全套到手，才是这个规模唯一现实的私有化方式。常规团队用一台标准服务器就能承载十来人的日常协作，有现成内网或专有云的，直接部署进既有环境即可。
而且这套环境不会被别人断供：平台是入口，AI 账号是企业自己的，哪天想增减 provider、调整账号池，团队自己说了算；会话记录、项目历史、权限结构持续沉淀在本地，用得越久，它越像团队自己养出来的研发底座，而不是租来的、随时可能被收回的工位。
三、需要隔离，就多接几台服务器：工作区先选服务器，再进项目
真实的研发协作并不总是关起门来一家玩。有外部合作方要联调，有外包供应商要参与某个模块，内部还有不同密级的项目必须分开。把这些东西全放进一台服务器，逻辑权限再细，很多老板也不踏实。
平台的解法是：多台服务器一起集成进来，在物理层面做边界。成员进入工作区时，先选这台服务器，再进服务器里的项目——服务器是第一道边界，项目权限是第二道边界，两层叠加。
切换动作非常直白：工程师登录后先看到服务器列表——"内部主机""合作主机"——选中一台，才进入这台机器上的工作区和项目。他在 A 主机上的会话不会出现在 B 主机，连搜索框都搜不到另一台机器里的任何文件名。边界不靠人记住规矩，而是写死在路径本身：你根本走不到那条路上。
典型的摆法是这样：A 服务器放自有团队的全部主力项目，核心算法、策略库、主干代码都在上面，只对内部管理员和正式成员开放；B 服务器专门放交付给合作方协同的项目，外部人员的账号只在这台机器上有效，他们能看到的世界从一开始就不包含 A 的存在；还有更敏感的封闭需求，单独再隔一台 C，物理上与其他服务器互不串门。
打开平台，入口仍然是一个，all in one 的体验不变；但入口底下，哪台服务器装着什么、谁能进入哪台，边界清清楚楚。这不是在软件里"假装隔离"，而是让敏感内容根本就不在同一台机器上——逻辑权限防的是误操作，物理隔离防的是不可能。金融团队常把这种摆法叫"一室一门关"：自营一室、合作一室、最敏感的项目再单独一室，每扇门的钥匙独立发放，谁也没法隔着墙串门。
四、自有高效协作，对外合作有界
多服务器结构同时满足了两个看似矛盾的要求。
对内，团队保持完整的高效协作：主力服务器上，十个人各自的 worktree 并行推进，会话、批注、测试报告、合并验收全在一个上下文里流动，上下游通过复制项目路径动态集成，版本永远一致。效率不因私有化而打一分折扣。
对外，合作变成一种有界的临时关系。合作方需要联调，就在 B 服务器上开项目、开账号、勾权限，他在自己的边界里跟 AI 干活，看到的测试报告和接口文档一分不少，但他永远摸不到 A 服务器上的主干；项目交付完毕，账号停用、权限收回，机器上该归档归档，合作方的访问从物理上终止。代码不出门，合作不串线，两件事第一次同时成立。
同时服务多个甲方的外包团队，还可以直接按客户摆：客户甲一台、客户乙一台，彼此物理隔绝，甲的代码永远不会在乙项目的会话里被 AI 引用——这种"串台"事故在共用环境里极难百分之百杜绝，而在多服务器架构里，它在物理层面就不成立。投标时讲"一客一环境"，也从一句口头承诺变成可以现场打开给客户看的架构图。
五、定位清晰：做十来人团队的台阶
这套架构对自己适合谁，非常诚实。
有超强研发能力的大厂当然可以照着这套理念自建一套——他们有人、有基础设施、有维护预算。它服务的是另一批数量庞大得多的团队：没有自研平台的能力，但已经有十几号工程师天天在用 AI 干活；有真实的保密约束和外部协作，却养不起一个平台研发组。对他们来说，私有化部署换来的不是一台服务器，而是直接跳过自建阶段，一步站到大厂级别的协作秩序上：隔离、权限、主干保护、额度调度，一次到齐。
这也是马良 Harness 研发协作平台整套设计的底色：企业的命根子，必须攥在企业自己手里。代码库也好，会话记录也好，账号账单也好，服务器边界也好——平台提供的是能力与秩序，数据的主权一刻都不离开企业。日后升级、扩容、接入新服务器，这条底线都不变：能力可以越用越强，边界始终画在企业自己的机房里。对老板来说，他终于不必在"拥抱 AI"和"守住家底"之间做取舍——这本来就不该是一道选择题。既要 AI 的十倍效率，又要核心资产绝对可控；既要内部高效协作，又要对外合作有界，这份"既要又要"，在私有化部署加独立服务器的架构里，不是奢望，是默认配置。
适合谁
它适合三类团队：一是金融、量化、医疗这类代码与数据天然敏感、受合规约束的研发组；二是给甲方做封闭交付、合同里背着保密条款的外包和服务商；三是已经有十几号人日常用 AI、且经常需要与外部合作方联调、希望把不同密级项目物理分开的成长期团队。越是主力项目不敢上公有云、但又最需要 AI 效率的团队，私有化的价值越直接。
私有化部署由平台负责部署与后续支持，服务器、运维和升级由企业承担，日常机器管理需要企业具备基本的 IT 条件。多服务器隔离解决的是"物理不串线"，开哪些项目、合作方看到什么颗粒度，由管理者按合同和信任关系亲自划定。