客户本地可控的质量内审 AI 一体机
面向制造企业质量管理体系内审样板，把本地大模型、企业资料台账、权限过滤、来源引用、拒答规则、审计日志和标准问题验收串成一套可演示、可试用、可交付的产品方案。
这不是一张单页概念图，而是一套可拆给客户、内部管理和开发同事看的静态方案站。
首页负责讲清楚总体判断；下面这些页面分别展开产品界面、入口集成、智能体工作流、办公 Skill、技术架构、业务逻辑、安全权限、部署运维和实施路线，方便按角色阅读。
我们不是再做一个通用智能体平台，而是做客户本地可控的一体机样板。
UniverAI/AgentPay 这类现成平台已经覆盖数字员工、智能体、模型市场、应用市场和协作空间。我们的差异必须落在客户本地资料、权限、引用、审计和验收闭环上。
客户资料留在可控环境
优先面向客户现场或客户可控环境部署，本地大模型承担首批问答和内审辅助。
权限在检索前生效
无权资料不能进入召回结果和模型上下文，防止页面权限和模型上下文脱节。
回答必须带来源
不只显示“根据知识库”，而是指向文件、版本、程序编号、页码或片段。
用标准问题验收
用标准问题、标准答案、允许角色、严重等级和失败原因做断言式验收。
企业真正缺的不是会聊天的 AI，而是能安全进入资料和流程的 AI。
质量内审、整改、制度引用和责任确认属于高风险企业流程。普通知识库问答容易在版本、权限、引用和责任边界上失控。
资料版本不清
员工不知道哪份制度是当前有效版本，AI 如果引用旧文件会直接影响内审依据。
权限边界复杂
普通员工、内审员、部门负责人、体系管理员、管理层能看的资料范围不同。
回答不可追溯
如果只返回自然语言答案，无法判断系统引用了哪份文件、哪个版本和哪个片段。
高风险结论不能自动化
正式不符合项判定、整改责任和整改关闭必须由授权人员确认。
验收不能靠感觉
客户现场随便问几句不能证明系统可靠，必须用标准问题和标准答案做测试。
运维容易断档
资料更新、权限变更、索引失效、回答错误都需要可复盘和可修复。
现成平台可以作为候选底座，但不能在未验证前替代一体机方案。
我们实际看到了 UniverAI/AgentPay 的前台和后台：它有模型、智能体、知识库、应用市场、能力市场、空间市场和权限中心。这说明通用平台能力不是我们的护城河。
| 维度 | UniverAI/AgentPay 更像什么 | 自研 AI 一体机要解决什么 | 方案判断 |
|---|---|---|---|
| 产品定位 | 数字员工和智能体生态平台 | 客户本地企业 AI 治理与业务交付系统 | 差异明确 |
| 知识库 | 有知识库对象、文档数、个人/团队权限 | 资料台账、版本、授权、分片、引用、生命周期 | 需深化 |
| 权限 | 数字员工资源和能力调用授权 | 用户角色、知识域、文档、片段、上下文、导出多层过滤 | 核心差异 |
| 审计 | 调用量、成功率、员工绩效等运营统计 | 召回、过滤、上下文、引用、模型版本、拒答原因和测试结果 | 核心差异 |
| 交付 | 平台账号、市场开通、应用调试 | 一体机硬件、模型服务、资料治理、场景包、验收和运维 | 不同交付 |
产品不是单个聊天窗口，而是一套本地 AI 工作台和治理后台。
第一版不要做通用 AI 平台，先做制造企业质量内审样板。底层组件尽量复用成熟模型和工具，自研重点放在 Harness 控制层、权限审计、场景工作台和验收闭环。
员工工作台
面向普通员工、内审员和管理层，支持体系资料问答、检查清单、访谈问题、整改建议草稿。
资料治理台
管理文件来源、版本、授权、可引用状态、脱敏要求、入库状态和生命周期。
权限矩阵
按角色、部门、知识域、文档、片段和导出能力设置权限，检索前生效。
RAG 控制层
统一编排全文检索、向量检索、重排、上下文组装、引用校验和拒答策略。
审计与验收
记录问题、角色、召回片段、过滤片段、引用、模型版本、回答和测试结果。
运维后台
支持资料更新、权限复核、失败问题归因、备份恢复、日志归档和月度报告。
第一版产品应该长得像一个工作型企业工具，而不是通用聊天页面。
以下是基于方案直接绘制的产品界面样式图，表达页面结构、信息密度和关键控件。后续有豆包生图能力时，可再生成更精细的场景图或设备渲染图替换。
内部审核从计划到报告一般应经过哪些步骤？
正式结论需内审员或授权人员确认。
Local LLM · Rerank · 引用校验 · 高风险规则
六层架构：从用户入口到本地基础设施。
底层模型、向量库、解析器可以用成熟组件；真正要掌握的是 Harness 控制层、资料治理、权限过滤、审计验收和场景工作台。
完整闭环必须从资料授权开始，到验收和纠错结束。
普通知识库问答通常从上传文件开始。企业级一体机必须前置资料授权、版本和权限，并把回答结果纳入审计和验收。
第一阶段只做质量内审样板，不扩展成全公司 AI 平台。
当前最清楚、最可控、最能演示的切入点是 `样例程序文件.pdf` 和首批 24 道标准问题。
客户已确认
- `样例程序文件.pdf` 是当前有效版本。
- 资料可用于内部测试资料整理。
- AI 回答可展示来源引用样例。
- 公网展示已使用脱敏样例内容。
- 组织架构仅作为样例，不作为最终权限依据。
- 后续资料仍在收集。
当前演示验收包
- 已确认与待补充清单
- 资料台账草案
- 来源引用索引草案
- 拒答与人工确认规则草案
- 演示脚本重排草案
- 验收记录表草案
| 首批演示题 | 演示目的 | 必须证明 |
|---|---|---|
| QMS-SQ-012 | 内部审核流程问答 | 能引用 `QMS-CX-2025-22`，输出从计划到报告和整改验证的流程。 |
| QMS-SQ-008 | 采购流程检查清单 | 能引用 `QMS-CX-2025-19`，把制度要求转成检查项和证据要求。 |
| QMS-SQ-013 | 审核发现草稿 | 能整理事实，但提示正式不符合项必须人工确认。 |
| QMS-SQ-015 | 整改任务建议 | 能生成整改草稿，但责任、期限和关闭结论需授权确认。 |
| QMS-SQ-017 | 无资料拒答 | 没有质量目标达成率数据时不能编造数字。 |
| QMS-SQ-018 | 越权拒答 | 普通员工不能查看内审整改明细，无权片段不得进入上下文。 |
验收不是看 AI 聊得好不好，而是看它是否守住企业边界。
标准问题验收是我们区别于通用平台的重要能力。它让系统质量可以被记录、复盘、修复和复测。
有依据问题
回答必须符合标准答案要点，并能引用对应文件、页码或片段。
无资料问题
必须拒答或提示资料不足，不允许编造质量目标、指标或事实。
权限问题
无权用户不能看到无权资料，无权片段不得进入模型上下文。
高风险问题
正式不符合项、整改责任和整改关闭必须人工确认。
引用问题
不允许虚构文件名、条款号、页码或来源。
失败归因
失败要归因为资料缺失、解析错误、检索错误、权限错误、引用错误、模型错误或策略错误。
四阶段推进：方案样板先闭环，再交给开发落地。
当前明确：我们不是马上开发，开发由其他同事做。现在要交付的是能指导开发、演示和客户确认的完整产品方案。
P0 方案闭环
- 完整 HTML 方案
- 产品样式图
- 演示验收包
- 开发边界
P1 样板准备
- 资料台账
- 标准问题
- 来源索引
- 验收记录
P2 工程落地
- Web 工作台
- RAG 控制层
- 权限过滤
- 审计日志
P3 试用运维
- 小范围试用
- 失败修复
- 权限复核
- 月度报告
方案必须主动讲清楚不能做什么。
清晰边界能保护交付，也能让客户理解 AI 是辅助体系内审，而不是替代内审员和管理责任。
| 不能承诺 | 原因 | 正确说法 |
|---|---|---|
| 正式知识库已完成 | 当前仍是测试入库候选和样板准备 | 可做内部测试和演示准备 |
| 权限矩阵已定稿 | 组织架构图材料状态不特别准 | 先做角色草案，等准确组织架构后更新 |
| AI 自动判定不符合项 | 正式结论属于内审责任 | AI 输出事实、依据和风险草稿 |
| AI 自动关闭整改 | 整改验证需要证据和授权确认 | AI 生成整改建议和验证方式 |
| 全公司一次铺开 | 资料、权限、运维都未成熟 | 先做质量内审样板，再复制扩展 |
当前最重要的是让方案可看、可讲、可拆、可验。
这份 HTML 是对外和对内的总方案入口。后续可以从它拆出 PPT、PRD、开发任务、演示脚本和客户确认清单。
给客户
讲清楚现成平台和本地一体机差异，确认资料、权限、演示和验收边界。
给内部
统一方向：不复制通用平台，做本地可控、资料治理、权限审计和场景闭环。
给开发
拆出最小功能：资料台账、问答、引用、拒答、权限、审计、标准问题验收。