先核对申报身份，再考虑如何写材料
江岸区经济信息化和科技创新局9月24日发布2026年模型券申报通知。10月19日核对官网正文时，材料提交日期为10月23日前。通知没有注明当天的截止时刻，拟申报者宜提前向主管部门确认，不根据其他平台摘要自行推定收件时间。
这项安排面向符合当地条件的主体，并分别设置服务与研发类别。本站服务10人及以下的AI创业团队，并不代表每个读者都符合该专项资格；是否具备申报身份、经营条件与对应材料，仍须逐项阅读官方原文。以下仅讨论怎样整理自己已有的事实。
采购应用与研发，回答的是不同问题
采购应用一侧可以先问：企业实际买了什么，由谁提供，费用对应哪段服务，应用于什么任务。研发一侧可以先问：自己形成了什么产品，谁承担研发工作，功能已经到了哪一步，有什么能够核对的应用记录。这些问题有助于内部准备，不是本文另设的申报门槛。
同一企业可能兼有采购和研发活动，不能因此把相同支出、材料与成果任意重复归入不同类别。遇到归类或重复支持方面的疑问，应把具体情况提交有权部门确认，不能仅凭文章、销售人员承诺或AI判断决定。
让合同、实际使用与费用记录指向同一事项
采购材料准备可以建立一张内部对应表：服务名称、合同主体、使用主体、实际用途、费用记录及证明位置。重点是发现不一致，例如付款主体与合同主体不同，或账单中还混有云主机、通用软件和其他服务。先标记需要说明的部分，再核对官方认可范围。
模型名称相近也不意味着底座及服务关系相同。可以请供应商提供其对外可验证的产品和模型来源说明，并保留信息日期；对于不能确认的依赖，明确写成待核对。不要为了匹配申报类别，给普通软件订阅临时换上智能体名称，或把未付款的试用额度写成实际费用。
研发案例需要区分演示与实际应用
研发一侧适合整理版本、功能范围、研发人员实际承担的工作，以及案例资料可公开或可提交的范围。若只有内部演示，就如实记录测试环境和使用情况；若涉及客户试用，则先确认客户允许提供哪些记录。本文不把测试记录直接判定为官方所需的优秀案例。
实际应用的记录可以说明输入来自哪里、系统完成哪一步、谁确认输出、出现错误怎样处理。技术材料与业务结果应能相互对应，但没有独立核实的收入、准确率或降本比例，不应为了增强申报印象而补写。
估算可用资源时，不预先计入奖励
通知列有支持标准和审核程序，完整表述请阅读原件。企业内部安排预算时，可以先按尚未获得支持计算必需支出，把潜在奖励单独列为待确认事项。这样即使材料补正、评审结果或兑现时间不符合预期，也更容易判断项目是否仍可继续。
提交前按官方附件逐项复核，指定一名负责人检查签章、版本和送达渠道，并保留自己的提交记录。文章中的整理方法不能替代原申报书及正式承诺书，也不能证明某家企业已经通过审查。
本文为本站原创阅读导引，政策正文与附件不作改写或删减。具体条件、材料及联系方式以文末官方链接为准。延伸阅读：AI项目依赖与切换成本；小团队项目验收清单。