网易云音乐前 CTO 曹偲：代码越来越不重要，好的架构才是软件工程核心|uml|代码|深度思考按钮|知名企业|翻译|软件工程

网易云音乐前 CTO 曹偲做了一款 AI Coding 产品 Toco AI。虽然是 Coding 产品，但他们想解决的问题不太一样。

在他看来，「单纯的代码能力的提升不能解决领域内所有问题」。他们想把确定性和工程性带入 AI Coding。

在 AI 程序员之外，他们专门打造了一个 AI 架构师，用来解决软件工程的架构和可维护的难题。

「写代码本身不会带来任何社会价值，只有代码写得好、容易维护，才能带来社会价值。」

AI Coding 和工程的结合已经逐渐成为行业内的共识。

什么是 AI 架构师，Toco AI 又打算如何解决软件架构和复杂性的问题？

在 Toco AI 产品开始内测前，我们跟曹偲聊了聊他的这次创业，以及对于 Coding 赛道的思考。

以下是 Founder Park 与 Toco AI 创始人曹偲的对话，经编辑整理。

Toco AI 官网：https://tocoai.cn/

采访 | 万户

编辑 | 夏天

⬆️关注 Founder Park，最及时最干货的创业分享

超 19000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。

邀请从业者、开发人员和创业者，飞书扫码加群：

进群后，你有机会得到：

最新、最值得关注的 AI 新品资讯；
不定期赠送热门新品的邀请码、会员码；
最精准的 AI 产品曝光渠道

01把确定性和工程性带入 Vibe Coding

Founder Park：为什么会选择切入 coding 赛道？这个赛道已经很卷了。

曹偲：我做了差不多 10 年的 CTO，团队也从 7 个人带到了 700 个人。在 2016 年，我们团队从 20 个人扩张到 70 个人的时候，我的身份也从技术经理向一个真正的技术管理者转变。那时候我发现管理的抓手很少，我不可能去看所有人的代码，团队也分了很多组，怎么去协调和管理？当时有几个点对我的技术管理理念影响很大。

第一，我认为架构决定了软件开发的上下限而不仅是代码。所以云音乐很早就有架构师委员会这样的虚拟组织。

第二，一定要工具化，而不能只停留在口号上。现在很多架构理论或者最佳实践，还都停留在文字层面，比如写一些文档。但文章每个人的理解不一样，执行也不一样，这是没有意义的。如果有最佳实践，我们一定要把它工具化。比如说 DDD，非常好的理论，前段时间也看到很多和它结合的 AI Coding 实践，但问题在于这些实践的落地往往都是经验而非固化的程序，实践中就会出现偏差、落地等一系列问题。

在 22 年的时候，我们在网易内部讨论未来的技术发展，有同事就跟我说 GPT-3 特别强。当时我们就觉得 AI 时代的到来，很有可能会对整个研发体系造成非线性变化。如果 AI 继续往前走，人与程序之间的交流，其抽象程度会变得越来越高，这也是大家一直想做的事。最早是打孔带，后来是汇编，再到编程语言。

但认真想，编程语言也往往不是描述业务的最好方式，比如，描述一个歌单要分页，人类说话可能就几句，但在代码里就很复杂：要去取数、拼装数据、如何设置分页参数、如何获取下一页、格式怎么定义……是一大堆分散在各种代码里的东西去描述一个抽象的概念。那么 AI 时代的到来，有没有可能让软件研发的范式发生根本性的变化，从对代码的关注大量转移到对架构的抽象上来。

这几个点结合起来，在网易云音乐上市之后，我们选择个人发展路径时，就会去考虑 AI 时代如何更好地做研发这件事。

Founder Park：你们的产品主要是解决什么问题的？

曹偲：Cursor 算是一个概率性、freestyle 的工具。这类工具确实有它适用的好场景，适应面更广。但是，软件研发本质上是一个工程。工程就需要确定性、需要工程化的东西，而工程化就包含了规范、约束和严谨。我们希望把这些严谨性、确定性带到 AI Coding 里面来。

这是我们很明确的差异点。

我们把建模方法论和建模工具引入 AI Coding 就是为了把确定性和工程性带入软件研发。而且也不会大幅提升使用成本，因为我们还是个端到端的工具，不是单纯的建模工具。单纯的建模工具不能交付产品，但因为有了 AI，你的建模工具就可以完整地交付整个需求。

Founder Park：和 Vibe Coding 类似，架构问题，如果是初学者用户，没有太多了解，会不会存在 AI 给出的东西，他没法判断好坏的问题？

曹偲：虽然我们把架构都归结为很高大上的东西，但严格来说，架构分两个方向：技术架构。技术架构可以被内化到引擎里，由 AI 辅助解决很多事情，这个大家不太需要关心。特别对于一群中小微企业来说，他们对性能这些东西的考量的场景并不多，也不需要超出他的范围去理解技术架构。

而业务架构，最熟的反而是产品经理和了解业务的人，不完全是程序员。这部分东西，经过 AI 和我们产品的解释，反而更容易理解了。

初学者只是需要一定的时间去理解，因为任何一个时代的工程工具使用都不可能是完全无门槛的。就像在移动互联网时代，很多产品经理也需要学点 SQL 一样，那你最起码得看懂建模这件事。它是一种异化的表达，不可能说因为有了 AI，你就什么都不用学了，这个逻辑是不成立的。

架构本身就是对业务的抽象方法而已，并不代表它是一个高大上的东西。提架构，并不是说我们觉得门槛高，把架构普世化、平民化、内嵌化，才是最重要的事情。

Founder Park：有点类似于很多笔记软件，一开始就强调它自己有一套做笔记的思路，这个思路本身才是重要的。

曹偲：对。我们更多的是启发你。经验足的人，他有自己的发挥空间；经验不足的人，用我们的产品最起码能得到一个合理的、能把思路抽取出来的过程。

架构和可维护性是软件的必备特质

Founder Park：举一个典型的客户案例场景？

曹偲：一类是小型的 SMB 企业，需要做有长期规划的业务。比如它做自己的电商管理系统，但它可能没有能力引入一位核心架构师，用我们的产品就等于内嵌了一个架构师，可以用业内比较好的最佳实践，从头到尾构建一个良好架构的电商系统。但如果他全程用 Cursor 自己去探索，很多人如果完全对架构不熟，做出来的东西在我们看来其实并不是一个真正的软件，只是一个功能的实现。

第二类就有点违反大家的直觉，就是在很多中大型系统，现在 AI Coding 的落地其实并不好。他们也可以用 Toco 来逐步地去重构或构建新的模块。

早些年我在云音乐架构治理时，整个 CI/CD 和架构里其实没有原始的一手数据。研发过程是缺少数字化的，除了代码和不准确的需求，大量信息都是丢失的，基本上用户的 CI/CD 流程很难完全自动化。而 Toco 这种以架构驱动的平台，某种程度上说，想做的就是帮助研发过程本身做到数字化管理。

所以，最典型的两个客户，对于 SMB，内嵌了一个架构师；对于中大型系统，它是一个很好的工具，可以维护你的架构不被劣化，同时协助团队持续协作。

Founder Park：你们和 Cursor、Claude Code 的区别是？

曹偲：产品的更大区别在于视角和解决的场景不同。

我们更多是在探索一条软件工程的端对端实现，于是找到一条可以建模的垂直赛道来做这件事。但就目前来看，服务端有标准化的建模，其他的研发领域，比如算法或者 iOS 开发，还没有一套非常标准化的建模方法，所以在该垂直领域我们把行业里的最好理论和我们的最佳实践都固化下来做了一个建模驱动的端对端研发工具。

在该赛道里，我认为我们是更优的解决方案，一个更高维度的产品。Claude Code 和 Cursor 更关注的是具体的代码实现，当然也可以用人来组织上层架构，但那不是原生的，而且每个人的理解会有偏差，也并非最佳实践。我们把团队优秀的最佳实践与行业公认的理念相结合，做到了端到端交付。

Founder Park：架构做完之后，后续写具体模块的时候，可以不用 Toco，切换到 Cursor 来写吗？

曹偲：你可以随时用其他产品来维护这个项目，但如果想一直获得 Toco 提供的架构和代码一致带来的便利，就需要一直使用 Toco。而且我们的产品本身也是端对端的，在编码的 AI 实现上，效果是和其他产品齐平，甚至由于有设计作为更好的上下文，会表现得更好。

你可以从 Toco 迁移到 Cursor，但很难再从 Cursor 迁移回 Toco。因为好的架构一定是有约束的。最好是彼此有一个约定，遵循社区的约定。

Founder Park：现阶段产品的核心用户群会是一群什么样的人？

曹偲：可以把视野拉长一点看。

我们团队想做的，是成为像 Spring 之于 Java，K8s 之于运维那样的东西。作为行业最早关注 AI Coding 中抽象落地的团队，希望去引领抽象层的定义。想想 K8s，原来的运维不是那样运维机器的，而是用各种命令，很随意，那时候运维也不是工程化的。Spring 之前的 Java，你用 Struts 也好，自己写框架也好，很多东西都不统一。我们最终是想成为 AI Coding 在软件开发中的抽象层，这是我们更长远的目标。

所以，我们真正面向的用户会是做这一类研发的所有开发者。但是前期，更能理解我们的人，我相信是一些资深开发者。因为他们对这个感触更痛。

Founder Park：理论上，只要是参与或创造一个复杂软件工程的开发者，未来都是这个软件的目标用户。

曹偲：对，再补充一点，这里面还有一个很违反常识的东西，就是没有严格意义上的复杂软件和简单软件。只要软件一直在用，它一定会变得非常复杂。哪怕做一个会议室管理系统，一开始建两个表、写两个接口就行。但只要它一直被用，就会多出很多东西，比如议程管理，然后议程会有取消，取消之后又会引发很多其他事情。

一个软件只要被反复使用，特别是业务软件，它就会越变越复杂。所以我们觉得，良好的架构并不是只为大型软件准备的，它是一个软件本身应该必备的东西。只是需要有手段让更多的软件具备低门槛、低成本的好架构。

或者可以这么理解，所谓的架构，就是对业务逻辑一个更合理的还原。从这个角度看，就不应该特意去区分大型和小型软件。只是说，大型软件不这么做一定会死，而小型软件还可以通过「搭飞线」的方式撑到它变大为止。问题就在于此，并不是说小软件就完全可以不重视架构。

Founder Park：也就是说，软件本身就代表着要有架构、有可维护性这个特质。

曹偲：对，除非是一些生命周期很短的软件，就可以不用关心。比如我就用一次，或者它是个脚本。为什么脚本从来不提架构？因为脚本的生命周期往往很短，而且它的工作场景不会发生剧烈变化。但业务系统只要被长期使用，它的工作环境就一定会变化，就一定会有很多变革出来。

Founder Park：在你们目前的内测场景里，最能体现你们产品能力的，有没有一些特别的场景或者行业？

曹偲：它目前最擅长的肯定是业务系统的服务端。当然，我们后续也会去延展，去做前端或者 BI 这一侧的解决方案。按照自动驾驶来类比的话，Toco 是一个封闭赛道的 L4，解决某类问题从架构开始的更高维度落地，而 Cursor 可能是一个全场景的 L3，它不会关心到某一个具体场景的更高程度抽象。

我们不会和某个具体行业或场景绑定，我们能支持的能力在各行业中都有存在。

写代码不会带来价值，交付产品才能带来价值

Founder Park：Toco 也提供 AI Coding 的能力，和 Cursor、Claude Code 相比，会有能力上的差别吗？

曹偲：无论是 Claude、Cursor 还是我们，基础的编码能力都来源于大模型本身，这点是对齐的。大模型也会出现错误的代码，这也是我们为什么希望把更多的确定性带到软件开发里来的一个很大原因。而且我理解软件开发这件事，不是给每个人提供一个扳手就解决问题，这是 Cursor 类产品的核心场景，但真正的现代化是生产线的现代化，我们不仅要把目光放在顶级大牛和一些新入者的反馈上，这在研发群体里面并不是多数。更应该考虑新的革命到来的时候，整个社会有没有更进一步用好工具的空间。

Founder Park：有扳手不代表生产力就进入了现代化流程。生产力进步的核心在于有了一个大型的、现代化的流水线作业，这才是提效的根本。

曹偲：我的理解是这样的。2025 年可以说是 AI Coding 最火的一年。AI Coding 是一个非常伟大的范式变化，大家也看到了一些很 fancy 的机会，但是，2025 年写的这些代码，到 2026 年就要去改、去维护，甚至线上会出现 bug。那明年就会有更多的声音提出来，如何让 AI Coding 更好地在软件里应用？

因为它是个工具，我们不能把它当成棒棒糖。写代码本身不会带来任何社会价值，使用工具的愉悦只是第一步，只有代码写得好、容易维护，才能带来社会价值。大家的兴奋感会逐渐从写代码时的兴奋，转变为如何让这个东西可持续地为写代码这件事提供长期价值。我们会发现，像谷歌、Netflix 的工程主管，或者 Martin Fowler，都在提 AI Coding 和软件工程的结合。虽然每个人的思路可能有点区别，但这个大方向不会变。

假设你是最终的消费者，是来吃拉面的，你绝对不只是希望厨师做饭的时候很开心、很兴奋，更关注的是拉面好吃管饱，希望他很严谨地做这件事。我们最终服务的是吃拉面的人，这是 AI 的本质问题，最终也要让吃拉面的人很开心。软件本身是追求确定性的，酷炫的东西不应该是软件的制作过程，而应该是软件工程带来的长远变化。

Founder Park：这是否意味着，今年行业内会更加意识到，代码本身可能正变成软件工程里最不重要的那部分？因为 AI 已经能帮我们写代码了。反倒是代码之上的东西，比如架构，开始变得越来越重要了。

曹偲：我越来越觉得一些模式化的代码将越来越不重要。Java 也好，Go 也好，Python 也好，其实都是在表达同样的问题，学习门槛也很低，可以快速抹平。

但架构、特别是业务架构为什么这么重要？架构其实是我们对现有真实世界的理解，甚至还要加上预测性的理解。因为很多软件的维护性和考量点在于它的扩展性，而所谓的扩展性就是对未来的一个预判。比如，这个会议会不会变成一个很大的会议？还是一直都是三个人开会？这里面的性能要求是不一样的，设计也会不同。

我不认为 AI 在这里起主导因素，它可以起辅助作用，告诉你有哪些选项，但真正了解业务本身的一定是人，而不是 AI。所以我认为，以后用什么语言和框架表达都会越来越不重要。越来越重要的是对业务的描述、理解，甚至是长期的规划。

原来你会很关心机器是怎么运作的，后来你关心 if-else，也就是逻辑是怎么运作的。最后，你会不太关心逻辑怎么运作，而更关心业务是怎么运作的。这是 AI 带来的范式性变化。

Founder Park：2025 年的 AI 已经能够解决写代码的事情了，能力上升之后，解决不了做架构的事吗？

曹偲：我觉得不是说它不能做，而是主导者一定还是人。举个例子，AI 能了解医院大概是怎么运作的，但它能了解这个医院是怎么运作的吗？它没法了解。它能预测这个医院以后想要怎么样吗？它也没法预测。

技术架构会随着我们和 AI 的能力继续黑盒化，但业务架构其实就是精准还原现实, 是很难被 AI 取代的, 这将是 AI 最后一块可以完全接管的领域。

Founder Park：现实世界的逻辑没有那么简单。

曹偲：真实世界不是线性的，你想，网易云音乐跟 QQ 音乐都是音乐产品，它的理念一样吗？不一样。我能不能卖一个工具，说网易云音乐和 QQ 音乐都用一套工具去解决？不行，它们的曲库管理都不一样，哪怕最标准化的东西逻辑都不太一样。

Founder Park：也就是说，今天的 AI 可能已经能够解决所谓的技术架构问题了，但是对于业务逻辑和整个产品的业务架构，这是一个很复杂、跟当下的产品策略、团队目标、甚至现实环境都强关联的东西。简单来说，在未来的几年内，AI 没有办法获取到足够多的上下文来理解这些，最终的决策权核心还是在人类手里。

曹偲：对，我觉得方向盘永远都在人的手上，但是刹车、油门这些很有可能交给 AI。因为有些东西它的控制变量比较少，只要判断会不会撞上东西，就可以控制刹车。但是我想去哪里，这个事情在大多数软件研发中可能永远都得我自己说了算。

Founder Park：其他的软件是不是也可以解决技术架构的难题？

曹偲：并不是只有我们解决技术架构。我们是一个架构工具，把架构的流程嵌入进来。我们绝对不敢妄称只有我们关心架构，其他人就不关心。Cursor 当然也能做架构，但它的随意性很强，也不是最佳实践。如果你是个非常资深的人，可以自己去控制，那当然很好。但如果你对这块本身就不熟，你也无法评判好坏，就有可能自己跟 AI 一起掉到沟里去。它也是非约束性的，它描述的东西会产生漂移, 代码会和架构不一致。

对 AI 抱有敬畏之心，才有可能用得更好

Founder Park：很好奇，为什么大家会突然觉得写代码是一件很酷、很爽的事？就像做饭、写文章一样，很少有人吹嘘过程很爽。这种说法在编程行业里以前就有，还是因为 AI 才出现的？

曹偲：虽然我们都自嘲是「码农」，但这不完全是现实。

首先，编程行业让大家更为兴奋的一个原因，是因为它是通往数字世界必不可少的钥匙。它本身就是一件改变世界的事，所以大家很容易兴奋，而且这是一个增量市场。特别是像大模型出来的时候，因为大模型本身也是程序。

其次，虽然我们自嘲是码农，但相对来说我们还是一些高知群体，这些人有很多自我价值实现的诉求。所以会去寻找编程带来的快乐，但这和约束其实并不矛盾。今天有人会去把 C 的编译器重新写一遍吗？没有的。大家会更关心更高层的快乐，比如我如何组织我的业务。原来我很多精力都关注在我的汇编里这个顺序换一下就能提升一倍效率，所有注意力都在那上面。今天也是一样，在这个转型期，一定还有人说，我不要这样写代码，怎么爽怎么来。

研发圈有个很经典的段子，大家为换行前面到底是 Tab 还是四个空格吵了那么久。但如果有一天代码完全不是你写的，如果 AI 写成了四个空格，你还强行用 prompt 去约束它一定是 Tab 吗？没有必要。在这个范式变化中我们就会理解，如果可以把架构、把很多东西固化到软件里交给 AI，我们就可以更多地关心业务的走向，这才是更难的。比如，这套医院系统可不可以支撑更好的医患体验？银行系统是不是可以满足更好的金融管理需求？

人的关注点也是在不断变化的，只是在这个转变过程中，未必那么多人会第一时间反应过来，他可能还会关心，我的汇编是不是比别人写得好一点，哈哈。

Founder Park：今年这一波 coding 产品出现，大家在讨论程序员会不会被取代，其实他可能不是真的被取代，而是这一波技术在进步引导大家，不应该把精力关注在怎么写出更漂亮的代码上，而是要往前走，去关注怎么做出好的架构，或者说在 AI 的辅助下，把人的能力放在更适合人做的事情上。

曹偲：是的。你想想看，我们作为程序员，一天手动能写 400 多行代码。而且很多时候都是在惯性编程。特别是像我们这些做架构、做程序很久的人，很多时候从想好一件事到实现，中间有很长的时间都是在写代码。AI 来了之后这个过程就会变成，我想好了，执行速度会非常非常快。

我认为这是范式性变化。中间会不会造成一些失业？这是个社会转型的问题。人在他所有的智能被其他东西取代之前，人所做的事情一定是越来越抽象，越来越满足自己高层次的需求，关注「what」而不是「how」，这是一个大的发展趋势。至于过程中产生的社会问题，或者对人的技能要求变化，这是由整个社会去决定的。

Founder Park：确实。现在所有行业都会面临这样的问题，我们这种写文章的也会担心，AI 都可以直接写文章了。

曹偲：对，所有行业，不光是编程。相信你们行业感受应该更深。我有很多新闻系的同学和好朋友，他们会觉得新闻学已经完全被 AI 和移动互联网颠覆得面目全非了。但是你会发现，它只是换了一些要求而已，依然还是有些人做得很好，有些人做得不太好，并不是有了 AI 大家都可以变成一个水平。只是说，它没有那么多科班要求了，它更要求你去挖掘一些别人挖掘不到的点。这个逻辑，我感觉今时今日的 AI 还没有这个能力。

Founder Park：对于「写」本身的要求会降低，但是对于你要「表达什么」这件事，回到了人类更主动的事情上，这和架构有点类似。

曹偲：对。而且时至今日，AI 还有很多东西不是很严谨。如果你是一个盲目的 AI 信奉者，最起码在很长一段时间内，并不会做得比别人更好。反而是你对 AI 抱有敬畏之心去使用它的时候，才有可能做得比别人更好。绝对不是说，我比别人更相信 AI，所以我会用得更好。

可能不会再有新的编程语言了，但没有影响

Founder Park：如果 AI 再发展，代码语言之争，或者技术栈之争还会有吗？

曹偲：很明显，语言和技术栈会慢慢地消亡掉。消亡不是说它没了，而是会慢慢地黑盒化。当然这个过程可能会比想象中要久一点。

开发到底是用 Go、Python 还是 Java？其实这不只是语言的问题，而是背后一套生态体系的问题。这也是在变化的，但并不是说一瞬间大家就不关心了，这做不到。我们不需要把社会的演进看成是一个今天有个新技术，明天就全变了的过程。但是从长远来看，用 Java 写还是用 Go 写，其实都不是最核心的，它只是一种实现而已。

Founder Park：如果一个行业没有新语言诞生，会有影响吗？

曹偲：我认为不会有影响。语言已经基本上图灵完备了，除非是计算科学的底层发生变化，比如量子计算出现。目前，描述事情的方式没有很大的问题，有问题的是如何组织和维护这个东西，以及如何去表达业务甚至是算法的抽象，那是数学和逻辑学的问题，是人要去突破的。

描述本身不存在太大的瓶颈，只是说描述效率高低、有类型还是无类型的问题。今时今日，这些的确还很重要，比如你用 TypeScript 还是 JavaScript，用有类型的 Python 还是无类型的 Python，因为它牵涉到维护性。但长远来说，这些东西也会被慢慢地黑盒化。

Founder Park：那会不会在 AI 足够强之后，效率高低的问题也变得不重要了？

曹偲：我的观点可能会有一点差异。我觉得「黑盒化」这件事代表着大家已经找到了公约的最优解，而不是说它不重要会去用一个你以前认为不好的方式。就像汇编器不断迭代，它生成的汇编我不敢说比人精心优化的要好，但基本上已经是到 95 分位的东西了。

黑盒反而意味着大家是会归一的，而不是发散的。我们认为，只要到了这个场景，它就是这个最佳实践。这反倒说明了上层抽象定义是更迫切的问题。

Founder Park：技术架构这个东西，存在所谓的创新或者范式大迭代吗？

曹偲：没有银弹型的技术架构，这是一个事实。包括我们提到的 DDD、CQRS 也好，它更多的是起到规范作用，让你更好维护，但并不代表用了这些你就不需要重构了，或者再也不会写垃圾代码了，这是不存在的。

我们可以看两种东西，一种是算法，描述一个固定的输入输出，它一定会有个最优解，到那里就停掉了。但业务系统其实一直在描述我们日常生活的变化，只要人的社会行为发生变化，业务系统本身就一定会变化，所以它的复杂性是动态的。它不是一个有最终最优解的问题，可能是一个有局部最优解的问题。而今年的局部最优解，和你业务发生巨大调整之后的局部最优解肯定不一样，所以才需要重构。

但是，盲目地重构，没有任何工具，比如没有像 Toco 这样的架构工具，很有可能你抱着满腔热情干了一个月之后发现，还不如不改。没有任何目的性，也没有一个更好的工具能让它重构之后变得更规整，并长时间保持这种规整，腐化的速度会很快，因为你没有遵循一些最佳范式。

回到刚才的问题，技术架构这个东西有没有继续往前走？宏观上我们有局部最优解，微观上他也在不断迭代。DDD 这个理论，已经是目前最好的理论之一了，但它其实是在 2000 年之前提出的，只是大家的实践和落地花了很多时间。软件的复杂性来源于逻辑的复杂性，这部分东西不可能被一个单纯的架构解决。

稍微总结一下。首先，我们的架构最佳范式，基本上已经很长时间没有发生过本质性变化了，这代表着它最起码进入了相当长一段时间的最优解。但是，我们在实践的过程中会碰到现实问题和执行力度的问题。有最佳实践，但我没有一个好的工具，理论是 A，我做出来的就是 A'，甚至是 A'''。这是我们更容易碰到的问题，理论本身在短时间内认为它就是最优解了。很多年了，行业里面没有比它更好的，只有一些修补，没有本质性的理论演进。

但是问题就在于，DDD 这类理论的落地都很差。架构落地的最大的问题是，在缺乏工具支撑时，所谓越好的理论越落地不了。因为所谓的好架构都是用更多的代码去实现逻辑的隔离。如果去问很多架构师，他知道 DDD 吗？他知道。但你说要去实践 DDD 吗？他一定是抱着怀疑态度去做这件事，因为没有工具，实践难度会比较大。我们的工具其实就是为了去解决或缓解这种问题。

不担心竞争，希望大家一起来做大市场

Founder Park：因为在 AI 辅助下做架构，需不需要 Agent 对行业有更专业的知识，比如需要一些数据去训练它，让它更了解这些场景？

曹偲：我觉得要看长短期。

短期内，我们不要求 AI 的架构能做到满分，这不现实。但它做到 80 分的水平其实不太需要额外的数据，现有的知识就够了。但长远来说，我们当然也希望产品发展的时候，会有更多累积的行业数据或者协同发展，让它更容易做到 90 分。

目前的基准线就是 AI 给你出一个 80 分的东西，由人来控制和修改。如果以后想更加自动化，达到真正的 L4，那肯定还是要有行业积累的支持。但我觉得这应该不在大家 2026 年的规划里，AI Coding 自身还没成熟呢，在基础还没夯实之前，暂时不需要去考虑更下一步的问题了。

Founder Park：你们的产品会有数据飞轮吗？

曹偲：肯定会有的。

首先，我们今天做这个东西，实质上还有一些技术问题。使用建模工具时，prompt 会比较长，需要教会 AI 使用工具。会通过后训练、私有数据或者私有小模型来做。它会让产品的内核变得越来越易用，现在可能是 80 分，以后可能可以做到 90 分。只是我们团队目前还没有专注在这一块。

其次，如果底层基础越来越夯实，从需求到完成研发的自闭环做得越来越好，那么往行业纵深发展就是一个终极命题。比如，银行行业的东西能不能更快速地出来？这就带来了更高层级的抽象。

其实，大家的逻辑思路是一致的，就是抽象层级更高了。使用者就像从一个编码人员慢慢到一个总监，再到一个 CTO 或 CIO 的角色。我更多的是关心业务发展方向，然后 AI 就可以开始帮你抽象一些事情。抽象程度越来越高，其实跟人的组织也蛮类似的。CIO 肯定不是很关心某一个需求稿的抽象。一个业务总监关心的肯定不是代码，而是某个具体业务的抽象。再到研发，他们可能关心的是还原到代码的抽象。这其实是一个层层递进的过程，那么 AI 就是帮助你把抽象程度越提越高。

这就是一个数据飞轮发展的方向。

Founder Park：如果今天大厂做一个这样的产品，你们的壁垒是什么？

曹偲：第一，世界上没有绝对的技术壁垒，无论是我们还是大模型本身，都是一个动态滚动的过程。我们绝对不会认为这是一个绝对的技术壁垒，但是它是一个相对的技术壁垒。我认为别人要做这件事情，花个半年、一年的时间还是要的。这个时间优势，就可以去转化成我们的竞争壁垒。

第二，非常非常欢迎所有的大厂来做同样的事情。我们不觉得一家公司去做这件事情是很好的一件事。只有大家一起参与进来，无论是参与我们的方案，还是做自己类似的方案，我觉得这是一件好事情。而且这个市场会足够大。

Founder Park：更像是说，现在需要更多人一起来做这个市场，甚至可以一起把用户教育做好。因为「架构很重要」这个认知，在当下并不是一个很大众的认知。

曹偲：对。只要我们刚才说的那个事实存在，就是在很多研发场景里面，AI Coding 的实际生产采纳率才百分之十几，大家就一定会去寻找新的出路。如何通过抽象去减轻软件表达的复杂度, 只能回到架构和抽象上来。

Founder Park：所以，如果 AI Coding 足够强大，它可能让一些更小众的需求被释放出来。但那些小众需求，最后都不一定需要用软件的方式来解决，可能就是一个复杂的提示词。那个场景更像是因为 AI 能力足够强，让一些即时性的、短期的需求更好被满足了。它不应该再用传统软件的逻辑去看，因为它最终产出的也不是一个需要维护、需要规划的传统软件。

曹偲：很有道理。很多人会问，AI 发展了之后，Coding 是不是会减少？我认为是不会的。

人类社会的数字化发展是一个往前走的过程。只要数字化进展不停，数字化里面的确定性部分存在，我认为 coding 这个事情就会长期存在。只是里面非确定性的表达，例如订哪张机票交给大模型和 agent，而如何扣减机票库存就必须交由 Coding。

用 AI-Native 的方式重做 UML

Founder Park：九十年代后期，当时流行所谓的 UML（统一建模语言），就是用一套很强的复杂系统约束好，代码就变成一个很自动化或者很快就能生成的东西。我直觉上感觉跟 Toco 要做的东西有点相似，它们本质的区别是什么？

曹偲：首先，太阳底下没有新鲜事，任何技术本质上都代表了人的一种思路。UML 这些东西，并不是说它本身思路有问题，而是它那个时代的环境并不太支撑这件事情能落地得非常好。

举个云音乐的例子，云音乐有个叫「歌单」的功能，在云音乐之前，大家可能都是用榜单听歌，所有人听的歌都一样。那歌单为什么在云音乐里这么成功？难道是因为在 PC 时代，十几年来没有人想过做歌单吗？不是的，是因为那个环境里没有个性化推荐。没有个性化推荐，歌单会沦为一个比榜单传播效率更差的东西。

所以，想法一直都会有，但是技术环境一直在发生变化。UML 本身所代表的思路，就是对业务理解的一个更高程度的抽象，我不认为今天有人会否认软件需要抽象。抽象这个事情肯定没有问题。但是在前 AI 时代，首先它的抽象度很难把控。我们今天把 80% 的信息模型化抽象了，20% 不去抽象。在没有 AI 的时代，就很难做这种抉择。要不要全部抽象成 UML？这会把它变成一种新的编程语言，就不太像抽象了。只抽象一半可不可以？那就会面临另一半怎么办，是自己手写吗？就会面临这种两难的抉择。

第二个问题，如果没有任何工具，今天有一个需求变更，到底是先改 UML 还是代码？时间紧，肯定是先改代码。这就导致两边不一致。当然，在一些传统、时间不紧急、要求规则很强的领域，比如在日本，有 60-70% 的时间都在整理 Excel 表格。这种设计驱动开发的事情，哪怕在非 AI 环境下也没有完全被抛弃，它还是有很大价值的。只是说在国内，特别是在一些快节奏的互联网开发里，不太成立。

回过头来说，软件的复杂性是不是需要抽象来解决？我认为这是个本源问题。如果认为需要，在 AI 时代，我们就应该找一个更好的解决方案。本质上来说，我们就是希望在社区和产品里，去找到一条在某个范畴内比较好的描述方法。

假设今天 AI 无限强了，只要人还参与软件开发，最大的问题是什么？是 AI 吗？不是，是人如何跟 AI 通信。人和 AI 的通信带宽要变宽，就一定得找更抽象的东西出来。回过头来看我们之前的 DDD、UML，我们发现这里面的东西并不是全无道理，很多是讲得通的，只是在那个环境里不能很好地发挥出来。就像你在 2005 年的时候去做歌单，你只能一个一个手动分发，而不可能通过机器学习去传播。

Founder Park：当时的技术能力和需求，没办法很好地支撑那样的想法。

曹偲：对。我认为我们去做技术理解的时候，一定要分清楚哪些是本源的东西，哪些是变的东西。UML 也好，AI 也好，Toco 也好，都是在解决问题的一些思路。这就带来了技术的循环兴起和衰落。但我认为抽象是不会衰落的。

Founder Park：是不是可以说，我们在用 AI native 的方式，把 UML 的理念重新变成一个更具可行性的产品解决方案？

曹偲：是这样的。还是那个歌单的例子，AI 对于这个东西而言，就像是一个机器学习的协同过滤算法，它可以让一个很有价值的东西焕发新的生命力。

在 AI 时代，以 UML 为代表的抽象方法论反而会越来越重要。是不是不应该和 AI 去交流 10000 行代码，而是三十个模型。

Founder Park：如果说再过几年，代码这一层会被黑盒化，那再往前走，AI 会把更复杂的东西也黑盒化吗？

曹偲：精准描述问题是必不可少的，从这个角度说，建模不太可能会被黑盒化，因为自然语言有很多天然的问题，它不太适合去精确描述你的系统，除非你对系统的对错不关心。如果要找一个准确性的表达，就得找一个准确性的语言。用一个不准确的语言，又能准确地表达你的需求，这是不太现实的。

除非你的要求就是，做一个会议系统，大概是我想要的就行, 如果你想做某个特定会议的系统，你就会对如何准确表达问题最感兴趣。但这里面其实有很多细节问题。技术的细节，包括增删改查这些，大家都会说非常简单，但其实想做好是很难的。想做好一件事情永远和做一件事情是两回事，你哪怕做一个简单的系统，想做好也不容易。

先成为一家产品公司，再成为行业标准

Founder Park：现阶段先从 Java 切入，纯粹是技术选择吗？

曹偲：因为涉及到建模引擎，所以就会有编程的部分。我们做了编程引擎，这个引擎需要翻译成某种语言，把它翻译成什么呢？我们可能优先去翻译成 Java，因为 Java 的工程化理念跟我们更近。

其次，我们就是先从最头部的开始覆盖，那最多的肯定是 Java。

Founder Park：这样更容易获客，更容易找到要解决的问题？

曹偲：对，我们的思路是这样的。往后延展一下，本质上来说，我们想先成为一个产品公司，再成为一种行业标准公司。Spring、K8s 某种程度上已经代表了一种行业标准。所以我们会去做开源，引擎内核部分，包括建模描述和建模的渲染引擎模板，都会在社区发布出来。当然可能要晚一点，因为我们代码得整理得更 strong 一点才能发布。

我们的思路是，我们也是一种 Spec coding，只是一种更约束化、更专用、更准确的 Spec coding。最终它一定是个开放式的、全支持的，要用 Go 肯定可以用 Go，要用 C# 肯定可以用 C#，而且 AI 会让这个泛化变得更快。

Founder Park：那你们和 Spec Coding 的区别？

曹偲：Spec Coding 跟我们有相似之处，也有不同之处。Spec 某种程度上也是让上下文更约束、更规范、更抽象。但 Spec 有点偏过程式，很难说 Spec 是个设计。怎么保证文档和最终的代码是一个映射关系？Spec 怎么写好？AI 写还是你写？用什么格式写？最终还是得解释这个问题。

当时我们在云音乐做架构师团队，第一个问题就是，架构师应该产出什么样的文档？不是要不要架构，而是每个人的架构写的方法又不太一样。那 Spec Coding 是不是碰到同样的问题？用什么样的方法来写 Spec？是不是需要有一些最佳实践？这最佳实践能不能被沉淀下来，成为一个固化的表达，还是就是自由发挥？

Spec 在用得很好的人手里可能会大放异彩，但在用得不好的人手里可能也就那么回事。

Founder Park：现阶段，它的适用场景是改造一个很大的旧代码库，还是说它更适应开发一个新项目，从架构开始规划？

曹偲：这个问题很重要，甚至会对我们的商业场景有一定限制。在典型的软件工程里，这叫 Greenfield 和 Brownfield。一个是绿地，指被良好规划、重新开始的项目；另一个是指一些陈年的、没有被良好维护的代码。

首先，在 Brownfield 上想做很好的迭代更新，其实逻辑上不成立，不是说 AI 变强了就一定能做好。大型系统，连人都很难维护。人很多时候解决这个问题都是在旁边再开一条支路，不影响原来的东西，重新写一个逻辑。我们听过最离谱的线上事故，是把两行不相关的代码顺序换了一下，然后线上直接出了 P1 事故。这件事不是 AI 的问题，也不是人的问题，是由它逻辑结构的混乱性造成的，这是个本源问题。

很多 CTO 反馈的 AI Coding 只有百分之十几的代码采用率，其实可以印证这件事。特别是在大型系统里面，长时间对架构的腐化、管理信息的丢失造成了这些问题。

所以我们认为，Toco 比较适合做 Greenfield 的项目，一开始会有一些限制。

但是，持续使用的软件，本身就需要新建，或者需要一定的重构。因为业务系统在变化，它的最优解也在不断变化。如果你是毫无目的地重构，很有可能就是撸起袖子来又掉到同样的坑里去。如果你的 Brownfield，可以逐步地剥离一些常常需要变更、维护且比较重要的模块出来，重构到新的、设计良好、被良好维护的体系上去，我们可以把它假设为「最后一次重构」——当然这个「最后」要打引号，绝对不是说以后不用重构了，而是说它的重构模式可以迁移到这种设计驱动的模式上来，那它的可理解性、可维护性就会高一个很大的档次。

从长远来说，如果 Toco 在新建和重构中有了行业共识，反而对我们的商业化空间有更大的想象力，这就比修修补补的工具有更大的市场空间。

Founder Park：也就是说，有了 Toco，反倒让一些以前可能没办法，只能修修补补的系统，可以真正实现大家想要的重构。

曹偲：对。这就看技术决策者，是想一直陷在泥泞之中，还是要做自身研发的数字化转型和 AI 化转型。否则，10% 的采用率，不会因为基础模型的变化变成 30%、40%，它可能就永远在那个水平了。无论有没有 Toco，这都不是一个可以直接解决的问题。Toco 来了，会给你一个新范式，让你的东西变成一个组织良好、更容易被抽象、理解和维护的东西。从短时间来看我们受到了限制，但从长时间来看，这是一个新的潮流。

回过头来看，为什么 2015 年到 2020 年，大家要去做微服务拆分？且不谈微服务是不是一定必要，大家花了那么多钱和精力去做，最起码是认为架构上应该往这个方向演进。这个东西长期来看，对我们的价值是放大的，而不是变小的。大家会发现，还有很多存量的东西也需要用 Toco 来做，而不是一个 Cursor 就能解决所有问题。

Founder Park：这反倒是你们的一个优势。Cursor 可能只是用来写新代码，但你们能把过去解决不了的重构问题给解决了。

曹偲：对，Toco 会帮你把规整这件事情做得更好。随着我们商业化的进展，后面可能会去推一些重构模式。我认为它长远带来的想象空间其实反而是更大的。前期我们可能更多地去找一些志同道合的人，在一些新建场景或者新建模块上使用。但如果是在老模块上去改个 if-else，用谁都一样，哈哈。

当我们逐渐成为一种行业标准或行业共识之后，大家就会发现，AI 时代需要 Toco 来管理我的系统，而不是可有可无的。如果大家都停留在老代码上面，那 Cursor 跟我们之间不会有太大区别，采用率就一定还维持在 10% 多。

Founder Park：你们能支持的系统架构，比如在复杂程度上，有量化的分级吗？比如能处理多少万行代码，或者多复杂的系统？

曹偲：如果用它来完全重构云音乐，是绝对没有任何问题的。

云音乐的复杂程度，我不敢说是 top 0.01%，但是 top 0.1% 绝对有。我们当年开发人员近千人，而且做了十几年，你可以想象它的复杂程度。

它没有一个绝对的复杂度瓶颈。做个很小的会议室管理系统，一张表也可以用；做云音乐，几千张表也可以用，这个绝对不是它的瓶颈。只是说，它做复杂系统的时候，还要进一步的改良和优化，这个是肯定要做的。我们会在不断的实践中，去适应各类场景。我们已经有比较复杂的合作厂商，只是目前还不方便透露，大概是对应到上市公司级别的这种软件研发项目。

Cowork 很牛，但可能并不复杂

Founder Park：怎么看待 Anthropic 说他们用 Claude Code 十天写出了 Cowork？

曹偲：首先，Cursor 和 Claude Code 一定是很牛的东西。我们并没有否认说用它们做不出优秀架构或好产品。我们只是说，在大众的协作活动中，你一定要考虑到使用人的协作水平、规模、环境。这样就会需要一个更合理的工具。AI 是一个放大器，如果使用者本身就很牛，他做出来一个很强的东西，从来没有人否认过这个观点。

其次，Cowork 本身可能也不是一个特别复杂的东西，可能不会比 Toco 复杂。它牛归牛，但复杂和牛是两件事情。

Founder Park：对，应该没有特别复杂，我感觉是基于 Claude Code，加了很多交互层面的东西。

曹偲：现在整个社区的声音有点分裂。比如前段时间 Redis 的作者说以后不需要写代码，然后网友的评论是：「我们用的是同一款 AI 吗？」哈哈。我不敢说谁说的是假话，很有可能大家说的都是真话。

只是，需不需要一个更适合拉齐大家水平的工具？有没有一些东西可以继续往前走，而不是永远停留在这种分歧上面？如果工具层面没有任何变化，这种分歧会不会永远存在？这不就是工程要解决的问题吗？把大家的水平拉齐。工程就是在原型完成之后，完成工业化生产的过程。

Founder Park：在 AI 时代做产品，和你们以前做产品，体感上有什么区别吗？

曹偲：首先，AI 时代做产品会更快，这个没有必要掩盖。当年可能要引入视觉、交互等很多角色，现在如果只是做一些原型创意，很多职位都被取代了。

其次，我觉得万变不离其宗。现在是 AI 应用的第一年、第二年，其实跟互联网的第一年一样，很多东西都在不断碰撞和证伪。现在的成功，无论是什么意义的成功，我都很难把它标记为是一个真正的成功。

在能够成为一个真正的 business，有稳定的用户留存之前，很难把它定义为一个真正成功的产品。可以把它定义为一个很成功的创业，但很难定义为一个很成功的产品。

ToB 看影响力，ToC 看留存，这个总是不会错的。如果不能满足这些，只是讲了一个故事，我认为它是个短暂的东西，或者只是个成功的生意，而不是成功的产品。

为什么会这么难？原来在移动互联网时代，大家是在平地上建楼，操作系统厂商和应用厂商的分工很明确。今天我们是在沙地上建楼，会面临基础模型如何变化、应用的边界在哪里等问题。在流沙上建东西，你既可能陷下去，也可能被扶起来，也可能因为一阵风被吹得很高，但实质上它可能只是一阵风而已。

Founder Park：模型能力会成为你们产品的一个卡点吗？

曹偲：不敢说卡点，但肯定是一个制约点。今天所有的 agent，在真正解决复杂问题的时候还是有不足之处的，这是肯定的。但并不代表影响它的使用。如果模型变得更好一点，上下文的注意力更集中一点，肯定会带来更好的用户体验。