动笔写这篇文章的时间点是我大二的国庆假期第四天晚上，这时的Pulse已经可以初步完成一个教育类MVP产品所需要的大部分职责。再回首三个月前，刚听说自己要参与开发这个项目时，我只有一腔无知者无畏的莽夫之勇。如今经历了多轮产品迭代，我对产品开发的理解逐渐加深，也因清晰地感知到自己的成长而不由得产生了一种踏实感。我一个关系不错的朋友（也是一位开发了不少好玩项目的开发者）曾跟我说过：“做项目最难的有两个节点，一个是刚起步的时候，一切的地基都要你从头搭建；另一个就是在项目进行到70%的时候，这个时候你一方面要兼顾修复前面埋下的坑，另一方面要紧锣密鼓地完成收口，不能再天马行空地添加新功能了。”在我看来，Pulse的MVP阶段就是到了这样一个70%之痒的阶段，在这个特殊的阶段，我一方面对前面犯下的错误和埋下的坑有了更加深刻的理解，另一方面对后续巩固前面留下来的战果也有了更加清晰的认知。从各种条件上面来说，都是写这篇blog的不二时间选择呢。那么，接下来我将会以Pulse发展的时间作为线索，跟大家分享一下我在做这个项目里面收获的成长以及后续我做项目会复用到的一些经验。（以及抱歉，本文不能分享过于详细的项目细节内容）
回到最初，我接手项目的原因和我在这个项目里面的成长起点
说到我接手这个项目的起因，我想可以追溯到今年三月份左右：当时我与程院长坐一台车回我的母校开讲座，路上院长偶然提起AI Agent相关的话题，我当时早已接触了各种AI Agent类的产品，对于Openclaw、Codex、ClaudeCode等产品的使用经验和感受，我都能如数家珍地讲出来（那一趟回家，也是要帮一个投资人前辈做一些投资辅助工具的开发，现在仍在进行）。院长对于AI如何革新教育的话题非常感兴趣，见到我作为一个AI Native的本科生对于此类产品有一定浅薄的见解，遂推荐我结识Vibe Coding课程的主讲老师——潘剑韬教授。在七月份抵达湾大前，潘老师已经开始对GBU GEC019F Vibe Coding这门课进行思考和设计了，作为项目的另一个推进力量，我在这段时间也着手做了不少项目，进一步加深了自己对Vibe Coding的理解，同时我也组织和收集了CS101 26 Spring的相关作品，给本课程设计提供了一定的参考。
直到老师在七月份落地湾大，我们才在一堂山东大学来的教授分享Cursor使用经验的讲座上面第一次见面（我至今仍然记得，讲座上面老师分享的对于AI Agent使用上，他认为最重要的技巧是将大任务分解成小任务的能力，我在第一次经历了Solo大型项目开发之后也后知后觉地意识到了这句话的含金量。）下午，我便跟老师详细分享了我在项目起点的时候使用的一些对应的技巧：在做项目的时候，第一步先规划好项目应该怎么拆分，分成哪些slices，然后再拆tickets，让不同的agent分角色执行。也是因为受限于当时的Agent上下文管理能力和容量的原因，用一些人类用的管理学的方法，对自己项目执行的agent team进行一些能力互补上面的编排，还是会对项目的推进起到一些不错的效果的。（当时我还想着，多Agent协作存在的一个很大的问题就是读文档带来的信息反复转换带来的损失，现在貌似也有很多大神提出了解决方案，如Cache2Cache等）当时我和潘老师的交流，也让我看到了我们在工具使用习惯上的不同。潘老师主力的Coding IDE是Cursor，习惯于在IDE里面直接看代码、检查AI改动了什么；我当时更多使用Codex和ClaudeCode这样的工具，把注意力放在项目推进的组织方式和任务拆解上。现在回头看来，组织好Agent只是其中一部分，最后做出来的东西到底对不对，还是得认真检查。老师在开发和产品团队管理上的经验，也让我慢慢补上了这方面的认识。
项目起步，将我的过往经验用于项目的前期推进
七月后期，课程团队逐渐确定下来，我也完成了之前手上积压的一些工作，准备开始Vibe Coding课程相关平台的开发了。在老师的指导和支持下，我们逐步明确了开发的分工：叶同学负责学生工作区（AILab），我负责课堂工具（Pulse）。我和叶同学先搭建了课程所需的基础运行环境，并在一次线上会议上展示了初步成果。这份初步成果，让老师对我们的开发能力多了几分信心，也更放心地把后续的开发工作交给了我们。其实现在回头看来，这份分工也用上了我们各自比较擅长的部分。叶同学在技术实现和环境维护上很有经验；Pulse在开发的过程里面有很多features要添加，需要不断和老师以及学生磨合，获得真实的反馈来推动它发展，也让我用上了自己喜欢沟通和提出想法的特点。
确定了开发职责，老师给了我一份充满了详细功能规划和vision的文档，也把尝试定义首版范围的空间留给了我。如何从这完整的项目vision里面拆分出具体可落地实行的demo范围与MVP产品范围，就成了我要面对的第一步。我先拿出自己的判断，再和老师讨论，一步步收窄首版范围，优先完成核心课堂流程。现在回头看来，老师给我的这份自由，也意味着我要学着为自己提出的范围和最后的交付结果负责。这也是我在项目里面很重要的一份成长。进一步明确了开发范围之后，就可以开始进行具体的开发路线规划了。起初，我设定的目标是完成单节课的完整验收和闭环。不过在起步之后，缺乏开发经验的我在老师的指导下调整了开发优先级与开发的架构。在这个开发路线的指引下，我闷头开始了猛攻。
早期infra搭建，旧的开发流程和规范问题初显
进入正式开发状态一周之后，我动了出门散散心，当一段时间数字游民的念头，遂跑去了大理生活几天。去大理的高铁要十几个小时，这也给了我一个静下来的机会，可以充分思考一下项目要往何方发展，我后面的路要怎么走。第一次Solo Trip，心中对远方充满着期待，又有些第一次自己面对世界的小紧张（有时间了也写写这段有趣的经历）。
路上我也读了一些Hassabis的传记。惭愧的是，这本书我到现在还差一点没读完。
大理的Vibe无疑是充满了松弛和惬意的，但是紧张的DDL在前催促，我也不算很敢放慢项目推进的脚步，于是常常是早上check一下前晚上跑了通宵的任务，和老师开会商量下一步的推进节奏，制定好了一系列可以跑四五个小时的串行任务之后才动身出门走走。下午，大理的气场缓解了我因项目推进而紧绷的情绪。晚上回到住处往往又要检查白天任务运行的成果。检查完成果之后再开一个彻夜跑的任务，电脑放到一旁（当然是不能合盖的。。），往往时候不早。
就这样，在这一周奇妙的：在自然中充电->燃尽赶进度->再次去自然中充电，的循环里面，我初步搭建好了Pulse的infra。建立了三端的雏形、数据库、身份权限、事务与恢复、后台任务、实时同步这些基本的内容。在开发过程里面，除了硬性的第一节课开课时间之外，还有一个隐性的、时间未定的DDL在暗处观察着我——那就是给程院长做线下汇报的时间。程院长很难提前排出验收项目的时间，所以我们只好随机应变，尽量早地完成好我们的项目，我也一直没有买高铁票，随时等待着需要我跑回去线下验收的通知发出。
我们俩负责的模块不同，遇到的挑战和推进节奏也不一样。叶同学那边推进得比较顺利，我这边还在需求拆解和验收上摸索，随着演示时间越来越近，进度压力也跟着上来了。好不容易第一次项目流程跑通，我点击进入预览🔗之后，功能与我最初计划的相差了不少，很明显是因为我的验收粒度太粗了，Agent执行的时候偏离了目标的边界。好巧不巧，这时将会在两天后的下午向院长线下验收的消息又在会议上放出，我在大理最后几天的行程安排被彻底打乱了。我还记得离开大理前一天，开完会的那个上午我狼狈的样子：一只眼睛盯着合适的高铁票还有位置剩不；一只眼睛在盯着屏幕上的任务跑到了哪里；双手不离键盘，疯狂敲击着给Agent下达的命令。一项一项清单接着验收，一个一个Bug在真实联调与测试里面被揪出，一条一条Todolist上面的待办项被勾选上。在从大理回到广东的高铁上，我终于跑通了一个可以完成完整演示的demo。可是，在正式演示的时候还是出了一些岔子……
磕磕绊绊完成的演示，与第一次上课的灾难现场
即便我提前一个晚上回到了学校，在演示前两个小时和老师对过了一遍演示内容，正式演示的时候还是掉了链子。我当时还盼着这次能顺顺利利，老师却早就把可能出问题考虑进去了。按他以往的经验，代码部署到演示环境之后，几乎没有哪次能在第一次就一路顺到底；至于具体会在哪个环节出问题，却很难提前说准。所以，备用方案不仅提前准备好了，也事先演练过。现在回头看来，老师对现场的不确定性比我有经验得多，而我那时还在一门心思地修bug，想让演示尽量不出岔子。让我们把镜头转回到正式演示时——
在演示前半个小时，我还在修复着一些demo早上演示的时候遇到的小bug，直到演示开始前十分钟，我才来到了现场，而此时，我开的修复任务还没有跑完。当时我的心情，自不必多说，对于演示可能会翻车的情况我设想了诸多种，唯独没想到演示开始时bug修复的任务还没有跑完。可是院长已经在演示开始的时间准时落座会议室，不开始是不可能的了。我咬咬牙，从side chat里面获得了预估的完成时间：“10分钟”。我心里一紧，看来有机会，只要叶同学先讲，把时间拖长一点，我这边的任务就有机会能够完成。于是，我接过了刚开始演示的叶同学的话头，帮着他介绍起了他那部分的平台功能来（ailab），也是在给我的项目修复任务争取时间。我一边尽可能详尽地展示着叶同学那边工作的各项功能，对着院长侃侃而谈，在介绍之余也用余光瞥了瞥我的bug修复任务界面，不由得咽下了介绍功能时产生的唾沫。
终于，在ailab的介绍几近尾声的时候，Pulse的bug修复任务终于跑完了，看来side chat果然没骗我。我单手比划着演示大屏上面的ailab相关功能，另一只手在忙乱地准备着临时演示环境，以便院长可以用他的手机体验Pulse师生互动的相关功能。“那ailab相关的功能介绍就到这里了，下面我们要介绍的业务模块是学生上课的时候要使用的平台：GBU Pulse。”看着院长和两位老师对于ailab演示功能满意的神情，我不由得对Pulse的演示多了几份信心。一切看起来也似乎是很顺利的，直到…
“可以看到，教师端发出了Survey之后，学生就可以同步进行回答…”一下子，演示的三端全部亮起了Network Error，临时演示环境遇到了网络连接问题。我顿时有点手足无措，好在潘老师早有准备，接过了话头，按之前演练的备用方案，用Slides继续讲述着课程的相关理念，我也借由潘老师争取下来的宝贵时间更换了网络连接方式，最后也是磕磕绊绊地完成了这一轮简陋的演示。
等到院长走出会议室的那一刻，我长舒一口气，擦了擦额头上出的汗，“总算是迈过了这第一道坎了。” 不过，潘老师也是在会后和我们重新讨论了事项优先级和主要的风险点，给我们的下一个阶段目标设定好了行进路线。“忙完这一阵，就可以忙下一阵了。” 虽然苦，我也是乐在其中，在实践中悟到了很多软件开发的原则，增长了自己项目组织和推进的能力，也对Agent的理解上了一层楼。
按照潘老师的构想，下一个阶段的重点是为正式课堂使用做好部署准备。部署资源需要多方协调，我们也需要在有限的资源下控制运行成本，并验证平台的承载能力。随后，新的挑战又出现了：本门课程因为太受欢迎，原本预订好的140个名额被学生瞬间抢空，同时还有很多没抢上课的同学表示要来旁听。此时我还没有意识到问题的严重性，想着再怎么样，Pulse已经在上线前经过了多轮验收没问题了，而且初期的业务复杂度不高，应该也对服务器的压力不是很大。结果，真正的噩耗，在我们上课前的早上传出来了：190名新生在教室里面上CS101的时候，AP压力过载，教室里面的所有人都连不上网。看来，下午上课的时候我们的平台也要经受一样的考验了…
我提前了两个小时到教室里面测试，果不其然发现了新的会影响课程推进的bug，面对着上课时间一分一秒地推进，我只好硬着头皮上hotfix，那两个小时里面，我几乎失去了对时间的感知。一方面是选课和准备旁听的同学们对这门课程的期待，一方面是所有人的精心准备，我有着不能输的理由口牙！上课前半小时，我终于在本地打包好了新的交付包，开始上传到服务器并更新。
“老师，我们上课要用的是哪个平台啊？”
“老师，为什么上课用的那个链接进不去啊？”
“老师，上课的平台有什么功能啊？”
此时，我作为TA的身份还没有披露，但是同学们对于这门课的期待和热情，也在上课前切实地传导到了我这里。
时间继续流逝，在上课前十五分钟，我终于上传并配置好了Pulse第一节课要用的最终版。老师也成功地在教室打开了签到链接，投送到了大屏上。同学们鱼贯而入，熟练地掏出手机，扫码登录，签到。坐在第一排的我，表面上波澜不惊，内心其实早已翻起了惊涛骇浪。“至今一切正常啊，不赖。”旁边的叶同学说。老师也在讲台上悄悄给我比赞。此刻，我自己从零开发的产品终于开始在真实课堂中服务同学，这份成就感的暖流流经了我全身，让我在心里不由得哼起了欢快的小曲。
不出意外的话，意外就要发生了。随着越来越多的学生进入教室，早上在CS大班课上面发生过的Network Error，又重现在了第一节Vibe Coding课上。“老师，我登录不进平台。”“老师，我闪退了。”渐渐地，因无法正常使用平台而导致的抱怨充斥了整个教室。结合早上CS101课堂的网络故障，我当时判断，教室网络的承载能力很可能是主要瓶颈，也担心服务器资源不足会进一步影响平台使用。但仅凭这些报错，还不能确定各个因素的具体影响，也不能保证减少人数就能避免故障。令人焦急的是，进入教室的同学数量还在不断增加。到了上课铃响的那一刻，现场已经有140多人。教室的容量只有128人，很多晚来了没有拿到位置的同学只好站着，或者是坐在地上。看来平台的问题是没有办法短时间内修复的了。老师便切换到了提前准备好的应急方案，用Slides和板书继续推进课堂。
老实说，我整节课都没怎么能听进去。心里面充满了先抵达高潮又跌回到谷底的复杂情绪，明明准备了那么久的活动和平台，却没办法按计划完整演示，真是让人不好受啊…懵懵懂懂过去了两个半小时之后，我稍带沮丧地跟老师交流本节课的Pulse运行情况。不料老师却对Pulse的表现表示了肯定，签到功能和Survey填写功能测试成功了，就算是网络大范围崩溃，还是有那么几个幸运儿连上了网络，并且完成了部分功能的测试。
这已经是一个还不错的起点了，剩下的我们没办法解决的部分只能等待其他部门的协作了。经过老师的一番宽慰，我收拾了一下心情，立马投入到了下一周的更新与开发中……