法律文书起草·小律同学AI

SKILL效率
效率 未标注权限 许可证不明确
安装这个技能

法律文书起草 AI 技能:基于 697 类文书模板库自动起草起诉状、答辩状、上诉状、法律意见书、仲裁裁决书等法律文书,服务端自动选择生成策略(模板生成/要素式/国标格式),支持案情澄清交互、长任务轮询、暂停恢复与取消。典型场景:起草民事起诉状、生成法律意见书、按修改要求重新起草。调用前需完成鉴权(客户端 OAuth 授权,或配置 API Key);与法律检索服务共用同一 MCP 服务。不适用于非法律文书写作、可直接提交法院的盖章文件、以及替代律师职业判断的诉讼策略。触发词:法律文书, 文书起草, 起诉状, 答辩状, 上诉状, 法律意见书, legal drafting。

一句话选型结论

按资料字段整理

法律文书起草·小律同学AI是效率类的 Agent Skill,安装方式未标注,权限级别未标注,许可证不明确,有可直接复制的安装命令。技能本质是给模型读的说明书,效果取决于模型与客户端;装完先用一个小任务验证,再放进正式流程。

分类效率 安装方式未标注 权限级别未标注权限 许可证许可证不明确
累计安装 未标注 本周 未标注
GitHub 星标 未标注 仓库 未标注
下载量 未标注 技能市场下载数
权限级别 未标注权限 安装前请确认风险范围
许可证 许可证不明确 未说明

安装

未标注
在支持 Skills 的客户端里执行,装完问一句「你有哪些技能」验证
skillhub install xiaolv-ai/legaldoc
  1. 1
    确认客户端支持

    确认你的客户端支持 Skills(Claude、Codex、Cursor 等),并升级到较新的版本。

  2. 2
    拿到技能文件

    执行上面的命令安装;也可以把仓库里的 SKILL.md 手动放进客户端的 skills 目录。

  3. 3
    刷新技能列表

    重新打开客户端,或刷新技能列表,让新放进来的技能被加载。

  4. 4
    验证是否生效

    问一句「你有哪些技能」,确认列表里出现它,再拿一个小任务试跑。

技能档案

效率
字段来自技能仓库与公开索引,中文说明由本站标注
作者 / 维护方xiaolv-ai仓库 未标注 · 版本 未标注
宿主客户端未标注技能可被这些客户端加载
安装方式未标注安装包 enterprise
权限级别未标注权限安装前请确认风险范围
许可证未说明许可证不明确,商用前请自行确认条款
仓库可用性available技能仓库当前是否可访问
最近核验未标注上游最后核验时间 · 数据更新 1791728759
正文体量25.2 KBSKILL.md 原文大小,越大说明说明书写得越细

典型使用场景

3 类
按分类整理的常见用法,具体以 SKILL.md 为准
整理待办与日程

把零散任务收进清单,排出优先级。

批量处理重复任务

把固定动作做成模板,重复执行。

把流程写成清单

把口头流程整理成可复用的步骤。

选择建议

装之前先看这几条
按条目字段给出的判断,不替你决定用不用

值得选的地方

  • 有可直接复制的安装命令,不用自己翻文档找入口。

先想清楚的地方

  • 没有标注权限级别,实际能做什么要装好后确认。
  • 许可证不明确,商用或二次分发前先到仓库确认条款。
  • 没有做站内核验,内容以作者仓库为准。
  • 技能只是说明书,实际效果取决于模型与客户端,装完先用小任务试一遍。

更适合

  • 需要在效率场景里给模型补一套做法的人。
  • 愿意先读一遍 SKILL.md、确认它会让模型做什么的人。

不太适合

  • 对许可证要求很严、必须明确可商用的人。
  • 只想装完就自动变强、不打算看说明书的人。

同类对比

6 个同类
同分类里挑最接近的几条,字段以各自详情页为准
技能权限级别安装方式累计安装宿主客户端安装命令
法律文书起草·小律同学AI当前 未标注权限 未标注 未标注 未标注 有
Nano PDF 文档 联网访问 ClawHub 市场 424.9 万 OpenClaw 有
自动更新程序 浏览器控制 ClawHub 市场 296.4 万 OpenClaw 有
Gemini 助手 联网访问 ClawHub 市场 254.7 万 OpenClaw 有
word DOCX 文档 联网访问 ClawHub 市场 239.6 万 OpenClaw 有
Excel XLSX 前端 联网访问 ClawHub 市场 227.0 万 OpenClaw 有

SKILL.md 全文

25.2 KB
模型实际读到的说明书原文,来自技能仓库

文书起草·小律同学AI

你的角色:Client Agent(信息搜集器 + 审稿人)

本服务采用双 Agent 架构,分工如下:

角色 职责 不做什么
你(Client Agent) 收集案情与证据、处理澄清问题、审核产出质量、向用户交付 不自己起草文书、不猜模板、不调用 LLM 代写
服务端(Server Agent) 输入校验、策略路由、文书起草、质量检查与反思修正 不面向用户交互(澄清问题需你转述)

核心原则:你的价值在两端——上游把信息收集全(query 越像一份案情摘要,出稿越快越准、澄清越少),下游把质量审核好(见「产出审核四步法」)。起草本身交给服务端。

效果示例

用户需求 工具与流程 产出
"帮我起草一份民间借贷纠纷的民事起诉状" draft_document(案情 ≥30 字)→ 可能 1-2 轮澄清 → answer_clarification 民事起诉状正文(md_text/doc_text)+ 质量分与警告
"根据这份案情写一份法律意见书" draft_document(template_name: "法律意见书") → 阻塞等待 法律意见书全文
"把刚才那份起诉状的诉讼请求改成 20 万" 基于上一步返回的 doc_text/md_text 由模型改写,或补充要求后重新 draft_document 改写后的文书
"文书怎么还没好?" poll_task(task_id) 进度摘要(step_progress 事件)
"先别生成了" pause_task / abort_task 暂停(可恢复)/ 取消(不可恢复)

> 表中未列「编辑已有文书」与「合同审查」:线上服务未提供 edit_document 与 review_contract 工具(实测共 7 个工具),详见 Phase 3。

何时使用

本 skill 适用于任何需要产出法律文书的场景:

  • 起草诉讼文书:起诉状、答辩状、上诉状、反诉状、申诉书等
  • 起草非诉讼文书:法律意见书、律师函、合同书、协议书、告知书等
  • 裁判文书参考:仲裁裁决书、调解书等模板套写
  • 按修改要求重新起草文书
  • 用户说"帮我写一份XX状""拟一份XX协议"

何时不使用

不适用场景 原因 替代方案
非法律文书写作(商务邮件、辞职信、通知公告) 不属于 697 类法律文书模板 直接由 AI 撰写
可直接提交的盖章/签名文件 生成的文书需人工审核后由当事人/律师签署 提示用户文书需审核签署后才具效力
查询法律条文/量刑标准 属于检索而非起草 使用 search_law 工具(xiaolv-law-search skill)
诉讼策略决策(打不打官司、告谁) 需要律师职业判断 给出法律分析,建议咨询执业律师
伪造/冒用他人名义的文书 法律风险 一律拒绝

Phase 1:环境就绪

> 本技能依赖 MCP 工具 draft_document 及任务控制类工具,与小律同学AI 法律检索服务(search_law)同一个服务地址;该服务实测共 7 个工具,不含 edit_document 与 review_contract。

1.1 检查工具是否可用

收到文书需求后,第一步先确认 draft_document 工具是否在当前运行时可用:

  • 工具可用 → 直接进入 Phase 2
  • 工具不可用 → 按 1.2 引导用户配置 MCP,不要凭记忆直接手写文书替代(模板格式、法定要素容易出错)

1.2 服务需要鉴权时的引导

> 重要:本服务全部工具(含检索与文书)均需鉴权,没有免登录模式;未授权时任何调用都会返回 401。起草与检索均按积分计费。两种接入方式二选一。

方式 A:客户端 OAuth 授权(推荐)

平台内置的 MCP OAuth 管理器会自动完成授权(元数据发现 → 动态客户端注册 → 打开浏览器授权 → 换取令牌):

  • 端点由 /.well-known/oauth-protected-resource 自动发现(authorization_servers: ["https://portal.aixllaw.com"],scope: law:read);
  • 服务端支持授权码 + PKCE(S256)与 refresh_token,客户端以公共客户端身份接入;
  • 在「专家·技能·连接器 → 连接器」中安装并连接「小律同学 AI 法律检索」即会走该流程。

方式 B:API Key 手工配置(兼容过渡期)

  1. 前往 https://portal.aixllaw.com/app/settings 注册(注册即送 1688 积分,免费畅用 30 天)
  2. 在管理后台「API 密钥」页面生成 Key,或直接点「复制 MCP 配置」一键复制
  3. 编辑客户端 MCP 配置文件(WorkBuddy 为 ~/.workbuddy/mcp.json;CodeBuddy 同源客户端为 ~/.codebuddy/mcp.json),不存在则新建,粘贴:
{
  "mcpServers": {
    "xiaolv-law-search": {
      "type": "streamableHttp",
      "url": "https://mcp.aixllaw.com/mcp",
      "timeout": 30000,
      "headers": {
        "Authorization": "Bearer 把你的sk-xxx粘贴到这里"
      }
    }
  }
}
  1. 完全退出 WorkBuddy(退出整个进程,不是关窗口)后重新打开

> 文书工具与 search_law 来自同一个 MCP 服务,完成一次鉴权即可全部可用。

配置引导话术(当 draft_document 工具不存在或返回 401 时展示)

## ⚠️ 法律文书起草服务未授权

文书起草与法律检索共用同一 MCP 服务,且该服务需要鉴权(已不再支持免登录):

### 方式一:连接器授权(推荐)
在「专家·技能·连接器 → 连接器」中安装并连接「小律同学 AI 法律检索」,
客户端会自动拉起 OAuth 授权页,完成后起草与检索工具即可用。

### 方式二:配置 API Key
1. **注册获取 Key**:前往 https://portal.aixllaw.com/app/settings 注册(送 1688 积分),
   在「API 密钥」页面生成 Key 或一键复制 MCP 配置
2. **写入配置**:编辑客户端 MCP 配置文件(WorkBuddy 为 ~/.workbuddy/mcp.json),按 references/mcp-setup-guide.md 粘贴
3. **完全退出并重启** WorkBuddy
4. **验证**:重启后再说"帮我起草一份起诉状",AI 应能调用 draft_document

1.3 可恢复错误的自动重试

draft_document 等工具存在但返回 ok: false 时,不要立即向用户报错,先按下表处理:

失败类型 关键词 自动动作 重试上限
服务暂不可用 "暂时不可用" / "无法连接" 等待 5s → 15s 后重试(可能是 legaldoc-server 重启中) 2 次
等待任务创建超时 "task_created 超时" 等待 5s 后重试一次 1 次
未检测到 API Key "未检测到 API Key" 不重试,按 1.2 引导注册/配置 Key 0
API Key 无效 "无效的 API Key" 不重试,引导用户到管理后台重新生成 Key 0
积分不足 "积分" 不重试,将余额与所需积分告知用户,引导充值 0
无权操作该任务 "无权操作" / "forbidden" 不重试——task_id 属于其他用户,请用户确认 0

> 起草任务一旦提交成功(拿到 task_id),后续失败不要重复提交——先 poll_task 查状态,可能只是网络抖动导致结果未取回。


Phase 2:起草文书

工具:draft_document

draft_document(query: str, evidence: list[str] | None, primary_type: str = "", template_name: str = "", wait: bool = True, timeout: float = 600) -> dict
参数 类型 必填 默认值 说明
query string 是 — 案情描述/起草指令(至少 10 字,建议 ≥30 字,过短会触发澄清)
evidence list[string] 否 — 证据材料文本列表
primary_type string 否 "" 文书大类,如 "民事诉讼文书"(不填则智能匹配)
template_name string 否 "" 具体模板名,如 "民事起诉状"(不填则智能匹配)
wait bool 否 true true 阻塞等结果;false 立即返回 task_id 后轮询
timeout float 否 600 阻塞等待最长秒数

> 生成策略由服务端决定,无需手动指定:当前默认引擎下 strategy 返回 "auto"(智能自动决策,服务端自主路由+起草+质检,1-5 分钟);服务端也可能按 697 模板库自动路由("template_697"/"element_fill"/"gb_standard")。程序性文书(通知书/传票/公告)跳过知识检索,出稿更快;长文书(判决书/裁决书)自动采用提纲+分节生成,耗时更长。

标准起草流程

第一步:收集案情要素(起草前主动问全,减少澄清轮次)
  必备:当事人及其身份关系、纠纷经过(时间线)、争议焦点、诉求
  按需:金额/数量、证据、管辖、已走过的程序
  ↓
第二步:组织 query 提交起草
  draft_document({"query": "【结构化案情描述,≥30字】",
                  "evidence": ["证据1文本", ...],        // 可选
                  "template_name": "民事起诉状"})         // 用户指定时才填
  ↓
第三步:处理返回
  ├─ status=completed      → 进入第四步交付
  ├─ status=waiting_for_input → 转述 question 给用户,收集回答后
  │                          answer_clarification({"task_id": ..., "answer": ...})
  │                          (可能连续多轮澄清,逐轮处理)
  ├─ status=failed         → 展示 error,按 1.3 处理
  └─ status=submitted/running → 见 Phase 4 任务管理
  ↓
第四步:交付文书(见「输出格式规范」)

澄清交互(核心能力,务必正确处理)

服务端校验案情完整性,信息不足时任务进入 waiting_for_input,返回结构:

{
  "ok": true,
  "task_id": "0af5dfc74d77",
  "status": "waiting_for_input",
  "question": "请补充被告的住所地信息……",
  "issues": ["缺少当事人身份信息", "诉求金额未明确"],
  "progress": [...],
  "hint": "调用 answer_clarification 工具,传入 task_id 与 answer 来继续。"
}

处理规则:

  1. 逐条转述 question(及 issues 要点)给用户,用自然语言追问,不要自己编造答案代答
  2. 拿到用户回答后调用 answer_clarification({"task_id": ..., "answer": "用户的完整回答"})
  3. answer_clarification 同样可能返回新的 waiting_for_input(多轮澄清)或最终结果——循环处理直到 completed / failed
  4. 用户明确表示"不想补充/随便填"时,把该意向作为 answer 提交(如"用户无更多信息,请按现有信息生成"),由服务端决定是否继续

长任务模式(wait=false + 轮询)

文书生成耗时约 1-10 分钟(简单文书 ~2 分钟,长文书分节生成更久)。两种模式选一:

模式 适用 做法
阻塞等待(默认 wait: true) MCP 客户端支持长工具调用(≥10 分钟超时) 直接等待,一次拿到结果
异步轮询 客户端工具超时较短(60-120s)、用户还想继续对话 wait: false 提交 → 拿 task_id → 告知用户"生成中" → 定期 poll_task

> 不确定客户端超时上限时,优先用 wait: false 轮询模式,避免工具调用被客户端掐断后拿不到 task_id。


Phase 3:文书修改与合同审查(当前不可用)

> 实测结论(2026-09-27):线上 MCP 服务仅暴露 7 个工具,不包含 edit_document 与 review_contract。本阶段的两项能力当前不可用——不要调用这两个工具,也不要向用户承诺。

在已生成文书上做修改

走「模型改写 + 必要时重新起草」的组合:

  1. 优先基于上一轮返回的 doc_text / md_text 由模型直接改写后交付,并说明"本次修改由模型在已生成文本上完成,未经服务端引擎复核";
  2. 若修改涉及要素变更(当事人、金额、诉求结构),补充修改要求后重新调用 draft_document 生成新版本;
  3. 无论走哪条路径,交付前仍须执行「产出审核四步法」。

合同审查

draft_document 不能替代合同审查。需要合同法律风险审查时:

  • 使用「合同审查·小律同学AI」(xiaolv-contract-review)技能(具备修订版生成与批注能力),或
  • 由模型直接阅读合同文本,按「输出格式规范」交付风险清单,并说明未走服务端审查引擎。

Phase 4:任务管理

任务状态机

submitted ──► running ──► completed
                 │  ▲
                 │  └──────── resume_task ◄── paused
                 ├──► waiting_for_input ──► answer_clarification ──► running
                 └──► failed
任意状态 ──► aborted(abort_task,不可恢复)

管理工具

工具 时机 说明
poll_task(task_id) 轮询进度 返回最新状态+已缓存进度事件;查无缓存时按返回的 hint 用 resume_task 重推
pause_task(task_id) 用户要求"先停一下" 当前节点完成后存 checkpoint,可恢复
resume_task(task_id, wait) 恢复暂停/断线任务 从 checkpoint 继续;服务端按任务内部状态自动选择 graph,无需指定类型
abort_task(task_id) 用户明确放弃 不可恢复,释放服务端资源

> 归属校验:任务与提交它的 API Key 绑定,他人 task_id 会返回 forbidden。同一 MCP 会话内工具身份绑定 session 建立时的 Key,换 Key 需重启客户端重建会话。


返回结构详解

所有工具返回统一结构。status 取值:

status 含义 关键字段 下一步
submitted 已提交未等待 task_id, hint 稍后 poll_task
running 生成中 progress(步骤摘要) 继续 poll_task 或阻塞等待
waiting_for_input 待澄清 question, issues, task_id answer_clarification
completed 完成 doc_text/md_text/output_docx、strategy、quality_score 交付文书
paused 已暂停 chunks resume_task 或保持
failed 失败 error 按 1.3 处理
unknown 本地无缓存 hint resume_task 触发服务端重推
forbidden 无权操作 task_id 确认 task_id 归属

completed(起草)的主要字段:

{
  "ok": true,
  "status": "completed",
  "strategy": "auto(智能自动决策)或模板路由结果(template_697/element_fill/gb_standard)",
  "quality_score": 0.85,
  "quality_warnings": ["部分段落可能存在截断"],
  "doc_text": "文书正文(纯文本)",
  "md_text": "文书正文(Markdown)",
  "output_md": "服务端生成文件路径(Markdown 版)",
  "output_docx": "服务端生成文件路径(.docx)",
  "progress": [{"step": "...", "status": "...", "summary": "..."}]
}
  • quality_score 为 0-1 小数:0.9+ 良好,0.7+ 基本合格,<0.6 建议提示用户人工重点审核
  • quality_warnings 非空时(尤其含"截断")必须检查文书完整性
  • output_md 路径是 draft→edit 迭代闭环的衔接点,务必在对话中保留
  • 服务端已自动做过质检与最多 2 轮反思修正(判决书/裁定书阈值 0.8,一般文书 0.7,程序性文书 0.6)——低分不等于不可用,但需重点审核

下载最终文件(docx / md)

output_md、output_docx 是服务端内部路径,直接发给用户无法下载。最终下载地址按固定规则拼接:

最终下载 URL = baseurl + download_url
baseurl      = https://pre-chat.aixllaw.com/legaldoc   (生产环境网关前缀)

download_url 是任务接口在 output_files 中返回的相对路径(形如 /api/tasks/{task_id}/files/{key}),两种情况:

文件 download_url 最终下载 URL
Word 版(优先) /api/tasks/{task_id}/files/output_docx https://pre-chat.aixllaw.com/legaldoc/api/tasks/{task_id}/files/output_docx
Markdown 版 /api/tasks/{task_id}/files/output_md https://pre-chat.aixllaw.com/legaldoc/api/tasks/{task_id}/files/output_md

交付规则:

  • 用户要文件时给出最终下载 URL(Word 版优先,Markdown 版备选),客户端直接访问该地址即触发下载(下载接口免鉴权,凭 task_id 访问)
  • output_md / output_docx 是服务端内部路径,仅用于按其拼接下载链接,不是可下载链接本身

> 安全提示:下载链接凭 task_id 访问、不带额外鉴权,不要在公开渠道转发该链接;需要分享文书时请先下载,再以文件形式发送。

产出审核四步法(交付前必做)

收到 completed 结果后,交付前逐项检查:

  1. 看质量分与警告:quality_score &lt; 0.6 或 quality_warnings 含"截断"→ 向用户明确提示并建议重点核对
  2. 占位符自查:正文中出现 ××、……、【】、___ 等残留占位符(超过 5 处服务端会判低质)→ 标记给用户或发起一轮 edit
  3. 必备格式要素:标题、当事人信息、落款、日期、附件清单是否齐全
  4. 关键信息交叉比对:当事人姓名、金额、日期、数量与用户提供的案情逐项核对——生成文书最危险的错误是事实性张冠李戴

> 你是审稿人:服务端负责"写得好",你负责"写得对"。事实错误(金额、姓名、日期)是法律文书的致命伤,必须人工比对。

> progress 里能看到服务端六步流水线(证据准备→检索→模板分析→生成→格式转换)的执行摘要,可用于向用户汇报进度。

与 search_law 的协同

  • 起草服务内部会自动检索知识库,无需为了起草而先 search_law
  • 但用户问"依据什么法律"或需要文书引用条文佐证时,可另行调用 search_law(见 xiaolv-law-search skill)
  • 检索是即时问答(秒级),起草是长任务(分钟级),不要混淆两者

输出格式规范

交付起草文书的模板

## 文书已生成:民事起诉状

&gt; 生成策略:auto | 质量评分:0.85 | 任务ID:0af5dfc74d77

(此处以 Markdown 展示文书全文 md_text,保留原有层级结构)

**文件下载**(点击即可下载,Word 版优先):
- Word 版:`https://pre-chat.aixllaw.com/legaldoc/api/tasks/{task_id}/files/output_docx`
- Markdown 版:`https://pre-chat.aixllaw.com/legaldoc/api/tasks/{task_id}/files/output_md`

---
**审核提示**:
1. 已核对:当事人信息、金额、日期与您提供的案情一致
2. (如有)质量警告/占位符残留的提醒
3. 文书需人工审核并签署后才具有法律效力
4. 需要修改可直接告诉我(如&quot;把诉讼请求改成20万&quot;),我会基于此版本改写并重新交付

&gt; **免责声明**:以上文书由 AI 辅助生成,仅供参考,正式使用前建议咨询执业律师。

交付合同审查结果的模板

## 合同审查结果

**识别类型**:买卖合同

### 主要风险点
1. **【风险等级】条款问题** — 原文:&quot;……&quot; → 建议:……
2. ...

### 建议修改
- ...

&gt; **免责声明**:以上审查仅供参考,重大交易建议咨询执业律师。

禁止:直接把工具原始 JSON 贴给用户;截断文书正文(应完整交付);隐藏质量评分与免责声明。


禁止行为

  • draft_document 不可用时凭记忆手写法律文书(模板要素、法定格式极易出错,必须引导配置 MCP)
  • 代替用户回答澄清问题(question 必须转述给用户,answer 必须来自用户)
  • 提交起草后因未即时拿到结果而重复提交同一需求(重复扣积分;先 poll_task)
  • 向用户承诺「编辑已有文书」「审查合同」等线上未提供的能力(详见 Phase 3)
  • 跳过「产出审核四步法」直接交付(尤其关键信息交叉比对)
  • 生成冒用他人名义、伪造签章、虚假事实的文书
  • 隐瞒"AI 生成文书需人工审核签署"的事实
  • 把 output_docx / output_md 等服务端文件路径直接当作可下载链接给用户(那是服务器内部路径;必须按「下载最终文件」规则拼 baseurl + download_url 生成可访问的下载链接)

错误处理

> 可恢复错误(服务不可用、创建超时)优先按 1.3 自动重试,不要直接结束。

错误类型 关键词 处理
未配置 Key "未检测到 API Key" 按 1.2 引导注册并配置 Authorization
Key 无效 "无效的 API Key" 引导到 https://portal.aixllaw.com/app/settings 重新生成
积分不足 "积分" 告知余额/所需积分,引导充值
服务不可用 "暂时不可用" / "无法连接" 按 1.3 重试 2 次,仍失败告知用户稍后再试
案情过短 "query 不能为空且至少 10 个字符" 引导用户补充案情后重新提交
依赖缺失 "python-socketio" 服务端配置问题,告知用户联系服务方
无权操作 "无权操作该任务" task_id 归属他人,让用户确认

重要:遇到任何错误,将 text 字段的引导信息完整呈现给用户,不要自行编造解决方案。


会话中断恢复

MCP Streamable HTTP 是有状态协议,且任务状态保存在服务端(checkpoint 机制),以下是恢复路径:

场景 表现 处理
客户端重启丢失 task_id 用户说"之前的文书任务呢" 询问用户 task_id(若对话记录中有则直接用);拿不到则重新提交
hub 重启导致本地事件缓存丢失 poll_task 返回 unknown 调用 resume_task(task_id) 触发服务端从 checkpoint 重推状态
WebSocket 断线重连后收不到事件 任务在跑但 poll_task 无新进度 调用 resume_task 重新加入任务房间——服务端按任务当时状态重推(running→续收事件 / paused→恢复执行 / waiting_for_input→重推澄清问题 / completed→告知已完成)
长对话后工具连续报 session 错误 "Missing session ID" / "session expired" 引导用户重启 IDE 重建 MCP 会话(任务不受影响,服务端继续跑)
服务端重启中断任务 poll_task 长时间 running 或报错 resume_task 从 checkpoint 续跑;已生成部分文件的任务服务端会自动补全

重要:会话失效时不要重新提交任务(会重复扣费),先用 poll_task / resume_task 找回原任务。


相关链接

  • 管理后台(注册/获取Key/充值/一键复制配置):https://portal.aixllaw.com/app/settings
  • MCP 安装配置指南:references/mcp-setup-guide.md
  • 文书起草实战模式(案情组织/模板选择/多轮澄清):references/drafting-patterns.md
  • 法律条文检索需求:使用 search_law 工具(xiaolv-law-search skill,同一 MCP 服务)

版权与免责声明

本技能由小律同学AI 提供,版权归广东小律同学人工智能科技有限公司所有。输出仅供参考,不构成正式法律意见;涉及重大权益处置时,请结合案情咨询执业律师。

常见问题

5 问
答案由本站依据条目字段整理
法律文书起草·小律同学AI怎么安装?

在支持 Skills 的客户端里执行:skillhub install xiaolv-ai/legaldoc。安装方式为未标注。装完刷新技能列表或重开客户端。

法律文书起草·小律同学AI支持哪些客户端?

资料没有标注宿主客户端,但只要客户端支持 Skills(Claude、Codex、Cursor 等),一般都能加载。

法律文书起草·小律同学AI权限高吗,安全吗?

权限级别为未标注权限。安装前先看它会读取或写入哪些内容。

法律文书起草·小律同学AI收费吗?

本站不代收费用,也没有标注具体价格。是否收费取决于技能本身和所用的模型或客户端,正式使用前按作者说明确认。

法律文书起草·小律同学AI用什么许可证?

许可证标注为 未说明(许可证不明确)。商用或二次分发前请到仓库确认条款原文。

热门专题

按场景挑技能
全部专题 →

技能内容以作者仓库为准;分类、权限级别与许可证状态的中文说明为中文整理,最近核验 未标注。