同样的培训、同样的工具，0% 和 91%
本连载整理我在一家为药房开发服务的开发组织负责 AX（AI 转型）期间，于 2026 年 6 月至 10 月搭建的东西，共七篇。第 1 篇讲起点，第 2 至 6 篇逐一讲五个阶段，第 7 篇讲沉淀下来的原则和放弃的做法。
起点是一个数字。9 月 16 日，我在业务指标看板上按人统计了提交。提交是保存工作内容时留下的一条记录，就像游戏的存档，记录了什么时候改了什么。用 Claude Code 这类 AI 工具工作时，这条记录末尾会加上一行“AI 共同编写”的标记。
在培训相同、工具相同的组织里，带这个标记的提交占比，一位设计师是 91%，一位开发者是 0%。中间有四人在 80% 区间、两人在 40% 区间、一人 15%。这个数字不是为了排名，而是为了看清谁卡在哪里，结果很明确：这不是多培训一次就能缩小的差距。
值得一提的是，用 AI 最多的不是开发者，而是设计师。区分大家的不是岗位，而是有没有把 AI 嵌进自己每天的工作里。
转变的第一句话——改 AI，而不是改人
方向早在 8 月 27 日就用一句话留在了开发频道里：“尽量不改变人的行为模式，用 AI 来覆盖。”之后的所有案例都出自这句话。
意思很简单。与其培训大家“不要把含密码的文件给 AI 看”，不如在 AI 试图读取那个文件的瞬间由设置先拦下。与其叮嘱大家“工作汇报先写结论”，不如用设置规定 AI 写的文字格式。人照原样工作，规则放进大家共用的 AI 里。
这样规则就不依赖任何人的记忆。新人从第一天起就在同样的规则下工作，规则一改，所有人同时生效。培训照样做，但原来靠培训维持的事交给了系统。
从 2022 年到 2026 年 10 月
走到这里的路并不笔直，尝试和碰到的问题交替出现。下表按时间顺序列出。
如表所示，在购买工具（2025 年 8 月）、考虑换用其他模型（2025 年 12 月）、提议黑客松（2026 年 3 月）期间，一直是用的人用、不用的人不用。9 月用数字确认差距后，做法变了；10 月“175 条审查意见只改了 33 条”这个数字推动了下一步。
| 时间 | 发生了什么 |
|---|---|
| 2022.02 | AI 还是研究课题 |
| 2025.08 | 开通 Cursor 和 Claude 团队账号 |
| 2025.12 | 研究是否换成 Gemini |
| 2026.03 | 提议举办黑客松 |
| 2026.09 | 确认 AI 提交占比 0~91% 的差距 |
| 2026.09 | 代码仓库迁到 GitHub，启动 KB 和度量 |
| 2026.10 | 确认 175 条审查意见只改了 33 条 |
| 2026.10 | Claude Team 托管设置到了第 19 版 |
搭建的五样东西——一览
从 6 月的规则仓库到 10 月的每日复盘任务，共五样。前四样把原来靠人记住的事交给 AI 和设置，第五样每天修正前四样。
第五样最关键。每天早上自动运行的复盘任务找出重复的错误，变成规则修改、公司文档更正和审查教训，再回到第 1 至 4 步。这段旅程的目标不是搭一次就完，而是建立一个能自我修正的循环。
表中的术语会在各篇配合真实界面解释，这里只看流程：把规则集中到一处，让它以无法关闭的方式跟随每个人，编写 AI 能读的公司文档，设立合并前必须通过的关卡，并每天修正这四样。
| 阶段 | 做了什么 | 开始 | 截至 10 月 |
|---|---|---|---|
| 1. 通用 AI 规则 | 改一处，7 个项目和所有电脑上的 AI 一起改变 | 2026.06 | 自动复制 95 次全部成功 |
| 2. Claude Team 托管设置 | 用组织账号登录即生效、个人无法关闭的设置 | 09-18 第 1 版 | 10-23 第 19 版 |
| 3. KB | 让机器人、编程 AI 和人读同一份公司文档 | 2026.04 | 10-02 成为全员正本 |
| 4. 关卡 | 通过 AI 审查和界面检查才能合并 | 10-01 试行 | 10-13 起 47 个项目必检 |
| 5. 每日复盘 | 早上的任务修正规则、文档和审查教训 | 09-24 | 每天五个任务 |
连载顺序
第 2 篇（11 月 9 日）讲通用 AI 规则，用真实界面看改一处规则仓库、2 到 5 分钟后复制到七个项目的结构。
第 3 篇（11 月 10 日）讲 Claude Team 托管设置，第 4 篇（11 月 11 日）讲 KB，第 5 篇（11 月 12 日）讲 AI 审查与界面检查关卡，第 6 篇（11 月 13 日）讲每日复盘，第 7 篇（11 月 16 日）讲沉淀的原则、放弃的做法和尚待完成的事。
每篇末尾都有“今天可以试的一件事”，只选不在开发组织、独自使用 AI 的人也能在自己电脑上试的事。
今天试一试——统计自己仓库的 AI 提交占比
起点的数字一个人也能算。仓库是把项目文件和变更记录放在一起的文件夹，git 是处理这些记录的工具。在 Mac 的终端或 Windows 的 PowerShell 中进入仓库文件夹，依次运行下面两行。
第一行统计过去 30 天的提交数，第二行统计其中带有“Co-Authored-By: Claude”一行的提交数。用 Claude Code 提交时，默认会在提交信息末尾加上这一行。第二个数除以第一个数就是占比。我的网站仓库是 75 条中 53 条，71%。
如果是团队，加上 --author="姓名" 按人分别统计。这个数字应视为下限：人工提交 AI 写的代码或关闭标记时不会被统计。即便如此，如果每个人的数字差距很大，在再培训一次之前，该看看大家共用的 AI 的设置了。第一步就是下一篇的通用 AI 规则。
git log --since="30 days ago" --no-merges --oneline | wc -l
git log --since="30 days ago" --no-merges -i --grep="Co-Authored-By: Claude" --oneline | wc -l