[分享创造] 分享一个生成 15 秒 AI 舞蹈短片的工具： A2O LITE NEON AI Dance
介绍一个面向照片动画创作的工具：A2O LITE NEON AI Dance 可根据已获授权的成人或宠物照片生成 15 秒舞蹈视频，提供 Human Duo 、Pet Duo 和 Solo 三种模板。它是受 NEON 霓虹色彩与动感启发的粉丝创作项目，并非官方合作；产品为付费服务，价格从 $9.90 起。使用他人照片前请确认已取得许可。
产品介绍：A2O LITE NEON AI
via V2EX (author: ALPHA123)
介绍一个面向照片动画创作的工具：A2O LITE NEON AI Dance 可根据已获授权的成人或宠物照片生成 15 秒舞蹈视频，提供 Human Duo 、Pet Duo 和 Solo 三种模板。它是受 NEON 霓虹色彩与动感启发的粉丝创作项目，并非官方合作；产品为付费服务，价格从 $9.90 起。使用他人照片前请确认已取得许可。
产品介绍：A2O LITE NEON AI
via V2EX (author: ALPHA123)
[程序员] 花了一个月做 AI API 中转站，发现最难的根本不是技术，而是搞到便宜的上游。
最近一个月一直在折腾 AI API 中转站，期间也刷了不少推特上关于 Claude 、Codex 号池搭建和防封策略的帖子，越研究越觉得这个行业有点魔幻。
一开始以为做中转站最难的是技术，什么高并发、负载均衡、自动切换、Token 计费、渠道监控之类的。
结果真正做下来才发现，这些可能反而是最简单的部分。
现在有 Claude Code 、Codex 这些 AI 编程工具，搭一套完整的中转系统根本花不了多少时间。开源项目也一大堆，真正拉开差距的反而是上游资源。
最近推特上各种号池搭建、账号防封、风控研究的内容越来越多，甚至还有人专门研究不同账号类型的封禁规律。
以前觉得做 API 服务，核心应该是服务器、架构和稳定性。现在看来，有些中转站最核心的技术可能是研究怎么不被官方封号。
这就很有意思了。
同样是做中转，A 用官方 API ，老老实实按量付费，哪怕做了再好的技术优化，成本也很难压下去。
B 通过各种订阅号池、特殊渠道，成本可能只有官方 API 的几个百分点，哪怕系统是直接拿开源项目改的，价格上也能直接碾压 A 。
问题是 B 的低成本建立在什么基础上？
我看推特上一些关于防封的讨论，感觉已经不太像传统意义上的软件工程了，更像是在跟大模型厂商的风控系统打持久战。
今天研究账号为什么被封，明天研究某种策略还能不能用，后天可能官方更新一下规则，整个号池就得重新调整。
号池越大，理论上可分摊的成本越低，但账号共享规模越大，风控风险可能也越高。
最讽刺的是，做一个中转站可能只需要几天，但想让一批低价账号长期稳定地活着，反而需要持续投入大量精力。
而且还有个问题我一直没想明白。
官方显然不希望个人订阅额度被大规模商业化转售，但市场上又确实存在大量这种需求。
于是就形成了一个奇怪的循环：
官方加强风控 → 号池成本上涨 → 中转商研究新的防封策略 → 低价渠道重新出现 → 官方继续加强风控。
整个行业似乎都在重复这个过程。
更值得讨论的是，这种模式到底能持续多久？
假如一个中转站的价格只有官方的 2%，这到底意味着它有非常强的技术和资源优势，还是意味着用户正在承担某些看不见的风险？
如果某天官方把账号共享的漏洞基本堵死了，靠号池生存的中转站是不是会瞬间失去竞争力？
折腾了这一个月，我现在越来越觉得：
AI API 中转站表面上是技术生意，实际上更像资源生意，甚至有一部分是在做风控套利。
挺想听听 V 友们怎么看。
你们觉得现在这些研究号池搭建和防封策略的人，算不算另一种技术能力？
还是说，这个行业从根本上就没有什么真正的技术壁垒，只是在利用大模型厂商暂时没有堵上的商业规则漏洞？
via V2EX (author: devlrboyz)
最近一个月一直在折腾 AI API 中转站，期间也刷了不少推特上关于 Claude 、Codex 号池搭建和防封策略的帖子，越研究越觉得这个行业有点魔幻。
一开始以为做中转站最难的是技术，什么高并发、负载均衡、自动切换、Token 计费、渠道监控之类的。
结果真正做下来才发现，这些可能反而是最简单的部分。
现在有 Claude Code 、Codex 这些 AI 编程工具，搭一套完整的中转系统根本花不了多少时间。开源项目也一大堆，真正拉开差距的反而是上游资源。
最近推特上各种号池搭建、账号防封、风控研究的内容越来越多，甚至还有人专门研究不同账号类型的封禁规律。
以前觉得做 API 服务，核心应该是服务器、架构和稳定性。现在看来，有些中转站最核心的技术可能是研究怎么不被官方封号。
这就很有意思了。
同样是做中转，A 用官方 API ，老老实实按量付费，哪怕做了再好的技术优化，成本也很难压下去。
B 通过各种订阅号池、特殊渠道，成本可能只有官方 API 的几个百分点，哪怕系统是直接拿开源项目改的，价格上也能直接碾压 A 。
问题是 B 的低成本建立在什么基础上？
我看推特上一些关于防封的讨论，感觉已经不太像传统意义上的软件工程了，更像是在跟大模型厂商的风控系统打持久战。
今天研究账号为什么被封，明天研究某种策略还能不能用，后天可能官方更新一下规则，整个号池就得重新调整。
号池越大，理论上可分摊的成本越低，但账号共享规模越大，风控风险可能也越高。
最讽刺的是，做一个中转站可能只需要几天，但想让一批低价账号长期稳定地活着，反而需要持续投入大量精力。
而且还有个问题我一直没想明白。
官方显然不希望个人订阅额度被大规模商业化转售，但市场上又确实存在大量这种需求。
于是就形成了一个奇怪的循环：
官方加强风控 → 号池成本上涨 → 中转商研究新的防封策略 → 低价渠道重新出现 → 官方继续加强风控。
整个行业似乎都在重复这个过程。
更值得讨论的是，这种模式到底能持续多久？
假如一个中转站的价格只有官方的 2%，这到底意味着它有非常强的技术和资源优势，还是意味着用户正在承担某些看不见的风险？
如果某天官方把账号共享的漏洞基本堵死了，靠号池生存的中转站是不是会瞬间失去竞争力？
折腾了这一个月，我现在越来越觉得：
AI API 中转站表面上是技术生意，实际上更像资源生意，甚至有一部分是在做风控套利。
挺想听听 V 友们怎么看。
你们觉得现在这些研究号池搭建和防封策略的人，算不算另一种技术能力？
还是说，这个行业从根本上就没有什么真正的技术壁垒，只是在利用大模型厂商暂时没有堵上的商业规则漏洞？
via V2EX (author: devlrboyz)
[程序员] Java 重大漏洞 CVE-2026-91403
https://www.cve.org/CVERecord?id=CVE-2026-91403
https://www.oracle.com/security-alerts/alert-cve-2026-91403.html
研究了一下, 并不是只有文中提到的几个特定版本才有影响, 而是只测了这些版本发现有问题
换句话说基本所有的 JDK 都有漏洞风险
目前修复漏洞的新版本似乎都还没发布, 只能按公告的方法临时缓解
拉黑这八张证书 (八张都是 eMudhra （印度 CA ）的中级 CA 证书)
via V2EX (author: Vaspike)
https://www.cve.org/CVERecord?id=CVE-2026-91403
https://www.oracle.com/security-alerts/alert-cve-2026-91403.html
研究了一下, 并不是只有文中提到的几个特定版本才有影响, 而是只测了这些版本发现有问题
换句话说基本所有的 JDK 都有漏洞风险
目前修复漏洞的新版本似乎都还没发布, 只能按公告的方法临时缓解
# 1. 从 OpenJDK 公告页下载对应平台的 blocked.certs （公告 "Advice to users" 节有 Windows / 其他平台两个版本）
# 2. 备份并替换（如果你之前没自定义过该文件，直接替换）
cp $JAVA_HOME/lib/security/blocked.certs $JAVA_HOME/lib/security/blocked.certs.bak
cp blocked.certs $JAVA_HOME/lib/security/blocked.certs
# 3. JDK 8 特例：文件名是 blacklisted.certs ，路径相同
拉黑这八张证书 (八张都是 eMudhra （印度 CA ）的中级 CA 证书)
via V2EX (author: Vaspike)
[分享创造] 尝试用 DeepSeek-V4.1-Flash-1017 复现官方的赛车游戏示例
尝试用 DeepSeek-V4.1-Flash-1017 + omp 复现官方给出的赛车游戏示例，成品和官方示例有不少的差距，哈哈
● 在线玩：https://oujingzhou.github.io/neon-racer/
● 源码：https://github.com/oujingzhou/neon-racer
via V2EX (author: jingzhou)
尝试用 DeepSeek-V4.1-Flash-1017 + omp 复现官方给出的赛车游戏示例，成品和官方示例有不少的差距，哈哈
● 在线玩：https://oujingzhou.github.io/neon-racer/
● 源码：https://github.com/oujingzhou/neon-racer
via V2EX (author: jingzhou)
[生活] 00 后想问一句：中年夫妻里，婚外性行为到底有多普遍？
先说身份，04 ，没结婚，纯好奇，不是来给自己找台阶的。
最近翻到几个讲婚姻的帖子，评论区里反复出现"性生活不和谐"这几个字。这种不和谐，后来都怎么处理了？
我能想到两种可能，但不知道现实里是不是真这样。
一种是，一方其实知道对方在外面有情况，为了孩子、房子、老人、面子，选择不捅破，日子照过。
另一种是，双方都有，但谁都不说，默契地维持一个"正常夫妻"的样子。
这两种在现实里到底常不常见？还是只是我网上看多了产生的错觉？
我问的不是"该不该"，该不该我心里有数。我想知道事实层面：你身边有没有见过这样的例子，最后是维持住了还是散了？
有冒犯到的地方先说声抱歉。
via V2EX (author: Giaorui)
先说身份，04 ，没结婚，纯好奇，不是来给自己找台阶的。
最近翻到几个讲婚姻的帖子，评论区里反复出现"性生活不和谐"这几个字。这种不和谐，后来都怎么处理了？
我能想到两种可能，但不知道现实里是不是真这样。
一种是，一方其实知道对方在外面有情况，为了孩子、房子、老人、面子，选择不捅破，日子照过。
另一种是，双方都有，但谁都不说，默契地维持一个"正常夫妻"的样子。
这两种在现实里到底常不常见？还是只是我网上看多了产生的错觉？
我问的不是"该不该"，该不该我心里有数。我想知道事实层面：你身边有没有见过这样的例子，最后是维持住了还是散了？
有冒犯到的地方先说声抱歉。
via V2EX (author: Giaorui)
[程序员] 昨晚笑 PHP 的, 今天可以笑 Java 了 🤪
今天 Oracle 也发布了一个 CVE 漏洞: https://www.oracle.com/security-alerts/alert-cve-2026-91403.html
via V2EX (author: GodSppp)
今天 Oracle 也发布了一个 CVE 漏洞: https://www.oracle.com/security-alerts/alert-cve-2026-91403.html
via V2EX (author: GodSppp)
[分享创造] 90 多个模块发版反复超时，于是我写了个 Maven Central 发布插件
最近给框架发版时总卡在 Maven Central 发布那一步：一次要推送 90 多个工件、加起来超过 300MB ，之前一直用的插件走 OSSRH 路径，在这个体积下反复超时，要么手动补发、要么整段重来，非常折腾。
按照 Maven Central 官方的 Publisher API 文档，我用 Java 实现了一个 Gradle 发布插件，把正式版收敛成 staging → bundle → 上传 Portal → 轮询部署状态一条命令；又补上了 SNAPSHOT 直接发布，根项目版本号带
两个自认为对多模块项目有用的取舍：
● 根项目聚合发布：一次扫描所有子项目，把它们的 publication 合并进同一次部署，避免同一版本拆成多个部署互相打架；
● 凭据不在配置阶段求值：默认按
如果你也有多模块发布的需求，欢迎试用，有问题可以提 Issue 。
当前版本是 v1.0.1 ，插件不依赖我的框架。源码包、Javadoc 、POM 元数据和签名需要在项目中自行配置，完整用法见仓库 README 。
● 插件： https://plugins.gradle.org/plugin/cn.taketoday.maven-central-publishing
● 仓库： https://github.com/TAKETODAY/maven-central-publishing-gradle-plugin
● 项目： https://github.com/TAKETODAY/today-infrastructure
via V2EX (author: TAKETODAY)
最近给框架发版时总卡在 Maven Central 发布那一步：一次要推送 90 多个工件、加起来超过 300MB ，之前一直用的插件走 OSSRH 路径，在这个体积下反复超时，要么手动补发、要么整段重来，非常折腾。
按照 Maven Central 官方的 Publisher API 文档，我用 Java 实现了一个 Gradle 发布插件，把正式版收敛成 staging → bundle → 上传 Portal → 轮询部署状态一条命令；又补上了 SNAPSHOT 直接发布，根项目版本号带
-SNAPSHOT 后缀就自动切快照仓库，不用再在两个工具间来回切。两个自认为对多模块项目有用的取舍：
● 根项目聚合发布：一次扫描所有子项目，把它们的 publication 合并进同一次部署，避免同一版本拆成多个部署互相打架；
● 凭据不在配置阶段求值：默认按
mavenCentral 身份在任务执行时解析，配置缓存只保存身份；--dry-run 不需要凭据。如果你也有多模块发布的需求，欢迎试用，有问题可以提 Issue 。
当前版本是 v1.0.1 ，插件不依赖我的框架。源码包、Javadoc 、POM 元数据和签名需要在项目中自行配置，完整用法见仓库 README 。
● 插件： https://plugins.gradle.org/plugin/cn.taketoday.maven-central-publishing
● 仓库： https://github.com/TAKETODAY/maven-central-publishing-gradle-plugin
● 项目： https://github.com/TAKETODAY/today-infrastructure
via V2EX (author: TAKETODAY)
[程序员] 运营了 3 个月的产品，播放量终于破 100w 了。
从 6 月 29 上线到现在，运营了 3 个多月的时间，VirPulse 话题 在抖音的播放量终于破 100w 了。
via V2EX (author: MagicCoder)
从 6 月 29 上线到现在，运营了 3 个多月的时间，VirPulse 话题 在抖音的播放量终于破 100w 了。
via V2EX (author: MagicCoder)
[分享创造] 做了一个 PHP2Shell 应急辅助工具：被动响应头检查、版本核对和配置引导
最近做了一个 PHP2Shell 应急辅助网站，把公开响应头检查、PHP 版本比较和临时缓解配置整理到了一起，想分享给有 PHP 网站需要维护的朋友。
地址： https://checkphp2shell.com/
目前主要有几个功能：
● 输入公开域名，查看响应头是否暴露 PHP 版本，以及是否存在 PHP 、Laravel 、WordPress 等相关线索。
● 识别 Cloudflare 、Sucuri 、Akamai 、CloudFront 等边缘服务的公开标记。
● 手动输入实际 PHP 版本，核对修复版本门槛，并查看不同部署环境的配置示例。
● 提供 php.ini 、Nginx 、Apache 、Cloudflare WAF 、ModSecurity 、Docker/K8s 的配置引导。
想先把检测边界讲清楚：它检查的是公开响应头，结果只能作为排查线索。
对目标网站只发送普通 HEAD 请求，遇到明确不支持 HEAD 的响应时才回退 GET ，不发送漏洞利用载荷或 multipart POST ，也不跟随重定向。
响应头可能被隐藏、修改或缓存，因此：
● 没有发现 PHP 特征，不能证明网站没有使用 PHP 。
● 显示的版本达到修复门槛，不能确认实际软件包和所有 Web worker 都已更新。
● 发现 Cloudflare 等标记，不能确认 WAF 已启用，更不能确认规则能够覆盖相关攻击。
● 外部检查无法读取内部 php.ini ，也无法确认网站此前是否遭到入侵。
另外，页面里刻意区分了临时缓解和完整修复。
INI 配置和 WAF 规则可以在适用条件下降低部分攻击路径的风险，但不能当成完整修复。完整修复仍需要应用官方修复版本或经厂商确认的安全补丁，并验证实际处理 Web 请求的 PHP 实例和 worker 都已经使用修复后的构建。CLI 的
配置生成前需要重新确认版本、部署方式和适用前提，响应头里的版本不会自动被当成已经核实的服务器环境。
网站目前支持英语、日语、德语、西班牙语和葡萄牙语。欢迎大家试用，尤其想听听：结果说明是否容易理解、配置引导有没有遗漏，以及哪些措辞可能让人误以为“检查通过就代表安全”。
via V2EX (author: Tim99)
最近做了一个 PHP2Shell 应急辅助网站，把公开响应头检查、PHP 版本比较和临时缓解配置整理到了一起，想分享给有 PHP 网站需要维护的朋友。
地址： https://checkphp2shell.com/
目前主要有几个功能：
● 输入公开域名，查看响应头是否暴露 PHP 版本，以及是否存在 PHP 、Laravel 、WordPress 等相关线索。
● 识别 Cloudflare 、Sucuri 、Akamai 、CloudFront 等边缘服务的公开标记。
● 手动输入实际 PHP 版本，核对修复版本门槛，并查看不同部署环境的配置示例。
● 提供 php.ini 、Nginx 、Apache 、Cloudflare WAF 、ModSecurity 、Docker/K8s 的配置引导。
想先把检测边界讲清楚：它检查的是公开响应头，结果只能作为排查线索。
对目标网站只发送普通 HEAD 请求，遇到明确不支持 HEAD 的响应时才回退 GET ，不发送漏洞利用载荷或 multipart POST ，也不跟随重定向。
响应头可能被隐藏、修改或缓存，因此：
● 没有发现 PHP 特征，不能证明网站没有使用 PHP 。
● 显示的版本达到修复门槛，不能确认实际软件包和所有 Web worker 都已更新。
● 发现 Cloudflare 等标记，不能确认 WAF 已启用，更不能确认规则能够覆盖相关攻击。
● 外部检查无法读取内部 php.ini ，也无法确认网站此前是否遭到入侵。
另外，页面里刻意区分了临时缓解和完整修复。
INI 配置和 WAF 规则可以在适用条件下降低部分攻击路径的风险，但不能当成完整修复。完整修复仍需要应用官方修复版本或经厂商确认的安全补丁，并验证实际处理 Web 请求的 PHP 实例和 worker 都已经使用修复后的构建。CLI 的
php -v 也可能与网站实际运行的 PHP 不同。配置生成前需要重新确认版本、部署方式和适用前提，响应头里的版本不会自动被当成已经核实的服务器环境。
网站目前支持英语、日语、德语、西班牙语和葡萄牙语。欢迎大家试用，尤其想听听：结果说明是否容易理解、配置引导有没有遗漏，以及哪些措辞可能让人误以为“检查通过就代表安全”。
via V2EX (author: Tim99)