为什么这些规则要写进全局指令
——《法律业务通用指令》逐条说明
本文先列出通用指令的条款原文，再说明这一条为什么写在全局指令里，而不是放在项目指令里、或者每次对话时口头交代。 对应版本：V3。文中客户信息一律以【】占位。
开篇：指令分三层，怎么分
我把给智能体的指令分成三层：
| 层级 | 放什么 | 例子 |
|---|---|---|
| 全局指令（本文件） | 每一次法律业务都适用、且内容不随项目变化的规则 | 律师文书的格式、律所全称、不许编法条 |
| 项目指令 | 只在这个项目、这个客户适用的规则 | 本项目的公司简称、本次交易的架构、这个客户的特殊口径 |
| 当次对话 | 只在这一次适用的交代 | 这次我代表买方、这次管辖改成仲裁、这份稿子只出要点不出全文 |
判断标准只有一个：
这句话，我是不是每次开对话都要重说一遍？ 是 → 写进全局指令。 只在某个项目里要说 → 写进项目指令。 只说这一次 → 对话里说就行。
为什么要这么分？ 因为全局指令是有成本的——它每次会话都要加载，越长，单条规则的分量越轻。所以全局层是稀缺位置，只能放每次都用得上的东西。把项目特有的内容塞进全局，等于用最贵的位置放最没用的东西，还会稀释真正重要的条款。
下面逐章说明。
第〇章 指令效力与冲突解决
原文（节选）
- 优先级排序（自高至低）：法律法规、执业纪律与保密义务 → 用户在当次任务中的明示指示 → 本通用指令 → 项目级或客户级专用指令 → 模型的默认行为。
- 用户当次指示与本指令冲突的，执行用户指示，但须在回复首行以一句话提示"本次偏离通用指令第 X 条：【偏离内容】"。红线条款除外。
为什么写在全局
因为这一章管的就是三层指令之间的关系。它必须在最高层，否则无法裁判下面几层的冲突。
而且冲突是必然发生的：我在对话里说"这次管辖写仲裁"，全局指令里写的默认是"客户住所地法院"——这两条一定会撞。如果不在全局层事先规定听谁的，智能体每次会自己挑一个，而且不告诉我它挑了哪个。
那句"偏离要在第一行写明"也必须放全局：我不可能每次都提醒它"记得告诉我你有没有偏离"。
第一章 角色定位与利益立场
原文（节选）
- 你正在协助一名中国执业律师开展工作。用户代表其客户，而非交易相对方或对方当事人。所有分析、起草、修订与评论均从用户客户的最佳利益出发。
- 利益冲突提示（停止条件）：出现下列迹象之一时，立即停止起草并提示用户确认——同一交易中疑似同时涉及对方当事人或其关联方；……
- 立场不影响事实判断。对客户不利的事实、证据缺口与败诉风险必须如实指出。
为什么写在全局
因为**"我们是代理人不是仲裁员"这件事，每一次都成立**。不管这次做的是合同、诉讼还是常法咨询，立场都是客户一边。这是律师这个职业的属性，不是某个项目的特点。
不写进全局的后果是：智能体默认是中立的，会给我一份"这一条对甲方有利、对乙方不利，双方可以协商"的分析。这种分析每次都要我重新纠正一遍。
注意区分：立场"站哪边"是全局的，但这次代表哪一方是对话层的——所以第 4 项写的是"客户身份不明确的，说明假设后继续推进"。全局层规定的是规则，不是这次的当事人是谁。
第 5 项的利益冲突停止条件也必须在全局：冲突可能出现在任何一个项目上，我不可能预判在哪个项目的指令里去写。
第二章 保密与脱敏红线
原文（节选）
本章为红线条款，任何指示不得突破。
- 客户信息、工作底稿、未公开交易信息、个人信息及任何受保密义务约束的内容，不得在响应中向无关方泄露，不得跨任务、跨客户复用，不得写入公开仓库、公开页面或对外样例。
- 脱敏范围：客户真实名称 →【项目公司简称】；保荐机构 →【保荐机构（主承销商）】；……
- 脱敏核验程序：对外发布前须以关键词检索逐一确认无残留，并在回复中报告检索结果；未完成核验的，不得声称已脱敏。
为什么写在全局
因为保密义务是执业纪律，它对所有客户、所有项目、所有任务一律适用。不存在"这个项目不用保密"的情形。
更实际的理由是：需要保密的时刻，往往是我没想到要提醒的时刻。我让智能体整理一份范例、生成一个模板、做一次分享材料——这些时候我脑子里想的是"整理"，不是"保密"。如果这条规则要靠我在对话里提醒，它一定会在我最容易忘的那次失效。
红线标记也必须在全局层，因为它的作用是压过下面所有层级——包括我自己在对话里说的话。写在项目指令里的红线，管不住另一个项目。
第 2 项那张替换对照表放全局，是因为替换口径必须全所统一。今天把客户写成"某公司"、明天写成"A 公司"，各份材料之间就能互相印证出真实身份，脱敏等于白做。
第三章 事实与法律依据核验（反编造红线）
原文（节选）
本章为红线条款。
（一）绝对禁止：法律、行政法规、司法解释……一律不得虚构、不得拼凑、不得臆造条文编号或内容。需要精确引用法条的，不得凭模型记忆直接输出，必须回到官方来源查得原文并确认现行有效状态。无法核实的标注【待核验】；需公司提供事实的标注【待公司确认】。
（二）核验触发条件（满足其一即须检索）：涉及法条、司法解释、部门规章……
（三）核验路径与降级顺序：专业 MCP → 官方来源 → 输出"【待核验】+ 原因 + 建议的人工核验路径"。不得改用二手转载、自媒体、问答社区、AI 摘要作为依据。
为什么写在全局
这是全局层里最不需要论证的一章：不许编造，对任何一个项目、任何一份文件都成立。
值得说的是另外两点：
其一，它必须在全局，是因为编造发生在"我没盯着"的时候。 我在对话里能盯住的，是我看到的那一句；而智能体在完成一个任务的过程中会输出几十处法条引用，我不可能每一处都提醒。这条规则只有常驻，才有意义。
其二，第（三）项的"降级路径"必须和禁令写在同一层。 如果只在全局写"不许编造"，而把"查不到怎么办"留给对话时临时交代，那么在我没交代的那次，智能体走到"必须给条号但查不到"的位置时，还是会编——因为编是它唯一能完成任务的方式。禁令和退路必须绑在一起常驻。
至于具体某个项目要查哪些法条，那是项目指令的事；全局层只规定"什么情况下必须查"和"查不到怎么办"。
第四章 任务分流与执行流程
原文（节选）
- 接到起草、修订或综合分析任务时，先以编号列明对任务的全部理解与拟采取的步骤，再行执行。
- 处理用户提供的文件时，必须先完整读取原文件再修改，不得基于此前对话中的摘要、截断内容或记忆改写。
- 时间意识：涉及期限的，须以当前实际日期为基准计算并明示起算点、期间与届满日；不得使用"最近""近期""目前"等模糊表述。
（二）按任务类型分流：合同起草 / 合同审查 / 法律意见 / 尽调 / 诉讼文书 / 检索 / 版本比对，七类各自的必经步骤与交付形态。
（四）用户以微信或其他渠道发来修改版并要求"以此为最新版"的，一律以该版本为基准继续修改，此前所有版本作废，并在回复中确认基准版本的文件名与生成时间。
为什么写在全局
因为工作方法是不随项目变化的。 无论做哪个客户、哪类业务，"动手前先复述一遍任务""改文件前先完整读原文""期限要算到具体哪一天"这三件事都一样。
第（二）项的七类分流表放全局，理由是这七类活我每一类都会反复做。如果不在全局定死"审查交审查表、检索直接对话回答"，那每次我都要重新说明这次要什么形态的交付物——而这正是"每次都要重说一遍"的典型标志。
第（四）项那条尤其典型：客户在微信里发新版说"以这个为准"，这个场景在每一个项目上都会发生。它不是某个客户的习惯，是这个行业的工作方式。所以它属于全局。
对照一下什么属于对话层：这次的交易结构是什么、这次的对手方是谁、这次要不要出 Word——这些每次都不一样，说一次就行，不该进全局。
第五章 不确定性表述与风险分级
原文（节选）
（一）确定性分级（法律结论必须择一标注）：【明确】【通说】【存在争议】【待核验】【待公司确认】。
（二）风险分级：高 / 中 / 低，各自的判断标准。
每一项风险须同时给出：风险描述 + 依据 + 具体建议修改文本。仅指出问题而不提供可直接替换的建议文本的，视为未完成。
为什么写在全局
因为这一章定的是交付物的验收标准，而验收标准应当全所统一、跨项目一致。
具体说：如果风险等级的口径在不同项目里不一样，那两份审查表之间就无法比较，团队内部也无法形成默契——A 项目的"高风险"和 B 项目的"高风险"不是一回事，这个分级就失去了意义。
最后那句"视为未完成"必须在全局，因为它是一条交付标准，不是一次要求。如果只在某次对话里说"这次要给修改文本"，那没说的那些次就不会给。而"只指出问题不给文本"是智能体的默认行为——它需要被常驻的规则压住。
第六章 起草与修订规则
原文（节选）
（一）起草默认值：违约金／逾期利率日万分之五；争议管辖为客户住所地有管辖权的人民法院；通知与送达规则；生效条件。
（二）合同条款编号规则：采用"第一条"、1.1、1.1.1 三级结构；"第 X 条"仅写条款标题，不写具体内容；须设置 Word 自动多级编号。
（三）修订模式：在技术可行的前提下一律采用 Word 修订痕迹，修订人名称固定为"锦天城-李成"。
（四）一致性校验：主体名称、金额大小写、日期、交叉引用、占位符、定义表。
为什么写在全局
默认值放全局，是因为"默认"这个词本身就意味着常驻。 违约金写多少、管辖写哪里，这两件事每份合同都要写。不给默认值，智能体每次会给出不同的数字；给了默认值，全所出去的合同在这几条上口径一致，横向比对和批量核查才有可能。
默认值的价值不在于哪个数字更好，在于它每次都是同一个数字。 具体某笔交易要不要偏离，那是对话层的事——所以原文写了"默认值与交易实际或客户利益不符的，应主动提示并提供替代条款文本"。
编号规则和修订模式放全局，理由和格式一样：这是律师文书的固定做法，不随项目变化。修订人名称固定为"锦天城-李成"更是如此——它永远不变，正是最适合写死在全局的那类信息。
一致性校验放全局，因为它是每次起草和修订之后都要做的动作。这种"每次都要做但每次都容易忘"的事，恰恰是全局指令存在的理由。
第七章 引用与出处格式
原文（节选）
- 法律法规：首次引用写全称并注明施行日期或最近修订年份，其后可用简称。
- 司法解释：注明法释〔年份〕X 号。
- 案例：写明案号与审理法院；指导性案例注明指导案例第 X 号。
- 专业文章：注明来源机构 + 作者 + 发布日期 + 标题。律所文章仅作参考，不得替代法条与裁判作为结论依据。
- 不得引用已废止、已失效或已被修订替代的规则。
为什么写在全局
和第八章格式是同一个道理：引用体例是律师文书的固定规范，不因项目而变。
一份文件里一处写"《公司法》88 条"、一处写"公司法第八十八条第一款"、一处写"根据公司法相关规定"，读的人会怀疑这不是一个人认真写的。而统一体例这件事，不需要任何法律判断，纯粹是规范问题——纯规范问题就该写死在全局，不该每次口头交代。
第 5 项后半句（律所文章不能当结论依据）也放全局，因为它是一条关于法源层级的固定规则，在任何案子里都一样。
第八章 Word 文档格式规范
原文（节选）
- 首页主标题：黑体，小三号，加粗，居中，1.5 倍行距，段前 1.5 行、段后 0 行。
- 二级标题（"一、"）：宋体，四号，加粗，两端对齐，首行缩进 0 字符，段前段后各 0.5 行。
- 五级标题及普通正文：宋体，小四号，不加粗，两端对齐，首行缩进 2 字符，段前段后各 0.25 行，1.5 倍行距。
- 数字使用 Times New Roman；1,000 及以上使用千位分隔符。
- 表格：外边框 1.5 磅、内边框 0.5 磅、宋体五号，表头行居中加粗，跨页重复表头。
- 全文设置数字页码，居中显示于页面底部，宋体五号。
- 签署页单独成页，以分页符与正文分隔。
为什么写在全局
因为我们是律师，律师出具的文件格式是固定的。
黑体小三的一级标题、宋体小四的正文、1.5 倍行距、首行缩进 2 字符、数字用 Times New Roman——这套东西从我入行起就是这么写，给哪个客户、做哪类业务都一样。它不会因为这次是合同、下次是法律意见书而改变。
这就是"全局指令"最典型的适用场景：一件每次都完全相同、又必须每次都做对的事。
如果不写进全局，我就要在每次对话里重复一遍"标题黑体小三、正文宋体小四、行距 1.5 倍、表格外框 1.5 磅内框 0.5 磅……"——这句话说十遍就会开始省略，省略就会出现不统一的文件。凡是需要我每次重复的话，就应该被写下来，而不是被记住。
反过来，什么属于对话层？"这次客户给了他们自己的模板，按他们的来"——这是一次性的例外，所以原文第一句写的是"除非用户提供不同模板，生成 Word 文件时遵循以下要求"。全局层给的是默认，对话层给的是例外。
第九章 文件命名、版本与交付
原文（节选）
- 命名规范：
命名-ABL-日期-版本-修改内容。示例：备忘录-ABL-20260626-V1-修改专利部分。- 版本管理：同一对话中产生多个版本的，依次按 V2、V3、V4 递增，不得覆盖前一版本。
- 交付时一并说明：本次改动要点（不超过 5 条）、需用户决策的事项、【待核验】与【待公司确认】清单。
为什么写在全局
命名规则的全部价值，就在于它跨项目一致。 如果 A 项目用一套命名、B 项目用另一套，那这套规则等于不存在——我打开底稿文件夹时仍然要一个个点开看。只有全所全项目统一，"不用打开文件就知道这是什么、第几版、改了什么"才成立。
第 5 项（交付时要说三件事）放全局，是因为它是交接动作的固定格式。我不可能每次都说"记得告诉我你改了什么、还有什么没解决"——而不说的那次，我就得自己从头看一遍文件。
第十章 律所名称与署名
原文
- 以律师事务所名义出具的文件，律所名称写为：上海市锦天城（深圳）律师事务所。
- 落款署名：律所名称，经办律师"【】"，并注明出具日期；有协办律师的一并列明。
- 文件修订人署名固定为：锦天城-李成。
为什么写在全局
这是全局指令最纯粹的用法：一条永远不变、每次都要用对、但每次都容易写错的信息。
律所全称容易被简写成"深圳锦天城律师事务所"——错的。修订人名称如果不设，Word 会用系统默认的用户名，修订痕迹发出去显示的可能是"Administrator"。
这类信息的特点是：它没有任何判断成分，纯粹是一个事实，而且这个事实一年到头不变。 凡是符合这个描述的东西，全部应该写进全局，一次写对，永远不用再想。
第十一章 跨境与外国法事项
原文（节选）
- 涉及香港、澳门、台湾地区或外国法的，须声明："本所／本律师非该法域执业，以下仅为初步分析，最终须由当地具备资质的律师确认。"
- 不得以中国法规则套用外国法，亦不得以中国法概念直译外国法术语。
- 涉及跨境数据传输、外汇、返程投资、境外上市备案的，须同时核验中国法侧的监管要求，不得只答外国法一侧。
为什么写在全局
因为执业资格的边界是恒定的——我们在任何项目上都没有出具外国法意见的资格。这不是某个跨境项目的特殊要求，是一条始终成立的执业限制。
而智能体不知道"执业资格"这回事。你问它开曼架构，它会用和讲中国法完全一样的语气给你一段分析。这个默认行为需要一条常驻规则去压住，不能指望我在每个涉外项目上都记得提醒。
第 4 项放全局的理由更实际：这是最容易漏、又最应该由我们回答的部分。客户问境外架构，外国法那一侧我们只能加免责声明；但返程投资的外汇登记、境外上市的备案、数据出境的合规——全是中国法，全是本职。把这条写进全局，等于每次遇到跨境问题都自动提醒一次"别忘了答中国法这一侧"。
第十二章 专业语气要求
原文（节选）
应当：专业、精确、保护客户利益、实用。
应避免：空泛的免责声明；过度学术化分析；缺乏依据的法律结论；过度重复与套话；只指出问题而不给出具体建议文本的模糊建议；用"建议咨询专业律师"作为结论。
为什么写在全局
因为这几条要避免的东西，是智能体面向公众场景的默认话术，在我这里每一次都是噪音。
最典型的是最后一条。智能体在涉及法律问题时几乎条件反射地会加一句"建议咨询专业律师"——而使用它的人本身就是律师。这句话在这个语境里没有任何意义。
这类"默认话术的清理"必须常驻，因为它是模型的固有倾向：清理一次没用，它下次还会加。
第十三章 多 Agent 协作规则
原文（节选）
- 子代理主要负责证据抽取、法律依据核验、主体及风险核查、事实比对、底稿匹配和文档验收；子代理不作最终法律判断。
- 子代理交付格式：任务范围与已完成事项 / 结论 / 资料来源与证据位置（文件名 + 页码／条款号／案号）/ 结论边界与不适用情形 /【待核验】【待公司确认】清单。
- 严格区分登记、协议、付款、实缴、税务和控制关系，不得由一类材料推导另一类事实。
- 同一文件同一时间只能由一个代理修改。
为什么写在全局
第 3 项那个五段式回报格式，是所有任务共用的交接格式。不管子代理这次做的是查工商还是比对合同，它回报的结构应当一致——否则主代理无法统一复核，我也无法快速判断哪一条结论是靠得住的。
第 4 项是这一章里我认为最必须放全局的一条。"登记不等于出资、协议不等于付款、流水不等于出资款"，这个原则在尽调、诉讼、常法核查里全部适用。 它是一条法律事实认定的基本规则，不是某类业务的技巧。
而且智能体天然倾向于把这些材料串成一条通顺的叙事——叙事通顺是它的偏好。这种倾向必须被一条常驻规则明确禁止，靠我每次提醒是拦不住的。
第十四章 交付前自检清单
原文（节选）
每次交付成文文件前逐项确认，并在回复中报告未通过项： 立场正确 / 无编造 / 引用合规 / 事实来源 / 一致性 / 编号 / 格式 / 签署页 / 命名与版本 / 脱敏 / 待办清单 / 可视核验。
为什么写在全局
这一章的内容前面各章都写过，为什么还要重复一遍放在末尾？
因为这是全局指令内部的一个补丁：一份较长的常驻指令，前面章节的约束力在任务执行到后半段时会衰减。末尾放一张清单，作用是在交付前把前面的要求重新激活一次。
它必须在全局层，因为**"交付前自检"这个动作本身是每次都要做的**。如果只在某次对话里说"这次交之前检查一遍格式"，那没说的那些次就不会检查——而恰恰是我忘了说的那次最容易出问题。
"报告未通过项"这个要求也放全局，因为它把"没做完"从隐藏状态变成了可见状态。这是一条关于如何交待未完成事项的通用规则，与具体项目无关。
附录 A 权威核验来源清单
原文（节选）：国家法律法规数据库（flk.npc.gov.cn）、国家企业信用信息公示系统（www.gsxt.gov.cn）、中国裁判文书网（wenshu.court.gov.cn）、最高人民法院、证监会、北交所、股转系统、市场监管总局、金融监管总局、网信办、外汇局、知识产权局等。
为什么写在全局
因为第三章规定了"必须回官方来源核验"，如果不把"官方来源在哪"一并写进全局，这条禁令的执行率会大幅下降——智能体会退回它记得的、更方便的渠道。
而这份网址清单，对所有项目都是同一份。它是最典型的"每次都可能用到、内容永远不变"的参考资料，正好属于全局层。
附录 B 本机文件处理与 OCR 工具
原文（节选）
- 有文本层的 PDF 一律先用 pdftotext 或 pymupdf 直接提取文字，不启用 OCR。
- 需 OCR 的首选 ocrmac（完全本地运行、客户文件不外传）。
- OCR 结果不得直接作为法律事实依据：关键数字、姓名、日期、金额须回原图逐一核对。
为什么写在全局
因为文字识别是每个项目都要做的基础动作——客户发来的扫描件、工商内档、银行流水，哪个项目都有。工具选择和使用顺序不随项目变化，属于全局。
更重要的是第 2 条和第 6 条各自连着一条红线："优先用本地工具"连着第二章保密（客户文件不外传）；"识别结果不得直接作为事实依据"连着第三章反编造（识别错一个数字，会一路传导到出资核查结论）。
既然它们服务的是全局层的红线，它们本身就应该在全局层。
结尾：什么不该写进全局
反过来说，下面这些我刻意没有写进全局指令：
| 内容 | 该放哪 | 为什么 |
|---|---|---|
| 客户的真实名称 | 项目指令 | 全局是公开维护的，客户名一律用【】占位；具体是谁在项目层交代 |
| 本次交易的架构、商业条款 | 对话 | 每次都不一样，说一次就行 |
| 这次我代表哪一方 | 对话 | 全局只规定"从客户一方出发"这个规则，不规定这次的当事人 |
| 某个项目的特殊口径 | 项目指令 | 比如某项目约定了不同的违约金比例、某客户要求用他们的模板 |
| 尽调报告、股权沿革、章程审查等各类业务的具体做法 | 专项提示词 | 这些内容进全局会稀释全局层——做合同审查时，一半内容是噪音 |
| 一次性的偏好 | 对话 | "这次只要要点不要全文"、"这次先给我看结构" |
一句话总结这套分层：
全局指令回答"我们所是怎么做事的"， 项目指令回答"这个项目有什么特别的"， 对话回答"这一次我要什么"。
三个问题的答案更新频率完全不同，所以要写在三个地方。写错层的代价是：该常驻的东西每次都要重说，不该常驻的东西每次都在占位置。
对应通用指令版本：V3 | 本文写作日期：2026 年 9 月 1 日
