唯易科技产品服务

企业智能文档服务

## 将一次性的 AI 文档问答，变成可配置、可重复、可追溯的文档作业

企业文档工作中最消耗专业人员的，往往不是判断一个复杂问题，而是日复一日地翻制度、对清单、找原文、查漏项，再把结论整理成一份能够交付和复核的意见。

合同审查、申报材料核验、证照附件比对、投标文件符合性检查——每一类文档工作背后都有一套制度、模板和业务经验。但这些规则通常散落在文件里、在人的记忆里。材料换一批、人员换一个，检查深度和输出口径就可能变化。

我们做的不是又一个"文档 AI 问答"，而是一个规则驱动的文档作业平台：把企业自己的制度、模板和经验配置为可执行的检查作业，AI 按要求逐项执行，每一条结果都关联原文和规则来源，留给专业人员复核和确认。

产品定位

规则驱动的 AI 文档作业平台。不是让 AI 临时回答一个文档问题，而是让它稳定完成一项文档工作。

系统将企业的制度、模板和业务规则显式化为可配置的检查作业。AI 负责材料理解、字段提取、逐项比对和异常标记；专业人员负责复核、修正和最终判断。每次执行的结果都可追溯——每一项结论都尽量关联原文片段、规则出处和中间执行记录。

材料接入→文档理解→作业执行→证据定位→结果交付→人工复核→规则沉淀

## 六类文档作业产品抽象的不是"文档类型"——合同、申报书、证照、标书这些会不断增加——而是稳定的"文档作业"。

content_paste_search

信息提取

从材料中找到关键内容并结构化输出：合同字段、证照信息、申报数据、表格内容。

checklist

完整性核验

应交材料是否齐全、必填字段是否缺失、附件是否匹配。适合申报附件、投标文件、验收材料。

compare_arrows

一致性比对

多份材料之间是否相互矛盾——主体名称、金额、日期、编号是否一致。跨文档交叉检查。

rule

规则审查

对照制度、模板或业务标准逐条检查。合同条款合规性、申报材料符合性、制度文件对标检查。

difference

差异比较

同一文件的不同版本之间发生了什么变化。合同版本、制度修订、申报材料修改前后对比。

summarize

内容整理与生成

根据材料形成标准化交付物：风险清单、补正意见、核对报告、结构化台账、摘要说明。

设计原则

**不是临时问答，而是可重复执行的作业**。用户不是每次重新写提示词，而是配置一次规则和检查清单，以后对同类材料持续执行。规则在复核中不断修正和积累。 **不是只生成结论，而是保留依据**。每一项输出都尽量关联原文片段、命中的规则条目、以及中间执行记录。复核者不需要猜测 AI 为什么得出这个结论。 **不是只处理单份文档，而是处理一组业务材料**。很多真实工作并不只是"读一份 PDF"，而是核对申报书、预算表、合作协议、证照附件和系统数据之间的关系。 ## 两层产品架构 ### 底层：通用文档作业平台负责统一的基础能力，不绑定具体业务场景：

Word / PDF / 图片 / 表格接入OCR 与版面识别字段提取与文档分类规则配置与作业编排多文档关联与交叉核验原文定位与来源引用结构化结果输出人工复核与执行记录规则、材料与结果版本管理

### 上层：可配置的场景作业包底层能力是通用的，但客户购买和试点的是一个具体的作业包。每个作业包包含：检查规则、输出模板、试跑样本和评估标准。 | 作业场景 | 输入材料 | 执行动作 | 输出结果 | |---|---|---|---| | **科研申报材料核验** | 申报书、预算表、合作协议、成果证明 | 完整性核验、跨附件比对、规则检查、签字盖章检查 | 补正清单、核验报告 | | **合同条款与风险审查** | 合同原文、制度文件、标准模板 | 条款提取、偏差检查、风险提示、权限审批触发线检查 | 风险清单、修改建议 | | **证照与附件核验** | 营业执照、资质证书、人员证明、场地证明 | 字段提取、有效期检查、证件编号格式校验、多附件交叉比对 | 异常清单、结构化台账 | | **投标文件符合性检查** | 招标文件、投标文件、附件清单 | 逐条响应检查、缺失项识别、矛盾条款检测 | 响应矩阵、缺失清单 | | **制度文件对标与修订** | 新旧制度、上级文件、参考标准 | 差异比较、条款映射、影响分析 | 对照表、修订建议 | | **档案分类与信息提取** | 大批量历史文件 | 分类、命名、信息提取、关联归档 | 文档目录、结构化数据 | | **项目验收材料检查** | 验收申请、技术报告、财务决算、附件 | 完整性核验、数据一致性、合规检查 | 验收审查清单、补正意见 | ## 核心工作机制 | 层 | 主要内容 | 设计目标 | |---|---|---| | 输入 | Word、PDF、图片、表格、证照附件 | 接入真实业务材料，保留原始文件 | | 配置 | 检查清单、审核规则、输出模板、风险等级 | 把企业自己的审核标准显式化、可维护 | | 执行 | 字段抽取、规则比对、跨附件核验、问题汇总 | 按步骤完成初筛，不跳过检查项 | | 输出 | 风险清单、修改建议、补正清单、审核报告 | 统一结果口径，减少人工整理时间 | | 治理 | 原文引用、规则来源、执行记录、人工复核 | 让文档处理过程可还原、可修正、可持续 | ## 两层审核模型企业文档审核不能只依赖通用知识。真正影响经营结果的风险，往往同时来自外部合规要求和企业自己的经营规则。 | 层级 | 核心问题 | 主要依据 | 典型输出 | |---|---|---|---| | **外部合规审核** | 是否触碰法律、监管、行业准入底线 | 法律法规、监管规则、通用规范 | 法律风险、合规风险、无效条款 | | **内部经营审核** | 是否符合企业自己的经营需求和管理制度 | 商业模式、项目经验、内部制度、风险偏好 | 付款风险、交付风险、验收风险、知识产权归属 | 很多合同并不违反法律，但付款节奏、验收标准、交付范围、知识产权归属可能明显不符合企业自身利益。两类规则分开管理，报告中明确风险依据属于哪一层。 ## 与常见方案的差异 | 方案类型 | 常见做法 | 本产品的侧重点 | |---|---|---| | 通用 AI 对话 | 根据提示生成回答，缺少企业审核规则和固定作业过程 | 基于客户规则逐项检查，输出可复核依据 | | 单点审查工具 | 聚焦某一类材料，规则与输出结构相对固定 | 可围绕不同材料配置检查清单、规则与报告模板 | | RAG 知识问答 | 重点是检索资料并回答问题 | 重点是执行检查流程、形成报告并保留过程记录 | | 定制软件项目 | 交付固定功能，后续规则变化依赖再次开发 | 将检查规则作为可持续维护和积累的业务资产 | ## 建设边界 AI 文档作业适合高频、有规则、可复核的初筛和辅助任务。以下责任不应交给模型直接承担：

替代专业人员签字或审批自动作出最终业务决定在没有依据时编造结论绕过业务系统权限读取材料把模型输出未经人工复核直接对外发送用一套通用规则覆盖所有材料类型

系统应明确给出"未找到依据"或"需要人工判断"，并保留材料版本、命中规则、原始输出和人工修改记录。涉及敏感资料时，还需落实部署环境、访问权限和数据保密要求。 ## 可以如何试点建议从 **1 类材料 + 10–30 条规则 + 1 个作业包**开始：

选定一类真实材料

提供一类真实业务样本（可先脱敏），不使用演示假数据。

整理首批检查规则

从制度、清单和高频错误中提取 10–30 条规则，定义输出模板。

执行一轮完整作业

输出风险清单、原文证据和结构化报告或核验结果。

人工对照评估

比较复核用时、漏项率和意见可用性，再决定是否扩展规则或增加材料类型。

试点周期约 2-4 周，输出核验样例与评估建议。试点不要求客户上系统，只要求客户给真实材料和反馈。

AI 知识问答与智能接待

## 这个产品是什么

企业和机构并不缺资料，真正的问题是客户与员工遇到问题时，仍然需要在多个页面、文件和人员之间反复寻找一个可信答案。

官网访客找不到适合自己的服务入口，员工不确定最新制度怎么执行，客服每天重复回答同类问题。普通聊天机器人可以把话说得流畅，却可能引用过期资料、混淆适用范围，也无法判断何时应该转交人工处理。

高频问题反复占用人工

客服、行政和业务骨干持续回答相似问题，真正需要判断的复杂事项反而被挤压。

资料版本多，回答口径不一致

制度、产品说明和办事指南分散，用户拿到的答案取决于问了谁、查了哪个版本。

问答结束后，没有形成下一步

外部咨询没有沉淀为线索，内部问题没有进入流程，机器人答不上时也缺少接管机制。

产品定位

AI 知识问答与智能接待不是让模型自由发挥，而是基于组织自己的资料、权限和服务流程，提供有来源、能分流、可转人工的问答入口。

系统先从可信资料中检索依据，再生成面向当前用户的回答；必要时继续追问、识别问题类型，并把咨询转交到对应人员或业务入口。回答找不到明确依据时，应如实提示进一步核实。

用户提问→问题识别→权限过滤→知识检索→带依据回答→分流 / 转人工

## 它解决什么问题

quick_reference_all

回答有来源

答案关联制度、产品说明或办事指南，用户可以回到原文核对。

update

版本可管理

知识内容保留来源、有效期和更新责任，减少过期资料继续被引用。

account_tree

问题可分类

识别咨询主题、用户意图和处理优先级，为后续分流提供结构化信息。

support_agent

人工可接管

遇到复杂、敏感或无明确依据的问题时，带着对话上下文转交人员。

person_search

线索可沉淀

在外部接待场景记录用户需求、来源与联系方式，供业务人员继续跟进。

lock

权限可控制

内部问答按用户身份过滤资料，避免通过自然语言绕过数据边界。

## 两类典型入口 | 入口类型 | 主要用户 | 重点能力 | 典型下一步 | |---|---|---|---| | 官网 / 公众号 / 客服 | 客户、访客、合作伙伴 | 服务介绍、需求识别、常见问题、线索收集 | 预约沟通、留下联系方式、转接业务人员 | | 内部制度与流程咨询 | 员工、管理者、业务人员 | 制度查询、流程解释、材料定位、权限内问答 | 打开原文、进入办事入口、咨询责任部门 | 两类入口可以复用问答与追溯能力，但知识范围、权限、语气和转人工路径应分别配置，不应混用同一套开放知识范围。 ## 适合什么客户 / 场景 - 官网、公众号和客服入口存在大量重复咨询 - 政策、制度、办事指南或产品资料相对稳定且查询频繁 - 希望回答显示来源，并明确找不到依据时的处理方式 - 需要把咨询分流、线索收集或内部办事入口连接起来 ## 建设边界

把所有文件直接上传后自动可用让模型回答没有依据的问题用公开入口查询内部敏感资料完全替代专业客服和责任部门自动承诺价格、交期或正式政策忽略知识版本和维护责任

问答质量首先取决于知识质量。过期、冲突和缺少责任人的资料需要在上线前梳理；涉及专业判断、交易承诺和正式政策解释时，系统应转人工确认。 ## 可以如何试点

选一个入口

先明确做外部接待还是内部制度问答，不同时覆盖所有渠道。

整理高频知识

接入一批稳定、常问、需要引用依据的 FAQ 与正式资料。

配置接管路径

明确哪些问题继续追问、转人工或进入具体业务入口。

评估真实对话

观察回答采纳、无依据问题、人工接管和线索有效性。

AI 流程作业助手

## 这个产品是什么把 AI 接入流程节点，在不替代最终审批的前提下，完成预判、预填和提醒。 ## 它解决什么问题 - 流程处理慢、人工重复输入多 - 分办不均导致积压 - 审核建议缺少标准化依据 ## 适合什么客户 / 场景适合受理分办、材料初审、进度提醒、流程协同场景。 ## 可以如何试点从单一流程切入，明确可自动化节点和人工确认节点，逐步扩大覆盖。

AI 数据分析与智能问数

## 这个产品是什么

管理者看到指标变化后，真正想知道的通常不是“这个月是多少”，而是“为什么变化、集中在哪、接下来还应该看什么”。

固定报表擅长展示已经定义好的指标，但临时追问、跨维度对比和异常解释往往仍要排队找数据人员。另一方面，如果收入、项目完成或有效客户等指标本身没有统一口径，AI 只会把不一致的数据包装成更流畅的结论。

看到结果，却无法继续追问

仪表盘展示了波动，但管理者难以快速下钻到区域、部门、客户或项目寻找原因。

临时分析依赖技术人员

每个新问题都需要重新写查询、导数据和整理表格，反馈周期跟不上管理节奏。

指标同名不同义，结果难信任

数据来源和统计范围不明确时，不同报表可能给出不同答案，AI 也无法自动判断谁正确。

产品定位

AI 数据分析不是替代 BI，也不是让模型凭常识猜数字，而是在统一指标、数据权限和可追溯来源之上，为业务人员补足自然语言查询与连续追问能力。

系统把问题转换为受控查询，在权限范围内读取结构化数据，并同步说明指标口径、筛选条件和数据来源。AI 可以帮助归纳现象和提出分析方向，但重要经营结论仍需结合业务事实确认。

自然语言提问→识别指标与维度→权限校验→执行受控查询→结果解释→来源追溯

## 它解决什么问题

chat

自然语言问数

业务人员用日常表达查询已治理的指标、时间范围和分析维度。

drill_down

连续下钻追问

从总体变化继续追问到部门、区域、项目或客户明细。

compare_arrows

对比与趋势

辅助完成同比、环比、分组对比和异常区间识别。

description

结果初步解释

基于查询结果归纳主要变化，并明确区分数据事实与分析建议。

data_object

口径随结果呈现

展示指标定义、筛选条件、时间范围和采用的数据版本。

verified_user

权限范围一致

沿用组织的数据权限，避免自然语言查询扩大可见范围。

## 与 BI 的关系 | 能力 | BI / 固定报表 | AI 数据分析 | |---|---|---| | 主要价值 | 稳定展示预先定义的指标与图表 | 围绕已治理指标进行临时查询和连续追问 | | 适合问题 | “当前经营状态是什么” | “为什么变化、集中在哪、还要看什么” | | 使用方式 | 看板、报表、筛选器 | 自然语言提问、下钻、对比与解释 | | 共同基础 | 统一指标、稳定数据源、数据权限 | 统一指标、稳定数据源、数据权限 | AI 问数通常建立在既有数据仓库、业务系统或指标平台之上。它不会替代数据治理和固定经营看板，而是降低非技术人员发起临时分析的门槛。 ## 适合什么客户 / 场景 - 已有管理看板或结构化业务数据，希望增加追问能力 - 指标定义相对稳定，但临时查询需求频繁 - 管理层、运营、科研或业务部门需要自助下钻分析 - 对查询权限、指标解释和数据来源追溯有明确要求 ## 建设边界

在指标口径未统一时直接问数让模型凭常识补齐缺失数据绕过数据权限查看明细把相关性直接解释成因果完全替代 BI 与固定报表未经业务确认输出经营结论

若基础数据更新不及时、关键字段缺失或不同系统无法对齐，应先解决数据问题。AI 可以提示异常和分析方向，但不能把数据缺口变成可靠事实。 ## 可以如何试点

选一组核心问题

收集管理者真实常问的问题，而不是先追求覆盖所有数据。

固定指标与数据源

明确定义、维度、更新周期、权限和权威来源。

跑通问数与追溯

验证查询、连续追问、口径解释和明细下钻。

对照人工结果

检查正确性、响应时间和业务采纳，再扩展更多指标。

科研管理与高校数据平台

## 一个平台，贯穿科研管理全周期

一个以项目为骨架、连接经费、成果、知识产权和组织权限的科研管理业务系统，已在多家研究型大学和国家级科研机构稳定运行多年。

它不是一套固定流程的标准软件，也不是大而全的"数字校园"平台。它聚焦科研管理的核心业务闭环——从项目申报到结题验收、从来款认领到拨款决算、从专利申请到用章审批——让科研处、院系、财务处和项目负责人在同一套数据上协作，而不是在多个系统和 Excel 之间搬运信息。

设计理念

以项目全生命周期为主线，通过可配置的流程引擎承接制度变化，通过统一数据口径连接多角色协作。

项目是骨架，经费是血液，审批流程是神经系统，成果是产出。平台不追求一次性覆盖所有模块，每个模块可以独立上线、按需组合，已有系统可以通过数据接口或阶段性导入方式协同。

项目申报→立项审批→预算编制→来款认领→拨款与经费卡→过程管理→成果与知产→结题验收→统计分析

## 平台能力结构 | 层级 | 主要能力 | 管理价值 | |---|---|---| | 业务流程层 | 表单、审批、待办、状态、权限与过程记录 | 承接科研项目和相关业务的日常运行 | | 数据中心层 | 项目、人员、经费、成果等主题数据 | 统一校院两级口径，减少重复汇总 | | 知识沉淀层 | 项目材料、制度文件、成果附件与历史记录 | 让科研过程资料能够持续查询和复用 | | 分析服务层 | 年度统计、专题分析、绩效数据与上级填报 | 从事后整理逐步转向过程治理 | ## 核心模块 ### 项目管理覆盖项目从申报到结题的全过程，支持纵向、横向、校级三类项目的差异化流程。 **申报与立项** 申报通知发布后，教师在线填报申请书（支持暂存和多次修改），提交后进入院级初审 → 校级复审的多级审批流程。审批通过后系统自动生成项目编号，将申报信息转为正式项目档案。支持预算编制、合作方信息维护、附件上传随流程流转。

发布通知→在线填报→院级初审→校级复审→立项建项→编号生成

**过程管理** 项目执行期间，负责人按年度或节点提交进展报告，院级和校级分别审核。平台记录每次报告的内容、审核意见和时间节点，形成完整的过程档案。项目发生信息变更（负责人变更、延期、预算调整等）时，提交变更申请走独立审批流程。 **结题验收** 项目到期后，负责人提交结题申请，按材料类型分类填报结题成果： | 成果类型 | 主要内容 | |---|---| | 论文成果 | 期刊论文、会议论文，关联项目和作者 | | 知识产权 | 专利、软著，与知识产权模块数据联动 | | 获奖成果 | 科研获奖，关联获奖等级和人员 | | 技术成果 | 技术报告、标准、样机等 | 结题材料提交后走院级和校级两级审核，审核通过后项目状态归档。支持结题材料的批量导出和打印。 **项目检索与导出** 多条件组合检索（项目来源、类别、状态、负责人、年份等），结果列表支持 Excel 导出。教师端可查看"我的项目"和"我参与的项目"两个维度。 ### 经费管理这是平台落地最深、与同类产品差异最大的模块。从银行来款到经费卡上账，形成完整闭环。 **拨款文件管理** 一笔科研经费到账后，首先创建拨款文件来"承接"这笔来款。拨款文件记录来款来源、到款金额、到款日期、经费来源类型（国家基金/省部级/横向/校级等）。文件余额实时计算：拨款总额减去已分配至各项目的拨款金额。一个拨款文件可以只拨给一个项目（单笔拨款），也可以分配给多个项目（统一拨款）。 **统一拨款** 在同一界面选择拨款文件下的多个目标项目，分别填写各自的拨款金额。系统按每个项目的类型自动匹配拨款模板，批量提交、批量生成拨款单。年底集中到款时，科研秘书不再逐个录入、逐条对账。

来款到账→创建拨款文件→选择 N 个项目→自动匹配模板→批量拨出→打印拨款单

**拨款模板与费用自动拆分** 系统内置覆盖 13 种项目类别（国家基金、省部级、校级、横向等）的拨款模板体系。创建拨款时自动匹配对应模板，将拨款金额拆分为多个费用科目：

印花税学校管理费学院统筹绩效支出劳务费 + 特支费增值税及附加发展基金风险基金

各科目支持按比例或固定金额两种方式配置。院级审核时，科研秘书可实时调整学院统筹费比例，系统自动重算全部分项金额和提成基数，不需要驳回重填。 **拨款审批与状态流转** 拨款申请提交后，走统一的多级审批流转： | 状态 | 说明 | 操作角色 | |---|---|---| | 暂存 | 草稿，可随时修改 | 教师 | | 待院审 | 已提交，等待院级审核 | 科研秘书 | | 待校审 | 院审通过，等待校级审核 | 校级管理员 | | 已初审待复核 | 校级初审通过，等待复核 | 校级管理员 | | 已复核完成 | 复核通过，拨款生效，经费卡生成 | 系统自动 | | 驳回 | 任一环节可驳回至发起人 | 审核角色 | **预借发票与销票联动** 预借发票模块与拨款模块数据联动。教师申请预借发票（选择发票内容、开票类型、付款单位、预计到款日期），走院级和校级审核。创建拨款时，系统自动列出该项目所有"已开具、未核销"的发票记录，勾选后提交。校级审核通过时，系统自动计算销票金额——拨款金额覆盖全部发票则全部核销，部分覆盖则按顺序逐票核销。不漏销、不重销。 **财务系统对接** 拨款审核完成后，平台将四类数据一次性推送到学校财务系统： | 推送数据 | 内容 | |---|---| | 拨款数据 | 拨款金额、费用科目拆分、提成基数 | | 项目信息 | 项目编号、名称、负责人、所属学院 | | 预算数据 | 预算编制表和子科目明细 | | 外拨经费 | 合作单位拨款信息 | 同时定时同步经费卡余额和预算执行数据。科研处看到的在途拨款、已上账金额和经费卡余额，与财务处是同一套数字。支持来款银行流水查询，可按流水号、日期范围搜索并匹配到对应项目。 **预算管理** 预算科目覆盖国家基金和科技部标准科目体系。支持预算编制（按模板新建或从项目信息继承）、预算调整（提交调整申请、走审批流程）和预算执行跟踪。 | 直接费用科目 | 间接费用科目 | |---|---| | 设备费、材料费、测试化验加工费 | 管理费 | | 燃料动力费、差旅费、会议费 | 绩效支出 | | 国际合作交流费、劳务费、专家咨询费 | 日常公用支出 | | 出版/文献/知识产权事务费、其他支出 | 其他补助 | **其他经费管理能力** - **补充拨款**：项目拨款后因追加经费需要再次拨款，走独立的补充拨款申请流程 - **结账管理**：项目结题或到期后，提交结账申请，选择可结账项目，走院/校审批后办理完毕 - **拨款单打印**：支持标准格式、天津市财政格式、预算格式等多种拨款单模板的批量打印 ### 知识产权与成果管理 **专利全生命周期** 覆盖专利从申请到放弃的全流程管理，状态可追踪、费用可记录。

提交申请→内部审核→代理事务所填表→递交知识产权局→受理/授权→费用跟踪→年费管理

支持专利信息的多条件检索和 Excel 导入导出，专利数据可导出为 Word 或 PDF 文档。 **代理事务所协作** 维护合作代理事务所的基本信息、代理人员信息，建立事务所与代理人的关联关系。支持事务所评分与评价记录。通过分享链接机制，外部代理事务所可登录系统在线填表和提交材料，实现内外协作——不需要反复发邮件、传文件。 **专利费用与法律状态** 记录每件专利的申请费、实审费、年费等费用明细，支持年费到期提醒，避免因遗忘缴费导致权利丧失。跟踪专利的法律状态（申请中、实质审查、授权、放弃等），状态变更自动记录审计日志。 **软著与获奖** 软件著作权登记与专利模块共享相同的数据管理框架。获奖管理记录获奖名称、等级、获奖日期、获奖人员等信息，支持按获奖级别和年份查询统计。 **成果关联** 专利、软著、论文、获奖与项目、人员、团队自动建立关联关系。结题时不需要临时收集成果数据——系统从各模块自动聚合该项目下的全部成果记录。 ### 成果基地管理面向高校与科研院所下设的重点实验室、工程中心、研究基地等科研平台，提供独立的信息管理、人员维护、年报评估和审批流程。 **成果基地信息与审批** 校级管理员创建成果基地档案后，科研秘书补充完善基本信息——包括中英文名称、批建部门与时间、验收时间、专业领域（多选）、依托学院与合作单位、研究方向、规章制度和批文附件。基地编号按日期自动生成。成果基地信息提交后走四级审批流程：

秘书提交→基地主任审核→学院审核→校级审核→基地建立

任一环节可驳回至待完善状态，审核意见全程记录在审计日志中。成果基地信息发生变更（名称、主任、委员会主席、研究方向调整、基地撤销等）时，提交变更申请走同样的审批流程，校级审核通过后自动更新档案。 **人员管理** 按三类人员分别维护： | 人员类型 | 内容 | |---|---| | 固定人员 | 基地主任、副主任、科研秘书、成员。对接学校人事系统，可 Excel 批量导入 | | 流动人员 | 访问学者、博士后、其他流动人员。校内外人员均可，外部人员手工录入完整信息 | | 学术技术委员会 | 主席（须为校外）、副主席、委员。新任主席/副主席上任时，前任自动降为委员 | 可在人员列表中按基地、角色、职称等条件检索，支持导出人员与基地的关联关系表。 **固定资产** 记录基地占地面积、固定资产总值、设备总值与数量（区分进口和国产）。以万元为单位，与项目经费和采购数据独立管理。 **年会与年报** 年会管理：记录召开年份、参会人员、时间地点、参会人数，可上传会议照片和纪要附件。年报管理：按年度记录批建报告、验收报告、评估报告、自评估报告、基地申请书、建设方案等多种类型，支持提交日期和备注。 **评估与导出** 记录历次评估的年份、日期、评分和等级（优秀/良好/合格/不合格），支持上传评估材料附件。支持将基地全部信息（基本信息、人员、固定资产、评估、年报、年会）导出为多 Sheet 的 Excel 工作簿。 ### 用章管理

提交申请→上传附件→院级审核→校级审核→现场盖章

用章申请全流程线上流转。申请人填写用章事由、上传附件材料，提交后走统一的院/校两级审批。审批进度通过微信实时推送，教师不再需要打电话催问。科研处可查看所有在途用章申请的排队情况。盖章完成后，系统生成盖章记录并支持追溯。支持盖章二维码生成，可通过微信扫码验证盖章信息。 ### 组织与权限 **六级角色体系** | 角色 | 典型权限 | |---|---| | 校级管理员 | 全部模块的管理权限、参数配置、字典维护 | | 科研秘书 | 本院系项目/经费/成果的审核与管理、通知发布 | | 教师/课题负责人 | 个人项目的申报、经费申请、成果登记、用章申请 | | 财务处 | 拨款审核、经费卡管理、财务数据对接 | | 院长/副院长 | 本院系数据的查看与审批、绩效数据查阅 | 支持一人多岗——同一位教师可能既是课题负责人、又担任某科研组的审批角色。角色切换无需重复登录，当前身份决定可见菜单和操作权限。 **科研组级权限** 科研组是最小权限单元。教师加入科研组后自动继承该组的菜单和审批权限，离开后自动回收。一个教师可属于多个科研组，在不同组内行使不同角色。组级权限与个人角色权限并行生效——用户的实际权限是其个人角色权限和所有所属科研组权限的并集。 **统一审批引擎** "暂存 → 提交 → 院级审核 → 校级审核 → 通过/驳回"这套审批流转覆盖项目、经费、用章、知识产权、结题等全部业务模块。审批节点可按组织层级和业务规则灵活配置。全流程审计日志记录每一次提交、审批、驳回、修改的操作人、时间、内容和结果，保证每一个决策有据可查。 **待办驱动** 首页按角色分流待办事项。教师首页展示待处理的申报、经费、用章等个人事务；科研秘书首页展示本院系待审核的项目、拨款和用章申请；校级管理员首页展示全校待处理的审核事项和异常提醒。点击待办直接跳转到对应的处理页面，不需要从菜单中逐层查找。 ### 数据分析与决策看板业务系统运行中沉淀的项目、经费、成果、人员数据，进入独立的数据分析与决策子系统，提供驾驶舱、预测、对比、报表和导出能力。它不是业务模块的附属功能，而是一个独立的子系统，对接业务数据库进行定时同步，面向科研处、校领导和院系管理者提供分析视角。 **决策驾驶舱** 首页提供全校科研运行的宏观总览，一次登录即可看到关键指标： - **KPI 总览卡片**：实到经费（亿元级，数字滚动动画）、合同经费、新立项数量、已授权专利数，附同比增幅 - **项目类型分布**：南丁格尔玫瑰图展示横向/纵向/应用项目的经费占比 - **学院经费排名**：词云图可视化各学院实到经费规模对比 - **经费预测曲线**：当前年度横向项目实到经费的月度累加曲线，叠加预测值和置信区间阴影带 - **客户地域分布**：中国地图展示横向项目委托方所在城市/省份的经费分布热力 - **重大项目排行榜**：年度大额项目按金额排序的明细表 ![决策驾驶舱首页](/assets/products/research-platform/analytics-dashboard.webp) **预测分析** 五条经费趋势曲线，每一条同时展示实际值、预测值、最大/最小置信区间三条线： 1. 横向项目实到经费月度累加曲线（当年） 2. 纵向项目实到经费月度累加曲线（当年） 3. 横向项目合同经费趋势（过去 4 年） 4. 未来 3 年横向合同经费预测 5. 未来 3 年纵向合同经费预测预测模型基于历史数据训练，置信区间帮助管理者判断经费趋势的确定性，辅助年度预算编制和资源分配决策。 **多维检索与下钻** 一个高级检索页面，提供 17 个筛选维度组合查询全校项目：项目名称、编号、类别（级联树多选）、状态（14 种多选）、级别、负责人（搜索+筛选）、委托方（模糊搜索）、合作方、经费卡号、合同金额下限、日期范围等。查询结果表格可按项目名称下钻到项目详情、按委托方名称下钻到客户信息、按人员姓名下钻到个人信息。支持分页和 Excel 导出。 **预置报表库** 20 余个标准报表模板，按业务领域分 9 大类，按角色权限分发可见报表。管理人员无需每次重新配置查询条件，直接进入对应报表即可查看结果。覆盖： | 报表类别 | 典型报表 | |---|---| | 科研项目与经费 | 经费总览、项目类别分布、年度对比、学院对比 | | 科研基地 | 基地基本信息统计 | | 知识产权 | 专利统计 | | 产学研 | 产业联盟、校企合作、省部合作 | | 科研成果 | 校级获奖统计 | | 科技人才 | 研究生导师统计 | | 主管部门统计任务 | 教育部项目统计、外拨经费统计、年度学科统计 | | 自主基金 | 自主基金申报统计 | | 管理数据 | 管理费统计、印章统计、在研项目、拨款表 | ![常用统计报表目录](/assets/products/research-platform/analytics-reports.webp) **对比分析** 支持最多 6 位研究者的横向对比。选择对比人员和时段后，并排展示各人的性别、年龄、所属学院、承担项目情况、成果产出等维度的差异。用于人才评估、资源分配和学科发展分析。 **业务流程效率评价** 两个维度的流程效率看板，用于内部管理优化： - **项目管理效率**：总项目数、受理与办结分项统计，按接单人拆分的接单量、办结率、平均受理时长、平均审核通过时长、一次性通过率 - **印鉴管理效率**：印鉴总量、办结率，按事项类型和接单人双维度拆分的处理效率指标 **定向导出** 上传包含项目编号（或工资号、合同编号等 7 种匹配条件可选）的 Excel 模板，选择需要导出的字段（26 个字段可按需勾选），系统自动匹配并生成定制化的导出文件。用于跨部门数据共享和临时性统计需求，比手动筛选再导出更灵活。 ![科研经费统计报表详情](/assets/products/research-platform/analytics-table.webp) ### 其他平台能力 **通知公告**：系统公告的发布、编辑、删除，支持按角色定向推送。 **系统日志与审计**：操作日志和跨模块审计日志覆盖全部业务模块的每一次提交、审批、驳回和修改操作。 **Excel 导入导出与打印**：多模块支持 Excel 批量导入导出，拨款单和项目表单支持 PDF/Word 打印输出，拨款单支持标准格式、天津市财政格式和预算格式等多种模板。 ## 功能模块一览

项目申报与立项项目过程管理结题验收项目变更与调整合作方管理附件管理预算编制与调整拨款文件管理统一拨款补充拨款拨款模板与栏目拨款单打印经费卡管理预借发票来款认领财务系统对接结账管理专利管理专利费用与年费软著管理获奖管理代理事务所管理分享链接协作成果基地管理用章管理科研组管理六级角色权限统一审批引擎待办驱动决策驾驶舱预测分析多维检索与下钻预置报表库对比分析流程效率评价定向导出通知公告系统日志与审计Excel 导入导出PDF/Word 打印输出

模块可以按组织现状组合上线，不要求一次性全部部署。已有系统能够继续承担的业务，可通过数据接口协同，不必为追求"大而全"重复建设。 ## 已有交付经验平台能力来源于高校与科研机构的长期建设实践，覆盖全校级科研项目与经费管理、院级数据治理与统计、知识产权全链条管理等不同切入点。 | 组织类型 | 建设切入点 | 已落地模块 | |---|---|---| | 综合性大学 | 项目与经费管理 | 项目全周期、拨款与经费卡、财务对接、用章管理 | | 学院级部署 | 学院综合数据平台 | 项目与成果统计、指标口径统一、管理驾驶舱 | | 行业研究所 | 课题、合同与知识产权 | 项目管理、专利全链条、代理事务所协作 | ## 建设边界

用固定标准流程覆盖所有学校替代财务核算系统一次性重建全部历史系统在口径未确认前直接生成统计结论论文数据的自动采集与清洗治理科研绩效考核的自动计算

项目范围应根据既有系统、数据质量、制度成熟度和管理优先级确定。涉及财务、人事、资产等权威数据时，以对应业务系统为准，通过接口建立关联。 ## 可以如何试点

选管理切口

从项目管理、经费管理或知识产权中选择当前最痛的一个模块作为切入点。

统一对象与口径

明确项目、人员、经费、成果等核心对象的字段、状态和统计定义。

跑通真实流程

选择一批真实项目和用户，完成申报、拨款、审批和成果关联的完整闭环。

验证后扩展

确认业务使用与数据质量后，再扩展到更多院系和业务模块，逐步迭代。

企业知识管理与业务协同

## 这个产品是什么把知识沉淀、项目协同和流程执行放在同一工作台，降低跨团队协作成本。 ## 它解决什么问题 - 经验无法复用 - 协同信息散落在聊天与表格 - 项目过程不可追踪 ## 适合什么客户 / 场景咨询、研究、研发团队、集团职能部门等知识密集型组织。 ## 可以如何试点先做一条业务线的知识沉淀和协同流程，验证复用率与协同效率。

轻量订单交付管理系统

## 这个产品是什么

很多中小制造企业真正失控的，并不是“不会生产”，而是订单进入公司以后，没有一条所有人都看得见的交付主线。

销售记着客户承诺，仓库掌握实际库存，采购在聊天记录里追到货，装配进度靠现场询问，发货与对账又各有一张表。每个人都在做事，但管理者很难及时确认：订单是否能按期完成，缺料会不会影响交期，当前卡点由谁处理。

信息散落，无法形成订单全貌

合同、库存、采购和交付分别记录，同一笔订单要跨多个表格与人员才能拼完整。

进度靠追问，责任停在口头

管理者反复问“到哪了”，业务人员反复同步状态，真正的异常却可能无人持续跟进。

风险发现太晚，只能被动救火

缺料、采购延期和装配滞后没有提前暴露，往往临近交期才发现问题。

产品定位

企业此时缺少的，通常不是一套庞大的 ERP，而是一条能够真正运行起来的最小业务闭环。

轻量订单交付管理系统围绕订单交付全过程，连接合同、销售订单、库存、采购、生产/装配、发货与对账。它不替代财税系统，也不强行引入复杂 MES，而是先让订单状态统一、业务责任清晰、交付风险提前可见。

合同 / 客户 PO→销售订单→库存判断→缺料采购→生产 / 装配→发货交付→对账导出

## 它解决什么问题

receipt_long

订单有主线

交期、状态、责任人和执行进度统一呈现，不再依赖多份台账拼接。

inventory_2

库存能判断

看清当前、可用与占用库存，及时识别缺什么、缺多少。

local_shipping

采购可追踪

缺料形成采购需求，持续跟踪供应商、预计到货和实际到货。

precision_manufacturing

装配看进度

用轻量看板呈现生产/装配状态，及时发现延期与异常。

package_2

交付有记录

发货、运输、签收和完成状态关联订单，交付结果可回查。

file_export

数据可导出

订单、库存、采购、生产、交付与对账数据按需输出。

## 业务主线与能力模块 ### 首页管理看板面向管理者快速查看运行状态：待交付订单、本周应交付、已延期、缺料、采购未到货、生产/装配中任务、异常提醒。重点不是复杂 BI，而是第一时间发现订单卡点。 ### 合同与订单 - **合同台账**：记录客户合同、客户 PO、报价单、技术协议等商务依据，并与销售订单关联；不做复杂法务审批与电子签章。 - **订单主线**：列表展示订单编号、客户、产品、数量、交期、责任人、主状态，以及库存 / 采购 / 生产 / 交付子状态与延期风险。 - **订单详情**：穿透单笔订单全过程——关联合同、进度时间轴、缺料与采购、装配进度、发货记录、开票 / 收款 / 对账状态。 ### 供应商、采购与库存 - **采购跟踪**：围绕订单缺料展开，覆盖供应商档案、采购记录、预计/实际到货与采购状态流转。 - **轻量库存**：物料/产品档案、当前库存、可用/占用、预警、出入库与流水；不做多仓复杂调拨、批次追溯与库存成本核算。 ### 生产 / 装配与交付 - **生产 / 装配看板**：待备料 → 待生产/装配 → 进行中 → 待检测 / 包装 / 发货 → 完成 / 异常；适合小团队快速更新进度，不做复杂 MES 与排产。 - **交付管理**：发货、运输、签收、完成状态跟踪，记录物流单号与异常备注。 ### 报表中心与对账导出导出订单执行、库存、采购跟踪、装配进度、交付、合同执行及对账所需数据，便于内部管理和对外财务协作。 ## 建设边界为控制系统复杂度和实施周期，标准产品暂不包含：

完整 ERP 财务总账 / 凭证 / 报税复杂成本核算多级 BOMMRP 运算MES 工序报工复杂排产设备 / 工时管理多仓复杂调拨批次 / 序列号电子签章法务审批财务系统深度接口

如后续确有需要，可在上线稳定后另行评估扩展；需要现场执行、质量追溯与设备采集时，可演进到[制造与生产管理方案](/solutions/manufacturing)。 ## 适合什么客户 / 场景 - 约 10–20 人规模的制造、装配、交付型团队 - 尚未建设完整内部业务系统，又不愿上重型 ERP - 财务由外部公司处理，内部更需要订单与交付可见性 - 希望先跑通闭环，再按使用情况扩展 BOM、扫码、审批、成本或系统接口 ## 版本与选型（四档方案）同一套标准产品能力，按**部署方式**与**实施服务深度**提供四个版本。多数制造团队推荐从**云端实施版**起步。

01自助上线

云端标准版

适合有内部人员完成资料整理、配置与上线的团队。

部署方式: 公有云 SaaS
使用授权: 订阅期内使用
用户数量: 15 人以内

多数团队推荐

02快速落地

云端实施版

适合希望有人协助整理资料、配置系统并陪跑上线的团队。

部署方式: 公有云 SaaS
使用授权: 订阅期内使用
用户数量: 20 人以内

03环境独立

独立云实施版

适合重视数据与运行环境独立，但不希望自行运维的团队。

部署方式: 独立应用与数据库
使用授权: 订阅期内使用
用户数量: 20 人以内

04本地部署

私有化实施版

适合有明确内网、本地部署或基础设施管控要求的团队。

部署方式: 客户自有服务器
使用授权: 当前版本永久使用
用户数量: 20 人以内

### 标准产品功能（四档均包含）

合同 / 客户 PO订单管理客户与供应商产品与物料档案轻量库存采购跟踪生产 / 装配状态发货与交付首页管理看板标准报表导出附件管理标准权限账号开通操作文档 / 视频

### 实施与培训服务 | 服务项 | 云端标准版 | 云端实施版 ★ | 独立云实施版 | 私有化实施版 | |---|---|---|---|---| | 业务适配会议 | — | 2 次 | 2 次 | 2 次 | | 基础资料 / 初始库存导入 | 客户自行导入 | ✓ | ✓ | ✓ | | 账号、角色与预警配置 | 客户自行配置 | ✓ | ✓ | ✓ | | 管理员 / 业务人员培训 | — | 各 1 次 | 各 1 次 | 各 1 次 | | 真实订单试跑 | — | 3–5 笔 | 3–5 笔 | 3–5 笔 | | 上线辅导 | 基础答疑 | 30 天 | 30 天 | 30 天 | ### 部署与运维 | 对比项 | 云端标准版 | 云端实施版 ★ | 独立云实施版 | 私有化实施版 | |---|---|---|---|---| | 独立域名 | 可选 | 可选 | ✓ | 客户提供 | | 独立数据库 / 文件存储 | — | — | ✓ | ✓ | | 服务器运维 | 唯易科技 | 唯易科技 | 唯易科技 | 客户负责基础环境 | | 系统备份 | 平台统一备份 | 平台统一备份 | 独立备份 | 提供基础备份配置 | | 产品版本升级 | 自动升级 | 自动升级 | 统一升级 | 服务期内提供升级 | | 安装部署服务 | — | — | 唯易科技完成 | 客户服务器部署 | ### 交付边界四档方案均**不包含**源代码交付与客户专属开发。选型建议：自助上线选标准版；多数团队选云端实施版；重视数据独立选独立云；强制本地/内网选私有化。具体商务条款与报价以正式沟通和合同为准。 ## 可以如何试点

定范围

先选定订单交付主线，生产/装配看板可后置。

定资料

导入客户、供应商、物料与初始库存。

真实试跑

用 3–5 笔真实订单跑通缺料、采购、交付与导出。

验证结果

确认管理者能否看清卡点、延期与下一步责任人。

试点目标不是一次上全模块，而是先让业务人员愿意用、管理者看得见。

学院综合数据管理平台

## 学院管理，应该关注哪些数据

大多数学院不是缺一套管理系统，而是缺一张清单——学院到底应该管哪些数据，每类数据由谁维护、谁审核、怎么流转。

教师信息散落在人事处系统里更新不及时，学生获奖存在辅导员电脑里，科研成果靠年末临时收集，出国境记录没人汇总，房间和工位分配靠纸质表格——每个业务口都在做事，但学院领导看不到一张完整的"学院资产地图"。这个平台做的事情，就是把这张地图画出来，并让数据在上面持续流动。

设计理念

以数据对象为治理单元，以归口部门为审核节点，以统一流程为流转通道。

平台本身不是某个具体业务系统（如科研系统或人事系统）的替代品，而是一张覆盖全院的数据治理网格。它定义"管什么"（数据对象与字段）、"谁管"（归口审核权限）、"怎么流"（提交→审核→归档），让散落在各处的学院数据汇聚到同一张表格里——可查、可审、可统计、可考核。

## 七个归口，一张学院数据地图平台围绕学院治理的实际分工，将全部管理对象归入七个归口部门，每个归口下定义了一组结构化的数据对象。

badge

人事

教师基础信息、合同聘期、人才称号、校外兼职、人事异动、团队与学科

school

学工

学生信息、竞赛获奖、荣誉表彰、党团建设、学术成果、就业、奖助学金

biotech

科研协同

论文、专利、软著、科研项目、获奖、学术任职、学术会议、科研基地

menu_book

本科教学

教改项目、在线课程、教学培训、评教成绩、招生宣传、教学督导

history_edu

研究生管理

导师系统、课程信息、教学工作量、盲审信息、成绩统计

language

国际合作

师生出国境、外籍专家讲座、国际组织实习任职

### 第七归口：综合行政房间与公房管理、师生工位分配、系统公告发布。 ## 核心模块 ### 人事数据治理人事是学院管理的数据底座。平台定义了 13 类人事数据对象，覆盖教职工从入职、聘用、发展到离职的完整信息生命周期，每一类都有明确的维护责任人和审核归口。

教师基础信息系所管理教师合同与聘期人才称号教师经历校外兼职兼薪非全职及兼职聘用人事异动记录海外任职经历团队管理学科与专业目录临时账号代录权限

过去这些信息散落在人事处系统、学院台账和教师个人手里，口径不一、更新滞后。平台把它们收敛到统一的数据对象上——职称评审、人才项目申报、年度考核需要的人事底数随时可查、随时可导，不再靠年末临时汇总。 ### 学工数据治理 18 类学生相关数据对象，覆盖招生、培养、发展到就业的学生全周期。

学生信息（本科/研究生）课外科技竞赛获奖学生荣誉表彰党团建设学生学术成果班级信息奖助励学金创新项目毕业生就业外部导师

学生的竞赛获奖、荣誉、学术成果、党团发展等过程性数据，以往依赖辅导员各自维护、临时统计。平台让这些数据在日常工作中持续沉淀，评奖评优、就业统计、学生画像都能从同一份可信数据出发。 ### 科研与成果协同 16 类科研成果数据对象，统一管理全院科研产出。与校级科研系统不冲突——学院层的数据协同关注的是本院维度的成果汇总、成果关联和绩效统计，可以作为校级系统的补充或独立运行。

论文教师获奖（个人/团队）出版专著/教材学术期刊/组织任职主办/参加学术会议科研项目专利软件著作权新产品新技术科研基地平台申报打磨评审

论文、专利、获奖、项目这些科研产出，是学院最需要"随时说得清、报得出"的一类数据。平台按统一口径归集全院科研成果，并与项目、人员、团队自动建立关联——上级填报、学科评估、绩效核算需要的成果底数，一次维护、多处复用。 ### 教学数据治理 **本科教学**：教改项目（类型、级别、经费、成员）、在线课程资源建设、教师教学培训参与、学生评教成绩、招生宣传活动参与、教学督导记录、课程信息与教学工作量统计、成绩统计。 **研究生管理**：导师系统（导师信息、聘期）、研究生课程信息与教学工作量、学生盲审信息、成绩统计。 ### 国际合作数据师生出国境记录（目的地、天数、因公/因私、费用来源、成果）、教师邀请外籍专家来校讲座（专家信息、讲座主题、参会规模）、国际组织实习任职（组织名称、职务、工作内容）。 ### 综合行政数据公房与房间管理（楼栋、房间号、面积、用途、设备清单）、师生工位分配（工位号、分配时间、使用期限）、系统公告（按范围发布、阅读统计）。 ## 统一审批流程所有数据对象共享同一套审批状态机，归口管理员审核本归口下的数据提交。

创建（暂存）→提交→归口管理员审核→通过/驳回→归档/重提

- **暂存**：草稿不校验唯一性，可随时返回修改 - **提交**：触发字段唯一性校验和必填校验，进入审核队列 - **归口审核**：每条数据归属到一个或多个归口部门，由对应归口管理员审核 - **驳回重提**：审核不通过退回发起人，修改后可再次提交 - **参与人机制**：涉及多人的数据（如论文作者、团队成员），系统自动关联到所有参与人的名下 ## 绩效考核：数据归档即绩效积累平台上每条经过审核归档的数据，不需要二次填报即可直接参与年度绩效考核。教师日常维护的论文、专利、获奖、教学工作量就是绩效数据的持续积累。 ### 从方案配置到自动计分

配置考核方案→绑定数据源→发布方案→年度考核启动→教师选择数据→系统自动计分→审核确认

**第一步：配置考核方案。** 绩效管理员为每个年度创建一套考核方案，定义考核的指标体系——包括大项（如"科研业绩""教学业绩""公共服务"）和子项（如"SCI一区论文""获批国家基金项目""指导学科竞赛获奖"）。方案配置为五步向导流程：基本信息 → 构建指标体系 → 配置评分规则 → 绑定数据源 → 校验与发布。 **第二步：绑定数据源。** 每个考核子项绑定到平台中已有的一类数据对象。例如"SCI一区论文"子项绑定到论文数据，筛选条件为"SCI分区 = 一区"；"获批国家基金"子项绑定到科研项目数据，筛选条件为"项目来源 = 国家自然科学基金"。绑定后，教师在进行绩效考核时看到的可选数据就是自己名下符合条件的数据记录，不需要在 Excel 里翻找。 **第三步：配置评分规则。** 每个子项设置计分方式： | 评分规则 | 说明 | 示例 | |---|---|---| | 固定分值 | 满足条件即得固定分数 | SCI一区论文每篇 10 分 | | 数据累计 | 每条数据计 X 分，可设封顶 | 国家基金项目每项 20 分，最多 60 分 | | 合格/不合格 | 满足条件即为合格，不满足不合格 | 年度教学工作量达标即为合格 | **第四步：校验与发布。** 方案发布前系统自动校验——必填项是否完整、总分是否分配完毕、数据绑定子项是否同时配置了规则和绑定。校验分三级：错误级阻止发布，警告级需确认后发布，提示级不影响发布。发布后方案版本冻结，后续修改自动生成新版本。 **第五步：年度考核启动。** 选择已发布的方案版本、设置参与教师范围、开放填报截止时间和审核截止时间。教师登录后在绩效考核页面看到自己名下的全部考核条目，每个条目下自动列出符合条件的数据记录——勾选想要纳入的数据、上传补充材料、提交。系统按方案配置的规则自动计算每项得分和总分，审核人确认后生成最终绩效结果。 ### 数据归属与防重复教师与数据的关联通过"拥有者"和"参与人"两种模式判定。论文的第一作者和通讯作者、专利的第一发明人、项目的负责人自动认定为拥有者；论文的合作作者、团队参与成员认定为参与人。考核方案可分别设置某一条目按拥有者还是参与人计分。同一条数据在同一年度内不会被多个考核条目重复计算——例如一篇论文不会既被"SCI论文"条目计分、又被"科研成果"条目重复计分。 ### 方案版本管理考核方案支持多版本管理。上一年度的方案可以作为模板复制、修改后生成新年度版本。历年方案和考核结果可追溯，支持跨年度对比分析。方案发布后即被冻结，年度考核启动后不可修改——保证考核的严肃性和前后一致性。 ## 按需扩展，不设数据边界新增一类数据对象（如"国际学术会议"或"教师企业实践"）不需要重新开发——平台支持通过配置快速上线新的数据类型，字段、校验规则、审核归属均可灵活定义。全部数据对象共享同一套存储规范、查询方式、导入导出工具和权限机制——不会出现"这个模块的数据导不出来、那个模块的权限对不上"的问题。

add_circle

新数据对象快速上线

新增数据类型通过配置即可完成，不需要开发周期。

layers

统一数据底座

全部数据对象共享同一套存储、查询、导入导出和权限机制。

extension

可渐进扩展

从当前最痛的一两个归口起步，逐步纳入更多数据对象。

sync_alt

可对接已有系统

与校级系统不冲突——通过数据导入或接口同步，学院平台作为数据汇聚层。

## 已有交付经验 | 组织类型 | 建设切入点 | 已落地内容 | |---|---|---| | 高校二级学院 | 全院综合数据治理 + 绩效考核 | 7 归口 40+ 类数据对象上线运行，覆盖全院教师和学生，关联年度绩效考核 | ## 建设边界

替代校级人事/科研/学工等核心业务系统承担财务核算职能一次性上线全部 90 余类数据对象在管理口径未达成共识前强制推行直接修改校级系统的源数据

平台定位为学院层的数据治理与绩效管理层。校级系统的数据可以作为数据源导入或通过接口同步，学院平台在此基础上完成数据汇聚、补充填报、归口审核和绩效计算。建设范围应从当前管理最迫切的一两个归口起步。 ## 可以如何试点

选归口切入

从管理最痛的一个归口（如科研成果、人事信息或学生获奖）开始，确定首批数据对象。

定字段与口径

逐类数据对象确认字段定义、必填项、归口归属和审核规则。

数据初始化

将现有 Excel、分散系统中的存量数据导入平台，建立初始数据基础。

跑通审核与绩效

让真实用户提交数据、走完审批流程，验证数据质量，再接入绩效考核。

生产业务与质量管理系统

## 这个产品是什么

制造现场最危险的不是出现异常，而是异常发生后不知道影响了哪些产品、为什么发生，也无法在问题扩大前及时拦住。

工单在系统里、参数留在设备上、检验结果靠人工录入、维修记录散落在班组。数据没有按产品、批次、工序和设备串联时，管理者看到的是滞后的日报，质量工程师面对的是需要几天才能拼完整的追溯链。

现场状态滞后，计划与执行脱节

工单下达后缺少及时报工和过程反馈，管理者无法准确掌握进度与异常。

质量记录分散，异常发现太晚

来料、过程和出厂检验没有形成连续记录，问题容易在后续工序或交付后暴露。

批次链路断裂，出了问题查不清

物料、设备、人员、工艺参数和检测结果无法正反向关联，追溯依赖人工拼表。

产品定位

生产业务与质量管理系统不是一次性上线一套庞大 MES，而是从工厂最需要的数据闭环切入，逐步连接工单、物料、工序、设备、检验与批次追溯。

建设重点是让现场数据及时、可信、可关联：一线人员操作足够简单，关键设备能够稳定采集，质量异常能够进入处置流程，管理者和工程师可以从产品反查过程，也可以从异常批次正向定位影响范围。

订单 / 计划→工单下达→备料与投产→生产报工→质量检验→异常处置→批次追溯

## 它解决什么问题

assignment

工单执行可见

计划、工单、工序和报工状态持续更新，及时识别滞后与停滞。

qr_code_scanner

物料批次接力

通过条码、PDA 等方式绑定原料、在制品和成品批次。

fact_check

检验过程留痕

来料、过程、复检和出厂结果与产品、工序及判定依据关联。

warning

异常及时处置

质量、设备和参数异常形成责任、措施、复核与关闭记录。

memory

关键数据采集

按现场条件连接设备、传感器或检测系统，减少事后补录。

manage_search

正反向追溯

从产品追到物料、工序和检测，也能从异常批次找到影响范围。

## 典型能力模块

仓储与条码生产调度工单与报工来料检验过程与出厂检验异常处置设备数据采集批次追溯现场看板统计分析

每个模块可以独立切入，也可以按业务主线逐步串联。具体范围取决于生产方式、标识体系、设备接口、节拍要求和质量管理制度，不宜用同一套模板覆盖所有车间。 ## 数据闭环 | 数据对象 | 需要形成的关联 | 主要用途 | |---|---|---| | 工单与工序 | 产品、计划、人员、班次、起止时间 | 生产进度、节拍与延期分析 | | 物料与批次 | 来料、投料、在制品、成品与供应商 | 正反向批次追溯与影响范围定位 | | 工艺与设备 | 参数、设备、模具、点检、维修与变更 | 还原生产条件，辅助异常分析 | | 质量与异常 | 检验项、结果、判定、措施、责任与复核 | 质量闭环、客户投诉与审计响应 | ## 适合什么客户 / 场景 - 已有基本订单与生产管理，希望加强现场执行和质量追溯 - 条码、设备、检测或人工记录分散，无法形成连续数据链 - 客户审计、质量投诉或批次索赔要求较高的制造企业 - 希望从一个仓库、工序或产线渐进建设 MES 能力 ## 建设边界

用一套固定 MES 模板覆盖所有产线用 AI 补造未采集的现场数据忽略标识体系直接建设追溯让模型直接作出最终质量判定一次性对接全部设备在不影响生产的假设下大爆炸上线

现场系统首先要保证稳定和可执行。AI 可以在数据稳定后辅助异常归因、知识检索和报告整理，但不能替代真实数据采集、质量规则与责任人员。 ## 可以如何试点

选择现场切口

从仓储扫码、报工、检验或批次追溯中选择价值明确的环节。

统一标识与状态

明确产品、批次、工单、工序及异常的编码和流转规则。

跑通数据闭环

在一条产线或一个工序完成采集、记录、查询和异常处置。

稳定后再扩展

验证一线可用性和数据完整性，再增加设备、工序与分析能力。

若团队尚未建立订单、库存与交付台账，可先看[轻量订单交付管理系统](/products/order-delivery)，再演进到本产品。

办公与流程基础平台

## 这个产品是什么提供组织级流程与协同底座，支撑多角色、多部门的日常业务流转。 ## 它解决什么问题 - 流程系统分散、权限复杂 - 跨部门协作效率低 - 业务表单和审批链条不统一 ## 适合什么客户 / 场景需要构建统一协同与审批体系的组织。 ## 可以如何试点先落地 2-3 条高频流程，建立可复制的权限与表单模板。

工程计算与仿真平台

## 让复杂计算工具触手可及

许多专业领域的核心计算能力——CFD 仿真、有限元分析、化学动力学建模、结构优化——长期以来锁在命令行工具和文本配置文件里，只有少数掌握工具链的专家才能使用。

工程计算与仿真平台提供了一套将专业计算工具 Web 化封装的通用框架。领域专家在网页上填写结构化表单，平台自动生成目标工具的配置文件，支持在线执行和结果可视化。不需要学命令行、不需要编辑配置文件、不需要在服务器之间搬运数据文件。

设计理念

用模型驱动架构解耦领域知识和工具细节，让每个领域专家都能直接使用自己需要的计算能力。

平台的核心思路不是为某个特定领域做一个专用系统，而是提炼了一套可复用的封装模式：定义数据模型 → 自动生成表单 → 模板化代码生成 → 任务调度执行 → 结果汇总呈现。任何一个依赖配置文件驱动、需要参数化执行的计算工具，都可以通过这个模式快速封装为 Web 应用。平台已经在内燃机燃烧仿真领域完成了首次落地验证。

定义数据模型→配置表单与字段规则→编写配置模板→用户填写参数→生成工具配置文件→执行计算任务→结果可视化

## 平台能力结构 | 层级 | 主要能力 | 价值 | |---|---|---| | 模型定义层 | 数据模型元数据定义、字段类型与约束、分组与布局 | 领域知识的结构化表达，一次定义，前端自动适配 | | 表单呈现层 | 模型元数据驱动的动态表单渲染、字段联动规则引擎、多语言支持 | 零代码生成交互界面，字段显隐/校验/联动全部声明式配置 | | 代码生成层 | 模板引擎、配置文件自动生成、打包下载 | 将表单数据转换为任意目标工具的配置文件格式 | | 任务执行层 | 服务器端进程调度、实时日志推送、任务状态管理、超时与异常处理 | 长周期计算任务的可靠执行与实时监控 | | 结果分析层 | 3D 网格可视化、2D 图表、时序动画、多方案对比 | 将计算结果转化为可交互的视觉分析 | ## 核心能力 ### 模型驱动的动态表单传统做法是为每一类计算工具单独开发一套表单页面，工具多了以后维护成本指数级增长。平台的做法是：通过结构化的元数据定义数据模型，包括字段类型、分组、校验规则、默认值、多语言标签，系统在运行时读取模型元数据自动渲染表单。一个包含 100+ 字段的复杂模型从定义到可用的 Web 表单，不需要写一行前端代码。新增一类计算工具只需定义数据模型和配置模板，表单界面自动生成。

字段类型自动映射分组与嵌套布局动态校验规则多语言标签版本化模型管理

### 模板化代码生成领域专家填写的结构化表单数据，通过模板引擎转换为目标工具所需的配置文件。模板定义了"表单字段如何映射到配置文件的哪些位置"，平台负责执行映射和文件打包。

表单数据 (JSON)→模板引擎→目标工具配置文件集→打包下载 / 服务器端部署

一个仿真场景通常对应数十个配置文件（初始条件、边界条件、求解器参数、物理模型参数等），人工编辑极易出错。平台一次性生成全部文件，保证参数一致性和格式正确。生成的配置可以选择下载到本地使用，也可以直接在平台服务器上执行。 ### 声明式字段规则引擎复杂计算工具的配置参数之间通常存在大量依赖关系——选择了 A 模型，B 参数才需要填写；C 的值超过阈值，D 参数必须启用。传统做法是在前端代码中硬编码这些逻辑，每增加一条规则就要改代码。平台提供了一套声明式的字段交互规则引擎，支持： | 规则类型 | 说明 | 示例 | |---|---|---| | 显隐控制 | 字段 A 的值决定字段 B 是否可见 | 选择"自定义混合物"后显示组分比例输入框 | | 启用/禁用 | 字段组合决定某个参数是否可编辑 | 选择"自适应时间步长"后禁用手动时间步长输入 | | 自动填充 | 字段值变化时自动计算关联字段 | 输入喷孔数量后自动计算孔间距 | | 异步动作 | 字段触发远程 API 调用 | 选择坐标系后从服务端加载该坐标系下的参数模板 | | 初始化执行 | 表单加载时自动触发的规则 | 根据当前日期自动填充默认时间范围 | 规则通过后台配置，不依赖前端代码修改。新增计算工具时，领域专家和开发人员协同定义数据模型和字段规则，无需前端开发介入。 ### 实时任务执行与监控计算任务通常需要运行数小时甚至数天。平台通过服务器端的进程调度器启停计算任务，将任务的标准输出和错误输出实时推送到浏览器，让用户随时掌握运行状态和进度。系统实时监控计算节点的 CPU、内存、磁盘和网络使用情况，异常时自动预警。支持多任务队列管理和优先级调度。 ### 结果可视化与分析计算结果不再是一堆文本文件和数字表格。平台内置三种可视化能力： - **3D 可视化**：计算网格的线框和实体渲染、温度场/压力场/速度场等物理场的等值面和切片展示、流线和矢量场动画 - **2D 图表**：时序曲线、散点分布、柱状对比，支持多方案叠加分析 - **时序动画**：按时间步长播放物理场变化过程，直观展示瞬态特性支持多方案对比分析——将不同参数组合的计算结果放在同一视图下对比差异，帮助工程师快速判断参数调整的方向。 ### 数据管理与复用 | 能力 | 说明 | |---|---| | 配置快照 | 每次提交的参数配置自动保存为快照，支持历史版本回溯和对比 | | 模板库 | 常用的参数组合保存为模板，下次直接加载修改 | | 多媒体附件 | 计算结果关联的实验数据、参考图像、文档等附件统一管理 | | 批量导出 | 支持 Excel、PDF、CSV 格式的数据导出 | ## 适合什么场景

CFD 计算流体力学仿真有限元结构分析化学动力学建模参数化设计优化实验数据的回归建模科研团队的仿真工具共享企业内部的工程计算平台教学场景的计算工具封装

任何依赖命令行工具、文本配置文件和长时间计算任务的工程或科学计算场景，都可以通过平台封装为 Web 应用。平台的适用边界不是领域，而是**工具的使用方式**——只要流程是"填写参数 → 生成配置文件 → 执行计算 → 分析结果"，就适合封装。 ## 已有实践经验平台已在内燃机燃烧系统仿真领域完成首次落地，覆盖以下计算场景： | 场景 | 封装内容 | 典型复杂度 | |---|---|---| | 喷雾混合仿真 | OpenFOAM Lagrangian 喷雾求解器的参数配置与执行 | 100+ 可配置字段，30+ 配置文件 | | 湍流燃烧模拟 | 高精度湍流燃烧模型的选择与参数配置 | 多组分化学反应机理文件对接 | | 气道性能预测 | 基于回归模型的气道参数预测 | 客户端侧回归计算，配置快照 | | 燃烧室结构优化 | 神经网络辅助的燃烧室参数优化 | ML 模型与仿真工具的联动 | 每个场景从传统的手工编辑配置文件到 Web 端可操作，配置效率提升显著，参数错误率大幅降低。平台已在高校机械工程学院的科研团队日常仿真工作中投入使用。 ## 建设边界

替代商业 CFD/FEA 求解器软件提供仿真工具的自主开发能力取代高性能计算集群的调度系统自动的网格生成与几何建模仿真结果的自动分析报告

平台解决的是"用"的问题，不是"算"的问题。计算工具本身（OpenFOAM、自定义求解器等）由客户提供或开源获取，平台负责降低使用门槛。涉及网格生成、几何建模、结果自动解读等能力时，通过接口与专业工具协同，而非自研替代。 ## 可以如何开始

选一个计算工具

选择一个团队内部使用频率高、配置流程复杂、多人需要协作的计算工具作为试点。

梳理参数与模板

整理工具的配置参数体系、文件结构和典型使用流程，明确哪些参数需要暴露给用户。

定义模型与封装

在平台上定义数据模型、编写配置模板、配置字段规则，完成首次封装。

验证后扩展

用真实计算任务跑通全流程，验证生成配置的准确性，然后逐步扩展更多工具和场景。

试点周期通常在 2-4 周内完成第一个计算工具的封装并跑通首个真实案例。

企业知识库建设

## 这个产品是什么把分散文档整理为可检索、可引用、可维护的知识资产。 ## 它解决什么问题 - 知识分散且版本混乱 - 新人上手慢 - 问答缺少可信来源 ## 可以如何试点先选一个主题域做知识清洗、分层与权限治理，再接入问答入口。

日程与资源预约管理系统

## 这个产品是什么大多数单位的日程管理不是缺一个日历软件，而是缺一套让所有人看同一张表、按同一套规则做事的系统。会议室预约靠群里喊"有人吗？"，领导日程靠秘书分别记在各自的笔记本上，同一个会议被三个秘书各录一遍，会议改期后有人不知道还去了旧会议室——每个人都在做事，但组织看不到一张完整的"谁在什么时间做什么"。日程与资源预约管理系统不是另一个个人日历。它面向高校、科研院所和企事业单位，把个人日程、团队忙闲、会议室与车辆设备的预约、会议组织与协同、代录授权、审批规则、操作审计整合为一套可以独立运行也可以嵌入其他业务系统的组织级时间协同平台。

普通员工在日历上排自己的时间、订会议室、回复会议邀请；秘书在团队视图里帮领导找空档、代录日程；管理员在治理层设定谁可以代谁操作、哪些操作需要审批、修改时限怎么控制——所有动作都有记录可查。

它不是替代 Outlook 或手机日历，而是在组织内部提供一套看得见、控得住、可追溯的时间资源管理闭环。

排期靠问，冲突靠碰

安排一次跨部门会议要挨个确认参会人时间，秘书帮领导排日程全靠私下沟通。会议室有没有空、领导有没有时间、设备能不能用——没有统一视图，靠问、靠看、靠猜。

改一次，追着通知一圈人

会议时间变了、会议室换了、临时取消了——通知靠微信群逐个 @。有人没看到消息去了旧会议室，有人日程冲突了也不知道。一场会议改期的通知成本，往往比创建会议本身还高。

有习惯，没规则

谁能帮领导录日程？录完要不要审批？不同秘书录了同一个会议怎么合并？日程创建后还能不能改、能改到什么程度？这些在大多数组织里都是约定俗成的习惯，没有系统规则。

产品定位

不是个人日历，而是组织级时间协同平台。人和会议室、车辆、设备被同等对待——忙闲查询、冲突检测、占用日历，共用同一套逻辑。会议一旦确认，自动落到每个参会人的日程上；会议改期，所有人的日程跟随平移。

核心不是"记日程"，而是让组织的时间资源变得可查看、可预约、可审批、可追溯。从一间会议室的预约试点，到全单位的日程治理平台，共享同一套数据模型，升级不需要推倒重来。

个人排期 / 资源预约→冲突自动检查→审批 / 代录留痕→日历同步 / 会议派生→消息铃铛通知→操作审计可查

## 从一间会议室到全单位治理：三层能力，按需开启三个层级共享同一套数据模型和业务规则，从轻量试点到完整平台，不需要更换系统。

### L0 会议室与资源预约面向仅需要管理会议室预约、预算有限、希望从小程序入口快速上线的客户。L0 解决的核心问题是：让会议室"有没有空、谁在用、怎么约"从口头协调变成系统管理。 **资源台账**：管理员可维护会议室、车辆、设备三类资源的基础信息——名称、容量、位置、配套设施说明，每种资源可独立设定"是否需要审批"并指定审批人。资源支持启用和停用，停用的资源不出现在预约选项中。 **提交预约**：用户选择资源、填写主题、选定时间段后提交。系统自动检查该资源在所选时段是否已被占用——同一资源、同一时段不可重复预约。冲突时提示具体冲突信息，无冲突则提交；需审批的资源进入待审批状态，否则直接生效。 **审批与状态流转**：预约状态分为五档——待审批 → 已通过 / 已驳回 → 已取消 / 已完成。审批人逐条处理，通过时填写审批意见，驳回时写明原因。通过后资源时段立即占用，驳回后释放。 **资源占用日历**：每个资源有独立的日历视图，用颜色块展示每一天每个时间段被谁占用。管理员和普通用户均可查看，不需要翻表格。 ![资源预约中心：左侧资源目录，右侧时段占用与冲突检测](/assets/products/schedule-resource/resource-booking.webp)

### L1 日程与资源预约 L1 在 L0 的基础上增加了完整的个人和团队日程能力，以及会议协同的闭环。这是面向大多数客户的主推版本。 **五视图日历**：个人日历支持日视图（半小时粒度纵向排列）、工作日视图、周视图（横向七列）、月视图和列表视图五种切换。顶部"今天"按钮一键回到当天，当前时间以红色横线标示。 **三种方式新建日程**：点击日历空白格（时段自动预填）、在日历上框选时间段（弹出快捷菜单"新建日程""新建会议""预约资源"）、点击"+ 新建日程"按钮。日程表单包含：标题（必填）、时间段（精确到分钟）、全天开关、归属人（支持代录）、日历本（多日历本独立颜色）、关联资源、位置、可见性（私密/仅忙闲/公开）、六种重复规则（每天/工作日/每周/每月/每年）、备注。 **八种视觉状态，一眼区分**：蓝色（自己创建）、紫色（代录，标归属人）、青色（他人日程）、橙色（会议派生）、青绿色（资源预约）、绿色（全天）、灰色半透明+删除线（已取消）、斜线条纹+忙碌（私密，别人视角下只看到时间占用）。 ![个人月视图日历：五种事件颜色区分来源与状态](/assets/products/schedule-resource/calendar-month.webp) **拖拽即改，冲突拦在保存前**：直接拖动或拉伸事件块边缘改变时长，拖拽结束时自动检查冲突——有冲突弹窗列冲突详情，可选择撤销或强制保存。会议派生和资源预约事件不可拖拽。 **多日历本与关系筛选**：多个私人日历本各自独立颜色，一键切换显示/隐藏；三种关系筛选交叉组合——我创建的、我代录的、他人的。 **团队日历**：通过人员选择器搜索并添加成员，所有选中成员的日程叠加展示。关键设计：别人私密日程仅显示"忙碌"色块，内容不可见——知道时间段有安排但不看具体内容。支持在团队视图中框选空白时段代选中成员新建日程，归属人自动设为该成员。 ![团队日历：多成员日程叠加，私密日程仅显示时间占用](/assets/products/schedule-resource/team-calendar.webp) **会议协同**：发起会议时指定主题、时间、地点、会议室、参会人（多选，按部门搜索）。保存后自动执行三条动作——向参会人发邀请（消息铃铛）；每人日历生成橙色派生日程；发起人日历同步显示。参会人可在"邀请待回复"中接受/暂定/拒绝，发起人实时看到回复状态。会议变更或取消时，所有参会人的日历同步更新，会议室占用自动释放。派生日程不可在日历上直接编辑——保证只有一个入口，不会出现"有人拖了日程但别人没同步"。 **会议中心**："我发起的"与"我参与的"两个 Tab，支持展开详情、编辑、取消和通知。 ![会议中心：会议列表与详情，参会人角色与回复状态](/assets/products/schedule-resource/meeting-center.webp)

### L2 会议协同与组织治理 L2 增加了面向管理者和行政岗位的治理能力。 **代录授权**：可配置的授权关系，管理员为被代理人指定代理人、设定授权范围和有效起止时间。代录日程归属对方，操作日志同时记录实际操作人和被代理人两个身份。 **审批规则**：按组织、按事件类型、按动作类型精细化定义审批链路——规则名称、编码、适用组织、触发事件类型（新建/修改/取消日程、新建预约等）、多步审批人定义。操作命中规则时进入审批流程，通过后生效，驳回后通知发起人，发起人可撤回。 **修改时限**：按策略定义日程和会议的可修改边界——创建后可修改时长、开始前可修改时长、开始后/结束后是否允许修改，超时后转审批。管理员可指定豁免角色。 **会议合并**：自动检测标题相似、时间接近的疑似重复会议，生成合并候选列表附带相似度评分。管理员在合并工作区中确认合并，系统将源会议参会人合并到目标会议中，源会议自动取消并通知相关人员，合并记录保留可追溯。 **配置中心**：统一管理基础参数、代录授权、公共日历、审批规则、修改时限、会议合并和操作审计七个分页。 **操作审计**：按对象类型、操作类型、操作人、被代理人、时间范围六个维度筛选，每条记录显示变更前后对比，支持分页和导出。

## 它解决什么问题

event_available

统一时间视图

会议室、领导、车辆、设备——忙闲状态一张图可查，不再靠逐个确认。

event_repeat

变更同步

会议改期后所有人日程同步平移，通知自动触达，无人被落下。

rule

规则可配

谁能预约、要不要审批、创建后多久还能改，全可按组织规则配置。

supervised_user_circle

代录留痕

秘书帮领导录日程、多秘书不会重复录入，谁操作的、替谁操作的，日志可查。

groups

会议协同

发起、邀请、接受拒绝、转派、变更通知、取消，一个闭环完成。

history

全程可追溯

谁在什么时间做了什么操作，每条都有前后对比记录。

## 适合什么客户 / 场景 - 会议室和车辆调度从口头协调转向系统管理的单位 - 需要帮领导统筹日程、多秘书协同排期的行政办公室 - 跨部门会议频繁，需要统一会议发起、邀请和变更通知的组织 - 希望对日程和会议的创建、修改建立规则与审批闭环的管理者 ## 建设边界

替代个人日历 App完整的会议纪要、决议与待办管理CalDAV/Exchange/ICS 外部日历同步替代企业微信、飞书、钉钉L0 版本承诺多级审批、代录授权或会议合并把个人日程当组织治理工具

L0 解决"会议室有空吗、谁在用、怎么约"，不引入个人日程和会议协同能力。L1 解决日常个人与团队的时间管理，不引入复杂治理规则。L2 是面向行政与管理者对规则和合规性的需求，适合已有日常使用习惯、需要收口规则的阶段。 ## 可以如何试点

从一个会议室开始

选最常见的痛点切入：不是"日程管理"，而是"会议室预约"。客户不需要理解日程协同这些概念，只需要感受到"手机上能看空闲、能提交预约、管理员能审批、微信能收到提醒"就够了。1-2 个会议室、50 人以内试点——最低门槛、最快见效的切口。

跑通 Web 管理端闭环

管理员录入会议室信息，用户在页面上提交预约，系统自动检查冲突、生成审批记录。审批人处理，预约状态自动更新，资源占用日历同步刷新。这个闭环跑通后，客户对系统能做什么就有直观感受。

接入小程序和消息推送

Web 管理端流程确认无误后，接入小程序端和微信消息推送。小程序解决移动端预约、查看、审批；消息推送解决预约成功提醒、审批结果通知、会前提醒。统一身份认证对接学校或单位的 SSO。

从试点升级到平台

试点验证通过后分步开启：增加资源类型（车辆、设备），启用个人和团队日历，引入会议协同，配置代录授权和审批规则，最终部署修改时限和会议合并，升级为完整的组织级日程治理平台。每一步都是增量叠加，不需要更换系统。

## 交付方式 | 方式 | 说明 | |------|------| | 产品授权 | Web 管理端按模块授权，部署在客户自有服务器上 | | 场景裁剪 | 按客户实际需要的层级和功能范围裁剪，不把全平台一次性全开 | | 嵌入集成 | 作为业务系统（科研管理、学院数据平台等）的底层日程能力组合使用，业务项目引用公共模块而非从零开发 | | 长期运维 | 功能升级、安全维护、第三方系统对接 | ## 客户需要准备什么 - 组织架构和人员信息 - 资源清单：会议室数量、容量、位置；车辆和设备信息（如适用） - 审批规则（如有）：哪些资源需要审批、审批人是谁 - 如需小程序或统一登录：学校或单位的 SSO 接口信息、微信公众号或小程序配置

项目交付过程管理平台

## 让项目状态不再靠人问

"这个项目进度怎么样了？"——这是技术管理者问得最多、也最难得到准确答案的问题。任务在任务管理工具里流转、代码在仓库里提交、构建在流水线上跑，但没有一个地方能让管理者一站式看到：哪些项目正常、哪些延期、团队负载如何、质量趋势怎样。

项目交付过程管理平台不是又一个任务管理工具，而是在已有的工程工具链之上建立一层管理视图——自动汇聚任务状态、代码提交、构建结果和测试数据，让管理者和团队成员从"被动汇报"转为"主动可见"。平台已在大型机构的技术部门稳定运行多年，支撑数百个并行项目的日常交付管理。

设计理念

项目管理数据不应该靠人填报，而应该从工程工具中自动汇聚。

任务管理工具知道这个需求开发到哪了，代码仓库知道今天提交了多少代码，构建工具知道最新版本有没有通过。平台做的事情是把这些数据按项目维度组织起来——每个项目关联自己的任务空间、代码仓库和构建流水线，管理者和团队成员在同一个页面看到工程真相，而不是依赖项目经理的口头汇报或手工整理的 Excel。

需求分析→系统设计→开发实施→测试管理→上线投产→运维监控

## 平台能力结构 | 层级 | 主要能力 | 管理价值 | |---|---|---| | 项目计划层 | 四阶段计划、关键节点里程碑、项目基本信息与关联系统 | 每个项目的路线图清晰可见 | | 工程工具集成层 | 任务管理、代码仓库、构建工具、文档空间统一入口 | 管理数据自动汇聚，不依赖手工填报 | | 过程管理层 | 需求分析、系统设计、测试管理、上线管理 | 项目阶段流转有记录、有审批 | | 报告层 | 项目周报自动分配与汇总、工作日报填写与审核 | 告别手工收集和拼凑周报 | | 数据看板层 | 驾驶舱、开发视图、统计分析 | 不同角色看到自己关心的数据维度 | ## 核心模块 ### 项目计划与关键节点每个项目按四阶段管理生命周期：立项 → 实施 → 测试 → 投产。每个阶段定义起止日期和负责人，阶段下设置关键里程碑节点（需求接收、方案评审、开发完成、测试通过、上线审批等）。项目概览页统一展示基本信息、关键节点进度、关联系统和项目文件。支持多项目并行跟踪——管理者在一个列表页看到所有项目的最新状态、阶段分布和延期风险。项目延期自动标红预警，通过企业微信推送提醒。 ### 工程工具链集成平台本身不替代任何工程工具，而是在它们之上建立统一的关联视图。每个项目配置自己对应的工具实例： | 工具类型 | 关联内容 | 管理价值 | |---|---|---| | 任务管理工具 | 项目下的需求、任务、缺陷列表和状态统计 | 任务完成率、Bug 趋势一目了然 | | 代码仓库 | 代码提交记录、分支视图、贡献者统计 | 团队工作量和代码活跃度可视化 | | 构建工具 | 构建流水线链接和最近构建状态 | 构建通过率和失败原因快速定位 | | 文档空间 | 项目文档和知识库链接 | 统一项目文档入口 | 管理人员在项目详情页即可看到该项目的任务完成情况、代码提交趋势和 Bug 分布——不需要切换到各个工具逐个查看。系统顶栏工具栏为每个已关联的工具提供快捷入口，点击即可跳转到对应的工具页面。 ### 需求到上线的全过程管理项目进入实施阶段后，按标准化流程推进： | 阶段 | 主要活动 | 输出与记录 | |---|---|---| | 需求分析 | 需求细化和确认，技术方案评审 | 需求文档、评审记录 | | 系统设计 | 架构设计、接口设计、数据库设计 | 设计文档、设计评审结果 | | 测试管理 | 测试计划、用例执行、缺陷跟踪、测试报告 | 测试通过率、缺陷分布、覆盖统计 | | 上线管理 | 上线审批、部署检查、回滚预案 | 上线记录、审批留痕 | 每个阶段的完成需要经过审批确认，审批记录和阶段文档归入项目档案。阶段间的关系不是简单的"完成→开始"，支持阶段并行和阶段回退。 ### 项目周报系统按项目生命周期自动生成周报周期和需要填报的项目清单。项目经理只需填写三部分内容：本周进展、下周计划、风险和待解决事项。填写完成后自动汇总为部门周报——管理者看到的是结构化、可对比的周报，而不是每个人不同格式的邮件。周报支持填报状态追踪：哪个项目已填、哪个项目未填，延期未填自动提醒。历史周报按时间线归档，支持按项目、按周期回溯。 ### 工作日报个人每日工作记录。团队成员填写当天完成的工作和遇到的问题，提交后由团队负责人审核。日报汇总视图按人员、按日期展示工作量分布。外包人员的日报独立管理。 ### 数据看板平台提供三层数据视图，不同角色看到不同的数据维度： | 视图 | 面向角色 | 核心指标 | |---|---|---| | 驾驶舱 | 部门管理者 | 项目阶段分布、进度异常比例、年度计划执行率 | | 开发视图 | 技术管理者 | 代码提交统计（团队/个人）、Bug 趋势、测试通过率、功能模块覆盖 | | 统计分析 | 运营管理者 | 项目开发周期分布、延迟原因分析、团队负载统计、各阶段耗时 | 所有统计视图支持按年度、按部门筛选，支持 Excel 导出和图表截图。 ## 适合什么场景

技术部门需要统一的项目状态视图数十到数百个项目并行的交付管理项目数据散落在多个工程工具中需要统一项目周报靠手工收集拼凑效率低管理者需要驾驶舱而不仅是任务列表需要追踪项目四阶段的计划和实际偏差

平台的适用边界不是工具的功能强弱，而是**项目的数量和复杂度**——当你有几十个并行项目、每个项目用到多个工程工具、需要自动汇总而非手工填报时，这就是你要的。 ## 建设边界

替代任务管理工具替代代码仓库或构建系统替代专业测试管理工具提供自动化CI/CD能力替代财务系统或合同管理

平台定位是在工程工具链之上建立交付管理视图——任务管理工具管任务流转、代码仓库管代码版本、构建工具管流水线执行，平台管"把这些数据按项目维度组织起来，让管理者看得见"。 ## 可以如何开始

接入一个项目的工具链

选择一个典型项目，关联它的任务管理空间、代码仓库和构建流水线，验证数据汇聚。

建立项目计划和周报流程

为几个活跃项目设置四阶段计划和关键节点，启动周报自动汇总。

跑通一个完整交付周期

跟踪一个项目从需求分析、开发、测试到上线的全过程，积累过程数据。

建立管理基线

积累2-3个季度的项目数据后，建立驾驶舱基线——知道"正常"是什么样的。

试点不以"所有项目都接入"为目标，而是以"管理者第一次不需要开口问、打开系统就能看到项目真实状态"为第一阶段验收标准。

项目立项与采购管理平台

## 项目不是一张任务表，而是一条决策链

大多数项目管理工具解决的是"执行"问题——任务分配、进度跟踪、看板协作。但一个项目在执行之前，需要经过能不能做、谁来做、花多少钱、签什么合同等一系列决策。这些决策通常散落在邮件、会议纪要和 Excel 台账里，没人能完整追溯。

项目立项与采购管理平台面向需要正规治理流程的组织——聚焦项目从规划到签约的决策阶段，将年度计划、预算编制、需求论证、采购流程、合同管理和供应商管理串联在一条审批线上。平台已在大型机构的技术管理部门稳定运行多年，支撑数百个项目的立项与采购管理。

设计理念

立项和采购不是填一张申请表，而是一条需要多角色、多层级参与决策的治理链。

平台将"能不能做（规划预算）→ 做什么（需求论证）→ 怎么做（采购方式）→ 谁来做（供应商选择）→ 多少钱（合同与付款）"五个决策环节串成一条线，每一步都有审批、有留痕、有数据。不是靠人盯人推动流程，而是流程本身驱动角色在正确的时间做正确的决策。

年度规划→预算编制→需求论证→采购方式→供应商选择→合同签订

## 平台能力结构 | 层级 | 主要能力 | 管理价值 | |---|---|---| | 规划预算层 | 年度项目计划、年度预算编制与跟踪、部门重点工作 | 从"年底突击立项"转向"按规划有序推进" | | 需求管理层 | 业务方案、需求说明书、需求评估问卷、需求变更 | 需求从提出到确认的全流程合规留痕 | | 采购决策层 | 采购申请、招标流程管理、多级会议审批 | 采购方式选择有依据，决策过程可追溯 | | 合同付款层 | 合同管理、付款节点跟踪、验收管理、预算执行 | 合同关联项目，付款关联预算，执行情况实时可见 | | 供应商管理层 | 厂商信息、人员入场退场、考勤打卡、费用结算 | 从人员入场到费用结算的全流程闭环 | ## 核心模块 ### 年度规划与预算每年底启动下一年度项目规划。各部门提报项目计划，汇总后形成年度项目清单。每个规划项目关联预算编制——预算总额、资金来源、分项预算明细。年度预算支持 Excel 批量导入和逐项填报两种方式。部门年度重点工作可与规划项目关联——"今年要完成的 N 件大事"与具体的项目计划挂钩，避免重点工作和日常工作两张皮。驾驶舱视图实时展示年度计划执行率、预算使用率和部门重点任务完成进度。 ### 需求全过程管理需求不是一张工单，而是一条需要层层确认的决策链。

业务方案→需求说明书→需求评估→需求变更→需求公示

| 环节 | 说明 | 审批节点 | |---|---|---| | 业务方案 | 业务部门提出项目需求和初步方案，提交审批 | 部门负责人 → 技术评审 | | 需求说明书 | 将业务方案细化为可执行的技术需求规格 | 技术负责人确认 | | 需求评估 | 组织专家对需求进行可行性、成本、周期评估 | 支持问卷打分和汇总 | | 需求变更 | 执行过程中的需求调整 | 变更影响评估 → 多级审批 | | 日常需求收集 | 零星需求的统一入口 | 需求池管理，按优先级排期 | | 意见征集 | 对方案或制度发起意见征集 | 收集反馈 → 确认闭环 | ### 多类型会议与审批决策平台内置五种正式会议类型的全流程管理，覆盖技术评审、采购决策和重大事项审议： | 会议类型 | 适用场景 | 核心功能 | |---|---|---| | 专家评审会 | 技术方案、架构设计的外部专家评审 | 议题提交、专家分配、评审表、结论记录 | | 科技管理委员会 | 技术战略和重大技术决策 | 议题排序、投票记录、决议生成 | | 总裁办公会 | 采购事项和重大业务决策 | 采购议案提交、审议意见、最终决策 | | 党委会 | 重大事项的前置审议 | 议题审核、前置程序、决议归档 | | 采购会 | 采购方式和采购结果的评审决策 | 采购方案评审、供应商选择、结果确认 | 每个会议类型包含：会议创建 → 议题征集和排序 → 专家/评委分配 → 会议召开和结果记录（通过/不通过/有条件通过）→ 会议纪要生成和归档。会议材料支持批量打包下载。会议统计按类型、按年份展示通过率、参会情况和议题分布。 ### 合同与付款管理合同信息结构化存储——签约方、金额、期限、付款节点、关联项目。合同模板支持信息自动填充，减少重复录入。付款管理按合同付款节点跟踪：每个合同定义多个付款节点，每个节点的支付金额、支付条件和实际支付状态一目了然。支付记录与年度预算关联，预算执行偏差实时可见。验收管理包括上线验收和中期款验收——验收通过后触发对应的付款节点，避免"未验收已付款"或"验收后遗忘付款"。 ### 供应商与人员管理对依赖外部供应商和外包人员的组织，平台提供从厂商入库到人员离场的全流程管理。 **厂商管理**：合作厂商的基本信息、资质文件、人员报价。厂商订单关联到具体项目，按订单管理厂商的人力投入。 **人员入场到离场**：

厂商入库→面试订单→人员入场→考勤打卡→月度核验→季度结算→人员退场

**考勤与结算**：外包人员通过企业微信 GPS 打卡，系统按打卡记录自动计算出勤天数。月验单和季验单自动汇总考勤数据，与厂商报价关联后计算结算金额。支持多办公地点、多打卡规则的灵活配置。支持虚假考勤记录的处理和节假日调休的自动计算。 ## 适合什么场景

技术部门需要正规项目立项和采购流程数百个项目并行的复杂项目组合管理依赖外部供应商和外包人员的组织需要多级会议审批和合规留痕年度预算与项目执行需要打通的场景合同管理和付款跟踪分散需要统一外包人员考勤和结算靠手工核对

平台的适用边界不是行业，而是**管理的复杂度与合规要求**——当项目数量多、采购金额大、供应商和外包人员多、需要多层级多类型的审批决策时，轻量协作工具就不够了。 ## 建设边界

替代财务总账或ERP系统替代电子招投标平台替代电子签章系统提供工程造价或成本估算功能

平台定位是在财务系统和招投标平台之上建立项目立项与采购的治理层。预算编制和合同数据可导出至财务系统，但不替代财务核算。 ## 可以如何开始

梳理一个年度的规划流程

从年度项目计划和预算编制开始，建立线上填报和审批流程，替代 Excel 收集。

选择一种会议类型试点

从使用频率最高的会议类型开始，跑通议题征集、专家分配、结果记录全流程。

接入供应商数据

录入合作厂商信息、人员清单和报价，开始线上考勤和月度结算。

建立管理基线

积累一个完整年度的规划、预算和合同数据后，建立下一年度的管理基线。

业务规则库建设

## 这个产品是什么把制度条款和审核经验转为结构化规则，供流程和 AI 统一调用。 ## 它解决什么问题 - 规则散落在制度和个人经验 - 规则更新无法同步到系统 - 审核口径难统一 ## 可以如何试点先梳理一个业务域的规则条目，建立变更管理和执行验证机制。

知识图谱与标签体系

## 这个产品是什么通过实体关系建模和标签体系，把“对象-关系-证据”沉淀为可计算结构。 ## 它解决什么问题 - 只能按关键词搜，不能按关系分析 - 跨对象关联难以发现 - 知识资产难复用 ## 可以如何试点从单一主题图谱起步，先验证关系查询和推荐价值，再扩展范围。

指标体系与数据治理

## 这个产品是什么围绕核心指标建立口径、来源、责任与权限边界，让数据可解释、可追责。 ## 它解决什么问题 - 同名指标含义不一致 - 报表“数字对不上” - 权限与口径缺少治理 ## 可以如何试点选一个管理主题先治理指标字典，再逐步扩展到更多业务域。

管理驾驶舱 / 数据看板

## 这个产品是什么基于统一指标体系搭建管理看板，支持分层查看、趋势追踪和专题分析。 ## 它解决什么问题 - 管理决策缺少实时视图 - 数据展示与业务解释断层 - 专题分析周期长 ## 可以如何试点先做一个核心看板，明确受众、指标和更新机制。

既有系统 AI 增强

## 这个产品是什么

很多企业并不缺业务系统，真正的问题是系统只能记录和流转，查资料、核附件、读制度、做汇总和催进度仍然高度依赖人工。

完全推翻旧系统代价高、周期长、风险大；单独上线一个 AI 工具，又容易与账号、权限、数据和业务状态脱节。演示时能回答问题，进入真实工作后却无法调用可信数据，也不能把结果送回原有流程。

旧系统能运行，但操作负担重

用户需要反复检索、复制、核对和填报，系统保存了数据，却没有减少多少认知工作。

AI 独立在外，拿不到业务上下文

通用助手不了解当前用户、业务对象、审批状态和企业内部规则，回答难以直接采用。

重建成本高，Demo 又无法上线

企业既不适合推倒重来，也不能接受 AI 长期停留在无法进入流程的展示阶段。

产品定位

既有系统 AI 增强不是再建设一套孤立平台，而是在保留原有权限、数据和流程的前提下，为明确业务节点增加智能能力。

我们从一个具体动作切入，例如制度查询、附件核验、表单预填、风险提示或数据解释；先确认 AI 能读取什么、依据什么、输出给谁，再通过页面组件、接口或流程节点嵌入原系统。

选择业务节点→确认数据与权限→接入 AI 能力→嵌入原有流程→人工确认→效果反馈

## 它解决什么问题

知识查询增强

在原系统对象和权限范围内查询制度、流程、项目材料与历史经验。

fact_check

审核核验增强

对合同、附件和申报材料执行规则检查，给出问题与依据。

document_scanner

识别录入增强

从 PDF、图片和表格提取字段，辅助预填原系统业务表单。

notification_important

提醒分办增强

结合业务状态识别逾期、缺项与待处理事项，辅助分办和提醒。

query_stats

分析解释增强

面向既有指标和结构化数据提供查询、归纳和异常解释辅助。

edit_note

作业辅助增强

根据当前流程上下文生成摘要、处理建议或文稿初稿，由人员确认。

## 接入方式 | 接入层 | 典型方式 | 需要确认的条件 | |---|---|---| | 页面入口 | 侧边助手、审核按钮、字段建议、结果面板 | 页面是否可扩展，用户当前在处理什么对象 | | 数据上下文 | API、数据库视图、文件与知识库检索 | 数据来源、更新频率、字段含义与访问权限 | | 流程联动 | 待办、消息、表单预填、状态回写 | 哪些动作可自动执行，哪些必须人工确认 | | 身份权限 | 沿用原系统用户、角色与数据范围 | AI 是否与原系统执行相同的权限过滤 | | 运行治理 | 调用日志、依据引用、人工反馈、效果统计 | 如何追溯结果、发现错误并持续修正规则 | 接入深度取决于原系统的接口能力、部署环境和数据质量。对于无法安全开放写入权限的系统，可先从只读查询、辅助审核或结果导出开始。 ## 适合什么客户 / 场景 - 已有 ERP、OA、科研、项目、档案或行业业务系统 - 不计划推倒重建，但希望降低用户查询、核对和整理负担 - 有明确高频业务节点，而不是只想建设一个通用聊天入口 - 对权限、依据追溯、私有化部署或人工复核有要求 ## 建设边界

在数据基础不清晰时直接上线智能问答绕过原系统权限访问数据让 AI 自动完成高风险审批用模型猜测缺失业务状态一次性改造所有系统以 Demo 效果代替生产验证

AI 增强不会自动解决原系统已有的数据质量、流程冲突和权限混乱。试点前必须确认权威数据来源、业务责任和人工兜底方式。 ## 可以如何试点

选一个高频动作

从查询、核验、预填、提醒或分析中选择边界明确的节点。

检查接入条件

确认页面入口、接口、权限、数据质量和部署限制。

嵌入真实流程

让实际用户在原业务环境中使用，而不是单独观看 Demo。

评估是否扩展

比较处理时间、人工采纳和错误情况，再决定下一个节点。

流程自动化

## 这个产品是什么针对高频重复流程构建自动化作业链，减少人工重复操作。 ## 它解决什么问题 - 手工分办和提醒效率低 - 重复录入导致数据误差 - 流程状态追踪困难 ## 可以如何试点优先选择规则明确、量大稳定的流程节点做自动化。

OCR / 文档识别

## 这个产品是什么把非结构化材料转成结构化字段，为核验、比对和流程流转提供输入。 ## 它解决什么问题 - 材料录入依赖手工 - 图片/PDF 信息无法直接利用 - 字段一致性检查成本高 ## 可以如何试点从单一证照或附件类型起步，验证识别准确率和字段回填效果。

系统升级与长期运维

## 这个产品是什么面向存量系统提供持续演进服务，包含升级改造、性能优化和日常运维保障。 ## 它解决什么问题 - 老系统技术债影响迭代效率 - 版本升级风险高 - 运维响应机制不稳定 ## 可以如何试点先做系统健康检查与优先级梳理，确定季度迭代清单和运维SLA。

KnoProbe AI 应用底座

## 这个产品是什么

企业 AI 从演示走向生产，真正缺少的通常不是另一个模型接口，而是一层能够解释“企业如何运行”的业务上下文。

制度和文档散落在文件库，审核标准留在个人经验里，流程状态存在业务系统中，用户权限又分布在不同平台。AI 如果只看到一段提问，就不知道当前处理的是哪个项目、适用哪条规则、可以读取哪些资料，更不知道结果应该进入哪个业务节点。

有知识，但缺少可用上下文

文档可以被检索，却没有与业务对象、版本、权限和当前流程建立稳定关联。

有模型，但不理解企业规则

通用模型能够生成流畅回答，却不知道组织内部的判断标准和例外条件。

有 Demo，但无法进入业务执行

回答停留在聊天窗口，难以结合真实状态、待办和人工反馈逐步进入业务流程。

底座定位

KnoProbe 不是一个面向所有人的通用聊天产品，而是连接知识、规则、流程与业务系统的 AI 应用底座。

它把企业资料、业务语义、检查规则、系统权限和执行接口组织成 AI 可以安全使用的上下文，支撑知识问答、文档审核、材料核验、流程助手等具体应用持续演进。

客户先看到什么

support_agent

AI 接待员

把企业资料变成官网、公众号或内部入口中的可追溯问答助手，回答有来源，复杂问题可转人工。

fact_check

AI 作业员

上传合同、制度、申报材料或业务附件，按规则逐项检查，输出风险清单、修改建议和审查报告。

底座能力的意义，是让这些应用不必每次从零搭建知识接入、规则配置、权限控制、证据链和人工复核机制。

知识接入→语义与规则组织→流程上下文→AI 业务作业→系统联动→人工反馈

## 核心能力

cloud_upload

多源知识接入

接入制度、文档、表格、附件和业务数据，并保留来源与版本信息。

hub

业务语义组织

把项目、人员、订单、成果等业务对象及其关系组织为可理解上下文。

rule

规则显式配置

沉淀审核、字段、流程和风险规则，让 AI 按企业标准执行作业。

lan

既有系统联动

按试点范围对接接口、权限、待办和业务状态，使 AI 结果能够逐步进入真实流程。

description

正式产物与证据链

输出风险清单、审查报告、补正清单、结构化结果或可下载文档，并保留对应依据。

model_training

反馈持续迭代

保存采纳、修改和拒绝结果，用于修正规则、知识和作业流程。

## 底座能力结构 | 层级 | 主要内容 | 对上层应用的作用 | |---|---|---| | 接入层 | 文档、数据库、业务接口、文件与模型服务 | 提供受控的数据和模型连接 | | 知识语义层 | 文档切分、元数据、业务对象、关系与检索 | 让结果有来源，并理解对象之间的联系 | | 规则流程层 | 检查规则、字段规则、任务步骤、权限与状态 | 约束 AI 如何判断、何时执行以及谁来确认 | | 应用作业层 | 问答、审核、核验、识别、提醒和处理建议 | 将底座能力包装成可使用的业务场景 | | 治理反馈层 | 日志、引用、人工反馈、效果评估与版本记录 | 支持追溯、纠错和持续演进 | ## 可以支撑哪些应用 ### 主推试点

contract_edit

AI 文档审核

按企业规则检查合同、制度和业务文档，输出风险、依据与修改建议。

verified

材料与证照核验

识别申报材料、证照与附件字段，检查缺项、格式和跨材料一致性。

menu_book

企业知识问答

基于制度、流程和专业资料回答内部问题，并引用对应来源。

forum

官网与业务接待

在客户入口中完成可追溯答疑、需求识别、信息收集与转人工。

### 可扩展场景

流程作业助手制度与规则查询科研知识关联既有系统 AI 增强

这些应用可以独立试点，也可以复用同一套知识、规则、权限和系统连接。底座的价值不是让所有场景共用一个提示词，而是避免每做一个 AI 应用都重新搭建数据接入、权限控制和追溯机制。 ## 与常见平台的差异 | 方案类型 | 主要关注点 | KnoProbe 的侧重点 | |---|---|---| | 通用模型 API | 提供生成与推理能力 | 补充企业知识、规则、权限和业务上下文 | | RAG 知识库 | 文档检索与问答 | 在检索之外连接规则、流程和系统动作 | | 工作流编排工具 | 串联模型、接口和处理节点 | 强调业务对象、依据追溯与人工反馈闭环 | | 单点 AI 应用 | 快速解决一个明确问题 | 为多个场景复用接入、治理和系统联动能力 | ## 适合什么客户 / 场景 - 已经验证一个 AI 场景，希望继续扩展更多业务作业 - 已经有业务系统或资料库，但 AI 仍停留在独立聊天窗口，无法进入审核、核验、问答、提醒或结果回写等真实业务动作 - 需要连接内部文档、规则和既有业务系统 - 对结果依据、权限隔离、人工复核和过程留痕有要求 - 希望支持私有化或受控部署，并持续更新知识和规则 ## 建设边界

替代所有既有业务系统在没有数据治理时自动理解全部资料绕过原系统权限调用数据让 AI 自主承担最终业务责任把所有场景一次性平台化只部署底座而不验证具体应用

KnoProbe 是否需要建设，取决于客户是否存在可复用的知识、规则、系统接入和治理需求。对于只有单一、短期场景的项目，优先交付具体应用通常更简单；当多个场景开始重复使用同一批上下文和系统能力时，底座价值才会显现。 ## 可以如何试点

拿一份真实材料来试

选择一份合同、申报材料、制度或一组真实问答，明确希望 AI 完成的动作。

接入最小上下文

只接入该场景所需的知识、规则、权限和业务对象。

进入真实流程

让结果可引用、可复核，并与现有入口或系统发生联动。

判断复用价值

当第二个场景出现时，验证底座能力是否真正能够复用。