很多技术老板是在一次离职之后，才第一次认真想"权限"这两个字。递交辞呈的工程师上午还在改核心模块，下午开始交接，老板想盘点他手里到底有什么——笔记本上的代码副本、群文件里的历史资料、各个工具的账号、跟 AI 聊了几个月的会话记录……盘不出来。这篇文章谈我们在马良 Harness 研发协作平台里把权限做进系统的思路：协作建立在"授权可见"四个字上，而不是建立在"大家都是自己人"的假设上。
一、小团队的裸奔：协作建立在"大家都是自己人"上
十人左右的研发团队，权限通常是一种默认状态：进了群就是自己人，是自己人就能看见一切。代码仓库一个大组全开，项目资料在群文件里随取随用，外包人员为了联调方便，拉进来就顺手给了全部目录，测试同事想看测试报告，干脆共用一个账号。
这种粗放在办公室时代就有漏洞，只是那时候拷走代码还需要一个 U 盘，动作大、有痕迹。AI 时代，出口变得悄无声息：员工每天都在跟 AI 对话，把接口定义、报错日志、策略思路一段段贴进对话框，项目上下文随时可能随着会话流出去。管住代码仓库，不等于管住每个人手里的对话框。
而且 AI 对话的泄露比拷贝代码更难防：代码是一个个文件，边界清楚；对话是流动的，员工为了让 AI 帮上忙，天然会把背景越讲越全——客户是谁、为什么这么设计、上次在哪栽过跟头。这些碎片拼起来，就是一家小公司的全部 know-how。等交付结束，外包电脑里的代码可以要求删除，他脑子里和对话框里的东西，谁也收不回来。
一位做医疗系统集成的老板讲过一段真事：项目最紧的半年请了两名外包驻场，为了联调省事，代码库、文档库、测试环境统统对他们全开；项目结束人走了半年，他在另一个客户的竞标现场，发现对方方案里的接口设计跟自家如出一辙。他没法证明什么，甚至说不清对方到底带走过哪些文件——因为从第一天开始，"能看"和"能拿走"就是同一件事。
团队小，从来不是资产不设防的理由。恰恰相反，大厂丢一个模块还有十个模块和一层法务兜底，十个人的团队，核心代码可能就是全公司最值钱的家底，一次流失就伤筋动骨。马良点睛团队在做马良 Harness 时，对这类问题的回答只有四个字：项目级权限。
二、权限做在项目颗粒度：勾选一下，可见与不可见立刻分明
管理员在后台看到的是一张成员与项目的清单：谁是管理员、谁是操作员，每个成员对应哪些项目，全部用勾选框表达。给测试同事勾上这个项目，他登录后就能看到项目、进入会话、查看测试报告；不勾，他连这个项目在平台里存在都不知道——不是"点开提示无权访问"，而是项目对他彻底隐形。
这个区别很要紧。"知道有东西但看不到"本身就是信息：它暴露了团队在做什么、项目如何命名、有几条业务线。而在项目级权限下，每个人看到的平台，只由他被授权的那部分世界构成。
放到具体场景里：一个十人的工业软件团队同时跑三个客户项目，成员按项目编组。A 组五个人只看得到客户甲的项目，B 组三个人只看得到客户乙，技术负责人和老板两个管理员看全量。新来的工程师第一周只勾了培训用的演示项目；外部顾问只勾他要评审的那一个模块。勾选、生效，是同一个动作，不需要找谁改配置文件，也不需要等运维排期。勾错了也不慌：当场取消，对方的访问下一秒就结束，不用重启任何服务。
角色同样一目了然：管理员负责开人、开项目、收权限，是守门人；操作员只在被授权的项目里干活，授权之外的世界对他不存在。技术负责人不必再维护那份"谁知道哪个仓库密码"的口头清单——权限第一次以系统记录而不是群聊记录的形式存在。遇到客户审计，管理员导出的也就是这张清单：谁、在什么时间段、对哪些项目有访问权，系统里是什么就导出什么，不用临时补台账。小团队平时嫌流程麻烦，往往是因为流程全靠人肉维持；当勾选本身就是流程，合规不再是额外负担。这套设计还有一个常被忽略的好处：它让"最小授权"从一句合规口号变成了默认动作。过去为了省事，管理员倾向于一次给全开、以后再说，结果权限越堆越乱；现在多勾一个项目就是多一次明确的授权决策，管理员在勾选的那一刻就在思考"他到底需不需要看这个"，最小权限原则不再靠事后审计来纠偏。
三、项目内与项目间，同一套"授权可见"的规矩
这套权限同时覆盖两种协作。
项目内，权限决定了谁能进入这条工作路径、谁能看到这个会话、谁能提交。被授权的成员在自己的工作路径里跟 AI 对话、改代码、看批注，所有动作都发生在授权边界之内；没被授权的人，会话和工程对他完全关闭。
项目间，权限是上下游协作的开关。一个很典型的画面：上游团队做好了一个工程化模块，下游团队要集成。过去这意味着打包、发邮件、拉群、对版本；现在上游管理员在后台把这个项目勾给下游对接人，对方刷新一下就能进入项目——看到完整的测试报告、进入会话直接沟通、把模块拿出来动态集成。上下游之间交付的不再是一堆文件，而是一个带上下文、带会话、随时保持最新的活项目。
哪天合作结束，或者对接人换了，勾一去掉，访问立刻终止，不需要对方"自觉删除本地副本"——因为本地压根就没有副本，一切都在服务器的项目路径上。
一个十人物联网团队的用法很典型：固件组是上游，把底层通信模块做成独立项目维护，应用组三个人在各自的应用项目里调用。每次新版固件就绪，固件组把项目权限开给应用组，应用组进入会话就能看到这一版改了哪些参数、兼容性如何，立刻在自己的工作路径里完成适配；固件组事后收回权限，也不影响已经完成的集成——授权期间的交付物已经长在应用项目里，而访问通道随时关得上。
权限不再是入职时一次性发完、从此无人问津的东西，而是随每个项目、每次合作动态收放的日常开关。
四、入职开权限，离职收权限：人员进出变成行政动作
平台还管着更底层的一件事：这个人能不能登录、用什么邮箱登录，都由管理员统一管理。于是人员进出团队，第一次变成了一个干净利落的行政动作。
新人入职，管理员建账号、勾项目，十分钟内他看到的就是他该看到的世界，不多也不少；人员离职，账号停用、权限收回，他的会话留在服务器上归档，他参与过的项目纹丝不动，新人接手直接进入同一条工作路径继续干。项目资料始终留在服务器、留在公司，从来没有"存在谁私人电脑里"这个中间状态。
新人接手时拿到的也不只是代码：上一任跟 AI 讨论过的方案、试过又放弃的路径、管理员留下的批注，全在同一条工作路径里。交接不再是一句"文档你先看看，不懂问我"——而"问我"在人离职之后，通常意味着永远问不到了。
对老板来说，这等于把团队的核心知识资产放进了一个有门有锁的房间：谁进来、谁出去、谁能进哪间屋子，全部有记录、有开关。能力沉淀在系统里，流动的是人，带不走的是家底。
五、AI 时代的组织级锁：连对话出口一起收进边界
为什么这件事在今天格外关键？因为研发团队最核心的资产，正在从"代码文件"变成"代码加围绕代码产生的全部上下文"——需求讨论、报错分析、方案取舍、跟 AI 反复打磨的推理过程。这些东西散在各台电脑、各个对话框里时，它们是员工的私产；收拢到一个按项目授权的平台里后，它们才成为公司的资产。
工作路径隔离保证了各干各的不互相干扰，release 闸门保证了主干只进过验收的代码，项目级权限则回答了更靠前的那个问题：这个人，配不配看见这个项目。三层机制叠在一起，构成的是一道组织级的锁——不靠自觉，不靠吼，人员流动再频繁，家底始终在房间里。
对十人团队，这件事的真正分量在于：小公司抗风险的方式不是事后追责，而是事前让流失在物理上难以发生。权限收拢之后，员工离开时带走的只有他自己的经验，带不走一行代码、一段会话、一份客户资料。这不是不信任员工，恰恰是让信任不必承担它不该承担的重量——关系归关系，边界归边界，好聚好散才有基础。
说回开头那个离职场景。如果今天团队里有人要走，老板能不能在十分钟内说清他碰过哪些项目、看过哪些代码、跟 AI 聊过哪些内容？你们团队现在的权限，是建在系统里，还是建在"大家都是自己人"这句话上？
