陈科｜从底座到 AI，技术人的成长进化论

在数字技术持续重构产业格局的今天，从分布式架构到人工智能的技术跃迁，正成为传统金融行业数字化转型的核心驱动力，而大模型与企业级知识服务的深度融合，更是券商在科技赋能业务中的关键探索方向。

如何将互联网高并发、微服务与 PaaS 架构的成熟经验，迁移至强合规、高稳定的金融技术体系；如何通过大模型与企业知识库建设，破解内部知识沉淀、场景落地、数据安全与应用实效等核心难题，成为金融科技领域亟待突破的焦点议题。

近日，我们有幸邀请到资深技术专家陈科老师，围绕技术转型与能力沉淀、金融数字化架构实践、企业级大模型平台建设、职业成长与技术路径选择，为理解全栈技术能力如何支撑金融 AI 转型、重构企业技术价值提供深度洞察。

谢谢主持人，也很高兴和大家交流。

我2012年毕业后进入互联网行业，早期在网易和vivo主要做中间件研发、微服务架构和PaaS基础设施，长期和高并发、分布式系统、服务治理这些问题打交道。后来进入证券行业，参与金融科技平台和数字化转型相关工作，把互联网架构思维带到金融场景里。最近两年，随着大模型技术的发展，我又把工作重心逐步转向企业知识库和大模型应用落地。一路走来，从中间件到平台，再到AI应用，我一直在做一件事，就是用技术解决复杂业务问题。

问题2：从互联网到券商，再切入大模型，三次大的方向跃迁，您是如何快速建立新领域认知，并把过往经验迁移过去的？

我进入一个新领域，通常先做三件事。第一，快速建立全局认知，先把业务链路、核心系统、关键约束搞清楚。第二，分辨哪些是行业特有的，哪些是通用规律。比如架构设计、稳定性治理、平台化建设，这些底层方法在很多行业都是通的；变化更多是在业务语义、监管要求和落地方式上。第三，就是尽快通过真实项目把认知压实。因为很多东西只有做过才真正理解。对我来说，跨领域不是推倒重来，而是把过去积累的能力，在新问题上重新组合、持续升级。

问题3：随着技术的快速发展，如何保持对新技术、新趋势的敏感度？你平时通过哪些渠道获取行业前沿信息，又是如何筛选和判断哪些信息对自己有价值并值得深入学习的？

我觉得保持敏感度很重要，但更重要的是判断力。平时我主要通过几个渠道获取信息：一是头部技术公司、云厂商、开源社区和技术博客，二是行业会议和同行交流，三是和业务、监管相关的信息。因为尤其在金融行业，技术能不能落地，不只是看先进不先进，还要看业务价值和合规边界。至于筛选，我主要看四点：是不是在解决真实问题，能不能工程化落地，和当前业务阶段是否匹配，能不能沉淀成长期能力。很多热点我不会一上来就重投入，而是先做小范围验证，看效果、成本和复杂度，再决定要不要深入。

问题4：在金融行业进行数字化转型过程中，遇到了哪些技术难点和问题，是如何解决这些问题的？

金融行业数字化转型最大的难点，不是在新系统上做建设，而是在大量存量系统之上做升级。这里面往往是多厂商、多技术栈、强监管、不能轻易中断，这几个问题叠加在一起。我们的做法不是一刀切替换，而是先做分层治理和标准化接入。通过统一网关、统一 API 管理、服务边界梳理，把新老系统逐步接起来。对于受监管业务，则强调访问隔离，核心服务尽量放在私有域里，对外只通过全局网关暴露有限 API，并做好鉴权和权限控制。同时在治理上，把核心 API、高延迟 API、外部 API 做分组隔离，发布必须灰度、滚动、可回滚。我的体会是，金融行业转型的关键不是上了多少新技术，而是能不能在复杂存量和强监管约束下，稳步演进。

问题5：在微服务架构落地过程中，服务治理、限流、熔断、降级这几块，您踩过最致命的坑是什么？

这个更多是我在互联网公司时期做高并发系统时的经验。踩得最深的坑，其实是治理策略过于粗暴，把局部问题放大成整体问题。比如下游只是少量实例抖动，但上游熔断做得太粗，一触发就把整个服务都熔断了，结果本来只是局部异常，最后变成全链路不可用。还有一种情况是限流只考虑‘拦’，没有考虑‘拦完以后怎么办’，所有请求直接失败，核心和非核心业务没有区分，限流、熔断、降级没有按照层级和维度去区分，导致用户体验会非常差。我记得在网易工作时，APP推荐首页就是一个高并场景，我们就是通过不同层级，不同维度去落地的，例如按照用户比例去限流和降级，保障确保VIP用户正常可用，保障普通用户在触发降级时看到的兜底内容是一致的。再就是重试配置不当，本来是为了提高成功率，结果在高并发下反而把下游打穿了。

所以我后来最大的经验是，限流、熔断、降级一定要分层、分级、分粒度设计，不能用统一模板一把梭。

问题6：做高并发系统时，是如何做容量规划、压测体系与全链路监控的？有哪些关键指标？

这部分也是我在互联网时期的工作体会。高并发系统最核心的，不是流量来了能不能扛一次，而是你知不知道自己的边界在哪里。容量规划上，我一般会从业务峰值倒推整条链路，包括网关、应用、缓存、数据库、消息队列和外部依赖，最后形成容量模型，并且预留冗余。压测体系不能只做单接口压测，还要做核心场景压测、混合流量压测、全链路压测，甚至故障演练，验证系统在异常情况下能不能稳住。监控方面，除了 CPU、内存这些基础指标，更要看 QPS、TPS、P95、P99、错误率、超时率、线程池、连接池、消息积压，以及关键业务成功率。我的经验是，真正的稳定性来自提前发现边界，而不是出问题后再补救。”

问题7：在券商内部建设企业知识库平台时，如何选择适合金融领域知识处理的大模型，考虑了哪些模型性能指标和金融业务特点，不同模型之间有哪些差异和优劣？

企业知识库平台的核心，其实不只是选模型，而是知识治理、检索体系、权限体系和模型能力的整体组合。金融场景里，不能简单追求‘哪个模型最强’，而要先看场景到底要解决什么问题，是问答、检索、总结、审核，还是结构化抽取。选型时我主要看几个指标：专业理解能力、事实准确性、幻觉控制、长文本处理能力、结构化输出能力、响应速度和部署成本。同时还要重点考虑私有化、安全隔离和审计留痕。闭源模型通常通用能力更强、效果更稳定，适合快速验证；开源模型则更可控、更适合私有化和深度定制。所以实际落地时，往往不是单模型，而是基座模型、Embedding、Rerank、规则和权限系统组合起来一起工作。

问题8：券商拥有海量但分散的数据，大模型应用需要高质量、结构化的数据支持，如何建立有效的数据治理体系，对数据进行清洗、整合和标注，为大模型提供优质的数据输入，有哪些数据治理工具和流程？

我一直认为，大模型在企业里的上限，很多时候是由数据治理决定的。券商的数据特点不是少，而是多、散、杂，而且权限边界复杂、口径不统一。所以第一步一定是数据盘点和分类分级，先搞清楚数据归谁管、能不能用、有没有敏感风险。第二步是标准化清洗和结构化处理，包括去重、纠错、版本识别、元数据补全、标签和摘要生成。第三步是权限和安全治理，要做到按业务域、按部门、按角色细粒度授权。第四步是效果反馈闭环，根据召回准确率、人工审核意见和实际使用效果持续优化。工具上会涉及文档解析、OCR、元数据管理、脱敏、标注审核、向量检索和评测体系，但核心还是要形成持续迭代的数据治理流程。

问题9：金融监管政策不断更新变化，大模型在券商应用中如何确保实时跟进并满足新的合规要求，例如在反洗钱、投资者适当性管理等场景，有没有建立动态的合规监测机制嵌入到大模型应用流程中？

在券商场景里，大模型不能只追求能力强，更要追求可控、可审计、可纠偏。我的理解是，合规必须前置，嵌入整个应用流程，而不是事后补丁。我们的思路是把外部监管要求和内部制度要求持续沉淀成动态更新的知识和制度体系，也就是常说的‘外规内化’。具体做法上，一层是知识检索，确保模型引用的是最新、权威的制度依据；一层是规则校验，对敏感内容和关键场景做硬约束；再往上是人工复核和审计留痕。像反洗钱、投资者适当性管理这些场景，我认为大模型更适合做辅助识别、归纳总结和风险提示，而不应该直接替代最终判断。这样既能提高效率，也能守住合规底线。

问题10：随着大模型技术的不断发展，未来在券商业务中还可能拓展出哪些新的应用场景，对于这些潜在场景，目前做了哪些前瞻性的研究和准备？

我觉得未来大模型在券商里的应用空间会非常大，而且不会只停留在智能问答这种浅层场景。随着模型能力、工具调用能力和企业治理能力逐步成熟，它会从信息辅助，慢慢走向流程辅助，再进一步走向业务协同。

具体看，我比较看好的方向有几类：一类是“外规内化”，比如监管规则理解、制度对齐、变更影响分析、执行检查等，帮助机构把外部规则更快转化成内部可执行能力；第二类是“数字员工”，比如投研、运营、合规、研发、客服等岗位的辅助；第三类是“智能工具化”场景，比如合同审核、制度文件审核、会议纪要、知识检索、材料撰写等，这类场景边界清晰、收益也更容易验证，应该优先落地。再往后，还可以逐步延伸到投顾辅助、财富管理、投行业务支持、风险排查、培训传承等更深层业务。

不过我觉得现阶段也不能太激进，更现实的策略还是优先瞄准业内相对成熟的场景，让子弹先飞一会。因为开源模型和智能体方案迭代非常快，今天花很大力气做的定制优化，可能下一次模型升级后就被快速覆盖，收益反而不如直接升级模型。比如有些最近很火的开源 Agent 方案，更适合个人产品，离企业级、强合规的券商场景还有距离。所以我认为现阶段更重要的是先把知识库、智能体平台、模型服务平台和安全治理底座搭好，为后续规模化落地做准备。

问题11：大模型正在重构技术栈，你认为未来工程师的核心能力模型会发生怎样的变化？

我认为未来工程师的核心能力模型会继续上移，但不是简单地从“代码实现者”变成“系统设计者”，因为今天的大模型和智能编程工具已经开始深入参与设计本身。真正稀缺的能力，将越来越体现在对问题和约束的定义、对方案优劣的判断、对复杂系统的取舍，以及对最终结果的验证和责任承担上。换句话说，未来工程师依然要懂实现，也依然要懂设计，但更核心的竞争力会转向“驾驭设计与实现过程”的能力。谁能把业务目标、系统约束、数据条件、风险边界和工具能力说清楚，谁就更能借助AI放大产出。因此，未来工程师最重要的能力，第一不是单点编码能力，第二也不只是传统意义上的架构设计能力，而是更高一层的系统级判断能力与人机协作编排能力。前者决定做什么、为什么这样做，后者决定如何把模型、工具、流程和人工协同组织成一个可靠闭环。从这个意义上说，工程师不会被压缩成“提示词操作员”，也不会只剩下写代码或画架构图，而会逐步演变成面向复杂问题的解决者、约束定义者、结果校验者和智能系统的指挥者。