他不会写代码，但 AI 会
团队里多了这样一个人之后，权限、边界和审查都得重新设计——照搬来的那套会失效。
START
团队里多了这样一个人
他最懂客户实际怎么用、哪里别扭、哪个默认值不合理。他不写代码，但他可以让 AI 替他写。于是他开始参与开发——然后你会撞上下面这三件事。
| 你经历的 | 真正发生的 |
|---|---|
| 他说只是"改一下筛选条件"，结果一次会话改了几十个文件，你审不过来 | AI 把单个人的影响半径放大了。改动规模不再由他的能力决定，由 AI 的能力决定 |
| 他改的是自己那块，可上线后别处挂了 | AI 分析后认为要调公共接口，于是"顺便"改了——他看不出这个改动会影响谁 |
| 你想给他降权限，结果他每推一次都要找你，工作流直接跑不动 | 降权限治不了这个病。它拦的是"他主动越界"，而问题出在"AI 顺手越界" |
三件事有同一个根：多数协作规范都隐含一个前提——操作者是人，而且是会写代码的人。你的团队不是。照搬来的权限设计会在这个前提上塌掉。
MODEL
一个反直觉的推论
传统上，能改代码的人＝会写代码的人。所以权限设计约等于能力设计——给谁权限，就等于承认谁有能力。
现在不一样了：他的"能力"由 AI 提供，"权限"和"责任"仍然是他的。这两样第一次分开了。
推论是反直觉的：权限设计必须更严，而不是更松。
因为 AI 放大了单个人的影响半径。一次会话可能改几十个文件，而授权它的那个人看不懂那些改动对不对。能力上去了，判断力没跟上——这中间的差额，就是新增的风险。
三类参与者
| 参与者 | 性质 | 靠什么约束 |
|---|---|---|
| 人 | 决策者、责任主体 | 代码托管平台的权限（硬边界） |
| 大脑 | 理解需求、规划改动、出指令 | 它读得到的约定文件（软边界） |
| 双手 | 在明确边界内实际改代码 | 同上 + 自动化检查兜底 |
AI 没有独立的账号身份，它用的是授权它的那个人的凭据。所以 AI 的每一次提交，在系统眼里都是那个人做的。
好处：责任模型天然清晰——AI 干的活，责任在授权它的人身上，不需要给 AI 单独建账号。
代价：正因为责任归人，"谁是谁"必须先分清。共用一个账号时，所有产出混成一个主体，事后无法区分是谁授权的、出问题找谁。
把"谁是谁"分清楚这件事本身，是上一页的内容——别共用一个账号：先把账号架构理顺。
LAYER
权限管不住 AI 的手
平台权限 管「能不能推上去」 ← 硬边界，技术强制
约定文件 管「AI 会不会去改」 ← 软边界，AI 自觉遵守业务成员有推送权限，技术上能推任何目录。但真实风险不是他主动越界，而是 AI 顺手越界。
典型场景
他让 AI「修一下客户列表的筛选条件」，AI 分析后认为需要调整后端返回结构，于是"顺便"改了公共接口——而他看不出来这个改动会让别的地方挂掉。
AI 不会读你的权限设置，但它会读你写给它的约定文件。所以约束必须写在它读得到的地方。
| 只有硬边界 | 只有软边界 | 两层配合 |
|---|---|---|
| AI 照样在权限内乱改 | 权限没兜底，误操作直达生产 | AI 不去改 + 改了也推不上关键区 |
所以对这类团队，软边界比硬边界更关键——这是与传统团队最大的差别。
CORE
发现一个待优化点之后，先判断走哪条通道
这一节可以整块转发给要动手的人
发现一个待优化点
│
├─ 通道 C · 配置 ── 文案、默认值、话术、规则参数、字段顺序、阈值
│ → 直接在系统后台改，即时生效
│ → 不进代码库、不需要分支、不需要评审
│ → 目标：这条通道要覆盖 70% 以上
│
├─ 通道 A · 本目录代码 ── 只动自己主责的目录
│ → 大脑理解 → 双手改 → 本地验 → 推主干 → 自动化检查兜底
│
└─ 通道 B · 共享区 ── 需要加数据库字段、改公开接口
→ 停下来，写需求交给平台负责人
→ 由他评估、改结构、通知下游重新对齐A / B / C 判断法
| 通道 | 判断依据 |
|---|---|
| C | 改的是内容或参数——文案、默认值、阈值、顺序、规则参数 |
| A | 改的是自己主责目录内的交互或逻辑 |
| B | 涉及数据库结构或公开接口契约 |
为什么 C 是关键
| 走代码（通道 A） | 走配置（通道 C） | |
|---|---|---|
| 他要理解的东西 | 分支、构建、部署 | 只需会用系统 |
| 出错影响 | 可能构建挂、生产崩 | 界面上改回来 |
| 生效速度 | 提交 → 检查 → 部署 | 即时 |
| 占用负责人精力 | 每次都要审 | 定期抽查 |
| 他能独立完成吗 | 需要兜底 | 完全独立 |
「架构已经稳定、只是要优化操作逻辑」——这句话本身就在提示：大部分优化点很可能是参数和文案，而不是结构。
盘点表（可照抄）
正式分工之前，先把待优化点列出来逐条分类：
| # | 优化点描述 | 类型 | 走哪条通道 | 是否需要先做配置化改造 |
|---|---|---|---|---|
| 1 | 客户列表默认排序改成按最近跟进 | C | 后台配置 | 是——当前是硬编码 |
| 2 | 售后话术第 3 条措辞调整 | C | 后台配置 | 否——已可配 |
| 3 | 订单列表增加一个筛选条件 | A | 代码 · 主干 | — |
| 4 | 客户表需要加"行业"字段 | B | 交平台负责人 | — |
如果 C 类占多数——先把这些做成后台可配置，分工难度会下降一个数量级。这项改造工作量最大，但收益也最大：它决定了后续是"他能独立跑"，还是"每件事都要你兜底"。
CHECK
审查对象要上移一层
AI 写出来的代码通常不差。出问题的是它理解错了需求，或者做了额外的事。所以审查的注意力要从"写得对不对"上移到"理解对不对、范围对不对"。
| 重点看 | 而不是 |
|---|---|
| 改动范围对不对（有没有越界） | 代码风格 |
| 需求理解对不对（他要的是 A，AI 做的是 A 吗） | 变量命名 |
| 有没有引入不该有的东西（新依赖、新表、改了公共接口） | 缩进格式 |
| 有没有误提交（配置文件、密钥、构建产物） | 注释写得好不好 |
把注意力放在机器判断不了的地方。格式、构建、类型交给自动化检查；人只看机器判断不了的：范围与意图。
让 AI 自己报告越界
在那份 AI 每次会话都会读的约定文件里，加一条收尾自检，要求它在会话结束前主动输出：
- 本次改动涉及的目录清单
- 是否碰了不属于自己主责的目录？碰了要说明理由
- 是否改动了数据库结构或公开接口？改了必须提示走握手协议
- 是否新增了依赖？新增了要说明为什么
他看不懂代码差异，但他看得懂"我改了 XX 目录"这句话。让 AI 自己报告，等于给了不懂技术的人一个可执行的检查点——这比要求他去读代码现实得多。
RULES
三条纪律
面向所有用 AI 写代码的人，不分角色。
让 AI 动手前，人先提交一次。 —— 版本管理就是安全网。改坏了随时退回上一个干净状态——这一步花三秒，省下的是整晚。
大改动先开分支。 —— 改砸了删掉分支，主干毫发无损。
提交时精确指定路径，不要习惯性地"全加"。 —— AI 可能生成你没预期的文件。提交前扫一眼未跟踪的那些条目，别把不该进去的东西一起推上去。
NEXT
第一次一定要陪着走完
从一个真实的小需求开始，不要用假任务。走通一次，后面就是重复。
第一次的十步
- 让他先判断走哪条通道（C / A / B）——这一步最重要
- 若走 A：开工先拉取最新代码
- 用大脑描述需求，先看它的理解对不对，再让双手动手
- 动手前先提交一次
- 改完看 AI 的收尾自检报告：有没有越界
- 本地验证效果
- 扫一眼变更列表，确认没有意外文件
- 精确添加 + 提交 + 推送
- 看自动化检查是否通过
- 负责人按语义层审：范围对不对、理解对不对
最好的移交，是让大部分工作不需要移交。
把"需要开发能力才能做的事"降级成"会用系统就能做的事"——这比培训对方学一套开发流程便宜一个数量级，也比你替他做可持续得多。
自己学的下一步
三条通道能跑起来，前提是"哪份算原件、谁在执笔"这些事先定清楚了。那是配置本身的功课。
去看挽具怎么装找我们做
盘点待优化点、把 C 类改造成后台可配置——这件事工作量最大、也最决定分工能不能真跑起来。我们做过很多次。
了解配置服务伴读词条 · 概念词典第三层