TRO 响应在邮件之前就已经开始

Core Claim

电商卖家遇到 TRO 时，通常不会带着一个干净的法律问题出现。他们更可能带着冻结的 Amazon 或 Temu 余额、一张平台通知截图、一封律所邮件、一个还没读懂的法院文件，然后问：“我的账户昨天被冻结了，我现在该怎么办？”

这一分钟正是许多法律 AI 产品最容易走偏的地方。最诱人的产品形态是邮件生成器：让用户填律所邮箱，自动写和解请求，再让用户复制发送。但在 TRO 事项里，这个顺序是反的。邮件不是第一产品；邮件之前的案件状态才是产品。只有当冻结通知、冻结金额、涉案销售、毛利、证据缺口和可选路径被整理清楚，外发草稿才有意义。

Lawless TRO response workflow 的核心判断很简单：冻结账户的恐慌应该先变成结构化案件状态，再变成对外沟通。这个状态至少有五部分：

• 通知来源：到底是什么触发了案件，是平台冻结通知、律所邮件、complaint、summons，还是 TRO order。

• 资金暴露：冻结金额、涉案商品销售额、毛利、店铺或账户地区，以及冻结金额和涉案销售之间是否明显不成比例。

• 证据缺口：缺 complaint、缺 ASIN 或 listing 证据、缺销售导出、缺管辖州发货证据、缺货源或授权记录。

• 路径卡：先补证、和解、律师/抗辩复核、平台解冻优先、风险/放弃评估。

• 草稿审查：任何对外消息都只能在案件状态可读之后出现，并且必须保留人工法律审查边界。

这个区分看起来像产品结构问题，但它直接影响用户判断。卖家看到 “$25,000 frozen” 时，很容易把这个数字当作账单或赔偿额。TRO 技能的和解框架把冻结金额和法律责任拆开：冻结是程序性压力，谈判分析通常应从涉案商品毛利开始，再结合抗辩、时间压力、原告行为和证据强弱调整。这个拆分会改变用户的心理状态和操作路径：他不再只盯着一个恐怖数字，而是开始知道哪些文件能改变判断。

用户先有紧急感，后有事实

TRO 响应最反常的地方，是最紧急的事情往往不是系统应该立刻做的事情。

用户想要行动。对方律师可能给了期限，平台资金可能被冻结，商品可能被下架，卖家甚至不确定问题是商标、版权、专利、平台政策，还是联邦法院命令。他可能只有卖家后台的一张截图。在这种状态下，让用户选择法律策略太早；让用户填写一整页法律问卷也很不友好，因为他还不知道哪些细节重要。

产品问题比“收集事实”更具体。工作区不应该像一个生成邮件的表单，也不应该要求用户先理解 TRO 才能使用。它应该允许用户上传混乱的通知、邮件、PDF、截图或自然语言描述，然后把这些材料整理成稳定的案件摘要。

关键不是取消结构，而是把结构延后到它有用的时候。界面可以从一个输入面和一个实时案件摘要开始；随着智能体读取材料，右侧逐渐积累已知事实、未知事实、已看文件、资金数字、期限和下一步动作。用户仍然有对话入口，但对话不是系统记录。案件交付物才是。

系统真正追踪的东西

当前 Lawless web app 有一个共享案件工作区，可以运行不同法律工作流。TRO 响应通过 /workspaces/workspace?caseType=tro 进入 TRO 配置，加载 ecommerce-tro-settlement 技能，并把结果指向 TRO 报告交付物路径。同一个外壳也可以支持专利检索，但任务合同完全不同：专利检索是证据检索和主张比对，TRO response 是围绕冻结资金、期限、缺失文件和人工路径选择的案件响应。

TRO intake 不是一句“描述你的案件”。配置会追踪被告和店铺信息、案件信息、平台通知和送达证据、涉案商品两年美国销售、ASIN/listing 证据、货源证据、冻结账户和金额、冻结金额中有多少和涉案商品相关、侵权立场、和解目标、已有律师以及证据包上传。

这张清单很长，因为法律状况不是单维度的。但它也解释了为什么第一屏不能只是巨大问卷。产品必须同时支持两种模式：

• 对已知且关键的事实使用稳定字段，例如平台、冻结金额、毛利、案号、管辖州销售、通知来源。

• 对用户只有 PDF、截图、邮件或片段叙述的情况，允许智能体先阅读、抽取和追问。

在 web app 路由里，产品模式决定可用技能。TRO 模式选择 ecommerce-tro-settlement，专利模式选择 patent-find。路由会把已选技能资源镜像到沙箱，流式运行智能体，持久化会话状态，并把案件文件夹快照回会话存储。这样，案件交付物不是一个聊天回答，而是可以审查、重新加载和继续处理的工作成果。

产品层边界也很重要。Lawless 应用层应该负责编排案件和会话设置、intake 持久化、文件上传、技能选择、智能体任务创建和交付物加载。法律分析属于已选技能和智能体运行时，而不是硬编码报告 endpoint。这样 UI 不会假装自己理解全部法律细节；UI 负责稳定表示，技能负责在边界内做法律和业务推理。

三种旧做法为什么失败

第一种失败是邮件生成器失败。它把用户的恐慌当成对文案的请求。邮件可以写得很顺，却在策略上错得很早：缺案件来源，缺冻结金额上下文，缺毛利，缺管辖州销售，缺证据姿态。在 TRO 案件里，过早邮件可能承认太多、披露太多、锚定错误金额，或者在没有事实支撑时提出救济请求。

第二种失败是向导式表单失败。它要求每个用户按顺序回答所有法律问题。这适合窄合规表单，不适合不知道 TRO 是什么的卖家。用户还分不清平台通知和法院命令，不知道冻结金额是否等于法律责任，也不知道某个律所名是否关键。用户需要方向感，才有能力给出干净事实。

第三种失败是黑箱建议失败。它给建议，但不显示是什么事实改变了建议。TRO 策略依赖具体证据：是否向管辖州销售，涉案商品是否早于原告权利，是否有授权链条，毛利是多少，实际收到了哪些文件，冻结金额中有多少和涉案商品相关。没有这些字段，建议会显得自信，却无法被审查。

Lawless 的设计试图避开这三种失败：用户可以以混乱方式开始，智能体可以解释混乱材料，工作区仍然显示驱动下一步决策的结构化案件状态。

资金暴露不是一个数字

TRO 技能材料里最重要的经验之一，是把钱拆开。

冻结余额是压力数字。它影响现金流、时间偏好和和解紧迫性，也给原告方带来杠杆，因为卖家希望尽快解冻账户。

涉案商品毛利更接近和解基线。和解因素把毛利作为损害分析的起点，核心计算是收入减商品成本。材料也提醒：平台费、广告费和一般运营费用，不等于这项计算中的 product COGS。

冻结账户中涉案商品占比是不匹配信号。如果店铺冻结了 $25,000，但被指控 listing 只产生 $800 收入和 $300 毛利，那么冻结对商业现金流可能是致命压力，但被指控商品层面的利润仍然很小。这不自动赢得案件，但会改变谈判姿态。

系统必须把这些数字分开，因为每个数字回答不同问题：

• 卖家此刻有多紧急，取决于冻结金额和账户访问。

• 和解计算可能从哪里开始，取决于毛利和销售窗口。

• 冻结是否不成比例，取决于冻结余额和涉案商品暴露的关系。

• 抗辩是否改变区间，取决于管辖权、授权、在先使用、权利缺陷或程序问题。

因此资金面板不是装饰性 UI，而是防止坏推理的护栏。如果工作区把所有钱都压成“冻结金额”，产品就在无意中教用户按照对方 demand letter 思考。只有保留区分，用户和复核人才能从案件事实出发。

证据缺口是工作流引擎

TRO response 的质量，取决于系统是否把缺失事实当成一等状态。

缺 complaint 和缺销售导出不是同一种缺口；缺律所邮件和缺货源 invoice 也不是同一种缺口；缺管辖州销售报告和缺和解目标更不是同一种缺口。每个缺口都会改变下一步最好做什么。

TRO 技能合同把这件事操作化。第一批 intake 会问平台、冻结金额、涉案商品收入和美国发货州。发货州在这个技能里不是可有可无，因为它们可能打开管辖权抗辩。后续收集会问律所、案号、products/ASINs、IP 类型、COGS/毛利，以及在 forum 已知后确认是否向管辖州销售。

抗辩 playbook 解释了为什么这些事实重要。没有向管辖州销售，如果有平台销售记录或发货记录支持，可能把案件从“付多少”转成“这个法院有没有管辖权”。在先使用、诉讼时效、授权、缺乏独创性、送达缺陷都需要不同证据。产品无法提前知道哪条路真实，直到它知道哪些证据存在。

所以工作区不能只说“需要更多证据”。它应该说清楚哪个缺口阻断哪个决定：

• 没有 complaint 或 TRO order，系统无法可靠识别法院、案号、plaintiff、claims 和程序期限。

• 没有平台冻结截图，系统无法验证账户和资金影响。

• 没有销售导出，系统无法区分收入、毛利和管辖州销售。

• 没有 listing 或产品证据，系统无法把 ASIN、页面和具体产品对应起来。

• 没有来源或授权证据，系统无法评估许可、供应商、在先使用或非故意侵权论点。

• 没有客户偏好，系统无法选择沟通姿态、紧急度、披露边界或和解容忍度。

这就是案件状态版本的法律分诊。智能体不只是回答问题，而是维护一张“仍然未知什么”的地图。

路径卡让人工选择显性化

事实足够清楚后，工作区可以显示路径卡。设计材料里的路径包括先补证、和解、抗辩/律师复核、风险/放弃评估；配置 intake 里还包括快速和解、先要求证据、保留律师/抗辩路径、优先平台解冻和“帮我决定”这类用户偏好。

路径卡有价值，因为它把隐藏的法律分叉变成可见选择。卖家可能以为问题只有一个：“怎么解冻账户？”系统可以展示几条不同路线：

• 先补证：向对方律所或平台索要更清楚的证明、ASIN 识别、文件或主张支持。

• 快速和解：计算区间，谈判，优先释放资金。

• 抗辩/律师复核：把管辖权、在先使用、授权、权利缺陷或程序送达证据打包给律师复核。

• 平台解冻优先：收集和解、撤案或释放文件，用于后续解冻平台账户。

• 风险/放弃评估：判断继续处理店铺或案件是否在商业上值得。

关键是，这些卡片不应该伪装成最终法律结论。它们是决策界面。产品可以基于事实提出建议，但路径选择属于用户和人类复核人；外部法律策略必须在审查后确认。

这也是为什么设计上不应该把“生成邮件”放成第一主动作。主动作应该是理解案件，再选择路径。邮件起草在下游。

草稿审查应该晚一点出现

TRO 工作流里的外发邮件必须晚出现。

起草前，技能规则要求先完成解释、事实收集、策略讨论、客户语气校准、分析和执行准备。系统不应该替用户选择语气、和解数字、期限、模板或让步。任何不可逆动作前，系统都要把决定回显给用户，并取得明确确认。

这听起来谨慎，因为这个领域必须谨慎。和解邮件不只是文字。它可能披露事实、锚定金额、塑造抗辩、放弃谈判杠杆，或和之后律师意见产生冲突。在 Lawless 模型里，AI 可以准备草稿，但客户选择姿态，律师或运营复核人审查结果。

输出渲染也应遵循同一原则。智能体流保持简洁，主要阅读面是交付物画布。密集策略备忘录、时间线、和解经济分析、证据清单和草稿预览应该进入报告交付物，而不是散落在会滚走的聊天气泡里。

机制：稳定外壳，智能体内部

这个项目最强的实现模式，是把稳定产品外壳和智能体法律工作拆开。

稳定外壳负责路由、认证、工作区会话状态、文件上传、问卷答案、语言区域、已选案件类型、交付物预览和重新加载行为。它知道 TRO response 使用 TRO 技能、写出 TRO 报告；它知道如何展示案件摘要、交付物、活动轨迹和控件。

智能体内部负责混乱解释：读取文件，追问缺失事实，区分平台通知和法院文件，解释冻结含义，从毛利计算和解区间，识别证据缺口，并在路径选择之后起草。

这个分工让产品不至于脆弱。硬编码的 “TRO report endpoint” 会把一种法律结构冻结在应用代码里；纯聊天会丢失稳定案件状态。共享工作区给产品一个可靠框架，同时允许技能随着法律工作流理解加深而演进。

当前路由代码体现了这个模式：注册 web 技能，按产品模式选择技能名，把已选技能资源镜像进沙箱，流式运行智能体，增量持久化引擎状态，通过客户端处理用户问题批次，并把生成的案件文件快照回会话存储。这些看起来是基础设施，但支撑的是产品主张：输出是可恢复案件交付物，不是一轮聊天答案。

当前证据支持什么

本地证据支持几个具体结论。

第一，TRO response 已经作为独立 caseType 接入 Lawless 共享工作区。配置里有 CaseWorkspaceType = "patent-search" | "tro"、TRO 产品模式、TRO 技能名、TRO 交付物路径、TRO 上下文开场和 TRO 问卷。公开工作区可以通过 caseType=tro 打开，/tro 也会导向这个工作区。

第二，系统把 TRO response 当作结构化 intake 问题。问卷包括店铺身份、案件身份、通知证据、涉案商品销售、listing 证据、货源证据、冻结账户、冻结金额中与涉案商品相关的比例、侵权立场、和解目标、其他律师和证据包。

第三，技能规则把策略放在起草之前。技能会要求平台、冻结金额、涉案商品收入、发货州、律所、案号、商品、IP 类型、COGS/毛利、管辖州确认、客户偏好、路径选择和发送前明确复核。和解邮件是可能输出，不是第一输出。

第四，资金模型是证据驱动的。和解因素把毛利和冻结余额分开，并把管辖权、在先使用、许可、权利缺陷、时间压力、原告侧风格和谈判执行作为改变和解姿态的因素。

第五，产品边界必须诚实。当前实现最强的是共享工作区层，TRO-specific 评测还薄于旁边的 patent-search 评测。项目证明的是工作流架构和案件交付物方向，不是成熟自治法律服务。

现在还不能解决什么

这个系统不会让法律判断消失。它做的是让判断之前的状态更可检查。

当前证据还不能证明 TRO 智能体能在真实案件中稳定识别每个缺失文件、正确计算和解区间，或起草律师级沟通文本。Patent-search 侧有更强的 benchmark 证据；TRO response 当前更多是产品和工作流证据，而不是结果质量证据。

还需要显式 gate 的风险包括：

• 文件解析风险：平台通知、律所邮件、complaint 和 TRO order 的权威性不同。

• 管辖州风险：管辖权分析依赖准确的销售和发货记录。

• 资金风险：毛利、收入、COGS、冻结余额和和解预算容易被混在一起。

• 披露风险：外发草稿可能过早披露事实或策略。

• 权威性风险：用户可能把路径卡当成法律意见，除非审查边界足够可见。

• 连续性风险：案件交付物必须经得起刷新、补证和复核人编辑。

下一步评测不应该是通用聊天 benchmark，而应该使用案件材料包：通知、complaint、平台截图、销售导出、产品证据和用户偏好记录。验证器应该检查系统是否正确识别通知来源，是否分开冻结金额和毛利，是否指出缺失证据，是否在状态足够前延迟草稿，是否保留路径选择，并生成有清楚边界的可审查交付物。

更大的产品经验

AI 法律工作经常失败，是因为它从用户要求的交付物开始，而不是从专家需要的状态开始。

用户要求邮件，是因为邮件是最可见的动作。专家需要的却是案件摘要、资金视图、时间线、证据缺口、路径对比和客户偏好。系统必须连接这两者，但不能假装这个连接本身就是法律判断。

TRO response 是很好的例子，因为压力非常直接：冻结制造恐惧，通知制造模糊，期限制造紧迫。一个有用的 AI 系统不能移除这些压力，但可以改变它们的形状。它可以把“我的账户被冻结了”变成：“我们知道通知来源，知道哪些钱数还缺，知道每条路径被哪些证据阻断，也知道任何外发草稿都必须在审查后才发生。”

这个主张比自动法律服务小很多，也更真实。Lawless TRO response 的价值不在于替卖家作出法律判断，而在于把冻结案件推进到可复核状态，让律师、运营或训练过的复核人可以在更清楚的上下文里接手。

参考材料

1. lawless-web-app/docs/case-workspace-inputs.md
2. lawless-web-app/docs/tro-agent-workspace-interaction-options.md
3. lawless-web-app/src/products/shared/case-workspace/caseWorkspaceConfig.ts
4. lawless-web-app/src/app/api/chat/route.ts
5. lawless-web-app/.agents/skills/ecommerce-tro-settlement/questionnaire.json