1.1 机审趋势：机器审核场景即将井喷
随着大模型能力的快速迭代和Agent搭建门槛的持续降低，我们正站在一个关键节点上：
| 趋势 | 现状 | 预判 |
|---|
| Agent搭建难度 | 指数级降低 | Workflow、Skills、Prompt等多种封装形式，让非技术人员也能快速搭建Agent |
| 机器审核场景 | 即将井喷 | 采购RT审核、合同审查、诉讼风险评估等场景，相比去年将倍增 |
| 评测能力 | 成为瓶颈 | Agent好不好用、稳不稳定，需要评测来验证 |
核心判断：未来接入一个Agent的难度会越来越低，但"如何做到好用"才是真正的竞争壁垒。评测能力，正是确保Agent"好用"的关键基础设施。
1.2 当前困境：评测能力成为AI落地的天花板
现有AI应用落地链路中，评测环节存在两大核心瓶颈：
迭代链路：场景挖掘 → 【经验萃取 ⚠️】→ 功能开发 → 【标注评测 ⚠️】→ 改进优化 → 上线
| 瓶颈 | 具体表现 | 影响 |
|---|
| 经验萃取端 | 强依赖业务专家时间，隐性判断逻辑难以结构化提取 | 每个机审项目需要1-2个月迭代 |
| 标注评测端 | 需要大量人工标注，标准随业务变化持续漂移 | 场景倍增背景下，现有速度难以跟上需求 |
这两个瓶颈不解决，中间的功能开发再快也无济于事。
1.3 信任困境：上线效果难验证
Agent想要推广上线，需要向业务同学证明其准确率。但现有评测存在信任问题：
| 问题 | 具体表现 |
|---|
| 离线数据 vs 线上真实 | 产研构建的评测集都是离线数据，无法完全打消业务质疑 |
| Benchmark滞后 | 评测基准需要跟随业务变化而变化，难以沉淀 |
| 人机信任缺失 | 业务方不敢放手让Agent上线，需要持续人工兜底 |
1.4 我们的解法：端到端智能评测平台
基于以上分析，我们需要构建一套端到端的智能评测平台，分阶段解决核心问题：
| 问题 | 解法 | 阶段落地 |
|---|
| 评测效率低 | 机审基线打通 + 流程全链路覆盖 | 第一阶段：6条基层流程全部跑通，具备线下+线上评测能力 |
| 能力水位分散 | 问答/对话评测扩展 + 报表功能补齐 | 第二阶段：问答场景评测覆盖，统一能力水位视图 |
| 上线信任缺失 | AI原生交互重构，降低使用门槛 | 第三阶段：Canvas+Chat双面板，对话驱动评测流程 |
2.1 总体定位
构建端到端的智能评测平台，专注于机器审核、流程审核、泛审核类、文本解析类及对话/问答类领域做到最好。优先服务开发者和基层业务场景（机审/ALE/对话Agent），逐步扩展到普通用户，实现"可用→好用→易用"的阶梯式演进。
不做通用平台，只在垂直领域深耕，致力于成为审核类、文本解析类及对话问答类领域的首选评测基础设施。
2.2 分阶段目标（S1 半年规划）
三阶段演进路线图
主题：机审基线全链路打通 + 扩域接入
核心任务：
- 机审基线6条流程全部跑通（3月31日前基线评测能力具备）
- 支持线下评测：手工导入用例 → 执行评测 → 标注打标 → 结果统计
- 支持线上提审评测：影子链路评测能力，人机结果比对
- 报表功能补齐：准确率统计、执行概况、趋势分析
- 归因分析能力补齐：效果评估与问题定位闭环
- 断言脚本健壮性提升：大模型评测能力引入
- 配置项前置枚举：域配置、业务场景预配置
- 4月中旬前完成扩域接入：将更多业务场景纳入评测范围
服务对象：开发者（能接受一定复杂度，但要求能力完整）
关键节点：3月31日前基线能力具备，4月中旬前完成扩域
主题：问答/对话评测能力建设 + 自动化评测
核心任务：
- 问答/对话场景评测能力建设：支持对话类Agent的评测（问答准确率、对话质量、意图识别准确率等）
- 自动化评测（线上化定期评测）：接入平台后自动开启定时评测、基于Benchmark或线上真实流量评测、对比人工与AI结果、定期生成报告并发送给负责人
- ALE/LA平台集成：ALE作为Skill体系中的原子能力接入
- 批量处理能力：大规模并发评测和自动化报告生成
- 全流程体验优化：基于第一月的用户反馈持续优化
服务对象：开发者和业务专家
主题：ALT内部AI原生改造
核心任务：
- Canvas+Chat双面板架构：Canvas可视化工作台为主（70%）、AI对话面板为辅（30%）
- 对话驱动评测流程：用户通过自然语言输入任务意图，AI自动完成接口生成、断言配置、用例推荐等技术细节
- AI辅助生成断言脚本：根据任务上下文和已解析用例自动生成，用户不用从零到一编写
- 轻量POC评测模式：极简评测入口，用例进去→关联机审服务→跑结果→快速标注→完成
- 设计原则：意图优先、零配置默认、渐进披露
- 用户旅程目标：压缩至3-5轮对话，10-15分钟内完成评测任务创建与执行
服务对象：全体平台技术部同学，进一步服务非技术背景的业务方
重要决策说明（Skill封装路线否决）
在规划第三阶段智能化路径时，曾讨论过将ALT操作包装为Skill供外部Agent平台调用的方案。经逐步推演发现：Skill封装并未减少任何操作步骤，仅改变了交互形态（"相当于有个人教你操作而已"），本质上不解决配置复杂和标注负担这两个核心痛点。
因此明确否决Skill封装路线，坚定采用ALT内部AI原生改造方向。
2.3 远期展望（S1 之后）
在机器审核、流程审核、泛审核类及文本解析类领域做到整个平台技术部最好，成为该领域的首选评测基础设施。
远期方向
- 评测服务化：ALT未来可能迁入更大平台，自身定位为评测能力提供方，对外提供标准化评测服务
- 配置自动化：如果计算服务原生集成到平台，配置复杂度将大幅降低，评测流程可进一步简化
- 垂直深耕：持续深耕垂直领域，不追求大而全，追求小而美且深
3.1 能力全景图
ALT端到端智能评测平台能力架构
3.2 三大核心环节 + 归因分析 详解
环节 1：ALE解析评测 🟡
- 定位：语义理解能力评测
- 现状：当前暂未重点投入，维持现有断言脚本机制
- 技术方案：工程脚本 vs 大模型/AI Agent方式争议，工程更稳定但大模型在语义理解上更优
- 后续规划：考虑 AI 增强方案，小范围试点验证；ALE未来将作为Skill体系中的原子能力，被集成到机审Agent/工作流中；ALE成为底层工具能力，评测维度随之调整
环节 2：机审评测 🔴
- 定位：用户搭建的机审 Agent/工作流体系评测（而非底层大模型本身）
- 评测对象：Workflow 编排的工作流、Skills 封装的技能包、Prompt 工程化的提示词体系、最终封装成可执行的 Agent
- 典型场景：合同审查 Agent、诉讼风险评估 Agent、无形资产评估 Agent
- ALT的作用：给用户提供测试集，验证用户搭建的 Agent 准不准、稳不稳定、哪里有问题
- 接入形式：支持多种封装形式的机审 Agent 灵活接入（Workflow、Skills、Prompt 等）
📌 评测策略核心原则
环节 3：对话/问答评测 🟡
- 定位：对话类Agent交互质量评测
- 评测对象：问答类Agent（问答准确率、意图识别准确率）、对话类Agent（对话质量、多轮交互连贯性）、智能客服/智能助手类场景
- 核心指标：问答准确率、对话质量、意图识别准确率、响应完整度
- 实施策略：第二阶段重点建设，复用机审评测的基础框架，扩展对话场景专属评测维度
归因分析 🟡
- 定位：效果评估与问题定位
- 缺失能力（需要优先建设）：按业务场景和整体业务域的准确率统计、历史趋势分析和波动监控、周期性评测结果的可视化展示、问题根因分析：是 prompt 问题、流程设计问题、还是数据质量问题
- 实施策略：优先开发核心报表，快速交付 MVP
📌 结果评测 vs 归因分析边界
注意：归因分析需要机审服务提供完整的调用过程数据
4.1 平台已有能力
核心功能模块
| 功能模块 | 具体能力 |
|---|
| 评测集管理 | 评测集的创建、编辑、删除、分类管理 |
| 用例管理 | 用例手工新增、批量导入（Excel）、用例共享策略配置 |
| 评测场景配置 | 评测服务配置、评测指标配置（ALE场景支持自动同步配置） |
| 评测任务管理 | 任务执行、执行历史查看、标注（当前仅支持ALE场景）、评测结果统计（当前仅支持ALE场景） |
ALE场景特色能力
- 支持自动同步ALE配置的文件类型及抽取要素，自动配置评测指标
- 基于ALE场景统一的评测指标自动计算结果
4.2 平台使用现状
接入情况
| 场景类型 | 接入状态 | 说明 |
|---|
| ALE场景 | ✅ 已接入 | 主要用于基线水位建立 |
| 机审场景 | ❌ 未接入 | 各业务场景评测打标差异较大，多围绕各场景自建工具进行评测 |
使用频率
- ALE场景：当前主要用于基线水位的建立，迭代优化的能力评测尚未充分使用
- 机审场景：暂未接入平台，依赖各业务自建工具
4.3 评测工作痛点
痛点一：打标&质检依赖人工，投入成本极高
典型案例：机审场景合同线上反馈链路数据评测
问题分析：线上反馈链路数据主要集中在预审结论维度的反馈，缺少下沉到规则维度的反馈，需依靠人工打标才能为后续优化提供输入
投入成本匡算（以线上反馈链路badcase优化为例）：
| 环节 | 参与人员 | 投入 | 具体内容 |
|---|
| 打标 | 产研+运营共11人 | 约12工作日 | 涉及模版推荐、实质性差异、条款规则、通用文本审查、表单一致性审查的打标 |
| 质检 | 产研+运营共5人 | 约8工作日 | 针对打标结果进行质检，对有问题的点做好记录方便review |
行业标杆参考（共性问题，已有成熟方案）：
| 标杆平台 | 核心能力 | 效果 |
|---|
| 阿里云 OpenJudge | 自动化评测框架，内置50+生产级评测器 | 提升质检效率，降低人工成本 |
| Dataloop | AI辅助标注 + 人机协同质检 | 标注效率提升5-10倍 |
| 中关村科金得助智能 | 全链路智能质检 | 降低漏检40%、人工成本30% |
技术路线
- AI辅助标注：预训练模型先做初标，人工只做校验
- LLM-as-Judge：用大模型评估输出质量，替代人工评测80%+场景
- 金标准样本：埋入已知答案的样本，自动检测标注质量
结论：此问题为行业共性问题，有成熟解决方案，建议纳入第一期建设重点攻克
痛点二：缺少统一视角的能力水位看板
- 各业务场景的水位分散维护，缺乏统一视图
- 无法快速了解整体评测能力和覆盖情况
痛点三：平台能力与业务需求存在差距
| 问题维度 | 具体表现 |
|---|
| 评测指标体系 | 仅ALE场景支持统一评测指标体系，机审场景（单据维度、规则维度）尚未抽取统一指标 |
| 打标&归因能力 | 平台能力缺失，极大依赖人工投入 |
| 管理视角看板 | 缺少数据看板视图，无法支撑管理决策 |
| 流程匹配 | 平台使用未与智能化项目各阶段评测流程匹配 |
痛点四：配置复杂度高，核心卡点难以短期解决
问题表现：指标配置和断言脚本编写门槛高、新用户上手困难，学习成本高
根本原因：计算服务未原生集成到平台，导致每个场景都需要独立配置、机审服务与评测平台之间存在耦合，配置项无法自动继承
| 时期 | 策略 | 目标 |
|---|
| 短期 | AI辅助生成断言脚本 | 降低从零到一的门槛，用户只需校验而非从头编写 |
| 长期 | 随计算服务原生集成 | 配置项将大幅减少甚至自动化 |
4.4 能力评估（0.1阶段）
| 维度 | 现状 | 问题 | 优先级 |
|---|
| 功能完整性 | 仅ALE场景可走完全流程 | 机审场景未接入，能力覆盖不足 | 🔴 High |
| 用户体验 | 流程复杂、操作繁琐 | 新人使用门槛高，需要多步骤才能完成任务 | 🔴 High |
| 用例管理 | 支持 Excel 导入 | 缺乏用例来源标识，流程不连贯 | 🟡 Medium |
| 调试能力 | 无单用例调试 | 调试体验差，问题定位困难 | 🟡 Medium |
| 报表功能 | 缺少完整报告 | 无法统计准确率、无趋势分析 | 🔴 High |
| 权限管理 | 分级权限过严 | 可能影响用户操作，需优化审批流程 | 🟢 Low |
| 打标&归因 | 能力缺失 | 极大依赖人工投入，影响持续评测 | 🔴 High |
| 管理看板 | 缺失 | 无法支撑管理决策 | 🔴 High |
4.5 用户反馈汇总
核心痛点（来自 3 场智启会讨论）
- "平台能力极度薄弱，业务方较为着急"
- "流程过于复杂，新人使用门槛高"
- "缺乏单个用例调试功能，调试体验差"
- "报告功能不完善，缺少执行通知机制"
改进期待
- 采用极简工作流，用户进入即可直接评测
- 配置项改为需要时再配置的模式
- 增加报表功能，提供整体情况概览
Canvas+Chat双面板架构布局（第三阶段目标）
5.1 S1 半年规划（三个月核心建设 + 三个月推广深化）
时间：2026-03-09 至 2026-09-09
模式：按月分主题推进，以周为迭代周期
S1 实施路径时间线
📅 第一个月：机审基线打通（3月 - 4月中旬）
时间：2026-03-09 至 2026-04-14
主题：机审基线全链路打通 + 扩域接入
已完成（截至 3月25日）
- 智启会 - 评测平台建设战略会 & 功能流程优化（定调+战术）
- 机审链路已打通：机审场景核心功能开发完成
- 影子链路已打通：线上提审评测能力具备
3月下旬 - 4月初：基线验收 + 能力补齐
- 机审基线6条流程全部跑通验收
- 断言脚本健壮性提升（大模型评测能力引入）
- 标注管理功能完善
- 报表功能补齐（准确率统计、执行概况、趋势分析）
- 归因分析能力补齐
4月初 - 4月中旬：扩域接入
- 将更多业务场景纳入评测范围
- 配置项前置枚举完善
- 用户动线优化验收
📅 第二个月：问答/对话评测扩展（4月中旬 - 5月中旬）
时间：2026-04-14 至 2026-05-12
主题：问答/对话评测能力建设 + 自动化评测
前两周：问答评测方案设计 + 核心开发
- 问答/对话场景评测需求调研与指标体系设计
- 问答评测核心功能开发与对话类Agent适配
- 问答评测技术方案评审
后两周：集成 + 自动化 + 验收
- ALE/LA平台集成（ALE作为Skill体系原子能力接入）
- 自动化评测能力（定时评测、自动报告生成与推送）
- 批量处理能力与全流程体验优化
- 第二阶段功能验收
📅 第三个月：AI原生交互重构（5月中旬 - 6月初）
时间：2026-05-12 至 2026-06-09
主题：ALT内部AI原生改造
前两周：方案设计 + 核心架构开发
- Canvas+Chat双面板架构设计与技术方案评审
- 对话驱动评测流程设计与核心开发
- 对话面板开发（自然语言输入→任务解析→AI自动完成配置）
后两周：能力完善 + 验收推广
- AI辅助生成断言脚本能力开发
- 轻量POC评测模式开发
- 用户旅程优化（目标：3-5轮对话，10-15分钟完成）
- 全体平台技术部同学试用与推广
- 第三阶段功能验收
5.2 关键里程碑
| 时间节点 | 里程碑 | 核心交付 |
|---|
| 3月底 | 机审基线能力具备 | 6条基线流程全部跑通，线下+线上评测能力可用 |
| 4月中旬 | 扩域接入完成 | 更多业务场景纳入，报表+归因分析闭环 |
| 5月中旬 | 问答/对话评测能力可用 | 问答场景覆盖，自动化定期评测上线 |
| 6月初 | AI原生改造完成 | Canvas+Chat双面板上线，轻量POC模式可用 |
6.1 分阶段量化目标
| 阶段 | 核心指标 | 验收标准 |
|---|
| 第一个月 | 机审基线能力 | 6条基线流程100%跑通，线下+线上评测能力具备 |
| 第二个月 | 问答评测能力 | 问答场景评测能力覆盖，自动化定期评测上线 |
| 第三个月 | AI原生交互 | AI原生交互上线，用户评测任务创建耗时降低60%+ |
6.2 S1整体目标
核心指标
- 场景覆盖：50+ 个机审场景（合同审查、诉讼风险、无形资产等）
- 用户规模：50+ 活跃开发者
- 能力完备：端到端链路完整，三大评测环节 + 归因分析全部可用（ALE解析评测、机审评测、对话/问答评测、归因分析）
- 自动化水平：支持定时自动评测，配置一次后无需手动干预
6.3 规模目标
- 服务用户数：50-100 人
- 并发能力：支持日常并发评测需求
6.4 场景目标
- 覆盖场景数：50+ 个业务场景
- 核心场景：合同审查、诉讼风险、无形资产等机审场景
7.1 核心阵型
双牵头人负责制，统筹产品、开发、业务三方协同：
项目组织架构
7.2 角色职责
| 角色 | 负责人 | 职责 |
|---|
| 项目牵头人 | 崖畔、月月 | 整体规划、资源协调、重大决策 |
| 产品经理 | 阿充 | 需求收口、优先级定义、产品方案设计 |
| 开发牵头人 | 庭森 | 技术方案、开发实施、团队管理 |
| 业务 PM | 铭勋 | 业务需求对接、兼职开发工作 |
8.1 运作模式
8.2 迭代机制
双周迭代制
- 迭代周期：每两周为一个迭代
- 需求收口：所有需求统一收口到产品经理（阿充）
- 优先级定义：由产品经理负责定义需求优先级
8.3 排期与进度同步
单双周错峰制
- 单周：周一上午进行排期会（定本周任务）
- 双周：周一上午进行进度会（过上周进展）
- 参会人员：全体项目成员
- 时长控制：1 小时内完成
8.4 需求管理
渐进明细原则
- 需求可以在迭代过程中逐步细化
- 优先保证核心功能交付
- 非关键细节可在开发过程中完善
风险矩阵图
9.1 高风险事项
风险 1：断言脚本健壮性提升不及预期 🔴
影响：大模型评测能力引入失败，断言准确率无法提升至 95%+
缓解措施：
- ✅ 小范围试点验证多种技术方案（工程脚本 + AI 混合）
- ✅ 设定明确的验收标准和止损点
- ✅ 控制投入预算，避免过度投入
责任人：技术负责人
风险 2：配置前置枚举不完整 🔴
影响：普通用户仍需手动配置，简化动线目标无法达成
缓解措施：
- ✅ 充分调研常见业务场景，整理完整枚举清单
- ✅ 建立管理员快速响应机制，及时补充缺失配置
- ✅ 提供用户反馈入口，持续完善预配置
责任人：产品负责人
9.2 中风险事项
风险 3：问答/对话评测技术方案不成熟 🟡
影响：问答场景评测指标难以量化，评测结果参考价值有限
缓解措施：
- ✅ 充分调研业界问答评测成熟方案（如BLEU、ROUGE、人工评分）
- ✅ 先做MVP验证，收集用户反馈后迭代
- ✅ 与问答类Agent团队紧密协作，明确评测需求
责任人：技术负责人
风险 4：AI原生改造用户接受度不确定 🟡
影响：Canvas+Chat双面板上线后，用户习惯迁移困难
缓解措施：
- ✅ 保留传统操作入口，提供渐进式迁移路径
- ✅ 提前与核心用户沟通，收集改造反馈
- ✅ 设计引导教程，降低学习成本
责任人：产品负责人
风险 5：配置复杂度短期难以根本解决 🟡
影响：AI辅助生成断言脚本效果有限，用户仍需大量手动配置
缓解措施：
- ✅ 短期：通过AI辅助降低从零到一的门槛，用户只需校验
- ✅ 中期：积累模板库，复用已有配置
- ✅ 长期：推动计算服务原生集成，从根本解决配置问题
责任人：架构团队负责人