Q报告里问题特别多，是不是说明标书质量很差
A
不一定。条目数量取决于检查的粒度和合并方式，同一个原因被拆成十条，数量就是十。更可靠的看法是合并成根因之后，看有多少条属于第一、二级，这才反映标书还有多少实质性问题。
审核报告
整改优先级
AI标书审核报告列了一堆问题，哪些真要改？一文看懂整改优先级
AI审核标书报告生成之后一打开，几十条问题从第一页排到最后一页，每条都有位置、有说明，看上去很认真。标书负责人问的却是另一件事：这些问题里哪几条不改就不能交，哪几条可以放到最后，哪几条根本不是问题。报告本身回答不了这三个问题，需要读报告的人自己拆。
报告在手之后，真正耗时的是读报告这一步：确认它查的是哪个版本，把重复的条目合并，按后果排出先后，再分给对应的人，每一条定下怎样才算改完。下面按这个顺序讲，每一步都附上判断标准。
提交前审核的整体框架，包括合规、查重、格式三类检查的分工，见提交前用AI审核标书：合规、查重、格式三类问题怎么分开查。本文接在检查之后，处理的是报告已经在手、需要决定先改什么的这个阶段。
本文内容
先确认报告对应哪个版本，查了哪些范围
报告里最容易被略过的是开头两行：检查对象是哪一版文件，检查覆盖了哪些部分。略过它们，后面的判断可能都建立在错误的前提上。
版本对不上是最常见的情况。报告针对周二的稿子生成，周三技术部门又改了参数表，负责人拿周二的报告去核对周三的文件，要么发现问题“已经不存在”，要么漏掉新引入的问题。所以报告至少要写明检查的文件版本和生成时间，拿到报告先对照当前版本。
范围同样要先看。报告里没有出现某一章的问题，有两种可能：这一章查过，没发现问题；这一章根本没有被查。两种情况在报告里看起来一样。如果报告没有说明覆盖范围，就要向生成报告的人确认，或者用指令要求每次输出时附上“已核对的章节与条款数量”。
一份能用的审核报告，至少有这些字段
读不下去的报告，往往是缺字段。每条问题至少应该带有下面的信息，缺失时的处理方式也列在表里：
| 字段 | 作用 | 缺失时怎么办 |
|---|---|---|
| 位置（章节、页码） | 让人直接翻到原文 | 要求补充；没有位置的条目无法处理 |
| 原文节选 | 判断问题是否成立，也排除凭空出现的条目 | 回原文搜索，搜不到的按不成立处理 |
| 对应的招标要求 | 说明依据是哪一条，而不是模型的一般看法 | 补问依据；说不出依据的条目降级为“待确认” |
| 问题类型 | 漏项、响应不足、前后矛盾、格式等，决定谁来处理 | 按内容自行归类 |
| 判定与说明 | 为什么算问题，缺的是什么 | 要求补充，不接受“建议完善”这类说明 |
字段缺得多，说明生成报告的指令需要改。输出格式怎么约定，见AI标书审核提示词怎么写？别只说帮我检查，附可复用模板，把字段要求写进指令，比事后逐条补问省事。
把几十条问题合并成十几个根因
报告里的条目数量，取决于检查的粒度，和标书质量只有部分关系。同一个原因常常被拆成很多条，读者看到的是数量，处理时面对的却是同一件事。
下面是一段示意的报告片段，内容为虚构，用来说明合并方式：
报告片段与合并结果（示意，内容为虚构）输出示例
原始条目：
第 3 条 技术方案第 12 页写“交货期 45 天”，商务标第 6 页写“交货期 60 天”
第 7 条 进度计划表第 2 页写“交货期 45 天”，与商务标不一致
第 9 条 投标函第 1 页写“交货期 60 天”，与技术方案不一致
第 15 条 响应表第 5 项“质保期”一栏为空
第 16 条 响应表第 8 项“培训方案”一栏为空
第 21 条 响应表第 11 项“备品备件清单”一栏为空
合并后：
根因 A（前后矛盾）：全文交货期出现 45 天与 60 天两种取值，涉及 3 处位置。
根因 B（响应缺失）：响应表有 3 项未填，涉及质保期、培训方案、备品备件清单。
第 3 条 技术方案第 12 页写“交货期 45 天”，商务标第 6 页写“交货期 60 天”
第 7 条 进度计划表第 2 页写“交货期 45 天”，与商务标不一致
第 9 条 投标函第 1 页写“交货期 60 天”，与技术方案不一致
第 15 条 响应表第 5 项“质保期”一栏为空
第 16 条 响应表第 8 项“培训方案”一栏为空
第 21 条 响应表第 11 项“备品备件清单”一栏为空
合并后：
根因 A（前后矛盾）：全文交货期出现 45 天与 60 天两种取值，涉及 3 处位置。
根因 B（响应缺失）：响应表有 3 项未填，涉及质保期、培训方案、备品备件清单。
六条变成两个根因，处理的方式也随之清晰：根因A是一个需要业务确认的事实问题，确认交货期之后一次性统一；根因B是一个需要补材料的问题，需要三类材料的提供人各自补充。合并之前，这六条会分别指派、分别处理，很容易有一处遗漏。
合并的判断依据是“改的时候是不是同一个决定”：多个位置取值不一致，决定只有一个，合并；多处响应为空，要补的材料各不相同，可以合并成一个根因，但要保留每一项的处理人。
AI审核标书报告的整改优先级，按“不改会怎样”分四级
排先后的依据是后果，而不是问题出现的先后顺序，也不是类型。下面四级可以作为起点，各团队再按项目调整：
第一级
可能导致否决
涉及资格、签章、报价、实质性要求的条目，例如资质不满足、报价表与投标函总价不一致、缺少法定代表人签署。发现之后立即升级给标书负责人，由其判断是否具备补救条件，不进入普通队列排队。招标文件中哪些属于否决项，可以对照标书提交前审核清单里的分类逐条确认。
第二级
响应缺口，影响评分或实质性响应
漏项、响应不足、缺少证明材料。需要在内容定稿前处理，因为补材料和重写响应都需要时间。
第三级
一致性与准确性
前后矛盾、数据与名称混用、引用错误。不改的后果是评审对文件可信度的判断打折，需要在材料收口前处理完。
第四级
形式与表达
格式、错别字、措辞。批量修改速度快，放在最后统一处理，有时间余量再改。
类型和级别不是一一对应的。同样是“前后不一致”，交货期不一致可能影响评分，总价大小写不一致则可能落到第一级。分级要看这个字段在本项目里的约束力。三类问题的定义见标书内容检查到底查什么：漏项、响应不足与前后矛盾的判定口径。
筛掉不成立的条目，也要写下原因
AI审核报告里一定会混进一些不成立的条目：引用了招标文件里并不存在的要求，把本来写得清楚的内容判成漏项，或者对一段合理的省略提出建议。筛除的方法是回原文：
- 看原文节选能否在文件中找到，找不到的，条目不成立；
- 看引用的招标要求是否真实存在，要求本身出处不明的，转为“待确认”；
- 看判断是否符合本项目的口径，例如这项内容招标文件明确允许缺省；
- 确认不成立的，标记“不成立”并写明原因，不要直接删除。
保留不成立条目和原因，有两个用处：下一次生成报告时，同样的条目再出现可以直接参照；原因也能反馈给指令编写人，用来调整判定口径。
反过来也要记住：报告没有列出的，不代表不存在。人工确认过的问题如果报告里没有，应当补记在清单里，这类条目累积起来，就是指令需要改进的地方。
给每个根因指定责任人和关闭标准
合并、分级、筛除之后，剩下的清单需要两项信息才能推进：谁处理，怎样算处理完。示意如下，内容为虚构：
| 根因 | 级别 | 责任人 | 关闭标准 |
|---|---|---|---|
| 交货期出现 45 天与 60 天 | 三级，涉及商务承诺，升二级 | 商务负责人确认取值，编制人员统一修改 | 全文交货期取值一致，确认人核对后关闭 |
| 响应表三项为空 | 二级 | 技术负责人（质保、培训）、供应链（备件清单） | 三项均有响应内容并附证明材料位置 |
| 资质证书扫描件有效期无法辨认 | 待确认 | 资证人员 | 对照原件确认有效期，并更换清晰扫描件 |
关闭标准要写成可以核对的状态，如“全文取值一致”“均有响应内容并附材料位置”，不能写“已修改”。条目的状态怎么流转，由谁关闭，在AI标书审核流程怎么设计？检查顺序与责任分工怎么定里有完整的约定。
报告里的“待确认”，交给能判断的人
“待确认”是报告里最容易被当作噪音的一类，实际上它标出的往往是风险最大的地方：要求本身表述模糊，企业材料不完整，或者前后文件存在冲突。
处理的原则是不为关闭条目而填写。企业资质不足、业绩缺材料，是投标中真实存在的情况，应该交给标书负责人或项目负责人判断：补材料、澄清要求，或者调整投标策略。如果为了让报告看起来干净，把缺失的参数写成“满足”，问题只是被挪到了评审环节。
改完之后，用新报告对照旧报告
修改完成后要重新生成一次报告，并和上一份对照三件事：已关闭的条目是否确实消失了；有没有新增的条目，新增的往往是修改引入的；上一轮标记为“待确认”的条目是否已有结论。
对照时用同一条指令、同一套字段，否则两份报告的粒度不同，没法逐条比。每一轮对照得到的结论，与文件版本一起记录，这样“这份文件是否检查过”就可以回答。
如果团队希望把审核指令、分级口径和责任人规则固定下来，LangHub 可以把它们沉淀为共用的 Skill，由熟悉标书业务的同事校准；报告里的判断仍由投标团队确认，具体做法可以预约演示了解。
常见问题 FAQ
QAI报告和人工审核的结论不一致，以谁为准
A
以人工确认后的结论为准，但要记下不一致的原因。如果是报告错了，原因反馈给指令编写人；如果是人工漏了，补回清单。人工也拿不准的，升级给标书负责人，不要在两者之间随便选一个。
Q审核报告可以作为合规证明吗
A
不可以。报告是内部的检查记录，说明检查了什么、发现了什么，它不构成合规结论，也不能代替标书负责人对提交文件的确认。是否满足招标文件要求，最终由投标团队判断并承担责任。
Q每次投标要生成几次报告
A
至少两次：内容定稿后一次，用来发现响应缺口和不一致；提交前一次，用来确认必须改的条目已经关闭，并发现修改带来的新问题。体量大、否决条款多的项目，可以在材料收口时再加一次。
Q怎样让报告更容易读
A
把读不下去的原因回写到指令里。缺位置就要求补位置，缺依据就要求引用招标条款，条目太碎就要求按条款合并输出。每一轮读报告时遇到的障碍，都值得修改一次指令。