LOCAL LLM REVIEW
HyApex ／ 本地 LLM 评审支持
数百页资料由机器通读，指摘是否成立由人判断。
机器逐件通读详细设计文档、源代码与测试用例，不做抽检。安排在夜间执行，第二天即可得到指摘候选。
工单系统与表格都不替换。判定的结果导出为一览，交回客户现在使用的流程。
评审停滞的结构性原因
评审受阻的问题无法靠增加人手解决。以下四种情形都曾在现场出现。
只有既懂业务领域、又清楚项目来历的人，才知道漏洞在哪里。因此，评审日程取决于这些人的时间安排。
详细设计文档数百页，代码数千行。人眼读不完，疲劳之后精度还会下降，实际上只能做抽检。
等待资深人员安排评审期间，整个工序停滞，测试收尾也随之延迟。
工单与表格分别记录，每天都要核对，确认停滞环节也需要额外工作。
从提出评审到关闭指摘的顺序
提出评审时只需指定三项。通读由机器完成，是否成立由人决定 —— 这一分工自始至终不变。
执行可以排到夜间。界面关闭之后处理仍在后台继续，第二天上午候选已经备齐。
判定的内容连同判定人、判定时刻，以及依据在原文中的位置（文件 → 工作表 → 区域）一并留存。
机器与人的分工
阅读由机器完成，判定由人负责；管理方式与运行环境按这一分工安排。
机器不受疲劳影响，可通读数百页资料，无需抽检。它会逐项找出分支遗漏、表述不一致，以及步骤与预期值的出入。
机器只产出候选。已处理、不适用、暂缓、未确认这四种状态由人选择，未经这一步就不算完成。候选附有依据与原文位置，判定时不必再回头翻资料。
从登记到确认完成，按五个固定状态追踪。增加状态会使管理再次分散，因此不允许增加。
列表显示各阶段的积压件数，条目的停滞状态会持续显示。判定结果导出为一览，交回既有流程，不替换工单系统或表格。
阅读和生成判断依据都由公司内部运行的模型完成。设计文档保持表格原样提交，代码直接取自公司内部的代码库。系统没有向外部服务发送这些设计文档或代码的路径。
我们已另行建好“本地私有化 LLM 应用平台”，用于在公司内部运行模型。阅读对象增多、同时使用的人数增加时，可以迁移到那套配置上运行。
结构上也能接入云端 AI，但目前以安全为先，只使用内网模型。是否接入云端 AI，按运行方针决定。
同一套读法，用在四个场景
资料格式保持不变，检查内容按评审场景调整。
可以按项目调整的四个方面
这四项各自独立，不必一次全部调整。
第一天确定实物设计文档与接入权限。第二天夜里通读全部，第三天由人用四种状态判定。第四天根据结果，决定是否扩大使用范围。
要看的是四点：指摘的关闭比例是否高于现状、重大遗漏有没有增加、判定依据与原文位置是否全件可追、机器通读一次能否在一夜之内完成。
其中任何一项不满足，都可以就此停下。数值只采用在客户自己环境中实测得到的结果。
仅凭 AI 无法判定评审完成。四种状态必须由人选择，系统不提供跳过人工判定的设置。
能省下多少工时，随环境与对象而变。资料中的走势是公司内部做的示例而非实测值，因此本页不作为数值列出。
目前只用在公司内部运行的模型。接入云端 AI 在设计上可行，但是否接入属于运行方针的问题；本页介绍的范围，到用内网模型运行的构成为止。
工单系统与表格不作替换。若希望把它们合并到一个工具里，那不在本方案的范围之内。
已经具备的能力，及其意义
已经具备的能力 → 它的意义
| 已经具备的能力 | 它的意义 |
|---|---|
| 通读全部 | 评审不再是抽检，资料越多差别越明显 |
| 执行可排到夜间 | 不必等资深人员空出时间，工序不会停在那里 |
| 只有人能按的四种状态 | AI 单独不能判为完成，是谁决定的留在记录里 |
| 依据与原文位置 | 判定时不必回头翻资料，事后也能复原经过 |
| 五个状态的追踪 | 列表显示各阶段的积压数量与停滞条目 |
| 带版本的评审着眼点 | 遗漏可以写回成规则，人员更替着眼点仍在 |
我们自研平台的功能规格（提案资料，截至 2026 年 9 月）。工时走势是公司内部做的示例而非实测值，故不列于此。
NEXT
咨询请联络相关负责人。
只要指定一个对象，我们就会展示对应的成果物及验证报告。
可以直接查看实际系统的输出，判断这套方式是否有效。
只需告知选定哪一个对象，即可开始。