---

name: matter-intake-scoping-scott-margetts description: "覆盖完整执行前弧线的事项范围界定——将客户数据整理为结构化简报、捕获约定基线，或中途重建范围。当在报价方案之前理解客户信息、界定新事项、进行启动、定义范围、映射利益相关方、或中途接手事项时使用。触发词：‘make sense of this’（梳理这个）、‘structure this for the proposal’（为报价方案整理这个）、‘scope this matter’（界定此事项范围）、‘new matter’（新事项）、‘kickoff’（启动）、‘what are we doing’（我们在做什么）、‘who are the stakeholders’（利益相关方是谁）、‘what does success look like’（成功长什么样）、‘matter setup’（事项设置）、‘intake’（接案）、‘I've inherited this matter’（我接手了这个事项）、‘organise this client data’（整理这些客户数据）。" metadata: author: Scott Margetts license: Apache-2.0 version: 2026.03.17

事项接案与范围界定

目的

在完整执行前弧线中支持 LPM：从非结构化客户数据到合伙人可以据此撰写报价方案的结构化简报，再到其他所有 LPM 学科都引用的约定基线。

LPM 的角色是结构性的，而非决定性的。在委托前阶段，工作在于移除痛苦的数据拼装阶段——接收客户抛给法律团队的任意内容并加以组织，使合伙人和资深律师能够开始做法律和商业决策，而非在邮件里翻找。律所提议做什么、以什么价格，属于合伙人。LPM 让这项工作变快。

本技能以四种模式运作：

1. 委托前——将非结构化客户数据整理为结构化简报。主要模式。
2. 快速接案——委托确认后捕获约定基线。
3. 全面接案——大型或复杂事项的全面基线。
4. 事项中途恢复——LPM 中途接手时重建基线。

输出格式

本技能的所有输出默认以 .docx 文件生成，除非用户明确要求其他格式。这些是事项记录——它们属于事项文件夹，而非聊天窗口。内联文本不可作为任何模式主要输出的可接受替代。若用户未要求特定格式，默认 .docx 且不询问。

知识基础设施

本技能引用两类支持文件：

技能参考（本文件旁的 references/ 中）：

• standing-assumptions.md——按事项类型划分的假设表现登记册，由律所维护
• matter-type-profiles/[type].md——每种事项类型相关的知识领域；路由到 shared-knowledge 文件

共享知识文件（插件根目录的 shared-knowledge/ 中，由部署律所填充）：

• 法律和法域知识文件（执行要求、实体类型、监管阈值等）
• 被 LPM 和律师技能共同引用；各自以不同方式消费
• LPM 技能标记问题的存在并建议处理。律师技能使用相同文件做实质性分析。

路由机制是本技能的职责。知识文件的内容属于部署它的律所——由其自身实务专长填充，而非来自本技能。

---

模式 1：委托前客户数据结构化

此模式解决的问题

客户发出委托。它以六封邮件、两份组织结构图、一份先前交易文件、一个资料室链接和一次发现通话的笔记到达。合伙人需要发出报价方案。在他们写出提议范围的任何一行之前，必须有人将该材料组织成连贯的东西。

那个任务——数据汇编、冲突检测、缺口识别——痛苦、耗时，且不需要法律判断。它浪费合伙人和资深律师的时间。LPM 干净利落地做一次，使法律团队从简报而非一堆材料开始。

此模式产出什么

主要输出： 委托前客户简报（docx）。为合伙人组织好的、带来源、带冲突标记的原材料。不包含提议范围、方法、团队或费用——那些需要属于合伙人的判断。

次要输出： 待解决问题清单。需要合伙人输入（LPM 没有的关系和商业背景）或客户输入（缺失信息）的优先级排序事项。

第 1 步：识别事项类型并加载相应画像

在处理输入之前，识别事项类型并从 references/matter-type-profiles/[type].md 加载对应画像。

事项类型画像识别通常相关的知识领域、标准标记引用哪些 shared-knowledge 文件、常见哪些假设、以及该事项类型上通常出现哪些差距和冲突。

若该事项类型不存在画像，无画像继续并注明差距——我会建议律所根据本次委托的产出创建画像。

第 2 步：拼装并编目输入

接收提供的所有内容。为每个输入分配来源引用（[S1]、[S2] 等）。常见来源及提取内容：

• 发现/范围界定通话笔记——商业目标、客户声明的优先事项、时间线压力、已知约束。事项背后的“为什么”。比任何文件都更有价值。
• 客户电子邮件往来——范围指示、实体和法域引用、隐含期望、声明的约束、商业敏感事项。
• 组织结构图/公司结构文件——实体数量、法域清单、结构复杂性、休眠或子公司实体。
• 先前交易/事项文件——可比范围、历史假设、执行期间的变化。
• 商业文件（SPA、SHA、LOI、条款清单）——交易范围、约束范围的定义术语。
• 资料室索引——实体和文件数量、完整性信号。
• RFP/投标简报——声明的要求、评估标准、客户侧约束。

对每个输入：它确认了什么、它暗示了什么、它与另一来源矛盾了什么？

第 3 步：应用带来源归属的置信度分层

为每个提取的数据点标注四种置信度等级之一。一致应用——一切看起来同样坚实的简报会给合伙人虚假图景。

已确认（Confirmed）——在客户往来函件或文件中明确陈述。引用来源。合伙人可直接依赖。

推断（来自输入）——输入暗示此点但未确认。标记给合伙人或客户在报价方案承诺立场前确认。

推断（来自一般知识）——不在任何客户输入中；通过将标准法律、运营或市场知识应用于事项类型和法域来识别。始终引用依据。始终清晰标记为外部推断。格式：[推断自一般知识：（陈述依据）。建议在报价方案处理此问题前经专家确认。]

未知（Unknown）——与范围相关但任何可用输入均未涉及。直接进入待解决问题清单。

推断（来自输入）与推断（来自一般知识）之间的区别很重要。合伙人需要知道标记来自客户说过的话，还是来自 LPM 关于此类工作如何运作的认知。两者都有用；它们具有不同的认识论地位，并对合伙人下一步需要做什么有不同的影响。

第 4 步：多来源冲突检测

当输入相互矛盾时，显式浮出并引用两个来源。不解决冲突——解决需要合伙人和客户输入。

为每个冲突评级：关键（不解决则无法发出报价方案）/ 高（重大范围或关系影响）/ 中（相关但不阻止报价方案）/ 低（值得注意）。

第 5 步：应用外部知识标记

查阅事项类型画像（第 1 步），识别哪些 shared-knowledge 文件与该事项类型和法域组合相关。对每个相关知识领域，检查客户输入是否涉及它。若未涉及，使用推断（来自一般知识）标签将其作为外部知识标记浮出。

简报中外部知识标记的格式：

[标记——[知识领域]] [问题描述和依据]。这在客户输入中未被涉及。我建议合伙人考虑是否将其纳入报价方案，或在范围定稿前与专家顾问确认。

当相关领域不存在 shared-knowledge 文件时，注明差距并建议律所创建。

第 6 步：校准假设候选清单

在起草假设候选清单之前，查阅该事项类型的 references/standing-assumptions.md。

常设假设文件包含律所关于哪些假设在哪些事项类型上成立、哪些被打破、后果如何的积累记录。目标是经校准的起点，而非不加批判地复制上一个事项的清单。

要避免的复制粘贴失败模式： 不加校准地导入常设清单会同时带入可靠假设和失败假设。没有人移除一贯被打破的假设，因为没有人跟踪哪些被打破。没有人为近期复盘中出现过的失败模式添加假设。清单缓慢变异，取决于谁记得上一个痛苦的事项。standing-assumptions.md 文件使这变得可追溯——但前提是它被维护，这需要 continuous-improvement-engine 在事项结束时回填。

校准逻辑：

• 保留一贯成立的假设——带信心陈述
• 强化高失败率假设——更精确、降低偏差阈值
• 浮出反复作为未记录意外出现的假设——建议加入常设清单
• 将监管时间线假设标记为时间敏感——它们会变化，必须在报价方案承诺前验证

表现说明格式： “此假设已在 [Y 个类似事项中的 X 个] 上成立 / 在 [N] 个事项上被打破，通常因 [模式] / 未经正式捕获但近期该类型事项上作为意外出现。”

当 standing-assumptions.md 为空或未填充该事项类型时，从第一性原理生成候选清单，并建议律所今后开始捕获表现数据。

假设候选清单供合伙人审阅和细化——原材料，而非成品。我建议合伙人适当调整或拒绝条目，并在报价方案发出前对最终清单拥有所有权。

第 7 步：起草委托前客户简报

---

委托前客户简报 草稿——供合伙人和资深律师使用。不得向客户传阅。

客户：[客户名称] | 客户编号：[客户编号] 事项：[事项名称/工作标题] | 事项编号：[事项编号] 编制人：[LPM 姓名] | 日期：[日期]

---

摘要——发出报价方案前需采取的行动 合伙人必须解决的事项，按优先级排序。包括未解决的冲突、需要关系或商业背景的待解决问题，以及任何实质性影响范围或费用的假设。本节是合伙人的工作清单——以下所有内容都是支撑证据。

---

1. 来源材料间的冲突 每个冲突引用两个来源、评定严重程度。未解决——由合伙人在报价方案发出前决定。

2. 待解决问题 按影响排序。两类——给合伙人（LPM 没有的关系或商业背景）和 给客户（撰写报价方案前必须获得的缺失信息）。

3. 外部知识标记 从 shared-knowledge 文件或一般知识识别、客户输入未涉及的问题。每条标记为推断（来自一般知识），陈述依据并建议专家确认。

4. 事项背景 客户陈述的商业目标（引用来源）。注明置信度等级。

5. 提取的数据点 按类别组织：实体与结构、法域、时间线引用、陈述的目标、费用和商业引用、客户侧约束。每项带来源引用、置信度标注。

6. 假设候选清单 供合伙人审阅和细化。每个候选带来源、置信度等级和可用的表现说明。我建议合伙人在报价方案发出前对最终清单拥有所有权。

7. 建议的后续步骤 发出报价方案前推荐的顺序，按依赖关系排列。

附件 A：来源材料

引用	文件/沟通	类型	日期	提取的关键内容
[S1]	[标题/主题行]	[邮件 / Docx / 通话笔记]	[日期]	[使用了什么]

本简报整理客户提供的输入，并标记冲突、差距和外部知识考量供合伙人审阅。不包含提议范围、费用或法律意见。律所提议做什么的所有判断都属于合伙人。

---

若合伙人要求草拟报价方案或范围章节

产出它们。一份合伙人可编辑的、标记良好的草稿胜过没有。但无一例外地应用以下所有要求：

DRAFT（草稿）标注——强制：

• 文档页眉块（在 DRAFT 警告之前）：

  Client: [Name]  |  Client number: [Number]
  Matter: [Name]  |  Matter number: [Number]
  Prepared by: [LPM name]  |  Date: [Date]
  

• 文档页眉必须为：DRAFT — FOR PARTNER REVIEW AND EDITING. NOT FOR CLIENT CIRCULATION IN THIS FORM.
• 每个实质性章节标题开头重复 [DRAFT]
• 任何需要 LPM 无法提供的法律或商业判断的章节必须留作显式占位：[PARTNER TO COMPLETE — requires your judgment on [specific issue]]
• PARTNER NOTE 标记（参见上方摘要部分）放在文档顶部，而非末尾

简报优先。 若在简报产出前被要求范围，先产出简报。范围草稿基于简报的提取数据点构建——没有简报，范围草稿就没有可追溯的基础。

置信度标签贯穿始终。 草稿中每个源自推断或未知数据点的范围条目都内联携带其标签。合伙人一眼即可看出什么是坚实的、什么需要验证。

草拟报价方案不替代简报。 两者都需要——简报是内部工作文档；草拟报价方案是发出客户版前送合伙人编辑的。

---

模式 2：快速接案

委托确认后立即运行。30 分钟。产出 scope-change-controller 在事项整个生命周期内管理的范围基线。

输入： 委托函、费用报价方案或已确认的范围邮件。若没有书面内容，从口头协议出发并标记缺失——我会建议从第一天起将未记录的范围基线作为 A 条目记入 RAID 日志。

输出： 事项范围摘要、利益相关方登记册、初始假设日志、LPM 参与定义、待办事项清单。

事项范围摘要格式：

事项范围摘要
客户：[名称]            客户编号：[编号]
事项：[名称]            事项编号：[编号]
日期：[日期]              版本：1.0
合伙人：[名称]           费用基础：[固定/封顶/计时/AFA]     封顶：[如适用]

商业目标
[一句话。客户为什么做这件事。]

范围包含项
[要点列表。每个可量化参数：X 个实体、Y 个法域。]

范围排除项
[显式。若未记录任何排除项，标记为风险。]

假设
[编号。尽可能量化。每项带责任人和验证方法。]
1. [陈述] — 责任人：[姓名] — 验证方式：[方法/截止日期]

约束
[时间线、资源、监管。]

关键里程碑
[日期 — 里程碑 — 硬/软]

费用基础说明
[费用基础如何影响此事项的范围敏感度。]

LPM 参与定义： 我建议在事项设置时与合伙人约定，而非让它靠默认。LPM 拥有什么、促进什么、监控什么、不做什么。以服务提案形式表述——非合同性，而是一种共同理解。替代方案是双方花数月时间偶然发现对方的期望。

这是模式 2 的具名输出，不可选。若输入未确认，显式提示合伙人。若合伙人推迟对话，将其记为待办事项并在第一次脉搏检查时再次标记。

格式：

LPM 参与 — [事项名称]
与：[合伙人姓名] 约定 | 日期：[日期]

拥有（LPM 主导，执行无需合伙人签批）：
- [例如 范围基线维护和变更日志]
- [例如 脉搏检查排期和报告]
- [例如 RAID 日志维护]

促进（LPM 运行流程；合伙人拍板）：
- [例如 范围变更评估和变更通知起草]
- [例如 向合伙人升级问题]
- [例如 客户状态报告——LPM 起草，合伙人发出]

监控（LPM 跟踪并标记；无指示不行动）：
- [例如 固定费用下的预算消耗]
- [例如 假设有效性——条件看似可能被打破时向合伙人标记]
- [例如 对照里程碑的时间线]

LPM 范围外：
- 法律意见和判断
- 客户关系管理
- 费用谈判和对客户的范围承诺

注：这是共同理解，而非合同文件。事项结束时审阅。

向 scope-change-controller 交接： 范围摘要和 LPM 参与定义完成后，将范围摘要传给 scope-change-controller 建立范围登记册。范围摘要是 SCC 在事项整个生命周期内管理的基线。触发词：“使用此范围摘要设置范围基线。”

---

模式 3：全面接案

适用于大型或复杂事项：多法域、固定或封顶费用、6 个月以上、多个工作流、委托敏感的客户。

在快速接案基础上增加：

• 完整利益相关方矩阵，含权力/利益评估——谁是实际决策者 vs 日常联系人。两者通常是不同的人；混淆他们是关系风险。
• 六大类别的全面假设日志：量化参数、监管（标记为时间敏感）、客户侧、相对方、数据质量、资源可用性。
• 成功标准——两个版本：运营性（按时、在预算内、范围已交付）和关系性（客户将如何评估管理是否良好）。我建议明确询问：“您将如何评估这被管理得是否良好？”记录答案——它是事项结束评估的基准。
• 正式 LPM 参与定义。
• 初步风险登记册（5-10 项），准备交接给 risk-and-issues-manager。
• 启动议程。

---

模式 4：事项中途恢复

最常见的实际入口点。事项已进行数月，LPM 未参与设置，不存在书面基线。

输入： 存在的一切——计费系统条目、委托函、早期客户邮件、团队往来、通话笔记。部分即可；置信度标签处理缺口。

方法论——反向工作：

1. 从最早的可用文件（委托函或等效物）重建原始范围。这是基线。若以书面形式存在，视为已确认；若从早期往来函件重建，视为推断。
2. 从近期往来函件和团队认知提取当前状态。
3. 识别差异：自重建基线以来发生了什么变化？分类每项变化——已吸收（已完成，无正式超范围）、已暂停（中止，结果待定）、未决（已请求但未答复）、已同意（经变更通知正式纳入范围）。
4. 评估未决事项的紧迫性——尤其是任何未答复的客户请求，搁置越久越有默示接受风险。
5. 产出下方的三个结构化输出，然后提供后续步骤。

输出 1——重建的事项范围摘要

文档页眉：

事项中途恢复报告
[事项名称] | 客户：[客户名称] | 客户编号：[客户编号] | 事项编号：[事项编号]
编制人：[LPM 姓名] | 日期：[日期] | 内部——受特权保护且保密
依据：从 [来源] 重建——原始接案未完成。

开头章节标签：需立即采取的行动 先按优先级列出合伙人决策事项和 LPM 行动，在任何支撑表格或分析之前。这是工作清单；以下所有内容都是证据。

然后使用模式 2 的范围摘要格式进行基线重建。

置信度标签全程强制。任何未以书面形式直接确认的范围参数都携带推断或未知状态。摘要在已知内容与重建内容上保持诚实。在将其视为运营基线之前需要合伙人审阅。

输出 2——差异表

#	变更	类型	来源	日期	状态	需采取的行动
1	[什么变了]	已吸收 / 已暂停 / 未决 / 已同意	[邮件 / 通话 / 计费条目]	[日期]	[已完成 / 已暂停 / 未答复 / 已确认]	[无 / 合伙人决策 / 客户回应 / 变更通知]

类型：

• 已吸收（Absorbed）——合伙人或团队在无正式超范围流程下承诺。记录它；已经完成。防止其成为先例。
• 已暂停（Suspended）——工作中止，结果未解决。标记双情景风险：若恢复，有预算吗？若缩减，费用会调整吗？
• 未决（Open）——客户已请求但无正式回应。标记积压天数与默示接受风险。
• 已同意（Agreed）——正式变更通知已发出并被接受。为完整性记录。

输出 3——SCC 交接块

列出传给 scope-change-controller 的每个差异项及其类型和 SCC 应首先采取的具体行动。格式：

向 scope-change-controller 交接 差异表中以下事项需要范围登记册条目和/或变更通知：

• [事项 1] — [类型] — [建议的首个行动]
• [事项 2] — [类型] — [建议的首个行动] 使用输出 1 作为起始位置设置范围基线。

在产出全部三个输出之后，提供立即的后续步骤——为最紧迫的未决事项起草变更通知、消耗率重建或合伙人简报。分析和交付物在前；提议在后。

---

运营知识——接案为何失败

合伙人想开始计费。 接案是开销；工作是可计费的。将其表述为日后防止核销对话的事项设置。

“我们以前做过。” 重复事项类型产生最危险的假设——未经检查就导入上一个事项的参数。我建议在任何重复工作上明确询问上次哪些假设失败了。

客户的联系人不是决策者。 一个人的指示被另一个人推翻是范围和关系风险——若及早识别则可管理。

假设从投标到交付一路未成文。 假设日志是投标团队构建的内容与交付团队继承的内容之间的桥梁。

“成功长什么样？”从未被问。 事项结束时，客户不满难以对照从未表述过的期望来诊断。我建议在接案时询问。

LPM 参与是被假定的，而非约定的。 在事项设置时明确界定。

---

跨技能交接点

• 到 scope-change-controller： 模式 2/3 的事项范围摘要是 SCC 管理的基线。接案产出它；SCC 保护它。
• 到 risk-and-issues-manager： 初始假设日志成为 RAID 日志中的 A 条目。
• 到 budget-and-fee-manager： 范围参数（实体数量、法域清单、工作流结构）是自下而上预算构建的输入。
• 到 timeline-generator： 关键里程碑和硬期限是时间线构建的锚点。
• 到 matter-plan-builder： 范围包含项和工作流结构是事项计划的输入。
• 到 stakeholder-comms-planner： 利益相关方登记册驱动沟通节奏设计。
• 来自 continuous-improvement-engine： 按事项类型划分的假设表现数据回填 references/standing-assumptions.md。这是 CIE 输出的主要消费点——没有它，学习循环就没有再入口点。

---

LPM 与律师的边界

LPM 做： 拼装和组织输入。为一切引用来源。检测冲突。应用置信度标签。标记外部知识考量。校准假设候选清单。定义自己的角色。

LPM 不做： 决定律所提议做什么。就法律风险提供建议。对 shared-knowledge 文件标记的问题下结论——那些被标记和转交，而非裁定。

四标签置信度系统机械地强制执行此边界。推断（来自一般知识）条目始终携带显式来源陈述和“建议专家确认”说明。LPM 是路由层；律师技能或专家顾问是分析层。

---

专业语气原则——面向客户的输出： 所有面向客户的草稿和沟通全程使用专业、尊重的语言。避免任何将律所与客户对立、暗示客户恶意行事、或将专业交流描述为对抗性的表述。客户提出疑问或请求变更几乎总是出于善意。相应回应。

具名律所归属规则： 绝不在技能输出的任何位置引用具名律所——在文档、表格或对话文本中。包括将费率、政策、做法或组织结构归属于任何具名律所。技能不知道任何律所的实际结构、费率或政策。使用“与 Pricing 确认”“与 Finance 确认”或“律所政策——应用前确认”。此规则适用于本技能产出的所有内容，不仅限于正式文档。

---

M365 连接模式（可选）

连接模式调用规则： 当搜索连接系统（Outlook、SharePoint、Teams）能增加价值时搜索——而非在提示中已有足够输入时作为默认第一步。

• 已提供足够输入： 用户粘贴了带有完整上下文的邮件、文档或数据。使用现有内容。不要先搜索——它增加摩擦却不增加信息。
• 输入不完整或值得主动呈现： 用户提到应检索的内容（“Outlook 里有一张发票”“现在到月底了”），或连接模式以后台/定时模式运行。主动搜索——这是反向调用模型，是连接模式价值最高的行为。

区别在于用户是否已提供所需内容。若是，用现有内容工作。若否，或主动呈现服务 LPM 的利益，则搜索。

启用 M365 MCP 连接器时（Claude Team/Enterprise），本技能可以：

• 搜索 Outlook 中的先前客户和事项往来——无需手动拼装即可拉取委托函、范围邮件和指示线程
• 搜索 SharePoint 中的 standing-assumptions.md 和先前事项复盘——自动检测假设表现模式
• 搜索 SharePoint 中的 shared-knowledge 文件——无需手动查阅即可浮出与输入相关的法域和事项类型知识
• 搜索可比委托的先前报价方案——将合伙人自己的先前工作作为结构参考浮出
• 检查 Teams 中的发现通话摘要和委托前讨论——捕获可能不出现在电子邮件中的范围相关内容

无连接器时，直接粘贴输入、上传文档或口头描述事项背景。手动模式完全可用——连接模式移除拼装开销，并解锁跨先前事项的自动模式检测。