专题演讲嘉宾:曹偲

Toco 创始人、CEO,前网易云音乐CTO

15 岁进入浙江大学计算机系,毕业后加入网易,2012-2022 年,作为核心创始人、CTO 参与网易云音乐从初创到上市,离职网易云音乐后创办 Toco,致力于打造新一代端到端 AI Coding 工具,是超大型产品&研发体系全生命周期主导者,拥有领导从 7 人到千人技术团队,网易云音乐第一行代码到两亿月活用户的完整技术管理经历;是产品创新实践者,曾同时负责网易云音乐产品策划团队,打造了深受用户喜爱的“一起听”等功能。

by 曹偲

Toco 创始人、CEO,前网易云音乐CTO

当前 AI Coding 工具在复杂系统中面临“结构不可控、上下文幻觉、资产难维护”的落地困境,代码采用率往往不足 10%。本演讲我将分享 Toco AI 探索的 “建模驱动开发 (MDD) + LLM” 新范式,深入剖析如何构建 “AI 架构师 (Agent) + 确定性引擎 (Engine)” 的双核架构:通过 DSL 定义领域模型与读写方案,利用 LLM 进行意图理解与胶水代码生成,再由引擎自动渲染 80% 的 DDD/CQRS 结构化代码,内容涵盖解决 “模型与代码一致性”、“非侵入式 DSL 设计” 及 “存量系统渐进式重构” 的技术细节与踩坑经验。

演讲提纲

1. 痛点:为什么 Chat-to-Code 在复杂系统中失效?

  • 现象: “Vibe Coding” 的繁荣与企业级落地的“ 10% 采用率”悖论
  • 根因分析
    • 熵增效应: 概率性生成导致代码同义异表(Same Intent, Different Code),维护成本指数级上升
    • 信任危机: 上下文窗口限制导致的“结构性幻觉”(引用不存在的类/循环依赖)
  • 结论: 在 AGI 到来前,必须引入“中间层”(DSL)来锁定确定性

2. 新范式:构建“神经符号”双核架构

  • 核心设计: Agent (右脑/概率) + Engine (左脑/确定性)
  • Agent 职责: 意图理解、模糊匹配、非结构化胶水代码生成
  • Engine 职责: 拓扑计算、架构约束、DDD/CQRS 骨架渲染
  • 工作流解密:Input: 自然语言需求 -> Output: 中间态 DSL -> Action: 静态语法校验 -> Result: 渲染标准 Spring 代码

3. 关键技术实践与 DSL 边界

  • 技术点 1:DSL 的“克制”哲学
    • 挑战: 如何避免重蹈 UML 覆辙(变得极其复杂且难用)
    • 方案: 坚决不侵入 if/else。DSL 仅描述实体 (Entity)、聚合 (Aggregate) 和读写契约 (Contract)
  • 技术点 2:解决“N+1”与复杂查询的读写建模
    • 方案: 引入 CQRS(读写分离) 策略
    • Write Model: 基于聚合根的事务一致性保障
    • Read Model: 基于 Toco-DTO 的自动组装器(Auto-Assembler)实现,解决跨表 JOIN 与脱敏
  • 技术点 3:从模型到代码的渲染机制 (M2C Engine)
    • 如何通过 AST 操作生成人类可读、可 Debug 的原生 Java 代码,而非二进制黑盒

4. 踩坑经验与反直觉教训 

  • 坑 1:Brownfield(存量系统)的阻抗失配
    • 问题: 在“屎山”代码上强行叠加 MDD 模式遭遇失败
    •  认知迭代: 承认技术的适用边界。该模式最适合 Greenfield(新模块/重构)。对于老系统,采用“双模开发” + “防腐层(ACL)”策略
  • 坑 2:AI 并非全自动驾驶
    • 问题: 试图让 AI 全自动设计架构,结果出现不合理的聚合边界
    • 认知迭代: 强调 Human-in-the-loop。人必须作为“架构审核员”介入 DSL 的确认环节
  • 坑 3:All-in Prompt 的失败
    • 教训: 无论 Prompt 多精妙,无法解决长链路依赖。必须用 Engine 兜底结构正确性

5. 实施效果与总结

  • 数据支撑: 某电商场景重构,Code Review 耗时下降 70%,架构类 Bug 归零
  • 终局思考: AI 时代,Code 是过程,Model 才是资产

您认为,这样的技术在实践过程中有哪些痛点?

  • 该方案对新建系统,新建模块,重构项目(Greenfield Projects)适合,对于在老系统(Brownfield Projects)上直接叠加逻辑并不适合建模驱动的开发模式. 需要一定的试用土壤,但长远来说,如果能成为行业标准,那么更容易成为大量系统重构的构建技术
  • 在当前大模型基础上,无法让AI在所有场景都是按最佳实践去试用引擎,还是需要人进行积极干预

演讲亮点

  • 把“架构规范”固化在工具里,彻底解决架构、代码随意发挥的问题。现有 AI 工具生成的代码风格完全取决于 Prompt 写得好坏和AI发挥,导致架构、代码风格严重发散,难以治理。我们通过内置引擎,统一了架构和结构性代码。避免了AI的发散导致的不易控制、不易维护的问题
  • 解决 AI 代码“只管生、不管养”的维护难题 现有方案生成的代码往往是“一次性”的,后续需求变更时,AI 很难在庞大的旧代码堆里精准修改。我们采用模型驱动,改需求本质上是在改模型,引擎会自动重新计算并同步更新所有相关代码。这让系统具备了长期演进的能力,而不是随着时间推移变成一堆不敢动的“黑盒代码”

听众收益

  • 了解一种解决 AI 编程“不可控”问题的架构实战模式(Agent + 引擎) 听众将看到我们是如何通过“中间层建模”和“双核驱动”的设计,让 LLM 负责理解意图,让规则引擎负责生成结构,从而解决 AI 写复杂系统时容易出现的“幻觉”和“逻辑不自洽”难题。这是一套可复用的架构设计参考
  • 获得一套在 AI 代码爆发下,保障系统可维护性的工程治理策略 当 AI 能瞬间生成几千行代码时,传统的 Code Review 模式已经失效。听众将收获如何通过“模型管理”替代“代码管理”,确保团队无论产出多少代码,架构标准始终统一,避免系统沦为难以维护的“各种风格的大杂烩”

交通指南

北京富力万丽酒店

Renaissance Beijing Capital Hotel
地址:北京市朝阳区东三环中路61号
  • 微信咨询

  • 电话咨询

    联系电话:+86 18514549229

微信联系我们

如您在购票过程中遇到问题,请扫码咨询票务小助手