AI 应用AI 写作人工智能AI Agent企业应用【免费下载链接】OpenBidKit_Yibiao开箱即用的AI标书编写工具标书AI生成工具投标工具箱、知识库、标书查重、废标项检查完全开源免费欢迎使用项目地址https://gitcode.com/gh_mirrors/op/OpenBidKit_Yibiao点击查看免费下载本篇技术指南围绕 OpenBidKit开源 AI 标书编写工具的标书检查 → 废标项检查功能展开完整讲解从选择招标/投标文件、提取无效投标与废标条款、补充自定义检查项到三类 AI 审计废标项、错别字、逻辑谬误结果解读与人工复核的完整流程并结合仓库源码说明背后的任务编排、提示词边界与数据持久化实现原理。读完本文你将能够熟练使用废标项检查功能为投标文件做提交前的系统性风险筛查并理解其输出结果为什么只能作为辅助、必须人工复核。一、功能定位用 AI 做提交前的硬性要求响应审计投标文件能否被认定有效往往取决于是否响应招标文件中的无效投标与废标项硬性要求。这类条款数量多、措辞绕、容易遗漏人工逐条核对成本极高。OpenBidKit 的废标项检查正是为此设计以招标文件中解析出的无效投标与废标条款为检查口径自动审阅投标文件正文输出风险清单。从源码结构看该功能在仓库中由一套完整的前后端模块支撑前端页面RejectionCheckPage.tsx负责三步向导与三类结果 Tab 渲染状态与类型定义types.ts后台任务编排rejectionCheckTask.cjs数据持久化rejectionCheckStore.cjsIPC 桥接rejectionCheckIpc.cjs。结果页共包含三类检查顶部均显示已完成后再查看检查类别检查内容废标项检查检查投标文件是否响应硬性要求按无效标invalidBid与废标项rejectionItem两类风险输出错别字检查检查明显的文字错误输出错字、建议正确字词与原文片段逻辑谬误检查检查前后矛盾、时间不一致和参数冲突等问题二、操作流程四步完成一次完整的废标项检查1. 进入入口在左侧点击标书检查 → 废标项检查进入三步向导。前端以steps: [documents, items, results]对应三个步骤页签选择标书、无效与废标项、检查结果见 RejectionCheckPage.tsx 的stepLabels定义。2. 选择招标文件和投标文件第一步选择需要检查的招标文件与投标文件招标文件支持一份或多份上传也可从技术方案直接导入IPC 通道rejection-check:import-tender-from-technical-plan见 rejectionCheckIpc.cjs投标文件支持一次选择多份可同时检查同一投标包下的多份文件每份文件会被分配唯一的bidDocumentId形如bid-xxxx由文件名与正文内容哈希生成。导入时rejectionCheckStore.cjs 会按文件名 内容哈希对重复文件去重并跳过避免同一文件重复解析解析后的正文以 Markdown 形式落盘到工作目录的rejection-check/目录下并登记到 SQLite 数据库供后续检查任务读取。3. 点击下一步等待软件提取无效投标和废标条款点击下一步后后台启动rejection-items-extraction任务调用 AI 从招标文件正文中提取无效投标与废标项条款作为后续检查的检查口径。提取任务的定义在 bidAnalysisTask.cjs无效投标投标人、投标文件、签章密封、递交时间、报价、保证金、资格条件、实质性响应等原因导致投标被认定为无效、否决、不予受理或按无效响应处理的情形废标项可能导致项目废标、采购失败、重新招标、终止评审、有效投标人不足或实质性响应不足的条款或风险项招标文件中出现否决投标投标无效不予受理无效响应重大偏差实质性偏离废标情形等同义表达时也按上述边界归类。提取状态在界面中显示为待解析 / 解析中 / 已完成 / 解析失败解析进度会通过任务日志实时写入数据库见 rejectionCheckStore.cjs 中rejection_check_extraction表的持久化逻辑。4. 检查提取结果必要时补充自定义检查项第二步无效与废标项页有两个页签解析结果与自定义检查项解析结果核对 AI 从招标文件中提取出的无效投标与废标条款是否完整、准确自定义检查项可补充用户自己关注的检查点。补充的内容会拼接进检查提示词但提示词明确要求仅在能从电子投标文件正文、目录、附件文本或材料内容中判断时使用如果涉及签字、盖章、密封、现场递交、纸质正副本等纸质或线下事项必须忽略。5. 点击下一步 → 开始检查等待全部任务完成第三步可勾选要启用的检查类型默认三种全部启用rejectionCheck、typoCheck、logicCheck默认均为 true见 rejectionCheckStore.cjs 的initialState。点击开始检查后后台启动rejection-check-run任务三种检查并行执行每项独立显示运行状态与进度界面顶部只有对应检查显示已完成后其结论才可供查看。三、检查结果解读与人工复核按投标文件筛选结果可按投标文件筛选便于聚焦某一份文件的响应情况——检查时每份投标文件都会拿到独立的bidDocumentId每条风险都会明确标注属于哪份文件。展开问题查看原文与位置、原因和建议点击任意一条结果可展开详情对应前端组件RejectionFindingItem/TypoFindingItem/LogicFindingItem见 RejectionCheckPage.tsx废标项检查展示检查依据投标文件证据风险原因处理建议四个字段风险带invalidBid无效标或rejectionItem废标项标签并标注高 / 中 / 低三级风险错别字检查展示错字 → 建议正确字词、原文内容错字在原文片段中高亮标记与判断原因并提供复制错字复制原文按钮逻辑谬误检查展示原文与位置谬误原因修改建议三个字段。确认误报时可删除该条若认为某条结论属于误报可直接删除该条删除结果不会影响其他条目。导出 Excel 复查检查完成后可将全部结果导出为 Excel 复查或归档。导出逻辑位于 checkResultExportService.cjs导出文件包含 4 个工作表检查概览、废标项、错别字、逻辑问题并通过 exportState.ts 校验结果与当前输入签名一致防止文件已变更但导出旧结果。人工复核是最后一道防线AI 检查结果只作为辅助提交标书前仍需人工复核。这是该功能设计的核心原则AI 只能基于文本解析后的电子正文进行判断签字、盖章、密封、现场递交等线下事项不在检查范围内且材料是否缺失等判断受限于解析完整性因此最终结论必须以人工核对原件为准。四、源码实现原理三轮检查与长文本滚动审阅提取任务与检查任务的编排整个功能由两个后台任务驱动状态全程持久化任务类型对应实现职责rejection-items-extractionrejectionCheckTask.cjs 中的runRejectionItemsExtractionTask从招标文件提取无效投标与废标条款rejection-check-run同文件中的runRejectionCheckTask并行执行废标项 / 错别字 / 逻辑谬误三项检查检查任务会先校验至少启用一种检查已完成无效与废标项解析等前置条件再通过Promise.all并行跑三个子任务任一失败都会在整体任务状态中标记为 error 并保留日志见runRejectionCheckTask的实现。废标项检查三轮递进式检查废标项检查采用先分析范围、再逐项检查、最后定稿的三轮递进策略提示词定义见 rejectionPrompts.ts第一轮分析——梳理哪些条款能通过电子投标文件内容判断明确排除签字、盖章、密封、纸质正副本、现场递交等纸质或线下事项并指出重点核查章节第二轮检查——基于分析结论逐项检查投标文件输出初步风险列表每条必须有投标文件中的明确证据第三轮补充与定稿——对第二轮结果去重、合并、补漏删除不满足证据要求的条目最终只输出 JSON。三个关键约束贯穿全程证据优先每条风险必须有投标文件原文中的明确证据证据不足不输出结构线索原则判断材料缺失时只要目录、章节标题、附件标题、材料清单、表格条目、页码线索、图片占位线索等结构性文本线索中出现过对应材料就视为至少存在提交线索不得判定为缺失不能仅因图片、扫描件正文不可见就输出缺失风险排除线下事项签字、盖章、密封、纸质正副本、现场递交、开标现场行为等一律不纳入电子文件检查。长文本自适应分段滚动审阅投标文件动辄数十万字一次性塞进上下文既超限又易遗漏。源码在 rejectionCheckTask.cjs 中实现了两套执行路径上下文容量足够时走三轮直通流程内容超长时通过splitUserTextByContextLimit按模型上下文上限判断自动切换为滚动审阅将多份投标文件按上下文长度切成片段逐段审阅并输出增量 patch新增证据、待确认风险、确认风险、排除项程序端维护权威累计状态最后按批次定稿并做全局合稿避免早期片段的证据丢失或误判对应runRollingRejectionItemCheck与runRollingLogicCheck。错别字检查也有对应的分段策略runSegmentedTypoCheck并且每条错别字都会在原文中做位置校验——先按片段偏移定位再生成以错字为中心的原文摘录防止模型编造原文片段。数据持久化与断点续跑rejectionCheckStore.cjs 通过 SQLite 将整个工作区状态落盘文档rejection_check_documents、提取结果rejection_check_extraction、三类检查结果rejection_check_risk_findings/typo_findings/logic_findings、任务进度rejection_check_tasks以及界面元信息rejection_check_meta。每次检查都会计算输入签名inputSignature用于判断结果是否与当前文件内容匹配——文件一变旧结果即失效从机制上避免看旧结论交新标书的隐患。五、关键 JSON 结构与字段说明废标项检查的每条结果遵循统一 JSON 结构提示词中明确约束源码在normalizeRejectionCheckFindings中做归一化兜底{ findings: [ { bidDocumentId: 对应投标文件的 bidDocumentId, type: invalidBid, severity: high, title: 不超过 28 个中文字符的风险标题, summary: 一句话概括风险, requirement: 对应检查依据或招标要求尽量引用原检查项, bidEvidence: 投标文件中的明确证据、章节、原文摘录或缺失位置说明, riskReason: 为什么该证据可能构成无效标或废标项风险, suggestion: 建议用户如何处理或复核 } ] }字段约束如下字段取值/含义type仅invalidBid无效标或rejectionItem废标项severity仅high/medium/lowtitle不超过 28 个中文字符的简短标题便于折叠列表展示bidEvidence必须有原文证据否则该条会被过滤掉bidDocumentId必须来自本次输入中的有效 ID错别字检查结果为wrongText原文错字/短词、correctText建议正确字词、originalExcerpt包含错字的原文短片段、reason判断原因逻辑谬误检查结果为title、originalText关键原文摘录可含同一份文件内多处、locationHint大概位置、章节、表格或上下文线索、fallacyReason谬误原因、suggestion修改建议。没有问题时返回{findings:[]}不会强行输出低质量条目。六、注意事项与使用边界仅覆盖电子正文可判断的事项签字、盖章、密封、纸质正副本、现场递交、纸质原件等线下事项不在检查范围内相关风险不会输出需要人工线下核对材料缺失判断受解析完整性影响图片、扫描件、附件页等非文本内容可能被过滤因此缺失结论只有在没有任何结构线索时才会给出反之存在章节标题等提交线索时应人工复核内容完整性而非直接视为缺失结果随输入变更失效更换投标文件、招标文件或修改自定义检查项后历史检查结果会被清除或标记为不匹配需要重新发起检查AI 结论仅供参考所有风险都应按检查依据 → 证据 → 风险原因 → 处理建议的链路人工复核后再处理删除误报条目是流程的合法组成部分。通过以上流程OpenBidKit 的废标项检查可以在提交标书前快速完成一轮覆盖硬性要求响应、文字质量和逻辑一致性的系统性筛查而源码中三轮递进 长文本滚动审阅 原文位置校验 输入签名失效的设计保证了检查在大文件、多文件场景下的证据可信度——这正是它作为 AI 辅助工具而非替代人工复核的价值所在。赞分享AI 应用AI 写作人工智能AI Agent企业应用【免费下载链接】OpenBidKit_Yibiao开箱即用的AI标书编写工具标书AI生成工具投标工具箱、知识库、标书查重、废标项检查完全开源免费欢迎使用项目地址https://gitcode.com/gh_mirrors/op/OpenBidKit_Yibiao点击查看免费下载相关推荐opencodex 中 encrypted: true Schema 标记的跨 Provider 风险审计与防御性清理实战opencodex 中 encrypted: true Schema 标记的跨 Provider 风险审计与防御性清理实战 本文围绕 opencodex 对上游让风扇不再自己决定转速FanControl 新手实操教程让风扇不再自己决定转速FanControl 新手实操教程 打游戏一开显卡风扇立刻拉满整个房间像小机库切回桌面又突然安静你开始担心热量堆着。这是 PC桌面应用智能硬件agent-governance-toolkit EU AI Act 合规检查器实践指南风险分级、条款级检查与部署门禁agent governance toolkit EU AI Act 合规检查器实践指南风险分级、条款级检查与部署门禁 本篇围绕 AgentMesh 示例 0人工智能AI AgentAI 安全治理策略引擎认证鉴权Agent 沙箱可观测性上一篇三种模式、二十多个引擎让游戏翻译自动跑起来下一篇Video2X 6.0.0免费AI视频增强神器让老旧视频重获新生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考