大模型时代下的技术管理“新思维” ｜年度盘点与展望
编辑 | 凌敏、冬梅
在大模型时代，技术管理面临着新的挑战和机遇。为了更好地应对这些挑战，管理者需要转变思维方式，重新审视技术管理的本质和目标。那么，大模型时代下的技术管理方式、方法发生了哪些变化？如何更新和改进技术管理的思维方式与策略？如何提升技术管理的效率和效果？
近日，InfoQ《极客有约》特邀某股份制银行数字化转型技术专家王辉，对话飞书项目前端研发负责人李梦泽，云知声董事长、CTO 梁家恩，Thoughtworks 中国区总经理肖然，一起探讨大模型时代下的技术管理新思维，共同迎接未来的挑战和机遇。
以下为访谈实录，完整视频参看：https://www.infoq.cn/video/HJOC4qt3mTCtsicJ4msb
王辉：InfoQ 年度技术盘点与展望系列直播的第三期节目即将开始，我是今晚的主持人王辉，目前在一家股份制银行负责推动数据化和数字化转型。随着大数据和人工智能技术的迅速发展，大模型已成为许多领域中不可或缺的工具。在这个大模型时代，技术管理面临着崭新的挑战和机遇。为了更好地迎接这些挑战，我们必须转变思维方式，重新审视技术管理的本质和目标。在本期直播中，我们将共同探讨《大模型时代下的技术管理“新思维”》，助力我们共同迎接未来的挑战和机遇。本期的分享嘉宾分别是飞书前端项目负责人李梦泽， 云知声董事长、CTO 梁家恩和 Thoughtworks 中国区总经理肖然。下面请三位嘉宾做下自我介绍。
肖然： 大家好，我是 Thoughtworks 的肖然。很高兴今天能够和大家分享一些关于技术管理的见解。我是一名技术管理者，在过去的十多年里，我不仅负责管理 Thoughtworks 的技术团队，还在协助许多研发型组织进行敏捷和数字化转型。从某种意义上说，我也是一个在这个领域不断学习的人。我希望通过今天的交流，能够获得更多的启发，同时也能够为大家呈现一些面向未来的思考。当然，由于时代变化迅速，我不敢说这些是绝对的洞见，但我希望这些想法能够帮助大家更好地应对未来的挑战。
李梦泽： 我是飞书项目前端研发负责人李梦泽。我们的飞书项目实际上是技术管理中沉淀出来的一套 SOP，是一种非常实用的技术管理工具。今天很高兴在这个场合能够与各位老师一起交流，探讨大数据和大模型时代下的技术管理。我相信这次交流会为飞书项目带来许多新的思路，注入新的活力。非常期待与大家共同探讨，在这个思想碰撞的过程中汲取新的灵感。
梁家恩： 大家好，我是梁家恩，来自云知声。作为一家人工智能领域的独角兽企业，我们专注于语音、语言和知识图谱的研究和开发。在 2023 年上半年，我们发布了山海大模型，成为大模型技术的提供商，为整个行业提供基于大模型的人工智能解决方案。作为公司的董事长和 CTO，今天非常高兴能在这里与大家交流。我期待在这个场合与大家分享经验、进行思想碰撞。
肖然： 我个人和团队的工作范围涵盖了从需求分析、产品设计、开发测试，一直到最后的运维等各个专业角色。GPT 技术可以应用于端到端软件交付的各个阶段，这使得这样的智能体能够参与并贡献于整个软件开发生命周期。从一个管理者的角度来看，我感觉这与以往有很大的不同。我曾经是一名开发人员，是从事研发工作的，当我转向管理职位时，我感到自己经历了从工程师到管理者的转变。这些过往的经验实际上是我在管理工作中能够引领团队从不成熟走向成熟的基础，这其中也包含了团队赋能和人才培养。
然而，去年的 GPT 给我带来了一种不同的感觉，就是这些过往的研发经验在未来的某个时间点似乎会变得无效。这也意味着，过去的经验可能无法在研发工程过程中帮助团队成长。因此，从去年年底一直到现在，对这项新技术我一直保持一份敬畏心态。此外，我也不断提醒自己要保持开放的心态，因为昨天的经验可能已经无法帮助今天的工程师们。未来，我们可能会发现新的方向和模式，这些新的方向和模式并不是我们过去的从业经验的延续。
如果问我最大的挑战或改变是什么，我觉得就是我们作为研发管理者现在需要承认过去的经验不一定总是正确的，我们需要更加开放地接受由于生成式人工智能技术带来的整个软件研发领域的变化，包括方法论、体系结构以及具体的实践方法都将与过去不同。
李梦泽： 我想从另一个角度回答这个问题。首先，我认为大模型的出现在一定程度上提高了我们的工作效率，这一点是显而易见的。其次，我想谈谈关于安全性审视的问题。 在提高效率方面，大模型对我们的产研工具产生了积极的影响。特别是在代码工具方面，大模型的支持下使得我们的开发效率得到了显著提升。通过利用大模型，我们能够将许多任务委托给外包，从而节省时间，同时保持对最终结果的掌控。
关于项目管理工具，我想分享一下我们内部遇到的实际场景。在以前，我需要通过工具和我自己的人工理解来获取有关下周截止产品、迭代产品、未完成需求和存在的 bug 信息，以及是否存在发布风险。然而，有了大模型之后，比如我们正在使用 AI 智能助手和飞书项目进行打通，我只需清楚地描述我的需求给智能助手，它就能够帮我在飞书项目中呈现相关数据，大大提高了我的管理效率。这是大模型对项目管理的一项有力支持。总体而言，大模型的出现使得技术管理变得更加便利且效率大幅提升。
第二点我想提到的是关于安全性审视。大模型实际上是一把双刃剑，因此大型企业相对于大模型的态度仍然是持谨慎自研的态度。尽管大模型给业务带来了正向收益，但公有模型的隐私和安全性相对较差，因此我们内部仍然会尝试自研或者自己部署开源模型。尽管这与公有模型相比有较大的提升空间，但逐步推进总是会有回报的。这是我对于这个问题的一些看法。
梁家恩： 我想从两个方面谈一下。首先，作为大模型的技术支持方之一，我们拥有在人工智能领域超过 20 年的从业研究和从业经验。大模型的出现让我们感到非常激动，作为在这个行业已经工作了 20 多年的从业者，我觉得大模型带来的技术突破令人兴奋。我相信大模型将成为我们业务的核心要素，甚至可能成为我们业务的基座。因此，在思维上我们必须先认知到这一点，这不仅仅是一个小技术突破，而是一个未来重要的业务方向。未来，我们将迎来许多基于大模型的 AI 原生应用。尽管我们不清楚具体的发展方向，就像 10 年前我们不知道移动互联网应用将走向何方一样，但这必定会实现。无论是否从事人工智能领域的工作，我们都应该了解大模型的原理、特点、优势和局限性。这对于我们能够更好地结合业务是一个重要的认知点，是思维上的一个重要进步。
其次，为了将这项技术应用到业务中，从管理角度来看，我们可能需要调整人才梯队。正如之前提到的，很多过去需要大量人工操作的工作，现在通过工具能够更有效地完成，因此我们在人才梯队的建设上需要适应新的业务流程。我们需要进行相应的人才结构调整，特别是在 AI 架构师和 AI 产品经理方面需要加速团队的培养，否则可能无法把握住这个新时代的应用。我们当时在设计移动应用架构时，与过去在 PC 领域的实践有所不同。从业务角度考虑，我们的架构师着重于如何最大化地发挥 AI 的能力，找到适用的场景。尽管 AI 这些大模型看起来很强大，但在实际应用中，我们会发现存在许多问题。在这个过程中，我们需要找到平衡点，发挥其优势，避免其短板。因此，这部分的工作需要架构师和专业的产品经理来负责。
总之，如果能够抓住这两点，相信我们可以跟上时代的潮流，应对未来的变化。
肖然： 作为一家咨询公司，去年下半年以来，我们就在帮助许多企业采用生成式人工智能技术。目前，我们观察到几个值得关注的趋势。首先，企业对信息安全的顾虑相当大，特别是在使用模型时，尤其是一些公有模型通过 API 调用的情况。企业都认识到必须锻炼自身的能力，但在真正结合到业务场景时，很多企业仍期待未来能够私有化部署模型。我们认为这一趋势在未来两三年将持续存在，因为对企业数据安全和隐私数据保护的敏感性不断增强。
第二个趋势是，由于大模型本身的微调和重训练在成本和工程实践方面逐渐变得更为成熟，企业逐渐开始接受领域模型的概念。例如，在企业的客服、财务和战略分析等领域，基于基础模型的微调和重新训练已经成为实际的工程实践。这种趋势在一些有实力的大厂和研发组织中逐渐显现，我们认为它可能会持续存在。
最后，我们发现企业在应对生成式人工智能技术和大模型带来的未来机遇和挑战时，主要建议是将其视为未来数字化平台的一部分，而不是孤立的技术。这带来一个重要的问题，即如何在企业和研发组织内部有效地进行工程化。工程化是使技术规模化使用的关键，它能够在研发流程和未来数字化产品中发挥作用。前两个趋势是我们观察到的，而最后一个实际上是我们认为在 2024 年有条件的企业都应该思考的问题，即如何有效地将人工智能大模型技术的能力进行工程化，以便在企业中被更多的团队所使用。
李梦泽： 刚才肖总在概念和细节上都进行了全面的介绍，所以我将重点谈一下我在日常工作中应用大模型的一些业务能力。最常见的场景之一是在面试过程中，飞书可以根据我的需求利用 AI 分析简历，在面试前向我推荐相关的面试题，最后提供一份全面的总结。这个系统可以从多个方面、多个角度帮助我们评估候选人是否符合招聘标准，同时也帮助我们节省时间，提高效率。
梁家恩： 关于大模型，我认为很多人可能仍将其视为一个提高效率的工具，它在效率方面确实非常强大。然而，作为生成式人工智能，它的生成性质可以启发我们更多的想象空间。如果能更好地挖掘这一点，将对设计和其他新领域产生帮助。大模型在数学方面可能相对较差，但仍然可以被用于探索数学问题，如陶哲轩等数学家所示，他们利用大模型探索数学问题，虽然数学不是大模型的专长，但这可能需要打开更多的新思路。
在大模型的选型上，经过一年的发展，至少在中文领域，中国的开源大模型在中文能力上与国外基本持平，尽管与 GPT-4 存在差距，但与 GPT-3.5 相当。对于企业来说，如果想使用大模型，可以从这些开源项目开始，成本相对较低，不论是由大公司发布的开源大模型，还是一些创业公司，如智谱、百川等，它们都在致力于大模型的应用。
对于技术实力强大的公司，可能会自己研发自家的大模型，强调如何将其应用于专业的行业场景。我们认为，对于一些相对基础且可由本科毕业生完成的工作，通用大模型可能已经足够满足需求。这是因为这些工作不涉及到特定领域的深度专业知识，通用大模型的泛化能力足以处理。然而，对于那些需要更深层次、更专业知识的工作，可能需要硕士或博士级别的人才来有效处理。在这种情况下，专业大模型可能更适合，因为它可以结合特定领域的专业知识，提供更为精细和定制的解决方案。
在我们的应用中，有两个主要板块，一个是个人与机器的交互，这是我们主要的业务之一，我们将使用大模型增强其交互体验。对话系统过去经不起人的十轮“蹂躏”，但现在我们可以持续对话，这是一种显著的进步，但仍然是一个相对基本的聊天和完成特定任务的功能。另一个探索较深的方向是与医疗行业的合作。医疗行业需要高度专业化的知识，我们将结合行业知识来减少在这些领域的“幻觉”错误，这在严肃场景中是非常致命的。解决这一层面的问题可能需要与在行业内有经验的公司合作，这可能会提供更具针对性的帮助，通用大模型可能无法达到这种定位的。
至于评估，根据业务进行数据评估可能是一个可行的方式，成本是所有解决工程问题时都必须考虑的问题，因为部署成本确实很大。在特定应用场景下，我们可能需要优化模型，减少与应用无关的参数，从而提高效率。
肖然： 开篇时我提到了一个观点，即底层思维发生了重大变化。多年来，我们一直在业务领导面前强调要从过去的经验管理转向相信数据，让数据来说话。虽然业务领导现在也接受了这一观点，认识到数据的重要性，但在技术管理者这一侧，我们很多时候还是会拿过去的经验和某个框架相比较。通过过去一年的实践，我们已经意识到生成式人工智能技术以及未来人工智能技术在软件工程中的应用将打破这一格局。因此，在底层逻辑和本质上，我们将不再是一代具有丰富经验的人，未来几代人可能才是真正具有实际经验的人。如果我们想要领导他们或者为他们指路，首先我们必须拥有开放的心态，愿意与大家一起开放性地探索。
我们知道研发产业是一个偏学习型的产业。在工作过程中，团队和个体的培养与业务的核心本质息息相关。我们团队每个成员的成长对于产品的交付非常关键。我们预计人工智能技术在未来将取得重大突破。在这个时候，我们更有必要将团队和个体的成长纳入技术管理的核心目标。尽管管理者可能受到实际管理投入产出、人效等方面的压力，但我们更需要关注的是团队是否有成长，团队成员是否感受到在团队中有学习的动力，并且是否在一个持续学习的环境中。我认为这是在变化中保持不变的因素，需要我们重新审视。
李梦泽： 我认为在技术管理者个人素养方面，需要特别强调两个关键素质：对技术的敏感度和技术判断力。这两点的提升需要基于充分的知识储备，使你能够更好地适应时代的发展。只有拥有对新技术的清晰理解，你才能做出准确的选择和判断。
在这个过程中，最有效的实践方法之一就是深入了解技术的原理，理解其内部构造。以 ChatGPT 为例，尽管我是前端领域的从业者，但我对这项技术产生了浓厚的兴趣。我研读了大量的技术文档，涵盖了监督学习嵌入、Transformer 模型等方面，并逐步消化理解。通过这个过程，我对于 ChatGPT 这类工具有了一种直观的认识，我学会了在何时使用，何时避免使用，心中有了一种清晰的认知。
其次，技术判断力是一个需要不断磨练的过程，因为它需要结合实际经验来进行。这是一个涉及取舍和博弈的过程。在团队中，你需要综合考虑人力资源、业务收益以及时间周期等多方面因素，这就要求你在实践中不断进行试错和决策，从而不断成长。当然，寻求优秀的导师帮助你进行评判也是一个很好的策略。因此，我认为敏感度和判断力是需要通过培养逐步形成的，同时也是技术管理者必备的两项核心能力。
梁家恩： 在技术领域，作为技术管理者，我们面临着技术不断演进的现实，这既有利也有弊。技术对于整个行业而言，我认为领先就是抢占时间差。在我的理念中，并不是说有了什么技术就一定比别人领先，而是看谁能够更快地实现。随着技术的不断演进，我们需要不断提高自己的工作节奏。这是唯一确保保持领先地位的根本条件，因为即使我们在某个领域领先一段时间，如果停滞不前，就会被其他人迎头赶上，失去领先地位。这就好比一架飞机，只有在达到一定速度（300 公里以上）时，才能飞翔，否则就会失去升空的能力。这也正是技术人员的命运，同时也是其中的乐趣所在。在这个过程中，我们要关注的不仅仅是技术的新鲜性，还有如何利用技术去提高我们的判断力，例如使用技术工具帮助筛选论文、指导方向等。这种工具本身就有助于提升我们的判断力，因此我认为从技术趋势出发，选择跟随哪些技术，哪些不需要跟随，是一个重要的决策点。
其次，技术最终需要在实际应用场景中得以落实。从目前的技术发展状态来看，整个业务的大流程框架并没有发生大的变化，仍然是从决策到 POC 验证，再到业务验证和优化。然而，在构思 AI 应用时，我们不能再将其视为一个模块，而是更多地将其看作一个基础组件。这是一种“Thinking in large model language”的思维方式。从这个角度出发，用模型的角度来设计新的应用，可能是主要的变化。未来，随着真正的 AI 应用的到来，可能还会有更多的变化。然而，在当前时点上，我认为把握住这两点，我们就能够跟上技术迭代的步伐。
肖然： 这个问题实际上是企业长期以来一直面临的一个难题，尤其是在技术飞速发展的背景下，业务领导常常感到投入产出比例不够理想。在去年大模型的出现和人工智能浪潮的推动下，许多业务领导第一次开始认真思考如何看待技术的进步。从现在的角度来看，我们会发现在去年生成式人工智能技术初现时，人们普遍提出了一个非常务实的问题：有没有实际应用案例？有没有其他公司的成功经验可以借鉴？这种务实的探讨精神在经营层面或领导层面是理所当然的。毕竟投资是真金白银，期望有产出。
在这个时代的背景下，对于这样一个问题的传统看法可能是有问题的。因为我们会发现真正从技术中获得最大回报的企业往往是通过一些大胆或多角度的尝试。这种实验的精神是非常重要的，可以说是对企业 DNA 的一种改造。如果看一些时代上比较领先的公司，比如 SpaceX 发射火箭，你会发现在 SpaceX 的火箭发射中，即便发生了几次爆炸，很少有人认为是失败的。大多数人认为这是成功的，原因是它完成了既定的实验目标。正是由于这种实验精神，造成了 SpaceX 整体成本和效益远高于同类竞争对手。例如，他们采用了不锈钢作为火箭的外壳，这在之前是不可思议的。然而，正是因为实验的精神，如果有可能，为什么不尝试呢？这样大量的尝试、数据整理、收集和分析，造就了我们看到的时代非常具有创新力的企业。
面对科技创新和业务收益的问题，最本质的逻辑是企业需要逐渐习惯多角度的实验，特别是在面对大模型和生成式人工智能技术时。 在有条件的情况下，鼓励不同的业务单元、科技部门都去尝试。当然，我们所要做的是设法降低每次实验的成本，以便快速获取更多可能性。从统计学原理来看，这就是大数定律，也就是说，当你进行多次实验时，你的成功概率显然更高。我认为这个时代可能正经历着这样一个核心逻辑的转变。
肖然： 去年，在各种协会和组织的研讨会上，我与南京大学、北京大学等一些教授讨论了这个问题。我们关注的焦点是，对于即将面临这个时代变革的大学生，未来两三代的学生，他们学到的知识可能与我们没有根本性的区别，但他们的眼界已经触及到了下一个时代。在与南京大学的张贺教授交流时，我问他作为计算机科学和计算机工程的专家，对这个问题的看法是什么？他表示，首先要坦诚，这是一个未来变化巨大的事情，而且我们现在也不知道它会变成什么样。我们会积极参与到产学研的研讨中。他认为最重要的一点是，他从大一开始就告诉学生们，你们是自由的，可以尝试运用新的技术，我们不会因为你们应用了新的技术而惩罚你们。因此，我认为这种开放的心态可能是无论大学什么年级，都需要具备的，因为各行各业实质上都在发生变革。
李梦泽： 谈到平衡技术创新与业务需求的问题，我完全赞同刚才肖总提出的观点。选择和更迭技术的问题一直是技术团队最常面临的挑战。我认为平衡技术创新与业务需求本质上是一个资源配置的问题。我更倾向于以现有团队的资源进行八二的分配。这样我们可以确保核心业务获得其关键的业务价值，同时在创新方面仍然保持活力。 有了大模型的支持，我们或许能够更好地将八分位的资源转化为二分位的资源。通过工具替代以前八分位完成的固有的重复性和流程化工作，实现业务的迭代与技术的创新。
回顾我们的项目，飞书项目最初的雏形是为抖音业务的迭代提供服务。随后，项目逐渐成熟，横向扩展到公司其他业务领域，最终演变成了一个项目管理工具。因此，我认为需要双管齐下，既要保证核心业务的稳健运作，也要保持对技术创新的持续投入。
李梦泽： 我认为大模型，尤其是像我们现有的对话机器人，实际上是一个庞大的知识库。它不仅能极大地提升我们在繁琐工作中的效率，而且本质上能够将所有未知领域的概念和功能呈现在你面前。当然，前提是你要知道如何正确使用它。你可以将其视为一个技术专家，用于咨询和提问。在日常工作中，你实际上可以为自己节省大量时间，用于学习新知识，拓宽视野，比如可以从前端跨足到后端，甚至全栈。
梁家恩： 关于创新和业务的问题，实际上并不是大模型时代特有的，这是所有时代都会面临的悖论。一方面，不创新就等于等死，另一方面，创新可能会引发风险，甚至找死。在这个博弈中，作为一家公司，我们可能必须要预留大约 20% 左右的资源和空间以支持创新，因为没有创新就没有未来。然而，一旦做出这个决定，我们就必须能够接受创新失败的代价。如果我们追求 100% 的成功，那么这就不叫创新了。
在创新的同时，我们要大胆地假设，小心地求证。我们一定会犯错，但犯错并不意味着要付出巨大代价，关键在于我们能否在试错过程中快速反馈，找到错误的路径并纠正它。这是一个需要平衡的问题，而大模型可能加剧了创新与业务守成的矛盾紧迫感。尽管大模型有助于加剧这一矛盾，但作为一个工具，它也有可能帮助我们提升决策质量和试错效率。因此，它既有加剧矛盾的一面，也有提升效率的一面。
对于大学生面对这个时代的问题，参与 AI 可以从三个方面进行：首先是作为技术参与者和推动者，需要高专业水准和创意；其次是在应用层面参与工具的研发；第三是以用户的角度参与。这些层面的参与可能会拉平一些人的差距，但对真正能够推动技术演进的人来说，要求更高，需要更有创意和创造性。这可能导致两极分化，但对应用层面来说可能是更有利的。所以大家不要因为身处不同层次就放弃，要充分利用这个时代的机遇。
梁家恩： 根据我的了解，在医疗领域的实践似乎是比较早期的。如果你对这些方面感兴趣，欢迎与我们联系，因为我们的客户包括协和医院等百强三甲医院，我们的解决方案在这些医院中的渗透率可能已经超过了 30%。
肖然： 这个问题在不同层面上可能有不同的考虑。从企业宏观角度来看，我们可以从两个层面来解决。首先，Thoughtworks 技术雷达提供了企业当前技术栈的评估，指导我们选择已被行业广泛采用且取得成功的技术。这涉及技术的社区支持和已知的技术副作用。其次，我们需要考虑业务部门对技术的理解。在这个层面上，我们不仅需要关注技术细节，还要强调技术趋势对用户交互方式的影响。例如，自然语言处理技术可能导致用户交互方式的根本性变化。
对于团队级别的技术管理者，建议保持开放心态，鼓励团队成员主动尝试新技术。这可以通过分配一定比例的时间，例如 20%、10% 或 5%，来进行技术实验和尝试。这种开放性的管理方式可以激活团队的活力，让团队能够更长远地看待技术的发展，并获得实践经验。团队管理者需要规划并设置机制，使团队成员有机会尝试新技术，促使团队在技术演进方面保持积极性。
李梦泽： 在我们的项目实践中，曾经面临平衡短期业务需求和长期技术战略的挑战，有时候甚至走过很长的弯路。这是因为需要在短期内快速响应业务需求，迅速实现实质性的收益，而这个过程往往与长期技术战略存在天然的抗衡关系。制定初期的规划如果没有很好地将短期和长期进行拆分和融合，就容易出现矛盾和对抗。
从我们研发的经验来看，最近几年与之前的超快猛时代已经完全不同。我们的前端项目规模庞大，如果仍然采用过去的超快猛心态，可能会对整体维护和未来产品迭代留下很多隐患，导致尾大不掉的问题。因此，我们采取的策略是定期审视全年的长期规划，进行修正和对齐，力求不让短期、破坏性的需求危害我们的产品和业务线。我们摒弃了追求短期业务需求的能力，认为坚守难而正确的事情是最为准确的策略。这种做法有助于确保我们的决策符合长期技术战略，同时最大程度地减少短期决策对产品和业务的负面影响。
梁家恩： 首先，很多人强调的是短期存在资源冲突，这也是许多人不愿意去处理的原因。然而，我们认为一致性可能在意识上没有得到足够重视，因为从业务的角度来看，问题的提出和解决方法的探索是当下的目标，而技术则是帮助我们找到解决方法的工具。带着问题去寻找方法，实际上效率更高。其次，在业务实践中，我们可以验证哪些技术是可靠的，哪些是不可靠的，这样可以避免许多人将资源投入到无效的技术创新中。因此，这两者的结合可以消除冲突所带来的负面影响。
在处理这种冲突的角度上，我们不能只看当下，还要相信技术的力量，因为如果我们在这个时代不相信技术的力量，就不会有未来。我们必须意识到，当我们在技术上落后时，存在着巨大的风险。只有具备了这种风险意识，我们才会不断地改进技术能力。我每年都会向我的团队提出类似的问题，询问他们在当前工作中是否采用了与去年不同的方法，以及在技术方面是否取得了实质性的进展。这是我必须要向他们了解的事项。如果他们无法回答，那么可能意味着团队存在一些问题。
梁家恩： 就基础技术创新而言，欧美仍然占据主导地位，占比可能超过八成。他们在原创性技术方面处于领先地位。然而，在应用层面上，我们可能更加大胆，更加前瞻。就基础研究创新能力而言，由于我们长期以来可能一直扮演着跟随者的角色，这在某个阶段可能并不是问题，因为成本相对较低。但当我们在推动应用时，会发现许多前沿性问题。在国外可能找不到解决方案的情况下，我们国内可能会提出许多新的方法。因此，总体而言，在基础性研究方面，我们与国外相比可能存在差距，但在应用方面，我们是处于领先状态的。
梁家恩： 在量化评估产出方面，我认为关键在于审视业务本身。暂且不考虑具体的方法，我们需要了解业务本身要解决什么问题，以及需要投入的成本是多少。我们可以比较不同方法在提升质量、提高效率和降低成本方面的表现。
对于大模型的评估，通常应该有一些公开测试集可以进行比较评测。然而，在国内，由于容易出现榜单被滥用的情况，这些测试集的参考价值可能会减弱。后续一些高校可能会推出更大、更充实的测试集，使其不容易通过简单刷榜的方式来评估模型性能。这将促使研究者不得不更深入地挖掘自己的模型极限，从而推动领域的进步。
肖然： 这个问题在过去两年中有了显著的进展，特别是通过引入 Team Topology（团队拓扑）的理念，这给我们带来了新的认知。在软件产业中，由于持续迭代演进带来的复杂性，我认为团队会更倾向于小规模化，即将几百人甚至上千人的大团队分割成几十个甚至上百个小团队。这种小团队的背后，实际上有一些基于心理学和我们学科内的基础理论支撑的。
作为知识劳动密集型产业，我们面临的挑战主要在于如何有效地进行交流和沟通。有效地将我们的思想传达给别人，特别是在不同专业背景的同事之间共同讨论问题，确实是一个相当困难的任务。因此，为了能够高效地协同工作，从团队结构的角度来看，我们更倾向于对团队规模进行有效的限制。例如亚马逊提出的"2 Pizza Team"团队规模，即一个由两个披萨能吃饱的团队，通常大约有 5 到 7 个人。当然，在复杂系统的团队中，一般来说，将其控制在 15 人以下已经相当不错。然而，小规模的团队也带来了一个问题，就是在组织中可能存在多个团队。例如，在一个拥有几百人的组织中，其研发组织可能会包含几十个团队。客观而言，团队和团队之间的沟通与协调变得不可或缺。
在团队拓扑中，它明确定义了各种小团队的定位。例如，有平台团队，负责内部平台的构建；有业务价值流团队，直接对接业务，完成端到端的业务需求；还有复杂子系统团队，解决特定技术难题，如监控和日志；最后还有赋能团队，专注于类似 DevOps 或 SRE 等领域的专业知识传授。这种团队拓补清晰划分了团队的种类，有利于团队设定相关目标。此外，团队拓扑提出了一个有趣的概念，即“团队和团队之间的 API”，明确了合理的团队间交流沟通方式。例如，如果一个平台团队的目标是实现自服务，长期将团队成员派驻到其他团队可能并不是最佳做法，因为这可能意味着平台本身的技术成熟度存在问题。
首先，我认为这种问题不应该被短时期的频繁交流所掩盖，或者仅仅因为大家认为频繁的交流沟通是一件好事。相反，这个理论框架的提出引发了我们对团队存在的目的的重新思考。即使在一个小的研发组织或者我们所称之为敏捷团队中，团队也应该明确自己的存在理由、阶段性目标和创造的价值。其次，我们应该认真梳理团队和团队之间的沟通交流协议。明确何时应该进行交流，何时不应该进行交流，因为交流沟通永远都是有成本的。这种考虑是从团队合作效能和效率的角度出发的。
当我进入一个团队时，我通常会尝试找到帮助他们建立小团队结构的方法。另外，我会运用团队拓扑的方式，帮助大家树立团队存在的目标和意义，这是一个阶段性的过程，当然也是一个不断演进的过程。关于团队和团队之间的沟通，我们需要确保这种沟通是合理的，以保证整个组织在协同过程中高效运作。
李梦泽： 我想从带领团队、共同攻坚项目的角度讨论团队协作机制。在项目中，我们通常将所有任务拆分成小块，假设团队内所有成员的能力模型是一致的。如何最有效地调度和激发每个团队成员的积极性，以及自动化程度，我认为这是衡量团队是否高效的最重要因素。
我在 2019 年在字节公司的经历中就有一些实践。当时，我领导了七八人的团队，一同攻坚一个项目。我们使用飞书的表格功能进行项目管理。在这个过程中，我们没有很好的标准 SOP（标准操作程序）流程，因此我需要不断摸索，并与团队成员确认事务结果，以及如何让他们自主驱动。由于表格集成的自动化能力也不够强，我在跟进项目和维护管理流程上花费了很多精力。这导致我对整体管理的难度相对较大，团队之间前进的阻力也很大。
后来，我们将这些流程都工具化了，就像之前提到的将固有资源二八开，八做核心业务，二做业务流程自动化工具。在启动新项目时，将这些经验都整合到工具中。有了这个经验后，我就没有了早期的盲目状态。在进行项目管理或团队协作时，我觉得使用好的工具来指导工作是非常有帮助的。此外，在技术能力方面，我强烈推荐大家利用 AI 工具，尤其是代码辅助工具和多轮对话的 AI 辅助导师等能力，这些可以为技术人员提供很多帮助，显著提高效率。这是我在团队协作和技术能力方面的一些建议。
梁家恩： 从技术管理的角度来看，我认为作为技术出身的管理者，我们应该充分发挥逻辑思维的力量。作为技术人员，我们通常对逻辑有较强的理解力。然而，我们在沟通中常常遇到效率低下的问题，实质上是因为底层的目标与逻辑没有对齐。很多无效沟通往往源于大家话术的不一致，这可能导致混乱。表面上是沟通问题和效率低下，但根本上可能是团队成员之间的目标和逻辑认知没有达成一致。我们希望通过目标导向的方法和将逻辑和流程可视化，以便在共识的基础上进行更多的沟通交流。这样一来，我们就能减少误解，提高效率。
对于技术团队而言，另一个较大的问题可能是情绪管理不足。很多理工男性格相对耿直，在这方面可能需要下一些功夫。我们团队在技术与业务协同初期发现，每个人的背景和诉求各不相同，很难理解技术商业化的节奏演进。我们难以理解那些推向市场一侧的困惑和挑战。由于双方目标本质上存在差异，会导致内在的结构性矛盾。如果大家的期望没有得到清晰的沟通，这种跨部门协同就可能充满冲突和问题。良好的情绪管理可以缓解这些问题，否则可能会放大矛盾，成为更大的难题。技术管理关键在于处理这两个方面的挑战。
肖然： 我认为一些传统的书籍并不可忽视，比如很多项目经理会学习 PMI 的 PMP 课程等系列。对于刚刚步入团队管理领域同事，我认为这些基础书籍还是值得阅读和学习的。
在软件工程和偏向研发的团队中，我会推荐三本书。首先是一本经典之作《人月神话》，它向大家揭示了软件工程的实质，以及与传统工程的区别。书中深入分析了一个简单而重要的观点：加人并不一定代表加效率，甚至可能拖慢效率，这本书的分析非常有深度。
我还推荐《团队拓扑》一书。这本书从实践的角度告诉我们如何设定团队目标，并如何有效地进行团队沟通和协调。
最后是我翻译的一本书《人件》（Peopleware）。这本书在硬件（hardware）和软件（software）之外，引入了“人件”这个概念。两位作者用了 25 年写作这本书，发表于十多年前，但我翻译时已经是第四版。书中的很多理念在当时是非常先进的。两位作者通过数十年的从业经验，总结出了很多有趣的核心本质，称之为“定律”（law），虽然这些定律并非经过科学论证，但对于管理者来说，阅读这本书将给你带来很多启发。它提供了关于培养人才、促进团队学习等方面的见解，对真正意义上的高效团队管理有着深刻的理解。
梁家恩： 这个问题涉及领域较为广泛。我认为重要的是回归到业务本身的目标和存在的问题。即使不能清晰描述方法，看看能否明确目标以及你认为当前存在的重大问题和差距在哪里，你能够指出那些痛点所在，这样我们才能更好地评估技术方案是否能够有效解决这些问题。
对我们来说，我们非常期待与那些在业务中真切感受到痛点的团队进行更多的交流。在学习技术的同时，我们希望找到更广泛的应用场景，以便结合和突破。因此，我认为从一个更具创新性的角度来看，我无法笼统回答这个问题。关键在于明确问题和方法，只有当我们将问题和方法都描述清楚时，我们才可能找到解决问题的有效途径。
肖然： 去年我曾经深入思考过这个问题。因为我们公司作为全球采用敏捷开发模式较早的企业之一，也是敏捷宣言的签署者，这些对我们公司的影响力非常大。因此，在大模型出现之前，我们一直在比较传统的瀑布式开发模式与上一代的对比中进行思考。在制造业，瀑布式开发模式广泛存在，其核心利润实际上是流程驱动。例如，许多制造业工厂，包括现今许多企业，都注重学习华为的流程，因为这些流程本身非常关键。对于制造业而言，如果流程没有清晰梳理，所生产的产品就很可能存在问题。我们听到的一些认证标准，例如 ISO 9001 或 9002，实际上是对制造流程的一种认证。这种认证可以验证流程的稳定性，确保其产出是可预测的。
这种流程应用到软件开发就不太奏效了。尝试用流程来控制人的思维，显然是行不通的。尤其是在当前社会趋势下，比如 00 后带来的职场变革，对于管理者想要控制他人的思维，确保员工不会上班“摸鱼”的做法，我持怀疑态度。敏捷宣言在开篇的第一句中明确指出，正确的软件开发方法是注重个体和互动，而不是过度依赖流程和工具。这一点强调了关注个体，并使其能够直接与其他人互动，例如，开发人员之间、开发人员与测试、开发人员与需求分析之间的协同关系。这是 2.0 时代的要求。
但在实践中，我们可能感到有些失望，因为它对人的依赖性太强。经常出现这样一种情况，刚开始企业可能在敏捷转型方面表现得不错，前半年取得了显著进展，企业和员工都较为认可。然而，一年后，情况可能发生逆转，我们离开后企业可能回到了过去的状态，之前认为很好的员工纷纷离职，因为缺乏持续运作敏捷机制。现在大多数企业的研发组织绝对没有达到敏捷宣言所描述的程度，可能也就是 0.5 或 1.5 的程度。
在 2.0 时代，最困难的问题是交流、沟通和知识的同步。而生成式人工智能技术背后产生的大模型，正是最擅长管理和存储知识的。这使得知识的沟通、交流以及跨职能的协作得以快速放大和增长。这也许标志着我们进入了软件工程的 3.0 时代。然而，模型到底能做到什么程度，目前还不得而知。例如，RAG 等技术已经展示了通用型大模型在专业领域知识方面的巨大潜力，但能否真正有效地管理知识，促进我们成为一个既尊重个体又高效组织的 3.0，还有待观察。因此，总的来说，对于技术管理者来说，无论如何我们都面临着与大模型共同工作以及如何使大模型更高效的问题。我们需要思考如何管理知识，或者将其融入我们的工作中。
肖然： 目前，创业公司大多是由两三个人组成的小团队，这个趋势已经相当明显。在 2024 年，我们迎来了一个多模态的时代，包括设计、互动，编码。对于这类小公司来说，如果你有创意，你实际上可以从零开始编写代码，进行测试，甚至将其上线并运营，只要你有兴趣去尝试，就完全可以做到。这对于两三个人的团队来说，并没有太多问题，因为你可以轻松在线上和线下之间切换。
对于复杂产品或规模较大的团队来说，应用这项技术可能会更具挑战性。目前这一领域尚未完全实现工业化，但未来充满期待。作为创业者，你现在可以思考两个关键问题。首先，你所做的事情是否仍然有意义？例如，你可以启用并构建自己的 GPTs。这个智能体根据你提供的脚本和数据输入，形成一个定制的“个性”。如果在 2024 年或 2025 年，这种方法成为行业标准，你是否仍然需要开发一个 APP？这是值得深思的第一步。其次，如果确实有这个需要，你是否考虑使用大模型来解决你自己不具备的技能，比如很多程序员可能缺乏设计技能，而现在完全有可能借助大模型实现。
李梦泽： 这个问题涉及到大模型与团队管理之间的关系，大模型的合理应用，以及与先进工具的协同，将使团队管理在效率方面取得巨大进步。在大模型时代，自动化和自然语义化本质上是两个技术上可能难以融合的概念，但有了大模型，它们有机会实现更紧密的结合，为团队管理带来全新的思考方式。
梁家恩： 对于管理工具，我认为它目前已经显示出非常重要的价值，特别是现在已经出现了 Agent 的雏形。尽管目前还存在一些不完善之处，但我坚信在未来三到五年，可能不超过十年的时间里，它将成为所有业务中不可或缺的伙伴。当这个时代到来后，我认为可以发挥两个方面的作用。
首先，它是一个极好的知识和信息整合工具。通过设计适应业务环境的方式，我们可以将大模型纳入其中，有效地传递不同岗位上的能力和知识模型，形成一种模型流程。这至少可以降低人员变动带来的不确定性，使其更规范和延续性更强。
其次，对于创新困境的解决，大模型可以取代人工扮演多个角色。当有一个新的想法时，我可以更轻松地打通整个闭环，而不是让人工去承担多个任务。这种轻量级的验证过程可以更快地进行，例如，我们可以使用 GPT-4 来验证一个新的工作流概念。这有助于更快地检验新想法，降低试错的成本。这两个方面都是需要关注的，并且随着大模型能力的不断增强，未来可能会有涌现更多潜力。
肖然： 我常常在讲课时强调的两个短语，第一个是“主动求变”。这个短语来源于习总书记在央企数字化转型时提到的三个要点中的一个，他用排比句表达了这三个要点。第一个是要积极识变，即要有意识地认知和辨别变化；第二个是要科学应变，也就是当你发现变化时，要用科学的方法而非蛮干的方式来应对；最后一个要求最高，叫做主动求变。作为技术管理者，我们刚才讨论的话题与这个密切相关。未来技术的发展，包括人工智能在内，将变化迅猛。比如，我们见证了苹果眼镜的正式发布，这可能会引发一波增强现实（AR）和虚拟现实（VR）的浪潮。你的企业业务肯定会受到影响，你可能会有很多想法。因此，最重要的一点是要主动求变，而不仅仅是被动地等待变化发生。
第二个短语是“知行合一”，在中国的心学中经常被提到。原因是其实你没有什么特别好的办法，最好的方法就是扩大自己的感知能力。对于未来的预测，通常来说是不准确的，因为时代变化因素太多。在科技行业，这一点在 2023 年已经表现得淋漓尽致。感知能力的最佳表达其实是由王阳明先生说出的，“知行合一”。怎样去感知？就是通过行动，而如何指导行动呢？就是基于你自己的感知。在感知和行动之间，逐渐地走向正确的方向。
李梦泽： 技术管理需要先有扎实的技术基础，因此在相关领域，你必须对基础知识和原理有清晰的理解。这样，你才能够以身作则，成为团队中的领军人物和引领者。其次，作为技术管理者，必须保持对技术的敏感性和准确的技术判断力，以便能够带领团队走出一条正确的道路，即使这可能是一条漫长而艰难的道路。此外，在与团队成员互动时，展现真诚和真心的态度是至关重要的。通过亲身体验团队内部问题并协助解决，能更好地理解问题的本质。最后，除了拥有过硬的个人素质和一个强大的团队，你还需要适当的工具来支持技术管理工作，确保工作能够取得良好效果。
梁家恩： 我认为有三点要注意。首先是关注大势，意味着在面对巨大变革时，我们不能惯性地前进，而是要了解变革的方向，因为成功通常与时代密切相关。其次是持续学习。在这个时代，学习变得更为重要，但我们的学习方式可能与以前有所不同。从以前应试性的学习转变为更注重问题导向的学习，这样效率可能会更高，目标明确，解决问题有针对性。最后一点是躬身入局。许多人可能在表面上谈论许多，但并没有真正进入问题场景并亲身体会。作为技术管理者，需要深入了解团队在业务中解决的核心问题和技术方案，而不仅仅是成为一个行政管理者。对这三点的把控是成为合格技术管理者的关键。
肖然： 这个问题涉及编码和程序设计两个方面。首先，若讨论编码，即写代码，当需求清晰且任务规划得当时，编写代码本身并不是主要难题。现在的大模型，如 Copilot，可以编写不同领域的代码。然而，一旦提到程序设计，情况就有所不同。
在国内，我积极推动领域驱动架构设计（DDD）等方法，尤其关注领域认知和业务领域划分。虽然模型可以提供建议，但不能完全取代架构师的角色。在多次与资深架构师的讨论中，我们共同得出结论：编码部分的能力可能会逐渐被模型替代，但设计部分的能力将被模型放大而无法替代。设计的重要性彰显在它从业务需求到可用软件的翻译过程中，而模型目前尚不能完成这一翻译工作。因此，程序设计中，尤其是在后半程编码阶段，需要学习如何使用提示语工程等方法。尽管代码的准确性在各方面已不再是主要问题，但设计阶段仍然需要不断历练和磨练。如果你站在技术一线，这将是未来三五年核心的竞争力所在。
肖然： 关于 Token 的使用，首先，对于小公司而言，通常采用公有模型通过 API 进行计算。计算可以采用两种方式，一是基于 Token 的计算，即你使用了多少个 Token；另一是基于流量的计算。目前大多数人认为 Token 是一个相对合理的计费方式。如果你希望减少 Token 的使用量，你可以考虑使用一些方法，比如采用像 Agent 和 RAG 这样的方式，前置准备让使用 Token 时更加高效。
在发送 Prompt 时，你可以思考如何使上下文更加有效，以优化 Token 的使用效果。此外，现在各家的模型都相对便宜，提供免费使用的服务。在未来的半年内，竞争将继续激烈，各公司都在亏损的状态下开展业务。对于小公司来说，找到一个突破点，专注优化应用的质量才是更有意义的，因为当前各家公司都在激烈的竞争。如果能够打造出优秀的应用，将会产生更大的意义。
梁家恩： 这个观众的问题我没太理解，他是希望利用大模型帮助他人解决问题，还是希望使用他人的大模型来解决自己的问题。如果是要用大模型帮助他人解决问题，我认为从开源方面入手可能是最经济有效的选择。已经有基础的模型，你可以在其基础上进行 fine-tuning，并结合具体业务需求，这应该是性价比最高的方法。
如果是使用他人的大模型来解决自身问题，目前可能国内外都有一些开放的 API 可供使用，可以先尝试使用这些服务，验证一下是否对业务有真正的价值。如果确实有必要进行更深度的定制和优化，那么可以考虑寻找专业公司的帮助，或者建立自己的团队。最重要的是确认应用是否通用，业务是否可行。如果业务可行，后续的选择很多。
梁家恩： 我们在内部分配资源时，大约有 20% 的精力会专注于前瞻性核心算法。虽然这部分可能并不直接涉及当前应用，但我们坚持在技术主线和未来技术趋势中投入资源。即使目前可能无法立即应用，但如果我们判断这是未来业务的趋势，就会提前进行一些布局和准备。因为我们内部的员工在业务方面可能更为专注，所以除了内部资源投入外，我们还与外部合作建立了一些联合实验室，与高校进行合作，这种合作更适合进行中长期的技术储备。
在 2023 年结束之际，InfoQ 编辑部重磅推出“年度技术盘点与展望”专题，聚焦 AIGC 引发的变革，与 50 多位头部专家深度对话，希望能为你揭示架构、前端、运维、大数据、云计算、编程语言、数据库等领域的核心变化和演进逻辑，明晰金融、汽车、制造、零售等行业的数字化、大模型应用思路和路径。
最新评论
推荐文章
作者最新文章
你可能感兴趣的文章
Copyright Disclaimer: The copyright of contents (including texts, images, videos and audios) posted above belong to the User who shared or the third-party website which the User shared from. If you found your copyright have been infringed, please send a DMCA takedown notice to [email protected]. For more detail of the source, please click on the button "Read Original Post" below. For other communications, please send to [email protected].
版权声明：以上内容为用户推荐收藏至CareerEngine平台，其内容（含文字、图片、视频、音频等）及知识版权均属用户或用户转发自的第三方网站，如涉嫌侵权，请通知[email protected]进行信息删除。如需查看信息来源，请点击“查看原文”。如需洽谈其它事宜，请联系[email protected]。
版权声明：以上内容为用户推荐收藏至CareerEngine平台，其内容（含文字、图片、视频、音频等）及知识版权均属用户或用户转发自的第三方网站，如涉嫌侵权，请通知[email protected]进行信息删除。如需查看信息来源，请点击“查看原文”。如需洽谈其它事宜，请联系[email protected]。