!封面
写一篇能发布的公众号文章，需要在几个软件之间切换？
我以前的答案是五个：Obsidian 写稿、Figma 画流程图、某生图工具做封面、微信编辑器排版、公众号后台发布。每一步切一次工具，每切一次就丢一次上下文。更麻烦的是，AI 辅助写作的质量忽高忽低——同样的 Prompt，有时候给的是结构清晰的分析，有时候是一篇"在当今时代……值得注意的是……综上所述"的教科书。
半年前我开始系统性地用 Claude Code 的工作区规则机制重构整个写作流程。现在，一个 Agent 会话覆盖从选题到发布的完整链路。这篇文章拆解这个规则系统的构建方法，以及每个设计决策背后的价值判断。
不是更好的 Prompt，是规则系统
大多数人对 AI 写作的想象是一行 Prompt 换一篇成稿。现实是 Prompt 只解决 30% 的问题。剩下 70% 是流程控制、质量把关和格式转换。
举一个典型的失败场景：你让 AI 写一篇法律实务文章。它给了你一篇结构完整的稿子，但第 3 段引用的法条已经废止，第 5 段的案例是编的，全文用"第一…第二…第三"串联，结尾"综上所述"——发出去同行一眼看出是 AI 写的。
这些不是 Prompt 能解决的问题。Prompt 可以告诉 AI "不要编法条"，但 AI 不知道自己在编法条——它只是在做概率预测。你需要的是一个规则系统：在 AI 引用法条前，先让它去权威数据库查一遍；在案例嵌入前，先让它去本地案例库全文检索匹配；在成稿后，再用独立的 humanizer-zh 扫一遍句式痕迹。
工作区规则的本质，是把写作全流程的决策树、质量闸门和工具路由固化为可执行的指令。不是"写一个更好的 Prompt"，而是"造一套不需要 Prompt 的机制"。
五层规则架构
工作区规则不是一个大文件，而是一个分层加载的系统。每一层只加载当前任务需要的规则。
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 420">
<rect width="600" height="420" fill="#fff" rx="4"/>
<text x="300" y="28" text-anchor="middle" font-size="17" font-weight="700" fill="#222">工作区规则五层架构</text>
<!-- L1 -->
<rect x="30" y="48" width="540" height="52" fill="#f5f5f5" stroke="#333" stroke-width="1.5" rx="2"/>
<text x="45" y="70" font-size="12" font-weight="700" fill="#c41e3a">L1 全局基础层</text>
<text x="45" y="88" font-size="10.5" fill="#555">CLAUDE.md + rules/ — 角色定位、法律分析框架、检索规范、工具边界（所有项目共享）</text>
<!-- L2 -->
<rect x="30" y="108" width="540" height="52" fill="#fff" stroke="#666" stroke-width="1" rx="2"/>
<text x="45" y="130" font-size="12" font-weight="700" fill="#c41e3a">L2 工作区主规则</text>
<text x="45" y="148" font-size="10.5" fill="#555">.claude/CLAUDE.md — 撰写模式、选题锚点、类别路由、输出流程、文件结构</text>
<!-- L3 -->
<rect x="30" y="168" width="260" height="56" fill="#fff" stroke="#999" stroke-width="0.8" rx="2"/>
<text x="45" y="190" font-size="11" font-weight="700" fill="#333">L3a 风格库（7套）</text>
<text x="45" y="206" font-size="9.5" fill="#777">语气区间、结构模板、金句密度</text>
<text x="45" y="219" font-size="9.5" fill="#777">AI痕迹控制策略</text>
<rect x="310" y="168" width="260" height="56" fill="#fff" stroke="#999" stroke-width="0.8" rx="2"/>
<text x="325" y="190" font-size="11" font-weight="700" fill="#333">L3b 排版主题库（9套）</text>
<text x="325" y="206" font-size="9.5" fill="#777">微信HTML渲染、H1-H3层级</text>
<text x="325" y="219" font-size="9.5" fill="#777">间距系统、色彩方案</text>
<!-- L4 -->
<rect x="30" y="232" width="260" height="56" fill="#fff" stroke="#999" stroke-width="0.8" rx="2"/>
<text x="45" y="254" font-size="11" font-weight="700" fill="#333">L4a 案例库</text>
<text x="45" y="270" font-size="9.5" fill="#777">判决书/裁决书全文检索</text>
<text x="45" y="283" font-size="9.5" fill="#777">脱敏规则 + 有机嵌入</text>
<rect x="310" y="232" width="260" height="56" fill="#fff" stroke="#999" stroke-width="0.8" rx="2"/>
<text x="325" y="254" font-size="11" font-weight="700" fill="#333">L4b 发布脚本（6个）</text>
<text x="325" y="270" font-size="9.5" fill="#777">封面生成 → 图片处理</text>
<text x="325" y="283" font-size="9.5" fill="#777">HTML排版 → 草稿箱</text>
<!-- L5 -->
<rect x="30" y="296" width="540" height="52" fill="#f9f9f9" stroke="#333" stroke-width="1.5" rx="2"/>
<text x="45" y="318" font-size="12" font-weight="700" fill="#c41e3a">L5 外部 Skill 层</text>
<text x="45" y="336" font-size="10.5" fill="#555">humanizer-zh（去AI痕迹）/ 知识库路由 / 法律检索MCP — 跨工作区共享</text>
<!-- Right labels -->
<text x="582" y="78" font-size="8.5" fill="#999">常驻</text>
<text x="582" y="138" font-size="8.5" fill="#999">项目</text>
<text x="582" y="198" font-size="8.5" fill="#999">按类型</text>
<text x="582" y="262" font-size="8.5" fill="#999">按需</text>
<text x="582" y="326" font-size="8.5" fill="#999">共享</text>
<!-- Connector arrows -->
<line x1="576" y1="100" x2="576" y2="108" stroke="#ccc" stroke-width="0.8"/>
<line x1="576" y1="160" x2="576" y2="168" stroke="#ccc" stroke-width="0.8"/>
<line x1="576" y1="224" x2="576" y2="232" stroke="#ccc" stroke-width="0.8"/>
<line x1="576" y1="288" x2="576" y2="296" stroke="#ccc" stroke-width="0.8"/>
<!-- Design principle note -->
<text x="300" y="398" font-size="10" fill="#aaa" text-anchor="middle">按需加载 · 上下文不浪费 · 通用能力跨项目复用</text>
</svg>这个分层结构背后有三个设计决策。
按需加载，不浪费上下文。全局基础层（L1）包含所有项目共享的规则——角色定位、法律分析框架、检索规范。每次会话自动加载。工作区主规则（L2）只在进入文章撰写目录时加载。风格库和排版主题（L3）只在实际写作时才读取具体文件。上下文是有限资源，不能把不参与当前决策的规则塞进去。
关注点分离。写作质量控制（L3a 风格库）和视觉呈现（L3b 排版主题）是两个独立维度。一篇法律实务文章可以用"精致蓝调"主题排版，也可以改用"黑白简约"——风格库定义了文章该怎么写，主题库定义了文章该怎么展示。两者解耦后可以自由组合。
通用能力跨项目复用。案例库（L4a）和发布脚本（L4b）是文章撰写工作区专用的。但 humanizer-zh、知识库路由、法律检索 MCP 这些能力（L5）是所有工作区共享的——合同审核、咨询分析、讲座准备都在用同一套基础设施。
七类文章，七套风格文件
AI 写作最常见的失败模式是语气错位——用写论文的方式写公众号，用写微博的方式写法律意见书。
每次 Prompt 里写"请用专业但通俗的语气"解决不了这个问题——太模糊了。我做了七套风格文件，每套精确到：
- 语气区间：方法论型是"清晰、有体系、不卖弄"，观点型是"有立场、第一人称、金句密度高"
- 结构模板：方法论型是"一句话定义 → 痛点 → 核心框架 → 逐要素展开 → 常见错误 → 适用边界"，法律实务型是"结论 → 依据 → 边界 → 行动"
- 论证密度：数据报告型"数据先行，反直觉发现驱动"，法律评论型"以法律为锚点评事件，控制结论边界"
- AI 痕迹控制策略：每套风格文件都列出了该类文章最常见的 AI 痕迹和破解方法。观点型禁止"在当今时代"式宏大开头，方法论型禁止"综上所述"教科书收尾
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 260">
<rect width="600" height="260" fill="#fff" rx="4"/>
<text x="300" y="25" text-anchor="middle" font-size="16" font-weight="700" fill="#222">类别路由决策树</text>
<!-- Root -->
<rect x="220" y="42" width="160" height="32" fill="#333" rx="3"/>
<text x="300" y="63" text-anchor="middle" font-size="11" fill="#fff" font-weight="700">文章主题</text>
<!-- Branches -->
<line x1="250" y1="74" x2="100" y2="100" stroke="#999" stroke-width="0.8"/>
<line x1="300" y1="74" x2="300" y2="100" stroke="#999" stroke-width="0.8"/>
<line x1="350" y1="74" x2="500" y2="100" stroke="#999" stroke-width="0.8"/>
<!-- Q1 -->
<rect x="30" y="102" width="140" height="36" fill="#f5f5f5" stroke="#666" stroke-width="1" rx="2"/>
<text x="100" y="118" text-anchor="middle" font-size="10" font-weight="700" fill="#333">涉及法条/案例？</text>
<text x="100" y="132" text-anchor="middle" font-size="9" fill="#666">→ 法律实务 / 法律评论</text>
<rect x="230" y="102" width="140" height="36" fill="#f5f5f5" stroke="#666" stroke-width="1" rx="2"/>
<text x="300" y="118" text-anchor="middle" font-size="10" font-weight="700" fill="#333">AI/方法论/框架？</text>
<text x="300" y="132" text-anchor="middle" font-size="9" fill="#666">→ 方法论/思维型</text>
<rect x="430" y="102" width="140" height="36" fill="#f5f5f5" stroke="#666" stroke-width="1" rx="2"/>
<text x="500" y="118" text-anchor="middle" font-size="10" font-weight="700" fill="#333">工具/教程/评测？</text>
<text x="500" y="132" text-anchor="middle" font-size="9" fill="#666">→ 技术实战型</text>
<!-- Q2 level -->
<line x1="100" y1="138" x2="70" y2="162" stroke="#ccc" stroke-width="0.6"/>
<line x1="100" y1="138" x2="130" y2="162" stroke="#ccc" stroke-width="0.6"/>
<line x1="300" y1="138" x2="300" y2="162" stroke="#ccc" stroke-width="0.6"/>
<line x1="500" y1="138" x2="470" y2="162" stroke="#ccc" stroke-width="0.6"/>
<line x1="500" y1="138" x2="530" y2="162" stroke="#ccc" stroke-width="0.6"/>
<rect x="15" y="164" width="110" height="30" fill="#fff" stroke="#ccc" stroke-width="0.6" rx="2"/>
<text x="70" y="183" text-anchor="middle" font-size="9" fill="#555">评事件 → 法律评论</text>
<rect x="130" y="164" width="110" height="30" fill="#fff" stroke="#ccc" stroke-width="0.6" rx="2"/>
<text x="185" y="183" text-anchor="middle" font-size="9" fill="#555">实务操作 → 法律实务</text>
<rect x="245" y="164" width="110" height="30" fill="#fff" stroke="#ccc" stroke-width="0.6" rx="2"/>
<text x="300" y="183" text-anchor="middle" font-size="9" fill="#555">思想/趋势 → 观点型</text>
<rect x="415" y="164" width="110" height="30" fill="#fff" stroke="#ccc" stroke-width="0.6" rx="2"/>
<text x="470" y="183" text-anchor="middle" font-size="9" fill="#555">数据报告 → 数据报告型</text>
<rect x="530" y="164" width="55" height="30" fill="#fff" stroke="#ccc" stroke-width="0.6" rx="2"/>
<text x="557" y="183" text-anchor="middle" font-size="9" fill="#555">学术</text>
<!-- Result -->
<text x="300" y="225" font-size="10" fill="#999" text-anchor="middle">路由结果 → 自动加载对应风格文件（语气 + 结构 + 金句密度 + AI痕迹控制）</text>
<text x="300" y="248" font-size="10" fill="#999" text-anchor="middle">跨类别时以主导内容决定主风格，局部吸收其他风格要素</text>
</svg>这七套风格文件的核心价值不是"写得比别人好"，而是质量基准线。同一类文章，每次调用同一套风格文件，出来的语气、结构、深度是一致的——不需要每次重新调试 Prompt。
配图零成本：SVG 嵌入 + 本地转换
公众号文章的配图通常有三个来源：自己做、找人做、网上找。三条路都有摩擦——Figma 要单独打开，设计师要沟通需求，网图有版权风险。
这个工作区用了一套零摩擦方案：AI 撰写正文时，遇到"纯文字难以讲清"的地方，直接在 Markdown 里嵌入 SVG 代码块。多步骤流程、多主体法律关系、框架层级——这些场景用简洁的框图比文字直观得多。
技术管线也很轻：发布时 wechat_images.py 自动检测 `svg 代码块，用 cairosvg 本地渲染为 PNG，然后上传微信 CDN。毫秒级完成，不依赖任何外部生图 API。
三个约束保证质量：每篇文章配图不超过 3 张，风格统一为黑白灰无衬线极简线条，只在确实需要视觉辅助时配图。约束的目的是防止"为配图而配图"——有些文章根本不需要图，但需要的那些段落，SVG 比截屏和网图好用得多。
封面生成：Codex CLI 替代付费 API
之前我做封面用的是 DALL-E API——单独付费，额度焦虑，每次还要切到另一个工具操作。后来发现 Codex CLI 内置了 image_gen 能力（等效 GPT Image 2），Plus 和 Pro 会员的额度已经覆盖了。
实现方式是 wechat_cover.py，一段 Python 脚本。它读取文章的标题、副标题和正文前 3000 字，自动构造一个专业级概念海报 Prompt，然后调用 codex exec --enable image_generation。
Prompt 的设计花了最多功夫。不是简单的"生成一张封面图"，而是一个反复打磨的设计系统：先理解主题语义 → 自动选择视觉锚点 → 决定图文融合方式 → 长标题自动提炼三层文字系统（主视觉大字 / 完整标题 / 辅助信息）→ 按主题类型匹配视觉策略。AI/知识类优先终端、档案盒、路径线；金融类优先图表裂缝、波动曲线；教程类优先地图、阶梯、入口。
最终生成的海报：黑白极简、现代编辑设计、作品集封面基调。右下角带 CSLawyer 连笔签名。从执行命令到出图，一张封面大约 1-2 分钟，成本为零。
去 AI 痕迹：改的是节奏，不是词
AI 写作的痕迹不在用词上，在节奏上。一段文字读起来"像 AI 写的"，通常是因为几个特征叠加在一起：
- 每段都是"主题句 + 展开 + 小结"的等长结构
- 连接词高度集中在"首先…其次…再次…最后""值得注意的是""在当今时代"
- 段落首句总是概括性声明（"XX 是一个重要的议题"）
- 结尾一定是"综上所述"或"总而言之"加一段复读
humanizer-zh 这个 Skill 做的事不是替换同义词。它打破的是节奏——把等长段落变成长短交替，把"第一…第二…第三"改成更自然的过渡方式，砍掉每个段落首句的概括声明，直接进入内容，结尾自然收束而不是教科书式总结。
它的执行时机在正文完成之后，与封面生成并行。两个任务互相独立，等封面那 1-2 分钟里 humanizer-zh 已经在改稿了。
发布管线：一条命令到草稿箱
写完稿、配完图、生成封面之后，最后一步是推到微信公众号草稿箱。
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 200">
<rect width="600" height="200" fill="#fff" rx="4"/>
<text x="300" y="24" text-anchor="middle" font-size="15" font-weight="700" fill="#222">发布管线（一条命令完成）</text>
<!-- Steps -->
<rect x="18" y="46" width="78" height="50" fill="#333" rx="3"/>
<text x="57" y="68" text-anchor="middle" font-size="10" fill="#fff" font-weight="700">Markdown</text>
<text x="57" y="84" text-anchor="middle" font-size="9" fill="#ddd">终稿</text>
<text x="110" y="76" font-size="16" fill="#999">→</text>
<rect x="125" y="46" width="78" height="50" fill="#f5f5f5" stroke="#666" stroke-width="1" rx="3"/>
<text x="164" y="68" text-anchor="middle" font-size="10" fill="#333" font-weight="700">SVG→PNG</text>
<text x="164" y="84" text-anchor="middle" font-size="9" fill="#777">cairosvg</text>
<text x="217" y="76" font-size="16" fill="#999">→</text>
<rect x="232" y="46" width="78" height="50" fill="#f5f5f5" stroke="#666" stroke-width="1" rx="3"/>
<text x="271" y="68" text-anchor="middle" font-size="10" fill="#333" font-weight="700">图片上传</text>
<text x="271" y="84" text-anchor="middle" font-size="9" fill="#777">微信CDN</text>
<text x="324" y="76" font-size="16" fill="#999">→</text>
<rect x="339" y="46" width="78" height="50" fill="#f5f5f5" stroke="#666" stroke-width="1" rx="3"/>
<text x="378" y="68" text-anchor="middle" font-size="10" fill="#333" font-weight="700">HTML排版</text>
<text x="378" y="84" text-anchor="middle" font-size="9" fill="#777">9套主题</text>
<text x="431" y="76" font-size="16" fill="#999">→</text>
<rect x="446" y="46" width="78" height="50" fill="#c41e3a" rx="3"/>
<text x="485" y="68" text-anchor="middle" font-size="10" fill="#fff" font-weight="700">草稿箱</text>
<text x="485" y="84" text-anchor="middle" font-size="9" fill="#fdd">Finder标记</text>
<text x="538" y="76" font-size="16" fill="#999">→</text>
<rect x="553" y="46" width="32" height="50" fill="#fff" stroke="#ccc" stroke-width="0.6" rx="3"/>
<text x="569" y="76" text-anchor="middle" font-size="10" fill="#555">审核</text>
<!-- Details below -->
<text x="300" y="120" font-size="9.5" fill="#777" text-anchor="middle">封面图自动插入正文首部 | MD5去重避免重复上传 | 仅发布到草稿箱，不自动群发</text>
<!-- Command line -->
<rect x="60" y="140" width="480" height="42" fill="#2d2d2d" rx="4"/>
<text x="300" y="158" text-anchor="middle" font-size="10" fill="#6f6" font-family="monospace">python .claude/scripts/wechat_publish.py publish article.md --gen-cover --theme minimal-bw</text>
<text x="300" y="174" text-anchor="middle" font-size="9" fill="#aaa">一条命令 = 图片处理 + 封面生成 + HTML排版 + 草稿箱 + Finder标记"已推送"</text>
</svg>六个 Python 脚本支撑这条管线：wechat_publish.py（总入口）、wechat_cover.py（封面生成）、wechat_images.py（图片下载/上传/MD5 去重）、wechat_html.py（Markdown → 微信 HTML，支持 9 套排版主题）、wechat_api.py（微信 API 客户端，token 管理和草稿创建）。全部在本地运行，图片上传到微信 CDN（不占永久素材配额）。
发布到草稿箱后，脚本自动用 macOS Finder 注释给项目文件夹标记"已推送"。在 Finder 列表视图里一眼就能看出哪些文章已经发过。
顺便建了一个文章知识库
选题双锚点、类别路由、封面生成、发布管线——这些设计都是为了写好一篇文章。但这套规则系统还顺带产出了一个东西，它的长期价值可能比单篇文章更大。
每篇文章自动创建 YYYYMMDD_主题/ 文件夹，内部严格三层结构：
20260518_文章工作区规则构建方法/
├── input/
│ └── 用户需求与原始材料.md ← 原始想法、材料、触发语境
├── scratch/
│ ├── 大纲.md ← 构思过程的决策痕迹
│ └── 草稿_v1.md ← 修改迭代的中间状态
└── output/
└── 20260518_用规则代替软件…….md ← 终稿这本质上是一个自动化的个人知识管理系统。三层目录对应了知识生产的三个阶段：
input/保存了"为什么写这篇文章"的初始语境。三个月后回头翻，你不会只看到一篇成稿——你会看到当时的原始材料、触发问题、想表达的核心思想。知识复用从这里开始。scratch/保留了"怎么写的"决策过程。大纲的结构选择、为什么放弃了某个角度——这些中间产物往往比终稿包含更多思考。下次写同类文章，不是从零开始，而是从上次的决策经验开始。output/是可交付的成果。按日期和主题命名，时间线就是目录树。
所有操作都是规则自动驱动的——不需要手动建目录、不需要记得把材料放进对应文件夹、不需要写完后整理归档。规则的每一步（input 存档、scratch 输出大纲、output 输出终稿）在执行时就完成了归档。增量成本为零。
再加上 Finder 注释标记的"已推送"状态，整个目录就是一个可浏览、可检索的文章馆。按时间排序就是作品年表，按主题搜索就是领域知识库。这个知识库的维护没有增加任何人力工作——它是写作流程的自然副产品。
法律类文章的专属防线
法律写作有一个通用 AI 绕不过去的问题：它不知道自己在编法条。
模型训练数据里有大量法条文本，但不知道哪些已经废止、哪些有地域适用范围、哪些条文在实践中已经被裁判观点实质修正。更危险的是案例编造——AI 能生成格式完全正确的"判决书摘要"，但案号、当事人、裁判观点全是虚构的。
这个工作区为法律类文章设了两道防线。
第一道：案例库全文检索。 本地 .claude/case-library/ 目录存放真实判决书和裁决书（只读，不做二次加工）。写法律文章时，在大纲确定后用 rga 全文检索案例库，匹配核心法律问题 + 行业 + 项目类型。找得到的案例才有资格嵌入正文。找不到就不强行嵌入。每一处案例引用都经过强制脱敏——去掉公司名留行业、去掉地点留项目类型、金额给量级不给精确数字。读者能感知到"这是一个真实的大项目"，但无法定位到具体公司和具体项目。
第二道：知识库交叉引用。 按全局规则 knowledge-base-crossref.md 的路由表，检索本地知识库中该法律领域的最新规范、裁判观点和研究资料，验证文章引用的法条时效性和权威性。知识库不足时再补充 MCP 法律数据库检索。
两道防线过滤掉的是同一个东西：AI 的幻觉。区别在于第一道管"案例真假"，第二道管"法条对错"。
构建工作区规则的五个坑
做这个系统的过程中踩了不少坑。这些坑是方法论文章该诚实交代的部分。
坑一：把 CLAUDE.md 写成说明书。 最早版本的 CLAUDE.md 写了很多"写作建议"——"开头要抓人""论证要有力""结尾要收得住"。这些话对 AI 毫无意义。它需要的是决策树，不是建议。现在的规则全部是"当 A 时做 B""禁止 C""D 步骤必须先于 E"，每条都可执行、可验证。
坑二：规则太细，AI 反而僵化。 有一个版本我把每种文章类别的段落数、每段字数都做了规定。结果 AI 写出来的东西像填表格，毫无弹性。后来改成了"区间"定义——风格文件定义的是"2000-5000 字"而不是"3500 字"，是"中密度金句"而不是"每 300 字一个金句"。
坑三：把所有规则塞进一个文件。 初始版本的工作区 CLAUDE.md 有 500 多行，每次打开项目全部加载。实际上一篇文章只用得到其中一小部分规则。分层后上下文消耗大幅下降——法律类文章不加载技术实战型的风格规则，非法律类文章不触发案例库检索。
坑四：忽略"不做什么"。 "在非法律文章中堆砌法条""模糊归因""使用夸张修辞""跳过 humanizer-zh"——这些禁令实际上比正向指令更关键。正向指令告诉 AI 怎么做，禁令直接阻止 AI 的默认坏习惯。通用 AI 被训练成"乐于助人"，它会自然地用法条来"丰富"非法律文章、用"专家认为"来增加权威感。这些倾向要靠禁令来截断。
坑五：脚本和规则脱节。 最早封面生成是用单独的命令行工具，和写作流程不在同一个上下文里。结果是规则说"正文完成后生成封面"，但 AI 经常忘记执行这一步。把封面生成封装成脚本并写进规则中的强制步骤后，遗漏率归零了——规则明确说"在正文完成后，执行 python .claude/scripts/wechat_publish.py cover {md_path}"，不需要 AI 自己判断要不要做。
适用边界
不是每个写作者都需要搭这套系统。
适用的场景：有固定发布节奏的公众号或博客作者；专业领域（法律、医疗、金融）的内容创作者——品质一致性比效率更重要；需要多品类写作的人——同一个人要写法律实务、行业评论、工具教程，每类都需要不同的语气和质量控制。
不适用的情况：一次性写作任务——搭系统的成本大于收益；纯创意写作——规则会抑制发散性；多人协作场景——这套规则是为单人全流程设计的，团队协作需要额外考虑权限和版本控制。
核心判断标准很简单：如果你每年写超过 20 篇非虚构类文章，而且对品质一致性有要求，这个规则系统值得搭。偶尔写一篇，每次单独调 Prompt 就够了。
规则系统搭好之后，最明显的变化不是"写得更好"，而是"写得更轻松"。以前写一篇文章要切五个软件，现在一个 Agent 会话从头跑到尾。省下的不是时间——是切换工具时的摩擦和上下文丢失。每次切工具都是在重新加载"这篇文章在讲什么"到脑子里。当所有环节在一个上下文里跑完，那些因为切换而丢失的判断和信息，就不会丢了。
这篇文章本身就是这个工作区的一个完整测试案例。从选题到发布，全部在当前 Agent 会话中完成。
作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。