6年前我写过《如何让规章制度活起来？》，里面我提到 raw 的想法，或者 Markdown、LaTeX，核心想法很简单：制度不应该只是 Word 文档，而应该是“结构化文本”。3个月后我又写了《一次经典的规章制度活起来的实践》。我已经忘记当时写那段 JavaScript 代码花了几天，那时候这件事成本不低，需要一定的开发能力。

但现在情况完全不一样了。大模型和智能体出来之后，一个很直接的变化是：很多原来属于“开发者”的能力，开始变成“普通人也可以调用的能力”。

最近全网很火的一篇内容，是 Andrej Karpathy 讲如何用大模型构建个人知识库（请自行查找并仔细阅读）。他用的是 Obsidian（《我所使用的29种或开源、或免费、或正版化软件》），但核心其实不是工具，而是方法：把知识结构化，并让模型参与处理过程。

所以这篇文章我也不打算讨论“怎么写一个管理制度”（我不专业），而是想讲一件更底层的事情：

能不能把“制度编制”，做成一套类似软件开发的流程 Pipeline？

我这段时间做了一点实践，用 Visual Studio Code、Claude Code，再加上 Git 和不同的大模型，搭了一条还算能跑通的“制度流水线”。我在这里把它写出来，有错误或者更好的做法也欢迎指出。

很多人会说：大模型写制度不行，不够好。

你直接问一句：“我是谁谁谁，我现在要写一个管理办法，可以参考的包括啥啥啥，我们单位的实际情况是啥啥啥。请帮我完成这个管理办法。”大模型当然能写。如果能用最好，但大概率是不能直接用的，于是你开始多轮对话。又由于大模型输出不稳定，前面改过的内容，可能又被它改回去了。

最后你抱怨：不好用。

这可能是你的方法不对。

并且在这个过程中，修改、检查、提示词的复用都比较难做到。

所以你可以再进一步，使用 Claude Code 来完成整个过程。用了 Claude Code，可能你基本上只有对话，不需要再真正手动执行了。

Claude Code 相对于 OpenClaw（《OpenClaw 的安全用法：开发自动化，而不是执行自动化》）来说，权限更加可控一些。在下面这个编辑流程中，Claude Code 内置的 Tool（如 file search、file listing、file read、file write 等）基本就可以完成大部分工作，很多时候你甚至可以直接开启 Edit automatically 模式。

在这里你需要用到多个不同的大模型，给 Claude Code 配置国内合规的大模型；切换大模型可以使用 CC Switch。你也可以让多个大模型分别进行同样的操作来对比。

御三家的问答大模型也可以继续使用，遇到 Claude Code 操作问题、提示词优化等，都可以交给它们来做。

制度，其实就是另一种“代码”

如果你把制度和代码放在一起看，会发现它们其实很像。

国王 - 男人 + 女人 = 皇后，这是一种迁移能力。

代码是用编程语言表达约束，制度是用自然语言表达约束；代码需要可读、可维护，制度同样如此。代码有版本，制度也有修订；代码要 Linting，制度要审查。

换句话说：

制度编制，本质上就是一种“文本工程”

一旦你接受这个视角，很多软件工程里的东西就可以直接迁移过来。

比如，软件开发里有需求分析、架构设计、编码（静态Linting）、测试、发布；对应到制度，大概就是上位法和本单位实际调研、结构设计、条文编写、合规审查、发文。

问题在于，大多数人写制度，还是停留在“打开 Word，开始写”的阶段。这相当于写代码直接在记事本里敲，而且没有版本控制、没有审查，也没有复用。

从“问AI”，到“跑流程”

真正有价值的变化，是从“让 AI 回答问题”，转向“让 AI 参与流程”。

我现在的实践，类似这样一条流水线：

调研 → 编制 → 审查 → 发布 → 下一轮修订

重点不在每一步怎么做，而在于：

你是不是在运行一套稳定的流程，你是不是可以随时交付

为了让这条流程跑起来，我做了三件事。

第一件事：把制度当项目来管理

我给制度建一个独立目录，用 git init 初始化。

这么做的好处是：

你可以随时 diff，看模型到底改了什么；你可以做原子提交，保证每一步修改都是可回溯的；当某一步改崩了，也可以快速回滚，而不是在对话里反复让模型“改回来”。

所有内容统一用 Markdown 存，而不是直接写 Word。

包括：

  • 上位法
  • 旧的管理制度
  • 兄弟高校的管理制度
  • 要修订的大方向

Markdown 在这里可以理解成一种“中间表示”（IR）：它既适合人看，也适合模型处理，还方便后续转换成不同格式。

这整个过程你可以手工提交，也可以让 Claude Code 帮你提交，在提交过程中完成 changelog 记录。

第二件事：用“多智能体”模拟“多人协作”

如果你一直在一个对话里完成所有事情，很快会遇到两个问题：上下文越来越长，模型开始“跑偏”；不同任务互相干扰，比如写条文的时候混进了格式处理的逻辑，大模型开始产生幻觉。

解决方法就是大家都听过的“一人公司”：

像组织一个团队一样，给不同角色分工

我一般会拆成几个相对独立的“角色”：有的负责调查，有的负责根据材料编制条文，有的专门做审查，还有一个角色专门写代码，把 Markdown 转成 Word。

这些角色可以用不同的 Session，或者子 Agent 来承载（截至目前，在 Claude Code 里，使用 Agent 可以配置指定模型是 lite mini 还是 pro ultra，Session 需要手动切换）。

关键不是用什么具体手段，而是做到一件事：

上下文隔离（Context Isolation）

也就是让每个角色只看到自己该看的信息。隔离维度包括：Session 隔离（上下文窗口）、Agent 隔离（角色职责）、文件隔离（输入输出边界）。

这样做的效果很明显：写代码的不会被制度内容干扰，做审查的也不会被生成过程“带偏”。你可以把一个 Agent 的输出，存成文件，作为另一个 Agent 的输入。

如果某个 Session 上下文太大，在尝试新的修改时，可以类似 git branch 一样，手动“分叉”一个新的；如果改错了，就干掉；否则把结果沉淀成文件，再从主 Session 继续往下走。

这件事其实和流水线生产是一个逻辑：分工 + 隔离，换来稳定性。

如果你是用多 Agent 工作，有些人会在过程中加入验收的环节，如果定义得好，做好约束、调度、验收，整个流程甚至可以脱离人工监管运行。

第三件事：把“能力”沉淀下来

如果每一次审查、每一次转换都重新写提示词，很快就会崩溃。

所以我会把一些稳定的能力固化下来，比如：

  • 标点和错别字检查
  • 中英文大小写
  • 条目之间冲突
  • 职责重叠、不清晰、覆盖度不够
  • 某些规定实际上无法执行

在 Claude Code 里，这可以抽象成 Skill 和 Command。你可以把 Skill 理解为函数，把 Command 理解为调用这些函数的一种入口。函数可以独立被调用，也可以再编排成一个更大的函数来调用。

有些 Skill 可以在互联网上找到。有些就请问答大模型给你生成。

时间长了，你手里其实会形成一套“工具箱”。下一次再写新制度，很多能力是可以直接复用的，而不是从零开始。

其他衍生产物

你最终还需要把 Markdown 转成 Word 文档，用来给没有使用 AI 的其他人会稿、审议，或者最终发布。这就需要让 Claude Code 帮你写代码。可以使用我以前写过的模板 Word样式的使用和管理办法/工作条例模板下载（最终版）。

这里不建议简单使用 Pandoc 直接输出 Word 文档，否则格式往往不理想。根据我的经验，可以让 Claude Code 使用 python-docx 来完成精细控制。

提示词会类似：帮我把这个 md 文件转换为 docx，使用“管理办法工作条例.郑海山dump.dotx”模板，Markdown 一级目录使用标题样式，二级目录使用“标题 1”样式。然后把提示词交给问答类大模型优化，再交给 Claude Code 执行，并在正确执行后请Claude Code保存为 Command 方便以后调用。

在这个过程中，你还可以：

  • 同步让 Claude Code 输出宣贯用的 PPT 大纲，再交由其他工具生成 PPT
  • 生成 Infographic，例如“一图读懂 XXX”
  • 将 Markdown 直接纳入校级知识库，用于问答系统
  • 生成修订差异视图，用于向领导汇报
  • 输出泳道图、流程图等
  • 输出简化版

这些，本质上都只是多写几个提示词。

写在最后

当你把这一整套 CI/CD 流程跑顺之后，你不再只是“会写代码的人”，而是设计了一套“制度生产系统”。这其实是一种很典型的能力迁移。

关注我，下一篇我可能会放炮：既然端侧的 Claude Code 已经能做这么多事情，那校级层面的智能体平台还有什么价值？