用Grok读源码，用Luma做演示，我这一年半的AI辅助开发路子

我算是GitHub Copilot比较早一批的付费用户，到现在快两年了。坐标成都，在一家做数据可视化的公司写前端。过去一年多，我用AI工具的方式变了不少：从只会让Copilot补全代码，到现在用Grok读源码、用Luma Dream Machine做演示视频、用Lovable快速验证想法，摸索出一套还算顺手的方法。

读源码这件事，Grok帮了大忙

我习惯研究开源项目源码。之前读Vue响应式系统或React Fiber调度，靠IDE跳转加断点调试，遇到跨模块调用链经常断掉。今年年初我在看xyflow流程图库的源码，想搞清它的节点拖拽性能优化。核心的useDrag逻辑绕来绕去，代码量不小。

我试着把关键文件贴给Grok，让它梳理调用链路。Grok对长上下文的支持确实可以，我把packages/core/src/store下面十几个文件一次性丢进去，它能给出清晰的模块依赖图，并标注热点路径。比如我在找节点位置更新为什么没触发多余渲染时，Grok定位到useStore里基于selector的浅比较逻辑，还解释了为什么用Object.is而不是深比较。这比一行行看代码快多了。

当然它也会瞎编。有次它信誓旦旦说某个函数在utils.ts里，结果根本没有。所以我现在养成了习惯：Grok给的结论，必须回到源码里验证一遍。它是个很好的“导航员”，但不能当“驾驶员”。

Lovable让我从想法到Demo只用了一个晚上

Lovable是AI驱动的全栈应用生成工具，描述需求就能生成可运行的Web应用。我一直想做“成都独立开发者线下活动日历”，但懒得动手。有天周五晚上用Lovable试了试，花二十分钟写了详细需求描述，包括数据模型、页面结构、筛选逻辑。第一版就能跑了：活动列表页、按月份筛选、点击看详情。

但生成的代码质量只能说能用。数据库查询直接写在组件里，没有分层；状态管理也东一块西一块。不过Lovable的定位本就是快速验证，不是生产级代码。我后来把前端重写了，后端接口保留，部署在Vercel上，那个小项目已收录三十多场活动。

我的体会：Lovable适合两件事。一是验证想法，在投入大量时间写代码前先看看产品形态对不对；二是给非技术背景的人做原型演示。我推荐给产品经理后，他居然自己生成了一个内部工具，跑来问我怎么部署。这类工具的门槛真的降到了让人惊讶的程度。

用Luma Dream Machine做技术分享的演示素材

Luma Dream Machine是AI视频生成工具，输入文字或图片就能生成几秒视频。我在准备“WebGL粒子系统的性能优化”组内分享时找到了用法。想展示粒子数量从1万到100万时帧率的变化，但光靠图表太干，录屏不够直观。我用Luma生成了几段粒子爆炸、星云旋转的视频素材，穿插在PPT里做视觉过渡，效果意外地好。

不过Luma生成视频的不可控性很大。我试了十几次才生成一段满意的“粒子从中心向外扩散”效果，大部分时候画面跟描述差挺远。免费额度烧得飞快，充了最低档套餐，一个晚上就用了大半。这东西目前属于“锦上添花”，不能指望它做核心内容。

书籍仍然是打底的东西

说了这么多AI工具，但书还是要看的。今年上半年我重新翻了《JavaScript设计模式与开发实践》。虽然例子有些老了，但设计思想依然不过时。比如策略模式、发布订阅模式，我在重构公司可视化项目的配置系统时就用到了。

AI工具能帮你快速找到答案，但不能帮你建立知识体系。用Grok读源码之前，最好已经对相关领域有基本认知，否则连它给出的解释是对是错都判断不了。书和系统性的文档是骨架，AI工具是加速器。

写在最后

这一年多最大的感受：AI工具的价值不在于替代你写代码，而在于帮你把时间花在更值得的地方。读源码时少花时间找调用链，做Demo时少花时间搭架子，准备分享时少花时间做素材。省下的时间，用来深入理解那些真正需要动脑的部分。

如果你刚接触这些工具，我的建议是：先选一个方向深入用，别贪多。工具是为人服务的，别反过来被工具牵着走。