唐霜

现在，已经完全离不开AI编程工具了，我的新项目 WebCut 中AI的参与度非常高，起码有 30% 的内容是AI生成的，特别是文档和一些细节算法，我则主要是把握整体的架构和方向。但是，在使用 Claude 时，高昂的成本实在是太让我心痛了。怎么控制成本，变成了一件头疼的事，当然，如果不差钱，无脑上最优模型才是正解。

经过一番折腾，我在Trae中使用Claude Code，感觉体验还是非常不错的。使用Trae的免费模型可以做一些常见的任务，比如写文档、总结和梳理代码逻辑等等，这些用免费的模型生成后，让它保存到一个文档里，然后再用Claude Code写代码，把免费生成的素材作为参考信息，这样既可以享受Claude的指哪儿打哪儿的编程体验，又能节省一些不需要代码思考的token。

上面就是我现在的工作区域截图。代码区域已经变得无足轻重了，主要承担代码预览和检查的作用。中间的claude code则是编程的主力军，右边的Trae则是干一些不需要代码精准度的事，随时可以关闭起来。另外，配合claude-code-router还可以路由模型到不同厂商，节约成本，感觉也是不错的。

随着AI时代的到来，很多关于互联网思考的观点出现，其中有一种声音指出，互联网正在消亡。这是因为，代表用户身份认同的Web2.0正在强大的商业社会中，逐渐式微。Web2.0是UGC社交时代，其本质内核是个体身份认同。我们自己写一篇文章表达自己的观点，或者发一篇图文以彰显自己的个性，甚至到后来通过短视频表达自己的价值取向。但是，这种全网热烈的表达欲，随着推荐流量为王的时代的到来，逐渐被淡化。然而，当Sora2再度火爆全网时，我猛然意识到，这种表达欲从未消逝，只不过换了形态。

为什么Sora2会爆火？

Sora2不是单纯的一个视频生成模型或工具，而是一款App。作为一款互联网产品，它定义了一种信息流的形态。在Sora App中，用户自己被尊为一等公民，其他所有的交互、技术，都围绕用户的创作欲展开。它的产品设计，不是为了发布一项技术载体而存在，而是通过激发用户的自我表达，形成一种基于创作的陌生人弱社交。

首先，Sora App提供了一项用户主角概念的构建，让用户通过Cameos把自己转变为可被（包括自己在内的所有用户）支配的视频主角。这是Sora2爆火的根本原因。所有基于sama创建的各种创意视频，从某种意义上完成了对创作本身的诠释，即故事本身并不重要，人在故事中的冲突才是最重要的。人们的创意就像无限的能源，源源不断，不会枯竭。然而，在这个时代中的个体认同确实稀缺的，创意本身如果不附带价值认同，则毫无乐趣。

其次，Sora App还提供了Remix功能，看上去好像是一个“视频编辑”的功能，然而实际上它是一种再创作。被用于remix的视频，本身并不参与再创作的素材内容，而只是一种灵感激发，当用户看到一个视频突然出现灵感时，他/她可以通过remix将灵感快速转变为可视化的结果，这种快速实现创意的过程，让人能在过程与结果之间，最快获得反馈。而对于被remix的用户而言，自己的创意给别人带来新的灵感，也就获得了价值认同。

最后，分享和喜欢是社交的基础功能，但是和其他社交中传递信息流不同，Sora App中的分享并不传递信息本身，因为它里面的视频全是AI生成的，全是虚无的，没有实际的信息价值，但是，它的社交属性在于创意的传递。人类在进入AI时代之后，信息、知识会逐渐变得廉价，而好的创意会成为稀缺资源，人们在对信息和知识无感之后，转而对好的创意报以热烈的喜爱。

从观点认同到角色认同

2019年，有一款名叫ZAO的视频换脸App突然火爆，但在随后的短短1个月内，由于侵犯用户权益问题被快速下架。我敏锐的意识到，时代变了。主要有两点原因：1.换脸技术已经成熟，核心门槛在于数据不够；2.人们对现实中的真人，在社交网络中扮演角色，将成为价值认同的核心追逐点。结果不出所料，短短几年之间，抖音攻城略地，成为国内唯二的社交顶部应用。

在AI成为主流声音之前，2023年底，chatGPT才进入普通大众视野。从2019年开始，传统的内容逐渐失去关注，facebook、微博这类信息流社交开始示微，很多著名的媒体人离开媒体行业转而在短视频、自媒体领域寻找出路。2024年，天涯爆出一篇新的热文，此外绝大部分时间，我们听到天涯的消息都是“快关门了”。在程序员界，CSDN这个原本的内容社区变成SEO病毒。总总这些，都说明依托文本内容传递观点的时代过去了，通过写一篇文章来获得社会关注的功能几乎完全丧失。而另一方面，通过建立人设、办自媒体、做个人IP来获得粉丝，以流量之名，以商业逻辑来进行创作，成为新的“时尚”。

然而，在新的“时尚”引领下，人们的审美也开始疲劳了。因为看似五花八门不同的作品，本质上却都几乎完全相似。社交变成了流量，个体认同就被裹挟了。

实际上，我们认真去研究ZAO和Sora App，会发现两者有非常相似的地方。首先，以用户为中心去构建内容，把用户捧到创作核心与演绎核心的地位，让用户得到“爽”的快感。其次，以社交分享为手段，实现快速的传播，让用户可以通过传播，把自己这个角色，展现在社交媒体中，以此获得来自环境的认同。只不过由于技术的限制，ZAO是固定视频片段，也没有remix功能。

在这个焦躁且枯燥的时代下，这种自我认同的社交会变得非常有意义。我认为Sora App正好踩在这个点上。

非生产力而是平台

Sora2的视频生成能力非常强，最大的亮点在于，极度智能的脚本能力和极高的视频真实度。然而，非常遗憾的是，我认为，Sora不会是生产力工具。它和其他视频生成模型有很大的区别，它有很多限制条件，这些限制正好是冲着生产力来的，它不希望我们这类玩技术的把它的底层能力拿去做其他生产场景的工具，它更希望普通用户在Sora上进行创作生产，它是一个平台。

这也就意味着，它和tiktok有直接竞争关系，需要抢夺tk用户的注意力时间。不过就目前的体验来讲，它虽然已经很成功，用户可以在sora上停留很长时间而不感觉枯燥，但是和tiktok的高粘度比起来，还是逊色很大一截。当然，作为一家创业公司，openAI本质上还是一家技术公司，如何运用sora这样的产品，我觉得还需要等待时间给出答案。如果运营的好，拉入更多的创作者和角色，相信未来它也可以成为一个平台，养活非常多的创作者。

结语

作为一款新兴的App，Sora是这两年最有价值的产品。这几年，很多新应用的发布，无非是把以前的旧功能重新做一遍，旧酒装新瓶。而Sora则是从创作本身出发，去探索一种基于用户为主角的价值认同，它很有可能对现在的社交媒体发起冲击。

前端开发作为独立开发系统进行工作的，不过10年，2012年前后，我还在用php输出页面，基于jquery做一些胶水工作。然而到了2015年时，前端已经基本上脱离后端，形成了自己的开发体系，实现了前端路由，仅通过ajax与后端交互，拉取必要的数据；同时ES6的发布加速了前端在编程语言上的成熟，随着模块标准化，前端已经具备了与其他编程语言基本一致的生态体系，虽然还比较年轻。2018年时，前端已经发展出比较成熟的工程化体系，已经可以在业务开发中，作为独立的工程项目进行项目管理。2022年时，前端已经开始逐步往基于服务端的能力发展，例如基于服务端渲染的框架、基于服务端的协同等等，这些标志着前端开发者可以逐渐脱离后端的约束，在开发工作中利用前端的技术解决产品从前到后的闭环。随着前端开发进入深水区，我们越来越发现，前端开发在模式上需要一场新革命，因为没有成熟的模式，前端编程从始至终都处于编程鄙视链的底端，系统级的c/c++/rust鄙视底层服务级的go/java，而go/java们又鄙视业务级的php/ruby，最终整个后端都鄙视前端（不过可能他们对客户端开发一窍不通，所以对android和ios开发又没有发言权）。这一鄙视链的根源，在于前端基于js语言并没有形成“规模级模式”，简单讲，java生态的spring就是“规模级模式”，即使在后端鄙视链末尾的php，也有laravel这样的框架支撑一个模式，因此，后端程序员往往在掌握一门框架或技术时，总是按照一定的模式进行编程，他们不会认为这样做有任何不对，甚至规范上要求一定要这样做。而在前端编程领域，完全没有这样的规模级模式，前端的编程具有随意性，我称之为“意识流编程”，可以想到哪里写到哪里，只要最终实现其效果即可。虽然在一些场景下这种思维不会带来问题，甚至还能快速上新，但是当一个项目运行许久之后，这种方式就会带来极大的问题。我这两年在研究相关课题时，经常会在知乎、乐问上了解前端开发者们的烦恼，其中非常大的一部分提到“怎么才能更好的管理业务代码和UI代码”，这个问题背后的本质，是前端没有规模级模式，来对前端编程的设计、思考、实现进行约束，或者应该反过来说，“前端目前的编程设计、思考和实现，没有形成一种业界共识，没有形成广泛性认可的编程模式”。

对于我自己而言，我不断思考的是，“前端的规模级模式应该是怎样？”这里面有很多问题，本文我将主要集中火力，讲解在我们最常见的业务系统开发中可遵循的分层模式。为什么只讲业务系统呢？因为据我观察，目前整个前端行业，业务系统开发占据主导地位，而大部分前端初学者，都是从接触vue、react之类的前端工具库开始，因此，我认为规模级模式，从业务系统突破最为可观。在过去的几年里，我对前端业界的观察，有非常多的开发者是在开发类似“后台管理系统”一类的产品，这类产品其实不能叫“后台管理”，而更多的是一种业务呈现，如果单纯是“后台管理”，那么更多的是一种“配置系统”，但是我们都知道，我们在开发的系统，不单单是“配置”，而是对业务的承载。业务系统往往包含这些方面：业务本身的定义、流转、审批，业务的数据呈现，衍生数据的呈现，与业务相关的外部行业数据的呈现。从功能上讲，既要基础的具有体验的产品所需的功能，同时也需要具备与业务相关的具有特殊性质的功能，比如在一些数据敏感的系统中，需要开发一些类似计算器、数据模板之类的功能，在一些需要进行通知的系统中，需要开发一些类似邮件模板、消息推送的功能，在一些宏观数据系统中，需要开发类似大屏的监测功能等等。由此可见，这类系统，往往整体难度不高，但是却常常规模巨大，且在某些细节点上又有比较高的难度。

要从代码层面比较好的把控复杂业务系统的开发，需要有比较好的架构规划。但对前端而言，整个行业中没有成熟的可供借鉴的模式，更别提有一种类似spring一样的行业通用的具有广泛共识的模式。因此，如何对代码进行架构，比较考验经验，只有长期接触和思考此类项目开发的工程师，才能具有宏观视野的描绘出完整的可供借鉴的范式。但是，就目前而言，没有百花齐放，就没有可能讲哪一种最好，哪一种不足，我下文所讲仅我一家之言。我长期参与此类项目开发，积累了非常多自己的想法，而我自己也是善于总结，所以冒昧聊一聊我所思考的一些结论。

前端的问题

单纯写一段代码，只有能够按照接口将其实现，并无不妥。但在我们工作中，往往不是只写一段代码那么简单，而是要写无数段代码。而在写这些代码段时，我们常常需要考虑它们相互之间的联系，这些联系网使得每一段代码之间关系复杂。且为了避免相同逻辑被不同实现，我们常常需要写可复用的代码，这就更加剧了代码之间的穿插，也就是说，代码之间的联系不仅仅有业务层面的逻辑联系，还有编程层面的代码联系，这就使得我们在写代码过程中，不得不想办法管理这些联系。

其实不仅是在前端领域，在任何编程领域，区分程序员能力高低的，往往是管理这些联系的能力。当然，这种能力是一种表征，这种能力越强，代表着这样的程序员在各个编程方面都可能胜过能力偏弱的程序员。而能力本身是可以习得和锻炼的，因此，对于程序员们而言，学习和锤炼这种能力非常重要。

对于前端而言，管理这种联系的能力异常稀缺，这是因为整个前端业界，没有形成一种统一的认知，在没有统一认知的情况下，无法确立一种有效的模式，进而也就不可能像后端领域一样，拥有相对完备的编程体系。在前端而言，没有通用的设计，因此，对相同目的的实现往往五花八门，这种杂乱的现状，使得前端的项目可持续性比较差，项目代码的腐败速度非常快，没有有效的组织逻辑，使得很多代码铁饼一块，在稍微有一段时间的沉积之后，就难以管理和重构。

我们经常有这样的困惑，如果把代码写在一个文件里，虽然是很多很乱，但是起码可以在一个文件内读完所有逻辑；而如果我们把代码抽离到多个文件中，虽然阅读流会被文件的跳跃打断，但是在代码的管理上显得更舒服，如果对代码比较熟，可以非常高效的处理和修改代码。这就是一对矛盾了，我们既希望阅读代码流畅，以帮助我们理解业务，但是同时又席位代码的管理高效，以帮助我们可以在需求发生变更时高效的修改代码。这一对矛盾的本质根源，是前端没有形成有效的模式，因为没有模式，所以在拆分代码时，没有可遵循的一套原则，不同的人对如何拆分理解不同，进而无法做到在两个人之间可以共用一种阅读思路，也就不能使得拆分更高效。

如果我们有一套有效的模式统一前端的代码组织管理，就不存在这样的问题，在业务层面，我们认同不同的业务逻辑层面应该按照某种方式组织在一起，在代码层面，我们认同不同的代码逻辑应该拆分放在另外一个地方。如果所有人都有这种认知，且这些认知有足够的细化，那么前端将和后端一样，没有必要为了如何拆分而争吵纠结，而是有相同的认知，这个东西就是应该放在这里，那个东西就应该被拆分出去。有了这样的认知之后，很多前端的代码问题都会引刃而解。

前端分层概览

分层设计决定了代码的组织管理形式，因此，如果你赞成前端分层设计，那么也就意味着你同意将代码拆分成不同功能和目的的文件，按照特定的逻辑进行组织，这必然打破之前的代码阅读习惯，不过，建立新的范式之后，改变阅读习惯也是很容易的。对于软件而言，我们往往按代码的目的将实现软件的代码组织分为表现层、逻辑层、数据层。从它们的名字，我们其实不难分清各自的目的，但是在实际操作中，我们往往会心里明白，手却不自觉的把代码写的杂糅在一起，最终变成耦合度很高的代码。实际上，在分层上，我们往往遵循这样的一种原则：依赖是单向的。文件A中的代码依赖了文件B中的代码，但B绝对不会返回来依赖A，这种单向依赖关系，可以确保在撰写内层代码时，其目的是简洁的清晰的，其实现也是比较薄的。从这一点上讲，对于前端的开发者而言，就非常不习惯，我们经常习惯于写大文件，一个文件把一个页面所有的东西都写在一起。单向依赖可以有效的解决一些代码乱串的问题，让你减少一些出错的情况。但是，当我们在阅读代码时，我们应该从外层往内读，先读依赖代码，再读被依赖代码。基于这种阅读顺序，我们还有另外一个原则，就是组合大于继承的原则。继承的问题在于，我们会一层一层的堆叠逻辑，

前几天我写了《Safari中无法播放视频，“Failed to load resource: 插件处理的载入” 或 “尝试载入资源时发生错误。”》一文，本来是记录自己在开发过程中遇到的问题和解决过程。然而，今天我在访问gemini特设的veo3页面时，发现视频也都无法播放。在访问replicate的详情页，也遇到了相同问题。没想到，就连google、replicate这样的大公司，竟然也都不在safari上做测试。

右侧这个视频无法播放的界面，是safari标志性的“侮辱”信号。

在上一篇文章中，其实我已经详细阐述了造成这个问题的原因，是safari特殊的视频资源读取逻辑。它严格按照Range Request的模式来请求视频资源，而且同时，它会在第一个请求时读取0-1 bytes来得到完整长度，而且立马丢掉（请求呈红色），然后再重新计算后严格按照Range Request来读取视频的buffer进行播放。

基于Range来读取视频数据虽然理想丰满，但是现实骨感。我打开网络面板，找到了卡住的Range请求，如下：

在这一个请求中，后端要返回14.2M的数据包，这……也太坑了吧，既然你都用Range请求了，为啥不请求一个只有1M的Range呢？而Range包的大小，则是由浏览器（也就是safari）发出的Range请求头决定的，后端也无法决定。

因此，最后其实不是google工程师没有考虑到，而是safari坑。

随后，我将默认浏览器切换成了chrome。

大家好，这两个月我完成了一款产品——Videa。虽然过去一年，我做了很多东西，但是部分是套壳，部分是把别人的想法做出来，真正我一直想做的，其实是一款借助AI创作短视频的产品。现在，我把它做出来了。

https://videa.work

下面，我将聊一聊我做这款产品的想法。

生成模型不是产品

我们现在已经有很多图片、视频的生成模型，图片领域有最早的SD、Flux，现在又有了recraft、ideogram等，而且国产的kolors等也获得好评，这几天flux kontext的发布再次震撼了业界；视频生成领域除了最早的Gen2、Pika、PixVerse，到Sora、Voe3，以及国内的混元、可灵、海螺、通义，都已经非常成熟。在如此激烈的生成模型竞争中，我发现，创作者要完成自己的短视频制作，仍然很难。

视频生成模型的厂商们在自家App中提供的视频生成功能，虽然在它们的演示中表现的非常抢眼，然而在实际使用中，普通用户很难一次性得到符合预期的结果。更重要的是，创作这件事本身，是有非常复杂的程序和时间因素的。而生成模型只能创建短时间的随机的视频，通过prompt是无法真正做到按预期生成视频的。

市面上出现了一些Agent模式的产品，例如skyreels，通过Agent来规划和制作长视频。然而其随机性大大增加，如果没有正确识别用户的创作意图，工具甚至会产出与用户意图背道而驰的作品。

总而言之，生成模型虽然好，但是只能解决从0到1的问题，而无法解决1到100的问题。模型本身很难直接成为产品，作为底层的支撑，在模型之上构建真正符合实际使用场景的产品，则是我的想法。

讲好故事而非视觉艺术

在得知AI生成视频的能力已经非常强的时候，我们跃跃欲试的心终于按捺不住，开始尝试将自己积压已久的想法制作成短视频。然而，很快我们就会发现，我们把事情想得过于简单，而工具们又把问题想得太复杂。实际上，我们的核心痛点，是想将我们内心的“故事”用短视频的形式表达出来，这种欲而不得的焦虑，促使我们对现有的AI工具产生质疑。

制作视频本身是一项技术的工作，优秀的视频剪辑，让视频非常出彩，专业的视频制作让一个博主、品牌具有强烈的人设。但是，作为普通人，很难在不以视频为自身主业的情况下，制作出令人称赞的视觉效果。那么，我们能否退而求其次，用朴素的视频，也可以传递我们想要表达的内容呢？

我的理解是，对于绝大多数有此冲动的人们而言，

短视频的本质是讲好一个故事，而非纷繁复杂的视觉艺术。

制作视频来讲述我们内心的故事，并不一定要让我们的视频具有多么高级的视觉艺术，我们都不是导演，拍不出电影级的视觉盛宴。我们的短视频，只是一个普普通通讲故事的人。这是一种表达欲的延伸，是互联网原始的初衷，是网络冲浪中敢于表达自身的内在需求。

在过去很长很长一段时间，文字或更高级的图文内容，充分展示了人们的内心世界。但在多媒体时代，这种表达，被媒体制作的技术要求所约束，以至于让网络平台成为某些人独有的话语权。

我们这个世界需要故事，而现在普通人通过AI，讲好自己的故事已经成为可能。我们绝大部分情况下，不会尝试去制作电影级的视觉效果，我们会用最朴素的节奏和配音，来把我们脑海中的故事，一点点的揉捏出视频的形。这个故事，可以是关于一个天真孩子看到神奇现象时脑海中的奇妙历险，可以是一个经过生活打磨后的中年打工人对年轻人的寄语，可以是科幻爱好者对未来星际旅行的人类空间城的设想，可以是策划人寻找与用户情感共鸣的广告设计，可以是文人们对历史回音里的控诉的无声传递。我们本质上想要短视频把90%的力量用在讲好故事，剩下的10%留给视觉和技巧带来的吸引力。

创作者们的工作流

在生成模型的基础上，创作者们构建了一套行之有效的工作流。总体而言，可以总结为如下：

在抛开需要在视频出现人物，并且保持人物一致性的情况下，这套工作流让创作者们可以利用AI工具，创作尽可能还原自身意图的短视频。而且，这套工作流的厉害之处在于，如果有足够的毅力，甚至可以制作出一部几十分钟的中长片，甚至电影级时长也不是没可能，毕竟即使电影的后期，也需要几个月的制作时间。

而对于AI工具的选择，则不同的创作者倾向不同，文生图有直接在本地部署Flux的，也有在即梦充会员的，音乐生成有网易云和qq音乐的对应平台，也可以去国外的suno等。总之，不同的工具选择，并不影响这一套工作流的具体实施。而这种灵活的组织模式，也可以让创作者们在实现创作的同时，尽可能压缩自己的成本。

化无形为有形

如何做出一款产品，将已知的概念，落地为切实的存在呢？我只抓住一个点，即前文所说的“短视频的本质是讲好一个故事”。从技术层面，短视频的制作中有一个非常重要的要素，就是“时间”，即视频这种形式与其它载体形式的最大区别就是在时间延续上的连贯性，画面的连贯性、声音的连贯性、意境情绪的连贯性。让“故事”在“时间”上行游，就是Vdiea这款产品的原始创意。

说的人话些，Videa的界面第一眼看上去就像一个视频编辑器。它由多个区域组成，其中最占视野的就是中间的视频画布区域和底下的轨道控制区域，轨道控制区域与几乎所有的视频编辑器大致相同。不同的地方在于：

• Videa没有其它视频编辑器所拥有的素材控制
• 没有其它视频编辑器的特效和转场
• 没有其它视频编辑器的超强剪辑能力

它不是一个编辑工具，不是一个编辑工具，不是一个编辑工具！在我看来，它本质上是一个管理工具，你可以直接在Videa中完成上述工作流的全部内容，包括但不限于：

• 与AI对话来进行故事创作、脚本制作等
• 通过文生图、文生视频、图转视频等来获得画面素材
• 通过语音合成来创建配音
• 无需分镜管理，因为它主动提供了“分镜”类型的轨道
• 集成了“剧本”类型轨道来获得连续的文案和配音

对于“讲故事”的创作者们而言，视频编辑器上的众多特效特技我们用不上，这种时间轴轨道的形式，仅仅是为了以“时间”的维度来管理我们的分镜和素材，我们会更多的将精力放在我们的故事创作上，用故事的内核（而非视频外在）打动我们的读者/观众，用朴素的方式，传递我们内心的声音。

结束语

从故事出发，一点一点地构砌那个属于我们自己的讲述，一帧一帧画面的跳动，干净而朴素，故事娓娓道来，然后结束。作为一个独立开发者，我有很多故事可以讲，而Videa就像一位老朋友，它慢慢的倾听，并把我的故事用短视频的方式，呈现给每一个恰到好处相遇的人。

AI让原本需要很专业才能做到的事，如今成为每一个普通人手到擒来的。Videa默认配置下可以完全免费使用，当免费的AI能力不能满足时，你可以通过购买资源包来升级，资源包是按量扣费，而且Fuu AI全站可用。无需邀请码。电脑上打开使用：

https://videa.work

在使用过程中，如果你遇到什么问题，或者发现有什么地方还做得不够好，你可以在下方留言，让我可以知道。也可以点击下面阅读原文，分享到电脑上打开后收藏，与我保持长期互动，不放过你的每一个想法。关注本公众号，获取更多使用技巧。

好了，就到这里，祝你愉快😀