ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

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

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_sr4000, clip_len3.0): # 加载音频重采样到目标采样率 y, sr librosa.load(wav_path, srtarget_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( yy, srsr, n_mels64, fmax2000, # 心音能量集中在低频 hop_length128, n_fft512 ) # 转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轮配合早停patience8 验证集划分: 按病人划分而不是按音频片段划分上面最后一条特别重要。我见过太多医疗AI项目因为“按音频片段划分数据集”导致验证集和训练集混入了同一病人的不同片段结果验证成绩虚高。按人划分才能真正模拟出模型在接触“新病人”时的表现这才是临床场景的真实要求。推理和部署阶段的优化技巧是模型导出为ONNX后在端侧推理框架中启用FP16精度。心音音频分类对数值精度没有图像分类那么敏感FP16推理几乎无损。同时可以把模型输出的各类概率做一次平滑滤波例如取最近3次的平均概率避免抖动。3.3 AI科幻世界观生成器的提示词工程方法论聊完前两个偏硬核的来一个偏应用的AI科幻世界观生成器。这东西如果放在今天你会叫它“AI工作流”但在当时我们更多叫它“结构化提示词模板”。方法论是通用的现在照样不过时。我当时看了这个项目的设计后自己也照着它的思路做了一个简易版本。核心就一句话给大模型一个“脚手架”让它别自由发挥。所谓脚手架第一层是角色设定。你不能一上来就跟模型说“帮我写个科幻世界观”你得先告诉它“你是一个科幻世界观架构师你擅长分析社会和科技演化之间的关系”。这个角色设定的作用是激活模型在相关领域的知识分布让它输出的词汇、概念、逻辑倾向都更贴合科幻类型。第二层是约束条件。我给模型定义了输出模板要求它必须包含六个板块世界观名称、时代背景、核心科技、社会结构、冲突来源、标志性场景。每个板块限制在一定字数内。这样一来模型生成的内容在结构上永远是完整的“至少不会跑偏”。第三层是“连环约束追问法”。让模型每完成一个板块就基于上一个板块生成下一个板块。比如先确定了“记忆交易合法化”这个核心科技再让它基于这个科技推导出“社会结构”应该是怎样的——如果记忆可以交易那么富人和穷人之间就会出现认知鸿沟进一步形成阶级固化。这种前后文强相关的内容明显比一次性让模型生成全文更连贯。第四层是风格注入。在生成最终剧本片段时需要指定叙事的视角、节奏和语气。这个在提示词里是通过形容词约束来实现的例如“使用冷硬的对话风格”“大量使用环境细节暗示心理状态”。你会发现同一个大纲通过不同风格注入生成出来的文本差异极大这种可控性对于“能不能商用”非常关键。我做这个项目时得到的最大经验是别指望模型理解你的产品逻辑你要把逻辑编码进提示词的顺序里。你设计的生成顺序本质上就是你的产品逻辑。观众是“先有世界观再看故事”的那你的AI也应该按这个顺序干活。4. 常见问题与排查技巧实录4.1 四类项目的典型踩坑和修复方案这些项目做下来踩坑是免不了的。我把最有代表性的问题整理成了一张速查表做同类项目时可以直接对照排查。项目类型典型问题根本原因解决方案AI积木模型在合成数据上精度很高一上真实摄像头就识别混乱合成数据与真实数据分布差异大加入风格迁移Sim2Real或采集少量真实数据微调自动驾驶仿真环境里表现很好换一个地图就“失忆”过拟合特定环境的道路纹理训练时增加随机化天气、光照、路面纹理参数AI听诊验证集精度很高但上线后对不同听诊器设备录音判断不准设备间的频率响应特性差异大采集多设备数据做域适应或前端加频谱归一化AI科幻生成长文本后前后设定矛盾人物名字/科技设定改变长文本生成缺乏全局一致性约束引入“设定记忆”模块让每个段落生成时都携带设定摘要这四类问题背后其实都能归结到一个共同的根源训练时的数据分布跟真实使用时不一致。AI项目的成功与否很大程度上不取决于你有多先进的模型而取决于你多早就意识到了数据分布不一致这个问题并且在系统中设计了闭环修正机制。我见过太多团队在模型层面死磕反复调参增加网络深度结果问题根本不在模型容量上——同样的模型换一套跟部署环境更接近的数据做训练效果立竿见影。如果你正在做AI相关项目建议时刻提醒自己这个优先级数据质量 数据量 模型结构 超参数。4.2 商业化落地中最容易被忽略的三个隐性成本这个部分参赛团队很少会公开讲但是对打算把项目推往市场的读者来说非常关键。三个隐性成本都是我在实际接触产业项目时观察到的第一是数据标注的隐藏成本。很多项目在校期间用的是开源数据集标注成本看起来为零。但一旦进入商业领域标注费用会瞬间变成一个不可忽略的支出。医疗数据、特定场景工业数据都需要专业标注人员介入价格往往是通用数据的好几倍。如果不提前在成本模型里留出这块预算到了交付期补标数据的狼狈经历才是真的酸爽。第二是模型维护和再训练成本。模型上线不是终点而是起点。部署之后因为环境变化、用户群体变化模型精度会慢慢下降这时候你需要持续采集新数据、重新训练、回归测试、灰度发布。这个链条中涉及的人力和算力成本往往比首次开发还要高。业界的经验法则是一个上线AI系统的年度维护成本大约是开发成本的1.5到2倍。第三是合规合规再合规的成本尤其是医疗、金融这类强监管领域。AI听诊项目如果真想进医院需要走医疗器械软件注册流程其时间周期和资金投入是普通人的想象力难以触及的。在项目初始设计时就应该想清楚是要做医疗器械还是做“健康管理”边缘应用这两条路的合规负担完全不同。这三个成本在技术竞赛中完全不存在但它们是决定一个demo能否转成一家公司的最关键变量。4.3 竞赛项目的“完成度”评估评委到底在看什么复盘这批冠军项目我还想聊最后一个维度评委的评审逻辑。你要明白竞赛评审跟论文评审最大的不同是——权重排序不同。论文看创新性竞赛看完整度。我对“完整度”的理解是下面这条完整链路上的每一个环节都不能有明显短板有没有定义清楚一个真实存在的用户痛点有没有给出数据来源的可行方案模型精度是否达到了可用基线产品演示是否让外行也能直观感受到价值是否说明了未来赚钱的可能路径把这套评估框架套回到DeeCamp2020的四类冠军项目上你会发现它们每一个都在上述环节中至少做到了70分以上。AI积木的演示直观AI听诊的社会价值显而易见自动驾驶的技术指标过硬AI科幻的演示有想象力同时商业模式上都有基本盘支撑。对于以后想参加类似AI竞赛的团队我的建议非常简单粗暴先画意面图再写代码。就是先把上面这条完整链路的关键环节画成一张图把每个环节的风险都标出来然后先解决风险最大的那个环节。大多数团队砸在“demo没想清楚怎么演示”上其实跟模型有关系但更大的关系在于整个项目的叙事没有打通。我个人在带着团队做项目时的流程是这样的第一天不写代码只做一次3小时的场景分析会。会上只讨论三个问题谁在用什么情况下用用完之后他觉得值不值这三个问题想清楚了后续的一切技术决策都只会出现少走弯路的选项。冠军项目之所以稳本质上是它们的创始团队在最初的几天就已经把这三个问题的答案揉进了项目基因里。
返回列表