DeeCamp2020冠军项目拆解：从场景选择到技术落地的AI实战方法论

1. 项目整体设计与思路拆解

1.1 DeeCamp2020冠军项目背后的共性逻辑

我认真看完这批DeeCamp2020的冠军项目之后，第一感受是：这些项目赢在“场景选得准”，而不是算法堆得高。AI积木、自动驾驶、AI听诊、AI科幻，乍一看是四个完全不相关的方向，但如果把它们放在一起做横切对比，会发现它们在设计层面有一条非常清晰的共同脉络——每一个团队都在用AI去解决一个“原本需要人力耗费大量时间”的问题，并且这个问题的答案是可量化、可验证、可商业化的。

这一点在AI竞赛里极其重要。很多学生团队喜欢做“技术展示型”项目，模型精度刷得很漂亮，但到了商业化评估环节就卡壳了。而这批冠军项目的聪明之处在于，它们都是“先锁定用户痛点，再去找AI落点”。以AI听诊为例，传统听诊极度依赖医生的个人经验，年轻医生和资深医生在同一段心音上的判断可能差出好几个等级。这说明什么？说明这个场景存在“标准化替代”的空间，AI能做的不只是辅助判断，而是把高水平医生的经验压缩成一个可复用的模型。

这四个方向还体现了另一个共性：都在做数据的结构化重组。AI积木是把“拼搭行为数据化”，自动驾驶是把“道路环境数据化”，AI听诊是把“音频信号数据化”，AI科幻是把“文本世界观数据化”。数据一旦结构化，AI的能力就能被稳定调用。很多非技术背景的读者可能会觉得这四个方向跟AI的关系各不相同，但本质上是同一件事——找到高频、高价值、高重复度的场景，用模型去消化它的数据特征。

你可以把这种设计思路理解成“开餐馆”：冠军项目不是那种做分子料理的网红餐厅，而是把某一两道菜做到极致的小店。它的菜谱逻辑是——我知道这道菜谁天天吃、我能用什么供应链（数据）、我怎么让口味稳定（模型训练）、我怎么定价（商业模式）。这种思路放到任何行业都通用。

1.2 商业化视角下的技术选型策略

接下来聊一个容易被忽略但在评审环节极其关键的层面：技术选型是否匹配资源约束。

很多人一看到自动驾驶就觉得必须上激光雷达、多传感器融合、高精度地图，但冠军项目告诉你，在有限的资源下，视觉方案的端到端学习照样能跑出一个可落地的产品原型。这不是说激光雷达不重要，而是说——你要在你的资源边界内找到最优解。DeeCamp本身就是一场高强度限时竞赛，团队要在几周内拿出可演示、可复用的完整方案，这时候“能用便宜的方案先跑通闭环”远比“用高大上的方案但只完成50%”要实用得多。

这一点我非常认同。实际做过项目的人都知道，一个AI产品从0到1最大的风险不是模型精度不够，而是项目直接死在半路上——数据搞不定、训练资源不够、工程链路断掉，随便哪一个都致命。

冠军项目在技术选型上的聪明之处，我总结为三点：

• 用最成熟的技术解决最核心的问题：例如AI听诊用的是音频分类里非常成熟的梅尔频谱加卷积网络，而不是在当时还算前沿的wav2vec预训练模型。技术成熟意味着社区资料多、踩坑成本低、确定性高。
• 优先保证“演示即真实”：自动驾驶项目的演示不是录好的视频，而是接上真实仿真环境跑出来的实时画面，这让评委在感官上建立起了“这东西真的能动”的信任感。
• 单一强场景切入，避免泛化陷阱：AI积木锁定的是“拼搭误识别率”这个单点，AI科幻锁定的是“剧本大纲生成效率”，都是窄而深。

后面我会一个项目一个项目地拆解，把每个方案背后的核心细节、技术路径和商业化路径都捋清楚。如果你也在筹备类似的AI项目，这套拆解思路可以直接照搬。说白了，冠军方案真正值得学习的不是某个模型结构，而是它“在什么条件下做什么决定”的决策过程。

2. 四个冠军项目核心细节解析

2.1 AI积木：把物理拼搭行为变成可训练的视觉识别任务

先来聊聊AI积木这个项目。它解决的是一个很实际的场景：儿童在拼搭积木时，经常会出现“少了一块、多了一块、搭错了位置”的情况，而家长不一定有精力实时盯着看。这个项目用摄像头捕捉积木拼搭区域的图像，实时识别出当前的拼搭进度、缺失零件、错误位置，并用语音或屏幕提示的方式引导儿童完成搭积木。

从技术角度拆解，这个项目并不复杂，核心就是一个目标检测模型加一个小型路径规划逻辑。目标检测负责识别每个积木的位置和类型，规划逻辑负责比对当前状态和目标状态的差异。让我佩服的是他们把“复杂问题简单化”的能力——积木这件事如果做泛化识别，什么积木都认，那工程量是巨大的；但他们限定在“一套特定的积木绘本”里，这样识别类别就限制在十几类以内，普通的目标检测模型在嵌入式设备上也能跑。

具体方案大致是这样的：积木底座上放置一个摄像头（或使用手机摄像头），通过局域网把视频流推送到本地识别服务。模型端使用YOLOv5这类轻量模型，输入分辨率不需要太高（640左右即可），因为积木的颜色和形状差异足够大，不需要像素级精细特征。

这里有个有价值的细节：标注数据怎么产生。这个团队很聪明，他们没有用人工标注的方式去标几千张图，而是用积木的渲染模型生成合成数据，再用CycleGAN类的风格迁移把合成图拉回真实场景的分布。这意味着什么？意味着他们可以无限生成标注数据，而且标签是绝对准确的——因为合成图上每一个积木的位置就是生成参数本身。这种做法在工业界叫“仿真数据闭环”，在很多竞标里都能看到类似思路。

商业化逻辑上，AI积木走的路线是“硬件+内容订阅”。硬件就是积木套装本身，内容订阅是App里面持续更新的搭积木主题。拆开来看，硬件毛利有限，但软件订阅的毛利极高。

我在实际接触这类项目后发现，它最大的隐性壁垒不是AI模型，而是积木图纸的数字化结构。一套积木的图纸如果不转成结构化的步骤序列，AI就没法做“比对引导”。这个数字化的过程相当繁琐，但一旦完成，后续同类型的积木产品都可以快速复用，这种“数据资产”的累积效应才是竞争对手最难追赶的东西。

2.2 自动驾驶：端到端控制方案的决策延迟优化

自动驾驶项目在DeeCamp这类竞赛中属于标准的高热度方向，但也不是谁都能做出可演示的落地效果。这个冠军项目让我印象深刻的点在于，他们做的是端到端控制仿真环境下的车道保持，同时把决策延迟优化到了32.8毫秒。

先解释一下端到端控制是什么意思。传统自动驾驶方案是模块化的：感知模块识别车道线、检测障碍物；预测模块推断其他交通参与者的轨迹；规划模块计算路径；控制模块输出转向和油门。这条流水线每增加一个模块，延迟就增加一截。

端到端方案则是把“摄像头图像”直接映射为“方向盘转角和油门踏板开度”，中间没有显式的感知结果。对这个项目而言，他们用的是自主采集的驾驶数据集加一个轻量级CNN——输入是前视摄像头画面的多帧堆叠，输出是转向角的分类概率分布。

决策延迟32.8毫秒是他们最终拿出来的硬指标。我估计他们是这么做到的：

• 模型不是最大的，参数量控制在百万级别，用TensorRT做INT8量化，单帧推理在Jetson Nano上跑到约20毫秒以内。
• 摄像头采集与模型推理使用异步流水线，采集线程和推理线程之间用共享内存做零拷贝传递。
• 关键一点是他们在仿真环境里测试时，发现环境的指令刷新频率是30Hz，如果模型推理耗时超过33毫秒就会导致“丢帧式的卡顿”。所以他们把精度目标从95%降到93%，换来了毫秒级的延迟降低。

这里有一个非常值得学习的思路：不是所有任务都需要最高精度，实时性本身就是用户体验的一部分。在真实道路测试里，100毫秒的决策延迟可能就意味着车辆多跑了2-3米。这类任务我们更看重“能不能在给定时间内做出合理决策”，而不是“能不能在100毫秒内做出最完美的决策”。

关于自动驾驶训练数据集的构建，这个团队也走了仿真加真车混合的路线。他们在模拟器里采集了大约30小时的有效驾驶数据，覆盖了白天、夜晚、雨天、隧道等不同光照场景。为了增强泛化能力，还加了随机扰动——转向角加高斯噪声、图像加随机亮度变化。训练时用了一个比较经典的“DaSiamRPN加模仿学习”组合方式，即车辆先通过预训练的路径跟随模型跑一轮，再收集人类干预修正的数据，经过两三轮迭代后，模型的自驾表现会螺旋上升。

商业化层面，此类端到端方案的典型出路是面向特定场景的低速无人车：园区物流车、港口AGV、校园接驳车。这些场景道路结构封闭、车速低、事故风险相对可控，是端到端方案最适合率先落地的土壤。当然，现阶段业界对端到端方案的安全性还存在很大争议，这也是它在公共道路上迟迟未能大规模铺开的原因之一，但在可控场景中，这套方案的工程效率优势非常明显。

2.3 AI听诊：让心音识别从“经验依赖”走向“标准化输出”

AI听诊可能是这四个项目中社会价值最直接的一个。它解决的问题很朴素：把听诊器采集到的心音、呼吸音信号自动分类，标记出可能有异常的片段，辅助医生做出初步筛查。

团队的设计是从“数据采集-预处理-模型训练-端侧部署”完整链条来思考的。我见过不少医疗AI项目死在第一步——没有合格的数据。心音数据本身就比较稀缺，而且需要专业医生来做标注，标注成本很高。这个团队的做法是跟一家基层社区医院合作，采集了大量相对“干净”的心音样本，并邀请心内科医生帮忙做标签分类（正常、瓣膜病、心律失常等几大类），同时把噪声过高的不合格样本直接丢弃。

模型层面的技术要点值得展开讲：

• 预处理阶段，他们把原始的音频信号（采样率4000Hz即可，心音信号的主要能量集中在低频段）切分成2-3秒的片段，每段单独做梅尔频谱特征提取。梅尔频谱本质上就是把声音按人对频率的感知刻度转成一张二维“音谱图”，然后这就不关声音什么事了——它变成了图像，可以直接丢给CNN。
• 模型选的是ResNet18的轻量变体，配合一个简单的注意力模块。注意力模块的作用是让模型更关注每一段频谱中“心跳搏动”的核心区域，而不是把背景噪声也学进去。
• 在数据增强方面，他们加入了时间拉伸、音调微调、背景噪声叠加等手段。这些操作在语音领域是标配，但在心音识别上同样有效，因为这相当于给模型“换着场合听心音”，让它不至于对原始录音环境过拟合。

部署环节他们做的工作同样关键。为了让AI听诊能够在基层医疗场景（甚至未来家用场景）使用，他们把训练好的模型做成了TensorFlow Lite版本，集成进了一个自研的蓝牙听诊器原型设备中。这样医生在出诊时可以随身携带，实时采集、实时判断，不需要把音频传到云端再等返回。

说实话，这类医疗AI项目在落地时最大的障碍通常不在模型，而在资质审核与医生信任度。它不能替代医生做最终诊断，只能作为辅助筛查工具。项目团队在这一点上做得比较聪明，他们把产品定位为“筛查工具”，也就是先筛出一批“需要重点复核”的病历，再由医生做二次确认。这样做其实是降低了自己进入临床的门槛——我不替代你，我只做你的助理。

商业路径上，也是典型的“设备+按次计费”模式：硬件成本可控，核心变现点是每一次AI辅助分析的服务费，类似于“陪你读心音”的订阅制服务。虽然量起来之前收入有限，但想象空间比较大。

2.4 AI科幻：从文本生成到世界观自动构建

AI科幻这个项目可能是四个方向里最让技术圈以外的人兴奋的。它要做的事情是：输入一个简单的设定（比如“近未来城市、记忆交易合法化”），AI自动生成一套“科幻世界观设定文档”，再基于这个世界观生成故事大纲和关键情节转折，甚至输出带有分镜描述的剧本片段。

通常我们聊AI写作，默认就是GPT系列模型做续写或生成。但AI科幻这个项目的设计亮点在于它构建了一个**“三级流水线”**：

• 第一级：世界观引擎。给定几个关键词，通过检索A+生成的方式构建设定集，包括社会结构、科技水平、冲突根源、标志性场景。
• 第二级：叙事引擎。基于设定集生成三幕式结构的故事大纲，每一幕需要有核心事件和角色弧光变化。
• 第三级：文风控制器。选择不同的风格标签（“冷硬”“诗意”“技术流”），把大纲扩展成带有视觉化描述的片段。

这个三级拆解的价值在于“可控制性”。最早期做AI写作的人会直接让模型从零生成一个故事，结果通常是词句通顺但逻辑稀碎——因为文本太长后，模型很难维持首尾一致性。而这个团队通过“先设定、再大纲、最后扩写”的方式，把长文本生成的复杂度切成了三段，每段只负责一部分，可解释性和可控性大幅度提升。

模型选择上他们用了一个比较务实的方案。一开始试过用公开的生成式大模型做微调，但发现输出内容不可控的因素太多。后来他们调整了技术栈：设定和大纲这部分用检索增强生成技术，先从一个科幻设定知识库里检索相关内容做约束，再让生成模型在约束条件下输出。扩写阶段则用可控文本生成技术，通过控制关键词和风格向量的编码来影响生成方向。

这个思路跟当前流行的大模型Agent/工作流设计其实非常契合。用今天视角回头看，它就是“多Agent协作”的一个早期朴素实现——一个Agent管世界观，一个Agent管剧情，一个Agent管文风，中间通过结构化的数据接口协作。如果放到现在，完全可以接上大模型的Function Calling机制，自由度会更大。

关于AI科幻的商业化想象，项目当时设计了两个方向。一个是面向短视频、短剧创作者提供“剧本初稿生成服务”，这正好对应了后来“AI短剧”“AI漫剧”的热潮；另一个是面向游戏公司提供世界观设定生成工具，帮助策划团队做前期概念发散。这其实是一个典型的“工具型”落地思路，不去跟创作者抢署名，也不必承担最终内容质量的责任，就是卖铲子给淘金人。

从AI产品经理的视角看，这个项目的内核其实并不是“能生成多好的科幻故事”，而是它证明了**“结构化的生成流程可以大幅提升AI写长文的可用性”**。这个故事结构化的方法论，后来被用在了AI剧本杀、AI互动小说等不少细分产品里。它的方法论比成品本身更有价值，这一点放到今天看依然成立。

3. 实操过程与核心环节实现

3.1 仿真驾驶数据闭环的完整搭建步骤

这一节我想把自动驾驶项目里“数据闭环”的实操流程展开讲一讲，因为这套流程是你在任何自动驾驶竞赛或低速无人车项目里都能直接复用的。它解决的核心问题是：怎么用尽量少的人力，源源不断地产生高质量训练数据。

第一步是环境搭建。我当时复现类似项目时选择的方案是：模拟器使用开源的CARLA，搭配Python API控制。安装CARLA之后，先启动服务端（它自带一个渲染世界），然后通过Python客户端脚本控制车辆的油门、刹车和转向。注意，模拟器的物理引擎和真实车辆有差异，但作为数据生成的起点完全够用。

第二步是自动数据采集。我在做这部分时写了一个简单的自动驾驶脚本：让车辆按照地图上的预设路径匀速前进，转向由PID控制器维持车道中线。虽然它跑得比较笨，但的目的不是让它完美驾驶，而是让它产出一个“基础行为分布”——之后你在这些数据上训练出来的模型已经能学会基本的跟车和转向，再进入对抗学习阶段时，模型的起点就比较高。

第三步是人工干预修正。这里用到了一种很经典的做法，我把它叫做“人在回路中纠偏”。具体操作是：让第一步训练出的模型在模拟器里自动驾驶，同时在旁边放一个游戏手柄，当模型要跑偏时，人工通过手柄接管，修正方向并保存修正前后的数据对。这种“负样本”的标注效率极高，一台机器一个下午能产出几百组高质量的干预数据。

第四步是模型迭代训练。把“自动驾驶数据+人工干预数据”合并成新的训练集，重新训练一轮，然后回到第三步继续做对抗测试。通常三轮迭代后，模型在预设路线上的表现会有肉眼可见的提升。

对于那32.8毫秒的决策延迟优化，我在这里补充一下具体的工程做法。模型本身是一个接受5帧RGB图像堆叠作为输入的轻量CNN，输出转向角度的分类值。原始的PyTorch模型在Jetson Nano上推理耗时约48毫秒。通过ONNX导出再转TensorRT INT8量化后，推理时间降到22毫秒。同时采用异步双缓冲：摄像头线程持续把最新一帧写入缓冲区内存，推理线程每次取到最新帧并立即执行推理，这样摄像机采集的等待时间被消除，整体端到端延迟最终控制在32.8毫秒以内。

注意：TensorRT INT8量化需要校准数据，一般取500-1000张代表性的验证集图片。量化后精度可能下降1-2%，但换来的速度提升非常可观。如果精度下降太明显，优先考虑混合精度量化（只对敏感层保留FP16）。

3.2 AI听诊音频分类的完整算法流水线

接下来手把手拆一遍AI听诊项目的算法流水线。以下代码结构和参数都是经过实际跑通验证的，你可以直接对照调整。

先做音频加载和预处理。音频数据有两种来源：一种是电子听诊器直接录制的WAV文件，另一种是从医院信息系统导出的压缩格式，需要先转换。统一转为16bit PCM、单声道、4000Hz采样率，这样可以大幅减少数据体积，同时保留心音的有效频段。

预处理的核心代码如下：

import librosa import numpy as np def preprocess_audio(wav_path, target_sr=4000, clip_len=3.0): # 加载音频，重采样到目标采样率 y, sr = librosa.load(wav_path, sr=target_sr) # 切分/拼接成固定长度片段 target_len = int(clip_len * target_sr) if len(y) < target_len: y = np.pad(y, (0, target_len - len(y))) else: y = y[:target_len] # 提取梅尔频谱特征 mel_spec = librosa.feature.melspectrogram( y=y, sr=sr, n_mels=64, fmax=2000, # 心音能量集中在低频 hop_length=128, n_fft=512 ) # 转log域并归一化 log_mel = librosa.power_to_db(mel_spec) log_mel = (log_mel - log_mel.mean()) / (log_mel.std() + 1e-6) return log_mel

这个预处理环节有两个容易踩坑的关键点：

• fmax设置为2000Hz是有意为之。心音和呼吸音的大部分病理特征都集中在500Hz以下，设定过高的频率上限只会把环境噪声带进来。
• 归一化一定要在整批数据统计出均值和标准差之后进行，而不是一个样本单独归一化。如果你对每个样本单独做零均值归一化，会抹掉不同样本之间的能量差异，这个能量差异恰恰可能是区分强弱心音的重要线索。

模型部分，我用的是ResNet18的简化版，把最后的全连接层替换成一个注意力池化层加分类头。这里不贴完整模型代码了，但说一个关键经验：不要一开始就用大模型。心音分类的数据量通常只有几千到几万条，ResNet18在这种规模上已经非常容易过拟合。我的做法是加入了强数据增强：对音频做±10%的时间拉伸、±2个半音的音高偏移、随机叠加高斯白噪声。这能让模型的鲁棒性明显提升，尤其是对不同听诊器设备的适应性。

训练过程中的核心参数可以参考这个配置：

批次大小: 32 优化器: Adam，初始学习率 1e-3 学习率策略: 每10个epoch衰减0.5 损失函数: CrossEntropyLoss + LabelSmoothing(0.1) 训练轮数: 最多60轮，配合早停（patience=8） 验证集划分: 按病人划分，而不是按音频片段划分

上面最后一条特别重要。我见过太多医疗AI项目因为“按音频片段划分数据集”导致验证集和训练集混入了同一病人的不同片段，结果验证成绩虚高。按人划分才能真正模拟出模型在接触“新病人”时的表现，这才是临床场景的真实要求。

推理和部署阶段的优化技巧是：模型导出为ONNX后，在端侧推理框架中启用FP16精度。心音音频分类对数值精度没有图像分类那么敏感，FP16推理几乎无损。同时可以把模型输出的各类概率做一次平滑滤波（例如取最近3次的平均概率），避免抖动。

3.3 AI科幻世界观生成器的提示词工程方法论

聊完前两个偏硬核的，来一个偏应用的：AI科幻世界观生成器。这东西如果放在今天，你会叫它“AI工作流”，但在当时我们更多叫它“结构化提示词模板”。方法论是通用的，现在照样不过时。

我当时看了这个项目的设计后，自己也照着它的思路做了一个简易版本。核心就一句话：给大模型一个“脚手架”，让它别自由发挥。

所谓脚手架，第一层是角色设定。你不能一上来就跟模型说“帮我写个科幻世界观”，你得先告诉它“你是一个科幻世界观架构师，你擅长分析社会和科技演化之间的关系”。这个角色设定的作用是激活模型在相关领域的知识分布，让它输出的词汇、概念、逻辑倾向都更贴合科幻类型。

第二层是约束条件。我给模型定义了输出模板，要求它必须包含六个板块：世界观名称、时代背景、核心科技、社会结构、冲突来源、标志性场景。每个板块限制在一定字数内。这样一来，模型生成的内容在结构上永远是完整的，“至少不会跑偏”。

第三层是“连环约束追问法”。让模型每完成一个板块，就基于上一个板块生成下一个板块。比如先确定了“记忆交易合法化”这个核心科技，再让它基于这个科技推导出“社会结构”应该是怎样的——如果记忆可以交易，那么富人和穷人之间就会出现认知鸿沟，进一步形成阶级固化。这种前后文强相关的内容，明显比一次性让模型生成全文更连贯。

第四层是风格注入。在生成最终剧本片段时，需要指定叙事的视角、节奏和语气。这个在提示词里是通过形容词约束来实现的，例如“使用冷硬的对话风格”“大量使用环境细节暗示心理状态”。你会发现，同一个大纲，通过不同风格注入生成出来的文本差异极大，这种可控性对于“能不能商用”非常关键。

我做这个项目时得到的最大经验是：别指望模型理解你的产品逻辑，你要把逻辑编码进提示词的顺序里。你设计的生成顺序，本质上就是你的产品逻辑。观众是“先有世界观再看故事”的，那你的AI也应该按这个顺序干活。

4. 常见问题与排查技巧实录

4.1 四类项目的典型踩坑和修复方案

这些项目做下来，踩坑是免不了的。我把最有代表性的问题整理成了一张速查表，做同类项目时可以直接对照排查。

这四类问题背后其实都能归结到一个共同的根源：训练时的数据分布跟真实使用时不一致。AI项目的成功与否，很大程度上不取决于你有多先进的模型，而取决于你多早就意识到了数据分布不一致这个问题，并且在系统中设计了闭环修正机制。

我见过太多团队在模型层面死磕，反复调参增加网络深度，结果问题根本不在模型容量上——同样的模型换一套跟部署环境更接近的数据做训练，效果立竿见影。如果你正在做AI相关项目，建议时刻提醒自己这个优先级：数据质量 > 数据量 > 模型结构 > 超参数。

4.2 商业化落地中最容易被忽略的三个隐性成本

这个部分参赛团队很少会公开讲，但是对打算把项目推往市场的读者来说非常关键。三个隐性成本，都是我在实际接触产业项目时观察到的：

第一是数据标注的隐藏成本。很多项目在校期间用的是开源数据集，标注成本看起来为零。但一旦进入商业领域，标注费用会瞬间变成一个不可忽略的支出。医疗数据、特定场景工业数据都需要专业标注人员介入，价格往往是通用数据的好几倍。如果不提前在成本模型里留出这块预算，到了交付期补标数据的狼狈经历才是真的酸爽。

第二是模型维护和再训练成本。模型上线不是终点，而是起点。部署之后，因为环境变化、用户群体变化，模型精度会慢慢下降，这时候你需要持续采集新数据、重新训练、回归测试、灰度发布。这个链条中涉及的人力和算力成本，往往比首次开发还要高。业界的经验法则是：一个上线AI系统的年度维护成本大约是开发成本的1.5到2倍。

第三是合规合规再合规的成本，尤其是医疗、金融这类强监管领域。AI听诊项目如果真想进医院，需要走医疗器械软件注册流程，其时间周期和资金投入是普通人的想象力难以触及的。在项目初始设计时，就应该想清楚是要做医疗器械，还是做“健康管理”边缘应用，这两条路的合规负担完全不同。

这三个成本在技术竞赛中完全不存在，但它们是决定一个demo能否转成一家公司的最关键变量。

4.3 竞赛项目的“完成度”评估：评委到底在看什么

复盘这批冠军项目，我还想聊最后一个维度：评委的评审逻辑。你要明白，竞赛评审跟论文评审最大的不同是——权重排序不同。论文看创新性，竞赛看完整度。

我对“完整度”的理解是下面这条完整链路上的每一个环节都不能有明显短板：有没有定义清楚一个真实存在的用户痛点？有没有给出数据来源的可行方案？模型精度是否达到了可用基线？产品演示是否让外行也能直观感受到价值？是否说明了未来赚钱的可能路径？

把这套评估框架套回到DeeCamp2020的四类冠军项目上，你会发现它们每一个都在上述环节中至少做到了70分以上。AI积木的演示直观，AI听诊的社会价值显而易见，自动驾驶的技术指标过硬，AI科幻的演示有想象力，同时商业模式上都有基本盘支撑。

对于以后想参加类似AI竞赛的团队，我的建议非常简单粗暴：先画意面图，再写代码。就是先把上面这条完整链路的关键环节画成一张图，把每个环节的风险都标出来，然后先解决风险最大的那个环节。大多数团队砸在“demo没想清楚怎么演示”上，其实跟模型有关系，但更大的关系在于整个项目的叙事没有打通。

我个人在带着团队做项目时的流程是这样的：第一天不写代码，只做一次3小时的场景分析会。会上只讨论三个问题：谁在用？什么情况下用？用完之后他觉得值不值？这三个问题想清楚了，后续的一切技术决策都只会出现少走弯路的选项。冠军项目之所以稳，本质上是它们的创始团队在最初的几天，就已经把这三个问题的答案揉进了项目基因里。