---

name: baidu-ecosystem-ai-product-review description: 用于审核百度生态体系“文心生态AI产品应用说明”与“飞桨生态AI产品应用说明”材料。适用于 Word、普通 PDF、扫描 PDF；要求同时核对正文、内嵌截图、调用量截图、代码截图，并输出纯文本审核结论、问题、告警、澄清项和修改建议。

百度生态 AI 产品材料审核

适用场景

当用户需要审核百度生态体系“生态AI产品”申报材料时使用本 Skill，覆盖：

• 文心生态 AI 产品应用说明
• 飞桨生态 AI 产品应用说明
• .doc、.docx、普通 PDF、扫描 PDF

该 Skill 适合用于：

• 初审合作伙伴提交材料
• 复核修改后的材料
• 统一审核口径，减少人工漏看截图、漏看 OCR 页面、前后逻辑不一致等问题

输入要求

• 待审核文档路径
• 若用户有额外审核口径，以用户最新口径为准
• 如有参考样例、旧版问题说明、保密说明，也应纳入判断

核心要求

1. 不能只看正文文本

• 对 .docx，必须同时读取正文和内嵌截图
• 对 PDF，必须同时检查正文、代码截图、调用量截图
• 对扫描 PDF，必须先做 OCR；OCR 低质量页要单独告警
• 如果当前环境无法提取内嵌图、OCR 质量不足或关键页无法辨认，应输出 需澄清 或“建议补更清晰材料”，不要拿不完整证据继续硬判

2. 输出必须分层

输出纯文本，分成：

• 审核结论：通过 / 不通过 / 需澄清
• 不通过问题
• 告警
• 需提报人澄清

每一项都要写清：

• 位置
• 问题
• 修改建议或补充建议

3. 审核重点是“功能价值占比”，不是机械代码行数

• 模板虽然写“代码占比”，但审核时要优先看百度技术在产品核心能力中的作用
• 若百度技术是产品核心能力，即使调用代码不多，也可以接受较高占比
• 若百度技术只是大产品中的边缘子模块，却填写很高占比，应判不合理或至少告警
• 只写一个百分比数字即可；在与截图、正文、模型信息等其他证据没有明显冲突时，不需要额外要求说明评估口径或剩余部分构成

审核流程

1. 识别文档类型和审核模板

   • 标题含“文心生态AI产品应用说明”时按文心规则审核
   • 标题含“飞桨生态AI产品应用说明”时按飞桨规则审核
   • 若标题被导出截断、改名或写得不标准，则根据字段结构、模型/套件痕迹做 fallback 判断
   • 例如出现 ERNIE、qianfan、aistudio 等文心痕迹时优先按文心规则判断；出现 Paddle、PaddleOCR、PaddleX、PaddleLite 等飞桨痕迹时优先按飞桨规则判断
   • 若 fallback 后仍无法判断，再向用户确认，不要在规则集不确定的情况下继续硬判

2. 提取全部可见信息

   • 正文文本
   • docx 内嵌截图
   • PDF 中的代码截图
   • PDF 中的调用量截图
   • 扫描页 OCR 文本

3. 建立字段映射

   • 产品名称
   • 应用单位
   • 注册地址
   • 产品上线时间
   • 产品功能简介
   • 产品形态
   • 百度技术模块
   • 实际应用模型/套件
   • 调用方式
   • 技术范式
   • 部署工具
   • 落地硬件
   • 百度技术占比
   • 百度技术调用比例
   • 代码截图
   • 调用量截图
   • 数据版权信息
   • 收益
   • 售价
   • 试用链接或测试账号

4. 做规则判断

   • 必填项是否完整
   • 功能是否写成“产品功能”而非纯技术词
   • 模型/套件与功能是否匹配
   • 百度技术占比、调用比例是否合理
   • 代码截图、调用量截图能否形成证据链
   • 收益是否量化
   • 文心材料中的数据内容和量级是否完整
   • 售价、试用方式是否充分
   • 前后字段是否一致

5. 生成审核结果

   • 先给结论
   • 再列出不通过问题
   • 再列告警
   • 再列需澄清项

关键审核口径

一、通过 / 不通过 / 告警 / 澄清的边界

• 不通过：硬性卡口问题，如关键必填缺失、关键证据缺失、收益不量化、前后重大矛盾
• 告警：可先保留但需人工关注的问题，如老模型、调用量偏少、上线时间晚于当前日期
• 需澄清：无法直接放行，但也不宜机械判不通过的情况，如保密原因导致链接或价格缺失、字段可能漏写、截图提取失败、OCR 质量不足、关键页无法辨认

二、功能项必须写业务功能

通过示例：

• 合同识别
• 票据识别
• 公文生成
• 修复评估
• 学术文本生成

不推荐写法：

• OCR识别
• 大模型生成
• 智能识别

三、模型比例的理解

• 若填写 100%，默认理解为仅使用该百度技术体系
• 不要求额外补一句“仅使用文心系模型”或“仅使用飞桨系模型”
• 只有当截图或正文中出现非该体系模型时，才把它视为不一致问题

四、上线时间

• 上线时间晚于当前审核日期，不直接判不通过
• 可能是“测试已开始、正式商用未开始”
• 若同时存在调用截图、测试链接、测试账号，可作为测试期使用理解
• 此类情况通常记为告警

五、文心专项规则

• 需要重点看：
  • 文心模型与功能是否匹配
  • API 调用方式下是否提供调用量截图
  • 调用截图中的模型是否与正文一致
• 文心材料要求填写数据版权归属、数据内容和数据量级
• 若使用明显较老模型，如 ERNIE 4.0、ERNIE 3.5，应告警

六、飞桨专项规则

• 需要重点看：
  • 飞桨模块是否写成功能，而不是只写 OCR
  • 飞桨模型/套件是否与场景匹配
  • 代码截图中是否能看出 Paddle、PaddleOCR、PaddleX、PaddleLite、PaddleServing、YOLOE 等痕迹
• 飞桨材料不要求填写“数据版权与量级”，除非用户当前回合另行补充口径
• 若使用明显较老模型，如 PP-OCRv3、PP-OCRv4，应告警

输出要求

使用纯文本输出，建议结构如下：

审核结论：通过 / 不通过 / 需澄清

不通过问题：
1. 位置：
   问题：
   修改建议：

告警：
1. 位置：
   问题：
   建议：

需提报人澄清：
1. 位置：
   问题：
   建议补充内容：

要求：

• 位置尽量具体到字段名、页码或截图位置
• 不要只说“有问题”，要指出为什么违反审核口径
• 修改建议必须可执行

参考资料

• 详细规则见 references/review-rules.md
• 样例经验见 references/sample-insights.md
• 输出格式见 references/output-template.md