最近给一个 vibe coding 平台做了几个 Showcase，才发现 Gemini 3 在个性化互动教学场景里真的挺能打。

很多抽象概念光靠讲是很难让学生 get 到的，但换成互动教学小工具来演示，就直观得多了。 而且这类纯前端、小而美的应用，本身代码量就很轻，测试、部署、扩展都方便，老师就算没什么编程基础，也能靠自然语言把它们堆出来。

更让我意外的是，Gemini 的 UI 品味肉眼可见地提升了。虽然它给的初稿还是比较糊，但稍微 PUA 一下，基本能拉到 80 分。

当然，它也不是万能的。像心脏结构这种极其精细、没办法用规则和数学公式描述的，前端代码就扛不住了，也别指望模型能编出来。

更多案例可以看这篇文章：mp.weixin.qq.com

看了anthropic最新这篇文章，有个困惑：Spec-driven development虽然很香，但是不会对“提前想清楚”的要求太高、太理想化了？产研流程中需求变更也是常态不是吗？🤔

看到身边好多朋友用 Gemini 3 一句话生成应用。而且惊叹于很短的 prompt 就能生成很完整的应用。
个人觉得好像这个并没有太值得惊叹的，因为提的要求少，AI 把缺失的部分都按照它自己的理解来实现了，反而对它来说是容易的。
除非只是随便玩一下，否则我觉得更有挑战的是AI 能更稳稳地按照我们预期的、清晰定义的需求清单来实现。

不过，一般来说，我们也没办法一开始就想清楚所有细粒度的需求，如果过程中再去增加、纠偏需求，那大概率会搞出一个屎山应用，跑步跑的起来则全靠运气。
因此我觉得一个反直觉的步骤是，即使没有完全想清楚，也可以直接让 AI 去按照它自己的理解去实现它。通过看它的实现，我就能更好地理解“哦，原来我想要的是这个”。然后我利用这种“一次性开发”中学到的东西，清空代码，再去为真正的功能开发编写一个更好的计划。这在以前是不可想象的，因为成本太高了，但是现在代码不值钱了，重来也不会心疼。

花了一天，用 AI + 知识图谱做了个本地工具，可以把长篇的用户访谈记录自动转成一个能不断扩展的知识图谱，还能用自然语言直接查询调研结论。

任何整理过访谈记录的人都懂那种痛苦。动辄几万字的内容，光是看完就头大，更别提从中提炼出有价值的洞察。常见的几个坑：
- 脑子容易“宕机”：看了十几场访谈后，早忘了前几场聊了啥。
- 判断会“漂移”：越新的、越激烈的观点更容易被记住，反而忽略了那些更普遍但平淡的反馈。
- 洞察会“丢失”：三个月前总结的核心结论，早被埋在某个没人再打开的文档里。

这时候，知识图谱就特别有用。它能把杂乱的信息组织成一个互相关联的整体，直观展示隐藏的模式，帮你快速看清：
- 同一个功能，为什么有人吐槽、有人喜欢？
- 某个负面反馈，是个例还是普遍问题？

当然，手动构建这种图谱依然是体力活。好在这正是大模型的强项——理解复杂文本并抽取结构化信息。
于是我用 Cursor 做了个本地原型工具，并写了一篇文章记录开发思路，希望能给你点启发。
mp.weixin.qq.com

最近在设计长程推理 AI Agent（一个chatBI产品)，发现一个误区：我们总想让 AI “一步到位”全自动搞定任务，但结果常常翻车。
其实不是 AI 不够强，而是三个绕不开的坎：
1、人的意图是模糊的，需要不断澄清。
2、AI 缺少你脑子里的“场外信息”。
3、上下文一长就过载，AI 会“失忆”。

而商业数据分析场景这些问题又尤为典型。因为：
1、问题不是一开始就清楚的。分析者往往只看到一个表象，接下来要不断拆解、追问，才能逐步聚焦到真正的核心。
2、很多关键线索不在数据表里，而存在于分析师掌握的隐性信息中，这些信息无法被AI自动获取，却是解释数据异常的决定性因素。
3、探索性分析的路径是非线性的。可能先拆漏斗，再切人群，再回头验证假设，然后跨到另一张表交叉论证。过程中会不断修正思路，路径极长、逻辑交错。

为了解决这个问题，我们使用“人机共创”的范式，增强人的存在感，我认为应该算是目前
Human-in-the-Loop最具象化的表达👀。

这篇文章浓缩了我们近期的全部思考：mp.weixin.qq.com

下方视频为产品 demo 演示（数据是 mock 的，但能充分说明设计的理念），期望发出来和更多朋友交流碰撞。

听了好几个AI生成的播客内容，感觉和日常聊天也太不像了，与其说是聊天，不如说更像是广播电台的主播在念稿。
自然的聊天是非线性的、天马行空的、逻辑跳跃的，可能有特定主题，但是受到“对方的只言片语”启发而发散出来的分支话题、子话题才是聊天的精髓。
而 AI 生成的播客内容是结构化的、金字塔式的，主题更加固定和聚焦，也不太会发散，虽然语调逼真自然，伪装成“捧哏”和“逗哏”，也全然没有人味儿。
不知道为啥一定要设计成“对谈聊天播客”的形式，如果单纯为了知识更好接收，单口的“故事会”形式不也挺好吗？

感觉很多AI产品的功能设计都有“过拟合”的问题…设计者基于自己怎么拆解目标任务的方式来开发功能，use cases 就那么几个，demo 也就演示这些，演示出来效果自然好，因为“训练集”就是这些，但是别的用户一用就发现很难用，因为用户拆解目标任务的方式和设计人员不同。
越是号称“通用”的产品，这类问题越明显。

最近花了点时间，把「生成式UI」这个话题认真啃了一遍。
查了论文、技术博客、教学视频，也把几个开源项目本地跑起来调了代码，拆了它们的实现逻辑。总结了业内主流做法的工程路径和能力边界，不是纸上谈兵，而是基于业务逻辑的原型验证。
实际的确没想象中那么科幻，但也不是概念吹嘘，边界清楚，用得明白才有意义。

目前诸多AI辅助生成UI产品（如 Galileo AI、Figma AI、Readdy.ai ）或 可控性差 或 无法修改主题样式 或 无法联通代码库 或 收费。
我基于shadcn+tailwind定义了一套50+组件的web端的代码化的可定制的设计系统，用它编排了一个人机协同的 UI 构建流程，能够让 cursor 基于草图生成符合规范的可运行页面，实测效果稳定（见视频），且已在真实项目中投入使用。项目已开源，个人认为是目前最务实的UI 生成解决方案了。
写了篇文章介绍完整的思路和流程：mp.weixin.qq.com

预测下之后UI 设计的全新工作流程：
设计师负责定义设计系统，直接用基于 ShadcnUI 等现成的库定制主题，甚至不用画出出来，直接用现成的主题定制工具（如 Tweakcn）调调参数就行，把design tokens 都定义好。
前端工程师拿到现成的主题JSON 之后，直接应用在ShadcnUI 的代码组件库上。
之后页面的设计，前端工程师基于 PRD直接让 cursor 基于现有的组件库来搭建页面即可。

预计会有2 个难点：
1、组件封装起来了，有代码组件库， 完全靠 cursor “画图”可能会失控，还是得有 human in the loop（让产品经理或设计师出草图），AI 基于草图来拼装会更可控。
2、原子层的样式是好控制的，但是原子与原子拼装起来的组合就很难控制住了，理论上有无穷无尽多，所以也得控制复合组件的数量，不要过度排列组合。