合理.

因为就算接下来拼命干,一直干到额度重置,可能也不及agent重置以后10分钟的成果.

那就没有必要做了.

所以没有token,就没法上班了.

至于token应不应该由公司提供,好像也应该,好像也不一定.毕竟有人带着公司的电脑上班,也有人带着自己的电脑上班.福利不同,生产资料也不总是由公司提供.

但是如果一个星期上到第四天,token刚好用完了,那第五天继续上班还有什么意义呢?

过去争取一周四天工作制,还要证明四天和五天的产出差不多.现在倒简单了:第五天拼命干八个小时,也不及下周token重置以后agent干10分钟.

于是劳动者突然获得了一点非常具体的议价权.不是要求少干一天还能有一样的产出,而是多干这一天本来也没有产出.

所以agent最后带来的劳工权利平权,会不会是大家终于可以一周只上四天班了?

不过四天工作制,只是从劳动者这一边算出来的结果.

到了公司那边,token就不再只是工具额度或者员工福利,而是升级成了生产成本.

既然多买token可以增加产出,那也可以买更多token,再降低人力成本.

所以最后得到的究竟是一周四天工作制,还是裁掉一部分人,让剩下的人带着更多token继续上五天班呢?

本文完全由 GPT-5.6-Sol 生成。

这是最近半年来最热的词了.

还是记录一下自己的想法:

首先是agent提供了一套能够落地的系统将ML inference这种概率计算落定并且scale到生产级别.

就好比来量子计算都算完成了,也得要很好的infra来让他落地一样,agent就是ml inference的product infra.

这也是为什么token在去年就会被老黄寄予厚望.每一次inference都是DC里面的CPU的一次计算的话,那自然是巨大的市场.

当下的agent还是比较粗放的,根本没有到精细设计的程度.毕竟首先是力大砖飞,看看砖在力大的时候大概能飞多远.之后才是精细优化,性能提升,走上metrics driven和ab testing的老路.

所以必然所有计算都用agent的ml inference自然是不合算的,也不会是最后的形态.

相比之下,一种基于传统算法和ML inference结合的落地形式可能会出现.

这大概就是后面会出现的最优秀的engineering产品了.

不过最后宣传的时候必然不会是这样的,因为这毫无卖点,也没有想象空间.

所以最后如何就让我们拭目以待吧.

那篇文章其实不是一个特别优雅的教程,更像是一次把问题摸出来之后留下的现场记录: ss-redir, iptables, TPROXY, UDP, DNS, Entware, kernel module, 每一个点都不算大,但是组合起来很容易忘.

所以这个问题很适合被整理成一个 Codex Skill.

不是让 Codex 直接替我登录路由器乱跑命令.更合理的做法是让 Codex 先把旧文章里面的经验抽出来,变成一个稳定的工作流:先问变量,再生成脚本,再列检查项,最后保留 rollback 和 troubleshooting.

我大概会这样问 Codex:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

Read my existing blog post about configuring a specific IoT device on an Asus Merlin router to use a Shadowsocks server:
source/_posts/cs-how-to-config-robot-cleaner-to-use-ss-server.md

Please create a local Codex Skill that helps me repeat this process safely.

The skill should not assume it can SSH into the router or run commands automatically.
It should guide the user through:

1. collecting router/device/server variables:
   - device IP
   - router LAN interface
   - ss-redir config path
   - local redirect port
   - whether UDP is required
   - whether TPROXY kernel modules are available
2. generating a reviewable shell script for Asus Merlin + Entware
3. generating verification commands for:
   - ss-redir process
   - TCP redirect
   - UDP TPROXY route
   - DNS behavior
   - iptables counters
4. explaining common failures:
   - missing TPROXY target
   - ss-server not started with UDP
   - DNS still going to public resolver
   - wrong iptables binary or missing kernel module
5. providing a cleanup / rollback section.

Please write the Skill in a way that asks clarifying questions before generating final commands.
Use placeholders for private server names, passwords, device brands, and IP addresses.

这里的重点不是把那篇文章重新总结一遍.重点是把「我当时为什么卡住」变成 Codex 下次可以复用的判断顺序.

比如旧文章里面真正有价值的地方,并不是某一行 iptables 命令,而是这些顺序:

• 先确认 ss-redir 本身能不能跑.
• 再确认 TCP redirect 有没有命中.
• 再看 UDP 是不是需要 TPROXY.
• 然后才检查 policy route 和 kernel target.
• 最后看 DNS 到底有没有被设备绕开.

这些东西如果只写在 blog 里,下一次还要重新读一遍.如果写成 Skill,它就会变成 Codex 的前置习惯.

比较好的 Skill 也不应该一上来就输出一大坨命令.它应该先问:

1
2
3
4
5

What is the IoT device IP?
Do you need UDP, or only TCP?
Is the router already running Entware?
Do you know whether xt_TPROXY exists on this firmware?
Do you want a dry-run checklist first, or a shell script draft?

我觉得这也是 Codex Skill 比普通 prompt 更有用的地方.

普通 prompt 解决的是「这次怎么问」.Skill 解决的是「以后我不应该忘记怎么问」.

对这种家用网络和半嵌入式设备的小问题来说,这件事还挺重要的.因为它们不是复杂到需要完整项目管理,但是又足够琐碎,足够依赖现场状态,足够容易在半年后完全忘记.

把这种流程写成 Skill,大概就是给未来的自己留一个比较可靠的施工队长.

本文完全由 GPT 生成。

但这句话其实挺危险的.因为它很容易从一个经验观察,滑向另一种身份本质论.仿佛不符合默认画像的人天然更细心,更负责,更会沟通,更能写文档,更愿意把事情兜住.

我不太相信这种解释.

我更相信的是另一个更残酷的解释: 很多非默认画像的 engineer 需要先更强,才会被看成一样强.

之前看到过类似的说法,具体到性别这个维度,后来发现这其实在工程行业研究里有个名字,叫 Prove-It-Again bias. Society of Women Engineers 和 Center for WorkLife Law 的 Climate Control 报告里也提到过,很多女性工程师会感受到自己需要反复证明已经证明过的能力.

这件事会制造两个效果.

第一个是幸存者偏差.如果一个人从学校,面试,组内合作,晋升,技术讨论,项目归因里一路过来,每一步都被多问一句”你真的懂吗”,那最后还能留在核心工程岗位里,并且能被旁人注意到的人,本来就已经经历过更硬的筛选.

第二个是表达和交付方式被迫训练得更稳定.同样一句”我觉得这里有风险”,有些默认画像里的 engineer 说出来,别人会理解成技术直觉;非默认画像的 engineer 说出来,有时候就需要补更多上下文,更多证据,更多预案,更多结果.久而久之,能在这种环境里持续赢的人,就会变得非常不容易被挑错.

所以最后看起来就是: 这些人设计更清楚,实现更稳,沟通更完整,判断更少飘.

但这不是天赋优势,这是系统成本🥲.

一个不公平的环境当然可能筛出很厉害的人.但不能因此说不公平本身是有用的.这就像说高压环境会训练人,但真正应该被讨论的不是高压有什么教育意义,而是为什么有些人必须先穿过高压,才获得普通信任.

我觉得比较准确的说法可能是:

不是非默认画像的 engineer 天生能力更强.

而是在一个默认画像仍然偏男性的行业里,那些被看见的非默认画像的 engineer,往往已经支付过更多证明成本.

当一个团队里非默认画像的 engineer 普遍显得更靠谱,这不一定说明某种身份更适合工程.它也可能说明这个团队,这个行业,甚至我们自己的观察方式,只允许一部分特别强的人穿过偏见以后出现在视野里.

所以”非默认画像的 engineer 能力更强”如果作为一句赞美,它是有点苦的🥲.

真正好的世界应该不是让非默认画像的 engineer 必须强到无可挑剔,而是让一个普通强的人,也可以先被默认当成 engineer.

本文用 GPT-5 创作。

和去年不同的是,年底火了openclaw.大家都叫着要替代所有白领,然而我还在用这个总是打错别字的输入法.

五笔是没有学的,token是付不起的.

生活是无奈的, 加班是无限的.

从《南明史》我们看到的是平行时空近代史.

胡风南渡说,到了明朝中期就加大了对元的鞭挞.记录在案!

和之前说的一样,民族国家,大概是要带入太空时代的.

很难想象已经30岁+了,生命过了这么久,感觉是悟了,但又觉得没有什么可以做的了,无力,也无奈.

错误总是一遍遍的犯,我,他人,世界,但是有在进步.

但是真的是进步吗,是熵减吗,还是只是局部的改进呢.

离开🐶已经整整一年又6个月了.曾经在做那些事的人,还在做那些事,但是这个世界却已经不是之前的样子了.

很庆幸当时离开了,虽然如果留下,可能也是能做出一些agentic app届的有趣应用,用在那些所谓的ML world backbone上.但是真的有多少就不得而知了.

最近半年感觉进步最大的地方,就是在过去几个月中强制读了一些Paper.获得了一些新的Know How.但是所谓的Know How依然是落了窠臼.这大概也是为什么觉得,算是悟了.mHC, Residual, Latent, GPRO.都是一些焦虑的人的焦虑的话.进步很好,效果很大,但是终究没有跑出原来的框架.

知道了自己的blog不用RLHF,不需要SFT,啥都不需要,你只要和Claude说,你给我建立一个人物侧写,一个LLM Wiki.

知道了成名拿上上亿大包,不需要你做的多好,多高级,只是曾经你有微小的贡献,然后处在正确的地方,就会成为可能.

大家说人一辈子运气只够挣一笔不错的收入,那是一次性的,就我这运气估计也是这样.

所以惶惶不可终日的,是想着,我的那一笔,是已经挣过了吗.

有这种想法,可能实在是最近几个月的新闻太多,周围圈子的人可以开始做自己想做的事情的人不少.

无论是投身自己热爱的事业;

或者是开始做自己一直想做的事情;

也或者是希望投入GDP大循环;

还或者是离开了循环,加入了人类命运的探索.

依然不变的,没有嫉妒,只是羡慕.

最近半年获得了从来没有过的近距离通过第二手资料了解Elon的机会,泯然众人矣.

然而如何成为有资本的那个众人,让资源为我所用,去探求那个可能根本没有必要的问题呢.

不知道,也暂时无法知道.

曾经刚毕业的时候,不懂YoE3年的同事的烦恼;YoE3年的时候懂了那时候同事的烦恼,却不懂YoE7年的同事的烦恼;
YoE7年的时候,感觉懂了YoE12年的同事的烦恼,也算是一种进步吧.

2026大概是软件工程的最后一年了.不再成为一个劳动密集型行业,而是转型成了机械工程,咨询,金融一样的门槛型行业,这就意味着薪资的降低,晋升的减速,倾轧的恶化.

希望各位,都能在这个百年一遇的历史之变革时期,把握当下:

勃勃生机,万物竞发!