[OpenWrt] [分享] 用 AI 搓了两个 OpenWrt 小工具： eBPF PPPoE Relay 和 Fake Flow
最近闲着没事，借助 AI 搓了两个 OpenWrt 网络小工具，分享给有需要的朋友折腾一下。😂
1. pppoe-relay-bpf
GitHub： https://github.com/lilu0826/pppoe-relay-bpf
基于 eBPF 的 PPPoE Relay 加速工具，主要用于优化 PPPoE Relay 转发性能，减少用户态转发带来的 CPU 开销，适合有多拨、PPPoE 中继需求的朋友。
2. fake-flow
GitHub： https://github.com/lilu0826/fake-flow
属于是一个 fakehttp 和 fakesip 的整合体，让 AI 参照了这两个搞得
一个用于网络流量伪装实验的小工具，可以构造特定的流量特征，用于研究和测试运营商 DPI 识别及流量管理策略。
两个项目都是自己折腾网络时遇到需求，然后借助 AI 一点点写出来的，代码谈不上多专业，主打一个能用就行。🤣
有兴趣的朋友可以试试。
via V2EX (author: lilu0826)
最近闲着没事，借助 AI 搓了两个 OpenWrt 网络小工具，分享给有需要的朋友折腾一下。😂
1. pppoe-relay-bpf
GitHub： https://github.com/lilu0826/pppoe-relay-bpf
基于 eBPF 的 PPPoE Relay 加速工具，主要用于优化 PPPoE Relay 转发性能，减少用户态转发带来的 CPU 开销，适合有多拨、PPPoE 中继需求的朋友。
2. fake-flow
GitHub： https://github.com/lilu0826/fake-flow
属于是一个 fakehttp 和 fakesip 的整合体，让 AI 参照了这两个搞得
一个用于网络流量伪装实验的小工具，可以构造特定的流量特征，用于研究和测试运营商 DPI 识别及流量管理策略。
两个项目都是自己折腾网络时遇到需求，然后借助 AI 一点点写出来的，代码谈不上多专业，主打一个能用就行。🤣
有兴趣的朋友可以试试。
via V2EX (author: lilu0826)
[推广] 数万开发者在用的 Claude 中转，新人领 10 美元
上周群里一位做独立开发的朋友私信我：“账单能再细一点吗？我想知道哪个项目最烧钱。”
我说后台的用量记录本来就有，每次请求的模型、tokens 和扣费都能看到，给每个项目单独开一个 Key ，分开看就清楚了。对方愣了一下，说之前用的那家只给一个总数，月底对账基本靠猜。
聊到最后，对方又问：国内能直连吗？能，不用挂梯子，Claude Code 里改一下 BASE_URL 就能跑。
现在 aicoding.inc 有数万人在用，这类问题我几乎每天都在回。想自己看看后台是什么样，加群送 10 美元额度，跑几个请求就知道了。
https://aicoding.inc
via V2EX (author: aicodinginc)
上周群里一位做独立开发的朋友私信我：“账单能再细一点吗？我想知道哪个项目最烧钱。”
我说后台的用量记录本来就有，每次请求的模型、tokens 和扣费都能看到，给每个项目单独开一个 Key ，分开看就清楚了。对方愣了一下，说之前用的那家只给一个总数，月底对账基本靠猜。
聊到最后，对方又问：国内能直连吗？能，不用挂梯子，Claude Code 里改一下 BASE_URL 就能跑。
现在 aicoding.inc 有数万人在用，这类问题我几乎每天都在回。想自己看看后台是什么样，加群送 10 美元额度，跑几个请求就知道了。
https://aicoding.inc
via V2EX (author: aicodinginc)
[问与答] ChatGPT Plus 土区老用户 500 里拉订阅价，断订后重新续费还是保持原来的价格吗？
目前 ChatGPT Plus 土区的订阅价格已经从每月 499.99 里拉涨到了 999.99 里拉，但之前订阅的老用户仍然可以按照 499.99 里拉续费。
想请教一下大家：
如果主动取消自动续费，等会员到期后再重新订阅，还能享受原来的 499.99 里拉价格吗？还是会直接按照新价格收费？
如果 Apple ID 余额不足导致自动扣费失败，过几天充值后恢复订阅，是否也会失去老用户价格？
有没有实际经历过断订后重新续费的朋友？
主要想确认一下这个老用户价格是否必须保持连续订阅才能保留。
希望有实际经历的朋友分享一下，感谢！
via V2EX (author: Parameter)
目前 ChatGPT Plus 土区的订阅价格已经从每月 499.99 里拉涨到了 999.99 里拉，但之前订阅的老用户仍然可以按照 499.99 里拉续费。
想请教一下大家：
如果主动取消自动续费，等会员到期后再重新订阅，还能享受原来的 499.99 里拉价格吗？还是会直接按照新价格收费？
如果 Apple ID 余额不足导致自动扣费失败，过几天充值后恢复订阅，是否也会失去老用户价格？
有没有实际经历过断订后重新续费的朋友？
主要想确认一下这个老用户价格是否必须保持连续订阅才能保留。
希望有实际经历的朋友分享一下，感谢！
via V2EX (author: Parameter)
[分享发现] 昨天我送走了 5 位同事
前言
昨天送走了五个同事，两个人跟我进行了交接。 明白回到这一天，但是没想到这么快。
2024 被裁
2024 年， 我被上家公司裁员，开开心心拿了大礼包。随后开始找工作，找了 1 个月，免了近 20 家， 在社保没有断缴的情况下入职了。
2024 入职
如果说有那么一家创业公司，大家跟随着三个创始人满腔热血的进入 AI 事业， 背靠上市公司。 在 AI 泡沫越来越大的 2024 年， 大家充满干劲，我估计我还是会再选一次，哈哈哈。
一起努力
大家经为了参加 WAIC （世界人工智能大会），经历过熬夜加班， 跟摄像老师反复确定 demo 。 用的 F3 拍摄，但是最终播放在大果冻屏幕上；
也经历过为了商业化项目，连续 9-12-5 ， 干了两周，大家后面都请了病假。 虽然后续没卖多少；
也为了机器人项目出差熬夜 虽然也快黄了；
风向变了
创始人是公司的灵魂， 但是身体已经被卖给了资本，身不由衷。方向是集团控制的，在沟通不顺的情况下，CXO 还是选择离职， 当创始人离开的时候， 这个公司基本上就是没了。在 3 个月后，也就是今天， 基本上这层楼的空了。我也送走了很多同事。 当然谁 tm 来送我呢， 估计大礼包都会因为申请破产而泡汤。
下一步
如果不出意外，我可能会再更新一版《 2026 提桶记录》
不过这一次，我打算给我自己半年的时间， 这一次我要为自己加班，这一次我要为谈客户，签合同。 总之感谢公司，感谢集团，给我这两年的时间成长。 如果不是今年安排我去趟深圳，可能我还是会去找工作，男人到了年纪，真的会想做自己的事情。 也感谢 AI 这个时代，不论结果， 还是得试一试。
via V2EX (author: 312ybj)
前言
昨天送走了五个同事，两个人跟我进行了交接。 明白回到这一天，但是没想到这么快。
2024 被裁
2024 年， 我被上家公司裁员，开开心心拿了大礼包。随后开始找工作，找了 1 个月，免了近 20 家， 在社保没有断缴的情况下入职了。
2024 入职
如果说有那么一家创业公司，大家跟随着三个创始人满腔热血的进入 AI 事业， 背靠上市公司。 在 AI 泡沫越来越大的 2024 年， 大家充满干劲，我估计我还是会再选一次，哈哈哈。
一起努力
大家经为了参加 WAIC （世界人工智能大会），经历过熬夜加班， 跟摄像老师反复确定 demo 。 用的 F3 拍摄，但是最终播放在大果冻屏幕上；
也经历过为了商业化项目，连续 9-12-5 ， 干了两周，大家后面都请了病假。 虽然后续没卖多少；
也为了机器人项目出差熬夜 虽然也快黄了；
风向变了
创始人是公司的灵魂， 但是身体已经被卖给了资本，身不由衷。方向是集团控制的，在沟通不顺的情况下，CXO 还是选择离职， 当创始人离开的时候， 这个公司基本上就是没了。在 3 个月后，也就是今天， 基本上这层楼的空了。我也送走了很多同事。 当然谁 tm 来送我呢， 估计大礼包都会因为申请破产而泡汤。
下一步
如果不出意外，我可能会再更新一版《 2026 提桶记录》
不过这一次，我打算给我自己半年的时间， 这一次我要为自己加班，这一次我要为谈客户，签合同。 总之感谢公司，感谢集团，给我这两年的时间成长。 如果不是今年安排我去趟深圳，可能我还是会去找工作，男人到了年纪，真的会想做自己的事情。 也感谢 AI 这个时代，不论结果， 还是得试一试。
via V2EX (author: 312ybj)
[Apple] IOS 的黑苹果是不是不远了
https://github.com/oosexgang/hackios-xnu-kernel 这个项目把 IOS16.5 安装在了安卓手机上，不过没有蜂窝网络和 applestore ，但是可以在 wifi 下巨魔自己装软件吧
via V2EX (author: Himmel)
https://github.com/oosexgang/hackios-xnu-kernel 这个项目把 IOS16.5 安装在了安卓手机上，不过没有蜂窝网络和 applestore ，但是可以在 wifi 下巨魔自己装软件吧
via V2EX (author: Himmel)
[分享创造] 花了两周做了个 bra size 计算器，纯静态 + Cloudflare Pages，聊聊选词和计算逻辑
最近花了两周时间，做了一个面向美国用户的 bra size 计算器： https://brascale.com/
整个站是纯静态的，没有后端、没有数据库，部署在 Cloudflare Pages 上。目前做了四个页面，核心功能就是根据用户输入的身体围度，计算一个参考内衣尺码。
做这个项目的初衷很简单：想试试用一个足够轻量的工具站，从关键词研究、页面设计到计算逻辑，再到 SEO 部署，完整跑一遍流程。
记录一下过程中比较值得分享的几个地方。
一、为什么选这个方向？
一开始并没有直接写代码，而是先看关键词。
美国用户搜索内衣尺码相关问题时，会涉及很多不同的搜索意图，比如：
● bra size calculator
● band size calculator
● sister size calculator
● bra size conversion
这些词看起来都和同一个需求有关，但用户真正想解决的问题不完全一样。
主词的竞争通常比较激烈，成熟的大站已经有相对完善的页面、外链和品牌积累。新站如果一上来就想竞争最宽泛的关键词，可能很长时间都没有什么结果。
所以我选择先从细分需求入手。
比如，有的人只想知道自己的下胸围应该对应什么 band size；有的人已经知道自己的尺码，只是想找姊妹码；还有的人想弄明白英寸和厘米之间的换算。
这些需求虽然相关，但完全可以分别设计页面，让每个页面尽量解决一个明确的问题。
这里也不是说长尾关键词一定比主词容易做，而是对于一个没有太多资源的新站，先把具体需求研究清楚，比直接冲最热门的词更有操作性。
关键词研究最后还是要回到搜索结果本身：看看现有页面解决了什么问题、有没有信息缺口，以及自己能不能做出更清晰、更方便使用的工具。
二、尺码计算逻辑，比写页面麻烦多了
这是整个项目里我觉得最值得花时间研究的部分。
内衣尺码计算并不是简单地把两个数字相减，再查一张表就完事了。不同品牌、国家和计算体系可能存在差异，如果直接照搬网上的一张旧表，很容易出现结果看起来合理、实际上却不太对的情况。
我在实现时，主要处理了下面几个问题。
1. 统一计算单位
内部计算以英寸为基准。
如果用户输入的是厘米，先转换成英寸：
inches = cm / 2.54
这样后续的 band、bust 和 cup 计算都使用同一套单位，避免在不同单位之间反复计算造成误差。
显示结果时再根据用户选择的单位进行转换。
2. Band size 怎么取？
这里采用下胸围取最近偶数的规则。
例如，下胸围测量值是 31 英寸，按最近偶数取值会得到 32 band。
这个步骤看起来简单，但需要注意测量值处于两个偶数中间时的处理方式，以及输入精度和四舍五入规则，否则不同页面可能算出不同结果。
3. Cup size 怎么算？
基本思路是用上胸围与下胸围之间的差值作为参考：
差值 = 上胸围 − 下胸围
然后根据差值映射到对应的罩杯。
我采用的映射规则中，差值小于 1 英寸时对应 AA，后续再按照设定的区间映射到其他罩杯。
这里需要强调一点：这是一套明确的计算规则，不代表所有品牌都使用完全相同的尺码体系。实际穿着效果还会受到品牌版型、胸型和测量方式的影响。
4. 姊妹码怎么换算？
姊妹码（Sister Sizes）的基本规律是：
● Band 增加 2，Cup 字母通常向下调整一级。
● Band 减少 2，Cup 字母通常向上调整一级。
例如，34C 的姊妹码通常包括 32D 和 36B。
原理是通过调整下胸围，同时调整罩杯容积，使不同尺码之间尽量保持接近的罩杯容量。
实现时不能只做字符串替换，还要处理罩杯字母的顺序、边界情况，以及不同尺码体系的差异。
5. 最麻烦的是 plus-four 算法
我在研究旧尺码表时，发现一个很容易造成误判的问题：plus-four 算法。
一些传统计算方法会先根据下胸围增加 4 英寸，再推算 band size。
这会产生一个很明显的差异：29–30 英寸的下胸围，经过某些旧式规则处理后，可能会被归到 34 band。
如果用户习惯的是不额外加 4 英寸的现代测量方式，这个结果就可能让人困惑。
因此，我没有直接把网上找到的旧 chart 当成唯一标准，而是明确采用自己的计算规则，并尽量让输入、换算和结果展示遵循同一套逻辑。
这也是我觉得工具站开发中很容易被低估的一件事：代码本身可能只需要几十行，但你得先搞清楚自己到底在实现哪一种规则。
三、为什么选纯静态 + Cloudflare Pages？
目前整个网站使用纯静态页面，没有专门的后端服务，也没有数据库。
选择这套方案，主要有几个原因：
1. 计算可以在浏览器本地完成。 用户输入围度后，直接通过 JavaScript 计算结果，不需要把数据发送到服务器。
2. 部署简单。 页面构建完成后直接部署到 Cloudflare Pages，不需要维护服务器、数据库和 API。
3. 访问速度和维护成本比较友好。 对于计算逻辑简单、数据量不大的工具站，没有必要为了技术架构而增加复杂度。
另外，页面里的图形尽量使用内联 SVG，而不是随便找一些模特照片或者商品图片。
一方面是版权问题，另一方面是工具本身也不需要大量照片才能完成任务。
如果以后考虑接入 AdSense，图片版权和页面内容质量也值得提前考虑。不过，使用 SVG 并不意味着自动符合 AdSense 政策，最终还是要看整个网站的内容质量、实用性和政策合规情况。
对这种小型工具站来说，我更倾向于先把核心功能和页面体验做好，而不是先堆很多视觉元素。
四、部署和 SEO 过程中踩过的坑
纯静态站不代表上线就万事大吉，域名和搜索引擎相关的细节也需要处理。
1. www 和裸域的统一
例如：
● brascale.com
● www.brascale.com
如果两个地址都能正常访问，却没有统一的规范域名，可能会给网站的索引和维护带来不必要的复杂性。
所以需要明确一个主域名，并将另一个域名通过 301 重定向过去。
这里要注意，不只是首页，其他页面的路径也应该正确保留，避免所有地址都被错误地重定向到首页。
2. Sitemap 和规范 URL
Sitemap 需要列出希望搜索引擎发现的规范页面地址，并且确保这些地址实际可以正常访问。
我在处理 URL 时也特别关注了尾斜杠的一致性。
严格来说，sitemap 并不是必须全部带尾斜杠，而是要和网站实际使用的规范 URL 保持一致。如果
因此，最好提前确定 URL 规则，再统一处理页面内部链接、canonical 标签和 sitemap。
3. 纯静态网站也需要考虑 SEO
工具站很容易出现一种情况：功能确实能用，但搜索引擎看到的页面内容非常少。
所以每个页面除了计算器本身，还需要清楚地解释：
● 这个工具解决什么问题；
● 输入的数据应该如何测量；
● 计算结果是怎么得出的；
● 结果有哪些局限；
● 用户接下来可以做什么。
这些内容不只是为了 SEO，也是为了让用户真正理解计算结果。
五、接下来准备观察什么？
网站上线只是第一步，接下来更值得关注的是实际数据。
我比较关心几个问题：
● 细分关键词能不能带来真实的搜索流量；
● 用户更常使用主计算器，还是某个具体的细分工具；
● 搜索用户进入页面后，是否真的完成计算；
● 哪些页面值得继续投入时间优化。
对小工具站来说，开发完成并不意味着项目验证成功。真正重要的是能不能找到明确的用户需求，并通过搜索流量持续获得用户。
如果最后发现某些关键词没有流量，或者用户需求和预期不一致，也需要根据数据调整，而不是不断增加功能。
目前先把第一版跑起来，后续再根据真实反馈迭代。
网站放这里： https://brascale.com/
如果大家也做过面向海外用户的纯静态工具站，尤其是通过 SEO 获取自然流量的，欢迎交流一下：你们通常会先做一个覆盖面比较广的主工具，还是先从几个具体的长尾需求切入？
via V2EX (author: sobinyuan)
最近花了两周时间，做了一个面向美国用户的 bra size 计算器： https://brascale.com/
整个站是纯静态的，没有后端、没有数据库，部署在 Cloudflare Pages 上。目前做了四个页面，核心功能就是根据用户输入的身体围度，计算一个参考内衣尺码。
做这个项目的初衷很简单：想试试用一个足够轻量的工具站，从关键词研究、页面设计到计算逻辑，再到 SEO 部署，完整跑一遍流程。
记录一下过程中比较值得分享的几个地方。
一、为什么选这个方向？
一开始并没有直接写代码，而是先看关键词。
美国用户搜索内衣尺码相关问题时，会涉及很多不同的搜索意图，比如：
● bra size calculator
● band size calculator
● sister size calculator
● bra size conversion
这些词看起来都和同一个需求有关，但用户真正想解决的问题不完全一样。
主词的竞争通常比较激烈，成熟的大站已经有相对完善的页面、外链和品牌积累。新站如果一上来就想竞争最宽泛的关键词，可能很长时间都没有什么结果。
所以我选择先从细分需求入手。
比如，有的人只想知道自己的下胸围应该对应什么 band size；有的人已经知道自己的尺码，只是想找姊妹码；还有的人想弄明白英寸和厘米之间的换算。
这些需求虽然相关，但完全可以分别设计页面，让每个页面尽量解决一个明确的问题。
这里也不是说长尾关键词一定比主词容易做，而是对于一个没有太多资源的新站，先把具体需求研究清楚，比直接冲最热门的词更有操作性。
关键词研究最后还是要回到搜索结果本身：看看现有页面解决了什么问题、有没有信息缺口，以及自己能不能做出更清晰、更方便使用的工具。
二、尺码计算逻辑，比写页面麻烦多了
这是整个项目里我觉得最值得花时间研究的部分。
内衣尺码计算并不是简单地把两个数字相减，再查一张表就完事了。不同品牌、国家和计算体系可能存在差异，如果直接照搬网上的一张旧表，很容易出现结果看起来合理、实际上却不太对的情况。
我在实现时，主要处理了下面几个问题。
1. 统一计算单位
内部计算以英寸为基准。
如果用户输入的是厘米，先转换成英寸：
inches = cm / 2.54
这样后续的 band、bust 和 cup 计算都使用同一套单位，避免在不同单位之间反复计算造成误差。
显示结果时再根据用户选择的单位进行转换。
2. Band size 怎么取？
这里采用下胸围取最近偶数的规则。
例如，下胸围测量值是 31 英寸，按最近偶数取值会得到 32 band。
这个步骤看起来简单，但需要注意测量值处于两个偶数中间时的处理方式，以及输入精度和四舍五入规则，否则不同页面可能算出不同结果。
3. Cup size 怎么算？
基本思路是用上胸围与下胸围之间的差值作为参考：
差值 = 上胸围 − 下胸围
然后根据差值映射到对应的罩杯。
我采用的映射规则中，差值小于 1 英寸时对应 AA，后续再按照设定的区间映射到其他罩杯。
这里需要强调一点：这是一套明确的计算规则，不代表所有品牌都使用完全相同的尺码体系。实际穿着效果还会受到品牌版型、胸型和测量方式的影响。
4. 姊妹码怎么换算？
姊妹码（Sister Sizes）的基本规律是：
● Band 增加 2，Cup 字母通常向下调整一级。
● Band 减少 2，Cup 字母通常向上调整一级。
例如，34C 的姊妹码通常包括 32D 和 36B。
原理是通过调整下胸围，同时调整罩杯容积，使不同尺码之间尽量保持接近的罩杯容量。
实现时不能只做字符串替换，还要处理罩杯字母的顺序、边界情况，以及不同尺码体系的差异。
5. 最麻烦的是 plus-four 算法
我在研究旧尺码表时，发现一个很容易造成误判的问题：plus-four 算法。
一些传统计算方法会先根据下胸围增加 4 英寸，再推算 band size。
这会产生一个很明显的差异：29–30 英寸的下胸围，经过某些旧式规则处理后，可能会被归到 34 band。
如果用户习惯的是不额外加 4 英寸的现代测量方式，这个结果就可能让人困惑。
因此，我没有直接把网上找到的旧 chart 当成唯一标准，而是明确采用自己的计算规则，并尽量让输入、换算和结果展示遵循同一套逻辑。
这也是我觉得工具站开发中很容易被低估的一件事：代码本身可能只需要几十行，但你得先搞清楚自己到底在实现哪一种规则。
三、为什么选纯静态 + Cloudflare Pages？
目前整个网站使用纯静态页面，没有专门的后端服务，也没有数据库。
选择这套方案，主要有几个原因：
1. 计算可以在浏览器本地完成。 用户输入围度后，直接通过 JavaScript 计算结果，不需要把数据发送到服务器。
2. 部署简单。 页面构建完成后直接部署到 Cloudflare Pages，不需要维护服务器、数据库和 API。
3. 访问速度和维护成本比较友好。 对于计算逻辑简单、数据量不大的工具站，没有必要为了技术架构而增加复杂度。
另外，页面里的图形尽量使用内联 SVG，而不是随便找一些模特照片或者商品图片。
一方面是版权问题，另一方面是工具本身也不需要大量照片才能完成任务。
如果以后考虑接入 AdSense，图片版权和页面内容质量也值得提前考虑。不过，使用 SVG 并不意味着自动符合 AdSense 政策，最终还是要看整个网站的内容质量、实用性和政策合规情况。
对这种小型工具站来说，我更倾向于先把核心功能和页面体验做好，而不是先堆很多视觉元素。
四、部署和 SEO 过程中踩过的坑
纯静态站不代表上线就万事大吉，域名和搜索引擎相关的细节也需要处理。
1. www 和裸域的统一
例如：
● brascale.com
● www.brascale.com
如果两个地址都能正常访问，却没有统一的规范域名，可能会给网站的索引和维护带来不必要的复杂性。
所以需要明确一个主域名，并将另一个域名通过 301 重定向过去。
这里要注意，不只是首页，其他页面的路径也应该正确保留，避免所有地址都被错误地重定向到首页。
2. Sitemap 和规范 URL
Sitemap 需要列出希望搜索引擎发现的规范页面地址，并且确保这些地址实际可以正常访问。
我在处理 URL 时也特别关注了尾斜杠的一致性。
严格来说，sitemap 并不是必须全部带尾斜杠，而是要和网站实际使用的规范 URL 保持一致。如果
/page 和 /page/ 的处理不统一，就可能出现重复 URL、重定向链或者错误的规范地址。因此，最好提前确定 URL 规则，再统一处理页面内部链接、canonical 标签和 sitemap。
3. 纯静态网站也需要考虑 SEO
工具站很容易出现一种情况：功能确实能用，但搜索引擎看到的页面内容非常少。
所以每个页面除了计算器本身，还需要清楚地解释：
● 这个工具解决什么问题；
● 输入的数据应该如何测量；
● 计算结果是怎么得出的；
● 结果有哪些局限；
● 用户接下来可以做什么。
这些内容不只是为了 SEO，也是为了让用户真正理解计算结果。
五、接下来准备观察什么？
网站上线只是第一步，接下来更值得关注的是实际数据。
我比较关心几个问题：
● 细分关键词能不能带来真实的搜索流量；
● 用户更常使用主计算器，还是某个具体的细分工具；
● 搜索用户进入页面后，是否真的完成计算；
● 哪些页面值得继续投入时间优化。
对小工具站来说，开发完成并不意味着项目验证成功。真正重要的是能不能找到明确的用户需求，并通过搜索流量持续获得用户。
如果最后发现某些关键词没有流量，或者用户需求和预期不一致，也需要根据数据调整，而不是不断增加功能。
目前先把第一版跑起来，后续再根据真实反馈迭代。
网站放这里： https://brascale.com/
如果大家也做过面向海外用户的纯静态工具站，尤其是通过 SEO 获取自然流量的，欢迎交流一下：你们通常会先做一个覆盖面比较广的主工具，还是先从几个具体的长尾需求切入？
via V2EX (author: sobinyuan)
[问与答] 如果，我是说如果，谈婚论嫁时，女方父母提出让男方婚后工资给女方管理，怎么破局。
女方家经济情况不差，女方不是那种以父母为首的人，女方父母接触下来也不是那种不讲道理的人。
彩礼三金之前和女朋友沟通过，都是正常范围，大概是 8-10 区间，给到女朋友，女方父母同样给这么多给女朋友。
女方年收入 14w 左右
男方年收入 30w 左右，房贷剩 50 w
如果，我是说如果，万一谈结婚时女方父母为了给女方争取到最大的利益，问出了这个话，在不破坏关系的前提下怎么破局。
比较明确的是不可能给女方管理，最多共同账户，当然用随便用。
问这个是因为女朋友说她妈妈私下问过她这个问题说婚后双方资金怎么管理。
via V2EX (author: PoorGuy188)
女方家经济情况不差，女方不是那种以父母为首的人，女方父母接触下来也不是那种不讲道理的人。
彩礼三金之前和女朋友沟通过，都是正常范围，大概是 8-10 区间，给到女朋友，女方父母同样给这么多给女朋友。
女方年收入 14w 左右
男方年收入 30w 左右，房贷剩 50 w
如果，我是说如果，万一谈结婚时女方父母为了给女方争取到最大的利益，问出了这个话，在不破坏关系的前提下怎么破局。
比较明确的是不可能给女方管理，最多共同账户，当然用随便用。
问这个是因为女朋友说她妈妈私下问过她这个问题说婚后双方资金怎么管理。
via V2EX (author: PoorGuy188)