Insights·2026-11-09

公共 AI 规则——改一处规则仓库,2~5 分钟后 7 个 repo 的 CLAUDE.md 一起更新

公共 AI 规则,是把组织里所有 AI 开工前都要读的规则集中在一处管理的做法。把规则当作文件发通知,只有读过的人的 AI 会遵守。于是规则不再交给人,而是放到 Claude Code 每次会话都会先读的 CLAUDE.md 里。原件只放在一个规则仓库,一改动,GitHub 的自动执行功能就会在 2~5 分钟内复制到 7 个服务仓库。截至 2026 年 10 月 21 日,最近 95 次复制全部成功;成员电脑拉取最新版后,从新会话开始按同一套规则工作。本文整理这套结构、规则写了什么,以及今天一个人也能试的 CLAUDE.md 三行。

承接前文接受同样的 AI 培训,AI 提交占比却分成 0% 和 91%——所以我改的不是人,而是 Claude Code 设置
GitHub 규칙 저장소 core 폴더 — AGENT_WORKFLOW.md, AI_BEHAVIOR.md, COMMON_RULES.md, JIRA_ISSUES.md, REVIEW.md, SECURITY.md, STYLE.md, WORKFLOW.md 여덟 문서와 review-lessons.json, 각 파일의 마지막 변경 메시지가 보이는 화면
실제 화면 · 규칙 저장소 core 폴더 10-21 · 모든 저장소에 공통으로 들어가는 규칙 문서 여덟 개

规则在文件里,只有读过的人遵守

这是「AX 旅程」连载的第二篇。我在一家为药房开发服务的开发组织负责 AX,2026 年 6 月到 10 月铺了五样东西,本篇讲第一样:公共 AI 规则。

一开始用的是常见办法:把要遵守的事写成文件发通知。结果也很常见:读过文件的人,他的 AI 按规则做事;没读的人,他的 AI 随意发挥。同样的请求,因人而异。

8 月 27 日留下的一句话改变了方向:「尽量少改变人的行为习惯,用 AI 来补上」。与其让人背规则,不如让 AI 每次开工时自己去读。

CLAUDE.md——AI 每次开工先读的便条

Claude Code 是 Anthropic 推出的、在终端里通过对话读写代码的 AI 工具。如果工作文件夹最上层有一个名为 CLAUDE.md 的文件,它在每次会话开始时都会先读。这就像贴在新同事桌上的工作便条,不同的是这位同事从不漏看。

于是规则的位置从公告栏搬到了 CLAUDE.md。不需要人记住,在那个文件夹里工作的每个 Claude 都读同一套规则。

问题是文件夹不止一个。这个组织的服务代码分散在 7 个仓库里。仓库(repo)是存放一个项目的代码和修改记录的共享文件夹。药房网站、管理后台、App 前端与服务器、广告服务器——要是手工往 7 处复制同一套规则,一定会有人只改了一处、忘了其余。

从一个规则仓库到 7 个 repo,再到每台电脑

GitHub Actions「Sync AI rules」运行列表——共 95 次运行,10 月 19~21 日每次规则提交都在 develop 上自动执行,耗时 2 分 11 秒~4 分 54 秒,全部绿色对勾成功
真实画面 · GitHub Actions「Sync AI rules」运行列表 10-21 · 每次改规则自动运行,复制到 7 个仓库

所以把原件集中到一处:另建一个只放规则的规则仓库,7 个服务仓库里只放副本,谁也不直接改。要改的地方永远只有一个。

复制不靠人。把修改提交到规则仓库的公共工作主线(develop 分支)后,GitHub Actions 会运行名为「Sync AI rules」的任务,把规则复制到 7 个仓库。GitHub Actions 是仓库一有变化就替你执行预设任务的 GitHub 自动执行功能。如画面所示,每次约 2 到 5 分钟;截至 10 月 21 日,最近 95 次全部成功。

成员电脑执行一次拉取最新版的命令(git pull)后,从新会话开始就用新规则。改规则的人要做的不是发通知,只是提交一个修改。

画面里 10 月 20 日晚到 21 日这两天,规则就改了五次。要是靠通知,就得发五次通知,再问五次「看了吗」。

8 条 core 规则写什么

GitHub 规则仓库 core 文件夹——AGENT_WORKFLOW.md、AI_BEHAVIOR.md、COMMON_RULES.md、JIRA_ISSUES.md、REVIEW.md、SECURITY.md、STYLE.md、WORKFLOW.md 八份文件和 review-lessons.json,以及各文件最后的修改说明
真实画面 · 规则仓库 core 文件夹 10-21 · 所有仓库共用的八份规则文件

规则仓库分两层:core 里是原样放进所有仓库的 8 份公共规则文件;其下是 7 份项目规则,写各仓库不同的内容(所用技术、部署方式)。公共规则按工作顺序、AI 行为原则、事项写法、评审、安全、代码风格等主题划分。

AI 每次都读的规则里,效果最大的是三条,下表写出含义和理由。提交(commit)是把修改打成一个包保存,分支(branch)是为了不碰原件而另外分出来的工作线。

规则句子要短,并且能检查。「谨慎工作」无法判断 AI 有没有做到,「未经要求不 push」做没做到一目了然。能检查,才能搬进下一篇要讲的自动检查。

规则含义为什么加
未经要求不 push把本机修改上传到共享仓库(push)只在人指示时做上传到共享仓库的修改会立即影响别人的工作和服务
1 个事项 = 1 个分支 = 1 次提交 = 1 次 push一件事对应一条工作线、一次保存、一次上传任何修改都能顺着一个工单号追溯原因
每个完成条件先写测试改代码之前,先写用代码确认「完成」标准的测试AI 说「做完了」时,由测试替你核实

规则只是请求——所以还需要下一步

规则仓库改变的是工作的样子。想改规则的人不发通知,而是提交一个修改建议。画面里的修改说明多次出现「反映 AI 评审反复指出的问题」,原因就在这里:AI 评审里反复出现的同一指正,第二天就变成一行规则。这个循环在连载第 6 篇「每日复盘」里细讲。

局限也很明显。CLAUDE.md 是对 AI 的请求,大多会遵守,但不保证每次都遵守;个人在自己电脑上再加别的设置,结果又会不同。

所以进入第二步:必须遵守的规则,从请求改成无法关闭的设置。下一篇「Claude Team 托管设置」讲的就是这个。

今天试一件事——在 CLAUDE.md 写三行规则

如果你在用 Claude Code,就在工作文件夹最上层建一个 CLAUDE.md,写入下面三行。在 Claude Code 里输入 /init,它会读取文件夹并生成 CLAUDE.md 草稿,也可以把三行加在草稿末尾。

保存后开一个新会话,问它「说说你刚读到的本项目规则」。它原样说出三行,就说明生效了。

如果文件夹很多,想让所有工作都用同一套规则,就写进对整台电脑生效的 ~/.claude/CLAUDE.md。一旦扩大到团队,需要的就是本文的规则仓库。

CLAUDE.md
# 本项目的规则
- 我没吩咐之前不要 push。
- 修改之前,先写好检查完成条件的测试。
- 不知道的事实不要编造,写「未确认」。
来源: SH Consulting AX 구축 사례(약국 서비스 개발 조직, 2026-06~10)를 정리