深入实战过AI编程的程序员们，大多已经深刻领悟到，想要“一句话生成一个软件”的Vibe Coding是不靠谱的，无法完成完整的软件的开发。
被大家认同的解药是：AI Coding Agent和Agentic软件开发方法。
同样的，”一句话生成一部AI剧/一部电影”，现阶段是不可能的。
你可能看到网上一个教程，三下五除二就教你完成一部炫酷的广告视频、MV，甚至大片质感的电影片段，这是幻觉，人家可以在家里苦练半年，从100段里面挑一个最好的给你看。
哪怕播主给你展示各种素材，中间过程，甚至打开生成界面给你看，这也是为了他这段教程优化了八百遍的，换成你自己的剧本，立马崩给你看：剧情逻辑混乱、角色场景不吸引人还是小事，视频里人物乱站、摄像机镜头不受控制，多段视频连起来差的连狗都不想看才是逼疯人的，所以大家叫生成分镜视频的过程是“抽卡”，你就知道这里面水分有多大了，这特么是玄学了。
Read More
AI剧本地流水线制片工作台
https://mbtv.me Mind it，Build it。
MBTV把剧本、角色、场景、分镜、镜头和视频生成整合到一个工作台中，让AI不只是生成工具，而是参与完整剧集的生产。
- 制片全流程资产本地保存，不上传
- 独创“M创意+B制作”制片流程，平衡AI效率与人工质量
- AI Agentic制片流水线，从故事到成片，制片人视角统筹全局
- 为完整剧集设计，而不是一个视频
- 一个工作台，连接整个AI创作生态
Read More
为了让AI Agent编程工具不局限与命令行代码生成和调试，可以通过MCP扩展其能力，例如通过MCP调用Chrome浏览器直接调试AI生成的WEB代码，不用手工去浏览器里截图和复制报错来告诉AI修bug或改代码了，它可以自动验证。
那么理论上，也可以直接通过MCP调用Figma、Pixso这些UI设计工具来辅助软件界面设计，这样就不需要美工了（笑），实战一下？
从互联网新闻的碎片中可以了解到，最先拥抱AI的是Figma，然后Pixso这些国产平替们也加入了AI功能，但都是类似WPS+AI这种在自己的一亩三分地里倒腾，给人的感觉就是……能用，但不好用。
所以最新一个新闻里，有个国外小哥用Claude Code+MCP调用Figma，而不是用Figma自带的AI设计功能，完全颠覆了使用体验，我们来求证一下。
由于Figma免费版本不开放MCP需要付费订阅，而Pixso免费版本就可以启用MCP，先用Pixso测试，开启方式很简单，在菜单里有明显的Pixso MCP开关，打开就行，然后在Opencode或Claude Code里添加MCP服务。
Read More
先放源码，非常简单，使用nodejs和原生javascript fetch调用大模型的HTTP接口（使用OpenAI传统chat接口），完成监控摄像头的运营管理的小例子。
注：测试使用的是随便找的一家平台服务商，用的deepseek和minimax模型测试，其它兼容OpenAI接口规范的一样。并且这段代码也是另一个编程智能体写的——Visual Studio Code的Copilot免费额度生成。仅作概念讲解，勿无脑照搬。
其主要逻辑就是：
- 定义给AI调用的工具（用人话给AI描述工具是干什么的，再映射到真实程序是怎样实现的，类似现在大火的Skills但那个要更复杂些）
- 从命令行输入读取用户输入命令（并记住所有的输入输出的文字，类似会话上下文的概念，实际工程要更复杂）
- 封装请求通过HTTP接口发给大模型平台（OpenAI定义的事实上的标准API接口格式，虽然它家出了新版本接口）
- 平台返回大模型生成的文字（或匹配到工具调用参数）
- 执行工具调用，并将工具的输出归并再发给大模型
- 多次循环调用工具直到不再需要工具调用
- 大模型综合分析所有输入和输出得出结论
虽然简单，但已经描述清楚一个典型的智能体底下究竟干了什么——利用大模型来理解自然语言的需求输入，再综合分析人和机器的各种输入、输出来得出结果。
Read More
人总是对未知的事物本能地产生两种情绪：恐惧和崇拜，越是不了解的，就越是极度恐惧或者极度崇拜。
做科学、做工程的，永远不可能对着一个黑盒子无条件信任，这是极度的不负责任和懒惰。
1. AI是什么？
计算机领域的基础科学其实已经停滞了好多年，从一门科学，变成了工程。
2000年门户网站互联网泡沫，10年互联网大厂电子商务奇迹，到现在移动互联网全民在线娱乐……这些都是由科技大厂堆服务器和上云计算带动，CPU、内存、硬盘和网络飞速发展作为支撑，大家一团和气、行业一片繁荣，而这些都是在2000年前就基本定型的现代软件技术和互联网架构上的不断规模化应用和改进。
Read More
经过一段时间尝试，暂时放弃FFMPEG WHIP，过段时间再回来看吧，它目前阶段有几大致命问题：
- ICE协商机制非常弱，无法正确解析流媒体服务器返回的TURN/STUN服务器信息，如果服务器或客户端在NAT后面，无法正确建立连接。
- 编码只支持H264和OPUS，虽然可以使用Android MediaCodec、Linux VAAPi、Mac VideoToolbox进行硬件编码，但无法支持H265，AV1，VP9就丢失了许多复杂网络自适应性的优势。
- 最大的问题：目前只是一个基础模式，NACK和RTX只是搭了框架还没有实现，在局域网下表现良好，但在5G移动网络下，由于高清视频的大吞吐量导致的丢包和RTP乱序问题，会被流媒体服务器大量丢弃包（否则花屏），几乎不可用。
以下为使用Google WebRTC在5G手机网络下进行WHIP推流一段时间的日志，可见大量丢包和重传：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| 2025-11-12 15:36:11.696 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 2236.78 kbps | 流量：261.55 MB | 丢包=3048 | 重传包=8337 | 平均延时=35.5ms | 分辨率=1280x720 @28.0fps
2025-11-12 15:36:21.705 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 2209.83 kbps | 流量：264.18 MB | 丢包=3048 | 重传包=8337 | 平均延时=35.2ms | 分辨率=1280x720 @30.0fps
2025-11-12 15:36:31.701 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 2225.46 kbps | 流量：266.84 MB | 丢包=3048 | 重传包=8337 | 平均延时=34.9ms | 分辨率=1280x720 @29.0fps
2025-11-12 15:36:41.704 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 2250.39 kbps | 流量：269.52 MB | 丢包=3048 | 重传包=8337 | 平均延时=34.6ms | 分辨率=1280x720 @30.0fps
2025-11-12 15:36:51.706 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 2263.40 kbps | 流量：272.22 MB | 丢包=3048 | 重传包=8337 | 平均延时=34.4ms | 分辨率=1280x720 @30.0fps
2025-11-12 15:37:01.710 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1360.12 kbps | 流量：273.84 MB | 丢包=3209 | 重传包=8678 | 平均延时=34.9ms | 分辨率=1280x720 @25.0fps
2025-11-12 15:37:11.713 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1116.58 kbps | 流量：275.17 MB | 丢包=3287 | 重传包=8834 | 平均延时=35.2ms | 分辨率=1280x720 @30.0fps
2025-11-12 15:37:21.718 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1085.65 kbps | 流量：276.47 MB | 丢包=3310 | 重传包=8894 | 平均延时=35.3ms | 分辨率=1280x720 @29.0fps
2025-11-12 15:37:31.720 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1019.51 kbps | 流量：277.68 MB | 丢包=3322 | 重传包=8935 | 平均延时=35.3ms | 分辨率=1280x720 @30.0fps
2025-11-12 15:37:41.724 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1419.96 kbps | 流量：279.38 MB | 丢包=3387 | 重传包=9159 | 平均延时=35.6ms | 分辨率=1280x720 @24.0fps
2025-11-12 15:37:51.728 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1463.75 kbps | 流量：281.12 MB | 丢包=3387 | 重传包=9159 | 平均延时=35.6ms | 分辨率=1280x720 @30.0fps
2025-11-12 15:38:01.733 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 2197.51 kbps | 流量：283.74 MB | 丢包=3387 | 重传包=9159 | 平均延时=35.3ms | 分辨率=1280x720 @19.0fps
2025-11-12 15:38:11.735 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 2192.32 kbps | 流量：286.36 MB | 丢包=3387 | 重传包=9159 | 平均延时=35.1ms | 分辨率=1280x720 @25.0fps
2025-11-12 15:38:21.736 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 2191.17 kbps | 流量：288.97 MB | 丢包=3387 | 重传包=9159 | 平均延时=34.9ms | 分辨率=1280x720 @27.0fps
2025-11-12 15:38:31.743 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 2226.45 kbps | 流量：291.62 MB | 丢包=3387 | 重传包=9159 | 平均延时=34.6ms | 分辨率=1280x720 @26.0fps
2025-11-12 15:38:41.743 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1494.46 kbps | 流量：293.41 MB | 丢包=3486 | 重传包=9431 | 平均延时=34.9ms | 分辨率=1280x720 @10.0fps
2025-11-12 15:38:51.742 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1092.73 kbps | 流量：294.71 MB | 丢包=3514 | 重传包=9525 | 平均延时=35.4ms | 分辨率=1280x720 @31.0fps
2025-11-12 15:39:01.745 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 989.63 kbps | 流量：295.89 MB | 丢包=3541 | 重传包=9594 | 平均延时=35.4ms | 分辨率=1280x720 @30.0fps
2025-11-12 15:39:11.750 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1081.26 kbps | 流量：297.18 MB | 丢包=3553 | 重传包=9639 | 平均延时=35.6ms | 分辨率=1280x720 @29.0fps
2025-11-12 15:39:21.751 16075-16124 MeCastSRV cn.mbstudio.nativewhip D 📡 上传带宽: 1026.44 kbps | 流量：298.40 MB | 丢包=3569 | 重传包=9683 | 平均延时=35.8ms | 分辨率=1280x720 @30.0fps
|
作为对比，Google开源的WebRTC实现，在同类硬件、OS和网络条件下，几乎不存在任何质量问题，可以说，WebRTC虽然一直以来没有信令层的标准实现（WHIP算第一个被接受的标准信令层协议）一直被诟病，但其媒体处理和传输设计的确优秀：无论是跨平台的硬件编解码实现的性能（另一个VoIP领域权威的SIP协议，其开源实现例如PJSIP最大问题就是硬件编解码支持的薄弱），提供的行业内最优秀的网络质量保障机制等，这些白手起家撸一套还是很有挑战性的。
Read More
由于Electron官方编译Linux版本不支持VAAPI编码，需要自行源码编译，这个工作还是有一些挑战性，首先是硬件需要8G以上内存，200G左右硬盘，以及10M以上的国际互联网访问通道。
可能因为各种原因，好不容易下载好的120G源码，在某台机器上由于硬件问题无法编译，需要更换机器，如果反复重复上述工作，都将是天大的折磨。
所以为了复用成果，一次下载在多个机器上可以反复使用，测试了一下使用Docker容器进行编译，以可以避免破坏某台高性能机器（一般上面有比较重要的内容，但临时借用几小时编译下得到编译成果，而不破坏主机现场环境还是可以的，Docker容器的价值也正在于此）。
本次实测通过3台主机：
- 4U至强服务器：硬伤是SAS机械盘比较慢
- MacBook Intel i7 16G
- Mac mini M4: 硬件是256的ssd，存储已经满了（arm主机，实际也可以运行x86 docker进行编译）
Read More
经过与ChatGPT反复探讨（挑战）与实机测试，目前官方Chrome对Linux平台的GPU硬件编解码支持度还是可以的，最新的141.0.7390不加任何启动参数启动，已经可以支持主流的H264，H265以及VP8，VP9的硬件解码：
带上启动参数：
1
| google-chrome --enable-features=PlatformHEVCDecoderSupport,VaapiVideoDecoder,AcceleratedVideoEncoder,AcceleratedVideoDecodeLinuxGL,VaapiVideoEncoder,AcceleratedVideoDecodeLinuxZeroCopyGL
|
能够启用完整的VAAPI硬件编码：
Read More
继解决了Android Mediacodec编码H264码流下降的问题后，码流上来了，WHIP推流也一如既往的奔溃了，毕竟是刚发布几个月的“试验性”功能……
话说FFMPEG为了抢市场，这个试验功能推出的也够仓促的，好多参数全部写死，视频只支持H264，音频只支持OPUS并且强制2声道48000Hz采样，啥VP8，VP9，711编码都不带给你的，而且随8.0主版本发布的还有ICE协商BUG导致许多流媒体服务器在ICE协商这步就出错，然后连接超时，根本推不了流，许多人可能尝试到这步这放弃了。
经过抓包才发现，STUN消息里少了关键字段服务器不认。然后想自己手写补丁的，上Git仓库一看，8.1 dev中有更新修正了，打上补丁在桌面系统上可以正常使用mp4文件进行推流了，以为一切ok就在Android上尝试一下吧，一试就出现了上面的编码码流问题，然后就是反复的错误，反复的ret返回-11错误。
1
2
| E Failed to write packet=1194B, ret=-11
E Failed to write packet, size=37952 Try again
|
可以看到，mediacodec上了高码率后，产出的nal包特别大，远超MTU大小，rtp肯定需要分片才能正常发送（rtp muxer负责在ff_rtp_send_h264_hevc中，进行nal分片，最后是nal_send发送的，所以并不是网上说的ffmpeg不直接提供H264裸包的nal分片功能，而是它不对外提供接口，只是自己内部使用）。
Read More
AI编程哪天真能分析解决问题才是生产力，不然还是渣渣……
记最近一次分析视频清晰度的问题，想使用FFMPEG最新的8.0版本中带的WHIP来试下“0延时”的推流，测试了RTMP和RTP_MPEGTS都是正常的了，但到了WHIP下面还是各种写包失败（虽然它的底层还是调用的SRTP来发送的），暂时还没空继续研究它的代码，就被Android手机上的清晰度问题缠住了。
现象就是，刚开始推流时，按给mediacodec设置的CBR和2M码流在推，可不到1，2秒，画面突然降到只有50KB（大概只有400kbit）了，画面就充满了马赛克。
把问题推给AI，AI的回答从教你如何使用FFMPEG命令行，一直讲到了大量代码给你演示怎么推流，最后都讲到了安卓硬件厂家的隐藏代码，说会因为cpu负载或发热等问题限制码流，并随手扔给你一些隐藏代码：
例如：
Read More
