2025年D2参会感想
关注外面世界的变化，培养大局观
我们常常容易局限于自己所接触的狭小范围，被琐事所束缚。然而，只有突破这种局限，才能真正拓宽眼界、丰富知识。当我们的视野不再局限于眼前，知识储备逐渐增长时，我们就能更清晰地认识和理解各种事件，并洞察其后续的趋势变化。这将帮助我们做出更具前瞻性和关键性的选择。
如果只盯着前端，就自己把路给走窄了。
该如何看待AI
我发现我们和这些公司有个很本质的区别：我们是自上而下搞AI，他们是业务团队带头，自下而上用AI，把AI当成一个加速的业务辅助工具，他们有很大精力放在基建和打磨组件上、物料上。
内聚 & Keep In Flow
PS：我经常做着做着就不知道该做啥了，就是这个缘故：在Mac的各个APP之间跳转。
所有工作能够集中在一个IDE内部完成，而不需要跳转到其他地方时，效率会大大提高。例如，之前使用AI工具时，我们通常需要在ChatGPT中对话，然后将返回的结果复制粘贴到其他地方进行后续处理。这种操作方式不可避免地会导致思维被打断，专注力也因此被分散。
相比之下，如果所有工作都能在同一个IDE中完成，就能保证精神高度集中，从而实现最佳工作效率。这种内聚的工作方式有助于维持心流状态，让思考过程不受外部干扰。
思维问题
遇到某个问题或者接到某个需求的时候，我们大部分人的思维都是做个功能来解决当前这个问题，而不是对问题进行抽象和提升，把池子和价值扩大，然后做个系统来解决更大的问题。
低码平台的关键：整体一致性大于局部最优
这次分享的低代码平台基本上都是面向ToB业务的。这类业务对UI的要求相对较低，大部分情况下可以舍弃UI上的个性化需求，通过保证UI的一致性来降低开发成本。因此针对这种需求，整体一致性大于局部最优，低代码搭建就具备非常强大的潜力。
当然，即使是面向中后台的系统，菜鸟这边也花了三年的时间进行了大量的基建相关的改造。
因此对我们公司而言，要做低代码搭建ToC业务其实难度非常高，最关键的是我们得解决不同业务的差异化需求问题。这一点刘帅也多次提到，可见是他印象非常深刻的一个问题，因为他之前也做过低代码相关内容，在这方面很有体会，也很有发言权。
所以，我们公司能否把低代码搭建运用到ToC业务，其核心关键因素就在于能否统一整个ToC业务在设计交互上的一致性。如果这个问题不能解决，那我们的低代码生成ToC业务就只能是空谈，最终必定走向失败。
这条路肯定很难，因为目前市面上基本没有任何公司搞定低代码生成ToC的需求，他们大部分还是面向运营中后台等系统。所以这条路一定要谨慎，我要不要趟这趟水也需要谨慎思考，千万不要整个人陷进去，把自己给拖死了。
速度快、便宜、效率，牺牲个性化。
AI可视化编辑器，可能会是我们最好的产品
特斯拉最好的产品：工厂。
小米汽车的第一个产品也是工厂，第二个产品才是汽车。
我们也是一样，第一个产品应该是IDE，第二个产品才是各个功能页面。
对于我们可视化而言，编辑器是我们的底座。AI可视化编辑器，可能会是我们最好的产品。
软件开发中的基建 = 制造业的工厂
关于可视化的想法
AI生成阅后即焚的可视化
很适合目前的HiPilot模式。
DSL和自然语言的转换
可视化生成和低代码搭建，其本质都是DSL和自然语言的转换。
如何定义一个合理的JSON Schema，以及如何做好用户自然语言需求到这个DSL的转换，是能否做成、能否做好这个事情的最关键的问题。
构建不同粒度组件之间的关联关系
原子组件、高阶组件、功能页面。
通过向量化之后进行对比分析，构建关联关系。
常规可视化图表需求的解决方案
- AI识别需求，通过NLP、OmniParser等，将非结构化的需求（自然语言需求、图像需求等)转为结构化的DSL需求(比如JSON)
- 推荐可视化配置和案例(特征提取、知识库)
- 问答式启发确认需求(Question-guided Insights Generation for Automated Exploratory Data Analysis)
- 生成可视化配置
可以从诸如Make A Pie这种网站抓取数据，作为可视化案例的训练数据。
分级知识召回
策略1：构建不同粒度的知识库，面向不同的用户和需求。
策略2：采用LlamaIndex的分级召回方式。
可视化和低码搭建的关系
低代码都是2B业务，但是我们可视化组件可以当成2B业务来看待(别人不会写，只能我们写，因此容易做标准化)，因此很适合走低码搭建的路线。
如何向LLM精准的表达需求
设计稿解决的问题：想法得到精准的表现。
D2C待解决的问题：(To LLM)信息得到精准的表达。
关于低码搭建的想法
用AI F10的模式和交互去做页面生成和搭建
页面左侧是功能的展示和布局，右侧一个AI Chat对话框去做微调以及局部组件的展示，所以低码搭建的模式和AI F10的模式是完全可以互通互换的。
目前公司的KAmis缺少用对话模式快速简便的去做微调的功能。
节点编辑器
网易的搭建平台：NASL语言+节点编辑器，类似UE的蓝图，极大降低使用门槛。
KAmis能不能通过这种形式解决易用性问题？特别是数据的绑定，这个用户反馈是最麻烦的环节。
根据不同用户，分为不同的交互
比如面向研发和非研发，分为两个版本。
面向研发：支持编写代码，便于进行精细操作；
面向非研发：全可视化操作，仅支持粗粒度操作。
蚂蚁的方案
走的C2D2C的方案：
1、协议制定（IR标准，Intermediate Representation）：作为模型训练备数和跨端消费的统一标准
2、准备阶段（Code2Design）：人工开发符合设计标准的组件，并与IR标准关联对齐
3、应用阶段（Design2Code）：根据设计稿，召回匹配的组件，组装成页面
只走通了Figma2Code的链路，还原了UI但没解决UX及业务信息的还原、交互、动画、数据绑定、埋点等问题。
这不是老板要的Figma2Code。
IR标准等开源了可以参考下，UI组件和可视化组件都涵盖了：
关于做PPT
用Keynote做PPT
绝大部分演讲者做ppt用的都是Keynote，做出来的视觉效果是非常好的。
Keynote比于传统的PPT软件，其风格布局字体等上面都有优势：
- 模板设计：Keynote 内置模板以极简风格和高审美著称，如「摄影」「经典」系列模板，视觉效果接近电影级质感，适合艺术展示、产品发布会等场景
- 字体渲染：Keynote 采用苹果的次像素抗锯齿技术，文字边缘更清晰锐利（类似“打过玻尿酸”），同一份文件在 Windows 上可能因字体渲染差异导致模糊
- **Magic Move(动画)**：通过拖拽进度条即可实现物体变形和路径动画，无需插件
简单的风格
比如尤雨溪的PPT，都是黑白风格+简单的文本。
简单可以让观众聚焦在问题上。