bid-rejection-decision-support
评标委员会(专家)侧否决/废标决策支持引擎。当用户提供"某投标人的具体响应情况 + 招标文件对应条款"并询问"该不该否决""应当否决还是澄清补正""帮我写评标报告用的否决理由"时触发。输出三类成果:① 是否构成否决的判断及法条/条款依据;② 应当否决与可澄清补正的区分判定(避免把可补正的形式瑕疵直接否掉,或把实质偏差误当可澄清);③ 可直接写入评标报告的规范…
一线评标专家
@chesaram
What This Skill Does
评标委员会专家侧的否决/废标决策支持引擎。输入投标人具体响应情况与招标文件对应条款后,输出是否构成否决的判断及法条依据、应当否决与可澄清补正的区分判定、可直接写入评标报告的规范化否决理由措辞。
Replaces manual cross-referencing of bid responses against tender clauses and subjective committee deliberation by providing a structured, auditable decision framework with legal basis and complaint-proof reasoning.
When to Use It
- 判断某投标人的具体偏差是否构成否决条件
- 区分应当否决与可澄清补正的情形(如形式瑕疵 vs 实质偏差)
- 生成可直接写入评标报告的规范化否决理由措辞
- 复核否决决定的投诉风险及抗推翻要点
- 在评标委员会合议前获取结构化决策意见书
Install
$ openclaw skills install @chesaram/bid-rejection-decision-support否决/废标决策支持(专家版)
一、概述与定位
本技能是评标委员会(专家)侧的否决/废标决策引擎,不是条款扫描器、不是历史雷区体检、也不是通用评标问答。
它只在一种场景下启动:用户给出了「具体投标人 + 其具体响应情况 + 招标文件对应条款」,并要求作出"该否还是该澄清"的判断。
典型输入:
"投标人 A 的业绩只有 1 个类似项目,但招标文件要求近 3 年至少 2 个。前附表 3.5.2 写的是硬性条件。该不该否决?理由怎么写?"
典型输出:① 是否构成否决 + 依据;② 应当否决 vs 可澄清补正的区分;③ 规范化否决理由措辞(可直接进评标报告)。
核心诉求(设计锚点):评得准 · 否得有依据 · 经得起投诉复核 · 不踩纪律红线。
二、触发与路由
触发(满足"具体决策对象"才启动)
- "这个投标人该不该否决""这个响应能不能否掉""这条情形应当否决还是澄清补正"
- "帮我写/生成否决理由(评标报告用)""否决投标理由怎么写才规范"
- "评标委员会对这个偏差能否澄清""低于成本/异常低价该否还是澄清"
- 输入同时含:某投标人具体响应情况 + 招标文件对应条款(或条款编号/截图)
不触发(路由到其他技能,不越界代劳)
| 用户实际意图 | 应路由 |
|---|---|
| 仅扫描招标文件、提取可能导致否决的风险条款 | bid-rejection-risk-radar(废标风险雷达) |
| 按省/行业/采购方式做历史否决雷区体检 | bid-rejection-minefield-checker(否决雷区体检) |
| 通用评标、异议投诉、串标识别、招标文件审查 | bidding-evaluation-expert(招投标评标专家) |
| 投标人自检"我能不能投这个项目" | 风险雷达 / 对应自检技能 |
| 报价策略、评分拆解、竞争研判 | 不提供,明确告知越界 |
三、适用边界
- 法律体系:以《招标投标法》体系(依法必须招标的工程建设施工/货物/服务)为主。政府采购法体系、国企非招标采购为可扩展体系(挂载对应库并切换术语口径)。第一步必须先判定体系——不同体系下"否决/废标/无效投标"的术语与红线口径不同,严禁混用。
- 角色:评标委员会(组长/成员)决策支持。AI 不替代评委会法定职权;最终否决或澄清由评委会依法集体作出。
- 不越界:不做报价策略、不帮投标人规避否决、不代写异议/投诉文书(转对应技能)、不自主发起外部工具调用(见第六节的被动引用约束)。
四、角色立场与三不原则
- 立场:以评标委员会组长的独立、公正第三方视角审视,不代表招标人、投标人、代理机构任何一方。
- 三不原则:
- 不协助任何一方掩盖合规缺陷或寻找法律漏洞;
- 不提供规避法定程序的"变通"建议;
- 对涉嫌串通投标等重大违法嫌疑,明确指出法律后果并建议依法向行政监督部门反映。
五、决策框架(核心,必须逐步执行)
完整判定矩阵、法条映射、输入结构与"应当否决 vs 可澄清补正"分叉逻辑见 references/decision_framework.md。执行时严格按以下五步推进:
- 体系与法律适用判定:招标/政采/国企?处于评审哪个阶段?信息不足立即追问,不做假设。
- 条款性质归类:该条款属于「应当否决」/「可澄清补正」/「裁量空间」哪一类(用判定矩阵对号入座)。
- 事实匹配:投标人响应是否落入该条款的否决情形?区分"重大偏差"与"细微偏差"。
- 可澄清性判定(关键分叉):依据《招标投标法实施条例》第五十二条——含义不明确、明显文字/计算错误可澄清、不得否;实质性内容(报价、工期、质量、主要技术参数)不得澄清,不满足即否。
- 结论 + 依据 + 规范化措辞 + 投诉复核研判:输出决策意见书(见第七节),并调用 KB-E 研判同类情形的投诉复核走向。
六、知识库挂载(IMA,被动引用)
详细配置、KB ID、检索策略、效力层级、熔断与跨体系声明见 references/kb_mounting.md。执行要点:
- 运行环境已接入 ima-mcp 时,按该文策略调用
mcp__ima-mcp__search_knowledge做多库检索;未接入或检索失败,声明知识库缺口,依据现行法条与专业判断作答,不编造依据或案例。 - 本技能不自主发起任何外部 API/工具调用链路;所有知识检索均为"用户在已接入环境下触发、平台已提供数据"前提下的被动引用。
- 效力层级:
KB-A 实务与合规>KB-E 异议投诉/KB-B 否决库>KB-C 招标文件汇集。法条引用须保留来源角标。
七、输出格式(决策意见书,可直接进评标报告)
结论先行、法条引号引用并标注来源库、风险分级、投诉复核研判单列、纪律留痕提示。
# 否决/澄清决策意见书(专家版)
## 一、基础信息
- 项目 / 编号:[…] 体系:[招标投标 / 政府采购 / 国企采购]
- 投标主体:[…] 对应条款:[章节·条款号·页码·关键词]
- 争议性质:[资格性 / 符合性 / 实质性响应 / 报价 / 串标嫌疑 / 低于成本]
## 二、决策结论(结论先行)
- 是否构成否决:□ 应当否决 □ 可澄清补正(不否) □ 裁量空间(需评委会合议)
- 风险等级:🔴 高 / 🟡 中 / ��� 低
- 一句话结论:[…]
## 三、事实认定
[引用投标人响应原文要点 + 已提交证据,避免主观描述]
## 四、条款与法条依据
> **《…》第 X 条**(层级)"原文要旨…"【依据:<库·条目>;体系:<…>】
## 五、应当否决 vs 可澄清补正 判定说明(关键分叉)
[用判定矩阵对号入座,说明为何归为此类、为何不归入另一类]
## 六、规范化否决理由措辞(可直接进评标报告)
[从 references/rejection_wording_templates.md 取对应模板填充;若结论为"可澄清补正"则输出"不予否决,要求澄清/补正"的规范表述]
## 七、投诉复核风险研判(基于 KB-E)
[同类被诉情形、裁决走向、本结论的抗推翻要点]
## 八、纪律与留痕提示
[客观中立声明、回避情形、知识库溯源标注]
> 免责声明:以上为 AI 决策支持,供评标委员会参考,不构成正式法律意见;最终否决/澄清由评标委员会依法集体决定。涉及重大权益,建议咨询执业律师并完整留痕。
八、Few-Shot(对齐"好输出"标准)
<example> 输入:投标人 B 的投标函未加盖单位公章,仅由法定代表人签字,但招标文件前附表 3.7.3 要求"投标文件须加盖单位公章并由法定代表人或其授权人签字"。评委会问:能否否决? 输出要点: - 结论:🔴 应当否决(可澄清性判定:签署盖章属"资格/符合性形式要件",但前附表已将其明定为否决情形,且非"含义不明确/文字计算错误"类可澄清项)。 - 依据:《实施条例》第五十一条(投标文件未经投标单位盖章和单位负责人签字);前附表 3.7.3。 - 措辞模板取"应当否决(符合性/签署盖章)",填充投标人、条款、事实、结论。 - 投诉研判:签署盖章缺失属客观硬伤,投诉翻盘概率极低,但须留存"已当场核验原件/扫描件"的留痕。 </example> <example> 输入:投标人 C 报价大写"伍佰万元整"、小写"5,000,000.00",但分项报价汇总后小写为 5,020,000.00,存在计算误差。招标文件的报价修正条款约定"单价金额与总价不一致以单价为准修正"。评委会问:能否否决? 输出要点: - 结论:🟢 可澄清补正(不否)。属"明显计算错误",依招标文件约定修正,不得直接否决。 - 依据:《实施条例》第五十二条(明显计算错误可澄清修正);招标文件报价修正条款。 - 判定说明:落入"可澄清补正"类,非实质性内容偏差;若修正后报价仍超最高限价,则转为"应当否决"。 - 措辞输出"要求澄清/修正,不予否决"的规范表述,并提示修正后复核限价。 </example>九、安全与纪律护栏
详见 references/discipline_redlines.md。要点:客观中立不偏袒、全程知识库溯源、不编造法条/案例、回避人情与领导干预、对"帮我想办法绕过去"类诉求直接拒绝、每次输出附免责声明。
十、参考资源
references/decision_framework.md— 决策五步详解、结构化输入、应当否决 vs 可澄清补正 判定矩阵、法条依据层级映射。references/rejection_wording_templates.md— 规范化否决理由措辞模板库(可直接进评标报告),按情形分类、含必填要素。references/kb_mounting.md— IMA 知识库挂载方案(KB ID、检索策略、效力层级、熔断、跨体系声明),含"除否决库外还应挂载哪些库"的明确建议。references/discipline_redlines.md— 纪律红线与合规护栏(不踩纪律红线)、留痕溯源、回避与拒绝话术。
Top skills in this category
Camsnap
@steipeteCapture frames or clips from RTSP/ONVIF cameras.
Openhue
@steipeteControl Philips Hue lights/scenes via the OpenHue CLI.
X Trends
@anishtr4Fetches current top trending topics on X (Twitter) for any country using public aggregators.
Recursive Self Improvement
@erichy777递归自我改进系统,能够自动检测错误并修复,或持续优化和重构。包含修复模式和优化模式,支持并发执行、自动化测试、性能监控、智能调度、自适应学习、错误预测和异常恢复。用于需要持续自我优化的系统。
Torch Market
@mrsirg97-rgbEvery token is its own margin market. Depth-adaptive risk engine, treasury-backed lending, real-token short selling. No oracles. No stored baselines. No keep...