MortiseAI 创业日志 #001 走出去

从最初接触 AI 到自己真正着手打造一款 AI Coding 工具，转眼已过去 5 年。

起点

5 年前，我在某宝的消息团队偶然推动了一个 AI 监控项目，需要每日处理数以十亿计的消息，如何以低成本、实时地监控违规消息成为关键。例如，有些通知消息看似“红包来了”，点进去却跳转到某直播间，属于典型的第三方违规导流。由于当时的 AI 技术尚不成熟，项目只完成第一期就搁浅了。但这段经历让我意识到一个严重的痛点：大多数系统在设计与实现阶段从未考虑过 AI 的应用，“AI-First” 仅停留在口号层面，等到需要真正接入 AI 时，就会出现各种问题。

也是从那时起，我开始了长达 5 年的思考与探索：如何构建真正的 AI-First 系统？

目标

决定投身 AI 编程领域后，我一直在思考“AI 编程的真正目的”。彼时，我入职了一家在线教育公司，负责搭建移动中台，整合在线课堂、提升教学质量、减少运维工单。在此过程中，我留意到一个常见现象：开发团队普遍更青睐做新功能，却不太愿意维护老功能。尤其在面对大量工单时，排查问题成为大家都不愿碰却不得不做的“苦活”。

在软件工程领域，零 Bug 几乎是不可能的，但可以尽量缩短排查和解决 Bug 的时间。基于这一点，我为自己设定了非常明确的目标：打造一款 AI-First Coder，不仅能高效开发需求代码，更能做到：

• 1 分钟内定位问题

• 5 分钟内解决问题

• 10 分钟内完成上线

于是，我的 5 年探索之旅就此正式展开。

现在

题外话

如今，很多 AI 工具声称能够自动排查并解决问题。可作为一名拥有 12 年开发经验的“老鸟”，我不得不说，这样的宣传未免过于夸张。软件中的 Bug 大多属于“运行时错误”，其中 99% 的情况又是非崩溃类型，问题往往并不直观，需要花费大量时间逐层排查。市面上的 AI 工具所能快速修复的，通常只占不到 1% 的简单错误，却被放大宣传。

举个例子：我之所以入职那家在线教育公司，就是因为他们的课件系统出现了一个长期无法解决的 Bug，导致工单激增，持续半年都无人能搞定。结果我入职后也花了整整一周才定位到问题根源：A 广告业务使用的 WebView 在暂停时会停止全局的 H5 JS 文件加载，如果没有切回 A 业务进行恢复，那么 B、C、D、F 等其他业务的 WebView 也会失去 JS 文件加载能力。更复杂的是，A 广告业务还采用了低代码工具搭建。这种交叉耦合的问题需要通晓 Web、Android、iOS 等多端技术，并通过梳理出多个业务流程的鲁棒图进行对比，才能最终查明。若仅凭静态检查或一般的 AI 工具就能解决，那类似 FindBugs 之类的工具早就实现了这点。可见目前一些所谓“AI 解决方案”更多是在忽悠缺乏经验的程序员或投资人。直到真正成熟的 AI Coding 工具出现前，我只希望自己乘坐的飞机、汽车或使用的任何系统，不是随意由人盲信这些半成品 AI 工具生成的。哪怕只有万分之一的概率崩溃，也足以令人担忧。

若借用智能驾驶的分级来类比 AI Coding 工具，判断是否达到了 L3+ 的标准其实很简单：在自动驾驶领域，凡是宣称达到 L3 或以上水平，一旦出现事故，提供该系统的企业就必须承担责任。对应到软件行业，若阿里云的云服务出现问题导致客户损失，阿里云也必须负责。那么，那些号称能“自动编程”的 AI 工具，如果真达到了 L3+，自然应该对它们所生成代码引发的损失承担责任；若不敢承诺，这些工具只能算是 L1/L2 级的辅助开发。

而我想做的，正是能够达到 L3+ 的 AI 编程工具，并且坚信在未来 18 个月里，MortiseAI 一定会给出明确的承诺。