一、自己 / 团队介绍
我是一名基层市场监管执法人员，就代码编程来讲，完全是门外汉。
市场监管横跨食品、药品、化妆品、医疗器械、特种设备、计量、认证认可、虚假宣传等不同领域，每个领域背后都是一套庞大的法规体系和专业知识，所以我们系统又被戏称为“宇宙局”，监管职责范围大如宇宙。基层执法的日常，是在这些领域里反复穿梭——遇到问题查资料、办案翻法规、裁量对基准、文书审合规。要想提高工作效率，就必须拥有足够的经验和知识储备。
半年前，我开始接触 Vibe Coding，我发现通过 Vibe Coding，能够弥补我软件开发能力的不足，我能够通过编程解决监管执法工作的实际痛点了，"试剑"就这样产生——以技术为剑，在执法实践中反复磨砺。
二、产品简介（复赛版）
2.1 是什么
“试剑” 是一款面向基层市场监管执法人员的微信小程序，集监管目录查询、法规检索、裁量基准查询、AI 辅助判定与文书审核于一体。产品以"让基层执法更高效"为核心理念，将原本需要翻阅大量文件、咨询专业人员才能完成的工作，浓缩到一部手机即可完成。
2.2 面向谁
- 核心用户：基层市场监管所执法人员
- 典型场景：
- 现场检查时快速查询监管对象分类目录、确认监管要求
- 案件办理时检索适用法规、查阅裁量基准
- 拍照判定产品是否属于 CCC 强制性认证范围
- 上传执法文书进行格式合规性、程序合法性、法律适用准确性审核
- 营养标签合规性校验（支持 GB 28050-2011 及 2025 新版标准）
- 现场检查记录的创建、拍照取证、地理定位、导出归档
2.3 完整功能清单
产品采用"工具 + 查询 + 资料"三大 TabBar 分区，共包含 40+ 页面，覆盖以下功能模块：
功能架构总览
| 模块分类 | 功能 | 说明 |
|---|---|---|
| AI 辅助分析 | CCC 强制性产品判定 | 拍照 → 豆包 OCR → 前置过滤 → 目录匹配 → 语义精筛 → AI 判定 → 追问/结论（属于/不属于/存疑） |
| 执法文书审核 | 上传处罚决定书/调查报告 → 四层架构（提取→结构化→程序计算+语义判断→合并报告）→ Markdown 审核报告 | |
| 营养标签校验 | 输入营养成分 → GB 28050 合规性校验（支持 2011/2025 双版本）→ 声称校验 → NRV 计算 | |
| 检查记录管理 | 现场检查记录 | 创建记录、拍照取证、GPS 定位、被检查实体信息采集、许可证信息、产品信息 |
| 记录查询与导出 | 分页查询、区域筛选、Excel 导出、统计分析 | |
| 区域权限管理 | 按区域绑定检查权限、用户权限 CRUD | |
| 监管目录查询 | 11 大类监管目录 | 食品、药品、化妆品、医疗器械、特种设备、计量、CCC 认证、广告、价格、知识产权、工业产品 |
| 法规与裁量 | 法规查询 | 128 部法规，支持排序与详情查看 |
| 通用裁量基准 | 281 条裁量基准，按法律/违法行为检索 | |
| 药品裁量基准 | 127 条药品专用裁量基准 | |
| 减轻处罚清单 | 468 条减轻/免罚清单，多维度搜索 | |
| 生产许可目录 | 567 条生产许可证 + 171 条许可条目 | |
| 实用工具 | 行政处罚时间计算器 | 基于工作日历（含法定节假日、农历）的期限计算 |
| 典型案例检索 | 历史案件搜索与详情查看 |
用户使用路径
打开小程序
├──【工具 Tab】
│ ├── CCC 判定 → 拍照/选图 → OCR 识别 → 追问确认 → 判定结果
│ ├── 文书审核 → 上传文书 → 等待审核 → 查看报告
│ ├── 营养标签 → 输入成分 → 校验 → 查看结果
│ ├── 检查记录 → 新建/查看/导出
│ ├── 时间计算器 → 选择日期 → 计算期限
│ └── 网页阅读器 → 输入网址 → 阅读内容
│
├──【查询 Tab】
│ ├── 监管目录 → 选择大类 → 列表 → 详情
│ ├── 法规查询 → 列表 → 详情
│ ├── 裁量基准 → 按法律/行为搜索
│ └── 案例检索 → 关键词搜索 → 详情
│
└──【资料 Tab】
├── 法规资料 → 分类浏览
├── 认证许可 → 目录查询
└── 行业领域 → 11 大类资料
2.4 相比初赛 Demo 的升级
从初赛 Demo 到复赛完整作品，完成了以下重大升级：
| 升级方向 | 初赛 Demo | 复赛成品 |
|---|---|---|
| 架构 | 外部 Python 服务 | 腾讯云 CloudBase 单服务架构，AI 工作流 TypeScript 本地执行 |
| AI 工作流 | Python FastAPI + LangGraph 外部服务 | 完全迁移到 NestJS 内，async/await + Promise.all 编排，零外部依赖 |
| CCC 判定 | 单阶段同步调用 | 六阶段流程（OCR→前置过滤→匹配→语义精筛→AI 判定→提问/结论），支持会话恢复 |
| 文书审核 | 基础 LLM 审核 | 四层架构（提取→结构化→程序计算 7 组并行 + LLM 语义 15 批并行→合并报告） |
| 数据库 | MySQL + Drizzle ORM | CloudBase NoSQL 文档数据库，42 个集合，2000+ 条数据 |
| 文件存储 | CloudBase 内置文件存储，简化凭证管理 | |
| AI 模型 | 仅 DeepSeek 文本模型 | 双模型路由：DeepSeek（文本/文书审核）+ 豆包（多模态/CCC 判定） |
| 营养标签 | 无 | 新增 GB 28050 合规校验，支持 2011/2025 双版本标准 |
| 页面数量 | ~15 页 | 40+ 页面，含主包 + 分包加载优化 |
| 开发规范 | 无 | 完整工程规范体系（9 份 standards 文档），ESLint 强制约束 |
三、产品演示视频
演示视频：四、产品创作历程
4.1 灵感来源
基层执法的一天往往这样度过：查处预包装食品，要逐行核对配料表是否违规；办理一个案件，要翻法规条文和裁量基准找到适用条款；现场检查，手写纸质记录；遇到 CCC 认证产品，打电话问专业人员。每一件事都不难，但加在一起，就是繁琐的一整天。
这些工作有一个共同特点：信息分散、要求固定、处理起来依赖经验。而经验，恰恰是最难复制的东西。如果一个老执法员脑子里积累的判断逻辑，能变成手机里随时可查的工具，对一线执法效率提升的可不只是一点点。
这就是"试剑"的起点。
4.2 关键问题与解决思路
从 Demo 到工具：专业知识如何变成代码
AI agent 把需求变成能跑的 demo 很快，但 demo 和工具之间隔着一道坎。最大的挑战不是让接口返回结果，而是让每一步判断都经得起法规条文和裁量基准的检验。
做法是像带新人一样教 agent：把真实案例讲给它听，把判断流程拆成可验证的步骤，写代码之前反复讨论逻辑细节。不赌 agent 的"理解力"，而是用明确的规则和测试用例约束输出——执法领域容不得"差不多"。
AI 工作流的调试黑盒
微信开发者工具只看得到输入和输出，中间的分析过程是黑盒。接口返回了错误结论，却不知道是哪个节点的推理出了问题。
引入 trace 追踪，记录每个节点的输入、输出和耗时；部署 Langfuse 做全链路可视化。AI 的每一步推理从此有了"案底"。
工程规范：从混乱到秩序
开发初期想到什么做什么，前端命名混乱、数据库结构不统一，代码量上来后人脑记不住。
借助 agent 梳理出 9 份 standards 文档，覆盖命名、接口、数据字典、错误处理、安全等维度，用 ESLint 做强制约束。规范不靠人记忆，靠工具兜底。
对话模式与代码模式的分工
初期所有工作——讨论方案、规划设计、写代码——都堆在代码模式里完成。方案讨论被打断，代码实现也被干扰。
后来按任务特点分了工：方案讨论和逻辑设计用对话模式，代码实现切到代码模式。各做各的事，互不干扰。
4.3 重要的设计与技术决策
双模型路由：文书审核是纯文本任务，要的是法律语义理解，走 DeepSeek；CCC 判定要先 OCR 再理解图片，要的是多模态能力，走豆包。两类任务对模型的要求完全不同，硬塞给一个模型，两边都做不好。通过 LlmClient 统一路由，按 model 前缀自动分发，调用方无感知。
工作流编排去外部依赖：CCC 判定和文书审核都是多阶段、有依赖关系的流程。没有引入 LangGraph 等外部库，而是用 TypeScript 的 async/await + Promise.all 直接编排——串行用 await，并行用 Promise.all，条件分流用 if-else。好处是消除了对外部 Python 服务的依赖，整个后端只有一个 NestJS 服务，部署和运维干净利落。
代码规则与 LLM 混合校验：专业领域的判断不能全交给 LLM，它会"幻觉"，且结果不可复现。文书审核的四层架构里，Layer 2 全部用纯代码实现——结构检查、期限计算、罚款区间、裁量匹配等 7 组校验并行，毫秒级完成，确定可靠；Layer 3 才调用 LLM 做语义判断——法律适用是否准确、裁量是否合理，15 批并行，8-15 秒。代码管"对不对"，LLM 管"合不合理"，边界清晰。
五、TRAE 实践过程
5.1 开发流程概述
本项目从架构设计到功能开发，全程使用 TRAE IDE 作为核心开发工具。以下是关键开发阶段：
| 阶段 | TRAE 辅助内容 | 产出 |
|---|---|---|
| 架构设计 | 通过对话描述需求，TRAE 协助生成架构方案和技术选型 | 单服务架构设计文档、数据库集合设计 |
| 前端开发 | 描述页面需求，TRAE 生成 Taro + React 组件代码 | 40+ 页面、shadcn/ui 组件库适配 |
| 后端开发 | 描述接口需求，TRAE 生成 NestJS Controller/Service | 26 个 Controller、数据库服务 |
| AI 工作流 | 描述工作流逻辑，TRAE 协助实现节点编排和各阶段逻辑 | CCC 判定六阶段流程、文书审核四层架构 |
| 数据迁移 | 描述迁移需求，TRAE 生成迁移脚本 | MySQL → NoSQL 迁移、Python → TypeScript 重写 |
| 工程规范 | 描述规范要求，TRAE 生成规范文档和 ESLint 规则 | 9 份 standards 文档、ESLint 配置 |
5.2 关键开发步骤
步骤一：项目初始化与架构设计
使用 TRAE 描述项目需求，生成了完整的项目架构方案：
- 技术栈选型：Taro 4.1.9 + React 18 + Tailwind CSS 4（前端）、NestJS 10 + CloudBase（后端）
- 数据库设计：42 个 NoSQL 集合，覆盖监管目录、法规裁量、检查记录等
- 部署方案：CloudBase CloudRun 单服务部署
TRAE 对话 - 架构设计阶段
步骤二：CCC 判定工作流开发
向 TRAE 详细描述了 CCC 判定的业务逻辑——从拍照到给出结论，中间要经过 OCR 识别、前置过滤、目录匹配、语义精筛、AI 判定，存疑时还要追问用户。TRAE 协助实现了六阶段流程：
- 阶段一：豆包多模态 OCR，提取产品名称、型号、铭牌信息
- 阶段二：纯代码前置过滤（R1-R3 规则），车载产品、再制造产品直接排除
- 阶段三：关键词匹配 + 路径 A/B 双策略，生成候选集
- 阶段三.五：LLM 语义精筛，剔除关键词匹配的歧义候选
- 阶段四：DeepSeek 逐候选语义判定，输出通过/不通过/存疑
- 阶段五：存疑项生成追问（最多 3 个问题），用户回答后重新判定
- 阶段六：合并结果，构建结构化结论
TRAE 对话 - CCC 判定工作流实现
步骤三：文书审核工作流开发
向 TRAE 描述了文书审核的四层架构和各层的依赖关系。核心设计思路是"代码能判的不交给 LLM"——格式、期限、金额这些有明确规则的检查用纯代码，法律适用、裁量合理性这些需要语义理解的才交给 LLM。TRAE 协助实现了各层逻辑：
- Layer 0：文本提取（支持 .doc/.docx/.pdf），0 次 LLM 调用
- Layer 1：结构化提取（1 次 LLM），从非结构化文书中抽出当事人信息、违法事实、处罚依据等字段
- Layer 2：程序计算（7 组并行，0 次 LLM）——派生字段、结构检查、当事人信息、期限计算（含农历/节假日）、听证范围、罚款区间、裁量匹配
- Layer 3：LLM 语义判断（15 批全部并行），覆盖法律适用准确性、裁量合理性、文书结构完整性等
- Layer 4：合并报告，生成 Markdown 审核报告，按 Critical/Major/Minor 分级
TRAE 对话 - 文书审核工作流实现
步骤四：营养标签校验模块开发
向 TRAE 描述了 GB 28050 标准的校验规则（NRV 计算、声称校验、0 阈值、豁免食品、糖醇能量换算等），TRAE 协助实现了完整的校验逻辑：
- 营养成分数据结构（2011/2025 双版本）
- NRV% 计算与 0 阈值处理
- 声称互斥校验（含有/富含）
- 维生素/矿物质"多种"声称泛化处理
- 豁免食品判断与提示语校验
TRAE 对话 - 营养标签校验实现
5.3 TRAE Session ID
以下为关键开发任务的 TRAE 对话 Session ID：
- Session ID 1：重构计划实施：2081795051365804:ddcdf0553e7ddfd824b5cd3715fe6867_6a5331256aa8a6d1a6059cc5.6a5331266aa8a6d1a6059cc8.6a5331256aa8a6d1a6059cc6:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/12 14:16:06)
- Session ID 2：MCP配置cloudbase：2081795051365804:ae114af4db8669685789e3242f2f1088_6a5331256aa8a6d1a6059cc5.6a546141f1891b3dcbc87a58.6a546141f1891b3dcbc87a56:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/13 11:53:37)
- Session ID 3：文书审核：2081795051365804:f5543e6eb521ba184995535ba0116b40_6a59ccb9c9085684ae7d9089.6a59ccb9c9085684ae7d908c.6a59ccb9c9085684ae7d908a:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/17 14:33:29)
- Session ID 4：UI重新设计：2081795051365804:5779f34b29bea0aee8b3786312d05895_6a69871ae35a47e870385235.6a69871ae35a47e870385238.6a69871ae35a47e870385236:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/29 12:52:42)
- Session ID 5：CCC判定：2081795051365804:43cb8f336060a200bae7133d02372973_6a63251c06ea03938a750114.6a63251c06ea03938a750117.6a63251c06ea03938a750115:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/24 16:41:00)
- Session ID 6：引入langfuse：2081795051365804:1d9ac18a8bcf9b380dec38926ef1f5aa_6a6a9da95657e42f9d14a644.6a6a9da95657e42f9d14a647.6a6a9da95657e42f9d14a645:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/30 08:41:13)
- Session ID 7：上线调试：2081795051365804:2d17be07f9e4aa7a906b99c1afd8bb7c_6a6c13525657e42f9d14ba15.6a6c13525657e42f9d14ba18.6a6c13525657e42f9d14ba16:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/31 11:15:30)
六、技术方案分享
6.1 技术栈
| 层级 | 技术 | 版本 | 选型理由 |
|---|---|---|---|
| 前端框架 | Taro | 4.1.9 | 跨端开发，支持微信小程序 + H5 |
| 前端 UI | React | 18 | 组件化开发，生态成熟 |
| 前端样式 | Tailwind CSS | 4 | 原子化 CSS，配合 weapp-tailwindcss 适配小程序 |
| 前端状态 | Zustand | 5 | 轻量状态管理 |
| 后端框架 | NestJS | 10 | 模块化架构，依赖注入，TypeScript 原生支持 |
| 后端语言 | TypeScript | 5.7 | 类型安全，与前端共享类型定义 |
| 云服务 | CloudBase | - | NoSQL + 文件存储 + CloudRun 一体化，免运维 |
| AI（文本） | DeepSeek API | deepseek-v4-pro | 文书审核，法律语义理解 |
| AI（多模态） | 豆包 API | doubao-seed-2-0-mini | CCC 判定，OCR + 图片理解 |
| 包管理 | pnpm / npm | - | 前端 pnpm，后端 npm（与 CloudRun 构建环境一致） |
6.2 系统架构
┌─────────────────────────────────────────────────────┐
│ 前端：Taro 微信小程序（40+ 页面） │
│ 主包：工具/查询/资料三大 TabBar │
│ 分包：详情页、检查记录 │
└──────────────────────┬──────────────────────────────┘
│ HTTPS
┌──────────────────────▼──────────────────────────────┐
│ CloudBase CloudRun │
│ ┌──────────────────────────────────────────────┐ │
│ │ server (NestJS + TypeScript) Port 3000 │ │
│ │ ├─ 27 个 Controller（业务 API 网关） │ │
│ │ ├─ workflows/ccc-judgment/ CCC 判定工作流 │ │
│ │ │ └─ 六阶段流程 + 会话恢复 │ │
│ │ ├─ workflows/checkreport-v3/ 文书审核工作流 │ │
│ │ │ └─ 四层架构（L0提取→L1结构化→L2程序+ │ │
│ │ │ L3语义→L4合并） │ │
│ │ └─ llm-client.ts 双模型路由客户端 │ │
│ └────────────────────┬─────────────────────────┘ │
│ ┌────────────────────▼─────────────────────────┐ │
│ │ CloudBase 数据层 │ │
│ │ ├─ NoSQL 文档数据库（42 个集合，2000+ 条） │ │
│ │ └─ 内置文件存储（照片、导出文件） │ │
│ └──────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
│
┌──────────────┼──────────────┬─────────────┐
▼ ▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌────────────┐ ┌──────────┐
│ DeepSeek │ │ 豆包 │ │ 腾讯地图 API │ │ 微信 API │
│ 文本模型 │ │多模态模型│ │ 地理编码 │ │ 小程序登录│
│ 文书审核 │ │ CCC 判定 │ │ 现场定位 │ │ 身份验证 │
└──────────┘ └──────────┘ └────────────┘ └──────────┘
6.3 AI 工作流核心设计
双模型路由
LlmClient 统一封装 DeepSeek 和豆包两个后端，按 model 名称前缀自动路由：doubao* 走豆包（火山引擎方舟），其他走 DeepSeek。两者均兼容 OpenAI SDK 接口，调用方无感知。内置 5xx 自动重试（最多 2 次）和 Langfuse 调用上报。
CCC 判定六阶段流程
阶段一：豆包多模态 OCR → 提取产品名称、型号、铭牌信息
↓
阶段二：纯代码前置过滤（R1-R3）
│ R1：图片中无人/物 → 直接输出"否"
│ R2：车载产品 → 直接排除
│ R3：再制造产品 → 直接排除
↓
阶段三：关键词匹配（路径 A/B 双策略）→ 生成候选集
↓
阶段三.五：LLM 语义精筛 → 剔除关键词匹配的歧义候选
↓
阶段四：DeepSeek 逐候选语义判定 → 通过/不通过/存疑
↓
阶段五：存疑项 → 生成追问（最多 3 个问题）
↓ （用户回答后，仅对存疑候选重新执行阶段四）
阶段六：合并结果 → 结构化结论（属于/不属于/存疑）
一轮提问原则：用户回答后不再生成新问题，直接输出最终结论。工作流状态持久化到 NoSQL，支持会话恢复。
文书审核四层架构
Layer 0：文本提取（.doc/.docx/.pdf → 纯文本） 0 次 LLM
↓
Layer 1：结构化提取（1 次 LLM，5-8s）
│ 从非结构化文书中抽出当事人信息、违法事实、
│ 处罚依据、裁量情节等结构化字段
↓
Layer 2：程序计算（7 组并行，0 次 LLM，毫秒级）
├─ 派生字段（罚款金额、听证范围等）
├─ 结构检查（7 项法定内容完整性）
├─ 当事人信息校验
├─ 期限计算（含农历/法定节假日工作日历）
├─ 听证范围判断
├─ 罚款区间校验（对接裁量基准库）
└─ 裁量匹配（不予/减轻处罚清单查询）
↓
Layer 3：LLM 语义判断（15 批全部并行，8-15s）
│ 法律适用准确性、裁量合理性、文书结构完整性、
│ 案情描述一致性等语义维度
↓
Layer 4：合并报告 → Markdown 审核报告
│ 按 Critical/Major/Minor 三级分类
│ 附裁量基准命中信息和清单命中提醒
核心设计原则：代码管"对不对"（格式、期限、金额有明确规则），LLM 管"合不合理"（法律适用、裁量合理性需要语义理解）。Layer 2 全部用纯代码实现，确定可靠且毫秒级完成；Layer 3 才调用 LLM，15 批并行将总耗时控制在 8-15 秒。
6.4 工程规范体系
建立了完整的开发规范体系，包含 9 份 standards 文档：
| 文档 | 覆盖内容 |
|---|---|
| ui-design.md | 主题色、字体、间距、卡片结构、页面布局 |
| data-dictionary.md | 42 个 NoSQL 集合的字段结构与查询约束 |
| api-conventions.md | 响应格式、code 约定、分页、异步任务 API |
| error-handling.md | 异常类型、日志规范、Service/Controller 分层 |
| naming-conventions.md | 文件、变量、函数、集合、路由命名规则 |
| components.md | 通用组件清单、shadcn/ui 使用原则、复用优先级 |
| security.md | 鉴权、输入校验、文件上传、NoSQL 注入防护 |
| performance.md | 包体积、首屏加载、接口 SLA、数据库查询 |
| git.md | 分支管理、commit message、部署流程 |
ESLint 强制约束：禁止直接使用 process.env、Taro.request，禁止定义重复 Network，禁止微信小程序不兼容的 Tailwind 语法。
七、社会价值分析
7.1 解决的工作痛点
基层市场监管执法长期面临三个问题：
依据难找。 市场监管横跨食品、药品、化妆品、医疗器械、特种设备、计量、CCC 认证等 11 个领域，法规条文、裁量基准、目录清单分散在不同文件中。现场执法时，查一个 CCC 认证目录可能要翻几本手册，找一个裁量基准可能要打开三四个文档。"试剑"把 127 部法规、281 条通用裁量基准、127 条药品裁量基准、468 条减轻处罚清单、567 条生产许可目录全部装进手机，一键检索。
经验难传。 一个老执法员积累了十年的判断经验——什么产品需要查什么、什么行为对应什么处罚——这些经验存在脑子里，新人只能靠跟班学习慢慢啃。AI 辅助判定和文书审核把部分经验固化成了可复用的流程：CCC 判定按六阶段逻辑走完，文书审核按四层架构跑完，每一步的判断依据、推理过程、中间结果都有 trace 记录，结论可追溯、可复盘。
文书难审。 执法文书的格式合规、程序合法、法律适用准确、裁量合理，每一项都有明确的规范要求，但人工审核耗时且容易遗漏。文书审核工作流把格式和程序检查交给代码，把语义判断交给 LLM，一份文书的审核时间极致压缩。审核报告按 Critical/Major/Minor 三级分类问题，并附裁量基准命中信息和不予/减轻处罚清单命中提醒，提示人工复核。
7.2 社会效益
市场监管是维护市场秩序的第一道防线。基层市场监管执法人员的工作效率和执法规范程度，直接关系到经营主体的合法权益和消费者的安全。
"试剑"的价值不在于替代执法人员的判断，而在于把重复性、查找性的工作自动化，让执法人员把精力集中在真正需要专业判断的环节。具体来说：
- 文书审核发现一个程序瑕疵——比如听证告知遗漏、期限计算错误——可能避免一起行政复议或行政诉讼
- CCC 判定把一个需要电话咨询专业人员、等待半小时才能确认的问题，压缩到一两分钟内给出初步结论
- 营养标签校验把 GB 28050 标准中复杂的 NRV 计算、声称阈值、0 阈值转换等规则固化成代码，避免了人工计算可能出现的疏漏
- 检查记录从纸质手写变成手机端录入、拍照取证、GPS 定位、Excel 导出，现场检查的归档效率提升显著
7.3 可拓展性
产品采用"工具 + 查询 + 资料"三分区架构，工具模块可插拔，新增模块不需要改动整体架构。AI 工作流的设计也是模块化的——新增一个判定流程，只需编写新的节点函数，不影响已有工作流。
数据层覆盖 11 大类监管目录、42 个 NoSQL 集合，结构统一，新增一个领域的目录只需按照既有 schema 导入数据，前端页面模板自动适配。
八、产品迭代规划
短期（复赛后）
- AI 工作流调优：收集实际使用中的误判案例，优化 CCC 判定的语义精筛 Prompt 和文书审核的 Layer 3 语义判断 Prompt，提升准确率
- 用户反馈闭环：在判定结果和审核报告页面增加反馈入口，用户可标记"判定有误"或"审核遗漏"，反馈数据用于迭代规则和 Prompt
- 运行监控：完善 Langfuse 全链路追踪的告警机制，对 LLM 调用超时、格式异常、成本异常等自动预警
- 数据更新：法规库跟进最新发布和废止信息，裁量基准跟进各省最新版裁量规定
中期（3-6 个月）
- 权力清单查询：对接市场监管领域权力事项目录，明确"能做什么、不能做什么"的边界
- 专项整治模板：针对常见专项整治（如网络餐饮、特种设备隐患排查）预制检查模板，一键生成检查记录
- 知识问答：基于现有法规和裁量数据构建 RAG 问答，执法人员可直接用自然语言提问
- 多省份裁量覆盖：当前裁量基准和减轻处罚清单以部分省份为主，逐步扩展至更多省份
长期（6 个月以上）
- 官方数据对接：对接国家企业信用信息公示系统、全国标准信息公共服务平台等官方 API，实现数据实时同步
- 执法经验积累：将用户反馈和实际案例沉淀为知识库，AI 工作流可参考历史判例优化判定逻辑
- 跨部门协同：探索与综合行政执法、应急管理等部门的数据共享和流程协同