从“人仰马翻”到“事半功倍”——大模型助力研发团队高效管理

如果无法正常显示，请先停止浏览器的去广告插件。

1. 毕鸣一

2. 深耕大前端性能优化多年，先后负责过多个大型项目的性能稳定性测试及测试工具平台的研发工作，当前负责终端、前端和跨端可观测产品的技术研发和平台建设先后对接了多个ToC、ToB和ToG的项目支持；进行了多次公有云、私有云、混合云的项目部署；落地了国内、亚太、中东、北美、欧盟等多种客户的交付实施

3. 行业分享及知识社区《QCon》《HarmonyOS开发者论坛·广州》等行业大会分享嘉宾《InfoQ》《腾讯云TVP》《腾讯云开发者》《腾讯程序员》等视频号直播分享嘉宾《腾讯云开发者》《腾讯技术工程》《工程师的分享》等公众号、知乎号媒体矩阵作者《腾讯云开发者社区》原创分享计划资深作者、优质共创者、年度创作之星《腾讯GO编程指南》参与编撰者《解析问题的艺术》课程讲师《腾讯学堂》聘任讲师

5. 目录

6. 从泥泞到坦途：大模型如何铺就高效研发之路

7. 日常遇到的经典“研发场景” 去年，某架构师反馈他Review了一位研发同学的代码，发现研发同学花了整整五天时间，只完成了一个简单的接口开发。他很好奇，为什么效率这么低？经过沟通，他发现，因为这里涉及到了研发同学不熟悉的模块，模块通信用了一个类似的RPC框架，研发同学把大部分时间都花在了阅读文档、熟悉框架和调试环境上，真正用于开发的时间不到20% 研发效能的数据统计某著名互联网大厂公开资料：研发序列人员只有 15%-25%的时间用于实际研发某新兴互联网企业内部消息：研发序列人员只有15%以下的时间用于实际研发某专注于产品的老牌软件公司：研发序列人员只有18%的时间用于实际研发团队自身数据统计：研发序列人员只有20%以下的时间用于实际研发

8. 从管理者的角度研发团队人员多、新人培训成本高、薪资福利成本高核心功能开发时间长，容易跟不上转瞬即逝的商务机遇期同时学习新技术新方案时间久，落地效果总是预期不符即使做个最简单的MVP版本也需要大量的时间成本从研发人员的角度十瓦的高速脑力一直被打断，没有完整的高效思考时间，提不起来速度重构的成本高、时间长，管理者无法接受，导致学到的高级技能只能做面试题，无法实际应用在工程项目中项目的历史包袱重，要在多个技术架构和语言中不断切换上下文，小心翼翼的避免踩坑

10.

11. 认知负担文档多、内容冗余、实时性差，研发人员需人工分析、比对、实验导致学习成本高走查数据流转过程耗时间，已有函数功能不了解，基础库的功能不掌握，导致重复造轮子，引入旧缺陷大模型文档知识库服务上云、接口上云步骤复杂，权限设置文档抽象可读性低，容易出现理解偏差

12. 1 “对话式”输出答案，并给出代码示例和参考文档数据展示 2 大模型学习RAG（知识库内容+基础代码知识）分析处理 3 统一归档、格式化、录入知识库格式清洗 4 已有的接口文档、配置文档梳理数据收集

13. 人肉知识库大模型知识库文档的易读性——完善的文档和完善的代码对话式大模型信息符合人类的基础认知，具一样，充满着对边界条件的说明，让人难以有易读性和效率高的特点，且可以拿原始的读懂，因为人类天然对文档类的多路径逻辑参考文档验证阐述难以理解文档的可读性——文档多到一定程度和没有文档是一回事文档的可维护性——当文档过时后，下一个使用的人是否能有效更新文档是一个难以衡量的事情，一般是文档有效性降低到一定阈值后，进行一场“运动式”的治理根据提前准备模版和提示词，让“需求”变得明确，从而可以做到“不要给非目标客户演示过于复杂的产品功能” 文档的可维护性可以通过修改提示解决，也可以通过增加正确的案例集来对冲，维护更加易用马斯克说过：人和AI有一个相似的点，学习训练需要很长时间，但逻辑推导仅需要很短的时间

14. 嵌入功能页面，让大模型知识库代填数据某内部云接口平台，一个新接口“上云”需要17个步骤，文档冗长，步骤繁多，研发同学在写好业务代码的同时，还需要专门花时间来上云，陷入了“研效沼泽” 新人没有文档的情况下，平均需要2-3天才能完成“接口上云” 新人在有文档的情况下，平均需要1天才能完成“接口上云” 撰写文档需要熟手1天工作量，平均更新文档需要新人0.5天工作量文档更新的次数越多，文档易读性越差，从而增加上云耗时，研效变差文档更新的次数越少，文档有效性越差，从而增加上云耗时，研效变差

15. 嵌入功能页面，让大模型知识库代填数据

16. 认知负担客户的反馈的信息通常有散、乱、少的特点，因为带有“自认为”的上下文，需要不断向上翻聊天记录在私有化交付的场景下，不同的客户，部署环境不同，每个客户的问题趋同，但客户之间的问题并不一定相同，需要有这个项目的“历史排障经验” 大模型文档知识库排障人员定期轮换，经验交接主要靠排障日志和排障案例，内容多，信息丰满度大，难以短时间消化，长时间难以准确记忆，导致低频问题始终低效处理

17. 1 2 3 4 “对话式”输出答案，给出处置步骤和命令和参考文档数据展示大模型学习RAG（案例（含标签）+手册+导图）分析处理统一归档、格式化、录入知识库打通工单系统、聊天数据接口收集工单复盘案例格式清洗数据收集

18.

19. 按照大模型方便识别的格式来写使用者在技术例会和复盘会上反馈效果定期组织技术例会和复盘会进行知识分享和评审自动化录入与基础知识更新

20. 大模型与研效的关系大模型与技术管理的关系坦途：高效思考和代码开发的事项技术管理者通常强调高质量的技术文档沉淀沼泽：重复且复杂耗时但难度不大的事项技术管理者通常强调有效的案例和事故复盘遇见沼泽，再好的车也加速不起来，例如：信技术管理者通常强调通用性的技术分享讨论息检索和归纳、系统配置、接口协议支持等历史经验来看，上面沉淀的“宝贵知识”有效性受限于而大模型擅长处理重复性、规则性事务，可以大脑“短时记忆”容量，受限于听众精神集中程度，受替代研发同学学习，从而显著降低认知成本，限于团队成员变更速率，让“宝贵知识”的流失率较高提高研发效率而大模型擅长处理拆分和搜索的事务，可以替代研发提高研效的关键在于找到这些沼泽，探索出快同学记忆，从而显著降低研发同学的认知成本，提升速搭桥的方案技术管理的有效性大模型不是替代研发同学去赶路，而是在沼泽大模型是提升技术管理有效性的重要手段，也是技术地上搭一个桥，助力研发可以高速通过管理者的重要助手和工具从泥泞到坦途：大模型如何铺就高效研发之路

21. 从混乱到清晰：大模型破解信息熵“飙升”难题

22. 项目中“需求信息流转”的常态场景客户一个“紧急需求”过来，售前架构师火急火燎的找到产品经理跟客户对齐，最终得到了50字的反馈；产品经理针对50字的反馈，按照自己的理解，写成了200字的需求文档；研发骨干针对200字的需求文档进行了技术评审，设计了技术方案，给出了排期工时并把预期交付时间给到了客户，需求也扩充为300字；结果在开发过程中，研发同学发现很多细节并没有在文档中体现，导致开发出来的功能与产品经理的预期相差甚远；更糟糕的是，由于信息传递不畅，测试同学对需求的理解也存在偏差（这里对“不符合预期”的功能点是新需求还是缺陷进行了多次battle），导致产出的功能客户十分不满，只能在不断加班和延期交付代价下个给到客户一个60分的功能，而且在后面的复盘会中，项目成员的发言变成了“甩锅”，后续执行的措施也变成了录音、录像等“证据为先”的原则，后续发会议纪要、邮件抄送所有干系人、回复务必确认等等也变成了以排除自身风险为目的手段，进一步降低了项目效率、项目士气和项目团队的团结

23. 行业项目管理现状项目管理的痛点根据Standish Group的CHAOS报告，全球软件项目当项目成员达到10人以上的时候，项目效率并的成功率平均为34%。这意味着所有参与调研的项不会随着人员变多而同比增加，反而会因为内目中，只有约三分之一能够成功地按时交付和满足耗，导致信息熵的“飙升”，甚至项目效率可能预期的需求出现负增长根据Standish Group的CHAOS报告，高达66%的失从项目管理的角度上来看，信息同步、颗粒度败项目中，大约60%的失败是源于需求问题对齐是项目管理者的主责，如果做不到位，也根据Standish Group的CHAOS报告，缺乏有效团队是项目隐藏风险的主要来源协作是ERP项目失败的主要原因之一从项目成员的角度，信息流转到我这里，希望根据Gartner的研究，超过50%的ERP项目失败是因得到的是，我听得懂的信息，我最熟悉的表述为需求问题，方式，但其他角色并不擅长这类信息的转换

24. “熵”的概念来源于热力学信息熵是信息论中的重要概念用来表达分子状态杂乱程度的一个物理量信息熵可以用来量化信息传递不确定性或混乱程度热熵只增加不减少熵值越高，信息的不确定性越大，沟通有效率越低，理论上只会增加不减少因素：系统吸收或释放的热量系统的绝对温度因素：信息源的确定性信息传递工具的有效性信息传递环节的个数

25. 提需求的人和写需求文档的人往往不是同一个人，容易出现“一句话需求”与详实的需求文档有Gap，导致了信息熵“升高” 需求评审不全面，导致需求的作用、意义和具体实现方案与“初心”有偏差，导致了信息熵“增加” 代码撰写者与需求评审者在技术理解上有分歧，按自己理解实现后，代码评审人员不了解需求具体背景，评审无法有效发现问题，导致功能带“病”上线开发（接口、注视）、运维（数据格式、数据库）测试（用例）等文档撰写随意，导致后期解决这个问题成本认知高，降低信息熵难度大

26. 把大模型当成信息传递的工具传统手段大模型辅助的手段逐个需求强评审——每个需求都叫对应的产减少环节——根据“模版、项目文档、历史相似需求品、研发、测试、运维同学仔细“过一遍” 文档和提示词”，把需求文档的撰写从简答题变成选逐个提交强评审——每次代码合入前进行集体评审，对需要修改的内容会议沉淀、邮件沉淀逐个功能强评分——需求完成后，根据需求提出方的评价，以及运维和测试同学的正负反馈，代码评审人员的打分综合判定评分培养招聘“多面手”、“翻译官”、“中间商” 择题，部分细节变成填空题；通过对话式的大模型，可以让提需求的人直接“写”出需求文档，减少信息传递的环节用好工具——在需求评审、代码评审等阶段增加大模型评审阶段，智能先行，解决60分位以下的问题，再进行人工评审，项目成员专注业务需求核心控制波动—— 根据最终撰写的代码逻辑，生成代码、文件修改记录，需求记录、测试用例，分别与需求提出者、评审者、测试人员“对帐” 在人性面前，行政管理上的奖惩效果不佳；天下之事，不难于立法，难于法之必行

27.

28. 1 2 3 4 评审维度完整、评审深度足够解决方案最佳评审维度完整、评审深度足够解决方案次佳评审维度完整，评审深度不足评审维度不全，评审深度不足 100 80 60 <60

29.

30.

31. 大模型在项目管理的作用大模型对项目管理的影响项目管理中存在大量重复性、规则性的信息传优秀的多面手、翻译官、中间商“失宠”：有研发经递工作，这些工作正是信息熵飙升的温床验的产品经理、有产品经验的解决方案架构师、有提高项目效率的关键在于：找到信息熵飙升的试地方，利用大模型来传递信息大模型擅长处理历史信息的收集、对比、总结归纳，这个点上可以有效抑制信息熵，提高信息传递效率和质量解决方案架构师经验的商务销售、有研发经验的测失宠不等于裁员，需要复合型人才去训练这个大模型，特别是知识填充、关键词设计、正负反馈工程效率的每一次大的迭代升级，都是减少“中间商”这个角色，中间商回到专业的岗位上、也是一种大模型最好的身位是：助手、实习生、对账检项目管理效率的提升，因为“中间商”角色本身需要测员具有丰富的业务经验和多角色历练，培养成本不低，同时个人核心能力的提升和价值举证本身难以得到上层管理者的认同从混乱到清晰：大模型破解信息熵“飙升”难题

32. 从“水杯困境”到‘信息枢纽’：大模型助力团队管理降本增效

33. “行业寒冬”的经典故事前年，某项目团队在“降本增效”的背景下，更换了一批新的低成本的技术人员。起初，团队对他们寄予厚望，希望通过培训和培养，快速提升他们的能力。然而，现实却给了当头一棒：新人上手慢、理解能力差、沟通效率低、培训成本高，个别几个培养出来后却因为薪资竞争力不足而流失。更糟糕的是，这些低成本技术人员的能力与项目要求存在明显Gap，导致团队研发水平在低水平徘徊，只靠几个“老人”撑着，团队士气也持续低迷。行业裁员和行业研发经费投入情况

34. 从基层管理者的角度从高层管理者的角度先天不足导致后天提升有上限，谁都想更高的薪资成本需要更好的业务营收来背书，要“天赋异禀”的战士，但需要更好的薪资标在业务没有突飞猛进的前提下，无法提高薪资标准准来吸引招聘有培训潜力的“新”人是一个解决方案，但部分聪明的“新”人会很快发现“投入产出比”的问题，存在培训完即离职风险如何提高非骨干成员的积极性是一个十分重要的点，在同等条件下如何让这些成员干的“爽” 灵活用工是行业大趋势，总公司、子公司、内包、外包更加符合团队梯队策略，作为基层管理者，要发挥好每种角色的能力和产出每个项目组中只有少数骨干能获得大部分收益，其他成员收益上限低，这符合公司经营模式，也是项目可持续发展的有效手段

35. 水杯项目成员水杯理论容量可培养的能力上限水杯现有水量目前已掌握的能力水杯有效水量目前可直接使用的能力水杯的杯口直径学习知识的效率

36. 以前对项目成员的要求是 “一专多能”，处处开花，现在对低成本成员的要求更多的只能是“一专”，多了可能“溢出” 业务知识零碎且硬知识较多，对于绝大部分“新”人没有实际项目经验（踩坑）时，“杯口”小，不易深刻记忆，导致培养周期长聪明的“新”人多问多思考，效率高，部分低成本的成员的沟通效率低，问的问题信息含量低，老人帮助成本高，帮助意愿低

37. 1 2 3 4 创造新的业务点项目专家创造性的解决业务难题用标准业务工具解决标准业务问题项目、业务背景知识、工具使用方式优秀的项目成员合格的项目成员项目文档

38. 暂时用不到的“硬”知识也放在水壶中注重定期分享和沉淀，评审通过后加入大模型知识库，这里可以有激励机制培养周期短、培养难度低专人专事效率高，干劲足不直接找“老人”咨询，减少低质量沟通

39. “小团队” 去年，某团队进行了组织结构调整，推行了小团队模式。起初，Leader希望通过小团队的灵活性和自主性，提升员工积极性和研发效率。然而，现 “小团队”的来源及现实痛点行业寒冬时的两种思路：“抱团取暖”与 “分路突击”，抢占市场一般用第一种，开拓市场一般用第二种实却让团队陷入了困境：小团队的管理工作占据了管理成本有下限，一级组织存在的那一刻大量时间，挤占了专注业务的时间；团队成员之间就会存在管理成本，不以人的意志为转移，小的沟通成本增加，导致信息传递效率低下；更糟糕团队导致组织层级变多，必然会有更多的沟的是，由于缺乏有效的管理工具，团队的OKR和通、协调、汇报成本 BSC经常对不上账，导致目标执行出现偏差。同小团队会导致管理人员变多，但管理能力时，修正这个内容也会引起新的成本，与小团队的跟不上的情况，毕竟在工程领域，大约每10-15 灵活高效的目标不相符名专业人员中会培养出一名优秀的管理者

40. OKR和BSC的范围来源于上级，是一个命题作文，同时历史OKR和BSC是高质量输入，符合大模型的擅长领域每日计划用于自我事务的梳理，数据质量高；而周、月、季汇报来源于“日报”范围清晰，符合大模型的擅长领域上传下达、颗粒度对齐是一级组织的最重要的作用之一，而信息沟通可以结合会议录音、邮件信息等高质量数据输入来生成，符合大模型的擅长领域

41.

42. 大模型在“水杯困境”的作用 “降本增效”是工程效能领域的永恒话题，低成本的项目成员更替即是“行业寒冬”的产物，也是工程效能领域不变的追求基层管理者的本质是在有限的资源下，产生更多的价值大模型在小团队管理的作用小团队的管理成本下限本质上是对信息有效传递和处理，这个成本不能少在上传下达、颗粒度对齐等方面，信息质量高、信息范围明确，是大模型擅长的领域低成本成员的学习容量不够大，大部分只能存储“高价值”的知识低价值的知识，知识范围固定、可通过知识沉淀增加数据质量，而大模型擅长处理这样的数据，从而形成用水壶来破解“水杯困境” 大模型知识库可以充当‘信息枢纽’，帮助团队高效传递信息，让团队成员专注于业务技能，提升员工积极性大模型知识库不仅是技术工具，更是团队管理‘赋能者’，帮助小团队走得更远从“水杯困境”到“信息枢纽”：大模型助力团队管理降本增效

43. 从数据海洋到决策高地：AI如何助力项目优先级决策

44. 客户真实反馈某头部金融客户：去年，团队负责一个应业务决策的难题软件工程项目中，随着行业的发展。用的升级改造，涉及运维、运营、产品迭代、团队成员分工越来越精细化、专业化，随研发重构、测试工具搭建等多个事项。项目初之而来的是成员间的自扫门前雪”的现实情期，收集了大量数据，包括客户反馈、系统日况，这就对项目负责人在项目领域的专业志、性能指标等，试图找出最影响客户体验的程度提出了挑战，由于“会哭的孩子有奶问题。然而，面对海量数据，我们发现难以快吃”以及“报风险才会有资源”的思想，项目速识别关键问题，项目的决策反复且效率低负责人每天都要决策资源的归属，而往往下，甚至出现了资源分配不当的情况，发了几在决策前，真实的数据被各个成员进行了个小版本试水后，客服部反馈客户满意度反而 “二次加工”，导致决策的“合理性”容易被下降了质疑，增加了决策的难度

45. 在下列场景下，如何快速识别最影响客户的事项，并确定其他事项的优先级？研发产品市场运营运维年度质量目标是崩溃率优化到0.1%以下近期用户们普遍反馈地图渲染很卡数分发现启动速度对新客留存有影响版本活动页面的质量需要重保近期TOP1工单指向转账频繁出现失败价值反馈价值反馈诉求s 诉求s 诉求s 价值反馈价值反馈决策者诉求s 诉求s 价值反馈

46. “在业务产品中，如何快速识别最影响客户的事项，并确定优先级？” VRIO模型… 1 2 3 4 决策最影响客户的事项结合分析结果判定客户影响范围单事件数据分析和批量数据计算指标真实应用数据：性能数据、行为数据、稳定性数据、日志数据、客户反馈数据决策者数据分析+人工分析数据分析系统海量数据采集

47. 海量用户真实体验数据智能分析应用“性能”、“稳定性”、“客户行为”现状，给出影响范围和解决建议单一维度数据的分析与聚合多维度数据整合分析

48. 大模型在“识别优先级”的作用在复杂项目中，识别最影响客户的事项并确定优先级，是一个耗时且复杂的过程。数据分析系统为大模型提供了高质量的数据来源数据分析系统和大模型的关系地基和高楼：数据分析系统是地基，为为提供坚实的基础，而大模型则是高楼，帮助团队从数据中挖掘价值大模型在业务管理角色而大模型则擅长从复杂数据中提取关键信息，提供客观的分析结果没有情绪的秘书、文员：数据分析的结果客观，没有感情、没有历史负担从数据海洋到决策高地：AI如何助力项目优先级决策

49. 大模型的角色定位一个基础扎实、知识广、阅读速度快、分析能力及格的员工一个知识广而不深，注意力涣散且不会积极主动的员工角色：助理、实习生、文字秘书、调研文员、文档工程师大模型的角色发展优秀的大模型：Agent——纯牛马普通的大模型：COT——工具人个人怎么用好大模型被动用好：嵌入研发流程、嵌入项目管理流程、嵌入团队管理流程主动用好：当成一个特质的“员工”带，管理者本身有知人善用的经验，在基础设施搭建完成后，可以作为第一批大模型训练师，基于“员工”亮点来安排工作用流程推动大模型的“主动”作为：使用者的正负反馈，自动化流水线的一环管理学两大观点

50. 1.低学习成本的AI的平台和工具 2.切实提高效能和质量的产出实践案例 3.低成本大模型算法+RAG 知识库 4.AI技能的学习和掌握 1.把AI嵌入到生产流程中：研发流程、项目流程、管理流程 2.基于AI的团队组织架构 1.使用者：相当于多几个员工帮忙，自己需要高效工作、需要轻松工作，需要摸鱼 2.管理者：老板需要渡过行业寒冬 1.行业需要懂AI的专家 2.老板喜欢会AI的员工 3.管理者需要AI来助力 4.我要成为AI浪潮的先行者

51.

52.

53.

54. 大模型正在重新定义软件 Large Language Model Is Redefining The Software