又给大家放点逆向福利(
有人说担心担心open-antigravity的安全，其实我还有个 reopenai，直接用 opencli 来操作你的 codex/antigraivty 客户端。属于是相当安全了。
https://github.com/jackwener/reopenai
另外，open-antigravity 其实已经挺安全的了，因为他根本不是反代。
https://github.com/jackwener/open-antigravity
有人说担心担心open-antigravity的安全，其实我还有个 reopenai，直接用 opencli 来操作你的 codex/antigraivty 客户端。属于是相当安全了。
https://github.com/jackwener/reopenai
另外，open-antigravity 其实已经挺安全的了，因为他根本不是反代。
https://github.com/jackwener/open-antigravity
This media is not supported in your browser
VIEW IN TELEGRAM
播客里有个男主播的声音想换掉，怎么办？
试了两种方案：
- https://pyannote.audio 本地跑（免费但准确度一般）
- ElevenLabs Scribe API（付费但时间戳精准）👈 推荐
分离完用 Voice Clone 克隆目标声音，再用 Voice Changer API 逐段替换。
视频里有前后对比，效果很丝滑。
试了两种方案：
- https://pyannote.audio 本地跑（免费但准确度一般）
- ElevenLabs Scribe API（付费但时间戳精准）👈 推荐
分离完用 Voice Clone 克隆目标声音，再用 Voice Changer API 逐段替换。
视频里有前后对比，效果很丝滑。
Media is too big
VIEW IN TELEGRAM
从国产SOTA走向世界SOTA? GLM-5.1 实测!
给大家带来 GLM-5.1 编程能力实测! 本次测试涵盖了前端, 后端, Agent 能力, 前端主要面向空间建模, 场景, 材质, 粒子效果等, 后端能力主要面向数据结构与算法, 体系结构, 性能优化, 内存和并发管理, 性能热点分析与调优, 面向编辑器方向的Agent能力(因为AI要自己改代码).
直接说结论, 本次测试前端方面粒子效果和光影鲜果略有提升, 剩下空间理解(甚至感觉下降了)和前端美学上没看到有什么提升, 只能说是提升了一点点.
但是后端性能上有巨大的提升, GLM-5.1 在我的 vector-db-bench 中直接秀了一手量化, 把原本32bit精度的数据量化到了8bit, 然后使用SIMD实现了一个指令周期内计算32个向量, 在我测试的其他模型中(包括Claude-opus-4.6, GPT-5.4-Pro(xhigh)) 都没有实现, 直接来到了榜首.
另外Agent能力上也有不小的提升, 同样是我写的让大模型模拟送外卖的硅基骑手测试, 其他大模型的优化还停留在看一个店能不能取两单上, GLM-5.1 已经优化到了我送餐的顺路还能再接一单, 并且仅用了大概GLM-5 1/4的 token 用量就超越了 GLM-5 的测试总分.
当然本次测试过程也很坎坷, 首先是我周末抢了2天都没抢到 coding plan (目前只有coding plan 能用这个模型), 我最后找智谱的同学给我开了个权限. 以及测试中发现白天API不是很稳定, 偶尔输出速度会掉到10tps, 以及会出现乱码文字(我的规避方法是让它输出英文, 然后再找个便宜模型翻译过来).
总结, 各位前端同学估计会失望, 因为无论是从工程还是页面效果上都看不到提升, 甚至可能会有点倒退, 但果写后端代码或者复杂Agent应用可以试试这个新模型, 会有很大的提升.
#GLM51 #智谱 #GLM #AIAgent #大模型编程
给大家带来 GLM-5.1 编程能力实测! 本次测试涵盖了前端, 后端, Agent 能力, 前端主要面向空间建模, 场景, 材质, 粒子效果等, 后端能力主要面向数据结构与算法, 体系结构, 性能优化, 内存和并发管理, 性能热点分析与调优, 面向编辑器方向的Agent能力(因为AI要自己改代码).
直接说结论, 本次测试前端方面粒子效果和光影鲜果略有提升, 剩下空间理解(甚至感觉下降了)和前端美学上没看到有什么提升, 只能说是提升了一点点.
但是后端性能上有巨大的提升, GLM-5.1 在我的 vector-db-bench 中直接秀了一手量化, 把原本32bit精度的数据量化到了8bit, 然后使用SIMD实现了一个指令周期内计算32个向量, 在我测试的其他模型中(包括Claude-opus-4.6, GPT-5.4-Pro(xhigh)) 都没有实现, 直接来到了榜首.
另外Agent能力上也有不小的提升, 同样是我写的让大模型模拟送外卖的硅基骑手测试, 其他大模型的优化还停留在看一个店能不能取两单上, GLM-5.1 已经优化到了我送餐的顺路还能再接一单, 并且仅用了大概GLM-5 1/4的 token 用量就超越了 GLM-5 的测试总分.
当然本次测试过程也很坎坷, 首先是我周末抢了2天都没抢到 coding plan (目前只有coding plan 能用这个模型), 我最后找智谱的同学给我开了个权限. 以及测试中发现白天API不是很稳定, 偶尔输出速度会掉到10tps, 以及会出现乱码文字(我的规避方法是让它输出英文, 然后再找个便宜模型翻译过来).
总结, 各位前端同学估计会失望, 因为无论是从工程还是页面效果上都看不到提升, 甚至可能会有点倒退, 但果写后端代码或者复杂Agent应用可以试试这个新模型, 会有很大的提升.
#GLM51 #智谱 #GLM #AIAgent #大模型编程
Media is too big
VIEW IN TELEGRAM
从国产SOTA走向世界SOTA? GLM-5.1 实测!
给大家带来 GLM-5.1 编程能力实测! 本次测试涵盖了前端, 后端, Agent 能力, 前端主要面向空间建模, 场景, 材质, 粒子效果等, 后端能力主要面向数据结构与算法, 体系结构, 性能优化, 内存和并发管理, 性能热点分析与调优, 面向编辑器方向的Agent能力(因为AI要自己改代码).
直接说结论, 本次测试前端方面粒子效果和光影鲜果略有提升, 剩下空间理解(甚至感觉下降了)和前端美学上没看到有什么提升, 只能说是提升了一点点.
但是后端性能上有巨大的提升, GLM-5.1 在我的 vector-db-bench 中直接秀了一手量化, 把原本32bit精度的数据量化到了8bit, 然后使用SIMD实现了一个指令周期内计算32个向量, 在我测试的其他模型中(包括Claude-opus-4.6, GPT-5.4-Pro(xhigh)) 都没有实现, 直接来到了榜首.
另外Agent能力上也有不小的提升, 同样是我写的让大模型模拟送外卖的硅基骑手测试, 其他大模型的优化还停留在看一个店能不能取两单上, GLM-5.1 已经优化到了我送餐的顺路还能再接一单, 并且仅用了大概GLM-5 1/4的 token 用量就超越了 GLM-5 的测试总分.
当然本次测试过程也很坎坷, 首先是我周末抢了2天都没抢到 coding plan (目前只有coding plan 能用这个模型), 我最后找智谱的同学给我开了个权限. 以及测试中发现白天API不是很稳定, 偶尔输出速度会掉到10tps, 以及会出现乱码文字(我的规避方法是让它输出英文, 然后再找个便宜模型翻译过来).
总结, 各位前端同学估计会失望, 因为无论是从工程还是页面效果上都看不到提升, 甚至可能会有点倒退, 但果写后端代码或者复杂Agent应用可以试试这个新模型, 会有很大的提升.
#GLM51 #智谱 #GLM #AIAgent #大模型编程
给大家带来 GLM-5.1 编程能力实测! 本次测试涵盖了前端, 后端, Agent 能力, 前端主要面向空间建模, 场景, 材质, 粒子效果等, 后端能力主要面向数据结构与算法, 体系结构, 性能优化, 内存和并发管理, 性能热点分析与调优, 面向编辑器方向的Agent能力(因为AI要自己改代码).
直接说结论, 本次测试前端方面粒子效果和光影鲜果略有提升, 剩下空间理解(甚至感觉下降了)和前端美学上没看到有什么提升, 只能说是提升了一点点.
但是后端性能上有巨大的提升, GLM-5.1 在我的 vector-db-bench 中直接秀了一手量化, 把原本32bit精度的数据量化到了8bit, 然后使用SIMD实现了一个指令周期内计算32个向量, 在我测试的其他模型中(包括Claude-opus-4.6, GPT-5.4-Pro(xhigh)) 都没有实现, 直接来到了榜首.
另外Agent能力上也有不小的提升, 同样是我写的让大模型模拟送外卖的硅基骑手测试, 其他大模型的优化还停留在看一个店能不能取两单上, GLM-5.1 已经优化到了我送餐的顺路还能再接一单, 并且仅用了大概GLM-5 1/4的 token 用量就超越了 GLM-5 的测试总分.
当然本次测试过程也很坎坷, 首先是我周末抢了2天都没抢到 coding plan (目前只有coding plan 能用这个模型), 我最后找智谱的同学给我开了个权限. 以及测试中发现白天API不是很稳定, 偶尔输出速度会掉到10tps, 以及会出现乱码文字(我的规避方法是让它输出英文, 然后再找个便宜模型翻译过来).
总结, 各位前端同学估计会失望, 因为无论是从工程还是页面效果上都看不到提升, 甚至可能会有点倒退, 但果写后端代码或者复杂Agent应用可以试试这个新模型, 会有很大的提升.
#GLM51 #智谱 #GLM #AIAgent #大模型编程
你们太卷啦
- 4.4K Claude Code 源码泄露事件的隔离逆向工程，用 Rust 重实现了包含 40+ 工具、Buddy 抽卡宠物、KAIROS 常驻助手、Dream 记忆引擎等未公开功能的 AI 编程 CLI。
https://github.com/Kuberwastaken/claude-code
- 8.3K Claude Code v2.1.88 泄露源码的完整提取与深度分析，揭示其遥测隐私、108个失踪模块、Undercover Mode 和远程 killswitch 等内部机制。
https://github.com/sanbuphy/claude-code-source-code
-6.1K Claude Code v2.1.88 源码的目录结构整理版，按模块分类标注 tools/commands/buddy/assistant 等各目录用途，适合自行按图索骥挖掘源码。
https://github.com/ChinaSiro/claude-code-sourcemap
- 4.4K Claude Code 源码泄露事件的隔离逆向工程，用 Rust 重实现了包含 40+ 工具、Buddy 抽卡宠物、KAIROS 常驻助手、Dream 记忆引擎等未公开功能的 AI 编程 CLI。
https://github.com/Kuberwastaken/claude-code
- 8.3K Claude Code v2.1.88 泄露源码的完整提取与深度分析，揭示其遥测隐私、108个失踪模块、Undercover Mode 和远程 killswitch 等内部机制。
https://github.com/sanbuphy/claude-code-source-code
-6.1K Claude Code v2.1.88 源码的目录结构整理版，按模块分类标注 tools/commands/buddy/assistant 等各目录用途，适合自行按图索骥挖掘源码。
https://github.com/ChinaSiro/claude-code-sourcemap
在 V2EX 上看到一个很简单的抓取微信公众号文章的方法.
核心思路其实只有一句话：通过伪装成微信客户端内置浏览器来访问文章页面。
由于微信公众号网页通常会对普通浏览器触发滑块验证码等限制，而微信内置浏览器访问时不会触发这些校验，因此只需要在请求时把 User-Agent 改成微信客户端的格式即可。
实现上可以直接使用 curl，一行命令就能完成，无需安装任何依赖，也不需要额外技术门槛。
例如在 curl 请求头中加入类似 iPhone + MicroMessenger 的 User-Agent，再请求目标文章链接，就可以正常获取页面内容。
整体来说，这个方法的关键不在于工具，而在于伪装请求来源，本质就是一句话：通过 curl 伪装微信客户端 User-Agent 即可完成抓取，而且 User-Agent 本身也可以根据需要灵活替换。
核心思路其实只有一句话：通过伪装成微信客户端内置浏览器来访问文章页面。
由于微信公众号网页通常会对普通浏览器触发滑块验证码等限制，而微信内置浏览器访问时不会触发这些校验，因此只需要在请求时把 User-Agent 改成微信客户端的格式即可。
实现上可以直接使用 curl，一行命令就能完成，无需安装任何依赖，也不需要额外技术门槛。
例如在 curl 请求头中加入类似 iPhone + MicroMessenger 的 User-Agent，再请求目标文章链接，就可以正常获取页面内容。
整体来说，这个方法的关键不在于工具，而在于伪装请求来源，本质就是一句话：通过 curl 伪装微信客户端 User-Agent 即可完成抓取，而且 User-Agent 本身也可以根据需要灵活替换。
飞书官方的CLI来了！
https://github.com/larksuite/cli/blob/main/README.zh.md
我已经把它集成到自己的OpenCLI里了。直接opencli lark-cli 就知道如何使用了。
感觉OpenCLI 的 CLIHUB 能力还可以打磨的更好一些，直接原生替代他们的SKILL。
https://github.com/larksuite/cli/blob/main/README.zh.md
我已经把它集成到自己的OpenCLI里了。直接opencli lark-cli 就知道如何使用了。
感觉OpenCLI 的 CLIHUB 能力还可以打磨的更好一些，直接原生替代他们的SKILL。
对项目控制复杂度是个很困难的事和考验工程师能力和品味的事情。
不同的用户有各种不一样的需求，支持功能是很简单的。但是如何把它们高效地整合在一起，并且使用起来要简洁易用，是个很困难的事情。
譬如很多人希望 opencli 支持 cdp 端口直接连接。这一点其实有很多复杂的考量.
1. 扩展模式能力最强，但是安装麻烦
2. chrome://inspect/# remote-debugging 的需要每一次都用户点击允许。
3. --remote-debugging-port 的方式不支持使用默认用户，但是有些用户是用vps反代连接到mbp等真机，需要支持3方式
4. 2方式可以用script的方式跳过，但是如何保证稳定性
5. 扩展模式fallback应该到哪个情况
6. 用户如果只是希望试用能力，3应该是最好快速试用的方式
7. 2&3的API发现方式和协议都不一样，如何保证代码里共存不打架（AI很容易弄混）
插件系统 metadata 格式到现在都还没设计，因为不能轻易写导致break change.
electron 的使用需要 带上 --remote-debugging-port，如何简化设计
错误系统如何设计和传递，让出错更加友好。
......等等一系列的问题。
这才是一个真实的复杂项目的实况。很多PR我没合入。很多时候是很多问题都没有想好。
不同的用户有各种不一样的需求，支持功能是很简单的。但是如何把它们高效地整合在一起，并且使用起来要简洁易用，是个很困难的事情。
譬如很多人希望 opencli 支持 cdp 端口直接连接。这一点其实有很多复杂的考量.
1. 扩展模式能力最强，但是安装麻烦
2. chrome://inspect/# remote-debugging 的需要每一次都用户点击允许。
3. --remote-debugging-port 的方式不支持使用默认用户，但是有些用户是用vps反代连接到mbp等真机，需要支持3方式
4. 2方式可以用script的方式跳过，但是如何保证稳定性
5. 扩展模式fallback应该到哪个情况
6. 用户如果只是希望试用能力，3应该是最好快速试用的方式
7. 2&3的API发现方式和协议都不一样，如何保证代码里共存不打架（AI很容易弄混）
插件系统 metadata 格式到现在都还没设计，因为不能轻易写导致break change.
electron 的使用需要 带上 --remote-debugging-port，如何简化设计
错误系统如何设计和传递，让出错更加友好。
......等等一系列的问题。
这才是一个真实的复杂项目的实况。很多PR我没合入。很多时候是很多问题都没有想好。