推荐工作节奏
T 是你计划提交的那一天。把最后一周切成五段，每段只干一件事，别把定题和填表挤在同一个晚上。
定题与证据盘点
- 用一句话锁定目标用户、核心问题、AI 方法和结果。
- 删除不能在演示中闭环的次要功能。
- 建立证据清单：基线、上线后数据、用户反馈、系统截图、日志、接口、模型评测和真实性证明。
- 确认哪些数字可公开，哪些需要脱敏。
完成文字初稿与演示脚本
- 按第 03 节填写全部字段草稿。
- 先写「解决的业务问题」，再写「为什么需要 AI」和「解决问题的方案」。
- 录制一次不剪辑的试讲，检查是否能在短时间内让陌生人理解价值。
- 准备真实或可信的模拟数据；常规基础表单只需简略展示。
技术与真实性审查
- 技术负责人核对模型名、部署方式、接口数、数据源数、智能体数和工程难点。
- 业务负责人核对收入、节省、ROI、客户数和使用人数的计算口径。
- 删除无法举证的绝对化表述，如「唯一」「首创」「100% 准确」。
- 确认演示环境稳定，关键路径有备用录屏。
模拟评审
请一位未参与项目的人完成两项测试：
- 读完文字后，能否在 30 秒内复述「问题、方案、价值、差异」？
- 看完演示后，是否相信作品真实可用，而不只是概念原型？
随后按五个评审维度打分，逐项补足证据。
最终提交
- 冻结最终文案和演示版本。
- 逐字段复核，不在提交页面临时改文案。
- 记录提交时间和最终版本。
- 确认无误后，将作品状态从草稿改为已提交。
先准备一页式作品主张
在填写作品提交表前，先完成以下六句话。
如果这六句话彼此矛盾，先不要填表。
「作品」工作表逐字段填写方法
按提交表的分组走一遍。带「必填」的字段没填完不能提交，其余字段留空好过瞎写。
3.1 基本信息
- 选择正确队伍，不要新建重复队伍。
- 提交前核对队名与报名信息一致。
推荐结构：业务对象 + 核心任务 + 产品形态。
[目标用户]，利用 [关键 AI 能力] 完成 [核心任务]，实现 [最重要结果]。控制在 300 字以内，采用四段式：
- 场景与用户；
- 原流程痛点；
- 方案闭环；
- 已验证结果与推广空间。
简介不要重复堆砌模型名称，模型细节放到「使用模型」和技术方案中。
- 是否已投入生产：只有真实业务用户已在生产环境使用时才勾选。
- 上线日期：填首次生产使用日期，不填内部立项或原型完成日期。
- 是否仍在运行：以提交当日实际状态为准。
- 部署方式（必填）：从云端部署 / 本地部署 / 混合部署中准确选择。
3.2 AI 技术属性
可选：自然语言处理、计算机视觉、语音识别与合成、推荐系统、预测分析、智能决策、多模态、其他。
只选择在核心业务链路中真正发挥作用的类型。不要为了显得复杂而全选。
写清三层信息：
- 基础模型或算法，例如 GPT、BERT、YOLO、XGBoost；
- 自研或微调内容，例如领域微调、RAG、分类器、蒸馏模型；
- 必要时注明版本，保证可复现和可核验。
用可验证的业务语言，不要从功能开始写。推荐结构：
[角色] 在 [流程/场景] 中，由于 [原因]，导致 [时间、成本、质量、风险或收入影响]。现有 [人工/规则/旧系统] 的限制是 [限制]。至少给出一个基线数字，例如人工覆盖率、平均耗时、差错率、缺货率或投诉率。
回答「没有 AI 为什么做不好」，而不是「AI 很先进」。常见合理理由：
- 数据规模超出人工处理能力；
- 输入是文本、图像、语音等非结构化数据；
- 规则无法覆盖长尾和不断变化的模式；
- 需要预测、个性化、语义理解或复杂关联判断；
- 需要在实时约束下持续决策。
同时写清 AI 的边界：低置信度如何转人工、如何防止误判、如何监控漂移。
按闭环描述：
- 输入：哪些业务数据、来自哪里；
- 处理：清洗、检索、模型推理、规则或智能体协作；
- 输出：预测、分类、建议、生成内容或告警；
- 动作：输出如何触发工作流、审批、任务、通知或系统回写；
- 反馈：人工反馈如何回流并改进系统。
3.3 新颖性
只写 1–3 个最强创新点，每个创新点采用：
可从数据、模型、交互、流程、部署或商业模式角度说明创新。创新必须与业务结果相连。
选择明确比较对象：人工流程、规则系统、通用 AI 工具或市场同类产品。建议写成：
| 比较项 | 常见方案 | 本作品 | 证据 |
|---|---|---|---|
| 覆盖范围 | |||
| 准确率 / 效率 | |||
| 部署与安全 | |||
| 业务闭环 | |||
| 扩展成本 |
避免没有证据的「行业第一」。
3.4 商业价值
工作表提供这些量化字段：年度成本节省金额、年度新增收入金额、投资回报率、其他量化价值、使用人数、客户数量。
填写原则
- 统一币种和周期，金额按年度口径填写。
- 区分实测、试点推算和目标值，并明确标注。
- 不知道的数不要填 0，0 表示真实为零。
- 保留计算底稿与证据来源。
推荐计算方式
250 表示 250%，不要误填成 2.5。其他量化价值
优先写前后对比，并注明样本与周期：
3.5 工程难度
工作表包含：开发周期月数、开发人数、接入系统数量、数据源数量、接口数量、智能体数量、工程难点。
不要只写「模型准确率难」。写清：
- 约束：延迟、成本、隐私、数据质量、并发、可用性或硬件限制；
- 失败风险：不解决会造成什么影响；
- 解决方式：具体架构或工程措施；
- 结果：延迟、吞吐、准确率、稳定性或成本指标。
这部分是「技术实现」评分的重要证据。
3.6 真实性
只有经过明确验证后勾选。最低建议验证项：
- 核心流程端到端可运行；
- 有明确的人工兜底；
- 权限与敏感数据处理已检查；
- 关键错误可追踪；
- 性能满足目标场景；
- 业务负责人完成验收。
准备可核验、可脱敏的证据包：
- 生产或试点界面截图；
- 运行日志、任务记录、调用记录；
- 上线通知、验收记录或用户反馈；
- 指标看板与原始统计口径；
- 关键接口或工作流截图；
- 演示账号或受控访问方式；
- 必要的客户 / 单位证明。
证据命名统一为：作品名_证据类型_日期_版本。涉及客户、员工或业务秘密时必须脱敏。
演示视频：让评委在最短时间内相信作品
视频是评委理解作品的主要方式，评委还可能进入应用逐一操作。视频应聚焦核心业务模块，不完整或有问题的功能可以不展示，常规基础表单可略过。
推荐脚本
- 开场：一句话介绍用户、问题和结果。
- 问题：展示原流程及基线数据。
- 主流程：用一个真实任务从输入走到业务动作完成。
- AI 关键时刻：明确指出 AI 在哪里判断、预测、生成或协作。
- 人工兜底：展示低置信度、异常或审批路径。
- 结果：展示指标看板或前后对比。
- 技术与扩展：简述部署、集成、稳定性和可复制性。
- 结尾：重复作品的独特价值。
录制要求
- 提前写逐字或半逐字脚本并多次试录；
- 放大网页显示比例，确保字段和按钮可读；
- 使用一致且可信的模拟数据；
- 关闭无关通知，准备干净账号；
- 不追求复杂剪辑，优先保证声音、画面和信息清楚；
- 涉及打印机、POS 或线下设备时，用手机补充实拍；
- 若方案里涉及敏感数据，请在录制前清除或剪辑时打码；
- 准备备用录屏，防止现场网络或外部接口异常。
提交前最终检查表
勾选状态只存在这台设备的浏览器里，随时回来接着对。