一、半年前，我把自己从最熟悉的位置挪开了
在 OceanBase 的第五年，我做了一个在旁人看来不太划算的决定：从后台的产品经理岗位，转到一线的 FDE。
后台的日子是体面的。你熟悉每一条需求从立项到发版的路径，知道哪个功能在哪个版本进，能在一场内部评审上把技术方案讲得滴水不漏。但时间久了，会有一种隐约的不安：我讲的每一句话逻辑和理论上都成立，可我不确定它们是否真的重要。会议室里的"客户需要"，是别人转述给我的；Dima上优先级上的"高优"，是前线反馈回来的。我离产品很近，但离使用产品的人很远。
所以我来到了前线。不是去"支持一下"，是把工位搬到了离客户最近的地方，跟着BD、交付团队一起进会议室、进机房、进凌晨的群聊。半年过去，我没有变得更能讲 PPT，反而变得更能听懂沉默。客户不说的部分，往往才是真正的问题。这篇文章，是这半年的账。
二、我的履历，是理解客户的一条近路
我常被问：你以前做过 Java 研发、DB2 DBA、Oracle DBA、架构师，还做过 2C 的技术产品经理，这些跟现在有什么关系？
关系很大，而且不是简历意义上的关系。
写 Java 那年，让我知道一条慢 SQL 是怎么被写出来的。不是因为开发不想写好，而是因为业务在催、字段在加、索引没人管。所以当客户说"迁移之后性能要一样"，我不会只回答"我们的优化器很强"，我会问：你们最慢的那几条 SQL 是谁写的、多久改一次、有没有人负责。
在做 DB2/Oracle DBA 的那 10 余年，我学会了敬畏。数据库这一行，出事往往不是因为“功能不够”，而是因为“边界没守住”。一次误操作、一个没有评估过的变更窗口，代价可能是几小时的业务停摆。服务商侧和集团内部我都待过，同一件事看到的却是两种视角：乙方算的是响应时长，甲方算的是业务损失。这个差别，后来在前线帮我听懂了很多客户的潜台词：他们问“多久能恢复”，问的其实是业务，不是技术。
在某外资金融机构做高级工程师，我见到了金融行业真正的约束：审计、变更审批、双人复核、可回滚。这些在互联网语境里像是“效率的敌人”，但在银行，它们是系统能够被信任的前提。一个产品如果不懂这些，再先进也进不了生产。再往后做架构师，我第一次从单点走到系统，知道一个技术选型背后要背多少年的运维成本。
做 2C 技术产品经理，是另一套训练。面对几百万普通用户，你会彻底明白一件事：没人读你的文档。用户只会用，不会学。产品必须自己把路铺平。
这五段经历，在前线变成了一种能力，我把它叫做"翻译"：把客户的抱怨翻译成需求，把需求翻译成产品的边界，把产品的边界再翻译回客户能听懂的风险与代价。
三、前线的第一课：客户问的不是功能，是责任
到前线之后，我遇到的第一个认知冲击，是客户提问的顺序变了。
在内部，我们讨论产品，起点通常是"我们有什么"。在前线，客户的第一个问题往往是："如果它出问题，谁兜底？"这句话听起来不技术，其实极其技术。它背后是三层追问：出故障时数据会不会丢？切换要多久？切换之后业务方能不能感知？以及最现实的一层——出了事，是你们来解决，还是我们自己扛？
我参加过一场方案评审会，客户的技术负责人只问了三件事：你们是否有真实案例，在这类系统上跑过多久、出过什么故障以及怎么处理的。那场会让我明白，用户买的不仅仅能力，更是风险转移和风险可控。
这件事让我清楚的知道：最重要的产出不是"讲清楚我们多强"，而是"讲清楚哪里会有问题、有问题的时候怎么办"。前者让客户心动，后者让客户信任敢签字。
心态的转变也是从这时候开始的。在后台，我的 KPI 是"这个功能有没有按时发"；在前线，我的 KPI 变成了"这个客户敢不敢把它放到核心系统"。这两个指标的重量，不在一个量级。
四、DataPilot：把"能回答"变成"敢用于生产"
这半年，我支持 DataPilot 在两家金融机构落地。这一段经历，把我对"AI 产品"的理解彻底改写了一轮。
DataPilot 是 OceanBase 推出的 AI 驱动智能体开发平台。在演示环境里，它很容易让人兴奋：一句自然语言，几秒钟出一张图、一份报告。但真正进到银行，兴奋感会在第一天立即消失，因为客户会开始问一些很不客气的问题：这个数为什么和报表系统对不上？
口径是谁定的？改了口径谁审批？
它答错了，我怎么知道它答错了？
分行的人上传自己的 Excel，会不会把数据带出去？
这些问题，没有一个是模型能力问题。
在其中一家机构，测试在 5 月底启动，前后有 20+ 人参与，来自数据管理部门、研发部门、数据中心和分行业务人员。团队在平台上创建了 60 + Agent，提出了 30 多项需求。其中典型的测试场景：驾驶舱业务：20 个问题答对 19 个，准确率 95%。唯一错的那一个，是币种换算。
我至今觉得这个错误很有代表性。它不是模型不会算，而是"口径"没对齐——同一个指标，业务方心里的定义和数仓里的实现差了半步。这半步，在报表时代由人肉对齐，在智能问数时代会被放大成一次公开的错误。
所以我们后来花了大量时间和客户讨论的不是模型，是语义。DataPilot 的 OSI 三层语义架构，本体图谱、语义口径层，本质上是在回答一个问题：让机器理解业务，靠的不是更聪明的模型，而是更严肃的定义。本体层管"世界由什么构成"，语义口径层管"这个词在银行内部到底指什么"。这两层做实了，准确率才是可维护的，而不是可炫耀的。
这半年我在 DataPilot 上学到的最重要一课是：AI 产品的落地难点，八成在组织，两成在技术。 谁有权限定义口径、口径变更怎么走流程、错误由谁复核——这些是产品设计必须提前回答的问题，否则再好的模型也只能停在演示环节。
另外那 30 多项需求里，有一类让我印象很深：对接行内知识库、支持分析本地上传的 Excel、PDF、Word。它们不"性感"，但它们是真实工作流的入口。一个业务人员手上的分析，起点常常是一份别人发来的表格，而不是一个干净的数仓表。产品要接住的，是这种“不体面”的真实。
五、OAgent：把凌晨三点的经验，变成四分钟的流程
如果说 DataPilot 让我重新理解了"语义"，OAgent 让我重新理解了"经验"。
OAgent 是一个智能诊断平台。它的工作方式并不神秘：通过定时任务从 OCP 取告警，自动完成告警分析、根因诊断、生成处置方案，最后由用户确认执行。
听起来像一条流水线，但它替代的东西很重。
数据库运维里最贵的成本，从来不是机器，是凌晨三点那个被电话叫醒的人。他要在几分钟内判断：这是真故障还是误报？影响面多大？先扩容还是先限流？回滚会不会更糟？这些判断依赖十年经验，而且不可复制、不可传承、不可审计。
在其中一家大型金融机构的落地中，我们以一个核心支付集群为对象做了完整验证：从告警触发到业务恢复，闭环控制在 4 分钟内，而这个集群承载着日均 500 万笔交易。
我对"4 分钟"这个数字的感情，比对任何性能指标都复杂。因为它不只是快，它意味着处置动作从"人的临场反应"变成了"系统的标准流程"。方案是生成的，执行是人确认的。这个"人确认"的设计，我一开始觉得是妥协，后来觉得是克制：在金融场景里，AI 不应该替人做决定，它应该把人从"找原因"里解放出来，让人只做"要不要"这一个决定。
这半年我见过运维同事看 OAgent 演示时的表情，那不是看到新功能的表情，是看到"我以后能睡个整觉"的表情。产品经理能收到的最好反馈，大概就是这个。
六、最有成就感的一役：8000 亿条记录的 PoC
如果只能讲一件事，我会讲这个 PoC：CDH 迁移到 OceanBase MySQL 模式。
客户原来的架构是 CDH 加 Kylin，一共 70+ 台以上机器规模。要验证的目标很朴素，也很残酷：数据能不能进来、加工能不能等价、查询能不能更快、机器能不能更少。
PoC 时数据规模是 8000 亿+记录，原始形态是 17TB 的 ORC 文件。导入 OB 数据库阶段我们跑出了 2800 万+ RPS 的速度。ETL 数据加工的结果与 CDH 侧完全等同——这一点比速度更重要，因为对客户来说，加工结果不一致等于整个迁移不成立。BI 报表和 Ad-hoc 查询，10 秒内出结果，部分场景是毫秒级。
最后的结论是：基于这次 PoC 的实际表现，完全可以用 24～30 台机器，替代原来的 CDH 加 Kylin 共 70+ 台以上的机器。
我为什么对这件事最有成就感？不是因为这些数字好看，而是因为它回答了一个长期存在的偏见：OceanBase 是不是只能做交易？
这个 PoC 的价值在于它是"等价替换"，不是"降级可用"。客户不需要为了省钱而牺牲分析体验，反而在查询延迟上拿到了更好的结果，同时机器数量降到原来的一半左右。这类结论对客户的决策影响是决定性的，因为它把"要不要换"从技术问题变成了财务问题，而财务问题在企业内部是能被推动的。
过程中的不确定性也值得说。PoC 从来不是一条直线，中间有表组/分区设计不合理、数据分布不均衡、旁路导入故障异常定位、有脏数据的处理&数据核验、数据迁移方案的反复验证。我作为“产品经理”在里面的作用，说出来不浪漫：把每一次失败定位成"产品问题、方案问题还是用法问题"，然后决定哪些当场解决、哪些带回产品线、哪些写进迁移方法论。前线最大的价值，是能把"客户的一次具体失败"变成"产品的一次普遍改进"。
这件事之后，我对 OceanBase 的判断变得很笃定：它在交易能力上的进步是持续的，而在 AI 与 AP 能力上的完善，已经不是"补齐"，是"能替"。
七、客户为什么愿意 all-in-OceanBase
这些我听过很多次"all-in"，也追问过很多次"为什么"。客户的答案，最后收敛成四条。
第一，出问题有"兜底"，再也不怕出故障。 这是所有理由里权重最高的。客户要的不是"不会坏"，因为故障是 100%会发生的， 是"坏了有人管、有预案、能切回来"。这背后是产品的高可用设计、也是团队在场。兜底这两个字，是信任的俗名。
第二，越用越多，越多越便宜。 这句话乍听反常识，其实是规模效应：资源池化、多租户、压缩、统一运维，让单位成本随规模下降。客户从一套系统用到十套系统，边际成本不是线性增长。对一家要管上百/上千个业务系统的银行来说，这个曲线的意义远超单次采购价格。
第三，外围工具越来越完善。 OCP、OMS、ODC 这三件套，是把数据库从"一个引擎"变成"一套可运营的基础设施"的关键。OMS 决定迁移敢不敢做，OCP 决定日常运维撑不撑得住，ODC 决定开发和管理人员用得顺不顺。工具不酷，但工具决定产品能不能被大规模使用。
第四，持续创新，AI 能力保持领先。 这一条是加分项，但在决策末期常常变成决定项。客户会说：我不想三年后再迁一次。
八、产品形态的完整，是"能替"的底气
到前线会发现，客户的问题从来不是"你们最强的是什么"，而是"我这个场景你们有什么"。
OceanBase 现在的产品形态，恰好能把这句问话接住。
- seekdb 面向 AI 应用的轻量形态，把检索能力做进数据库本身，解决的是"应用侧要一个不笨重的数据底座"的问题。
- 集中式形态，用租户级别的主备来保障高可用。它回答的是大量中小规模、但绝对不能停的业务：不需要分布式那么大的盘子，但需要同样的可靠性。
- 分布式形态，共享存储与存算分离两条路线，回答的是规模、弹性与成本的问题。计算和存储各自扩展，资源按需供给，这在大数据量场景里是决定成本曲线的关键。
这四种形态放在一起，才叫"产品家族"。客户不需要为了一次选型去赌未来五年的架构，他可以从一个小场景开始，然后长到任意规模。这半年我越来越相信：一个基础软件产品成熟的标志，不是能力最强的那一项，而是最弱的那个场景它也能接。
九、半年之后，我对"产品经理"的四个修正
第一，从功能清单到责任清单。 过去我习惯说"我们支持 X"。现在我会先讲"X 在什么情况下不成立，那时候我们怎么一起处理"。前者是销售语言，后者是产品语言。
第二，从"客户要什么"到"客户会为什么付钱"。 客户提的需求，常常是他对问题的猜测，而不是问题本身。前线让我学会往前多问一层：你说要这个功能，是为了解决哪一次具体的失败？
第三，从内部对齐到前线翻译。 “产品经理”在前线最不可替代的价值，不是拿单，是双向翻译。把客户的现场翻译成产品线能执行的判断，把产品的取舍翻译成客户能接受的风险说明。这个角色，坐在总部是做不了的。
第四，从追求先进到追求可被信任。 在金融行业，一个能力如果无法被审计、无法被回滚、无法被解释，它就不算能力。这半年我对"克制"这两个字的理解深了很多：能自动做十步，但只自动做七步，剩下三步留给人确认，这不是能力不足，这是对场景的尊重。
十、写在最后
半年前我以为自己去做的是"支持"，半年后我发现我做的是"校准"。
校准我对客户的理解，校准我对产品边界的判断，也校准我对这份工作的期待。在后台，我关心的是产品能不能变强；在前线，我关心的是产品能不能被托付。
这两件事不冲突，但后者更难，也更值得。我依然会在会议室里讲架构、讲性能、讲最佳实践。但每次开口之前，我会先想起那些具体的场景：一个 DBA 凌晨三点的电话，一位业务人员手里那份不干净的 Excel，
一位技术负责人反复追问的"谁兜底"。“产品经理”的成长，往往不是学会了更多答案，而是终于问对了问题。 这半年，我大概问对了几个。接下来还有很多个。
