AI 与大模型如何助力金融研发效能最大化？

泡椒竹笋面

已于 2024-09-05 21:17:32 修改

阅读量1.1k

点赞数 20

文章标签：人工智能金融深度学习 pytorch chatgpt 华为

于 2024-08-22 14:54:27 首次发布

本文链接：https://blog.csdn.net/kaka0722ww/article/details/141428320

版权

在金融行业，技术创新与严格合规的需求并行存在，推动着研发团队不断寻求更高效的解决方案。面对日益增长的市场竞争和技术进步，金融机构必须迅速适应变化，同时确保所有创新措施都符合监管要求。这种需求催生了对高效研发流程和先进技术应用的追求。

在日前的 InfoQ《超级连麦. 数智大脑》x FCon 直播中，我们邀请到 微众银行研发效能负责人余伟， 以及 数势科技数据智能产品总经理岑润哲，深入探讨了在金融研发中提升效能的有效策略，如何选择合适的技术栈和架构设计，以及如何利用 AI、大模型和低代码等技术优化研发流程、加速产品交付。

8 月 16-17 日，FCon 全球金融科技大会上将于上海举办，届时，2 位老师将在「金融研发效能提升路径与实践」专题论坛中与大家进行深入的交流和分享。此外，大会还将聚焦智能 IT 架构、现代化核心系统建设、前沿金融科技探索等话题，邀请来自银行、证券、保险的专家分享最佳实践。更多演讲议题已上线，点击链接可查看目前的专题安排：https://fcon.infoq.cn/2024/shanghai/

以下内容根据对话整理，篇幅有删减：

1 金融研发效能提升：关键因素与平衡策略

余伟：金融行业在提升研发效能方面哪些因素最为关键，以及如何平衡这些因素？

岑润哲： 在金融机构的项目研发过程中，我认为有三个关键因素对提升研发效率有着显著影响。首先，也是最重要的，是 人才素质。一个团队如果拥有既懂金融知识又精通技术和产品的复合型人才，那么无论是项目推广还是产品研发都将更加迅速和敏捷。这样的人才能够作为产品团队和研发团队之间的桥梁，将复杂的业务逻辑转化为技术语言，从而极大提升研发迭代和测试的效率。

其次，技术架构的选择至关重要。金融机构需要处理大量数据并应对高并发情况，因此，一个先进的技术架构能够确保系统在面对未来数据量增长时仍能稳定运行。在项目初期，预判未来几年内数据量的增长，并以此为基础设计架构，可以避免未来需要进行系统重构的情况，从而节省时间和资源。

第三，流程管控和项目管理同样关键。一个有效的项目管理机制，如敏捷开发的 Scrum 框架，以及一个负责任的项目经理，能够确保产品的设计和开发过程更加高效。项目经理可以引入短期迭代和持续反馈机制，提高资源利用效率，加强产品与技术人员的协作。

余伟： 在微众银行，有一个岗位，称为科技产品经理，他们既懂技术又懂产品。这个角色在金融科技领域尤为重要，因为他们需要与业务团队紧密合作，理解业务需求并将其转化为技术解决方案。业务团队可能清楚自己需要什么，但不一定知道如何通过技术手段来实现这些需求。科技产品经理不仅要了解业务团队的需求，还要与技术团队沟通，确定如何利用现有架构或进行架构调整来实现这些功能。

敏捷和持续迭代的理念并非所有人都能一致理解。过去金融机构可能需要数月才能推出一个版本，但现在通过敏捷开发，迭代周期缩短至两周甚至每周。这种转变需要团队成员对敏捷开发有清晰的认识，并接受持续学习的文化。此外，明确的责任划分和系统架构设计对团队的敏捷落地至关重要。

流程工具的自动化和基础建设，如持续集成 / 持续部署（CI/CD）、容器技术、测试环境和泳道，尤其是金融机构复杂的测试环境，以及与 AI 结合的自动化输出，对提升组织效率极为重要。

IT 能力的共享也是金融机构提高效率的关键。例如，一个风险模型可能在一个产品中得到应用，也可以作为公共服务被其他产品共享。这种能力共享对于避免资源浪费和提升研发效能至关重要。

金融机构与其他机构最大的区别在于风险管控和合规性。风险管控和合规性要求对研发效能有反向作用，高风险管控意味着需要做更多的工作来解决或降低风险，可能会影响研发效率。因此，在设计架构和产品时，需要提前考虑风险管理和监管要求，避免后期返工带来的损失。

敏捷文化、流程工具自动化、IT 能力共享以及风险管控和合规性，这四点对金融机构的研发项目集成有着显著影响，需要在实践中不断平衡和优化。

岑润哲： 在金融机构中，IT 能力的共享至关重要，特别是在数据分析领域。以我们数势科技的指标平台 SwiftMetrics 为例，这些产品的核心目标是帮助金融机构以更低的门槛进行数据分析。数据分析本身是可以在不同业务线之间共享的，例如风控模型在信用卡场景中有效，在保险代销或财务管理中可能就不再适用。我们希望我们的产品能够在金融机构的各个业务线中低成本复用，从而减少冗余开发和烟囱式架构的成本。

监管在金融机构中扮演着特殊的角色。在监管严格的环境下，金融机构可能不会尝试使用 AI 或大模型进行深入探索。例如，在风控领域，模型的可解释性至关重要，因为需要向借款人解释为何被拒贷或额度设置的原因，这就是为什么许多银行和金融机构仍然使用决策树，尽管它们可能不是最优模型，但具备可解释性。

在金融机构，尤其是监管严格的业务领域，先进技术的使用需要谨慎，因为风险合规的存在。如何在大模型的创造性和监管的规则性之间找到平衡，是未来需要重点关注的挑战。

2 利用 AI、大模型与低代码，优化研发流程与加速产品交付

余伟： 在银行业务中，用户与资金和征信相关的事务至关重要，准确性是关键，任何微小的差错都不允许。在这样的背景下，我们接下来要讨论的是 AI 与低代码技术在金融研发中的应用，这些技术是如何具体应用在金融研发中的，以及它们是如何帮助提升研发效能的？

岑润哲： AI 技术在金融领域的应用已经相当广泛，从智能客服、人脸识别、OCR 到风控等。随着大模型技术的发展，金融机构正在探索更深层次的应用场景。

数据分析：金融机构拥有庞大的数据资产，数据分析成为关键应用之一。传统上，业务方提出报表需求，数据团队进行开发，这不仅效率低下，而且成本高昂。数势科技公司擅长数据分析，通过结合大模型和指标语义层，使业务人员能够用自然语言进行数据分析，从而提高效率并减少数据团队的冗余开发工作。
智能客服：在大模型技术的支持下，智能客服可以提供更高效的服务。金融机构拥有大量政策和产品文档，通过大模型的自然语言处理能力，可以提升客服的响应速度和质量，甚至构建完全自动化的智能客服系统。
知识库管理：金融机构作为知识密集型行业，需要有效管理和调用历史知识文档。大模型可以帮助将非结构化文档转化为向量数据库中的信息，供业务方和客户经理使用。但这也带来了挑战，如文档版本管理和观点差异，可能导致大模型输出的不稳定性。
代码辅助：在研发领域，大模型可以辅助编写代码，提供基础代码框架供开发人员修改和完善。此外，大模型还能将代码转换为流程图或泳道图，帮助产品经理理解代码逻辑，从而提高产品和研发团队之间的沟通效率。

余伟： 在微众银行，我们对数据分析的实践采取了一种新的方法，利用大模型技术来提高效率和精确度。例如，业务团队在策划营销活动时，可能需要了解在深圳存款超过 1000 元的人数。过去，这需要向科技团队提出需求，由他们编写 SQL 查询并开发相应的页面功能，这个过程耗时长且需要排期。

现在，我们通过大模型技术，业务团队能够直接与模型交互。他们可以向模型描述所需的条件和营销活动的目的，模型会生成类似 SQL 的查询结果。这些结果首先在准生产环境中进行基准分析，确保它们符合业务团队的预期和产品理解。如果结果符合预期，再将其转化为正式的需求，交由科技部门开发。

这种方法解决了几个问题：首先，它减少了业务团队因需求不明确而导致的资源浪费；其次，它允许业务团队在小范围内低成本尝试，验证产品特性的可行性；最后，它确保了业务团队的需求与科技团队实现的功能之间有良好的匹配。

岑润哲： 大模型在生成代码方面的能力确实为快速原型开发提供了显著优势。以往，业务方提出需求后，设计师需要花费一两天时间来设计图纸，而现在，通过大模型，我们可以迅速提炼出多个版本的设计方案。业务方可以直接从这些版本中挑选，这大大提升了产品开发和研究的效率。

无论是将文本转换为图像还是代码，大模型都具备这样的能力。尽管这些能力可能尚未达到完美，但在原型制作过程中，AI 技术的加速作用非常明显。这不仅加快了业务方的选择过程，还为 AB 测试等提供了便利，从而在整体上提高了业务效率。

余伟： 金融机构正在探索 AI 技术在多个方向的应用，包括利用 AI 分析研究报告 来辅助投资顾问作出决策。研究报告来源广泛，有些容易获取，有些则相对分散。以往依赖有经验的分析师手动阅读和分析，但这种方法存在局限，尤其是对于缺乏经验的分析师，他们可能无法准确把握报告的重点。通过将这些报告交给 AI 大模型进行分析，可以生成标准化的输出，确保分析的全面性和准确性。

智能投资顾问 也是 AI 技术应用的一个重要领域。通过算法，智能投资顾问能够提供个性化的投资建议和投资组合，满足不同客户的长期或短期需求。微众银行的 App 已经集成了这样的智能投资顾问服务，为客户提供定制化的产品推荐。

除了 AI 技术，低代码开发平台 也在金融机构中找到了其应用场景。低代码平台允许用户通过少量编码或零编码来快速构建功能，特别适用于产品管理台的开发。金融机构的每个产品都需要后台管理台，业务人员可以在管理台上执行查询、审批等操作。通过低代码平台，可以快速生成这些标准化功能，并与应用系统集成，实现快速开发。在移动端应用开发方面，低代码工具同样发挥着重要作用。利用 iOS 和 Android 平台提供的组件，低代码工具可以快速开发出功能原型，特别是在产品初期的体验版或演示版开发中。这种方式允许业务团队在没有具体数据支持的情况下，快速验证移动端功能的表现是否符合预期。

岑润哲： 在与多家金融机构的接触中，我发现他们已经采购了不少低代码工具，用于风控策略、营销策略等业务场景。低代码工具通常基于工作流（workflow）进行编辑，允许用户通过拖拽组件的方式快速构建应用，如 H5 活动页面。这些工具虽然功能强大，对业务方来说学习门槛仍然存在。一些金融机构的业务人员在使用这些工具时可能会感到复杂，这影响了工具的普及和应用效率。余老师如何看待这个问题？

余伟： 低代码平台在金融机构中的应用主要面向两类用户：一是非技术背景的业务人员，二是具备一定代码能力的科技同事。

对于业务人员而言，他们通常对代码不太了解，只有产品概念，因此学习使用低代码平台确实存在门槛。为了降低这个门槛，我们需要在易用性和可用性上做出更多努力，使得用户能够像使用普通互联网产品一样，通过简单的拖拉拽操作快速实现所需功能，而无需经过复杂的培训过程。

金融机构中使用低代码平台的主要是科技同事，他们利用这个工具来提升研发效率。低代码平台使得需求提出者能够快速看到接近最终形态的产品，从而更准确地确认是否符合预期。这种模式的价值在于金融机构人员结构的特殊性：业务人员面对客户，收集需求并翻译成需求文档，然后交给科技人员实现。业务人员通常只在需求提出阶段和产品即将面向客户的阶段参与，因此 低代码平台在中间起到了桥梁作用，帮助快速实现并验证需求。

通过 低代码平台完全组装一个新产品，尤其是涉及前端页面和后端服务的复杂串联，目前还有一定难度。金融机构的产品通常包括前端展示和后端逻辑两部分，如果这些组件能够标准化，前端的页面组装和后端的微服务组装相对容易实现。但中间的逻辑串联过程往往需要人工参与，因此完全自动化的流程编排和快速上线尚未达到成熟阶段。

岑润哲： 去年，我们尝试将低代码工具和 API 交给大模型，希望它能进行编排调度。但很快我们发现，这一过程存在困难。Workflow 的编辑具有强烈的业务逻辑性，如果大模型不了解金融机构的业务逻辑，它就无法将这些 API 有效串联起来。

目前大模型在自动化生成后端代码，尤其是涉及复杂业务逻辑的代码方面，仍然面临挑战。这需要一个既懂业务又懂技术的中间人来介入，无论是通过低代码平台还是传统编码方式，都需要这样的人来组装业务逻辑，以形成一个完整的产品并交付。

余伟： 接下来我们讨论下 如何优化从需求收集到产品交付的整个研发流程，以缩短交付周期并提高质量。

在传统的研发流程中，工作通常分为几个主要阶段：首先是需求收集，将需求转化为业务和技术人员都能理解的需求文档；接着是将业务需求转化为系统需求；然后是详细设计、编码、单元测试；最后是移交到系统集成测试（SIT）、用户验收测试（UAT）、回归测试，直至上线发布。

为了缩短这一流程，敏捷开发方法被广泛采用。通过将原本可能一个月的迭代周期缩短至两周，一些需求能够更快地上线。例如，某些需求可能仅需 3 天开发加 1 天测试，4 天后即可发布。而更复杂需求可能需要两周开发和一周测试，总共三周才能上线。通过这种方式，大的需求和小的需求可以搭配进行，使得整体的交付时间缩短。

在需求量保持不变的情况下，通过缩短交付周期，可以提高整体的研发效率。金融机构普遍采取这种策略，将交付周期进行合理划分，快速上线小需求，而大需求则按照正常流程处理。这对研发管理人员提出了更高的要求，他们需要能够识别哪些需求可以快速交付，并能够将人力资源有效分配到这些快速迭代的开发任务中。随着研发任务的细分，研发人员的管理也变得更加复杂。可能需要将团队分成多个小分队，每个小分队针对不同的需求进行快速响应和服务。

岑润哲： 在我们的公司内部，从需求收集、研发设计到单元测试、UAT 和回归测试的整个流程中，我认为 AI 可以在测试环节发挥重要作用。特别是在我们公司开发的 SwiftAgent 产品中，该产品允许用户通过自然语言进行数据分析。在这种情况下，测试的成功率至关重要，因为这是一个基于自然语言交互的产品，与图形用户界面（GUI）不同，它具有不确定性。

设计全面的测试用例集对于评估 AI 产品的使用效率和成功率非常关键。例如，在智能客服场景中，不同类型的问题回答率是否达到预期阈值，这就需要精心设计测试问题。AI 产品测试中，如何设计问题和持续优化不良案例是一个重要环节。

大模型可以通过提供测试问题来提高测试效率。测试人员可以基于示例问题，让大模型生成多种问法，从而测试 AI 产品的响应能力。例如，提供一个问题示例，大模型可以生成 10 种不同的问法，甚至 100 个问题，这样测试人员就不需要自己构思问题，从而显著提高了测试 AI 产品的效率。此外，大模型还能够通过举一反三的方式，帮助我们从不同角度评估 AI 产品的性能。这种基于大模型的测试方法不仅可以提升测试效率，还能够提高产品的成功率和召回率。

余伟： AI 产品的核心期望是输入特定信息后，通过大模型的处理得到正确且符合预期的输出结果。那么我们如 何判断 AI 输出的有效性和合理性？

岑润哲： 我们的分析产品实质上采用了 Text to API 的逻辑。用户用自然语言表述请求，例如“请帮我分析一下近三个月的账单金额”，我们的系统不会直接将其转换成 SQL 查询语句，因为 SQL 逻辑相对复杂且可能不准确。我们的产品逻辑分为两个阶段。首先是 语义理解阶段，系统需要识别用户输入的自然语言中的关键要素，如时间范围（1-3 个月）和指标（账单分析金额）。这可以通过脚本检查来验证大模型是否正确理解并翻译了用户的意图。

第二阶段是 数据调用阶段，系统将识别出的关键要素转换成 API 调用所需的半结构化数据，如 JSON 格式。我们需要验证大模型生成的 JSON 或半结构化数据结构是否正确，因为这一步骤可能会有不稳定性。即便是先进的模型如 GPT-4，也可能在生成 JSON 时出现随机性或不稳定性。为了提高准确性，我们通过对齐方式来确保生成的数据结构尽可能符合 API 调用所需的 JSON 入参格式。这有助于后续的数据调用过程更加顺畅。

最近，GPT-4o 发布了一项新功能，即代码对齐能力，这意味着生成的 JSON 将严格符合语法规范。这一功能如果能够实现，将极大降低代码生成层面的幻觉问题。如果 GPT-4o 的这一新功能能够确保生成符合 API 入参的 JSON 结构，那么在准确性上就能达到 100%，从而提高产品在多种场景下的应用可行性。

在产品实现逻辑上，一个关键点是确保大模型不仅能理解用户的话，而且能 将其理解过程反馈给用户。例如，如果用户询问产品的产品经理是谁或产品的起购日期，如果大模型只给出直接答案，用户可能会怀疑其可信度。因此，展示大模型的思考过程，包括它是如何得到这个结果的，即所谓的"白盒化"，对于赢得用户信任至关重要。

在数据分析方面，一旦指标定义清楚，只要数据准确，通常不会有问题。但文档查询就更具挑战性，因为可能存在多个版本的文档，观点可能相互冲突。如果用户提出问题，而两个文档的观点相反，大模型可能无法做出判断。在这种情况下，将所有相关文档召回供用户选择可能是一种更好的方法。

这种“思维链”（Chain of Thought, COT）的透明化，使用户能够理解大模型是如何得出结论的，从而增加了对结果的信任。这与互联网企业中的推荐系统类似，用户不仅希望获得良好的推荐体验，还希望了解推荐背后的逻辑，尤其是在金融产品推荐中，这一点更为重要，因为金融产品涉及合规性和风险管理问题。例如，如果一个稳健型客户被推荐了一个高风险产品，这显然是不合规的。

大模型如果能够作为用户自然语言和技术语言之间的桥梁，将提升 AI 产品的可信度，使用户更愿意使用。确保 AI 具备足够的可解释性，是 AI 产品推广和普及的重要一步。这是 AI 产品能否被广泛接受和使用的关键因素。

余伟： 在微众银行，我们探索了多种方法来缩短从需求收集到产品交付的整个流程。我们从统一的研发节奏转变为根据需求和产品类型采用不同的研发节奏，以实现更高效的交互。

组织结构上，我们也在 尝试引入解决方案层，特别针对 ToB 产品在与金融机构对接时可能遇到的非标准化、研发周期长的问题。如果没有解决方案层，产品直接与金融产品对接，就需要同时满足业务系统和金融机构产品的排期，这可能导致产品研发周期非常长。

解决方案层的引入，可以将对接工作分成两部分：一部分是与业务方的对接，另一部分是与银行科技团队的对接。这样的方法可以最小化双方的改动，而解决方案层则承担适配的工作。这种适配相比直接在成熟产品上进行调整要快速得多，从而大大缩短了 ToB 产品的交付流程。

当前，许多金融机构不仅做 ToC 业务，也开始大量涉足 ToB 业务，面临提高 ToB 产品交付效率的挑战。我们内部进行了许多讨论，集思广益寻求解决方案。

岑润哲： 数势科技为金融机构提供多种软件和产品服务。面对金融机构多样化的需求，我们意识到不能仅仅依赖标准产品。为了更敏捷地交付并满足定制化需求，我们通过组件化和配置化来提高服务的灵活性。这个关键在于构建一个能力中台，它允许我们通过组装和拼接组件来形成满足不同需求的产品。这样，即使面对不同机构的不同需求，我们也无需对 PaaS 层进行大量修改。通过 PaaS 层构建的服务可以被复用，为不同的金融机构提供定制化的解决方案。

避免“烟囱式”开发，避免每次开发都从头开始，导致代码重复且难以共享，对我们来说是至关重要的。中台能够高效地重用已有的软件组件和服务平台，从而减少重复工作，加快交付速度，并提升产品的质量和一致性。

余伟：研发团队的文化建设对于整个团队的运作至关重要。不同的角色在团队中承担着不同的职责。例如，在编写需求文档的过程中，有些团队可能由业务人员负责，而有些则由产品经理来完成。开发和测试人员在面对不完整的需求时，常常会抱怨需求描述过于简单或频繁变更，这增加了工作的复杂性。这种抱怨并不有助于研发流程的正向发展。每个团队成员虽然有明确的岗位职责，但在需求不完善的情况下，团队成员应更积极地参与到需求的快速转化中。

例如，在开发支付产品时，一些基本功能如代收、代付签约是支付渠道必须具备的，这些功能的变化范围有限，团队可以基于这些共通点提前开始开发工作。团队成员在面临依赖问题时，应主动沟通和规划。如果上游工作未能及时提供所需支持，团队成员应提前与依赖方沟通，明确自己的需求和计划，以便双方可以共同协商解决方案。

我们鼓励团队成员主动推动产品的落地和面向客户的进程。这种主动性体现在将产品视作自己的责任，展现出主人翁精神，不仅关注自己的任务，还考虑到如何帮助依赖方，甚至在提供支持之前，就给出建议和指导。

通过这些实践，我们的团队文化已经从严格的角色划分和等待依赖转变为更加主动和负责任的态度。团队成员开始将产品视为自己的一部分，积极推动产品的发展，并以更加开放和协作的方式与其他团队成员一起工作。这种文化的建设对于提高研发效率和产品质量具有重要作用，我对此深有感触，并且认为这对于团队的长期发展是非常有益的。

3 打破部门壁垒，传统银行模式如何转向敏捷协同

岑润哲： 余老师的分享非常中肯，尤其是在互联网银行领域，敏捷文化是其核心特质之一。然而，在与传统金融机构合作进行产品交付时，我们常会发现这些机构可能存在部门间的隔阂，即所谓的“部门墙”。这在一定程度上影响了敏捷迭代和协同工作的效率。对于 ToB 业务，尤其是面对那些可能没有充分采纳互联网思维的传统金融机构时，提升研发效率的关键在于如何打破这些障碍，实现敏捷协同，余老师在这方面有哪些经验可以分享吗？

余伟： 在我们团队中，我们经历了从传统银行模式向敏捷文化的转变。这种转变体现在团队成员开始主动与依赖方沟通，提前明确需求和交付时间，以及他们能为对方提供的支持。这种变化不仅提升了团队的交互效率，也使团队成员更加积极地参与到产品的整个生命周期中。我们通过以下几个方面来推动这种文化转变：

行业最佳实践分享：我们寻找行业内的优秀案例，与团队成员分享，让他们了解其他团队的成功经验，从而激发团队改进的动力。
产品驱动：在新产品的研发初期，我们就提出高效率的要求，鼓励团队想象在没有历史包袱的情况下，如何实现更快速的交互和更高效的工作。
文化驱动：通过在新产品和服务中尝试敏捷实践，影响那些固守传统研发模式的团队，促使他们认识到改变的必要性。
角色融合：在一些团队中，我们尝试减少角色划分，让开发和测试人员承担更多职责，如需求拆解、架构设计、项目管理、培训等，从而提高团队的灵活性和效率。我们鼓励团队成员拓宽自己的职责范围，不再局限于单一角色，而是有机会尝试和体验不同的工作内容，这样不仅提升了个人能力，也为团队带来了新的视角和解决方案。我们在小范围内试验这些新的做法，目前已经取得了超出预期的效果。

岑润哲：在我们开发数据分析类的 AI 产品过程中，有时会发现技术团队，特别是算法团队，提出的产品想法可能比产品经理的更出色。这是因为算法人员对算法的潜力和局限有深刻的理解。即便他们提出的 10 个想法中有 9 个不可行，基于对算法底层逻辑的了解，他们仍有可能提出一个非常符合用户需求的产品设计理念。

在当前快速迭代的环境中，无论是产品经理、测试人员还是研发人员，如果能够横向扩展自己的能力，成为所谓的“T 型人才”或“π型人才”，即拥有深度专业技能的同时也具备广度的跨领域知识，确实能够提高团队的研发效率，并推动团队文化的发展。这样，测试人员能够更好地理解研发的工作内容，研发人员也能更准确地判断产品需求的合理性。每个成员不仅在自己的专业领域内精益求精，也能够对其他领域有所涉猎和理解，这种多元化的技能组合对于产品创新和问题解决都具有积极的影响。

余伟：在微众银行，我们的研发团队与业务团队建立了定期沟通的机制，比如每周或每两周举行一次会议。这些会议的特点是跨部门参与，不仅业务团队的成员会参加，科技团队的成员也会参与进来。

最初，这类会议主要由科技产品经理参与，目的是为了理解业务需求和业务目标。但随着时间推移，我们扩展了参与角色的多样性，包括一些核心开发人员也会参与会议。通过这种方式，开发人员能更直接地了解用户和业务的反馈，真实地看到自己开发的产品在业务落地时的效果，并思考在产品开发过程中如何做出改进以支持业务的更好发展。

这种长期坚持的做法我们已经实施了两三年，每周都会举行这样的会议。团队成员聚在一起，听取业务团队对产品未来发展的规划和期望。这样的机制不仅促进了科技与业务之间的沟通和理解，而且也帮助项目更加顺利地进行。

岑润哲：AI 产品具有一个独特的优势，即能够更直接地理解用户需求。 用户通过自然语言提出的请求直接反映了他们实际的需求，这些请求作为日志记录在后台，为研发团队提供了宝贵的原始数据。通过对这些文本进行分析，研发团队可以清晰地了解用户的疑问和需求，这大大缩短了终端用户与研发团队之间的距离。这种直接从用户输入中获取需求的方式，与传统的 GUI 产品形成鲜明对比。在 GUI 产品中，用户可能需要通过点击多个按钮来完成操作，而他们的真实需求却不一定能够被准确捕捉。这通常需要额外的市场调研。AI 产品通过自然语言处理，能够直接从用户的提问中提取需求，无需额外的调研步骤。

此外，如果能够将成千上万条用户的自然语言需求进行抽象和分析，就可以为产品的优化方向提供指导。这种基于用户实际提问的迭代思路，可以更准确地反映用户需求，从而提高技术团队与产品团队之间的协作效率。例如，当前流行的 ChatGPT 以及基于自然语言处理的其他应用场景，都展示了用户输入即需求的直接性。这种直接性不仅提高了产品开发的针对性和效率，也使得产品迭代更加贴近用户的实际使用情况和需求。

4 减轻金融研发中的技术债务负担

余伟： 接下来我们继续聊下一个话题：技术债务的管理与研发效能，探讨 技术债务对研发效能的影响，以及如何有效管理和减少技术债务。

岑润哲： 在我之前所在的互联网大厂，我们确实面临技术债务引发的问题，例如代码可读性差、维护成本高，以及新功能开发受阻。业务方可能会紧急提出需求，要求加入限制条件，而研发团队为了满足这些紧急需求，有时会采用临时技术方案，导致技术债务的积累。这种债务会使得后续的升级和扩展变得非常困难，并需要花费大量时间和资源进行重构。

为了应对这些问题，我们采取了以下措施。

定期技术评审：通过技术评审来检查新上线的功能，判断是否存在临时性功能，以及这些功能是否会对未来技术架构产生影响。执行代码审查流程，确保代码质量和避免技术债务的产生。
预留资源：在产品或活动策划中预留一定比例的资源，专门用于偿还技术债务。项目经理需要在项目排期中预留人 / 天资源，用于偿还技术债务。
定期复盘：定期回顾项目，分析为何会产生技术债务，以及如何避免临时性开发。进行数据分析，了解技术债务的具体情况，明确净债务量，以便采取措施降低比例。
技术债务追踪：建立技术债务台账，定期追踪和分析标准产品迭代需求、定制化开发和临时开发的比例。
需求分级：对需求进行分级管理，区分标准产品迭代和临时填坑需求，确保它们的比例合理。使用需求管理工具进行复盘分析，量化评估技术债务的影响。

余伟： 技术债务是研发过程中需要重点关注的问题，它涉及产生的原因、量化的方法以及解决的优先级。在管理技术债务时，我们一方面使用管理手段来督促团队成员主动解决技术债务问题，这是一种被动的督促方式。另一方面，我们通过激励措施来鼓励团队成员解决技术问题，尤其是那些对复杂系统有深入影响的技术栈问题。对于成功解决这些问题的个人或团队，我们会量化他们创造的价值，并通过奖项或奖励来给予表扬和鼓励。

在金融行业，技术债务可能涉及数据处理、交易处理和安全性问题，尤其是用户数据和合规性安全，这些都是至关重要的。未能及时处理的技术债务可能会导致金融风险，甚至引发危机。例如，生产环境中的慢 SQL 处理、未及时关闭的临时开关、异常用户数据未得到妥善处理等，这些都可能带来法律风险。金融行业的研发团队必须持续面对解决技术债务的问题。我们甚至有时会暂停产品功能上的新交付，专注于清理技术债务，以确保产品的安全性、合规性和稳定性。

5 如何度量与优化金融研发周期与代码质量

余伟： 接下来我们讨论下 如何度量研发效能，并基于度量结果进行持续改进。

岑润哲： 在评估研发效能时，我们通常从两个主要方面来考虑：

项目交付周期：这是指从项目开始到最终上线的整个时间跨度，是一个非常重要的指标。
代码质量：通过代码审查和评分系统来衡量，包括是否遵循了编码规范、是否存在性能问题、以及代码的整体质量。现在，大模型也可以帮助理解代码并识别潜在问题，将代码质量以量化得分形式展现，为优化提供依据。我们也会衡量产品上线后出现的 bug 数量和严重程度，包括前端和后端的问题。通过统计分析，我们可以计算不同级别 bug 的加权平均值，得到一个整体的得分。
团队文化和满意度：虽然这不容易量化，但通过问卷调查和团队成员之间的评价，可以评估团队成员的相互满意度和配合程度。团队文化的重要性不容忽视，因为它直接影响团队成员之间的交流和协作。产品经理、研发和测试团队之间的协作默契对于项目成功至关重要。如果团队之间存在分歧或沟通不畅，即使代码质量很高，最终也可能出现问题。

综合这些方面，我们可以建立一套完整的指标体系来评估研发效能。这不仅包括项目的周期和代码质量，还包括团队文化的强度和团队内部的协作情况。只有当所有这些因素都达到一定标准时，我们才能全面提高研发效能。

余伟： 在度量研发效能时，我们采用的指标并非固定不变，而是动态的。大约 30% 的度量指标会定期进行滚动式更新。这种动态性是必要的，因为一旦指标被定义，人们总有可能找到方法来规避它们，使自己或团队在指标上的表现不至于太差。这是人的本性，我们不逃避这个事实，在度量指标管理上，我们有以下三个方式。

度量指标的动态化：我们建议在制定度量指标时，要考虑其动态化，新的指标可以与其他现有指标相互佐证。如果在某个方向上的指标表现很好，而在另一个方向上表现不佳，这种差异需要检视和分析。
重视度量指标：为了让大家重视度量指标，我们开发了度量平台，并公开度量数据。但仅仅公开数据还不够，有些人可能不会关注这些数据。为此，我们采取了一些管理手段，比如定期召开研发效能专题会议，每月将各个产品团队的度量指标数据公开，让大家了解自己的表现，并识别出与预期有偏差的地方。
度量指标的反馈机制：度量不仅仅是一个结果的展示，更重要的是建立反馈机制。我们希望团队在看到度量结果后，能够采取行动。如果团队认为自己的表现一般，我们不希望他们满足于现状，而是希望他们能够基于度量结果提出新的需求，深入分析数据，辅助决策，甚至对未来的风险进行预警。对于那些表现不佳或未达预期的团队，我们不仅仅通过度量指标来反馈问题，而是通过更多的方式来告诉他们需要改进和调整。我们的目标是让研发效能度量真正推动团队在质量、效率上实现滚动式提升和发展。

岑润哲： 指标的深入分析对于研发团队至关重要，因为不同产品形态和需求导致单一的缺陷率指标，如 1% 或 20%，并不能直观反映研发的实际表现。我们需要根据产品的不同维度进行细化分析，并将分析结果与产品的实际价值直接呈现给研发团队，这不仅有助于他们了解自己的工作效果，也是一种激励。

我们开发的工具如果能够帮助业务团队提升分析效率，那么将具体的用户故事反馈给研发团队，如他们研发的产品如何帮助金融机构的客户经理节省时间，可以显著提升研发人员的成就感。这种成就感来源于他们能够直观地看到自己工作的成果和对实际业务的影响。

当前，许多研发人员在编写代码后，并不十分清楚自己的代码如何被使用以及产生了哪些实际效果。如果能够让他们参与到产品的实际应用中，了解他们的工作如何帮助解决具体问题，那么这种正面的用户反馈和成功案例可以极大地提高研发人员的积极性和主观能动性，进而推动他们在未来的工作中更加投入和创新。