BeautifulSoap

tailscale 组网啊，直接暴公网 ip 想什么呢

你应该使用 tailscale 组网，而不是将任何家庭内部网络服务直接暴露到公网中
我无法理解为什么有人敢直接把家庭服务就这么暴露到公网里的，你暴露的服务有漏洞就意味着整个家庭网络在黑客面前裸奔
就像这次飞牛 OS 一样，有人说加 WAF ，你的 WAF 只能防这次漏洞的，就飞牛这安全下次再爆个漏洞你依旧要出事

“我甚至看到 reddit 有人说他去美国，餐厅结账的时候，服务员直接拿他的信用卡记录下来，并让他写下小费数量，等他离开之后再扣款”

这是非常复古的信用卡扣款流程了。网络出现之前信用卡就是这样消费的。不过那时候还需要店家拿客户的信用卡拓印出卡号等信息然后交给银行。这就是为什么信用卡的卡号等信息都是凸出来的

$20 用完官方还会送给你额外的一些额度可以继续用。能用多少我也不知道，公司的商业账号能额外多用$70+，我个人账号额外用$20+就到头了
auto 的话似乎用光额外额度还能继续免费用下去，但能用多少也不知道，至少继续用到大几十$应该没问题

我 go 后端+react 前端旧是放一个 repo 里，主要是自动 ci/cd 不是一个 repo 实在太麻烦了
分 repo 存放最大问题就是前端 or 后端更新，ci runner 需要拉取另一个 repo 的话必须为 runner 配置哪个 repo 的 key
想想真的算了

Github Copilot 和现在的其他 ai 工具相比的确不行。配合高级模型虽然智能程度凑合，但实在太他妈慢了。它是怎么用着 claude 的模型还能跑得比 codex 还慢得我是真的想不通

了解下 spec 驱动开发这个概念，引用我另一处的看法

------------------------
Spec 驱动开发绝对不是 ai 开发的未来。真做过项目的就知道 Spec 这东西本质上就是一个项目的详细设计书（尤其日本 it 开发喜欢这一套。开发项目先确定需求,然后做完整的系统的设计，这种设计可能详细到每个小功能逻辑步骤，然后开发照着设计书实现代码）
大部分是你用了 Spec 驱动开发，往往结果如下

1. 对于一个复杂功能，生成的 spec 过度复杂
2. 虽然能拆分功能 spec ，但是功能的复杂度是改变不了的，spec 的复杂和 ai 生成的大量 spec 结果就是根本懒得去看
3. spec 详细到了代码细节实现，review spec 本质上和 review 伪代码没区别，到后来就和 2 一样懒得去详细看 spec 了
4. spec 对各自的功能模块只适合功能变化不大、较为稳定的情况。当你的设计书经常动不动就发生大的变化（实际上开发中经常遇到），spec 也会经常会发生巨大变动，如何将最新的变动融入已经写下去的 spec 并且更新到代码也是个问题。而且每个 spec 之间都互相依赖，牵一发动全身。

一般问这种问题前，应该先问公司的 it 管理相关规章制度。。。。。这其实不是个单纯的技术问题

当别人还在那整调度、调电源计划的时候，我早就直接 BIOS 里把所有小核都禁用了。相信我，这是最简单的方法。而且续航也没减少多少。