Oracle 云按照负载情况清退免费账户的虚拟机，这个思路感觉很厉害。其他云厂商都是听说有谁负载太高了，被限制。两种思维方式不同，可能面对的情况也有很大的区别。常规云厂商，如果单用户负载过高，影响到整体用户的体验，这就必须介入管控，这运行的每一分钟对云厂商都是金钱。但是对 Oracle 这种体量的企业来说，有严格的风控和注册限制，即使如此规模也很大，这里面难免有一批注册来不用的，这样的机器回收回去确实也合理，需要保证的是整体负载要上去，不要空置。两种思路，似乎跟现实中许多实体运转的情况，高度的类似。
关于睡眠的周期，总是可以看到一个说法，是说睡眠最好睡到一个半小时的倍数，这样是完整的睡眠周期，可以避免从深度睡眠中起来。
但很奇怪，感觉自己不同的时长，对应清醒程度跟睡眠周期不是很一样。有时候感觉很符合睡眠周期的时间，反而起来的时候很困。有时候感觉睡眠时间跟睡眠周期差的很远，但是起来的时候反而是清醒的。
神奇，或许得记下来清晨的感觉，再去反推一下实际的睡眠时间和清醒状态的对应关系，才可以真实的了解对于自己来说最合适的睡眠周期。
在书店顺手买了一本《给大人们的情绪使用说明书》，从第一章《愤怒》中摘录几句话：
想让愤怒这种情绪发挥它原本的作用，就需要借助大脑中的“自动翻译器”。 在感知到自己生气后，迅速在大脑中转换：愤怒 = 事情发展不顺。于是豁然开朗，进入解决问题的状态中。
在有限的文字里，提取一个清晰的观点，再用有限的时间，透彻的表达这个观点。这样就够了。不需要对写东西焦虑。二十分钟就足够表达一个清晰的观点或故事。不一定非要去追随热点，找到对自己有用和关心的点，不要盲目追随。
某个项目 mod 托管在 gitcode，无法拉取。git 登陆也不行，需要配置 git 针对 gitcode 默认走 ssh 协议：
git config --global url."ssh://git@gitcode.com".insteadOf "https://gitcode.com"在网上查到比较多的是针对 gitlab 或 github 的：
# gitlab
git config --global url."ssh://git@gitlab-company".insteadOf "https://gitlab.xxx.cn"
# github的同理
git config --global url."ssh://git@github-company".insteadOf "https://github.com"配置后就可以正常 go mod tidy 了。
# 下面两种写法二选一
git checkout dev -- path/to/config.yaml
git restore --source=dev -- path/to/config.yaml以上命令都做了一件事情：假设我当前在 main 分支，希望将 path/to/config.yaml 恢复到 dev 分支的状态。
有两种方式可以实现通过跳板机直接连接目标服务器 SSH.
# ProxyJump（推荐方式）OpenSSH >= 7.3
ssh -J user@jump-server.dealiaxy.com:10023 user@target.dealiaxy.com
# 在这条命令中，-J 后面指定了跳板机的地址（user@jump-server.dealiaxy.com）和端口（10023）。SSH 会先与跳板机建立连接，然后通过跳板机转发流量到目标服务器 target.dealiaxy.com。整个过程只需要一次登录操作，极大简化了访问流程。
# ProxyCommand
ssh -o "ProxyCommand ssh -W %h:%p user@jump-server.dealiaxy.com -p 10023" user@target.dealiaxy.com
# 在这个命令中，-o "ProxyCommand" 选项指定了一个自定义的命令来通过跳板机进行连接。具体地，ssh -W %h:%p 会将目标主机（%h）和端口（%p）转发给跳板机，然后通过跳板机建立与目标主机的连接。lxc 启动 chronyd 是无法直接启动的，因为用到了很多未授权的权限。
lxc与宿主机共用内核，因此时间也是共用的，无需同步。如果你想构建一个 ntp 服务，不需要同步时间，可以像下面这样做：
$ sudo systemctl edit chrony
# 新增以下内容：
[Service]
User=
Group=
ExecStart=
ExecStart=/usr/sbin/chronyd -F 1 -x这些配置会覆写默认的 chrony 后台服务参数，启动 chronyd 时加 -x，禁用步进/微调系统时钟，这样即使没有 CAP_SYS_TIME 也能跑起来。
上面两行 User 和 Group 这样 chronyd 会以 root 启动，然后按照 /etc/chrony/chrony.conf 里的 user chrony 自动降权运行，这是官方推荐方式。
这样配置后 chrony 的服务就可以启动了，可以对外发布 ntp 服务。
cc 的额度用的好快。之前每次触发限流，又可以用差不多的时间。现在触发几次限流以后，就开始提醒我接近周限额。限制可真是越来越多。本来以为发了新的模型可以用更久一点，结果非但没有更多，感觉更容易限流了。可能每个人的体感不一样。既然这么容易限制，大规模的使用势必是要考虑如何回本的，所以就看如何在有限的token中获取更多了。似乎 AI 正逐渐向一种“资源”靠近，未来或许真的就像是用水和电一样，去获取和使用AI资源。但是从经济的角度去看，似乎赚钱的人们很喜欢这样。都希望将自己的产品，包装成更容易、更广泛流动的资源。
独立思考的能力和时间。虽然现在 AI 能够快速的做一些事情，但越来越发现独立思考的能力时间似乎越来越重要。能够从快速获取和变化的信息中找到思路，从严重过载的信息中抽丝剥茧，让自己从高压的同行压力中得到放松，好像现在看来也挺难的。只要不断训练，日积月累，总是能越来越强。所以就从每一件事情，开始训练自己思考的能力，处理信息的能力，找寻方向的能力，输出的能力。
有些事情只有做了才能看懂。最近照葫芦画瓢做了不少东西，之前感觉望而却步的事情，看到只能感叹作者好厉害，这个团队好厉害。真的自己做过，发现看到的东西都不一样了，一眼就能从纷繁的信息中提炼出关键信息。就这样不断积累吧。
今天尝试了一下用 cc 写代码、设计。再用 cx review，发现的问题再给 cc 优化，效果确实不错。cx 的优势在于准确可控，致力于给出最标准的答案，因此创造性略差，做出的东西准确但呆板。cc 做的东西更容易给人眼前一亮的感觉，但有时不够准确，修改面积过大，随之会带来一些风险和漏洞。结合两者优势，共同使用，扬长避短，效果还不错。
就是真跑起来 token 消耗惊人，一直使用大约 3h cc 的 20💲套餐就限流了。
要是真的要发挥ai的效能，还是需要人类自主选择合适的工具和流程，之后再监督执行，发现错误及时纠正，避免在错误的道路上进入token消耗死循环。
另外在其他地方看到的一个思路，用 cx 来调用 cc 执行，这样说不定真的可以做到自主运行。有合适的场景可以试一下。用 ai 的方式调用 ai ，自举了。
做稍微复杂一些项目时，先跟ai一起设计、检查、微调、循环往复。直到生成接近完美的设计文档。再按照路线图，同样的流程一步步实现功能。这样更能够长期维护迭代使用的软件。
或许到一定程度，就需要换个思维考虑问题。不同的阶段，需匹配不同的思维方式才可。
今天在听腾讯发展的一个播客，讲到腾讯早期什么都做，各种抄袭，最后发展成很坏的风评，最终引发 3Q 大战。Pony Ma 在那时候进行深刻反思，觉得自己只是一心想要做好产品，但是为什么会到这个结果呢，经过深刻反思，后面的做事方式也发生了深刻的改变。
之前听到这个故事还不觉得有什么，现在突然又有了一些心得体会。当发展到一定程度，已经具备相应的规模和实力，就不要在跟那些“初创公司”抢饭碗了。应该做的是在自己足够大的客群下深耕。做深场景，做好口碑。看到有其他好的公司项目，就可以用收购或持股的形式来支持。
绝不应该在已经找到自己方向且取得一些成果之后，还不断的分精力去尝试自己不擅长的方向。在许多事情上都是如此。
寻找，验证，直到取得成果，再深耕。不要在走到第三步的时候，还在想着重复前面的事情。要瞄着更远大的目标。
refs: No.169 腾讯与 QQ:你的灰色头像 还在跳动吗|中国互联网故事|半拿铁|商业沉浮录