Today I had a rare opportunity to chat with a co-worker about our similar approach to work and the challenges we both face. I was surprised to realize how much I needed allies — more than I had previously understood.

I’m not even hiding my weaknesses or vulnerabilities; I’m just really good at not showing them at work. Navigating the workplace can feel like walking a narrow path. In recent years, I’ve often been the one setting expectations for a small cohort of peers, which leaves me with fewer opportunities to express my own struggles. Of course, I’m privileged to have support systems — a strong circle of managers and mentors. But even with them, I naturally position myself as someone with a high caliber, someone who has things under control. It’s hard to loosen up, if ever.

这个周末, 我用 Google Antigravity 做了一个自己的网站. 耗时大约10小时. 原本没两个小时就上线了; 后来我想着把podcast, substack都搬运一遍, 多用了一倍时间. 我上一次做任何网站, 是在2017年左右.这些年 front-end 技术的迭代很多, 对我来说, 这是一个相对新的体验.

1. AI 辅助全栈开发实战

概要

• 结合 Gemini 架构决策与 Antigravity IDE 智能编码

• 复盘如何利用 AI 工具(Gemini 和 Antigravity)在一个周末内构建并上线一个高性能的个人静态网站.

• 不算建站教程, 应该是 AI 辅助工程(AI-Assisted Engineering)的实践分享.

项目背景与目标

目标: 把substack还有podcast的内容,可以同时sync到自己的服务器上.

核心需求

• 高性能: 静态页面, 极速加载. 不需要复杂的网页功能

• 低成本: 零维护费用, 免费托管.

• 掌控权: 数据完全自有, 独立域名 (tuwang.ai).

AI 角色

• Gemini: 架构,做简单的research -- 负责技术选型与方案制定.

• Antigravity: 负责代码实现, 调试与资源生成.

2. Gemini 技术选型

架构决策: hosting static website

技术栈:

• 框架: Hugo (构建速度极快)

• 托管: Cloudflare Pages (全球 CDN, 自动化 CI/CD)

最近的半年, 我跟AI Coding Assistant 和 AI-based feature每天混在一起, 终于从一个局外人, 变成了一个长期在线用户. 我要么在适应AI的路上, 要么就是在被AI淘汰的路上; 在这两者之间, 我坚定地选择了前者. 但即便如此, 我还不时发现自己在这两种状态里左右横跳: AI技术和工具的迭代之快, 让我有了90年代互联网初期的体感, 又或者那种工业革命就发生在你家门口的焦虑.

太慢接受AI工具的人, 会被淘汰. 但不是被AI取代, 而是被那些提高生产力的同事们取代. 最近的一期的’影视飓风’说到这个类似的概念, 下面这句夹杂了我的个人想法: 今后我们越努力地去手动做一些事情, 回报率就越低. 旧时代的“专业壁垒”正在崩塌. 过去, 我们依赖经验积累下来的“手感”和许多重复性但需要专业知识的劳动, 现在这些都在被 AI 极速贬值. 我大胆地预测, 没有公司会因为个人过去的成绩和努力, 而维持生产力落后的部件.

大厂社畜原本就有悲观的一面: 我这颗螺丝钉, 随便都能取代; AI just made sure of it. 把AI工具用的不错的人, 通常会非常注重记录有效的AI输出, 也就是context. 什么都可以是context: 对代码的理解是context, 做一个development plan是context, 上次AI犯的错和正确的选择是context…等等. 从某种意义上, 我们就是在培养一个记忆更好, 更一以贯之, 并且更能大幅度输出的’自己’. 不是说’别培养AI就行了’, 这不由得我们; 一个员工离开后, 让AI去复习一遍他的过往输出, 就能很快填补上他离职后的知识空缺.

AI coding assistant is a hyper-motivated intern; if you enjoy coaching intern to succeed, you will love working with AI. 这句话是我2025年初, 第一次用AI帮我写代码时候的感受, 也就是所谓的planning step, 做规划是必不可少的一步. 我给AI写的第一个task, 其实就跟我给实习生写项目简要一模一样: 写目标, 阅读资料, 详细步骤, 还有过去的例子. 转眼间将近一年, planning也很自然的变成industry standard. 如果在AI-first的工作环境里有层级的分别, planning也许就是最基础的一层. 不做planning, AI体验一定很差.

① 编译日志的来由

过去的一年之间, 我的工作的氛围有了极大的变化. 从team role转到org role; 从带组员转到带TL; 从跟IC协作到跟EM协作. 在这个过程里面, 我发现自己难回到曾经那个up主的节奏里: 我的表达欲受到了一些冲击, 似乎因为看到了更多的人和事, 导致过往的’经验总结’显得过于肤浅, 无法入目. 基于这个认知, 我把小红书, YouTube, B站上面的视频全部下架了.

我姑且把这样的心理变化归类为个人成长, 但本质也是一种被打磨后的怯懦. 回想年少的自己, 未曾有顾及别人利益的情商, 看到不顺的事情还会写写文章; 而今, 每每有想法却无处表达, 瞻前顾后, 只能在网上给认同的观点加个赞.

2019年是我表达欲的巅峰, 那时候做了很多coding interview, 也做了很多人生低谷的自我检讨. 当时的我认为我是有信息差的. 而今, 我已经不具备明显的信息差, 尤其是跟硅谷大厂的同事们相比, 我能给到的信息, 远不及身边人.

这几年我都很喜欢听podcast. 从Mordern Wisdom听来的一个想法我非常赞同. 其实我并不需要是整个房间里面最聪明的那个人 - 做最愚蠢的那个人, 做提问的那个人, 没什么掉面子或者不好的. 这句话在我心里来回折腾了好几年. 现在的我认为, 我的能力从来不是有超宇常人的眼界, 但是我具备一定深度的同理心和好奇心. 这可能是一个新的方向.

2025年初的时候我在西雅图出差, 那时候已经有了重整podcast的想法. 当时我去跟课代表立正聊天, 受到了鼓励, 次日就录了编译日志的第一期: #1 课代表立正: 打开第四面墙, 走进课代表的世界. 就录视频而言, 我已经有了5年多的经验, 但查资料做采访, 那算是头一回.

在给播客取名字的时候, 我给它的定位, 是要找寻builders and thinkers. Builder字面意思, 就是那些创造者/构建者, 同时也包括了自我提高的人, 尤其是那些运动, 训练, 比赛的人. 其次, thinkers顾名思义, 就是乐于思考的人.

👋 这次想聊聊我的人生首场 10K 比赛。成绩嘛，就一个“参与奖”水平，但训练和比赛的过程太有意思，值得记录一下！

小宇宙播客: Vol.20 我人生的第一场体育比赛 | 10K PB

去年 12 月，我突然想跑步，但35 岁的膝盖还行吗？ 于是我先在跑步机上试了试，感觉还行。但换到室外，发现硬地+坡度=灾难！小腿前侧疼得要命，姿势不对+肌肉不够力，跑起来像是在硬抗。💀

调整步伐后，问题没解决，反而膝盖更累……所以前期训练就是不停试错，努力找到不崩溃的跑法。

10K 训练：从“跑崩”到“稳住节奏”

1. 起跑太猛

第一次尝试 10K，前半程猛冲，后半程直接“走路大赛”，6:46 配速收场。

2. 跟别人跑容易乱节奏

和朋友一起跑，结果第 4 公里就炸了，自己的节奏才是王道！

3. 找到适合自己的配速

多练几次后，配速提升到 6:32，虽然中间还是掉速，但起码跑完不废。

比赛日：San Francisco 10K

早上 7 点到金门公园，结果下雨+刮风+没带雨衣，只好和大家一起瑟瑟发抖躲树下。（下次带塑料袋保暖, 开跑前丢掉！）

比赛氛围特别 chill，主持人开玩笑，音乐嗨翻，完全不像严肃竞技。起跑线前根本没人抢跑，大家就像菜市场排队一样慢悠悠地移动。

沿途观众太给力了！

• 有人举着“Power Up” 向日葵牌，大家都会去击掌🌻

• 桥底下有“应援团”在敲金属管助威🔥

• 终点家人朋友疯狂鼓掌，整个体验超温暖

冲线！

因为误解了路标，我一度以为自己的表有问题, 还剩很多路程。结果志愿者喊“快到了”才发现只剩 500 米，赶紧冲刺！最终 6:18 配速完赛，比训练快了一点！ 🎉

跑步的收获🏆

1. 比赛比训练更燃. 现场氛围和沿途观众的加油让你不得不撑下去

2. 自己的节奏最重要. 开跑太猛=后面炸裂，稳住配速才能保持输出。

3. 装备细节很关键. 雨天跑步要带个一次性雨衣！

4. 音乐很重要. 这次听了 big bang、汪峰、老王乐队.

我在一篇文章里面读到12 week year. 转述文章作者的概括: “忘掉传统心理上的一年结束是12月31日，把12周当做一年。因为只有12周去完成目标，所以需要满打满算、让能安排的时间都更有价值”. 这个想法非常有趣.

我原本对写new year resolution有所抵触, 因为从未完成过一年的计划; 花几个小时就为了当下感觉良好? 不太值当. 可是反观工作: 我最擅长的也是把饼转化成execution timeline + 收尾; 通常我喜欢把项目规划成超不超过12 ENG weeks的时间线, 哪怕18 ENG weeks 的项目在我这里都是过大的, 肯定要找更多人分割, 并排执行.

同样的思路, 亲测有效的执行方案, 我竟然从来没有给自己施行过. 因此, 我决定给自己的Q1 做个2025年度规划:

1/ 沟通成长

• 完成6次有准备的演讲或者视频, 不限工作/副业. Stretch: 12次.

• 发起24次新人coffee chat, 不限工作/副业, 但普通1:1之外的. Stretch: 48次

• 找到适合自己的Toast Master Club, 成为会员

2/ 健康&运动

• weekdaily avg burn 500 calories, stretch: 700 calories

• 挑战10k(2/2/2025), stretch: 挑战半马

• Snowboarding学会ride switch, 录一个ride switch video

3/ 学习

今年9月, 我就遇到了做这个选择的时刻: 是继续做IC (Individual Contributor) 呢, 还是选做People Manager 呢? IC的意思就是单兵的意思, 不负责团队. People Manager顾名思义, 就是传统意义上的经理, 做管理工作.

当时的契机是我们都听过的那种: 隔壁组的manager转走, 于是需要一个人来补. 不久后的将来, 我可能又要面对类似的选择: 我们自己的团队壮大许多, 所以在某一个时间节点, 我们会需要加一个manager.

我过去这两年一直在做Tech Lead, 我们原生的工程师团队成长到了14个人; 还有一些散装的合作的小团队. 我的角色一般是找找scope, 带带项目. 如果转职为管理, 对我来说, 是工作核心内容的彻底变更, 也相当于对这几年积累的机遇直接放手. 因此在这个选择上, 我找了一些前辈探讨, 今天的笔记就是讨论的一些话题点.

很多工程师默认的职业规划就是转管理. 曾几何时的我自己也有这样的想法. 举几个比较传统的思维:

1. 写代码是年轻人的活, 所以资历深更适合做管理, 总不能写一辈子代码?

2. 管理职位, 有个官职似乎更厉害, 眼界更开阔, 更有机会成长?

我对这两个假设都有一些不同的想法. 对传统观念的疑虑不是今天讨论的重点, 这里暂且不表; 我们主要讨论, 在去除这些传统观念之后, 客观地去考虑, 该如何选择呢?

首先, 我们来说说具体是什么时候有转职的机会:

工程师在升职到到了Staff或者Senior之后, 自然而然就有了这样的机遇. 我司职位到了level 5, 所谓的Senior Engineer, 就有资格转M; 同样级别对口的是M0. 职位到了level 6, 也就是Staff Engineer, 对口的就是M1. 近些年, M0已经很少见了, 大多数转管理的都是L6 > M1.

The highlights of 2024 were a few long-term goals coming together, both in my personal life and career. On the flip side, there were also matters that I was underprepared for, which led to harsh life lessons. Overall, the past year was a challenging but productive experience.

Why bother writing about the recent past?

• Writing about the 45%–65% of my awake time is a meaningful practice for the year’s finale. Like many others, I dedicate a lot of effort to the yearly performance reviews for myself and others at work. However that only represents merely 40–60 hours per week (~35%–55% of the 112 hours of non-sleep active time). Ignoring the rest 45% — 65% seems silly.

For a long time, I have been chasing after the prestigious title of senior engineer. I was mentally exhausted when I achieved it a few years back. Leading up to this latest title update, my anxieties piled up— what’s next? (vol.15 小宇宙FM)

Senior Engineer, 2022

In 2020, I flopped my interview for the senior engineer role at my dream company. Through a series of debates, I also gave up on the senior engineer role at Uber for which I aced the interview. I proved that I was worthy of a senior title, even just for a few hours at San Francisco Uber HQ. But on the flip side, I picked the lower rank in favor of my dream company.

① Dead Code Lives Forever

那些不再用的代码, 通常被叫做 dead code.

每隔一段时间, 这些不用的代码会被手动清理掉. 不然, dead code会将系统变得臃肿, 难以维护, 有时候还会浪费一些计算资源.

比如, 有一些冗长的 if/else 曾几何时用来控制迭代版本的, 而多年后, 所有traffic都在最新的版本, 我们理应删掉不用的code path; 有一些 function 是当时防备一些edge case的, 而多年之后, 这些边角问题早就不存在, 我们没必要维护这些附加功能 … etc.

既然是没用的代码, 留你何用? 为什么不删除? 你怎么想?

• What Doesn’t Break, Don’t Fix It: 工作时, 大家一般不太想碰这些代码. 等出了问题, 报错了, 才会引起人的重视, 再删不迟

• Perceived Value: 再次遇见那一坨不用的代码, 我们很可能给出保守的判断: 这块代码, 未来可能还用, 是不是该留着?

• Identity and Self-Worth: 若是一串引以为傲的代码, 即便真的用不到了, 心理上肯定还有一点阻力: 是不是删掉了就意味着之前的功夫白费? 是不是就意味着之前的付出是无效的?

• Additional Efforts: 删除dead code也并不总是轻松: 我们还是要测试, 还是要验证’没用’的假设, 花好一番功夫. 在效率至上的工作环境里, 谁会无缘无故花几个小时给代码瘦身?