文章目录背景我为什么要搭这个最终效果先说清楚谁会用它什么时候用Before vs After变化发生在哪一步为什么选劳动争议而不是通用合同审查16 份案卷不是随机样例搭建过程技术选型核心 Prompt / Agent 编排图片是怎样送进模型的请求体长什么样System Prompt 全文这七条里最要紧的三条输出契约模型说的话得能在原文里找到JSON 会被截断所以要能修切片对照组必须诚实实现前端把引用做成可点击的定位踩坑记录接口协议404 但错的不是路径Windows 下中文请求体会损坏公章得让模型看得清埋点会跑偏所以写了个校验脚本效果对比严格判分的结果三条漏检它自己找出来的东西长上下文 vs 切片对照总结Qwen3.8-Max 在这个场景下的表现当前局限复现指南背景我为什么要搭这个最近在往 AI 应用方向转习惯拿真实业务流程练手。这次挑的是劳动仲裁的庭前质证开庭前用人单位会提交一整箱证据员工手册、规章制度的民主程序材料、工会通知函和复函、考勤记录、工资水单、绩效制度、解除通知书、往来邮件导出按目录编号排好一份一份规规矩矩。问题是你把它们一份一份读完会发现每一份看起来都没问题。真正致命的东西不在任何一份文件里面它在文件与文件之间。于是我做了一个工具把全部材料一次性投进去专门找跨文档的时序矛盾和程序硬伤。选这个场景还有个原因它的对错可以被检查。模型说这里有程序瑕疵我能追问它涉及哪几份文档、原文怎么写的、援引哪条法律。比起让模型写一段漂亮的法律分析这种能被追责的输出更适合判断一个模型能不能真干活。最终效果先看跑起来是什么样庭前质证助手内容依次是案卷材料浏览16 份文档 8 张扫描件→ 触发全量分析 → 流式进度推进 → 案件概览 → 矛盾清单与引用定位。我构造了一份完整案卷做真实测试16 份文档共 59,362 字外加 8 张渲染成扫描件的图片会议纪要、签到表、解除通知、工会函件等。不做任何切分全部一次性送进模型。单次运行实测输入 59,214 token模型思考消耗 19,588 token输出 30,033 token缓存命中 54,272 token端到端 557.72 秒约 9 分 18 秒运行编号full_context_20260810-020551_4940。返回结果重建出 26 条事件时间线其中 16 个节点标记为时序异常检出13 处跨文档矛盾每一处都带涉及文档、原文摘录、援引法条和置信度。流式界面这张我想单独说一句因为它把跨文档这件事直接摆在了屏幕上。后端真实推送的进度事件是这样的[ 3%] 正在读取案卷材料… [ 8%] 已读取 16 份材料、8 张扫描件正文约 33,050 tokens [ 15%] 正在把 16 份材料与 8 张扫描件一次性送入模型重建时间线并交叉比对… [ 55%] 已发现 13 处跨文档矛盾正在生成逐份质证意见…前端把这些事件渲染成左侧阶段推进 右侧日志流交叉比对的部分会展示成D05 × D02 × D03 × D14这样的形式——意思是这一条矛盾必须同时看到四份文件才能发现。先说清楚谁会用它什么时候用三类人。正在打劳动仲裁的当事人。 大部分人请不起律师或者请了律师但律师手上同时有二十个案子。开庭前把对方提交的材料全部投进去拿到一份带原文定位的矛盾清单知道该在庭上主攻哪几个点。工会法援志愿者和律所实习生。 他们的工作里有大量材料初筛。把机械比对交给工具人的精力集中在模型标红的时点上做判断。做劳动用工合规的 HR。 这个用法是反过来的把自己公司的制度文本、民主程序材料、历次修订记录投进去看有没有同样的缝隙。制度改了没重新走民主程序、新版本没送达员工、工会审议的文件名和实际执行的对不上。这些在真实企业里非常普遍而且往往是无心之失。等到仲裁庭上被对方指出来已经晚了。我把工具的职责限定为庭前准备参考。它不出具法律意见不替代律师。每条输出都带原文引用和地区口径提示最终判断仍然由人做。Before vs After变化发生在哪一步举一个具体的矛盾。有一份《员工手册培训签到表》日期 2023 年 3 月 15 日员工本人签的字。这份文件本身完全正常。公司组织了培训员工参加了签了到。另有一份《工会成立备案回执》上级工会出具写明该公司工会委员会成立日期为 2024 年 1 月 10 日。这份文件本身也完全正常。单看任何一份都挑不出毛病。但把它们并排放在一起《劳动合同法》第四条要求直接涉及劳动者切身利益的规章制度应当经职工代表大会或全体职工讨论与工会或职工代表平等协商确定。而这家公司组织学习该制度的时候它的工会还有整整十个月才成立。一个尚不存在的主体不可能与谁平等协商。Before人也能看出来前提是同时记住 16 份文件里的所有日期、版本号、盖章主体和条款编号并且两两比对。这件事不难但极其琐碎。读到第十二份的时候第三份里那个不起眼的日期早忘了。After全部材料在同一个上下文里日期比对是模型顺手做的事。这里我必须诚实我没有做严格计时的人工对照实验所以不给从两小时降到九分钟这样的数字。这类数字很好编编出来就没意义了。我能确定的变化是另一件事——它找到了我没找到的东西后面会讲。为什么选劳动争议而不是通用合同审查因为这个场景把 Qwen3.8-Max 的三个能力逼到了必须同时在场的位置。上下文装不下就得切片而切片在这里是致命的。 常规做法是把材料切成小块做向量检索命中哪块处理哪块。但矛盾恰恰存在于A 文件的日期和B 文件的要求之间。一旦切开两块内容永远不会同时出现在模型视野里这类矛盾在原理上就检测不到了。材料根本不是纯文本。 真实案卷是扫描件、翻拍照片、聊天截图。公章上的字、签到表上有几个签名、手写的签收日期是几号这些信息只存在于图像里。传统流程要先跑 OCR而 OCR 会把公章的环形文字、手写体、表格结构全丢掉丢掉的恰恰是关键。需要真推理而不是关键词匹配。 “函件要求 6 月 28 日前完成而函件落款就是 6 月 28 日”——没有任何关键词能命中这个矛盾它需要理解要求的期限和文件生成的时点之间的逻辑关系。三个能力缺一个这件事就做不成。所以它不属于换了个更强的模型那类改进而是这些能力不存在时这个产品就无法成立。16 份案卷不是随机样例演示案卷是虚构的公司名、人名、日期全部虚构不涉及任何真实当事人。但案卷里预埋的每一处矛盾类型和裁判标准都取自公开裁判案例。我先去查了公开判例整理出一张矛盾类型表民主程序时序倒挂培训学习早于工会成立、制度版本内容不一致工会审议的和解除援引的不是同一份文件、公示告知断链员工签收的是旧版、未事先通知工会、绩效制度溯及既往、会议纪要形式要件缺失、单方安排年休假规避补偿。每一条都能追溯到具体案例和具体法条出处台账写在项目的data/SOURCES.md里。然后按这张表反过来造案卷一共埋了 10 处矛盾另放 3 个干扰项都是看起来像问题但其实站不住的东西手册里一条高额违约金条款确实无效但本案争议焦点是违法解除公司并未据此主张权利列为本案矛盾点属于跑题原合同 2024 年 2 月 29 日到期、续签合同 3 月 1 日起始看着像有一天空档但 2024 年是闰年衔接完整某月社保基数从 8200 调到 9100看着像随意变更实际是年度申报调整且对劳动者有利10 处矛盾里7 处标记为跨文档必须同时看到两份以上材料才能发现2 处标记为纯视觉只能从图像看出来公章的盖章主体与用人单位不一致、参会签到表上只有三个签名。纯视觉那两处专门用来验证多模态是不是必需能力而不是可有可无的装饰。答案存在单独的answer_key.json里分析引擎完全读不到代码里也没有任何硬编码的矛盾点。搭建过程整条链路的核心是第四个环节16 份文本和 8 张图像合并成一个 content 数组一次送入中间不做任何切分。左边那条虚线是评测的前提——预埋的答案从案卷生成阶段直接走到评测判分绕开整条分析链路引擎读不到。技术选型工具链方面全程在 Claude Code 里搭没用别的 IDE 插件。它对我的实际价值不在补全代码在于契约定死之后可以开四条并行线——案卷生成、后端分析引擎、前端、评测框架各跑各的互不阻塞。这个项目里配套脚本的工作量超过主链路本身串行做会拖很久。技术栈是后端 Python FastAPI模型走 Responses API。前端 Vue 3 Vite TypeScript评测脚本纯 Python除可选的 jsonschema 外无第三方依赖。除了主链路还写了四个配套脚本它们的工作量其实超过了主链路本身脚本作用gen_structured.py生成考勤、工资条等结构化案卷固定随机种子gen_docs.py调模型生成叙述性案卷矛盾埋点写死在 spec 里verify_case.py逐份校验埋点是否精确落地不通过就重新生成render_scans.py把案卷渲染成带公章和手写签名的扫描件结构化数据我没交给模型。240 行考勤记录、12 个月工资条用 Python 直接生成埋点精确可控随机种子固定任何人重跑都得到完全相同的案卷。核心 Prompt / Agent 编排图片是怎样送进模型的Responses API 的图片走input_image本地文件 base64 内联def_image_part(path:Path)-dict[str,Any]:mimemimetypes.guess_type(path.name)[0]orimage/pngencodedbase64.b64encode(path.read_bytes()).decode(ascii)return{type:input_image,image_url:fdata:{mime};base64,{encoded}}8 张扫描件和 16 份文本合并成同一个 user 消息的 content 数组一次性发出。没有分批没有先 OCR 再喂文本这一步。这正是要验证的能力。请求体长什么样payload{model:model,input:[]}ifsystem:payload[input].append({role:system,content:[{type:input_text,text:system}]})payload[input].append({role:user,content:content})effortreasoning_effortoros.environ.get(QWEN_REASONING_EFFORT)ifeffort:payload[reasoning]{effort:effort}reasoning.effort我用的是xhigh。这次运行思考消耗 19,588 token最终输出 30,033 token——思考量还不到输出的三分之二。我原本以为时序推理会吃掉大量思考预算实测并没有。另外缓存命中了 54,272 token开发阶段反复投喂同一批材料时这一项很省。System Prompt 全文你是一名长期专办劳动争议案件的资深律师现受**劳动者仲裁申请人**委托为即将开庭的劳动仲裁做庭前质证准备。 用人单位被申请人已提交整箱证据你要在开庭前把这些材料**整体**读一遍找出它们相互之间对不上的地方。 工作原则 1. **只依据材料本身说话。** 每一个结论都必须能落回具体文档的原文。材料里没有的事实不许推定、不许脑补也不要引用本案材料之外的事实。 2. **摘录必须逐字复制原文。** 不得改写、不得概括成大意、不得自己加标点。原文过长时截取最能说明问题的一句控制在 60 字以内。摘录要能被前端在原件里检索到所以必须与原文完全一致。 3. **跨文档矛盾是本次工作的核心。** 单份文档内部的瑕疵也要写但优先找A 文档说的和 B 文档说的对不上——时间倒挂、主体不一致、版本不一致、口径不一致这类**必须同时看多份材料才能发现**的问题。凡跨文档矛盾citations 必须把涉及的每一份文档都列出来缺一份都算没写完。 4. **有多大把握写多大把握。** confidence 如实填写。拿不准的写低置信度并在 description 里说明还需要什么材料才能坐实不要为了凑数把猜测写成事实。宁可少写一条不可编造一条。 5. **中国劳动争议的裁判口径存在明显地区差异。** 凡结论依赖于地方裁审惯例、审查宽严尺度的必须在 region_caveat 里写明差异不得给出单一确定结论。 6. **输出是庭前准备参考不是法律意见。** 必须在 summary.disclaimer 中声明不替代执业律师。 7. **严格输出 JSON。** 不要输出 JSON 之外的任何文字不要用 markdown 代码块包裹不要写解释性前言或结语。这七条里最要紧的三条第一每条结论必须给原文摘录。不允许空泛断言存在程序瑕疵必须写明是哪份文档的哪句话。这条是为了让输出可回溯也是评测能判分的前提。第二必须标注地区裁判口径差异。劳动争议的地区差异很大未建立工会时是否仍需通知工会多数地区以已建立工会为前提江苏等地则要求通知所在地工会规章制度的民主程序审查广东部分口径对内容合法且已公示的制度认定较宽松多数地区严格要求用人单位举证。所以输出结构里有个region_caveat字段工具不说这个一定违法而是说这一点在多数地区会被认定为程序瑕疵但某些地区口径不同需要确认本地判例。第三必须输出免责声明。法律工具最危险的地方是给出听起来确定的错误结论。输出契约前后端和评测脚本共用一份 JSON Schemadocs/CONTRACT.schema.json三大产出timeline— 事件时间线每条带anomaly字段标记时序异常contradictions— 矛盾清单每条带citations数组每个引用有doc_id、quote、from_imagecross_examination— 逐份证据的三性质证意见 应对方案契约先定死前端、后端、评测三边才能并行开发不打架。这个决定后来省了很多返工。模型说的话得能在原文里找到这是整个项目我认为最重要的一段代码。法律工具最怕的不是漏检是编造。模型说《员工手册》第十九条规定……如果这句话原文里根本没有这条结论在庭上会当场垮掉比没有还糟。所以每条引用都要回原文核对defaudit_quotes(result:dict[str,Any],docs:list[CaseDoc])-dict[str,Any]:自检每条 citation 的 quote 能否在对应文档原文中检索到。 去掉空白与常见标点后做子串匹配容忍模型抄写时的排版差异。 命中率低说明模型在编造摘录是评测报告里必须披露的指标。 norm_docs{d.doc_id:_NOISE.sub(,d.text)fordindocs}totalhit0misses[]forcinresult.get(contradictions,[]):forcitinc.get(citations,[]):ifcit.get(from_image):continue# 图像上的内容文本里可能没有不计入total1bodynorm_docs.get(cit[doc_id],)q_NOISE.sub(,cit.get(quote,))ifqandqinbody:hit1else:misses.append({contradiction_id:c[id],doc_id:cit[doc_id]})return{checked:total,verbatim_hits:hit,hit_rate:round(hit/total,3)iftotalelseNone,misses:misses[:20]}两个细节值得说。一是去噪后做子串匹配模型抄原文时常把全角标点改成半角、把换行合并掉直接精确匹配会误杀大量正确引用。二是**from_image**的引用要跳过来自扫描件的摘录比如公章上的字在文本里根本不存在算作编造是冤枉的。实测结果42 条可核查引用中 41 条能在原文逐字找到1 条无法验证。这个数字比召回率更能说明模型有没有在胡说。JSON 会被截断所以要能修长输出被截断是必然遇到的。第三个产出要给 16 份证据逐份写质证意见输出量很大多次运行都在中途断掉。断掉的 JSON 直接json.loads会抛异常前面几千 token 的有效内容全丢。所以解析走容错路径先正常解析失败则回退到_repair_truncated()扫描未闭合的字符串、数组和对象补齐括号丢掉最后一条不完整的记录保住前面完整的部分。这不优雅是现实妥协。但对一次要跑九分钟的调用来说救回 80% 的结果比重跑划算得多。切片对照组必须诚实实现对照实验最容易作弊的地方是把 B 组实现得比实际更差。所以切片这段写得很克制按行切而不是按字符切尽量不切断表格行短文档合并进同一块充分利用预算超长文档才跨块。这些都是让 B 组尽可能表现好的做法。唯一不做的让步是块与块之间不共享上下文。这是短上下文方案的本质约束允许共享就不是对照组了。前端把引用做成可点击的定位前端最花心思的是一件事每条矛盾的引用可以点击跳回原始文档并高亮。文本文档高亮对应段落扫描件则展示图片并把模型摘录的内容列在旁边供人工对照。这里有个细节值得说。扫描件是图像、没有可检索的文本层所以做不了原地高亮。前端的处理是明确告诉用户该引用由模型读图得出改为把摘录原样列出供人工对照印章、签名与手写日期并提供切换到同一份材料的文字版做定位高亮。诚实地暴露能力边界比假装能做到更重要。踩坑记录接口协议404 但错的不是路径网关走的是 Responses 协议不是通用的 Chat Completions。最初按后者调用POST /chat/completions → 404 {type:error,error:{type:api_error,message:not support}} GET /models → 404 同样的错误 POST /messages → 404 同样的错误所有路径返回同一个not support包括模型列表接口。报错完全不指向真正的原因——我一度以为是鉴权或者模型名不对。后来在另一个项目里看到client.responses.create的写法才反应过来是协议选错了。改成POST /responses一次就通。这类报错正确但毫无信息量的情况比报错错误更耗时间。Windows 下中文请求体会损坏不显式指定 utf-8 编码中文内容在传输层就坏了服务端返回的错误同样具有误导性。所有请求体强制 utf-8bodyjson.dumps(payload,ensure_asciiFalse).encode(utf-8)文件读写也一样全部显式encodingutf-8。公章得让模型看得清案卷里的扫描件是程序渲染的会议纪要那页的公章是关键考点章上写的是集团工会和用人单位对不上。第一版渲染出来两个问题环形文字的字头朝内正确的公章是字头朝外站在圆外面读是正的而且章直接压在落款文字上两层字叠一起谁也看不清。这种情况下模型识别不出章面内容视觉考点等于没埋。后来做了两处改动公章超采样绘制再缩放旋转后字口才锐利盖章用正片叠底代替普通覆盖。真实印泥本来就是半透明的压住的黑字仍然透得出来。字向的正确算法是图像坐标系 y 轴向下字符位置角deg满足(cos deg, sin deg)deg -90是正上方未旋转的字字头指向 -90 方向PIL 的rotate(a)逆时针为正在 y 向下的坐标系里会让方向角减小解-90 - a deg得旋转量a -(90 deg)。自检点正上方的字旋转量应为 0。改完之后章面 14 个字全部正立清晰考点才真正成立。埋点会跑偏所以写了个校验脚本案卷让模型按规格生成但生成的东西不一定精确落地。会议纪要第一版模型为了凑字数灌了一堆会议材料管理归档说明的废话而且把甲控股集团有限公司工会委员会这个全称在正文里重复了八次。矛盾点太扎眼模型一眼就能看出来评测就失去区分度了。真实的纪要应该简洁盖章主体错位只该出现在落款处。所以写了verify_case.py逐份检查每个必需字面是否出现、禁忌内容有没有混进去还有几条结构性校验比如集团全称在会议纪要中出现超过 1 次就告警。这个脚本救了好几次。它自己也出过错一开始我禁止员工手册 V2.0 全文出现第十九条结果它在第二章正常的条款编号里命中了。手册条款是全文连续编号的前面章节必然有第十九条真正该检查的是第十一章之后有没有。校验规则本身也需要被校验。最终 16 份全部通过效果对比之前这一列我没有可靠的人工计时数据所以拿切片方案模拟短上下文作对照人工那栏如实留白指标切片方案8000 tokens/块全量入模耗时跑完 4/6 块用了 22 分钟第 5 块中断557.72 秒9 分 18 秒输入 token未跑完无完整值59,214思考 / 输出 token未跑完19,588 / 30,033缓存命中未跑完54,272跨文档矛盾检出原理上无法发现跨块矛盾13 处引用可核查率未跑完41/42 97.6%人工基线未做计时实验不填—耗时那行值得看一眼切片跑 4 块就花了 22 分钟比全量入模跑完全程的 9 分 18 秒还慢一倍多。这跟直觉相反。大家默认切片是为了省钱省时间但在这个任务上同样的材料被读了六遍每块都要重新建立一次上下文。严格判分的结果判分跑了六条轨道因为「命中」本身有解释空间关键词匹配还是语义判定、要不要求引用完整、允不允许一条发现同时命中多个考点不同口径下能差出 20 个百分点。六条轨道的区间是 5/10 到 7/10全部留在结果文件里正文取最保守的那条总召回率 6/10 60% 跨文档召回率 4/8 50% 纯视觉召回率 1/2 50% 引用可核查率 41/42 97.6% 误报数 0取哪个数字都不算撒谎但我倾向于报低的那个。放宽标准很容易把召回率抬到 7/10 只需换一套判分规则可那个数字不解决任何问题。误报数是 0。三个干扰项没有一个被当作本案矛盾报出闰年衔接陷阱没上当社保基数年度调整没上当违约金条款那条被报出来了但模型自标最低严重级别按规则计入跑题而非误报。另有 5 条被归为额外发现。三条漏检M1 是真漏了漏的还是我认为最致命的一条培训签到表2023-03-15早于工会成立2024-01-10这个具体的时序倒挂。模型说了民主程序有问题也提到了工会纪要的瑕疵但没有把这两个日期并排指出来。M2 和 M5 性质不同是想到了但没说清楚。以 M5 为例模型明确指出纪要上盖的是集团工会的章、集团无权代行子公司工会职能判断完全正确但它引用的是工会备案回执和会议纪要没引劳动合同——而劳动合同才是证明用人单位是甲公司而非集团的那份。引用覆盖不达标严格口径下判不命中语义轨道下算命中。跑多轨道的意义就在这里。单一数字会掩盖掉没想到和想到了但没说清的区别这两件事对产品的意义完全不同。它自己找出来的东西13 条里有 5 条是我没预埋的其中两条值得单独说。第一条是路径错配。绩效考核不合格公司走的是严重违反规章制度的即时解除。模型指出这里有问题绩效不合格属于《劳动合同法》第四十条的不能胜任工作情形需要先经过培训或调整岗位而且要支付经济补偿套用第三十九条的严重违纪来即时解除是在规避补偿义务。这个角度我设计案卷时压根没想到。第二条是迟到次数按年度切分。考勤里有四次迟到公司据此主张多次迟到构成严重违纪。模型的反驳是这四次横跨 2023 和 2024 两个年度按年度分别统计各只有两次达不到 V3.2 手册规定的年度累计三次门槛也远达不到 V2.0 的十二次。要得出这个结论它得同时做三件事从两百多行考勤明细挑出四条迟到记录并读取日期分别翻到两个版本手册的量化门槛然后按自然年度切分统计。长上下文 vs 切片对照这个实验没跑完我如实说明。B 组的设计是同一批材料、同一套提示词、同一个模型只改变投喂方式切成约 8000 token 一块逐块分析后汇总块与块之间不共享上下文16 份材料被切成 6 块。实际跑到第 5 块时账户欠费中断没有完整的召回率数据只有前面那张表里的耗时记录。不过从分块边界已经能看出方向。M4工会征询函晚于解除通知需要同时看 D14 和 D15这两份恰好都落在第 5 块里切片组有机会发现但 M1 需要 D04、D06、D07M3 需要 D02、D03、D05、D14这些文档被切进了不同的块在原理上就不可能被发现。这只是推断我不打算凭它编一个数字出来。等能跑了再补。总结Qwen3.8-Max 在这个场景下的表现最突出的能力是把长上下文和多模态用在了同一个任务里。 59,214 token 的输入里同时有 16 份文本和 8 张图像模型不仅要在这么长的跨度上做交叉比对还要从图像里读出公章文字和签名数量。检出的 13 条矛盾中有一条同时引用了工会成立备案回执记载职工 83 人和会议纪要扫描件签到表只有 3 个手写签名指出参会人数畸少不具代表性。这两个数字一个在文本里、一个只在图像里。推理开销比我预期的低。 思考消耗 19,588 token输出 30,033 token思考量还不到输出的三分之二。我原以为时序推理会吃掉大量思考预算实际上没有。缓存命中 54,272 token 也说明重复投喂同一批材料时成本会显著下降这对需要反复调整提示词的开发阶段很友好。9 分 18 秒不快但对比对象要选对。 如果比另一个更快的模型这个耗时不占优势。可问题在于别的模型在这个任务上不是慢是做不了——材料切开之后跨文档矛盾就不在同一个视野里快也没用。而实测下来切片模式反而更慢同样的材料切成 6 块逐块分析跑完 4 块就用了 22 分钟。最需要注意的是它仍然会漏。 最严口径 6/10我埋得最深的那条时序倒挂没抓住另有两条虽然判断正确但引用不完整。这决定了产品形态它只能做首轮整理和建议输出的每条都要能回溯到原件最终判断留给人。提示词没有反复调。 第一版跑出来的结构就是可用的主要返工都花在接口协议和案卷生成上不在模型这一侧。当前局限单次分析 9 分钟不适合交互式追问目前只能做离线批处理逐份质证意见第三个产出在长输出下容易被截断需要拆成多次调用地区口径提示依赖模型的既有知识没有接实时判例库实际使用仍需人工核对本地裁判倾向案卷是虚构的教学素材真实案卷的扫描质量、倾斜程度、手写潦草程度都会更差复现指南环境Python 3.10、Node 18、Windows/macOS/Linux 均可依赖pip install fastapi uvicorn pillow pydantic前端npm install配置项目根目录.envMODEL_API_KEY你的 key MODEL_BASE_URLResponses 兼容端点 QWEN_MODELqwen3.8-max QWEN_REASONING_EFFORTxhigh完整流程python scripts/gen_structured.py# 生成结构化案卷固定随机种子python scripts/gen_docs.py# 生成叙述性案卷python scripts/verify_case.py# 校验埋点必须 16/16 通过python scripts/render_scans.py# 渲染扫描件python-mapp.services.analyze--modefull_context# A 组全量入模python-mapp.services.analyze--modechunked# B 组切片对照python eval/quick_score.py# 判召回率python-muvicorn app.main:app--port8000# 后端cdwebnpmrun dev# 前端 localhost:5174完整 PromptSystem Prompt 见上文另有审查清单REVIEW_CHECKLIST1,564 字、地区口径指引REGION_CAVEAT_GUIDE、三段输出 schema全部在app/services/prompts.py共 9,530 字符。注意事项案卷生成使用固定随机种子verify_case.py保证埋点未跑偏。任何人重跑都能得到同一份案卷和同一套答案这是评测可复现的前提data/answer_key.json是评测金标准绝不能进入分析引擎的上下文代码里也不能有硬编码的矛盾点前端有 MOCK / LIVE 双模式。后端未就绪时用 MOCK 内置示例数据也能完整演示后端有并发锁同时只允许一个分析任务。跑对照实验时用 CLI 而不是 API