这是一个关于挑战、团队合作、创新和坚持的故事，它揭示了在高科技公司中，如何将一个复杂的大模型应用成功迁移到主平台的幕后故事。

第三季度收到公司决策，需要将大模型应用迁移落地主平台。尽管产品已在新平台落地并探索了很长一段时间，也收到了内测客户的很多反馈。但考虑到主平台的研发、测试等人员还未接触过大模型相关应用开发，平台与大模型结合的落地场景也有所不同，市面上可参考的解决方案很少，主平台的兼容性等因素，也算是一场硬战。

幸运的是这次“攻坚”小队都是合作了很多次的小伙伴们，正好可以通过记录产品从设计到上线大家的沟通（扯皮）过程，看看产品上线过程中会遇到什么。

因为优先级极高，从公司决策同步给产品，到进行研发评审给的时间非常短，在这很短的时间内产品需要考虑：功能是否能解决客户痛点、功能的可实现性与可延展性、定价的合理性、客户是会为此买单、是否需要分期上线、上线时间、培训与推广计划……虽然很顺利地通过了各类评审，但在真正进入开发阶段时，也会推翻之前的设计，这个时候产品提出的需求修改，一定会收获极度暴躁的测试和研发。

因为是全新的产品，部分方案具有开放性，大家也会头脑风暴，积极地贡献idea，讨论什么样的解决方案是最合理的，在会议中不停地推翻之前的方案，最终达成一致结果。有时候讨论出的方案很傻，但又找不到更好的方案时候，也只能暂时搁到一旁等头脑清醒些时再继续讨论。更不容易的是，投入的每位产研人员都同时肩负着其他项目的任务，会议结束后大家还得奔向其他项目。

到开发阶段的中期，随着问题的接连暴露和对上线后不确定性的担忧，我从一开始的信心满满到逐渐怀疑自己。主平台牵一发而动全身，开完测试 case的评审会后，我焦虑地在群里一一列出了自己的担忧点，最后总结：我们可能要完蛋了。

大家虽然在群里附和，但会找我单独聊，打消我的各种顾虑，告诉我没有100% 完美的产品，当下的方案已经是我们能做到的 100%最好的方案，我们需要选择相信自己。

当然开发过程不会是一直和和睦睦、相亲相爱的，一定会有扯头花互相推锅的环节。当测试发现问题时，产品和研发互相认为对方的锅，研发有时会有自己的想法，不跟着产品文档设计做，产品有时也会被研发指出忽略了一些判断逻辑，大家都绝不让步，非要辩个清楚，要对方给自己磕一个这件事才算完。当然，最后还是得握手言和，一起齐心协力解决问题，毕竟上线前能将问题暴露出来也是一件好事。

因为在争取提前上线时间，研发和测试 pd被压缩了很多，在原定showcase （研发按测试 case 过一遍流程通过后再交付给测试）的前一天，研发流程还没调通，为了不辜负大家的等待，研发在公司熬到了三点多才调通了流程，第二天坑坑绊绊，还算是顺利通过了 showcase。

进入测试阶段后，研发算是暂时交差了，测试同学开始焦头烂额了。禅道的 bug 数量急剧增长，在北京的测试同学想要抓到异地的研发同学快速修复找到的问题，会在群里同步报问题并@研发，而研发同学半边投入到这个项目里，另一半投入到其他项目里，不想总被打断敲代码，隔一段时间才会出现在群里，这时焦急上火的测试同学经常会让base 地相同的同事代去工位抓研发赶紧修。

测试阶段，产品除了需要在测试环境验收功能，还需要准备业务侧的培训材料，运维配置手册、市场宣传等资料。在上线前规范好运维流程。平常售卖方案是需要在这个阶段之前同步给计费系统侧排期做，这次因为售卖方案管理层已确定计费上线时间，暂不用考虑这方面。

就这么终于熬到了上线发版的日子，腾讯云上线发版的那个凌晨比想象中顺利很多，除了前端遗留了一个小问题决定第二周跟着阿里云修复上线， 并没有出啥大幺蛾子需要回滚。上线第一天运维报了一个问题但很快就解决了，大家都不敢相信这么短时间内做完上线的“硬“需求能这么顺利，算是闯过了第一关。

上线后对业务侧的培训如果没做好或同步到位，很容易出现销售同事单独找产品不断咨询：“什么时候上线的？”、“售卖规则是什么”、“哪些版本支持，怎么配置”……培训完后也不意味着可以马上看到用户反馈，b 端系统的新功能，从功能上线到培训再到销售进行售卖最后到用户使用后给予反馈，时间可能并不短，特别是一些“大而重”的功能，销售找到合适的客户进行投标到最后用户使用后提优化意见，可能一两个月已经过去了。

好的反馈可以给团队带来非常正向的激励，上线后当业务侧传来好消息时，同步到项目群里，研发和测试也会非常开心，转而更加有激情地投入下一期迭代中。