01

券商研发的 AI 转型，核心问题是持续累积

我参与的 FICC 核心交易平台已经持续迭代近 7 年，覆盖自营、做市、对客、销售以及境内外业务场景，研发中心包括产品、多个研发团队、架构、测试和运维，共上百人。过去几年，平台的建设规划和研发团队的组织架构随着业务发展方向几经调整，加上骨干离职，部分核心模块经过了多轮交接。

方向和团队在变，时间在推移，平台的架构、设计、代码逻辑等知识如何维护，成为团队的一项重要挑战：知识如何做 AB 岗互备，文档如何持续更新，交接时如何保证完整，都成了难题。外汇交易报价模块就是一个例子：关键骨干离职后，模块逻辑只能从代码反推，后续的维护和开发都付出了大量额外成本。

这类问题在 Agent 时代并没有消失，反而更加突出。在研发知识上下文充分的任务中，Agent 编写的代码已经可以接近资深程序员的水平，AI 正在抹平“写代码”这一段的技术差距。差距抹平之后，瓶颈随之转移：Agent 能否获得完成任务所需的研发知识上下文，包括需求、业务流程、功能设计、技术架构，以及当初为什么这样设计。

券商自研系统在这一环面临的挑战尤其大。相较于一般的应用系统，券商核心业务系统的生命周期通常在 10 年以上，技术栈“必须升级才升级”，又与大量内外部系统对接，复杂度和技术债持续累积，Agent 需要的知识因此很多。

一项开发任务常常涉及多个团队甚至多个部门，相关文档散落在 Wiki、JIRA 和各类汇报材料中，缺少统一的规范和版本管理，Agent 很难拿到准确的知识。核心系统的稳定运行是 IT 考核的重要指标，每一次改动都要谨慎验收；Agent 的产出越多，人的验收负担越重。

这些经历的共同点在于，知识只留在人和代码里。Agent 可以从代码读出系统“是什么”，却读不出“为什么”：哪些是业务约束，哪些是历史妥协，哪些可以改。缺少这部分知识，Agent 写代码越快，按错误理解施工的风险就越高。

新建的 FICC Agent 应用项目提供了对照：代码每次迭代，技术架构、功能设计和业务流程文档同步更新，之后的 AI 编码始终在一条可靠的基准线上推进，不需要每次从头考证，既提升了研发效率，也守住了质量（详见第四节）。

由此看，随着模型和 Agent 能力的提升，券商研发 AI 转型的核心问题，不再在于 Agent 能否写出代码，而在于每次任务的产出能否沉淀为下一次任务可用的研发知识上下文，也就是能否在迭代中持续、高质量地累积。

02

不持续维护的研发知识，会累积成知识债

研发知识不维护，就会产生利息

代码不持续重构，会累积技术债；研发知识不持续梳理和维护，同样会累积知识债。过期、重复、口径不一的信息越积越多，每次使用都要先付一笔考证成本。

一个常见的场景：今年做了一个债券业务项目，留下一套需求和方案。第二年又来了一个债券需求，由新同事承接。原有文档已无法确认是否反映现状，他只能重新梳理，另写一套方案。两份文档的结构、表述和信息颗粒度都不一样，也没有哪一份标明自己是现行版本。第二年的重新梳理，就是在为第一年没有维护的知识付利息；再过一年、再来一个项目，就会是三份。

知识债并非 Agent 带来的，但 Agent 从两个方向改变了它。一方面，债务增长更快：Agent 让代码和文档的产出不再受人力限制，它也不会像人一样先找老同事问一句，而是直接按拿到的内容施工。两份文档都会被检索到，它无法判断该信哪一份，甚至可能把两份拼在一起使用。另一方面，还债的成本在下降：过去维护文档全靠人工，难以坚持；现在 Agent 可以在每次修改代码时同步更新文档，持续维护才真正变得可行。

不加管理，Agent 的产出更可能累积为知识债，而不是资产。

对四种知识管理方式的观察与思考

面对知识债，业界已有不少应对。围绕“如何让 Agent 用好研发知识”，目前较为流行的有四种方式（其中有通用实践，也有亲身试过或在交流中观察到的），分别回答了四个问题：知识存在哪里（Wiki 与项目管理工具），怎样交给 Agent（Spec 驱动），怎样统一口径（本体），怎样被找到（RAG 知识库）。它们各自解决了一部分问题，但在常见的用法中，都没有回答同一个问题：知识怎样保持现行。

实践中遇到过这样的情况：一条风控规则先后有业务需求、产品方案和技术最终方案三份文档，后一份在前一份的基础上补充细节、做出调整，只有最终方案代表系统的现状。进入 RAG 知识库后，三份文档却成了同等地位的来源；检索权重又按来源设置，业务来源的权重更高，返回结果反而偏向最早、最粗略的描述。RAG 只能依据文档本身携带的信息排序；如果文档没有记录自己处于演进链的哪一环、是否已被取代，再好的检索规则也无从判断。

知识债有三个来源

“保持现行”之所以没有被回答，原因有三个，它们也正是知识债的三个来源。

• 产出不回流
  ：知识按项目和任务组织，任务结束，文档就不再更新。
• 缺少权威性
  ：同一事实写在多处，只记结果、不记理由。哪份是现行版本，本应由演进关系决定，而不是由来源或时间决定。
• 没有强制同步
  ：知识与代码分开维护。券商的上线流程通常要求提交需求、设计等材料，但检查的是文档齐不齐，而不是文档与代码是否一致；文档是否跟随代码更新，全凭自觉。

三个问题可以帮助估计自己团队知识债的规模：上一次需求变更后，相关的设计文档更新了吗？同一业务的两份方案，Agent 会拿到哪一份？文档不更新，代码能合并吗？

偿还知识债，需要的不是再建一个知识库，而是改变对待研发知识的方式。“文档即代码”（Docs as Code）的主张早已有之：像管理代码一样管理文档。过去，它受制于人工维护的成本，很难在大型存量系统中坚持下来；Agent 降低了这项成本，也让它变得更加必要。

03

研发知识是代码的上游，需要分层管理、持续维护

知识是代码的上游

“文档即代码”回答了怎么管，还没有说清为什么值得这样管。在 Agent 时代，研发知识的地位需要重新定义：它不再是代码的附属说明，而是代码的上游。代码记录系统“在做什么”，知识记录系统“应该做什么、为什么”。从足够完整的知识出发，Agent 可以反复生成和改进代码；从代码反推知识，却只能还原出“是什么”，丢失了“为什么”。因此，研发知识至少应当与代码享有同等的管理级别：有唯一的现行版本，有变更记录，接受评审和门禁。

两层知识：结构化记录，按场景取用

分层的目的，是把“为什么做”“现在怎么做”和“重要决策”分别结构化地记录下来，让不同场景按需取用。

意图层是需求、产品方案、技术方案等项目文档，记录某一次要做什么、为什么做。它可以有多份，按时间归档，写完不再修改；后续的变更作为新的记录追加，构成一条可追溯的演进链。

现状层是架构、功能设计、业务流程等系统文档，记录系统现在是什么样，其中的设计决策记录说明现状为什么是这样。它每个主题只有一份，随代码持续更新。

两层之间靠回链连接：每条需求完成后，标明它改动了哪些系统文档；每份系统文档的变更，也能追溯到引起它的需求。

分开存放之后，不同场景各取所需：改代码、修缺陷时读现状层，需求评审、追溯变更原因时读意图层，调整架构、重构时读设计决策。Agent 每次只加载当前任务需要的那部分，研发知识上下文用得更少，也用得更准。回到第二节的例子：债券业务的新同事应当先读现状层，而不是在两份项目方案之间判断哪份更新；风控规则的三份文档都属于意图层的同一条演进链，Agent 需要了解规则现状时，读的应是现状层中唯一的那份描述。

我的团队新建的 FICC Agent 应用项目（第四节详述）就采用了这种划分：需求记录写完不回改，设计与架构文档持续更新，一份需求索引把每条诉求回链到它影响的设计文档和提交，每次开始工作时按任务类型加载对应的文档。

三项机制：持续维护，防止知识崩塌

分层解决了知识“放在哪里”，还没有解决“如何保持现行”。研发知识不是写一次就完成的资产，每一轮迭代都可能让它偏离代码一点。在人工开发时代，这种偏离是缓慢累积的；有了 Agent，它会自我强化：Agent 按过时的文档写代码，下一份文档又根据这段代码来写，偏差一轮轮放大。即使在这个从第一天就重视文档的项目中，启动第 8 天的一次检查，也发现了 7 份文档与代码不一致。不主动维护，多轮迭代之后，知识的质量会迅速崩塌。

持续维护依赖三项机制，分别对应第二节的三个缺口：

如果说两层知识是仓库，Skills 就是生产线。研发方法本身也是知识，写成 Skills 之后，每个人、每个 Agent 会话都按同一个标准产出，入库的知识在结构、表述和颗粒度上保持一致。第二节债券例子里“两份方案口径不一”的问题，根源正是缺少这条生产线。

三项机制缺一不可。只有文档结构、没有 Skills，规范写在那里却没人照着做；只有 Skills、没有门禁，赶工时最先被省略的就是文档更新；只有门禁、没有文档结构，门禁没有可以对照的标准。

人与 Agent 的分工：AI 抹平执行的差异，放大认知的差距

编码、测试、文档起草这些执行层面的工作，Agent 已经可以承担大部分，执行不再是研发的主要瓶颈。人的精力随之转向方案、设计和规划，以及对 Agent 产出的判断与验收。AI 抹平的是执行的差异，放大的是认知的差距。

现阶段，Agent 已经能提出方案、比较方案，但做出正确的选择，取决于它掌握的信息是否充分。至少有三类信息常常不在它的上下文里：一是现实约束，环境、业务规则等写在文档和代码之外的限制；二是历史决策，过去的重要技术决策和踩过的坑，缺了它们，同样的坑可能踩两遍；三是当下条件，方案是否符合技术架构、研发资源和项目排期。

人的认知、项目经验和工程化知识，因此成为最有价值的研发知识。但它们只有被写进知识体系，才能被 Agent 反复使用，也才不会随人员流动而流失，第一节中骨干离职后模块只能从代码反推的情况就不会重演。这正是两层知识中要单独记录“为什么”和设计决策的原因：Agent 写下“是什么”，人补上“为什么”，门禁保证两者与代码同步。

04

FICC Agent 应用项目的实践：写代码成了最短的环节

这个项目在研发过程中有过一次核心重构：更换底层的数据存储方案，同时重新设计数据结构。上午，设计文档定稿；午后，Agent 按实现计划写代码，用时约 45 分钟；剩下的时间，用在端到端验证、人工验收、收尾核对和文档同步上。从设计定稿到合并，不到 6 小时。回头看这一天，写代码是最短的环节，时间主要花在了写代码之前和之后。

这是我的团队今年 6 月中旬启动的项目，从第一天起就以 AI Native 的方式开发：核心开发 2 人，公司内部另有同事参与，大部分代码和文档由 Agent 在人的指导下写成。第三节讲的两层知识和三项机制，就是在这个项目里一点点长出来的。几个月下来，我有三点体会。

知识体系的回报，出现在交接和重构这两个最痛的时刻

平时，知识体系的价值并不显眼：每次都要多花时间更新文档，却看不到立刻的回报。它的回报集中出现在两个时刻。

一是新人加入。 一位新同事用 2 天熟悉了项目的架构和流程机制，提交了第一个合并请求。开工时加载的文档，就是项目当前的样子，不需要从代码里反推。

二是重构。 在我看来，上面那次重构之所以快，不是因为 Agent 写代码快，而是因为涉及的每个模块，现状、约束和当初的设计理由都写在文档里。方案讨论可以直接从“要改成什么样”开始，而不必先花时间弄清“现在是什么样”。

这两个时刻，恰好对应第一节里存量平台最痛的地方：骨干离职后，模块只能从代码反推；交接时，知识难以完整传递。两边系统的规模和复杂度不可同日而语，不能直接比较快慢，但差别的来源是清楚的：一边的知识留在人和代码里，一边的知识写在持续维护的文档里。

机制要轻，要嵌进日常的工作流

我在这个项目里做得最有效的一件事，是把机制嵌进每次工作的开头和结尾，而不是另设一套流程。开工时，Agent 先读取项目规范和架构文档，按任务类型加载相关设计，与人确认本次目标后才动手。收工时，Agent 核对文档与代码是否一致、同一功能在不同文档里的说法是否一致，并把本次形成的新约定写回项目规范。每个合并请求之前做一次这样的核对，另外不定期做一次整体回顾。

这套做法的代价，按我的估算，约占每个任务 10%–20% 的时间。换来的是研发时间结构的变化：过去花费最多的编码环节，比重下降了；沟通目标、方案设计以及知识与上下文的管理，比重上升了。那次重构中 45 分钟的编码时间，就是一个缩影。这与第三节的判断一致：执行交给 Agent，人的时间用在认知层面的工作上。

机制是动态发展的，要主动迭代

这套机制不是一开始就设计好的。第三节提到的第 8 天那次检查，发现了 7 份文档漂移，促成了收尾时的一致性核对；一次文档体系审计发现需求无法追溯，当天就有了需求记录机制；换用新一代模型后，开发流程也随之调整，不再使用原先的流程插件。收尾时的最后一步“经验沉淀”，更让机制在每次工作结束时都有机会更新。

项目推进、问题暴露、团队流程成熟，以及大模型能力和业界实践的演进，都会推动机制调整。稳定的是原则：两层知识、意图回流、门禁同步；持续调整的是具体规则、检查项和 Skills。团队需要建立主动管理和迭代机制的意识与习惯，并且让机制的每一次调整，也像研发知识一样被记录、有理由可查。

这个案例还不能说明什么

这个案例也有它说明不了的地方。它是新建项目，没有多年的历史代码和存量文档；团队规模小，周期不到半年；门禁由流程触发、Agent 执行、人确认，还没有接入合并时的自动拦截。三项机制放到一个运行 7 年、上百人协作的存量平台上是否同样有效，还需要验证，这是第五节要讨论的问题。

05

存量系统：先定标准、建基准线，再在迭代中累积

新建的系统从第一天起就在知识体系里生长，没有历史包袱。存量系统不同：一个运行多年的平台，知识量大、分散在各处，其中一部分已经过期。从零开始重写不现实；把历史文档原样搬进新体系，又等于把旧债转进新账本。我的做法分三步：先定标准，再建基准线，然后在迭代中持续累积。

先定标准：把团队的流程抽象成 Skills

第一步，是让所有人在同一条标准线上工作。第三节说过，Skills 是知识的生产线；存量平台上参与的团队和人更多，这条生产线更要先建起来。需求分析、方案设计、文档校验这些关键环节，团队共同遵循的流程和标准，都抽象成团队共用的 Skills。

标准要轻。规则和必填项一多，大家就开始应付填写，甚至干脆跳过，真正有价值的知识反而没写下来；模板过于僵硬，又会把知识硬塞进固定的格子，那些不属于任何格子的经验和判断就丢了。过度设计的结果，往往是知识的缺失。

标准也要持续维护。Skills 不是某一个人写好就完成的，团队里每个人在使用中发现的问题和更好的做法，都应该回写进去。这和第四节的体会一致：机制是动态发展的。

再建基准线：从架构到数据，再到业务功能

有了标准，第二步是为存量系统建立一条可靠的知识基准线，后续的迭代都在这条线上展开。

梳理的顺序是系统架构、数据、业务功能，这也是从“机器能校验”走向“依赖人判断”的顺序。系统架构大部分可以从代码还原，由 Agent 梳理、人来确认；数据的表结构和字段可以还原，口径和含义需要人来补；业务功能的“是什么”可以从代码读出，“为什么”只能靠人，而且往往只有业务同事说得清。

范围上，不追求一次做全。全局架构先梳理一份薄的地图，让人和 Agent 都知道系统由哪些部分组成、彼此怎样连接；然后选改动最频繁的模块，在模块内按数据、业务功能逐层深入。改动越频繁，知识过期的风险越高，梳理的回报也最先显现。

为此，我做了一个存量知识梳理的 Skill，把梳理的流程和标准固定下来，保证每个模块的起点一致。但各模块的情况不同、重点不同，Skill 只能保证起点；梳理的质量，取决于过程中人给出的引导。

基准线还有一个陷阱：历史文档和老同事的记忆里，本来就混着过期的信息。梳理出来的每一条知识，都要对照代码或现行系统校验；校验不了的，明确标为“待确认”，而不是直接当作事实写进现状层。

然后在迭代中累积：触碰即转化

基准线建好之后，就回到第三节的三项机制：每次改动都同步更新文档，收尾时核对一致性。还没有建立基准线的模块，不必专门安排梳理，在下一次被修改时再转化：Agent 先从代码还原现状，人确认“为什么”，文档随这次改动一起沉淀。日常的研发工作，由此成为知识体系不断扩展的过程。

已经验证的，和尚待验证的

这套做法已经在我负责的研发团队中试行，用在面向生产的真实项目上，几个迭代下来效果良好。但验证的时间还短，规模也还小，真正的考验在后面。

06

长期竞争力取决于持续累积，而非单点提效

在 Agent 时代，模型能力持续提升，Agent 的工作流框架也在不断更新，执行能力已经不再是研发的瓶颈。同样的模型、同样的工具，每个团队都可以用上，Agent 写代码的速度，也会很快在团队之间拉平。真正拉开差距的，是两样 Agent 自己生产不出、别的团队也复制不来的东西：持续累积的研发知识，以及在这些知识之上形成的系统架构。前者记录系统应该做什么、为什么这样做；后者决定系统能否承载持续不断的变化。

Agent 让每一次任务的产出更多、更快，这些产出是累积为资产，还是累积为知识债，取决于团队是否把研发知识当作代码的上游来管理。

单点提效会被下一代模型抹平，累积下来的知识不会。

这套做法还有两个我没有答案的问题。

第一，知识体系如何在持续迭代中长期运行。新建的 FICC Agent 应用项目和团队内部的试用项目，证明了它可以启动、可以运转；半年、一年之后，知识是否仍然现行，机制是否仍然被认真执行，还需要时间检验。

第二，从小团队到大团队、跨团队，该如何推进。小团队里，几个人就能对标准达成共识，共同维护现状层的知识；在一个上百人、多团队协作的存量平台上，标准由谁来定，跨团队的知识由谁来维护，团队之间的边界划在哪里，都还没有现成的答案。

这两个问题，也是我接下来要继续实践的方向。

— 完 —