[分享创造] 给全球闷声发大财的网站做了一个排行榜
https://topcheckouts.000ooo.ooo
推特上晒 MRR 的人很多，但真正闷声发大财的人一般不说话。所以我换了个思路：不看谁自己说赚了多少，看每个月有多少人点进了它的付款页。
怎么做的
1. Similarweb 能看到哪些网站把流量导到 Stripe 、Gumroad 、Lemon Squeezy 、Polar 、Creem 、Whop 的付款页。我把 2026 年 4–9 月的引荐记录全拉了下来，一共 15,790 个网站。
2. 留下 9 月付费页访问 ≥ 3,000 的，剩 1,344 个。
3. 去掉付费流量超过一半的、大厂和融资公司、企业 B2B 、市场平台、主要靠联盟拉客的，最后剩 607 个。
4. 每个网站按新客主要从哪来归一类：SEO 171 个、AI 助手 6 个、社交媒体 79 个、病毒传播 126 个、其他 225 个。
前 5 名（ 9 月点进付款页的次数）
65 万｜ krillion.io ，每日猜谜小游戏
● 1,925 → 15 万 → 65 万：7 、8 、9 月的付费页访问，3 个月涨了 300 多倍。
● 2,700 万次：9 月网站访问，一半用户在美国。
● 59%：直接访问占比，搜的几乎全是站名，玩家每天自己回来。看起来是个人开发。
29 万｜ votremelodie.com ，法国定制歌曲礼物
● 0 → 29 万：4–8 月都是 0 ，9 月突然冒出来。
● 35%：邮件渠道占比，第二渠道是付费社交，还上过《世界报》。严格说它不算"闷声"。
20 万｜ wiki-masters.com ，用维基百科条目做卡牌的法语抽卡游戏
● 0 → 1.4 万 → 20 万：7 、8 、9 月的付费页访问。
● 91%：用户在法国。平均每次访问看 15.5 页，停留 15 分钟。
● 免费玩，新用户主要靠玩家拉朋友。
19 万｜ wavespeed.ai ，一个接口调用上千个 AI 图像、视频模型
● 9 月比 8 月掉了 34%。
● 新用户主要来自搜索 "video watermark remover"、"seedance 2.0" 这类具体需求。
18 万｜ starii.com ，旗下 5 款 AI 创作应用的公司官网
● 官网每月只有约 3 万访问，付款流量很可能来自旗下应用。
几个发现
● 6 个：新客主要靠 AI 助手的网站数，靠 SEO 的有 171 个。GEO 现在还远远当不了主渠道。
● 221 个：4–6 月还低于可见门槛、半年内冒出来的网站，超过三分之一。
● 很多是很冷门的刚需：监狱小卖部充值（每月 18 万次）、英国宠物芯片登记、英国医学考试题库、机票降价提醒会员（都在 4–5 万这一档）。
每个网站都有单独页面，能看到付费页访问走势、流量来源、搜索词、访客国家和定价。
口径说明
数字是 Similarweb 估算的"从这个网站跳到付款页的访问次数"。点开不等于付了钱，一个人点两次算两次，不能直接换算成收入。"发大财"是调侃，具体赚多少只有他们自己知道。
纯静态站，不用注册，有中英文两版。分类哪里不对、或者你知道哪些闷声发大财的网站没上榜，欢迎在下面补充。
地址： https://topcheckouts.000ooo.ooo
via V2EX (author: MaxSoloware)
https://topcheckouts.000ooo.ooo
推特上晒 MRR 的人很多，但真正闷声发大财的人一般不说话。所以我换了个思路：不看谁自己说赚了多少，看每个月有多少人点进了它的付款页。
怎么做的
1. Similarweb 能看到哪些网站把流量导到 Stripe 、Gumroad 、Lemon Squeezy 、Polar 、Creem 、Whop 的付款页。我把 2026 年 4–9 月的引荐记录全拉了下来，一共 15,790 个网站。
2. 留下 9 月付费页访问 ≥ 3,000 的，剩 1,344 个。
3. 去掉付费流量超过一半的、大厂和融资公司、企业 B2B 、市场平台、主要靠联盟拉客的，最后剩 607 个。
4. 每个网站按新客主要从哪来归一类：SEO 171 个、AI 助手 6 个、社交媒体 79 个、病毒传播 126 个、其他 225 个。
前 5 名（ 9 月点进付款页的次数）
65 万｜ krillion.io ，每日猜谜小游戏
● 1,925 → 15 万 → 65 万：7 、8 、9 月的付费页访问，3 个月涨了 300 多倍。
● 2,700 万次：9 月网站访问，一半用户在美国。
● 59%：直接访问占比，搜的几乎全是站名，玩家每天自己回来。看起来是个人开发。
29 万｜ votremelodie.com ，法国定制歌曲礼物
● 0 → 29 万：4–8 月都是 0 ，9 月突然冒出来。
● 35%：邮件渠道占比，第二渠道是付费社交，还上过《世界报》。严格说它不算"闷声"。
20 万｜ wiki-masters.com ，用维基百科条目做卡牌的法语抽卡游戏
● 0 → 1.4 万 → 20 万：7 、8 、9 月的付费页访问。
● 91%：用户在法国。平均每次访问看 15.5 页，停留 15 分钟。
● 免费玩，新用户主要靠玩家拉朋友。
19 万｜ wavespeed.ai ，一个接口调用上千个 AI 图像、视频模型
● 9 月比 8 月掉了 34%。
● 新用户主要来自搜索 "video watermark remover"、"seedance 2.0" 这类具体需求。
18 万｜ starii.com ，旗下 5 款 AI 创作应用的公司官网
● 官网每月只有约 3 万访问，付款流量很可能来自旗下应用。
几个发现
● 6 个：新客主要靠 AI 助手的网站数，靠 SEO 的有 171 个。GEO 现在还远远当不了主渠道。
● 221 个：4–6 月还低于可见门槛、半年内冒出来的网站，超过三分之一。
● 很多是很冷门的刚需：监狱小卖部充值（每月 18 万次）、英国宠物芯片登记、英国医学考试题库、机票降价提醒会员（都在 4–5 万这一档）。
每个网站都有单独页面，能看到付费页访问走势、流量来源、搜索词、访客国家和定价。
口径说明
数字是 Similarweb 估算的"从这个网站跳到付款页的访问次数"。点开不等于付了钱，一个人点两次算两次，不能直接换算成收入。"发大财"是调侃，具体赚多少只有他们自己知道。
纯静态站，不用注册，有中英文两版。分类哪里不对、或者你知道哪些闷声发大财的网站没上榜，欢迎在下面补充。
地址： https://topcheckouts.000ooo.ooo
via V2EX (author: MaxSoloware)
[程序员] 软件工程不会消失
-- AI 率 0% --
考虑一个软件系统是如何构建和迭代的，它可以被抽象为以下的一个 Loop：
需求建模 A->代码编写 A->需求反馈 A->需求建模 B->代码编写 B->需求反馈 B......
那么，我们如何定义一个完美的系统？给定系统 S ，用户需求的形式化描述为 R,对于所有针对系统的动作 A 的反馈,其不确定性都为 0(预期返回正确)，这里可以用条件熵来表示：∑H(R|S(A_i)) = 0 。而需求反馈本身则扮演了优化函数的作用，它的作用本身是引导条件熵 ∑H 向 0 优化，优化的过程则是降低各个流程的不确定性。
编程语言的演化，本质上是不断提高抽象程度，把越来越多的实现细节从程序员转移给编译器，编程语言是一种对于信息的 encoder 。现代语言使程序员用更少的描述表达所需行为，并把更多实现选择交给系统，失去了对底层代码的控制，引入了更多的不确定性（信息熵）。如果要加强对底层的控制，则需要用更底层的语言和更长的描述长度降低不确定性。即便是 AI Coding 也无法违背信息论的规律。程序员对系统的描述越短，系统的不确定性就更高，无法通过建立一个万能的预测器无尽地压缩描述来无损地描述系统本身，其存在一个理论下界，也就是柯氏复杂度；
这一点在需求建模流程也广泛存在着，用户的需求往往是在多轮迭代、描述、交互中产生的，需求方依旧是人，那么需求拆解、编写是一个无法避免的过程。
回过头来表达我的观点：
1.把复杂需求的实现寄希望于许愿式编程是不现实的，消除需求的不确定性和编码的不确定性是一个永恒的问题
2.AI Coding 时代，程序员可能会消失，但软件工程不会因为代码生成变得廉价而消失，反而会更重要。
via V2EX (author: gitlight)
-- AI 率 0% --
考虑一个软件系统是如何构建和迭代的，它可以被抽象为以下的一个 Loop：
需求建模 A->代码编写 A->需求反馈 A->需求建模 B->代码编写 B->需求反馈 B......
那么，我们如何定义一个完美的系统？给定系统 S ，用户需求的形式化描述为 R,对于所有针对系统的动作 A 的反馈,其不确定性都为 0(预期返回正确)，这里可以用条件熵来表示：∑H(R|S(A_i)) = 0 。而需求反馈本身则扮演了优化函数的作用，它的作用本身是引导条件熵 ∑H 向 0 优化，优化的过程则是降低各个流程的不确定性。
编程语言的演化，本质上是不断提高抽象程度，把越来越多的实现细节从程序员转移给编译器，编程语言是一种对于信息的 encoder 。现代语言使程序员用更少的描述表达所需行为，并把更多实现选择交给系统，失去了对底层代码的控制，引入了更多的不确定性（信息熵）。如果要加强对底层的控制，则需要用更底层的语言和更长的描述长度降低不确定性。即便是 AI Coding 也无法违背信息论的规律。程序员对系统的描述越短，系统的不确定性就更高，无法通过建立一个万能的预测器无尽地压缩描述来无损地描述系统本身，其存在一个理论下界，也就是柯氏复杂度；
这一点在需求建模流程也广泛存在着，用户的需求往往是在多轮迭代、描述、交互中产生的，需求方依旧是人，那么需求拆解、编写是一个无法避免的过程。
回过头来表达我的观点：
1.把复杂需求的实现寄希望于许愿式编程是不现实的，消除需求的不确定性和编码的不确定性是一个永恒的问题
2.AI Coding 时代，程序员可能会消失，但软件工程不会因为代码生成变得廉价而消失，反而会更重要。
via V2EX (author: gitlight)
[Android] 分享一个自己搞的安卓下载器开源项目
优点:
1. 多线程,种子跟磁力都支持,基本的都有
2. 下载核心框架拆分成 lib 库,可复用在其他的项目上
3. BT/磁力下载核心按需使用
https://github.com/mtdhllf/Tug-Android
via V2EX (author: mtdhllf)
优点:
1. 多线程,种子跟磁力都支持,基本的都有
2. 下载核心框架拆分成 lib 库,可复用在其他的项目上
3. BT/磁力下载核心按需使用
https://github.com/mtdhllf/Tug-Android
via V2EX (author: mtdhllf)
[产品经理茶话会] 别急着上智能体，有些问题一个对话框就够了
今年我们给一家专业类图书出版社做知识库应用。上线前搞了场内测，开完我感觉，这事我们做复杂了。
人家要的就是个“对话框” 需求其实评审会上就说清楚了，朴素到有点不像需求：能不能在网页上放个对话框，让人直接问问题。
就是读者、编辑、律师打开网页，输一句”夫妻共同债务怎么认定”，底下给一段带出处的回答。比搜索框多会说话。
我们最后交出去的东西技术上高级得多。535 本正版法学图书做了结构化检索，以 API 和 MCP 的形式开放，各种 AI 智能体都能调。
但要用上它，得走完这几步：先下载一个桌面客户端，网页端不支持；然后在客户端里配置知识库连接；再配置 API Key；然后才能提问。
内测会上，出版社同事的原话：
“第一步是要装那个本地化的智能体的这个服务，咱们才能用这个平台。网页端应该是用不了是吧？” “对，网页端用不了。” 现场还有一句更实在的：”关注点一个是这个沃克巴蒂什么的，没用过。”
后来我们才弄清楚人是怎么流失的。跟产品能力没关系，卡在门口：出版社里几乎没人用笔记本，都是台式机，C 盘还紧。有人压根没装成。
我们是从自己会做什么出发的，没从用户已经打开的那个窗口出发。
三种工具，成本差一个量级 这类问题我后来重新理了一遍。同样是解决问题，有三个层次，成本差得挺远。
能写代码的，就别上模型 很多被包装成”AI 问题”的，本质是查表比对。
还是这家出版社。编辑抱怨最多的是参考文献核验。一篇书稿一二十条参考文献，要逐条核对书名、作者、出版社、年份。现在靠什么？学生一条一条去知网、超星上人工查。
这事需要智能体吗。不需要，连大模型都不需要。
拿这 20 条书目信息，去 535 本的书目库里查一遍，比一下出版社和年份，返回”匹配 / 不匹配 / 未收录”。二十行脚本的事，或者做成网页上的一个表单，粘贴进去点一下出结果。
关键是它确定性，对就是对，错就是错，不会编。一次五分钱。
换成智能体来做，用户先装客户端、配 Key，然后问一个会说”我查了一下，这本书好像是……”的模型。一个要精确答案的活，交给了最不擅长精确的东西。
所以，这件事有标准答案、答案还能被验证，就用代码。
对话框够用的，别做成智能体 如果确实是自然语言问答，但只有一轮，问一句答一句，那就放个对话框。
用户输入问题，后台检索片段，模型组织成一段带出处的回答。不用装任何东西，打开就能用。
这才是那家出版社真正想要的。他们要的不是”接入 AI 生态”，是读者在网页上能问问题。
这两种做法成本差多少。我觉得不是差个百分之十，是差一个量级。
用户那边，一个要打开网页，一个要下载、安装、配置、授权，每一步都在筛人。运行那边，一次对话就是一次 API 调用，智能体要跑多轮、要调工具、要维护状态，token 和延迟都翻几倍。论出错，答得不好再问一次就行，智能体中途跑偏可能真的改错文件。
内测会上有个细节我印象挺深。有编辑问”积分用完了就用不了是吧”，还有人盯着”生成一份 PPT 消耗 31.49 积分”这个数字。用户开始算资源账，就说明你的方案对他来说重了。网页上放个对话框，不会有人焦虑这个。
智能体留给真正需要它的活 那什么时候值得上智能体。我觉得得同时满足三条：任务本身多步骤，中间结果要喂给下一步；要跨系统动手，读文件、调接口、改东西；用户愿意为它付安装成本。
比如把一批书稿自动排版，核对法条引用，再生成终稿。或者围绕一个话题把法规、案例、学理观点都检索一遍，最后出一份带引用的研究报告。这些活用户不可能靠问一句话拿到结果，那装一套环境的成本就值。
反过来，用户就想打开网页问个问题，你的智能体再强，他也不会为这个去装客户端。
我们为什么会选错 我后来复盘，原因有三个。
一个是想问题的方式不对。 做技术的人容易先想”这个我能不能做出来”“用新架构是不是更优雅”，我自己也是这样。但用户不关心你用了什么，他只关心自己现在的手在哪儿。他开着浏览器，你的方案就得从浏览器开始。
一个是”先进”这词有诱惑。 MCP、Agent、多智能体协作，这些词说出来有面子，做出来有成就感。给网页加个对话框太朴素了，朴素到不像个值得汇报的成果。但朴素常常是对的，因为朴素意味着用户不用学新东西。
还有一个，安装成本是用户掏的，不进你的账。 算成本的时候算的是 API 调用费、服务器、研发工期，没人会把”用户下载客户端失败”写进报表。它不在你表上，但它是真发生的。那场内测我们丢掉的不是钱，是第一天就没装成的那些人。
而且被筛掉的人不会告诉你为什么，他们只是不来了。
上手前问自己几句 有标准答案吗。有就写代码，别上模型。
用户现在在哪儿。如果他已经开着浏览器，入口就该在那儿。
这活需要多步骤、跨系统吗。一问一答能解决的，对话框够了。
他会为这件事装个客户端吗。一周只用一次的，答案是不会。
顺序大概是这样：能不能不做，能不能用代码，能不能用对话框，最后才轮到智能体。
最后 我不是说智能体没用。它贵、重、强，所以更不该拿去拧螺丝刀就能拧的那颗螺丝。
那家出版社要的东西最后看下来特别简单，一个网页上的对话框。我们做得出来，当时只是没往那个方向想。
via V2EX (author: wmxpop)
今年我们给一家专业类图书出版社做知识库应用。上线前搞了场内测，开完我感觉，这事我们做复杂了。
人家要的就是个“对话框” 需求其实评审会上就说清楚了，朴素到有点不像需求：能不能在网页上放个对话框，让人直接问问题。
就是读者、编辑、律师打开网页，输一句”夫妻共同债务怎么认定”，底下给一段带出处的回答。比搜索框多会说话。
我们最后交出去的东西技术上高级得多。535 本正版法学图书做了结构化检索，以 API 和 MCP 的形式开放，各种 AI 智能体都能调。
但要用上它，得走完这几步：先下载一个桌面客户端，网页端不支持；然后在客户端里配置知识库连接；再配置 API Key；然后才能提问。
内测会上，出版社同事的原话：
“第一步是要装那个本地化的智能体的这个服务，咱们才能用这个平台。网页端应该是用不了是吧？” “对，网页端用不了。” 现场还有一句更实在的：”关注点一个是这个沃克巴蒂什么的，没用过。”
后来我们才弄清楚人是怎么流失的。跟产品能力没关系，卡在门口：出版社里几乎没人用笔记本，都是台式机，C 盘还紧。有人压根没装成。
我们是从自己会做什么出发的，没从用户已经打开的那个窗口出发。
三种工具，成本差一个量级 这类问题我后来重新理了一遍。同样是解决问题，有三个层次，成本差得挺远。
能写代码的，就别上模型 很多被包装成”AI 问题”的，本质是查表比对。
还是这家出版社。编辑抱怨最多的是参考文献核验。一篇书稿一二十条参考文献，要逐条核对书名、作者、出版社、年份。现在靠什么？学生一条一条去知网、超星上人工查。
这事需要智能体吗。不需要，连大模型都不需要。
拿这 20 条书目信息，去 535 本的书目库里查一遍，比一下出版社和年份，返回”匹配 / 不匹配 / 未收录”。二十行脚本的事，或者做成网页上的一个表单，粘贴进去点一下出结果。
关键是它确定性，对就是对，错就是错，不会编。一次五分钱。
换成智能体来做，用户先装客户端、配 Key，然后问一个会说”我查了一下，这本书好像是……”的模型。一个要精确答案的活，交给了最不擅长精确的东西。
所以，这件事有标准答案、答案还能被验证，就用代码。
对话框够用的，别做成智能体 如果确实是自然语言问答，但只有一轮，问一句答一句，那就放个对话框。
用户输入问题，后台检索片段，模型组织成一段带出处的回答。不用装任何东西，打开就能用。
这才是那家出版社真正想要的。他们要的不是”接入 AI 生态”，是读者在网页上能问问题。
这两种做法成本差多少。我觉得不是差个百分之十，是差一个量级。
用户那边，一个要打开网页，一个要下载、安装、配置、授权，每一步都在筛人。运行那边，一次对话就是一次 API 调用，智能体要跑多轮、要调工具、要维护状态，token 和延迟都翻几倍。论出错，答得不好再问一次就行，智能体中途跑偏可能真的改错文件。
内测会上有个细节我印象挺深。有编辑问”积分用完了就用不了是吧”，还有人盯着”生成一份 PPT 消耗 31.49 积分”这个数字。用户开始算资源账，就说明你的方案对他来说重了。网页上放个对话框，不会有人焦虑这个。
智能体留给真正需要它的活 那什么时候值得上智能体。我觉得得同时满足三条：任务本身多步骤，中间结果要喂给下一步；要跨系统动手，读文件、调接口、改东西；用户愿意为它付安装成本。
比如把一批书稿自动排版，核对法条引用，再生成终稿。或者围绕一个话题把法规、案例、学理观点都检索一遍，最后出一份带引用的研究报告。这些活用户不可能靠问一句话拿到结果，那装一套环境的成本就值。
反过来，用户就想打开网页问个问题，你的智能体再强，他也不会为这个去装客户端。
我们为什么会选错 我后来复盘，原因有三个。
一个是想问题的方式不对。 做技术的人容易先想”这个我能不能做出来”“用新架构是不是更优雅”，我自己也是这样。但用户不关心你用了什么，他只关心自己现在的手在哪儿。他开着浏览器，你的方案就得从浏览器开始。
一个是”先进”这词有诱惑。 MCP、Agent、多智能体协作，这些词说出来有面子，做出来有成就感。给网页加个对话框太朴素了，朴素到不像个值得汇报的成果。但朴素常常是对的，因为朴素意味着用户不用学新东西。
还有一个，安装成本是用户掏的，不进你的账。 算成本的时候算的是 API 调用费、服务器、研发工期，没人会把”用户下载客户端失败”写进报表。它不在你表上，但它是真发生的。那场内测我们丢掉的不是钱，是第一天就没装成的那些人。
而且被筛掉的人不会告诉你为什么，他们只是不来了。
上手前问自己几句 有标准答案吗。有就写代码，别上模型。
用户现在在哪儿。如果他已经开着浏览器，入口就该在那儿。
这活需要多步骤、跨系统吗。一问一答能解决的，对话框够了。
他会为这件事装个客户端吗。一周只用一次的，答案是不会。
顺序大概是这样：能不能不做，能不能用代码，能不能用对话框，最后才轮到智能体。
最后 我不是说智能体没用。它贵、重、强，所以更不该拿去拧螺丝刀就能拧的那颗螺丝。
那家出版社要的东西最后看下来特别简单，一个网页上的对话框。我们做得出来，当时只是没往那个方向想。
via V2EX (author: wmxpop)
[程序员] iPhone 越来越重了，对比了下 15pro 至 18pro，每一代重量都在上升，现在的 18pro 已经到了 211 克了，快赶上之前的 16promax 了，更别说现在的 iPhone 折叠屏了
我现在用的 16promax ，因为之前体验感觉还好，但用久了后明显感觉还是有点笨重，尤其夏天裤子一塞就明显的坠落感，跑都没法跑，一跑短裤就往下掉，想着换个轻点的，结果一看 pro 系列越来越重，本来是想用 air 的，感觉各方面都不错，他的缺点续航、单摄啥的我都无所谓，就单杨我是真不好接受，不知道大家啥看法
via V2EX (author: coderMonkey)
我现在用的 16promax ，因为之前体验感觉还好，但用久了后明显感觉还是有点笨重，尤其夏天裤子一塞就明显的坠落感，跑都没法跑，一跑短裤就往下掉，想着换个轻点的，结果一看 pro 系列越来越重，本来是想用 air 的，感觉各方面都不错，他的缺点续航、单摄啥的我都无所谓，就单杨我是真不好接受，不知道大家啥看法
via V2EX (author: coderMonkey)
[推广] 做了个小工具：上传一张照片，几分钟生成一段竖屏 AI 跳舞视频
大家好，分享一个最近在做的小站： https://danceaigenerator.com/
它能做什么 上传一张人物正面照，选一个跳舞模板，几分钟后就能拿到一段 9:16 的竖屏跳舞视频，可以直接发抖音、TikTok 、Reels 或 Shorts 。
为什么做 刷短视频时经常看到「照片跳舞」这类内容。现有的工具要么要装 App ，要么步骤多、等得久。我想做一个打开网页就能用的版本：不装软件，流程尽量短。
用法
1 ）上传一张照片，正面、全身或半身、光线好的效果最好 2 ）选一个舞蹈模板 3 ）等生成，然后下载
目前的情况
1 ）只支持英文界面 2 ）照片角度太偏、有遮挡、背景很乱时，效果会差一些，还在优化
想听听大家的意见
生成效果和速度能不能接受？ 想要哪些舞蹈模板，或者现在哪些热门梗应该加进来？ 有 bug 或者体验不好的地方，欢迎直接回复，我会一条条看。
谢谢大家 🙏
via V2EX (author: zizhu2)
大家好，分享一个最近在做的小站： https://danceaigenerator.com/
它能做什么 上传一张人物正面照，选一个跳舞模板，几分钟后就能拿到一段 9:16 的竖屏跳舞视频，可以直接发抖音、TikTok 、Reels 或 Shorts 。
为什么做 刷短视频时经常看到「照片跳舞」这类内容。现有的工具要么要装 App ，要么步骤多、等得久。我想做一个打开网页就能用的版本：不装软件，流程尽量短。
用法
1 ）上传一张照片，正面、全身或半身、光线好的效果最好 2 ）选一个舞蹈模板 3 ）等生成，然后下载
目前的情况
1 ）只支持英文界面 2 ）照片角度太偏、有遮挡、背景很乱时，效果会差一些，还在优化
想听听大家的意见
生成效果和速度能不能接受？ 想要哪些舞蹈模板，或者现在哪些热门梗应该加进来？ 有 bug 或者体验不好的地方，欢迎直接回复，我会一条条看。
谢谢大家 🙏
via V2EX (author: zizhu2)
[分享创造] 做了个麦当劳 MCP 省钱助手「麦麦精算师」，一句话帮你算出最省点餐方案
最近麦当劳搞了个程序员创意开发大赛，基于他们开放的 MCP 能力开发 Skill 。
研究了一下他们家的 MCP ，提供了 33 个工具，覆盖点餐、领券、积分、活动日历等场景。发现一个痛点：精打细算的人吃顿麦当劳其实很累——
1. 先去麦麦省一张张领券
2. 翻菜单，记住自己有哪些券
3. 脑子里排列组合算哪个搭配最划算
4. 逐个试价格
5. 突然想起来看看积分快过期没
6. 再看看这周有什么活动
7. 终于下单了……但大概率没选到最优解
所以做了「麦麦精算师」，把上面 7 步压成一句话。
核心逻辑：
- auto-bind-coupons 一键全领券
- 拉菜单 × 优惠券做全组合，calculate-price 逐个算，取 Top3 最优
- 顺带检测积分过期 + 推荐兑换方案
- 拉当月活动日历，如果叠加活动更便宜会更新推荐
- 最后附一份营养报告（热量/蛋白质/脂肪/碳水）
用了 16 个 MCP 工具，是覆盖比较全的一个方案。
项目地址： https://github.com/qinruimac/mcd-smart-spender
支持两种用法：
1. 当 AgentSkill 用，加载 SKILL.md 到任意支持 MCP 的 AI 客户端
2. 命令行直接跑，python mcd_smart_spender.py
比赛按 GitHub Star 排名，如果觉得有点意思，求个 Star ⭐
也欢迎提建议和 PR ，比如比价策略还可以优化——目前是穷举热门品项，如果全菜单遍历组合数会爆炸，做了个 Top5 采样的折中。
via V2EX (author: d5n)
最近麦当劳搞了个程序员创意开发大赛，基于他们开放的 MCP 能力开发 Skill 。
研究了一下他们家的 MCP ，提供了 33 个工具，覆盖点餐、领券、积分、活动日历等场景。发现一个痛点：精打细算的人吃顿麦当劳其实很累——
1. 先去麦麦省一张张领券
2. 翻菜单，记住自己有哪些券
3. 脑子里排列组合算哪个搭配最划算
4. 逐个试价格
5. 突然想起来看看积分快过期没
6. 再看看这周有什么活动
7. 终于下单了……但大概率没选到最优解
所以做了「麦麦精算师」，把上面 7 步压成一句话。
核心逻辑：
- auto-bind-coupons 一键全领券
- 拉菜单 × 优惠券做全组合，calculate-price 逐个算，取 Top3 最优
- 顺带检测积分过期 + 推荐兑换方案
- 拉当月活动日历，如果叠加活动更便宜会更新推荐
- 最后附一份营养报告（热量/蛋白质/脂肪/碳水）
用了 16 个 MCP 工具，是覆盖比较全的一个方案。
项目地址： https://github.com/qinruimac/mcd-smart-spender
支持两种用法：
1. 当 AgentSkill 用，加载 SKILL.md 到任意支持 MCP 的 AI 客户端
2. 命令行直接跑，python mcd_smart_spender.py
比赛按 GitHub Star 排名，如果觉得有点意思，求个 Star ⭐
也欢迎提建议和 PR ，比如比价策略还可以优化——目前是穷举热门品项，如果全菜单遍历组合数会爆炸，做了个 Top5 采样的折中。
via V2EX (author: d5n)
[分享创造] 跨链转 USDT 之前，我现在固定核对这几项
以前觉得跨链就是选个币、填个地址、把数量发出去。真正会出错的地方不在价格，而在网络。Tron 上的 USDT 是 TRC20 ，Ethereum 上的 USDT 是 ERC20 。两边名字一样，却是两条链上的两种资产，不能直接转到对方的地址。
后来我换成一个固定顺序，用「付出 Tron 上的 USDT ，收到 Ethereum 上的 USDT 」做例子。
先看两边分别是什么。付出的必须是 Tron 上的 USDT ，收到的必须是 Ethereum 上的 USDT 。钱包里如果还停在别的网络，先改网络，再谈金额。
再看到账数量，而不是手续费百分比。页面上的服务费和网络成本，通常已经折进你最终能收到的数量。自己钱包里支付的那笔转出手续费一般另算。只拿一个百分比去和别的平台比，很容易比错。
然后整段核对 Ethereum 收款地址。地址或网络填错，链上撤不回来。收款方如果要求 Memo 或 Tag ，而订单页没有这一栏，这笔就不要付，换成自己的钱包地址。
最后看失败了怎么办。下单时填一个自己控制的 Tron 地址当退款地址。路线走不成，钱才有地方回去。没到账之前，不要按同一个充值地址再转一笔，第二笔通常会被当成新订单。
第一笔我只换很小的金额。到账地址、网络和数量都对上，再换剩下的。这五步比多比较一次价格有用。
via V2EX (author: yaobawu66)
以前觉得跨链就是选个币、填个地址、把数量发出去。真正会出错的地方不在价格，而在网络。Tron 上的 USDT 是 TRC20 ，Ethereum 上的 USDT 是 ERC20 。两边名字一样，却是两条链上的两种资产，不能直接转到对方的地址。
后来我换成一个固定顺序，用「付出 Tron 上的 USDT ，收到 Ethereum 上的 USDT 」做例子。
先看两边分别是什么。付出的必须是 Tron 上的 USDT ，收到的必须是 Ethereum 上的 USDT 。钱包里如果还停在别的网络，先改网络，再谈金额。
再看到账数量，而不是手续费百分比。页面上的服务费和网络成本，通常已经折进你最终能收到的数量。自己钱包里支付的那笔转出手续费一般另算。只拿一个百分比去和别的平台比，很容易比错。
然后整段核对 Ethereum 收款地址。地址或网络填错，链上撤不回来。收款方如果要求 Memo 或 Tag ，而订单页没有这一栏，这笔就不要付，换成自己的钱包地址。
最后看失败了怎么办。下单时填一个自己控制的 Tron 地址当退款地址。路线走不成，钱才有地方回去。没到账之前，不要按同一个充值地址再转一笔，第二笔通常会被当成新订单。
第一笔我只换很小的金额。到账地址、网络和数量都对上，再换剩下的。这五步比多比较一次价格有用。
via V2EX (author: yaobawu66)
[问与答] 问一个问题： iPhone 上 Safari 差在哪里？
最近做一个浏览器，突然有一个感觉：发现常用的浏览功能，Safari 并没有太差，但是需要的播放视频、下载视频功能，Safari 上没有
手机上常用的 Aloha 、Brave 、Alook 我都安装了。
- 觉得目前 Aloha 启动有点重，给人的感觉慢，但是其他都完美，下载视频、视频播放、广告屏蔽、云等等。
- Brave 感觉比 Aloha 稍微轻一点，尤其是开了 Origin ，然后把 Web3 相关的屏蔽之后，但是 Brave 的问题是，播放器太笨了，跟 Safari 一样。好的一点是看 Youtube 顺。。。
- Alook ，最轻量，感觉打开很快，但是呢，不能下载视频，而且偶尔会卡死，也常年不更新
我觉得 Brave 的启动 + Aloha 的视频 + 广告拦截对我来说应该就够了。。。而如果为了这个做一个完整的浏览器，觉得有点费事了。。。
大家还有觉得 Safari 哪里不够好的吗？
via V2EX (author: mokong)
最近做一个浏览器，突然有一个感觉：发现常用的浏览功能，Safari 并没有太差，但是需要的播放视频、下载视频功能，Safari 上没有
手机上常用的 Aloha 、Brave 、Alook 我都安装了。
- 觉得目前 Aloha 启动有点重，给人的感觉慢，但是其他都完美，下载视频、视频播放、广告屏蔽、云等等。
- Brave 感觉比 Aloha 稍微轻一点，尤其是开了 Origin ，然后把 Web3 相关的屏蔽之后，但是 Brave 的问题是，播放器太笨了，跟 Safari 一样。好的一点是看 Youtube 顺。。。
- Alook ，最轻量，感觉打开很快，但是呢，不能下载视频，而且偶尔会卡死，也常年不更新
我觉得 Brave 的启动 + Aloha 的视频 + 广告拦截对我来说应该就够了。。。而如果为了这个做一个完整的浏览器，觉得有点费事了。。。
大家还有觉得 Safari 哪里不够好的吗？
via V2EX (author: mokong)
[分享创造] 我在一个 3 周前的新词上做了个站，想测一下 GEO 到底有没有用，会持续更新数据
做了一个站：tiptoeinginmyjordansmeme.org。
目的是想做个 GEO 实验，社群现在对 GEO 的讨论基本靠猜。
这个梗是今年 10 月 1 日才起来的（Know Your Meme 记的最早一条）。我看到窗口期就上了站，但是表现并不好
我现在想测下 geo 而不是 seo：对一个新词站，「llms.txt + 结构化数据 + 事实密度 + 来源标注」这一套 GEO 处理，能不能让 AI 在回答相关问题时引用它？
我的想法是：
1. 爬虫日志，记录 GPTBot、PerplexityBot、ClaudeBot、OAI-SearchBot 的请求数和抓取的页面。
2. GA4 里 chatgpt.com、perplexity.ai 这些来源的引荐会话。
3. 每天在 4 个 AI 里问 12 个固定问题，看有没有被提到
我手上还有一个做同一个词的站，本来想拿它当对照组（一个做 GEO 处理、一个不动），但两个站内容如果太像，可能互相蚕食，或者被 AI 当成重复内容只引用一个。这样对照就不成立了。
后续数据我会在这个帖子里更新。
via V2EX (author: wytdh)
做了一个站：tiptoeinginmyjordansmeme.org。
目的是想做个 GEO 实验，社群现在对 GEO 的讨论基本靠猜。
这个梗是今年 10 月 1 日才起来的（Know Your Meme 记的最早一条）。我看到窗口期就上了站，但是表现并不好
我现在想测下 geo 而不是 seo：对一个新词站，「llms.txt + 结构化数据 + 事实密度 + 来源标注」这一套 GEO 处理，能不能让 AI 在回答相关问题时引用它？
我的想法是：
1. 爬虫日志，记录 GPTBot、PerplexityBot、ClaudeBot、OAI-SearchBot 的请求数和抓取的页面。
2. GA4 里 chatgpt.com、perplexity.ai 这些来源的引荐会话。
3. 每天在 4 个 AI 里问 12 个固定问题，看有没有被提到
我手上还有一个做同一个词的站，本来想拿它当对照组（一个做 GEO 处理、一个不动），但两个站内容如果太像，可能互相蚕食，或者被 AI 当成重复内容只引用一个。这样对照就不成立了。
后续数据我会在这个帖子里更新。
via V2EX (author: wytdh)
[程序员] 不是我说，成都这地方当码农简直是灾难级别，成都的程序员真能顶啊？
之前一直在北京工作，2024 年来成都，老婆体制内工作，今时不同往日，私企就是一坨，我这种私企牛马当然是决定跟着老婆走，就准备在成都这随便干干，找了两份工作，工资是以前的三分之一，一个干着干着投资人跑路（我顺走一台主机+一个显示器），另一个干着干着老板看我不顺眼（说我普通话太好，穿衣打扮太得体，能力太强不服管教）开了我，属实难绷。而且我发现成都这的小土老板普遍不遵守劳动法，并且毫无人文关怀，基本都是加入世贸突然起飞或者拆迁的暴发户，素质情商能力极低。西南柬埔寨诚不欺我。
via V2EX (author: lmmlwen)
之前一直在北京工作，2024 年来成都，老婆体制内工作，今时不同往日，私企就是一坨，我这种私企牛马当然是决定跟着老婆走，就准备在成都这随便干干，找了两份工作，工资是以前的三分之一，一个干着干着投资人跑路（我顺走一台主机+一个显示器），另一个干着干着老板看我不顺眼（说我普通话太好，穿衣打扮太得体，能力太强不服管教）开了我，属实难绷。而且我发现成都这的小土老板普遍不遵守劳动法，并且毫无人文关怀，基本都是加入世贸突然起飞或者拆迁的暴发户，素质情商能力极低。西南柬埔寨诚不欺我。
via V2EX (author: lmmlwen)