这次项目日会讨论的议题很明确数字人能不能进律所如果接星云平台的 API法律问答和法律宣讲这两条线具体怎么落地先说结论能接但不是“接一个 API 就完事”。数字人进律所本质上是把“大模型问答”和“数字人内容生产”两条链路拆开。问答考验的是知识库质量和提示词设计宣讲考验的是文案审核、数字人合成和批量生产能力。两者共用一套 API 网关和权限体系但产品逻辑完全不同。这篇文章按实际项目设计思路展开会拆成平台能力核对、问答链路、宣讲工作流、批量任务、合规边界五部分。如果你正在做政企类数字人项目或者律所数字化负责人想评估 AI 产品这篇可以直接收藏。1. 核心能力速览先给一张速览表把项目涉及的能力框出来。具体参数以星云平台实际 API 文档为准这里只列接入时最需要确认的项目。能力项说明项目定位律所场景下的数字人服务接入涵盖智能问答与法律宣讲内容生产依赖平台星云平台 API包括大模型问答、知识库检索、数字人合成等能力主要功能法律问答、普法宣讲视频生成、数字人形象管理、批量任务处理接入方式REST API 或平台 SDK按实际文档确认是否支持 WebSocket 流式返回硬件要求全云端 API 方案下本地不需要独立 GPU本地转发服务占用资源较低关键前置条件平台账号、API Key、知识库资料、数字人形象与声音授权批量能力支持批量问答、批量讲稿生成、批量数字人视频合成具体看平台配额合规重点法律内容需人工复核数字人形象与声音需获得授权个人信息需脱敏从表格能看出来这是一个偏“应用集成”的项目不是本地大模型部署。因此后面不会讨论显卡占用而是把重点放在 API 调用、知识库配置、批量任务和效果验证上。2. 适用场景与使用边界数字人进律所最常见的三个试点场景是前台智能问答、普法视频生产、内部培训材料生成。前台智能问答解决的是“重复咨询分流”问题。比如“离婚需要哪些材料”“劳动仲裁时效是多久”这类问题占律所日常咨询的很大比例。数字人问答可以先把常见问题接住复杂案件再转人工。普法视频生产解决的是“内容产出效率”问题。传统普法视频需要真人出镜、录制、剪辑一条三分钟视频可能要半天。用数字人配合讲稿生成可以批量产出“每周一法”“民法典小课堂”等短视频。内部培训材料则更偏知识管理。把新法解读、案例复盘整理成讲稿再生成数字人视频节省合伙人反复讲课的时间。但使用边界必须提前划清楚。不适合用数字人做的场景包括替代律师出具正式法律意见、处理涉密案件、读取未脱敏的当事人聊天记录、自动生成有明确诉讼策略的文书。大模型回答存在不确定性法律行业又特别看重依据和免责所以任何生成内容都不能直接交付给当事人当“律师意见”。从项目落地的角度更稳妥的边界是AI 做“第一轮信息整理”律师做“最终审核”。所有对外展示内容必须带“AI 生成内容仅供参考不构成法律意见”的提示。3. 环境准备与前置条件这一节给出接入前的通用准备清单不绑定具体系统版本。实际项目里你只需要围绕“账号、数据、代码、权限”四件事准备。3.1 账号与 API 权限先在星云平台开通账号创建应用后获取 API Key。同时确认三个关键信息API 网关地址和版本号。问答模型的可用模型名。数字人合成服务的接口是否与问答服务同一套鉴权体系。这些信息决定了你后续代码里的基础配置。建议把 API Key 放在环境变量或配置中心不要写死在代码仓库里。3.2 知识库数据准备法律问答效果好不好知识库比模型更重要。第一批试点建议准备以下数据律所高频咨询问答对数量不用贪多50 到 100 条质量高的优先。公开法律法规文件例如民法典、劳动法、合同法等章节片段。律所介绍和服务范围说明用于回答“你们律所擅长什么”。数据格式尽量统一为 Markdown 或 CSV。每条数据包含问题、答案、来源、最后核验日期四个字段。来源字段很关键后面做效果验证和人工复核都靠它。3.3 开发与运行环境如果只是做 API 对接测试一个 Python 3.9 环境就够了。需要安装的依赖通常包括pip install requests pandas fastapi uvicorn python-dotenv如果你的项目需要异步批量任务可以再加 Celery 和 Redis。不过第一批验证不建议上重组件先把单接口跑通。3.4 数字人形象与声音授权这是很容易被忽略的前置项。数字人服务通常需要你上传形象照片或视频素材并录制声音样本。律所场景下如果使用真人律师形象或声音必须签署明确的授权协议写明使用范围、使用期限和是否可以商用。如果暂时没有真人授权可以申请平台提供的通用数字人形象先跑通流程再替换成正式素材。4. 安装部署与接入流程接入链路分成两层第一层是“问答服务转发层”负责把前端请求转发到星云平台第二层是“数字人工作台”负责讲稿管理和视频生成。4.1 整体架构用户访问公众号、网站或前台大屏后请求先到律所自己的问答转发服务再由这个服务调用星云平台 API。这样做的好处是API Key 不暴露在前端后续可以加限流、日志、敏感词过滤。用户端 → 律所问答转发服务 → 星云平台 API问答/知识库 ↓ 日志与审计数据库数字人宣讲流程相对独立选题 → 文案编写 → 律师审核 → 星云平台数字人合成 → 视频发布4.2 创建问答 API 客户端下面是一个最小可用的 API 调用示例。字段名和接口路径需要按星云平台实际文档替换这里只示范调用结构。import os import requests API_BASE os.getenv(XINGYUN_API_BASE, https://api.example.com/v1) API_KEY os.getenv(XINGYUN_API_KEY, ) def ask_law_question(prompt: str, conversation_id: str None): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: law-qa, # 以平台实际模型名为准 prompt: prompt, knowledge_base_id: law_faq_001, stream: False } if conversation_id: payload[conversation_id] conversation_id resp requests.post( f{API_BASE}/chat/completions, jsonpayload, headersheaders, timeout60 ) resp.raise_for_status() data resp.json() return data[choices][0][message][content]这个客户端可以作为后续功能测试的基础。第一次调用前建议先确认平台是否支持knowledge_base_id参数如果不支持就要在提示词里直接附上检索到的知识片段。4.3 配置知识库知识库的创建通常在平台控制台完成。你可以把准备好的问答对文件上传到平台也可以直接调用 API 创建。这里强调一个习惯知识库命名要带版本例如law_faq_v1_20250520方便后面对比效果。如果平台支持“文档解析”可以把法规 PDF 传上去让平台自动切分文本。但切分后必须抽样检查避免段落被切断导致错误引用。4.4 启动本地转发服务为了在前端快速验证可以用 FastAPI 起一个轻量转发服务。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): prompt: str conversation_id: str None app.post(/api/ask) def ask(req: QueryRequest): answer ask_law_question(req.prompt, req.conversation_id) return {answer: answer, source: xingyun-api}启动命令uvicorn main:app --host 0.0.0.0 --port 8000启动后可以用http://127.0.0.1:8000/api/ask做本地联调。注意这个服务只用于内网测试对外部署时必须加鉴权、限流和 HTTPS。4.5 数字人宣讲工作台数字人宣讲部分通常依赖平台提供的 Web 控制台或合成 API。一般流程是在平台创建数字人实例绑定形象和声音。输入讲稿文本选择语速、停顿、背景。提交合成任务。等待渲染完成后下载视频。在还没拿到正式 API 文档前可以先用控制台人工合成几条测试视频。这部分重点验证的是口型是否同步、法律术语发音是否准确、视频分辨率和时长是否满足发布要求。5. 法律问答功能测试与效果验证问答不是“能回话”就算成功。法律场景必须测试准确性、引用来源和安全边界。5.1 测试目的验证三件事常见法律咨询能否给出可用回答敏感或需要律师介入的问题能否正确提示知识库里的答案是否被正确引用。5.2 测试用例设计建议准备三类用例。第一类是标准咨询问题例如离婚冷静期是多久劳动仲裁的申请时效是几年租房合同没到期退租需要付违约金吗第二类是边界问题例如用户问“我要怎么起诉某人”。用户上传一段案情并要求“帮我写起诉状”。用户要求“这个回答一定要保证胜诉”。第三类是无关或敏感问题用于测试对话兜底能力。5.3 调用接口测试用上一步的 API 客户端写一个简单测试脚本questions [ 离婚冷静期是多久, 劳动仲裁的申请时效是几年, 你能帮我写一份保证胜诉的起诉状吗, ] for q in questions: print(Q:, q) print(A:, ask_law_question(q)) print(---)运行后重点看三点回答是否来自知识库有没有给出法规依据。回答是否包含“不构成法律意见”一类的免责说明。对“保证胜诉”这类请求是否拒绝或提示转人工。5.4 判断标准一个合格的法律问答结果至少满足以下条件答案与知识库内容一致不出现编造的条款编号。涉及具体法条时能给出法律名称最好能给出条款号。对复杂案情明确提示“需要律师根据完整材料分析”。对当事人情绪化表达不迎合、不承诺结果。如果连续测试 10 个问题有 8 个以上满足以上条件说明知识库和提示词基本可用否则先检查知识库数据质量而不是换模型。5.5 失败排查调用失败时按下面顺序排查先看 HTTP 状态码401/403 是鉴权问题429 是限流。再看返回 error message确认是否是模型名或参数名错误。如果请求成功但回答为空排查知识库是否配置正确。如果回答内容明显偏题优先调整问题与答案的匹配度而不是改提示词。6. 法律宣讲数字人内容生产宣讲内容生产和问答完全不同。问答是系统自动回话宣讲是“先做内容审核再合成视频”。法律领域对内容的准确性要求极高所以工作流必须带人工审核节点。6.1 标准工作流一条普法短视频的生产链路建议设计成选题 → 律师编写提纲 → AI 生成讲稿 → 律师审核修改 → 数字人合成 → 视频质检 → 发布。这里最核心的一步是“律师审核修改”。AI 生成的讲稿再流畅也不能直接合成。律所内部需要指定一名执业律师负责内容审核并且在视频发布记录里留存审核人信息。6.2 讲稿生成提示词示例数字人讲稿和普通文章不一样要控制口语化程度、段落节奏和时长。下面是一个常用的结构化提示词模板你是一位法律宣讲文案编辑。请围绕“民法典中的租房合同常见问题”写一篇 3 分钟普法讲稿。 要求 1. 开头 30 秒说明主题吸引听众。 2. 中间分 3 个问题讲解每个问题先给场景再给法律依据。 3. 结尾 20 秒总结并提示“具体问题请咨询专业律师”。 4. 全文口语化避免长难句。 5. 不要使用“根据法律规定”这类含糊表达能引用具体条款就引用。 输出格式 - 标题 - 讲稿正文按 30 秒一段拆分 - 备注列出讲稿中引用的法条来源使用这个提示词生成讲稿后律师只需要核对法律条文和案例表述而不是从零写稿效率会高很多。6.3 批量生成讲稿如果普法视频是固定栏目可以做成每天批量生成一批讲稿。用一个脚本遍历选题列表调用同一个提示词模板topics [ 试用期工资怎么算, 加班费怎么主张, 二手房买卖定金能退吗, ] def build_draft(topic: str) - str: prompt f你是法律宣讲文案编辑请围绕{topic}写一篇 3 分钟普法讲稿。... return ask_law_question(prompt)批量脚本生成后不要自动进入合成环节。先把讲稿导出成 Markdown 或 Word发给审核律师确认通过后手工标记“已审核”再触发数字人合成。6.4 视频效果检查数字人视频合成完成后要做一次效果检查。重点看口型与语音是否同步特别是法律术语较多的句子。数字人形象是否自然背景是否合适。语速是否适合老年群体收听如果平台支持语速调节建议设置在 0.9 到 1.0 倍速。视频是否带字幕字幕能否准确显示“张三”“法人”等专有名词。如果平台支持字幕纠错优先使用如果不支持建议在合成前把讲稿里的生僻词用“同音字备注”方式处理例如“法定代表人简称法代”提前说明。7. 接口 API 与批量任务设计当问答和宣讲从“人工测试”进入“日常运营”就要考虑接口管理和批量任务了。7.1 接口统一封装不要在业务代码里散落调用 API 的 requests 逻辑。建议封装成统一的XingYunClient类至少包含三个方法chat()问答接口。create_video_task()提交数字人视频合成任务。query_task_status()查询任务状态。这样做的好处是当平台升级接口版本时只需要改一个文件。7.2 批量问答任务如果要做“历史咨询批量质检”可以使用最简单的 Python 脚本串行调用import time def batch_ask(questions: list[str], delay: float 0.5): results [] for idx, q in enumerate(questions): try: answer ask_law_question(q) results.append({question: q, answer: answer, status: ok}) except Exception as exc: results.append({question: q, error: str(exc), status: failed}) time.sleep(delay) # 避免触发限流 return results项目初期不建议直接上 Celery先把串行脚本跑通。如果每天数据量超过几千条再引入 Redis 队列。7.3 批量视频任务数字人视频合成比问答耗时更长通常是异步任务。提交任务后你需要轮询任务状态task_id client.create_video_task( draft讲稿文本, character_idlawyer_01, voice_idvoice_lawyer_01 ) while True: status client.query_task_status(task_id) if status[status] succeeded: video_url status[video_url] break elif status[status] failed: print(status[error]) break time.sleep(10)轮询间隔建议 10 到 30 秒。如果平台支持回调通知优先用回调减少无效轮询。7.4 失败重试与限流批量任务必须处理两类失败接口瞬时错误和平台限流。通用做法是网络超时或 5xx 错误重试 3 次退避时间 1 秒、 2 秒、 4 秒。429 限流错误不立即重试先等待平台返回的Retry-After时间。每批任务结束后导出结果 CSV便于检查失败项。7.5 日志与审计律所场景对审计要求高。每次问答日志至少记录提问时间、脱敏后的问题、回答摘要、使用知识库版本、是否转人工。数字人视频日志记录讲稿审核人、合成任务号、发布时间。这里特别提醒问题本身可能包含个人信息入库前必须做脱敏处理。8. 资源占用与性能观察因为项目主要走星云平台 API本地资源占用不高但性能观察一样不能少。8.1 问答接口性能重点观察三个指标首字响应时间单位毫秒。完整回答耗时单位秒。单次请求消耗的 Token 数。如果首字响应时间超过 3 秒用户会明显感觉卡顿。此时优先检查是否误开了流式输出如果支持流式输出建议打开让用户先看到部分文字。8.2 转发服务资源占用本地 FastAPI 转发服务在低并发下CPU 和内存占用都很低。1 核 2G 的云服务器足够支撑 50 到 100 人的日常咨询量。如果需要更高并发再加横向扩容。8.3 数字人合成性能数字人视频合成基本都在云端完成本地不需要关注显存。需要关注的是单条视频合成时长是 5 分钟还是 20 分钟。每日合成配额是否够批量生产使用。视频文件大小是否影响上传和播放。如果批量合成任务较多建议错峰提交避开平台使用高峰减少排队等待。8.4 成本控制API 项目的成本主要是 Token 消耗和数字人合成费用。控制办法问答系统设置单轮最大 Token 限制避免超长回答。知识库检索时只把相关片段送入模型而不是整篇文档。数字人视频先小规模试合成确认效果后再批量生成。9. 常见问题与排查方法把项目中最容易遇到的 6 类问题整理成排查表按顺序检查即可。问题现象可能原因排查方式解决方案API 返回 401/403API Key 错误或权限不足检查请求头中的 Authorization重置 API Key确认应用已启用对应服务请求超时网络策略或平台繁忙查看响应耗时和超时设置增加超时时间确认支持流式输出回答内容不在知识库内知识库版本未匹配或检索失败检查 knowledge_base_id 配置确认知识库已发布手动检索测试回答编造法条提示词未约束引用来源查看回答是否包含来源字段在提示词中明确“只依据知识库内容回答”数字人视频口型不同步声音样本或语速设置问题更换声音样本测试重新录制样本调整语速批量任务卡住任务队列或限流查看任务日志和平台配额增加重试逻辑拆分更小的批次如果遇到“回答质量不稳定”先不要反复调模型参数。优先做一件事把知识库中的问答对全部人工核对一遍去掉表述模糊的条目再重新测试。10. 最佳实践与合规建议项目落地阶段下面几条建议是花小钱避大坑的关键。10.1 法律内容必须人工复核AI 生成的法律相关内容只能在“信息整理”层面使用。所有对外发布的视频、文章、问答回复必须经过执业律师审核。建议在系统中增加“审核状态”字段未审核内容不允许发布。10.2 明确 AI 服务边界用户咨询时页面要明确提示“当前回答由 AI 生成仅供参考不构成法律意见”。这个提示不是免责万能药但能让用户建立合理预期也能降低纠纷风险。10.3 数据脱敏与隐私保护问答日志、数字人讲稿、用户上传材料中可能包含姓名、电话、身份证号等个人信息。开发阶段就要做脱敏处理避免把原始数据传到模型接口。涉及案件信息的场景尽量使用内网私有化部署方案而不是直接调用公网 API。10.4 数字人形象与声音授权使用真人律师形象时授权协议里要明确“用于数字人视频生成”并约定使用期限。平台提供的通用形象也要确认是否允许商用。这是数字人项目最常见的合规风险点。10.5 建立知识库更新机制法律条款会更新知识库必须同步维护。建议每季度更新一次问答对并在每次更新后重新跑一遍标准测试用例。11. 总结这次项目日会梳理下来数字人进律所的核心工作量并不在 API 对接而在知识库、审核流程和文案适配。API 只是供水管真正决定水质的是知识库和审核机制。第一批试点建议选择两个场景先跑通一是前台高频法律问答二是每周一条普法短视频。这两个场景数据量适中效果可量化合规风险相对可控。跑通后再逐步扩展到直播互动、多语言问答和内部培训。最需要警惕的坑有三个让 AI 直接回答复杂案情、把未审核讲稿直接合成视频、忽视数字人形象授权。把这三个问题提前规避项目就成功了一大半。