一起劳动争议案件的当事人最需要的往往不是“AI 已经给你判了”的结论而是先有人告诉他关于这件事法律是怎么规定的可以主张哪些权利举证要准备什么材料。过去这件事只能依靠律师或法律援助机构背后是昂贵的咨询成本和漫长的排队时间。现在很多法律平台已经接上了大模型“AI 帮助普通人获得法律服务”看起来不再遥远。但问题是AI 真的改善了正义的可及性吗还是只让一堆看起来很像样的答案变得更流畅、更自信我的判断是AI 确实显著降低了法律服务的信息获取成本尤其是在法律检索、文书起草、术语解释、多语言翻译等环节但它并不能自动实现“正义可及性”。这个词的完整含义不只是“让用户问到一个答案”还包括答案是否可靠、引用是否准确、责任谁来承担、不会用手机的人能不能触达、资金不足的法律援助机构是否真的部署得起。换句话说AI 改善的是效率不等于改善结果公平。本文会用工程视角拆解这个问题。先说明“正义可及性”在技术语境下究竟卡在哪里再给出法律 AI 助手的一套最小可运行系统设计包括知识库建设、检索增强生成、提示词约束、输出校验和效果评测。你不需要有法学背景只要熟悉 Python 和大模型 API就能自己跑通一个法律问答原型。读完你会明白为什么说 AI 法律应用真正的分水岭不是模型能力而是数据工程、评测机制和人机协同流程。1. 这篇文章真正要解决的问题法律科技并不是新话题。过去十几年各个机构和企业一直在做“法律信息化”裁判文书上网、电子诉讼平台、线上立案、智能柜员机这些系统解决的是流程数字化。流程数字化确实降低了进入法律程序的操作门槛但它没有解决一个更前置的问题用户根本不知道自己的问题属于哪种法律关系应该适用哪部法规甚至不知道自己“有权利可主张”。大模型的出现改变的是这个前置环节。用户可以直接用自然语言提问“公司没签劳动合同我主动离职还能要双倍工资吗”这种问题不再需要用户预先掌握法律术语。单从交互体验来说AI 法律助手比传统检索系统友好得多。但这里有一个很大的坑法律回答和普通知识问答不一样错误答案的代价不是“少学一个知识点”而是用户可能据此放弃维权、错过时效、提交错误材料。因此一个可用的法律 AI 系统必须同时满足三个条件回答有依据必须能定位到具体法条、规定或案例知识边界清晰不知道就是不知道不能编造有完整的使用链路设计人工复核、免责声明、隐私保护都要跟上。所以本文不是要否定 AI 的正向价值而是想说明白AI 想要真正改善法律服务的可及性开发者必须从“模型能聊天”走向“系统能负责”。最适合读这篇文章的读者有两类。第一类是正在做或打算做法律科技产品的工程师你需要一套能落地的架构思路和原型代码第二类是做 AI 应用落地的技术人员虽然不做法律方向但可以借鉴如何用检索增强、提示词约束和评测机制解决“大模型一本正经胡说八道”的通病。2. “正义可及性”到底卡在哪里“Access to Justice”在国内法律界常被译作“接近正义”日常讨论中也叫“正义可及性”或“司法便利”。它不是一个抽象口号而是可以拆解的工程问题。一个普通人要解决法律纠纷大致要走完这样一条链路意识到自己遇到了法律问题 → 判断问题类型 → 找到法律依据 → 准备证据和文书 → 进入调解、仲裁或诉讼程序 → 获得结果并执行。传统法律服务体系在这条链路上存在很多断点。第一个断点是信息成本。法律条文本身是公开的但普通人很难读懂条文之间的适用关系。比如劳动合同法里的“经济补偿”和“赔偿金”只差一个字适用条件完全不同非专业人士很容易混淆。第二个断点是语言壁垒。法规语言高度抽象民间表达又充满口语和隐含情境两边存在翻译成本。第三个断点是地域和资源不均衡。发达地区的法律服务资源相对充足偏远地区的用户可能连“去法律援助中心问一下”都未必方便。第四个断点是时间成本即使找到律师一次咨询的完整流程往往需要数天甚至数周。以往的信息化手段主要解决的是“程序入口”问题比如把线下立案搬到线上。可用户走到立案这一步之前已经需要大量前置知识。大模型和自然语言处理技术第一次让机器能够在“用户还没想清楚自己属于哪类纠纷”的时候就通过与他的对话逐步澄清问题、给出初步指引。这是 AI 在法律服务领域最核心的价值点它把断点向前挪到了“用户最早产生困惑”的那个时刻。但注意技术只能解决“信息供给”问题。用户获得了信息之后是否有能力执行材料怎么填写证据链是否完整这些依然依靠后续的服务体系。如果我们把一个法律 AI 问答产品当成“正义可及性”的全部那只会让那些最不会使用数字工具的人被排除在另一个入口之外。3. 法律场景下的 AI 能力地图要判断 AI 能在多大程度上改善法律服务先要看清楚 AI 在具体法律任务上的真实能力边界。把任务分类之后结论会更冷静。任务类型传统方式AI 辅助方式当前成熟度法律检索关键词查数据库需要用户先懂术语自然语言语义检索支持“我离职后公司不给工资怎么办”这类提问较成熟工程上可落地合同审查律师逐条人工阅读OCR 文档解析 条款风险识别中高但必须人工复核法律文书生成从模板复制粘贴修改用结构化问答生成申请书、起诉状初稿中等格式化文书效果较好法律知识问答人工客服或电话咨询RAG 增强的大模型问答可引用来源中等强依赖知识库质量裁判结果预测完全依赖律师经验判断裁判文书 统计模型给出倾向性分析早期不能作为正式参考多语言与口语化翻译专业翻译成本高机器翻译 法律术语库中高复杂条款仍需校对法律援助分流人工记录、转接意图识别 知识库引导 人工兜底生产可用这张表有一个值得注意的规律越靠近“信息整理”的任务AI 越可靠越靠近“价值判断和最终裁定”的任务AI 越不可靠。法律检索做错了检索系统多返回几条内容问题不大但裁判预测若是错了用户可能基于错误的预期做出非常错误的决策。所以给法律 AI 做能力定位时我更推荐“助手”而不是“裁判”的角色。从技术实现角度看法律场景里的 AI 并不只有大模型一种组件。一个完整的法律智能系统通常由五层组成数据层法规库、裁判文书库、合同模板库、实务问答库处理层PDF/图片转文字、文档切分、条款结构化、命名体识别知识层向量索引、法律知识图谱、法条关联关系应用层问答助手、文书生成、合同审查、风险预警控制层来源引用、权限管理、人工复核、操作审计。很多人以为做一个“法律 AI”就是调大模型的 API这是最危险的误解。大模型只是应用层的一个生成引擎它能不能回答得靠谱完全取决于前面几层有没有做好。4. 核心架构法律问答助手的设计思路下面用一个最常见的“法律 AI 助手”作为例子讲清楚整体架构。这个助手要解决的核心场景是用户用大白话提问系统返回有依据、可读、能进一步操作的初步法律指引。系统的整体流程可以拆成六个环节用户输入问题系统做基础预处理包括去敏感信息、判断问题与法律领域的相关性在法规和实务知识库中做语义检索召回最相关的若干片段把用户问题和召回片段一起交给大模型要求只能依据材料回答对回答做格式校验和引用完整性检查输出给用户同时保留完整日志供人工复核和后续评测。第 3 步和第 4 步合起来就是现在最常用的 RAG检索增强生成。RAG 之所以重要是因为大模型无法记住不断变化的法律法规也不适合靠参数记忆来输出需要精确到条款号的内容。RAG 的思路是不强迫模型“背法条”而是先从知识库里把相关法条找出来放到提示词里让模型基于给定的材料作答。在法律场景知识库的组织方式比模型选择更关键。法规库不能简单地把整部法律塞成一个大文档。更好的做法是做到“结构化入库”按编、章、条拆分保存条款号、效力级别、施行日期、最近修改日期等元数据。这样检索时既可以做语义召回也能用条款号做精确过滤。比如用户问“试用期辞退”系统可以先定位到劳动合同法相关条款再根据“是否在试用期内”细分。原型项目需要控制规模但目录结构应当向生产级架构看齐。我把 Demo 设计成下面这样legal-ai-demo/ ├── data/ # 存放法律知识文档支持 txt/md ├── ingest.py # 文本清洗、切分、向量化、入库 ├── query.py # 检索 生成回答 ├── requirements.txt # Python 依赖 └── README.md这个小项目没有引入重型向量数据库而是用本地文件加余弦相似度实现最小检索链路。这样做的目的是先跑通逻辑。真实项目可以把向量部分替换为 Milvus、Elasticsearch 或云上向量检索服务架构不会变只是工程能力扩展。5. 从零搭一个最小可用的法律 AI 助手现在进入实操环节。我的目标不是做一个能直接商用的产品而是用尽量少的代码跑通“法律知识入库 → 语义检索 → 大模型约束生成 → 来源展示”的完整链路。5.1 环境准备建议使用 Python 3.10 及以上版本。需要安装的依赖如下# requirements.txt numpy1.24 openai1.0这里使用 OpenAI 兼容的客户端接口。你可以把OPENAI_BASE_URL指向任意兼容服务包括云服务商提供的合规模型接口也可以指向你自己部署的本地网关。嵌入模型和对话模型都通过环境变量配置方便替换。export OPENAI_API_KEYyour_api_key export OPENAI_BASE_URLhttps://your-compatible-endpoint/v1 export EMBEDDING_MODELtext-embedding-3-small export LLM_MODELgpt-4o-mini如果你用的是本地模型服务没有真实密钥也可以设置一个占位值比如EMPTY。关键是保证接口协议兼容。5.2 法律知识库文本入库法律文本和普通文章不一样它常常有清晰的条、款、项结构。但为了演示通用思路我们先用一个简单的切分函数优先按段落切分遇到超长段落再按句号做二次切分。实际项目中强烈建议根据具体法规的条文章节做结构化切分而不是依赖通用切分。代码放在ingest.py中# ingest.py import json import uuid from pathlib import Path from openai import OpenAI DATA_DIR Path(./data) INDEX_DIR Path(./index) client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text-embedding-3-small) def embed_texts(texts: list[str]) - list[list[float]]: 批量向量化。OpenAI 兼容接口一次调用即可。 resp client.embeddings.create(modelEMBEDDING_MODEL, inputtexts) return [item.embedding for item in resp.data] def chunk_document(content: str, max_len: int 300) - list[str]: 把整篇法律文本切成适合检索的片段。 优先保留段落结构超长段落按句号切分。生产环境应改为按条切分。 units [] content content.replace(\r, ).strip() for para in content.split(\n\n): para para.strip() if not para: continue while len(para) max_len: cut para.rfind(。, 0, max_len) if cut -1: cut max_len units.append(para[: cut 1].strip()) para para[cut 1:].strip() if para: units.append(para) return units def build_index() - None: rows [] for path in DATA_DIR.iterdir(): if path.suffix.lower() not in {.txt, .md}: continue text path.read_text(encodingutf-8) chunks chunk_document(text) for idx, content in enumerate(chunks): rows.append({ id: str(uuid.uuid4()), source: path.name, chunk_id: idx, content: content, }) if not rows: print(没有在 data 目录下找到 txt/md 文档) return texts [r[content] for r in rows] embeddings embed_texts(texts) INDEX_DIR.mkdir(exist_okTrue) with open(INDEX_DIR / chunks.json, w, encodingutf-8) as f: json.dump(rows, f, ensure_asciiFalse, indent2) import numpy as np matrix np.array(embeddings, dtypefloat32) np.save(INDEX_DIR / embeddings.npy, matrix) print(f入库完成共 {len(rows)} 个知识片段) if __name__ __main__: build_index()这段代码把data/目录下的每篇法律文档切分成多个片段为每个片段生成向量然后把片段元数据保存为 JSON向量矩阵保存为 npy 文件。所谓“入库”本质就是把纯文本变成可检索的向量索引。切分参数max_len300只是一个示例值。法律条文的颗粒度差异很大有的条很短有的条包含多款。所以生产项目里更合理的做法是先按“第X条”的正则表达式切出条文再把包含多款的条文按“第X款”二次切分。5.3 语义检索与回答生成接下来写query.py。它负责加载索引、计算用户问题的向量、用余弦相似度召回 TopK 片段然后把召回内容拼进提示词让大模型生成回答。# query.py import json import os import numpy as np from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text-embedding-3-small) LLM_MODEL os.getenv(LLM_MODEL, gpt-4o-mini) INDEX_DIR ./index def load_index(): with open(f{INDEX_DIR}/chunks.json, encodingutf-8) as f: chunks json.load(f) matrix np.load(f{INDEX_DIR}/embeddings.npy) return chunks, matrix def search(question: str, top_k: int 5): chunks, matrix load_index() resp client.embeddings.create( modelEMBEDDING_MODEL, input[question] ) q_vec np.array(resp.data[0].embedding, dtypefloat32) # 归一化后做内积等价于余弦相似度 q_vec q_vec / np.linalg.norm(q_vec) matrix_norm matrix / np.linalg.norm(matrix, axis1, keepdimsTrue) scores matrix_norm q_vec top_indices np.argsort(scores)[::-1][:top_k] results [] for idx in top_indices: item chunks[idx] results.append({ content: item[content], source: item[source], chunk_id: item[chunk_id], score: float(scores[idx]), }) return results def build_prompt(question: str, contexts: list[dict]) - str: context_text \n\n.join( f[来源{item[source]} / 第{item[chunk_id]}段]\n{item[content]} for item in contexts ) prompt f你是一名严谨的法律信息助手。你的目标不是代替法官或律师作出决定而是帮助用户理解与问题相关的法律知识。 请遵守以下规则 1. 优先依据下方【参考资料】回答如果材料充分请结合材料分点解释。 2. 每一个关键结论后面用 [来源xxx / 第x段] 标注依据。 3. 如果参考资料不足以回答请直接说“当前知识库没有覆盖该问题建议咨询专业法律人士”。 4. 禁止编造法条、案例或文件名称。 5. 不要使用“根据法律规定”这种模糊表述除非你确实在资料中定位到了对应内容。 【用户问题】 {question} 【参考资料】 {context_text} return prompt def answer(question: str) - str: contexts search(question, top_k5) prompt build_prompt(question, contexts) resp client.chat.completions.create( modelLLM_MODEL, messages[{role: user, content: prompt}], temperature0.1, ) result resp.choices[0].message.content return result, contexts if __name__ __main__: q 试用期被公司辞退怎么办 result, contexts answer(q) print(回答) print(result) print(\n召回的知识片段) for c in contexts: print(f- {c[source]} / 第{c[chunk_id]}段 (score{c[score]:.4f}))这里有几个设计点值得展开。第一temperature设置为 0.1尽量降低模型输出的随机性。法律回答应该稳定不需要创意。第二提示词明确要求“禁止编造”和“标注依据来源”这是 RAG 应用里控制幻觉的第一道闸门。第三检索的 TopK 设置为 5实际项目中可以根据知识库质量和问题复杂度动态调整。如果召回太少模型容易没话说召回太多提示词会过长而且无关片段反而可能干扰生成。5.4 Prompt 模板法律场景的约束策略提示词设计在法律 AI 中很容易被低估。很多法律平台早期把通用对话提示词拿过来直接用结果模型动不动就给出“综合分析如下”的长篇大论看似严谨实际无法定位到具体条款。我在上面给出的提示词有几个明确设计意图角色定位为“法律信息助手”不是“法律专家顾问”避免模型进入过度自信的专家口吻明确要求依据材料回答不依据内部记忆自由发挥要求每个关键结论后标注来源便于用户核查允许回答“不知道”并且给出替代建议。这段 Prompt 的核心思想是“用约束换取可控性”。你不可能完全消除大模型的幻觉但你可以让它在犯错时更容易被发现。5.5 运行与验证先把准备好的法律文档放进data/目录。比如准备一份劳动合同法相关的公开文本命名为labor_law.txt。然后执行入库python ingest.py预期输出类似入库完成共 87 个知识片段如果提示没有文档先检查data/目录下是否有.txt或.md文件。接下来执行问答python query.py 试用期被公司辞退怎么办输出会分为三部分模型回答、召回片段列表、每个片段的相关性分数。判断系统是否正常工作的第一步不是看回答是否流畅而是看召回片段是否包含真正相关的条款。如果召回的内容本身就偏了后面的模型回答再通顺也没有意义。这里需要特别说明Demo 展示的是技术链路的可行性不是成熟的法律产品输出。无论这个回答写得多么合理都不应该直接当成正式法律意见使用。一个真实可用系统必须有“该回答仅供参考”的明确提示并把完整的原始召回片段同步展示给用户。6. 保证法律回答“不胡说”的工程手段大模型应用于法律领域最让人担心的不是能力不足而是“能力越强幻觉越难发现”。模型会用一种非常笃定的语气把不存在的规定讲得头头是道。所以法律 AI 系统的工程重心应该放在可信控制上。除了 Prompt 约束之外至少还有四道防线。第一道防线是召回质量。如果知识库本身没有相关条文模型再强也无法生成有根据的答案。召回质量取决于三件事知识库是否覆盖、切片是否合理、Embedding 模型是否适配法律术语。法律文本中有大量长句和特定术语通用切分经常把一个条文拦腰截断。更稳妥的做法是按“编-章-条-款”结构化组织然后对每个条款做 embedding。第二道防线是引用完整性校验。在 Prompt 里要求模型标注来源只是第一步。模型可能在正文里写了“根据相关规定”却没有标注具体来源。更严谨的做法是在返回给用户之前用规则或第二个模型检查回答中是否存在引用标记。如果某些关键结论缺少引用系统可以拒绝输出或要求重写。最简单的方式是检查回答文本中是否出现了召回片段里的文件名或来源前缀。第三道防线是置信度控制。检索阶段可以拿到相似度分数。用户的问题与知识库内容的相似度如果整体偏低比如最高分只有 0.3系统就不应该强行让模型回答。这时候更合适的做法是直接告诉用户“该问题超出当前知识库范围建议转人工咨询”。把“不知道”做成一种正常的系统行为而不是让模型硬答。第四道防线是人工复核闭环。即使自动化评测全部通过法律场景依然需要人在回路中。常见的做法是把 AI 生成的初步回答推送给法律专业人员由人工在线审核后再对外发布。对于完全自动化的交互产品至少要建立用户反馈按钮和定期抽检机制。运营人员每周抽取一定比例的问答记录判断是否符合业务规范。这个机制虽然简单却是很多法律 AI 产品长期保持质量的基础。下面给一个基于规则的最小引用校验代码思路可以放在query.py的生成逻辑之后def validate_citation(answer_text: str, context_sources: list[str]) - bool: 检查回答中是否出现了知识库来源的前缀。 这里为了演示使用最简规则生产环境建议用更严格的引用识别。 return any(src in answer_text for src in context_sources)如果校验失败可以选择重试一次也可以直接返回类似“该问题暂时无法生成可靠回答请转人工”的安全话术。这道防线并不能证明回答是正确的但至少能降低模型脱离资料自由发挥的概率。7. 没有数据与评测一切都是空中楼阁很多团队做一个法律 AI Demo 只花三天真正上线却用了三个月瓶颈几乎都出现在数据和评测上。RAG 类应用有一句很实在的话更改一个 Prompt 很容易难的是你如何判断这个改动是变好了还是变坏了。没有评测集你只能靠感觉。构建评测集的第一步是定义“好回答”的标准。法律问答至少要评估五个维度事实一致性回答中的法律结论是否与知识库材料一致引用准确性标注的条款号或来源是否真的支持该结论完整性用户关心的关键点是否都覆盖到安全性是否出现编造法条、虚假承诺、误导性表述交互友好性用户能不能看懂下一步操作是否清晰。有了评测维度之后用三类数据构建评测集。第一类是高频真实问题比如劳动纠纷中的试用期辞退、未签合同、拖欠工资第二类是知识库边界之外的问题用来测试系统是否诚实拒绝回答第三类是容易造成误导的“雷区问题”比如“我打了人只要赔钱就不会坐牢吗”这类问题系统必须给出正确边界不能顺着用户的错误假设展开。评测过程不能只看最终回答文字。一个典型的错误是回答本身写得很好但引用的法条与知识库中的法条内容根本没有关系。这是“检索没召回但模型靠常识硬答”的典型症状。所以在自动化评测里必须同时记录召回片段、完整 Prompt 和最终输出三者一起留档。自动化评测只能做初筛法律场景的最终把关还是要靠专业人员。合理的人力投入策略是先用规则和大模型做第一轮粗筛把明显不合格的样例过滤掉再由法律专业人员审核剩余的高风险样例和随机抽样样例。这样既能控制成本又能保证质量底线。评测不是一次性工作。每次更新知识库、修改 Prompt、切换模型都要重新跑一遍评测集。我建议把评测集纳入 Git 仓库与代码一起做版本管理。每一轮 Prompt 优化是否真正提升了回答质量应该有数字记录而不是凭印象拍板。8. 现实边界为什么 AI 还不能当“AI 法官”虽然 AI 在法律服务信息化的前端已经能发挥实际作用但我们必须坦诚地划清边界。如果这个问题问的是“AI 是否已经能改善正义可及性”答案是肯定的但改善的幅度远远小于很多人预期。如果问的是“AI 是否能够代替人来实现正义”答案是否定的而且这个否定不仅仅是技术问题。先看技术层面的局限。法律适用的过程不是简单的“事实到法条”的匹配。同一部法律在不同场景下怎么解释法官在裁量时如何权衡证据、动机、社会影响这些都依赖丰富的语境信息和价值判断。大模型擅长从文本中找到统计规律但法律现实是由无数个案细节构成的。一个人说“我是被辞退的”和“公司以严重违纪为由辞退我”表面是两句话实际对应的是完全不同的举证责任。这类情境判断AI 只能做初步辅助无法形成确定性结论。再看数据层面的限制。法律知识库再怎么更新也天然存在滞后。新的司法解释出台、地方裁审口径调整、典型案例发布都会影响一类案件的判断。模型本身不会“自动知道”这些变化必须依赖工程团队持续维护。这种维护成本容易被低估但恰恰是决定系统长期可用性的关键。还有一层是技术之外的约束。真正“可及”的服务不只是“有人回答你”还要让不熟悉手机、不会操作 App 的老年人和低收入群体也能用上。AI 如果只嵌在网页或移动应用里反而可能制造新的数字鸿沟。那些最需要法律帮助的人往往也是最不容易接触到线上工具的人。这个问题的答案需要线下渠道、社区服务和数字化的配合不是一篇模型部署文档能解决的。责任边界同样重要。如果 AI 给出的参考意见不准确用户因为信赖它而错过仲裁时效责任应该由谁承担部署方、模型开发者还是知识库提供方这个问题在不同地区可能有不同答案但在任何答案里运营方都需要建立完善的日志、审计和免责机制。把 AI 定位成“辅助工具”并加入人工审核既是对用户的保护也是对开发团队的保护。9. 给开发者的落地建议与下一步方向如果你看完前面的内容准备在真实项目里落地一个法律 AI 助手我的建议可以浓缩成五条。第一条不要从“全流程裁判”开始要从“单点信息助手”开始。先选一个知识边界清晰、用户高频提问的场景比如“劳动争议常见问题”或“民间借贷纠纷指引”把知识库做深做细验证整个工程链路跑得通再逐步扩展。贪多求全的结果通常是每个领域都覆盖一点每个问题都答不深。第二条把数据工程放在模型选型之前。模型能力在很多时候已经不是瓶颈真正的瓶颈在于法规文本的结构化程度、检索召回的质量、评测集的覆盖面。建议花 60% 的精力做数据20% 做评测最后 20% 打磨 Prompt 和交互。第三条坚持 Human-in-the-Loop。法律 AI 产品的最佳形态不是“AI 取代律师回答用户”而是“AI 辅助律师和客服更快地回答用户”。系统生成初稿专业人员审核修改后再发送这样既提升了效率又守住了质量底线。第四条重视隐私和合规设计。不要在日志里保存不必要的用户个人信息。如果用户上传了合同、聊天记录等敏感文件处理完成后应当及时清理临时副本。系统中的所有操作都应该有审计记录明确到“谁在什么时间输入了什么系统给出了什么”。最小权限原则不只适用于数据库也适用于 AI 系统的训练和日志分析。第五条建立持续的知识更新机制。法规在变判例在变业务流程也在变。知识库不是一次性做完的它需要像代码一样做版本管理每次更新都要说明变更范围、变更时间和影响条款。知识库上线后建议按月或按季度检查一次覆盖率和过期内容。技术方向上RAG 还远没有到终局。现阶段可以考虑把法律知识图谱和 RAG 结合起来用图谱维护法条之间的引用关系、效力层级和时效状态用向量检索做语义召回再用 Agent 能力做多轮澄清。比如用户只说“被辞退了”Agent 可以继续追问“是否在试用期”“公司给出的理由是什么”“你有没有签合同”逐步定位到更精确的法律条文。这种交互看起来只是多问几个问题实际上是降低误判率的关键设计。最后一个提醒无论你在技术方案上投入多少都不要忘掉产品名称里“助手”这两个字。AI 的价值不是替代专业判断而是让稀缺的专业判断触达更多需要它的人。把一个法律 AI 真正做好考验的不是对大模型的热情而是对用户处境的耐心。这条路比写几个模型调用复杂得多但它值得做。 法律AI助手工程实践：用RAG构建可解释的法律问答系统
一起劳动争议案件的当事人最需要的往往不是“AI 已经给你判了”的结论而是先有人告诉他关于这件事法律是怎么规定的可以主张哪些权利举证要准备什么材料。过去这件事只能依靠律师或法律援助机构背后是昂贵的咨询成本和漫长的排队时间。现在很多法律平台已经接上了大模型“AI 帮助普通人获得法律服务”看起来不再遥远。但问题是AI 真的改善了正义的可及性吗还是只让一堆看起来很像样的答案变得更流畅、更自信我的判断是AI 确实显著降低了法律服务的信息获取成本尤其是在法律检索、文书起草、术语解释、多语言翻译等环节但它并不能自动实现“正义可及性”。这个词的完整含义不只是“让用户问到一个答案”还包括答案是否可靠、引用是否准确、责任谁来承担、不会用手机的人能不能触达、资金不足的法律援助机构是否真的部署得起。换句话说AI 改善的是效率不等于改善结果公平。本文会用工程视角拆解这个问题。先说明“正义可及性”在技术语境下究竟卡在哪里再给出法律 AI 助手的一套最小可运行系统设计包括知识库建设、检索增强生成、提示词约束、输出校验和效果评测。你不需要有法学背景只要熟悉 Python 和大模型 API就能自己跑通一个法律问答原型。读完你会明白为什么说 AI 法律应用真正的分水岭不是模型能力而是数据工程、评测机制和人机协同流程。1. 这篇文章真正要解决的问题法律科技并不是新话题。过去十几年各个机构和企业一直在做“法律信息化”裁判文书上网、电子诉讼平台、线上立案、智能柜员机这些系统解决的是流程数字化。流程数字化确实降低了进入法律程序的操作门槛但它没有解决一个更前置的问题用户根本不知道自己的问题属于哪种法律关系应该适用哪部法规甚至不知道自己“有权利可主张”。大模型的出现改变的是这个前置环节。用户可以直接用自然语言提问“公司没签劳动合同我主动离职还能要双倍工资吗”这种问题不再需要用户预先掌握法律术语。单从交互体验来说AI 法律助手比传统检索系统友好得多。但这里有一个很大的坑法律回答和普通知识问答不一样错误答案的代价不是“少学一个知识点”而是用户可能据此放弃维权、错过时效、提交错误材料。因此一个可用的法律 AI 系统必须同时满足三个条件回答有依据必须能定位到具体法条、规定或案例知识边界清晰不知道就是不知道不能编造有完整的使用链路设计人工复核、免责声明、隐私保护都要跟上。所以本文不是要否定 AI 的正向价值而是想说明白AI 想要真正改善法律服务的可及性开发者必须从“模型能聊天”走向“系统能负责”。最适合读这篇文章的读者有两类。第一类是正在做或打算做法律科技产品的工程师你需要一套能落地的架构思路和原型代码第二类是做 AI 应用落地的技术人员虽然不做法律方向但可以借鉴如何用检索增强、提示词约束和评测机制解决“大模型一本正经胡说八道”的通病。2. “正义可及性”到底卡在哪里“Access to Justice”在国内法律界常被译作“接近正义”日常讨论中也叫“正义可及性”或“司法便利”。它不是一个抽象口号而是可以拆解的工程问题。一个普通人要解决法律纠纷大致要走完这样一条链路意识到自己遇到了法律问题 → 判断问题类型 → 找到法律依据 → 准备证据和文书 → 进入调解、仲裁或诉讼程序 → 获得结果并执行。传统法律服务体系在这条链路上存在很多断点。第一个断点是信息成本。法律条文本身是公开的但普通人很难读懂条文之间的适用关系。比如劳动合同法里的“经济补偿”和“赔偿金”只差一个字适用条件完全不同非专业人士很容易混淆。第二个断点是语言壁垒。法规语言高度抽象民间表达又充满口语和隐含情境两边存在翻译成本。第三个断点是地域和资源不均衡。发达地区的法律服务资源相对充足偏远地区的用户可能连“去法律援助中心问一下”都未必方便。第四个断点是时间成本即使找到律师一次咨询的完整流程往往需要数天甚至数周。以往的信息化手段主要解决的是“程序入口”问题比如把线下立案搬到线上。可用户走到立案这一步之前已经需要大量前置知识。大模型和自然语言处理技术第一次让机器能够在“用户还没想清楚自己属于哪类纠纷”的时候就通过与他的对话逐步澄清问题、给出初步指引。这是 AI 在法律服务领域最核心的价值点它把断点向前挪到了“用户最早产生困惑”的那个时刻。但注意技术只能解决“信息供给”问题。用户获得了信息之后是否有能力执行材料怎么填写证据链是否完整这些依然依靠后续的服务体系。如果我们把一个法律 AI 问答产品当成“正义可及性”的全部那只会让那些最不会使用数字工具的人被排除在另一个入口之外。3. 法律场景下的 AI 能力地图要判断 AI 能在多大程度上改善法律服务先要看清楚 AI 在具体法律任务上的真实能力边界。把任务分类之后结论会更冷静。任务类型传统方式AI 辅助方式当前成熟度法律检索关键词查数据库需要用户先懂术语自然语言语义检索支持“我离职后公司不给工资怎么办”这类提问较成熟工程上可落地合同审查律师逐条人工阅读OCR 文档解析 条款风险识别中高但必须人工复核法律文书生成从模板复制粘贴修改用结构化问答生成申请书、起诉状初稿中等格式化文书效果较好法律知识问答人工客服或电话咨询RAG 增强的大模型问答可引用来源中等强依赖知识库质量裁判结果预测完全依赖律师经验判断裁判文书 统计模型给出倾向性分析早期不能作为正式参考多语言与口语化翻译专业翻译成本高机器翻译 法律术语库中高复杂条款仍需校对法律援助分流人工记录、转接意图识别 知识库引导 人工兜底生产可用这张表有一个值得注意的规律越靠近“信息整理”的任务AI 越可靠越靠近“价值判断和最终裁定”的任务AI 越不可靠。法律检索做错了检索系统多返回几条内容问题不大但裁判预测若是错了用户可能基于错误的预期做出非常错误的决策。所以给法律 AI 做能力定位时我更推荐“助手”而不是“裁判”的角色。从技术实现角度看法律场景里的 AI 并不只有大模型一种组件。一个完整的法律智能系统通常由五层组成数据层法规库、裁判文书库、合同模板库、实务问答库处理层PDF/图片转文字、文档切分、条款结构化、命名体识别知识层向量索引、法律知识图谱、法条关联关系应用层问答助手、文书生成、合同审查、风险预警控制层来源引用、权限管理、人工复核、操作审计。很多人以为做一个“法律 AI”就是调大模型的 API这是最危险的误解。大模型只是应用层的一个生成引擎它能不能回答得靠谱完全取决于前面几层有没有做好。4. 核心架构法律问答助手的设计思路下面用一个最常见的“法律 AI 助手”作为例子讲清楚整体架构。这个助手要解决的核心场景是用户用大白话提问系统返回有依据、可读、能进一步操作的初步法律指引。系统的整体流程可以拆成六个环节用户输入问题系统做基础预处理包括去敏感信息、判断问题与法律领域的相关性在法规和实务知识库中做语义检索召回最相关的若干片段把用户问题和召回片段一起交给大模型要求只能依据材料回答对回答做格式校验和引用完整性检查输出给用户同时保留完整日志供人工复核和后续评测。第 3 步和第 4 步合起来就是现在最常用的 RAG检索增强生成。RAG 之所以重要是因为大模型无法记住不断变化的法律法规也不适合靠参数记忆来输出需要精确到条款号的内容。RAG 的思路是不强迫模型“背法条”而是先从知识库里把相关法条找出来放到提示词里让模型基于给定的材料作答。在法律场景知识库的组织方式比模型选择更关键。法规库不能简单地把整部法律塞成一个大文档。更好的做法是做到“结构化入库”按编、章、条拆分保存条款号、效力级别、施行日期、最近修改日期等元数据。这样检索时既可以做语义召回也能用条款号做精确过滤。比如用户问“试用期辞退”系统可以先定位到劳动合同法相关条款再根据“是否在试用期内”细分。原型项目需要控制规模但目录结构应当向生产级架构看齐。我把 Demo 设计成下面这样legal-ai-demo/ ├── data/ # 存放法律知识文档支持 txt/md ├── ingest.py # 文本清洗、切分、向量化、入库 ├── query.py # 检索 生成回答 ├── requirements.txt # Python 依赖 └── README.md这个小项目没有引入重型向量数据库而是用本地文件加余弦相似度实现最小检索链路。这样做的目的是先跑通逻辑。真实项目可以把向量部分替换为 Milvus、Elasticsearch 或云上向量检索服务架构不会变只是工程能力扩展。5. 从零搭一个最小可用的法律 AI 助手现在进入实操环节。我的目标不是做一个能直接商用的产品而是用尽量少的代码跑通“法律知识入库 → 语义检索 → 大模型约束生成 → 来源展示”的完整链路。5.1 环境准备建议使用 Python 3.10 及以上版本。需要安装的依赖如下# requirements.txt numpy1.24 openai1.0这里使用 OpenAI 兼容的客户端接口。你可以把OPENAI_BASE_URL指向任意兼容服务包括云服务商提供的合规模型接口也可以指向你自己部署的本地网关。嵌入模型和对话模型都通过环境变量配置方便替换。export OPENAI_API_KEYyour_api_key export OPENAI_BASE_URLhttps://your-compatible-endpoint/v1 export EMBEDDING_MODELtext-embedding-3-small export LLM_MODELgpt-4o-mini如果你用的是本地模型服务没有真实密钥也可以设置一个占位值比如EMPTY。关键是保证接口协议兼容。5.2 法律知识库文本入库法律文本和普通文章不一样它常常有清晰的条、款、项结构。但为了演示通用思路我们先用一个简单的切分函数优先按段落切分遇到超长段落再按句号做二次切分。实际项目中强烈建议根据具体法规的条文章节做结构化切分而不是依赖通用切分。代码放在ingest.py中# ingest.py import json import uuid from pathlib import Path from openai import OpenAI DATA_DIR Path(./data) INDEX_DIR Path(./index) client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text-embedding-3-small) def embed_texts(texts: list[str]) - list[list[float]]: 批量向量化。OpenAI 兼容接口一次调用即可。 resp client.embeddings.create(modelEMBEDDING_MODEL, inputtexts) return [item.embedding for item in resp.data] def chunk_document(content: str, max_len: int 300) - list[str]: 把整篇法律文本切成适合检索的片段。 优先保留段落结构超长段落按句号切分。生产环境应改为按条切分。 units [] content content.replace(\r, ).strip() for para in content.split(\n\n): para para.strip() if not para: continue while len(para) max_len: cut para.rfind(。, 0, max_len) if cut -1: cut max_len units.append(para[: cut 1].strip()) para para[cut 1:].strip() if para: units.append(para) return units def build_index() - None: rows [] for path in DATA_DIR.iterdir(): if path.suffix.lower() not in {.txt, .md}: continue text path.read_text(encodingutf-8) chunks chunk_document(text) for idx, content in enumerate(chunks): rows.append({ id: str(uuid.uuid4()), source: path.name, chunk_id: idx, content: content, }) if not rows: print(没有在 data 目录下找到 txt/md 文档) return texts [r[content] for r in rows] embeddings embed_texts(texts) INDEX_DIR.mkdir(exist_okTrue) with open(INDEX_DIR / chunks.json, w, encodingutf-8) as f: json.dump(rows, f, ensure_asciiFalse, indent2) import numpy as np matrix np.array(embeddings, dtypefloat32) np.save(INDEX_DIR / embeddings.npy, matrix) print(f入库完成共 {len(rows)} 个知识片段) if __name__ __main__: build_index()这段代码把data/目录下的每篇法律文档切分成多个片段为每个片段生成向量然后把片段元数据保存为 JSON向量矩阵保存为 npy 文件。所谓“入库”本质就是把纯文本变成可检索的向量索引。切分参数max_len300只是一个示例值。法律条文的颗粒度差异很大有的条很短有的条包含多款。所以生产项目里更合理的做法是先按“第X条”的正则表达式切出条文再把包含多款的条文按“第X款”二次切分。5.3 语义检索与回答生成接下来写query.py。它负责加载索引、计算用户问题的向量、用余弦相似度召回 TopK 片段然后把召回内容拼进提示词让大模型生成回答。# query.py import json import os import numpy as np from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text-embedding-3-small) LLM_MODEL os.getenv(LLM_MODEL, gpt-4o-mini) INDEX_DIR ./index def load_index(): with open(f{INDEX_DIR}/chunks.json, encodingutf-8) as f: chunks json.load(f) matrix np.load(f{INDEX_DIR}/embeddings.npy) return chunks, matrix def search(question: str, top_k: int 5): chunks, matrix load_index() resp client.embeddings.create( modelEMBEDDING_MODEL, input[question] ) q_vec np.array(resp.data[0].embedding, dtypefloat32) # 归一化后做内积等价于余弦相似度 q_vec q_vec / np.linalg.norm(q_vec) matrix_norm matrix / np.linalg.norm(matrix, axis1, keepdimsTrue) scores matrix_norm q_vec top_indices np.argsort(scores)[::-1][:top_k] results [] for idx in top_indices: item chunks[idx] results.append({ content: item[content], source: item[source], chunk_id: item[chunk_id], score: float(scores[idx]), }) return results def build_prompt(question: str, contexts: list[dict]) - str: context_text \n\n.join( f[来源{item[source]} / 第{item[chunk_id]}段]\n{item[content]} for item in contexts ) prompt f你是一名严谨的法律信息助手。你的目标不是代替法官或律师作出决定而是帮助用户理解与问题相关的法律知识。 请遵守以下规则 1. 优先依据下方【参考资料】回答如果材料充分请结合材料分点解释。 2. 每一个关键结论后面用 [来源xxx / 第x段] 标注依据。 3. 如果参考资料不足以回答请直接说“当前知识库没有覆盖该问题建议咨询专业法律人士”。 4. 禁止编造法条、案例或文件名称。 5. 不要使用“根据法律规定”这种模糊表述除非你确实在资料中定位到了对应内容。 【用户问题】 {question} 【参考资料】 {context_text} return prompt def answer(question: str) - str: contexts search(question, top_k5) prompt build_prompt(question, contexts) resp client.chat.completions.create( modelLLM_MODEL, messages[{role: user, content: prompt}], temperature0.1, ) result resp.choices[0].message.content return result, contexts if __name__ __main__: q 试用期被公司辞退怎么办 result, contexts answer(q) print(回答) print(result) print(\n召回的知识片段) for c in contexts: print(f- {c[source]} / 第{c[chunk_id]}段 (score{c[score]:.4f}))这里有几个设计点值得展开。第一temperature设置为 0.1尽量降低模型输出的随机性。法律回答应该稳定不需要创意。第二提示词明确要求“禁止编造”和“标注依据来源”这是 RAG 应用里控制幻觉的第一道闸门。第三检索的 TopK 设置为 5实际项目中可以根据知识库质量和问题复杂度动态调整。如果召回太少模型容易没话说召回太多提示词会过长而且无关片段反而可能干扰生成。5.4 Prompt 模板法律场景的约束策略提示词设计在法律 AI 中很容易被低估。很多法律平台早期把通用对话提示词拿过来直接用结果模型动不动就给出“综合分析如下”的长篇大论看似严谨实际无法定位到具体条款。我在上面给出的提示词有几个明确设计意图角色定位为“法律信息助手”不是“法律专家顾问”避免模型进入过度自信的专家口吻明确要求依据材料回答不依据内部记忆自由发挥要求每个关键结论后标注来源便于用户核查允许回答“不知道”并且给出替代建议。这段 Prompt 的核心思想是“用约束换取可控性”。你不可能完全消除大模型的幻觉但你可以让它在犯错时更容易被发现。5.5 运行与验证先把准备好的法律文档放进data/目录。比如准备一份劳动合同法相关的公开文本命名为labor_law.txt。然后执行入库python ingest.py预期输出类似入库完成共 87 个知识片段如果提示没有文档先检查data/目录下是否有.txt或.md文件。接下来执行问答python query.py 试用期被公司辞退怎么办输出会分为三部分模型回答、召回片段列表、每个片段的相关性分数。判断系统是否正常工作的第一步不是看回答是否流畅而是看召回片段是否包含真正相关的条款。如果召回的内容本身就偏了后面的模型回答再通顺也没有意义。这里需要特别说明Demo 展示的是技术链路的可行性不是成熟的法律产品输出。无论这个回答写得多么合理都不应该直接当成正式法律意见使用。一个真实可用系统必须有“该回答仅供参考”的明确提示并把完整的原始召回片段同步展示给用户。6. 保证法律回答“不胡说”的工程手段大模型应用于法律领域最让人担心的不是能力不足而是“能力越强幻觉越难发现”。模型会用一种非常笃定的语气把不存在的规定讲得头头是道。所以法律 AI 系统的工程重心应该放在可信控制上。除了 Prompt 约束之外至少还有四道防线。第一道防线是召回质量。如果知识库本身没有相关条文模型再强也无法生成有根据的答案。召回质量取决于三件事知识库是否覆盖、切片是否合理、Embedding 模型是否适配法律术语。法律文本中有大量长句和特定术语通用切分经常把一个条文拦腰截断。更稳妥的做法是按“编-章-条-款”结构化组织然后对每个条款做 embedding。第二道防线是引用完整性校验。在 Prompt 里要求模型标注来源只是第一步。模型可能在正文里写了“根据相关规定”却没有标注具体来源。更严谨的做法是在返回给用户之前用规则或第二个模型检查回答中是否存在引用标记。如果某些关键结论缺少引用系统可以拒绝输出或要求重写。最简单的方式是检查回答文本中是否出现了召回片段里的文件名或来源前缀。第三道防线是置信度控制。检索阶段可以拿到相似度分数。用户的问题与知识库内容的相似度如果整体偏低比如最高分只有 0.3系统就不应该强行让模型回答。这时候更合适的做法是直接告诉用户“该问题超出当前知识库范围建议转人工咨询”。把“不知道”做成一种正常的系统行为而不是让模型硬答。第四道防线是人工复核闭环。即使自动化评测全部通过法律场景依然需要人在回路中。常见的做法是把 AI 生成的初步回答推送给法律专业人员由人工在线审核后再对外发布。对于完全自动化的交互产品至少要建立用户反馈按钮和定期抽检机制。运营人员每周抽取一定比例的问答记录判断是否符合业务规范。这个机制虽然简单却是很多法律 AI 产品长期保持质量的基础。下面给一个基于规则的最小引用校验代码思路可以放在query.py的生成逻辑之后def validate_citation(answer_text: str, context_sources: list[str]) - bool: 检查回答中是否出现了知识库来源的前缀。 这里为了演示使用最简规则生产环境建议用更严格的引用识别。 return any(src in answer_text for src in context_sources)如果校验失败可以选择重试一次也可以直接返回类似“该问题暂时无法生成可靠回答请转人工”的安全话术。这道防线并不能证明回答是正确的但至少能降低模型脱离资料自由发挥的概率。7. 没有数据与评测一切都是空中楼阁很多团队做一个法律 AI Demo 只花三天真正上线却用了三个月瓶颈几乎都出现在数据和评测上。RAG 类应用有一句很实在的话更改一个 Prompt 很容易难的是你如何判断这个改动是变好了还是变坏了。没有评测集你只能靠感觉。构建评测集的第一步是定义“好回答”的标准。法律问答至少要评估五个维度事实一致性回答中的法律结论是否与知识库材料一致引用准确性标注的条款号或来源是否真的支持该结论完整性用户关心的关键点是否都覆盖到安全性是否出现编造法条、虚假承诺、误导性表述交互友好性用户能不能看懂下一步操作是否清晰。有了评测维度之后用三类数据构建评测集。第一类是高频真实问题比如劳动纠纷中的试用期辞退、未签合同、拖欠工资第二类是知识库边界之外的问题用来测试系统是否诚实拒绝回答第三类是容易造成误导的“雷区问题”比如“我打了人只要赔钱就不会坐牢吗”这类问题系统必须给出正确边界不能顺着用户的错误假设展开。评测过程不能只看最终回答文字。一个典型的错误是回答本身写得很好但引用的法条与知识库中的法条内容根本没有关系。这是“检索没召回但模型靠常识硬答”的典型症状。所以在自动化评测里必须同时记录召回片段、完整 Prompt 和最终输出三者一起留档。自动化评测只能做初筛法律场景的最终把关还是要靠专业人员。合理的人力投入策略是先用规则和大模型做第一轮粗筛把明显不合格的样例过滤掉再由法律专业人员审核剩余的高风险样例和随机抽样样例。这样既能控制成本又能保证质量底线。评测不是一次性工作。每次更新知识库、修改 Prompt、切换模型都要重新跑一遍评测集。我建议把评测集纳入 Git 仓库与代码一起做版本管理。每一轮 Prompt 优化是否真正提升了回答质量应该有数字记录而不是凭印象拍板。8. 现实边界为什么 AI 还不能当“AI 法官”虽然 AI 在法律服务信息化的前端已经能发挥实际作用但我们必须坦诚地划清边界。如果这个问题问的是“AI 是否已经能改善正义可及性”答案是肯定的但改善的幅度远远小于很多人预期。如果问的是“AI 是否能够代替人来实现正义”答案是否定的而且这个否定不仅仅是技术问题。先看技术层面的局限。法律适用的过程不是简单的“事实到法条”的匹配。同一部法律在不同场景下怎么解释法官在裁量时如何权衡证据、动机、社会影响这些都依赖丰富的语境信息和价值判断。大模型擅长从文本中找到统计规律但法律现实是由无数个案细节构成的。一个人说“我是被辞退的”和“公司以严重违纪为由辞退我”表面是两句话实际对应的是完全不同的举证责任。这类情境判断AI 只能做初步辅助无法形成确定性结论。再看数据层面的限制。法律知识库再怎么更新也天然存在滞后。新的司法解释出台、地方裁审口径调整、典型案例发布都会影响一类案件的判断。模型本身不会“自动知道”这些变化必须依赖工程团队持续维护。这种维护成本容易被低估但恰恰是决定系统长期可用性的关键。还有一层是技术之外的约束。真正“可及”的服务不只是“有人回答你”还要让不熟悉手机、不会操作 App 的老年人和低收入群体也能用上。AI 如果只嵌在网页或移动应用里反而可能制造新的数字鸿沟。那些最需要法律帮助的人往往也是最不容易接触到线上工具的人。这个问题的答案需要线下渠道、社区服务和数字化的配合不是一篇模型部署文档能解决的。责任边界同样重要。如果 AI 给出的参考意见不准确用户因为信赖它而错过仲裁时效责任应该由谁承担部署方、模型开发者还是知识库提供方这个问题在不同地区可能有不同答案但在任何答案里运营方都需要建立完善的日志、审计和免责机制。把 AI 定位成“辅助工具”并加入人工审核既是对用户的保护也是对开发团队的保护。9. 给开发者的落地建议与下一步方向如果你看完前面的内容准备在真实项目里落地一个法律 AI 助手我的建议可以浓缩成五条。第一条不要从“全流程裁判”开始要从“单点信息助手”开始。先选一个知识边界清晰、用户高频提问的场景比如“劳动争议常见问题”或“民间借贷纠纷指引”把知识库做深做细验证整个工程链路跑得通再逐步扩展。贪多求全的结果通常是每个领域都覆盖一点每个问题都答不深。第二条把数据工程放在模型选型之前。模型能力在很多时候已经不是瓶颈真正的瓶颈在于法规文本的结构化程度、检索召回的质量、评测集的覆盖面。建议花 60% 的精力做数据20% 做评测最后 20% 打磨 Prompt 和交互。第三条坚持 Human-in-the-Loop。法律 AI 产品的最佳形态不是“AI 取代律师回答用户”而是“AI 辅助律师和客服更快地回答用户”。系统生成初稿专业人员审核修改后再发送这样既提升了效率又守住了质量底线。第四条重视隐私和合规设计。不要在日志里保存不必要的用户个人信息。如果用户上传了合同、聊天记录等敏感文件处理完成后应当及时清理临时副本。系统中的所有操作都应该有审计记录明确到“谁在什么时间输入了什么系统给出了什么”。最小权限原则不只适用于数据库也适用于 AI 系统的训练和日志分析。第五条建立持续的知识更新机制。法规在变判例在变业务流程也在变。知识库不是一次性做完的它需要像代码一样做版本管理每次更新都要说明变更范围、变更时间和影响条款。知识库上线后建议按月或按季度检查一次覆盖率和过期内容。技术方向上RAG 还远没有到终局。现阶段可以考虑把法律知识图谱和 RAG 结合起来用图谱维护法条之间的引用关系、效力层级和时效状态用向量检索做语义召回再用 Agent 能力做多轮澄清。比如用户只说“被辞退了”Agent 可以继续追问“是否在试用期”“公司给出的理由是什么”“你有没有签合同”逐步定位到更精确的法律条文。这种交互看起来只是多问几个问题实际上是降低误判率的关键设计。最后一个提醒无论你在技术方案上投入多少都不要忘掉产品名称里“助手”这两个字。AI 的价值不是替代专业判断而是让稀缺的专业判断触达更多需要它的人。把一个法律 AI 真正做好考验的不是对大模型的热情而是对用户处境的耐心。这条路比写几个模型调用复杂得多但它值得做。