# 本校AI编程黑客松筹办决策与执行模板

本校日期、预算、人数及合作企业未指定。下面是一份可修改的R方案：首次试办以20队容量、每队2—4人、一条企业任务加一条开放校园题、两天开发与Demo评判为工作假设。20队是便于计算运营负荷的设计容量，不是研究证明的最佳规模；最终容量由资源试跑、导师与评委可用时间决定。所有金额、姓名和承诺日期待实际确认后发布。

## 先决定的事项

| 决策 | 建议起点 | 改用其他方案的条件 | 发布前需拿到的材料 |
|---|---|---|---|
| 目标 | 学生交出可体验产品，企业验证一条真实流程 | 若目标是算法性能或开源贡献，采用对应长周期规则 | 目标用户、核心路径、成果定义 |
| 时长 | 两天集中开发；前一周培训与预检 | 新手/值守不足改6—12小时练习场；硬件/大数据任务延长并减功能 | 学生试做记录、场地和服务时段 |
| 范围 | 单校跨专业；容量20队，2—4人 | 扩跨校须能承接交通/资格、账号和技术支持 | 报名/组队规则与能力负荷 |
| 企业任务 | 第一届先做1题，业务导师与技术接口分别明确 | 有两套完整资源和验收人后再扩题 | 企业参与表、任务书、服务承诺 |
| 工具 | 一个首选教学工具，允许经说明的其他AI编程工具 | 企业平台有必须验证的功能时独立设平台题/奖 | 工具限制、额度、部署和许可边界 |
| 旧作品 | 可用公开库与框架，申报赛前资产；核心新增在赛时完成 | 从Demo起步的创业活动另用迭代赛制 | 初始版本/赛时版本、贡献及使用声明 |
| 组队 | 允许个人报名，提供匹配；优先自愿跨角色组队 | 招生营或教学分组才考虑随机组队 | 成员确认、换队与截止规则 |
| 评判 | 先验Demo可用，再看价值和实现；人气奖独立 | 展台筛入围时提前公布投票作用 | 验收清单、权重、复核/并列和故障规则 |
| 奖励 | 只发布已确认的证书、实物或奖金 | 企业招聘权益可另列，但说明对象/条件/有效期 | 资金来源与办理人、兑现清单 |
| 后续 | 愿意继续的团队另议POC，不用自动商业授权 | 企业只供工具则按学习活动结项 | 自愿意向、范围、资源、权属及退出安排 |

两天开发可以安排为首日上午开场/组队与开发，次日上午完成核心流程并冻结提交，随后技术验收、路演及结果。若要宣传精确“48小时”，须让开发起止确实相隔48小时，并把路演放在窗口之后；不要用“两天活动”混写为48小时开发。

## 相对日程与交付关卡

以下时间是建议的筹办缓冲，T为开赛日；日期确定后才能填入公告。

| 关卡 | 建议时间 | 负责者向谁交什么 | 放行标准 |
|---|---|---|---|
| 企业参与确定 | T−28至T−21 | 企业联络→总协调：七维表、任务/资源/导师/奖项承诺 | 没有未确认却准备宣传的权益 |
| 任务试跑 | T−21至T−14 | 业务/技术导师→命题编辑：任务与样例；试做组→总协调：试跑问题 | 核心流程和资源能跑，评分不依赖未给数据 |
| 发布招募 | T−14 | 招募运营→学生：公告、报名、规则、任务、培训 | 链接试走、截止一致、负责者可联系 |
| 培训与组队 | T−7至T−3 | 讲师/组队运营→队伍：样例、分工确认 | 学生理解交付；个人报名有明确状态 |
| 资源预检 | T−3至T−1 | 资源接口→队长：到账；队长→技术台：四项预检 | 阻塞已处理或有统一备用方案 |
| 规则说明 | T−1或T开场前 | 业务/技术/评委/运营→全队：当前版本和答疑 | 关键问题不悬而未决 |
| 开发与答疑 | 开发窗口 | 导师/运营→全队：FAQ与变更 | 所有规则答案公开一致，故障留记录 |
| 冻结与体验 | 窗口截止 | 队长→提交运营：完整包；验收→评委：体验记录 | 可完成核心路径，异常依规则分类 |
| 评判与复核 | 体验后 | 评委→协调人：分数/理由；协调→总协调：排序 | 冲突回避、并列和故障处置有依据 |
| 结果与兑现 | 结果当天起 | 奖项/财务/企业HR→团队：具体权益和办理回执 | 获奖公示与权益交付分别记账 |
| 后续与结项 | T后约2—4周作为复盘窗口 | 团队/企业→校方：意向、试点状态；运营→组织方：漏斗和异常复盘 | 只报告已发生状态，保留未完成项的负责者 |

## 组织方工作量与预算模型

先列工作岗位，再合并可兼任的人：总协调、企业联络、命题编辑、招募/组队、技术/资源、答疑运营、提交验收、评委协调、奖项财务、赛后项目。业务导师不自动兼技术运维；最终评委与正在辅导的队伍关系应记录并处理回避。

预算按实际报价填写：

`总现金支出 = 场地与设备 + 网络/部署/模型调用 + 餐饮与物资 + 交通住宿（如有） + 奖金奖品 + 服务/制作费用 + 经确认的备用支出`。

另记校方、学生运营和企业投入工时。代金券、到期算力额度、无偿场地与人力分别记作实物/服务投入，不与现金重复相加。题目中的经营预算不是赛事资金，计划预算也不是决算。

资源需求按“队伍数×每队配额×使用窗口”估算，并在试跑后调配。导师负荷按问题量与响应窗口计算；评判时长按入围队数×每队展示/问答时长加换场和复核计算。例：20队每队5分钟展示、3分钟问答，纯评判需160分钟；换场、休息、复核另加。此为容量计算，不是已核实赛事用时。

## 模板A 企业邀请附件

**活动目标：**学生借助AI编程完成可体验产品，校方承担招募、组队、场地、运营和成果整理。邀请企业参与一项能在既定周期内验证的业务任务，同时明确技术资源与验收安排。

**希望企业确认：**业务场景与允许给学生的数据；业务负责人、技术资源接口及可服务时段；一套样例与最低交付；是否派评委；是否提供已批准的奖项；优秀项目后续是否另议自愿试点。品牌、资源、业务、辅导、评审、后续、权属七维逐项填，不要求全部承担。

**校方提供：**报名和资格核验、跨专业组队支持、赛前培训与环境预检、统一问题入口、Demo验收与评判组织、权益兑现跟进、经团队同意的可公开成果包与复盘。

**合作确认表：**企业主体［待填］；任务负责人［待填］；技术接口［待填］；交付物/提供日［待填］；服务窗口/替补［待填］；奖项及办理人［待填］；数据、IP和宣传许可［待填］。未填项保持未承诺。邀请附件可用于沟通，未经确认不能作为企业正式承诺。

## 模板B 学生任务书

| 字段 | 待填内容与检查要求 |
|---|---|
| 标题/版本/生效时刻 | 唯一版本，谁批准修改 |
| 目标用户与场景 | 一类具体用户、一次典型使用任务 |
| 当前问题 | 为什么现有方法不够；哪些事实可向学生公开 |
| 核心路径 | 输入→处理→输出→用户确认/反馈 |
| 必做 | 最低可运行范围，逐条可验收 |
| 选做 | 加分项与对应分值，不替代核心路径 |
| 示例 | 可取得的输入、期望输出、错误/空输入例 |
| 数据与资源 | 权限、领取、额度、登录、到期、备用、禁止上传的数据 |
| 技术约束 | 必用/可选工具，接口限制，既有库与旧资产声明 |
| 交付包 | Demo、说明、录屏、代码/实现证据、使用与许可声明 |
| 体验方式 | 公网/本机/平台ID、测试账号、步骤、评委设备 |
| 评分 | 核心路径门槛、权重、选做、复核/并列/故障规则 |
| 服务 | 业务/技术/赛务入口、响应目标、时段、FAQ |
| 权属与后续 | 原创/第三方许可、宣传范围、是否另议商业试点 |
| 试跑记录 | 学生能否理解、资源是否可用、核心路径耗时和修订 |

“真实企业题”要求企业业务负责人确认场景与验收，不能只由模型生成一段故事后挂企业名称。场景需要真实，给学生的数据不必是真实敏感数据；脱敏/合成样例应说明范围。

## 模板C 资源预检回执

`队伍ID｜题目/版本｜资源类别与平台ID｜申请时间｜到账时间/到期｜模型或接口调用通过｜样例读取通过｜部署/本机运行通过｜独立设备核心路径通过｜故障类别｜负责者｜下一处理时点｜最终状态`。

公共回执不含密钥/个人账号资料。未过检的队伍必须知道该找谁、何时获得下一消息，以及统一备用方案是否适用。

## 模板D FAQ和变更记录

`问题ID｜首次报告时刻｜业务/技术/资源/赛务｜受影响范围｜问题简述｜当前答案/临时方案｜负责人｜是否改变任务/评分/期限｜批准人｜版本与生效时刻｜全体通知渠道｜关闭证据`。

改变要求的答案属于规则变更，所有队同步；只说明代码报错的答案可以作为排障。保留旧版，当前规则页标明最新版本。

## 模板E 提交与体验核验

提交包建议文件夹：`01项目说明`、`02体验与录屏`、`03代码或平台实现`、`04测试与已知问题`、`05工具数据许可及贡献`。命名方式和允许格式在发布前固定。

验收记录：`队伍ID｜冻结版本/提交时间｜材料齐全｜陌生设备可访问｜核心路径结果｜异常输入结果｜公网/本机/平台依赖｜备用录屏/离线包｜已知限制｜验收人｜有效提交/需按规则处置`。

Demo故障分团队实现、主办方资源、现场网络/设备；处理依据均提前写入规则。没有公开体验链接的离线作品也可合格，关键是评委能按允许方式验证。

## 模板F 评判表与结果漏斗

建议权重（R，合计100）：核心任务完成与可用性30、用户/业务价值25、技术实现与AI编程证据20、体验15、测试与限制说明10。平台题可按实际任务调整；不能同时宣传这套权重又临时按创新度排名。最低交付门槛与未通过处理先公开，技术可用性的门槛不替代各维度评分。

`队伍ID｜评委/回避关系｜各维分数｜体验/问答证据｜关键优点｜未完成与限制｜故障处置依据｜总分｜复核/并列处理`。

运营漏斗每个数给分母和日期：有意向→完整报名→合格组队→资源通过→有效提交→体验通过→入围→获奖。赛后再单列权益兑现、签POC、实际试点、试点验收、持续维护，不把作品展示数当提交数。

## 模板G 奖项与后续台账

权益：`队伍/个人｜获奖公示｜权益内容｜金额/形式/税费｜条件/期限｜办理人｜所需资料/私密渠道｜发出｜收到/可用证据｜未完成原因｜下一处理日`。

后续：`团队是否自愿｜企业业务验收人｜意向/签试点/执行/验收状态｜任务范围｜资源和维护成本承担｜数据/IP/商业许可｜交付日｜验收依据｜退出/设备返还/账号回收`。

最终成果报告分别讲产品做到了什么、还有哪些限制、奖励兑现到哪一步、合作是否实际发生。没有签约、用户验证或真实运行的数据，就保留相应状态，不用“落地”一词把阶段省略。