距离这次服外结果下来其实已经过了一个半月了,很遗憾没有拿到奖,现在想起来还是记录一下心得与教训.此篇不打算细聊技术方面的问题,主要聊一下针对于服外这类比赛的开发方式和团队合作方面的问题.
服外赛制概况以及针对战略(A类赛题)#
服外队伍最多由五个人构成,今年的比赛从 2 月 11 发布赛题,到 4 月 22 截止提交(大概比往年缩短了两个月的时间),A 类赛题一共有 31 道,绝大部分题目基于大模型展开,大致可以分为:
- Agent交互
- 视觉识别
- 智能控制
- 数据分析与监控
- 平台与基础架构. 很多题目很有难度,但第一类的题目明显会好上手很多.赛制是不区分选题所有队伍一起竞争,并从最后每道赛题的参赛队伍数和获奖队伍选题的分布来看,并没有一定要选难题的必要,能保证自己的队伍可以完成项目并获得收获的选择可能更为稳妥.
提交材料要求为
- 所有赛题必须要提交的:1. 演示视频 2.概要文档 3.详细方案文档 4.简介 PPT
- 部分赛题会有额外提交要求,如项目源码,知识库,训练样本等. 同时,差不多一半多的赛题都是不需要提交源码的,能实际展示项目的只有一个视频,在不能完全确定队伍赛段内生产力的情况下选择这部分赛题至少能有效避免烂尾.而对这类赛题我们一般采用的战略是"面向演示编程",应当放弃传统后端思维:不需要管理用户数据,也不需要考虑任何性能和安全问题(甚至可以通过 Mock 数据或前端硬编码来进行替代).再加上当前服外比赛几乎完全围绕 AI 展开,所以程序方面的核心工作量应放在AI方向的算法设计,流程搭建上.
在此背景下，因为 AI 产品本身的高不确定性(如模型能力不达预期)，以及为迎合比赛对“创新点”(包含算法/流程创新和功能创新)的评分要求并保证产出，研发流程应当转向敏捷迭代. 关键生命周期节点应设定为:选题 -> 核心能力验证 (PoC) -> 最小可行性产品设计 (MVP) -> 敏捷开发与验证 -> 核心演示材料准备. 而在队伍组成上,由于选题差异和 vibe 的强势辅助,职责分配可以更加自由,以及在现在的趋势下,程序进行全栈开发或许是个更好的选择,但由于比赛重材料,重产品力,重演示的特点,队伍里最好要有强能力的产品岗和 UI/美工,有会剪视频的队员更佳,万不可将重心完全放到程序上.
团队组织与项目推进#
此次比赛我们遇到的最大的问题就在于这两点,上一节中提到的有几点建议就出于这一次的教训,在这里将展开.
我们的队伍是在赛题发布前就提前在部门中组好的,并由于组队前不了解部分队友的能力和能动性,导致队伍能力出现了严重倾斜,产品端生产力严重缺失,程序部分生产力也不抵预期,实际有效的生产力几乎只有三人.更严重的是当我们意识到这个问题的时候其实已经到比赛中期了,就是因为团队内系统化工作进度汇报的缺失.
所以比赛的第一个关键点从组队就开始了,要了解队友每方面的能力做合理的队伍搭配,并且比起基础能力更重要的是在比赛期间是否能提供应有的生产力,虽然由于比赛存在队员位序问题(根据贡献度队内自行排序,高位序在学校方面认可度更高)不应当要求每个队员都付出相同贡献,但至少不应该出现生产力漏洞.
项目经理/Scrum Master 也是同样重要的.平层团队可能在当前阶段更容易被接受,但在我经历这一次比赛后我认为有至少一个项目经理能在项目推进上容易很多,这里的经理并不意味着是上级,而是需要在项目的流程安排和每个节点上做牵头并把控项目迭代节奏,这样才能使团队有一个较为稳定的流程去开发,汇报和检验,而不是像一盘散沙一样最开始分工完成后就自顾自只完成自己的内容和小范围沟通(这就是我们这次比赛前半期所遇到的问题). 虽然队伍内成员的技术力肯定存在差距,但这个领导人的位置我认为不必要主动让给队伍中 能力/技术力 最强的那个人,而是应取决于组织力,大概率最开始找人组织这个队伍的人就能自然成为这个领导人,而关键是不能只找人组队,必须要做到组织开会讨论,流程制定等等.
提到的流程制定也是相当关键的一点.之所以我推荐在服外比赛中使用敏捷迭代开发而并非传统的瀑布流开发,除了前面提到的 AI 产品的不确定性和对创新点逐渐产出的原因外还有个主要原因. 因为队伍的生产力无法完全可控,如果按照瀑布式进程,队友因为特殊情况而导致未在预期时间内产出需要的内容就会导致后续内容难以推进,在这种短期开发的比赛内这种后果是难以接受的.比如我们队伍在比赛前期按照预定的标准化流程应该需要拿到产品原型图后然后再进行程序开发,但我们的产品岗因为个人原因在最后也没能有一版原型图有效产出,而我们前期就因为这个原因程序的进度陷入了一周多的停滞.而敏捷开发模式可以通过改变交付标准来解耦开发链路,迅速转向为降级策略而减少损失,保证进度不会陷入停滞.
而敏捷迭代开发在执行过程中一定需要制定迭代周期(如7天/周期),并在每个周期后进行一次短会汇报周期内工作进展,出现问题和特殊情况可立即做出调整并规划下一周期内容,提出新得出的创新点等等.同时,可以利用飞书机器人对 github 中的项目仓库进行监控,做到更实时的进度同步.
程序开发与核心创新#
在与获国奖队伍中的学长交流后,我对我们的程序开发也得到了额外的反思,打比赛的思路应区别于做产品的思路.
其一是技术重心的偏离,我们的 Agent 开发将重点放到了基础静态产出物的生成效果上,最终的生成效果其实是比较不错的,我们自己也将测试的产出实际使用了,虽然符合产品的核心价值,但这部分终究只是基础功能,再加强打磨只是吃力而不讨好,何况在最终的视频评审环节极易被掩盖或被低成本 Mock.所以核心工作应集中于进阶/衍生功能,有可能这部分在赛题里没做必要要求甚至可能只简单提了一次术词,但把这部分做好反而能成为核心竞争点.
其二是创新功能,我们队的几个创新点由于实现难度设计得比较保守,而这同样在比赛中达不到足够的竞争力.设想和落地是两码事,但正因如此,在无需提交源码的规则下设计创新点时应更加激进,针对高难度创新功能,最佳实践是:在前端通过 Mock 数据进行高保真交互展示,但在详细文档中必须必须提供严密的系统架构图,数据流转逻辑与算法伪代码,只要理论架构闭环且未突破当前硬件与开源技术的天花板,就能获得较高的创新评分.
其三是 算法/workflow 的创新,这是相当有含金量的一项,同时也相当有难度.实现底层算法和流程的创新和突破在比赛时间内是不现实的,但可以善用开源项目和相关论文,将前沿的单点技术引入到传统的业务流中进行改造.即便最终的工程实现未能达到最优的性能指标,在文档中也足够有含金量.
其四是美工/UI,我们队伍这次就完全缺少了美工,最后界面美观度尚可但没有任何记忆点和特色,只能算上普通.而由于服外着重于展示,所以有一个好看的界面和 UI 能提升很多印象分,让专员负责设计是很有效的.
提交材料#
这里主要谈及所有赛题都必交的四项材料,它们是评分的最核心判据.一定要关注每届参赛手册中对提交材料的详细要求,本次比赛我们就因忽视了部分格式规范,付出了相应的代价,这是极大的教训.
- 演示视频:视频是突破代码实现瓶颈的关键媒介.对于受限于算力或工期未能落地的功能,完全可以通过前端数据 Mock 和高保真交互模拟来展现完整的产品蓝图.对于大模型固有的推理延迟等性能瓶颈,也可利用视频剪辑技术进行合理的规避,确保获取最流畅的交互体验.
- 概要文档:参赛手册中有详细提到要写几节和写哪些内容,较简单.页数在 5 页以内即可.
- 详细方案文档:提交材料中工作量最大的一部分,一般来说页数50 页往上,字数三万字往上.包含但不限于项目背景和概要,团队简介,项目管理,产品方案,功能和交互设计,核心架构/技术/算法介绍,创新点介绍,商业计划,风险控制.即使在 AI 辅助下这部分的工作量也不容小觑,关键逻辑在于:不要被当前代码的完成度限制了文档的深度.即使是代码层面仅停留在概念验证阶段的功能,也必须在文档中补齐理论上最严谨,高可用的架构方案,并大量使用 UML 图,数据流图和算法伪代码来拉升技术深度.
- 简介PPT:套用商业路演的逻辑,更着重于剖析核心痛点,产品价值主张和技术壁垒.必须注意对页数上限的要求.
结语#
服外这个比赛认可度还算不错,但在专业性上有所局限,针对赛制可采用特殊战略.第一次参加团队型的开发比赛,过程中暴露了了生产力错配与流程失控的问题,成绩未达预期.但因为这次比赛我也跳出到新的开发方向,踏出了转型的第一步,也留下了这些心得为下次团队开发比赛做好准备.总的来说算是不少收获.
Reply by Email