ElonJask

AI Coding 实战：非技术人如何用好 Claude Code

Wed, 29 Apr 2026 10:00:00 +0800

最近读了 Tw93 的一篇关于 AI Coding 的文章，深有感触。他面向产品、业务、运营等非技术背景的人员，系统介绍了如何上手 Claude Code。我读完后觉得很多观点值得提炼和分享，于是整理了这篇文章。

核心观点很简单：门槛没想象的高，会用豆包这类对话框 AI 的人花点时间也能上手，剩下的就是慢慢习惯把执行权交给它。

一、从对话框到终端：两种模式的本质区别

很多人习惯了豆包、ChatGPT 这类对话框式 AI，看到终端就犯怵。但这两种模式的工作流完全不同：

对话框 AI：描述需求 → AI 生成代码 → 复制粘贴到别处试 → 来回搬运

Claude Code：直接在终端项目中执行，自己读、改、跑、验，完成一圈才回来找你

区别在哪？对话框 AI 需要你当搬运工，Claude Code 让 AI 直接干活。你不需要会写代码，只需要会描述问题和验收结果。

如果你真的不想碰终端，Anthropic 官方出了个桌面应用 Cowork，可以直接读写下载和文档目录，适合完全零基础的用户。

二、四个技术通识：不必会写，但要会读

作者强调非技术用户不必会写代码，但需要了解四个基础概念：

常用框架：知道 React、Vue、Next.js 解决什么问题即可
软件基础：终端命令、Git、VS Code、Chrome 开发者工具
编程核心思想：函数、变量/状态、多文件拆分的意义
读代码和读报错：比会写代码更早派上用场，报错信息直接丢回去问

建议花一两个晚上过一遍 freeCodeCamp 或 MDN 入门，或者看看 B 站的计算机科学速成课、哈佛 CS50。不需要精通，只需要建立基本认知。

推荐书单：

《启示录》— 产品判断
《Linux/Unix 设计思想》— 工程哲学
《左耳听风》— 程序员专家视野

三、Claude Code 最适合什么活

用过 Cursor、Windsurf 等工具后，作者主力仍是 Claude Code。它的核心优势：

模型能力好，整个项目一起看
天生在终端里，git、测试、脚本都能直接调用
本质是通用 Agent，Anthropic 内部非工程团队也在用它处理 CRM 数据和客户邮件

关键判断标准：两个条件都满足才最适合交给它——目标清楚 + 结果好验收

最适合的场景：

做原型和内部小工具
处理 CSV、做销售报表
合同提炼条款、版本差异对比等文档活
链接/PDF 从特定视角提炼信息

“模型快不快不重要，准不准才重要。它 10 分钟跑完然后你花 20 分钟 debug，远不如它 20 分钟跑完直接能验收来得舒服。”

四、Software for One：做只给你用的软件

Kevin Roose 提出了一个概念：software for one——不需要做给百万用户的 App，做只给自己用的工具。

他给自己做的例子：Stash（整理链接）、LunchBox Buddy（给孩子准备便当）。对非技术人来说，可以是语音批注转会议纪要的工具、每天提醒三件事的小仪表盘。

循序渐进的节奏：

时间	任务	产出
第 1 天	让它改一个现成的 Excel 或 Markdown 文档	熟悉基本操作
第 1 周	做单页个人主页或日报大盘（15 分钟跑起来）	可展示的小项目
第 1 个月	挑一件每周重复做两三次的事变成一条命令或页面	日常提效工具
第 3 个月	选一个 software for one 想法做只给自己用的小工具	完整小工具

五、CLAUDE.md：给 AI 写一份交接文档

CLAUDE.md 放在项目根目录，Claude Code 每次启动都先读它。相当于给新同事写的交接文档，但 AI 每次都从头认真读并严格执行。

三个关键原则：

写得短：150 行以内，太长挤对话空间
语气直接：用命令式。”所有注释用中文”比”团队偏好中文注释”有效太多——软话对 AI 效果差
每条可判断：如”函数超过 50 行必须拆分”

四条最值钱的规则：

先问清楚再动手
简单优先
只动该动的
做完要验证

关键技巧：压缩时保留

文末加”压缩时保留”段落很关键。Claude Code 长会话会自动压缩，决策理由通常第一个被丢。比如之前说”用 POST 不用 GET 因为数据量大”，压缩后只剩”用 POST”，理由没了，下次 AI 可能给出完全不同的方案。

推荐的四段结构：

项目背景：技术栈、团队成员
工作规范：具体规则
禁止项：不主动重构、不删文件、不确认不装依赖
压缩时保留（优先级）：架构决策及理由 → 改过哪些文件改了什么 → 当前进展 → 未完成 TODO

六、需求描述：每多一条细节，少一次返工

“每多一条具体细节，就少一次返工。”

模糊版：”帮我做一个客户跟进工具” → 需要返工

精确版：销售用跟进工具，单文件网页存本地。左边列表显示公司名、下次跟进时间、状态；右边详情含沟通记录、日期、要点；顶部三个筛选（状态、时间、关键词）；数据存 localStorage，不调后端。

→ 精确版当天能跑出可用版本

Tw93 举了一个极致范例：yetone 的 macOS 语音输入工具需求。每条具体细节都在防止 AI 猜错：

写了什么	不写会怎样
macOS 原生 + Swift	可能做成 Python 网页版或 Electron 应用
默认简体中文 zh-CN	默认英文，中文识别率极差
NSPanel + .hudWindow 胶囊窗	弹普通窗口，遮挡输入框
LLM 纠错”极保守”	过度润色，改掉原意

业务场景需求写法要点：

开头先写清楚问题和用户
明确划范围（不做登录、不做分享等）
异常情况单独列出
验收标准给数字（如”首屏 1.5 秒内”）
避免用”待定”“TBD”等模糊词——Claude Code 碰到待定内容会自己猜着填，猜的往往不是你要的

七、Plan 与 Auto 模式：先过方案再动手

Plan 模式（按两次 Shift+Tab）：先列计划再执行，像先拉会过方案再动手。适合复杂任务，防止 AI 越权操作。

作者的教训：让 AI 重构登录模块时，它顺手删了一个后面要用的工具类，回滚花了半小时。从此复杂任务先用 Plan 模式。

Auto 模式（按 Shift+Tab 循环切换）：安全操作直接跑，风险操作才问。Max、Team、Enterprise 可用，Pro 暂未开放。

刚上手默认 Auto 模式即可。

八、验收与纠错：三层验收 + 根因诊断

三层验收

命令过没过：构建和测试跑完绿灯
眼见为实：页面打开看、数字对、关键流程试
对照清单：需求验收标准一条条过

改坏了怎么救

Git 快照：大改前让 AI 跑 git status 看清楚，确认后 commit 检查点。改坏说”按刚才检查点回退”
撤销上一步：说”撤销刚才所有改动”或按 /rewind

避免死循环：先诊断根因

“根因没说清楚之前先别动代码。”

死循环：报错 → 改 → 新错 → 再改，4-5 轮后问题变一团乱麻

正确路径：

让 AI 先答”问题出在哪个文件的哪一行，为什么会这样”
答含糊 → 继续查
答清楚 → 再改
AI 说”我试试改 X 看行不行” → 直接喊停，先答根因

九、进阶技巧：alias、opusplan 和长会话管理

alias 快捷启动

alias c='CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude --dangerously-skip-permissions'

--dangerously-skip-permissions：跳过所有权限确认（不建议新手用）
CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000：自动压缩点提前到 400k

opusplan 模式

输入 /model opusplan（隐藏命令）：规划用 Opus、执行用 Sonnet，整体省钱省时间。

长会话管理

任务做完就 /clear：一个会话只做一件事，两件不相干的事在同一个上下文里来回切，它会越做越乱
长任务结束前让它写交接笔记：HANDOFF.md，含做了什么、试过什么没成功、下一步做什么
第二天打开新会话把文件给它接着干

十、Waza Skill 系统：8 个开箱即用的技能

Tw93 做了 8 个 Skill 工具包：

Skill	用途
`/think`	动手前先想技术方案，质疑问题本身
`/design`	设计产品化页面，拒绝 AI 模板感
`/hunt`	排查问题，根因没清楚前不动代码
`/check`	收工前最后一关，diff 审查
`/read`	网页/PDF 转干净 Markdown
`/write`	让表达更清晰
`/learn`	从收资料到出文章的研究流程
`/health`	给 CLAUDE.md 和规则做体检

安装命令：npx skills add tw93/Waza -g

特别推荐 /design 给产品/业务/运营：截图 + /design，AI 会先反问目标用户、气质、不喜欢的风格、微交互，而不是直接吐一个”AI 模板感”的页面。

自写 Skill 三种常用类型：

工作流型：固定步骤打包（如整理周会纪要）
检查清单型：上线前过一遍避免漏项
领域专家型：沉淀判断框架（如线上问题排查）

编写小坑：

description 写触发条件不写功能介绍：”开完会有原始记录需要整理时调用”比”把会议录音整理成结构化周报”准确率高得多
一个 Skill 只做一件事

十一、其他实用工具

Kami：AI 排版设计工具

安装：npx skills add tw93/Kami -g

8 套模板（一页纸、作品集、幻灯片、Resume 等），风格统一。实用场景：会议纪要排简报、项目进展排一页纸、个人经历排简历。

OpenCLI：网页操作变命令

地址：opencli.info

内置小红书、知乎、Twitter/X、Bilibili 等站点的 CLI 适配器，把网页动作变成命令。应用场景包括小红书调研数据抓取、多平台舆情自动拼成日报。

Claude Design：不写代码出原型

地址：claude.ai/design

Anthropic 官方 2026 年 4 月推出，上传截图或文档即可生成可交互的原型、幻灯片或落地页。产品经理可用来画原型开评审，过了直接扔给 Claude Code 变代码。

十二、用熟后的小习惯

截图比文字快：描述界面问题直接丢图，布局、颜色、层级都带进来了
任务拆小一件件来：一句话能讲清的任务几乎不出错
对话跑偏就重启：清掉上下文重说比来回纠正快
Memory 跨项目记偏好：说”记住我喜欢先看方案再执行”就永久生效
双击 ESC 改上一条：不用重开会话

十三、安全习惯

在 CLAUDE.md 要求每次执行前先解释要做什么
不认识的命令先问风险再确认
生产环境不要拿来练手
密钥放环境变量或 .env 文件，不贴到对话里
涉及登录、支付、个人信息的功能，用 Clerk、Stripe 等现成服务而非从零写

最后

读完 Tw93 这篇文章，我最大的感触是：AI Coding 的门槛真的没那么高。

很多人看到终端就犯怵，看到命令行就认为是程序员的专属。但实际上，Claude Code 的本质是一个”非常直男但是技术非常厉害的程序员”，你只需要把问题说清楚、把验收标准定好，它就能干活。

从改一个 Excel 开始，到做单页小工具，再到自动化每周重复的工作，每个人都能找到属于自己的”software for one”。

关键不是会不会写代码，而是会不会把问题说明白。

延伸阅读：

当 AI 越来越会写代码，真正稀缺的是把方向说明白的人

Thu, 12 Mar 2026 10:30:00 +0800

这两个月我越来越强烈地感觉到一件事：

写代码这件事，正在迅速失去它过去那种“稀缺工种”的地位。

不是说工程师要消失了，也不是说软件不重要了。恰恰相反，软件会变得更多，代码会变得更廉价，真正贵的东西会慢慢从“手写代码的速度”转向“定义问题、组织约束、验证结果的能力”。

换句话说，AI 正在吃掉“写代码”这件事里最容易规模化的部分，但软件工程里最难的那部分，反而被放大了。

这可能才是接下来几年最真实的变化。

一、代码会越来越多，但“会写代码”不再天然值钱

过去我们判断一个工程师强不强，常常会看几个显性指标：

会不会很多语言
写代码快不快
能不能独立把一个功能堆出来
遇到需求能不能很快开干

这些能力当然还有价值，但它们的含金量已经开始下滑。

原因不复杂。以前代码产能是稀缺资源，一个功能从想法变成实现，需要大量人工翻译。现在这层翻译工作，越来越多可以交给 Agent 来做。你描述需求、补充上下文、指出问题，它就能连续地产出实现、测试、重构甚至 PR。

这意味着什么？

意味着“能不能把代码写出来”，正在从门槛，变成基础设施。

以后很多团队真正缺的，不再是那个能把功能硬敲出来的人，而是那个能判断：

这个功能到底该不该做
应该先做哪个版本
该怎么拆，才适合交给 Agent
结果要用什么标准验收
出问题时，应该怪模型、流程，还是架构

代码仍然重要，但代码本身不再是最稀缺的资产。

二、AI 最擅长的不是“创造”，而是“在约束里高速填空”

很多人一上来就对 AI 编程失望，本质上是给错了题。

他们让 Agent 去做的是：

从零发明一个产品
在没有清晰边界的业务里自由探索
接管一个没有测试、没有文档、风格混乱的老项目
用一句话把一个复杂系统全做完

这种用法当然容易翻车。

我现在越来越认同一个判断：

AI 编程最强的场景，不是无中生有，而是在清晰约束里高速推进。

什么叫清晰约束？至少包括四样东西：

1. 有参照物

有现成实现、现成 API、现成规范，哪怕只是一个旧版本代码库，都会让 Agent 的成功率暴涨。

2. 能自动验证

测试、类型检查、Lint、CI、浏览器回归，这些不是锦上添花，而是 Agent 的“护栏系统”。

3. 有架构蓝图

不是把一坨需求丢过去，而是先把模块边界、任务顺序、接口约束讲清楚。

4. 有人持续把控方向

Agent 很能干，但它没有真正意义上的“负责感”。它会非常自信地做错事，也会在错误路径上越跑越远。这个时候，方向盘必须在人手里。

所以我更愿意把 Agent 理解成一种超高产的执行层，而不是自动替你思考的产品负责人。

它能把路跑得很快，但路往哪儿修，还是得人来定。

三、软件工程没有消失，只是从台前退到了后台

很多关于 AI 编程的讨论，最大的问题是把“写代码”和“软件工程”混成了一件事。

其实不是。

写代码更像施工。软件工程更像：

需求澄清
边界定义
架构设计
质量控制
风险隔离
可维护性决策
线上问题的追责与回收

以前因为“施工”本身太贵，大家会误以为工程师最核心的价值就在施工。现在施工成本被压下去之后，后台那一整套东西就会重新浮出水面。

这也解释了为什么很多人会产生一种错觉：

明明 AI 已经能写很多代码了，为什么团队还是没有变得轻松？

因为代码生成只是把产能瓶颈打掉了，但没有自动解决另外几个更难的问题：

方向是不是对的
代码是不是可靠的
系统是不是可维护的
团队是不是知道自己在优化什么

甚至恰恰相反，代码变多之后，这些问题会更快暴露。

如果以前一个团队每周只上线 3 个改动，现在变成 30 个，那测试薄弱、文档失真、架构混乱、隐性技术债，都会被迅速放大。

AI 不会自动拯救工程差的团队。很多时候，它只会让问题更早爆出来。

四、真正稀缺的能力，正在从“实现”转向“编排”

我觉得接下来会越来越明显的一件事是：

工程师的角色，会从代码实现者，慢慢转向问题编排者。

这里的“编排”不是一个时髦词，而是一组很具体的能力：

把模糊需求拆成可以执行的小任务
识别哪些任务适合交给 Agent，哪些不适合
给 Agent 提供足够但不过量的上下文
设计反馈闭环，让它能自我修正
在关键节点做判断，而不是在每一行代码上耗死自己

说白了，未来强的工程师，不一定是那个最爱手敲代码的人，而更可能是那个最会组织一整套人机协作系统的人。

这听起来有点像管理，但又不完全是传统意义上的管理。

它更像是：

你在管理一个会写代码、会犯错、会胡扯、但也会给你巨大产能红利的数字团队。

如果你只会亲自上手，不会拆问题，不会定标准，不会验结果，那你的优势会越来越薄。

反过来，如果你能把问题讲清楚，把约束讲清楚，把验收讲清楚，你会发现自己能调动的“执行力”突然变大了很多。

五、对普通工程师来说，最现实的变化是什么

我觉得接下来最现实的变化，不是“所有人都会失业”，而是行业对工程师的期待会被整体上调。

以前一些属于资深工程师的能力，正在提前变成通用要求。

比如：

能不能独立定义任务边界
能不能读懂并维护测试体系
能不能对架构做出最小但正确的判断
能不能识别 AI 生成代码里的伪正确
能不能在速度和质量之间做取舍

这对新人会更难，对只习惯执行工单的人也会更难。

但它也未必全是坏事。

因为 AI 把很多机械性的编码劳动接过去之后，人的成长路径也许会被迫前移：更早接触系统思维、更早面对产品和工程的交叉地带、更早理解为什么“把问题想清楚”比“把代码敲出来”更重要。

真正危险的，不是不会写提示词。

真正危险的是，到了 AI 时代，还是只把自己理解成一个接需求、敲实现、交工单的人。

那种角色，不是明天就消失，但它的议价能力大概率会越来越弱。

六、最后

我现在的看法很明确：

AI 不会让软件工程消失。

它会让“写代码”这件事变便宜，让“工程判断”这件事变昂贵。

代码会继续爆炸式增长，软件也会越来越多。真正决定差距的，不是谁能多打几行字，而是谁能在更复杂、更高产的系统里，依然保持清晰的方向感。

所以如果要问，AI 时代最稀缺的工程师是什么样的人？

我会给一个很朴素的答案：

不是最会写代码的人，而是最会把问题说明白、把约束搭起来、把结果验清楚的人。

这类人，未来不会更便宜，只会更贵。

当增长像日志一样漂亮，人的告警却越来越多

Fri, 27 Feb 2026 21:30:00 +0800

最近一直在想一句话：现在的经济，正在和普通人越来越没有关系。

这话听起来刺耳，但它击中的，恰好是这两年很多人的体感。你看新闻，增长、创新、提效、突破，关键词都很正向；你看周围，岗位收缩、招聘谨慎、收入预期下调，也都是真的。两个世界像在同一时间并行运行，却很少交汇。

孙立平教授把这种状态叫无就业繁荣或减员式增长。核心判断很直接：经济增长、就业、个人收入，正在失去过去那种绑定关系。

过去我们脑子里的模型很简单：

经济差 -> 企业收缩 -> 工作难找
经济回暖 -> 企业扩招 -> 收入改善

这套模型像一个大家都熟悉的老系统，虽然慢，但能跑。现在的问题是，底层架构变了，旧模型还在，现实已经切到新版本了。

一、从周期波动到结构替代

文章提到美国近年的数据很典型：宏观指标不差，企业利润和资本市场表现亮眼，但裁员和招聘数据却往反方向走。这不是一两个行业的偶发波动，而是一个更稳定的新趋势：经济可以继续增长，但增长不再强依赖多雇人。

作为写代码的人，我很难不把这件事看成一次架构重构：

旧架构：靠人力堆规模，增长和就业高度耦合
新架构：靠自动化 + 算法 + AI 叠加，增长和就业解耦

过去你可以把岗位减少理解为临时降配，等流量回来再扩容。现在更像是服务被重写了，很多旧节点直接下线，不再回滚。

这也是为什么越来越多人会觉得无力：不是我不努力，而是系统把我的接口给废弃了。

二、开发者视角：宏观指标像平均吞吐，个体处境像 P99 延迟

我越来越觉得，这个时代最大的误判，来自指标错位。

宏观数据好看，像监控面板上的平均吞吐在涨。普通人的生活体验，更像 P99 延迟和错误率。平均值可以很漂亮，但只要长尾在恶化，真实体验就会越来越差。

换句话说：

GDP 增长，不自动等于岗位增长
企业利润增长，不自动等于工资增长
技术进步，不自动等于多数人受益

如果把经济当成一个分布式系统，今天的现实是：核心节点性能上去了，但边缘节点在掉线。

三、三层外挂合流之后，替代就不再是线性的

文中提到一个很形象的框架：人类给自己装了三层外挂。

体能外挂：机器替代肌肉
信息外挂：搜索和数据库替代记忆
智能外挂：AI 介入判断与决策

以前这三层是分开演进的，所以替代速度是分段式的。今天它们在同一个流程里融合，替代速度就从线性变成了复合增长。

这对企业是好消息：单位成本更低，流程更稳定，扩张更快。这对很多岗位却是坏消息：一个环节被重写，可能连带整条链路都缩编。

你会看到一个常见场景：

过去需要 10 个人维护的流程
现在变成 1 个工程师 + 一套 AI + 一组自动化脚本

企业会把它叫效率提升。站在个人角度，它就是岗位蒸发。

四、观念也变了：裁员从应急操作变成常规策略

这几年还有一个变化更值得警惕：裁员在不少公司内部，已经不再被当成危机状态，而是管理工具的一部分。

资本市场越来越看重人效指标。员工数增加不再天然代表增长，反而可能被解读成组织笨重。于是企业追求的是：更少的人，做出同样甚至更高的产出。

从管理学角度看，这逻辑没毛病。从社会角度看，问题就来了：如果技术红利主要沉淀在财报和估值里，而没有转成更广泛的收入改善，那多数人的体感只会继续变差。

最讽刺的是，AI 由技术人员推动，但技术岗位也最先感受到冲击。很多人拼命卷效率、卷交付、卷自动化，结果是把替代自己的工具训练得更快更稳。这不是个人选择的问题，而是激励机制把所有人推向了同一个方向。

五、普通开发者该怎么理解这件事

我现在的看法是，先别急着喊口号，也别急着绝望。先把时代变量看清楚，再决定自己的策略。

至少有三件事要接受：

第一，等经济好转，岗位自然回来，这次不一定成立。很多岗位不是被短期需求压住，而是被结构性替代。

第二，技术能力仍然重要，但只会写代码正在变成基础项。更稀缺的是：跨业务理解、系统设计、流程改造、人与系统协同。

第三，个人要从岗位思维转向能力栈思维。岗位可能消失，但问题不会消失。谁更接近真实问题，谁就更难被替换。

六、最后

我并不反技术，也不反 AI。作为开发者，我比很多人更清楚技术提升效率的价值。

但我也越来越确定一件事：技术进步本身不会自动导向更公平的结果。它只会先把能被优化的东西优化掉，至于被优化掉的是成本还是人，取决于制度和分配。

无就业繁荣真正刺痛人的，不是数据，而是落差：系统看起来越来越先进，普通人的生活却没同步升级。

我们面对的，不是要不要发展的选择题。真正的问题是：在减员式增长的时代，普通人还能靠什么维持一份体面的生活。

这才是我觉得值得长期写、长期想、也必须继续讨论的话题。

归乡之后，继续向前

Wed, 18 Feb 2026 04:00:00 +0800

最近终于到了心心念念的年假。坐了 12 个小时高铁，我顺利到家。

回家这几天，脑子里有很多画面和情绪，一直想写点什么，却总觉得不知从何下笔。后来我发现，可能不是没东西可写，而是有些感受太真实，反而更难开口。

久别重逢，话到嘴边却停住

年前，老家一位发小通过我表妹加上了我的微信。我们很多年没见了。上一次听到他的消息，还是从母亲口中断断续续拼出来的近况。

他是留守儿童，从小跟着奶奶长大。后来奶奶离世，父母早年离婚，母亲改嫁后基本不再过问，父亲常年在外。原本他在大学读书，成绩一直很好，但家里还有一个上小学的弟弟要照顾。为了撑住这个家，他不得不暂时耽搁学业，回老家一边接辅导孩子的活，一边照顾家里的生活起居，还要照料一位患有智力障碍的舅舅。

我一直想不明白，为什么这样一个从小努力、成绩优异的人，会被命运安排进这样一条艰难的剧情线。

加上微信后，我本来想着这次回去一定要和他好好喝一场，把这些年没说的话都说了。结果见面时，我们只是尴尬地笑了笑，互相问了问近况。再后来因为别的事情耽搁，又一次错过。

很多话最终没说出口。
只希望他以后的人生能慢慢顺起来。
也把这句话送给自己。

年味在变，回家的意义也在变

这次回去，家乡又突然禁止燃放烟花。村镇还好，县城里几乎感受不到多少过年的热闹。小时候那种满街人潮、花灯连片、到处都是节日声响的场景，像是被留在了很远的地方。

也许有些记忆，本来就只能停在某个年代。

现在再看“过年”这件事，它最实际的意义，可能就是给在外工作的人一个集体回家的机会。热闹会变淡，但团聚依旧珍贵。

说到底，烟花再精彩，也比不过一家人平安坐在一起吃顿饭。

新一年，给自己几条硬约束

新的一年，我给自己定了几条清晰的规划：

做好严格的资金管理，不再为情绪化消费买单。
认真存钱，给未来留出更大的选择空间。
让性格和内心慢慢转向“向内求”，不再把任何人当成情感上的唯一寄托。
希望能遇到一段正常、双向、能一起面对酸甜苦辣的关系。

这些话写下来，不是口号，而是提醒自己在具体生活里一点点落实。

写在最后

祝你，也祝我，在新的 2026 年：

工作顺利，身体健康，所求皆所得。

我的 Mac 效率工具清单（2026）

Sun, 08 Feb 2026 05:00:00 +0800

这篇文章是我长期使用后的整理，不追求“功能最全”，只选那些能明显减少操作成本、稳定可靠、装上就能长期用的软件。整体原则是：少而精、轻量优先。

如果你也在搭建自己的 Mac 工作流，希望这份清单能给你一些参考。

1. Raycast

官网：https://www.raycast.com

这是我个人的“效率入口”，也是最先推荐的工具。Command + 空格 基本能覆盖 80% 的日常操作：打开应用、查资料、执行动作、快速切换。

我最常用的插件：

Clipboard History：复制历史回溯，写文档和开发时非常实用
View 2FA Codes：两步验证码快速查看，减少手机来回切换
Translate：划词翻译，阅读资料时更顺畅

推荐它的核心原因是：减少切换动作，降低注意力中断。

2. BetterDisplay

项目地址：https://github.com/waydabber/BetterDisplay#readme

这是外接显示器用户的“救命工具”。我用 2K 显示器时，macOS 原生缩放的显示效果不理想，字体发虚、比例也不舒服。BetterDisplay 可以细致调节缩放和渲染方式，肉眼可见地提升清晰度。

如果你有外接显示器，尤其是 2K 分辨率，这个工具非常值得装。

3. AltTab

项目地址：https://github.com/lwouis/alt-tab-macos

macOS 原生窗口切换看不到窗口内容，对多任务切换来说不够直观。AltTab 的体验基本就是 Windows 的 Alt+Tab：

能看到窗口缩略图
支持只切同一应用或所有窗口
对多窗口用户非常友好

如果你经常在多个窗口之间切换，这个提升非常明显。

4. MOS

官网：https://mos.caldis.me

一个“装上就忘记”的小工具，但滚动体验会顺滑很多。对于鼠标党来说尤其重要，整体使用感会更舒服。

5. Stats

项目地址：https://github.com/exelban/stats

菜单栏性能监控工具。我平时只开网络状态，主要为了随时查看 IP；如果你需要更细的 CPU/内存/磁盘/温度信息，它也能胜任。

推荐点是：轻量、稳定、配置简单。

6. Keka

官网：https://www.keka.io/en

Mac 上很靠谱的压缩/解压工具，支持常见格式，界面干净，使用成本低。对我来说，它是“用着放心”的那种工具，装上基本就不用再折腾。

7. Keyden

项目地址：https://github.com/tasselx/Keyden

非常方便的 TOTP 双因素认证器，常驻菜单栏，一点就能看到验证码。对需要频繁登录的场景来说，这能明显减少手机切换的动作。

8. Shell360

项目地址：https://github.com/nashaofu/shell360

SSH 连接工具。它的优势是界面简洁、配置顺手、使用逻辑清晰。对我来说属于“够用而舒服”的类型，目前没有遇到明显缺点。

9. 妙言（MiaoYan）

项目地址：https://github.com/tw93/MiaoYan

Tw93 大佬开发的 Markdown 笔记软件，也是我现在在用的工具。它最大的优势是 UI 美观、功能克制，不会因为插件和复杂配置变得臃肿。

如果你写作或记录想法比较多，妙言的体验会很舒服。

10. ClashMac

代理工具我需求不高，稳定优先。之前从 Mihome 到 Spleak 遇到不少奇怪问题，最后选择 ClashMac，原因很简单：菜单栏操作直观、配置方便、使用稳定。

以上就是我长期在用的一套 Mac 工具组合。剩下的就和大家差不多：前后端开发全家桶 + 常见社交软件。

如果你有更顺手的工具，欢迎交流。

向外走

Fri, 06 Feb 2026 18:00:00 +0800

我常在夜深时翻史书。看英雄如过江之鲫，看王朝如潮水起落，前一页还写着鼎盛与豪迈，后一页就变成荒烟与灰烬。那些名字很亮，亮到几乎刺眼；可亮过之后，终究要归于沉默。看得久了，我甚至开始怀疑：我们争夺的、坚持的，究竟能留下些什么？

后来我又开始读诗。诗人的命运更像一面镜子：有人怀抱理想走到绝路，有人在动荡年代把所有热望写成短句。诗句很轻，轻到像一枚落叶；但它能穿过时间，落在我今天的桌上。我明白了，很多人其实并不是被击垮，而是被时代推着走，推着走到一个他们也不认识的地方。

再往后，我把目光投向星空。人类探索宇宙、寻找地外生命，这是一件壮阔的事。可当我把视角拉到更大的尺度——无边的星海，缓慢的时间——我们与尘埃并没有太大的区别。那种渺小感袭来时，我心里像被掏空了一块：一切有意义的叙事似乎都被稀释掉了。我开始迷茫，甚至怀疑，努力究竟是为了什么。

就在这段迷茫里，我突然更能理解刘邦了。过去我对他不甚在意，觉得不够“完美”，不够“高尚”。可越往后看，越觉得他身上有一种难得的实用主义：能屈能伸，敢于进退，既能激烈地争，也能在不得已时退。他不执着于一种“必须怎么样”的自我形象，而是愿意在变化中活下去。那句“无可无不可”忽然在我心里有了分量——这不是随波逐流，而是知道自己的边界，并在边界里把路走通。

这让我对自己松动了一点。我不必强迫自己成为某种“必须很厉害的人”，不必为了“正确”而把生活压成一条线。也许，意义不是用来证明的，而是用来经历的。就像历史会落幕，但人仍然要走过它；宇宙再浩瀚，人的每一次呼吸、每一次心跳，仍然是真实的。

我也逐渐意识到，我不能再一个人坐在书堆里想下去。再聪明的思辨，如果没有身体的触碰与真实的反馈，也只是不断在空气里画圈。我需要向外走——去山川湖海、去街巷人潮、去听雨落在伞面上、去和陌生人交换一个眼神。哪怕只是去市场买一份热饭，或在路边停下来闻一闻花香，也比独自的沉思更能让我确认：我还在活着，我仍有方向。

于是我决定把目光从天上收回人间。看历史，不是为了灰心，而是为了理解；看星空，不是为了否定意义，而是为了珍惜；看诗人，不是为了模仿悲伤，而是为了学会诚实。我愿意继续思考，但不再孤独地沉溺。我愿意走出去，把内心的波澜带到现实里，让脚步去回答那些在脑海里打转的问题。

我想，这就是我写下这篇文字的理由：

不是为了给自己一个答案，而是给自己一个方向。
不是为了证明我看懂了世界，而是承认我仍在学习。
不是为了逃离内心，而是让内心被生活照亮。

如果你也在相似的迷茫里，愿你能像我一样，哪怕只是向外迈出一步。世界会用它的方式回应你——不一定轰轰烈烈，但足够真实。

你好，世界

Thu, 05 Feb 2026 18:00:00 +0800

欢迎来到你的新博客！

这是一个最小的示例文章。
你可以在 _posts/ 中继续添加内容。

为什么写博客

写博客对我来说是一次“慢下来”的练习。在快速迭代的世界里，留下系统性思考能帮助我建立长期记忆，也让未来的自己更容易回顾。

我计划写什么

技术：前端、工程效率、工具链与实践
记录：阅读、学习、思考、方法论
生活：零碎但有趣的发现

文章结构

我倾向于用简单的结构来写一篇文章：

背景
问题
解决方案
总结

开始行动

如果你正打算开始写博客，不要等“准备好”再开始。先写第一篇，哪怕只是三百字，也比停留在“计划中”更有价值。

结束语

欢迎你留下评论，一起交流。

AI Coding in Practice: How Non-Engineers Can Use Claude Code Effectively

Wed, 29 Apr 2026 10:00:00 +0800

I recently read an article by Tw93 about AI Coding that resonated deeply with me. He systematically introduced how non-technical people—product managers, business analysts, operations teams—can get started with Claude Code. After reading it, I felt many insights were worth extracting and sharing, so I put together this article.

The core idea is simple: The barrier is lower than you think. Anyone who can use chat-based AI like Doubao can learn Claude Code with some practice. The rest is just getting used to handing over execution to it.

1. From Chat Box to Terminal: Two Fundamentally Different Workflows

Many people are used to chat-based AI like Doubao or ChatGPT, and feel intimidated when they see a terminal. But these two modes have completely different workflows:

Chat-based AI: Describe requirement → AI generates code → Copy-paste elsewhere to test → Back and forth

Claude Code: Executes directly in your terminal project, reads, modifies, runs, verifies, then comes back to you when done

The difference? Chat-based AI needs you to be the porter. Claude Code lets AI do the work. You don’t need to know how to write code—you just need to describe the problem and verify the results.

If you really don’t want to touch the terminal, Anthropic has released an official desktop app called Cowork that can directly read and write to your Downloads and Documents folders—perfect for complete beginners.

2. Four Technical Fundamentals: You Don’t Need to Write, But You Need to Read

The author emphasizes that non-technical users don’t need to write code, but they should understand four basic concepts:

Common frameworks: Know what React, Vue, and Next.js solve
Software basics: Terminal commands, Git, VS Code, Chrome DevTools
Core programming ideas: Functions, variables/state, why code is split across multiple files
Reading code and errors: More useful than writing code—just throw error messages back at the AI

Spend a night or two going through freeCodeCamp or MDN basics, or watch the CS Crash Course on YouTube or Harvard’s CS50. You don’t need mastery—just basic awareness.

3. What Claude Code Is Best At

After trying Cursor, Windsurf, and other tools, the author’s primary tool remains Claude Code. Its core advantages:

Strong model capability, looks at the entire project together
Lives in the terminal—git, tests, scripts can all be called directly
Essentially a general-purpose Agent—Anthropic’s own non-engineering teams (sales, risk, finance) use it to process CRM data and customer emails

Key criteria: Two conditions must both be met—clear goals + easily verifiable results

Best use cases:

Building prototypes and internal tools
Processing CSVs, creating sales reports
Document work like extracting contract terms or comparing versions
Extracting information from links/PDFs from specific angles

“How fast the model is doesn’t matter—how accurate it does. If it finishes in 10 minutes but you spend 20 minutes debugging, it’s worse than if it takes 20 minutes but the result is immediately usable.”

4. Software for One: Build Software Just for You

Kevin Roose coined the concept of software for one—you don’t need to build apps for millions of users; you can build tools just for yourself.

His examples: Stash (organizing links), LunchBox Buddy (preparing kids’ lunchboxes). For non-technical people, it could be a tool that converts voice memos to meeting minutes, or a dashboard that reminds you of three things every day.

A gradual progression:

Time	Task	Output
Day 1	Have it modify an existing Excel or Markdown file	Learn the basics
Week 1	Build a single-page personal site or daily dashboard (15 minutes to set up)	A small showcaseable project
Month 1	Turn one thing you do repeatedly 2-3 times a week into a command or page	A daily efficiency tool
Month 3	Pick a software-for-one idea and build a tool just for you	A complete small tool

5. CLAUDE.md: Write a Handoff Document for AI

CLAUDE.md sits in your project root. Claude Code reads it every time it starts. It’s like a handoff document for a new colleague, except AI reads it thoroughly from scratch every time and follows it strictly.

Three key principles:

Keep it short: Under 150 lines—too long squeezes conversation space
Use direct language: Use imperative voice. “All comments must be in Chinese” works much better than “The team prefers Chinese comments”—soft language is less effective with AI
Every rule must be verifiable: Like “Functions over 50 lines must be split”

Four most valuable rules:

Ask before acting
Simplicity first
Only touch what’s asked
Verify when done

Key technique: Preserve during compression

Adding a “preserve during compression” section at the end is critical. Claude Code automatically compresses long conversations, and decision rationale is usually the first thing to go. For example, if you said “use POST instead of GET because data volume is large,” after compression only “use POST” remains—the reason is lost, and next time AI might give a completely different approach.

Recommended four-section structure:

Project background: Tech stack, team members
Work rules: Specific rules (Chinese comments, English variable names, explain before changing)
Prohibitions: Don’t refactor unprompted, don’t delete files, don’t install dependencies without confirmation
Preserve during compression (priority): 1. Architecture decisions and rationale → 2. What files were changed and how → 3. Current progress → 4. Incomplete TODOs

6. Requirement Description: Every Extra Detail Prevents a Rework

“Every extra specific detail prevents one rework.”

Vague version: “Help me build a customer follow-up tool” → Needs rework

Precise version: Sales follow-up tool, single HTML file stored locally. Left side shows company name, next follow-up date, status; right side shows communication history, date, key points; top has three filters (status, time, keyword); data stored in localStorage, no backend.

→ The precise version can produce a usable result the same day

Tw93 cited an extreme example: yetone’s macOS voice input tool requirements. Every specific detail prevents AI from guessing wrong:

What was written	What happens without it
macOS native + Swift	Might build a Python web app or Electron app
Default to Simplified Chinese zh-CN	Defaults to English, Chinese recognition rate is terrible
NSPanel + .hudWindow capsule window	Pops up a regular window, blocking the input field
LLM correction “extremely conservative”	Over-polishes, changes original meaning

Key points for business requirement writing:

Start by clarifying the problem and user
Explicitly define scope (no login, no sharing, etc.)
List edge cases separately
Give numerical acceptance criteria (like “first screen loads in 1.5 seconds”)
Avoid vague words like “TBD”—Claude Code will guess when it sees placeholders, and it’s usually not what you want

7. Plan and Auto Mode: Review the Plan Before Acting

Plan mode (press Shift+Tab twice): Lists the plan first, then executes. Like reviewing a proposal in a meeting before starting work. Good for complex tasks, prevents AI from overstepping.

The author learned this the hard way: when having AI refactor a login module, it deleted a utility class that would be needed later, costing half an hour to roll back. Since then, complex tasks always start with Plan mode.

Auto mode (press Shift+Tab to cycle): Safe operations run directly, risky operations ask first. Available on Max, Team, Enterprise; Pro not yet available.

When starting out, default to Auto mode.

8. Verification and Error Recovery: Three-Layer Verification + Root Cause Diagnosis

Three-layer verification

Did the command pass: Build and tests run green
Seeing is believing: Open the page, check numbers, test key flows
Check against the list: Go through acceptance criteria one by one

How to recover when something breaks

Git snapshot: Before major changes, have AI run git status to see clearly, then commit a checkpoint. If it breaks, say “revert to the last checkpoint”
Undo last step: Say “undo all changes just made” or press /rewind

Avoid death loops: Diagnose root cause first

“Don’t touch the code until the root cause is clear.”

Death loop: Error → Fix → New error → Fix again → After 4-5 rounds the problem becomes a mess

Correct path:

Have AI answer “which file, which line, why”
Vague answer → Keep investigating
Clear answer → Then fix
AI says “let me try changing X to see if it works” → Stop it, answer the root cause first

9. Advanced Tips: alias, opusplan, and Long Session Management

alias quick start

alias c='CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude --dangerously-skip-permissions'

--dangerously-skip-permissions: Skips all permission confirmations (not recommended for beginners)
CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000: Moves auto-compression point to 400k

opusplan mode

Type /model opusplan (hidden command): Planning uses Opus, execution uses Sonnet—saves both money and time.

Long session management

/clear when a task is done: One session, one task—switching between unrelated tasks in the same context makes it increasingly confused
Have it write handoff notes before long tasks end: HANDOFF.md with what was done, what didn’t work, and what to do next
Pick it up the next day in a new session

10. Waza Skill System: 8 Ready-to-Use Skills

Tw93 built 8 Skill tools:

Skill	Use case
`/think`	Think about the technical approach before starting
`/design`	Design product-quality pages, rejecting AI template feel
`/hunt`	Debug problems—no code changes until root cause is clear
`/check`	Final gate before finishing—diff review
`/read`	Convert web pages/PDFs to clean Markdown
`/write`	Make expressions clearer
`/learn`	Research workflow from collecting materials to writing articles
`/health`	Health check for CLAUDE.md and rules

Install: npx skills add tw93/Waza -g

Special recommendation: /design for product/business/ops—screenshot + /design makes AI first ask about target users, vibe, styles you dislike, micro-interactions, rather than just spitting out an “AI template-looking” page.

Three common types of custom Skills:

Workflow type: Package fixed steps (like organizing meeting notes)
Checklist type: Run through before going live to avoid missing items
Domain expert type: Codify judgment frameworks (like production issue investigation)

Writing tips:

description writes trigger conditions, not feature descriptions: “Call when you have raw meeting notes to organize” is much more accurate than “Organize meeting recordings into structured weekly reports”
One Skill does one thing only

11. Other Useful Tools

Kami: AI Typesetting Tool

Install: npx skills add tw93/Kami -g

8 templates (one-pager, portfolio, slides, resume, etc.), consistent style. Use cases: Meeting notes → brief, project progress → one-pager, personal experience → resume.

OpenCLI: Turn Web Actions into Commands

Website: opencli.info

Built-in CLI adapters for Xiaohongshu, Zhihu, Twitter/X, Bilibili, and more—turns web actions into commands. Use cases include scraping Xiaohongshu research data, auto-compiling multi-platform sentiment into daily reports.

Claude Design: Prototypes Without Code

Website: claude.ai/design

Launched by Anthropic in April 2026. Upload screenshots or documents to generate interactive prototypes, slides, or landing pages. Product managers can use it to draw prototypes for review, then hand them to Claude Code to turn into code.

12. Small Habits After Getting Comfortable

Screenshots are faster than text: Drop an image to describe interface issues—layout, colors, hierarchy all come through
Break tasks into small pieces: Tasks that can be described in one sentence almost never go wrong
Restart when the conversation goes off track: Clearing context and starting over is faster than trying to correct it repeatedly
Memory remembers preferences across projects: Say “remember I like to see the plan first” and it’s permanent
Double-tap ESC to edit the last message: No need to restart the session

13. Security Habits

In CLAUDE.md, require explaining what will be done before every execution
Ask about unfamiliar commands before confirming
Don’t practice on production environments
Store API keys in environment variables or .env files, never paste them into chat
For features involving login, payments, or personal information, use services like Clerk or Stripe rather than building from scratch

Final Thoughts

After reading Tw93’s article, my biggest takeaway is: The barrier to AI Coding really isn’t that high.

Many people feel intimidated by terminals and think command lines are exclusive to programmers. But in reality, Claude Code is essentially a “very blunt but technically brilliant programmer”—you just need to explain the problem clearly and set good acceptance criteria, and it does the work.

From modifying an Excel file, to building a small tool, to automating weekly repetitive work, everyone can find their own “software for one.”

The key isn’t whether you can write code—it’s whether you can explain the problem clearly.

Further reading:

As AI Gets Better at Writing Code, The Scarce Skill Is Explaining Direction Clearly

Thu, 12 Mar 2026 10:30:00 +0800

Over the past two months, one idea has become harder and harder to ignore:

Writing code is rapidly losing its old status as a scarce craft.

That does not mean engineers are disappearing. It does not mean software matters less. If anything, software will become even more abundant, code will become cheaper, and the expensive part will shift away from typing implementation by hand toward defining problems, setting constraints, and validating outcomes.

In other words, AI is eating the most scalable part of programming, while amplifying the hardest part of software engineering.

That is likely the real shift of the next few years.

1. There Will Be More Code, But “Being Able to Code” Will Not Be Enough

For a long time, we judged engineers by a familiar set of visible strengths:

how many languages they knew
how fast they could write code
whether they could build a feature alone
how quickly they could start implementation after reading a requirement

Those skills still matter. But their relative value is starting to fall.

The reason is not mysterious. In the past, implementation capacity was scarce. Turning an idea into working software required a lot of manual translation. Now more of that translation layer can be delegated to agents. You describe the task, provide context, point out mistakes, and the system can keep generating implementation, tests, refactors, or even PRs.

So what changes?

It means “can this person write the code?” is moving from a differentiator to infrastructure.

Teams will increasingly need fewer people whose only advantage is shipping implementation fast, and more people who can answer questions like:

Should this feature exist at all?
What should be built first?
How should the task be decomposed for an agent?
What counts as success?
If something breaks, is the problem in the model, the workflow, or the architecture?

Code still matters. But code itself is no longer the scarcest asset.

2. AI Is Best at Constrained Acceleration, Not Freeform Creation

A lot of disappointment with AI coding comes from giving it the wrong kind of problem.

People ask agents to:

invent a product from scratch
explore vague business logic with no clear boundary
take over a messy legacy system with no tests and no documentation
complete a large system from one sentence of intent

That is exactly how you get bad results.

The pattern that now seems most important to me is this:

AI coding works best not when it is asked to invent everything, but when it is asked to move quickly inside a clear set of constraints.

What does that require? At least four things:

1. A Reference Point

An existing implementation, an API spec, a prior version of the codebase, or even a solid pseudocode sketch can dramatically improve agent performance.

2. Automatic Validation

Tests, type checks, lint rules, CI, browser checks — these are not decorations. They are the guardrails that let agents correct themselves.

3. An Architectural Plan

Instead of throwing a blob of requirements at the model, you define module boundaries, execution order, and interface constraints first.

4. Ongoing Human Direction

Agents are productive, but they do not have real ownership. They can be confidently wrong and continue down a bad path for a very long time. Someone still needs to hold the wheel.

That is why I increasingly see agents as a very high-output execution layer, not as a substitute for product or engineering judgment.

They can move fast. But humans still need to decide where the road goes.

3. Software Engineering Is Not Disappearing. It Is Moving Back Into Focus

The biggest mistake in many discussions about AI coding is treating “writing code” and “software engineering” as the same thing.

They are not.

Writing code is closer to construction. Software engineering is closer to:

clarifying requirements
defining boundaries
making architectural decisions
controlling quality
isolating risk
deciding maintainability trade-offs
owning failures when systems go wrong

In the past, construction itself was expensive enough that people often confused it with the core value of engineering. Once construction becomes cheaper, the rest of the discipline comes back into focus.

That also explains a common frustration:

If AI can already write so much code, why do teams not feel dramatically lighter?

Because removing the implementation bottleneck does not automatically solve the harder problems:

whether the direction is right
whether the code is reliable
whether the system is maintainable
whether the team is optimizing the right thing

And in some cases, those problems get worse faster.

If a team used to ship 3 changes a week and now ships 30, weak tests, stale documentation, shaky architecture, and hidden technical debt all become visible much sooner.

AI will not automatically rescue a team with weak engineering practices. Often it just exposes the weakness earlier.

4. The Scarce Skill Is Moving From Implementation to Orchestration

I think one shift will become increasingly obvious:

The engineer’s role will gradually move from code implementer to problem orchestrator.

“Orchestration” here is not a fashionable buzzword. It is a concrete bundle of skills:

breaking fuzzy requests into executable tasks
recognizing which tasks fit agents and which do not
providing enough context without flooding the system
designing feedback loops for self-correction
making decisions at key checkpoints instead of drowning in line-by-line supervision

Put simply, the strongest engineers of the next few years may not be the ones who most enjoy typing code by hand. They may be the ones who are best at organizing a full human-plus-agent workflow.

That sounds a little like management, but it is not exactly traditional management.

It is more like this:

You are managing a digital team that can write code, make mistakes, hallucinate, and still deliver enormous execution leverage.

If all you can do is implement by yourself, but you cannot decompose problems, set standards, or evaluate outcomes, your advantage gets thinner.

If you can make the problem clearer, the constraints tighter, and the acceptance criteria sharper, the amount of useful execution you can unlock gets much larger.

5. What Changes Most for Ordinary Engineers?

The most practical shift is probably not “everyone will be replaced.” It is that the baseline expectation for engineers will rise.

Skills that once belonged mostly to senior engineers are moving earlier in the stack:

defining task boundaries independently
reading and maintaining test systems
making small but correct architectural decisions
spotting plausible but wrong AI output
making trade-offs between speed and quality

That makes life harder for juniors, and also for people who are used to seeing themselves purely as ticket executors.

But it is not entirely bad news.

If AI absorbs more of the mechanical work, human growth may also be pulled forward. People may be forced earlier into system thinking, into the overlap between product and engineering, and into understanding why thinking clearly matters more than merely shipping implementation.

The real danger is not “not knowing how to prompt.”

The real danger is reaching the AI era and still seeing yourself as someone who receives requirements, writes implementation, and closes tickets.

That role may not disappear tomorrow, but its bargaining power will likely keep declining.

6. Final Note

My view is fairly simple.

AI will not make software engineering disappear.

It will make code cheaper and engineering judgment more expensive.

Code will keep exploding in volume. Software will keep multiplying. What will matter is not who can type more lines, but who can keep direction clear inside a much higher-output system.

So if we ask what kind of engineer becomes truly scarce in the AI era, my answer is straightforward:

Not the person who can write the most code, but the person who can explain the problem clearly, build the right constraints, and verify the result with discipline.

That kind of engineer does not get cheaper. It gets more valuable.

When Growth Looks Healthy but People Still Feel the Squeeze

Fri, 27 Feb 2026 21:30:00 +0800

Lately I keep returning to one uncomfortable sentence: the economy is growing, but that growth feels less and less connected to ordinary people.

On paper, many numbers still look solid. In real life, people around us are still worried about hiring freezes, slower salary growth, and shrinking role demand. Both are true at the same time.

That contradiction is the point.

1. The Old Model Is Breaking

For years, we used a simple mental model:

weak economy -> fewer jobs
recovery -> hiring comes back

That model worked well enough in a labor-heavy growth cycle. But now we are seeing a different pattern: companies can keep improving output without adding headcount, and sometimes by reducing it.

As engineers, we would call this a system rewrite, not a short-term incident.

old architecture: scale mostly by adding people
new architecture: scale by automation, software, and AI

In the old world, layoffs often looked temporary. In the new world, many roles are not paused; they are removed from the design.

2. Macro Wins, Micro Pressure

One reason this feels confusing is that we are looking at different metrics.

Macro indicators are like average throughput: they can look strong and stable. Individual experience is closer to P95/P99 latency: if the long tail gets worse, users still feel pain.

Translated to daily life:

GDP growth does not automatically mean job growth.
Profit growth does not automatically mean wage growth.
Better technology does not automatically mean better outcomes for most workers.

A system can be objectively faster while more users report a worse experience.

3. Why This Time Feels Different

We used to replace human effort in layers:

physical work with machines
memory work with search and databases
parts of reasoning with software

Now these layers are being merged into one production flow with AI + automation + robotics. When that stack works end to end, replacement speed is no longer linear.

A process that once required a full team can now run with:

one engineer
one AI-assisted workflow
a smaller operations loop

From a company perspective, this is efficiency. From a worker perspective, this can be sudden displacement.

Both statements can be true.

4. Layoffs Are Becoming a Standard Tool

Another shift is cultural, not just technical.

In many organizations, layoffs are no longer treated as a last-resort emergency response. They are increasingly used as a routine management instrument to protect margins and improve “revenue per employee.”

That changes the game:

headcount growth is not always rewarded
leaner teams with equal output are often rewarded

The irony is obvious in tech: we build tools to increase efficiency, then those same efficiency gains reduce demand for the teams that shipped them.

This is not about blaming workers for “not working hard enough.” It is about incentive structures and where value is captured after productivity increases.

5. What I Think Developers Should Do

I do not think the right response is panic, and I do not think denial helps either. We need a better model and practical strategy.

Three things feel clear:

First, waiting for a generic recovery to restore all old roles is risky. Some jobs are cyclical; many are now structurally replaced.

Second, coding skill is still essential, but “only coding” is becoming baseline. Higher resilience comes from combining engineering with business context, system design, process ownership, and communication across functions.

Third, career planning should move from job-title thinking to capability-stack thinking. Titles can disappear. Real problems do not.

If your work is close to core business pain points and hard to abstract away, your replacement risk goes down.

6. Final Note

I am not anti-tech, and I am not anti-AI. I work in this field and I benefit from these tools every day.

But technology does not distribute gains by itself. It optimizes what can be optimized. Whether that optimization improves life broadly or concentrates value in reports and valuations depends on policy, governance, and organizational choices.

That is why the “jobless growth” discussion matters.

The hard question is not whether development should continue. The hard question is: in an era of growth with fewer jobs, how do ordinary people still build a stable and dignified life?

This is where the real conversation starts.

Homecoming, Then Forward

Wed, 18 Feb 2026 04:00:00 +0800

The annual leave I had been waiting for finally arrived. After a 12-hour high-speed train ride, I made it home.

I stayed for a few days, carrying too many thoughts at once, but had no idea where to begin writing. Later I realized it was not a lack of words. Some feelings are simply too real, and that makes them harder to put down.

A Reunion With Too Many Unspoken Words

Before the holiday, a childhood friend from my hometown added me on WeChat through my cousin. We had not seen each other for many years. The last time I heard about him was through scattered updates from my mother.

He grew up as a left-behind child and was raised by his grandmother. After she passed away, things got even harder. His parents had divorced years ago. His mother remarried and no longer stayed involved. His father worked away from home and never really returned.

He had been in college and was always an excellent student. But there is still a younger brother in elementary school back home. To keep the family going, he had to pause his studies, return to the village, take tutoring jobs, and handle daily care at home, including cooking and supporting an uncle with an intellectual disability.

I still do not understand why someone so hardworking had to be placed in such a heavy life script.

After we reconnected, I thought we would finally sit down for a long drink and talk through everything we had never said. In the end, we met, exchanged an awkward smile, asked about each other’s current life, and then missed the chance again because of other commitments.

A lot remained unsaid.

I only hope his life becomes easier, steadier, and kinder in the years ahead. I say the same to myself.

The New Year Feels Different Now

This time, fireworks were suddenly banned again in my hometown. Villages still had some signs of the holiday, but the county town felt unusually quiet. The memory of packed streets, lantern shows, and loud festive nights from childhood feels very far away now.

Some memories belong to a specific era and do not return.

Maybe the core meaning of the New Year has changed. For many of us who work away from home, it is now mostly a precious window to return and stay with family.

Even when the atmosphere gets quieter, reunion still matters. No fireworks can replace a peaceful meal with family.

Hard Rules For My New Year

For 2026, I set a few practical rules for myself:

Build strict money management habits and stop paying for impulsive consumption.
Save consistently and create more options for my future.
Keep turning inward emotionally and stop making other people my only emotional anchor.
Hope to have a healthy, mutual relationship that can hold both sweetness and hardship.

These are not slogans. They are constraints I want to execute in real life.

Final Note

For you, and for myself, in 2026:

May work go smoothly, may health stay steady, and may what we truly seek become what we truly gain.

My Mac Productivity Toolkit (2026)

Sun, 08 Feb 2026 05:00:00 +0800

This list is based on long-term use. I’m not chasing “the most features,” only apps that clearly reduce operational friction, stay stable, and can be trusted long-term. The principle is simple: fewer, better, and light-weight first.

If you’re building your own Mac workflow, I hope this helps.

1. Raycast

Website: https://www.raycast.com

This is my personal “productivity gateway,” and the first app I recommend. Command + Space covers 80% of daily actions: launching apps, searching, running commands, quick switching.

My most used extensions:

Clipboard History: revisit recent copies, great for writing and coding
View 2FA Codes: see TOTP codes quickly without reaching for the phone
Translate: quick translation for reading materials

The core reason I recommend it: fewer context switches, less attention breakage.

2. BetterDisplay

Project: https://github.com/waydabber/BetterDisplay#readme

A lifesaver for external monitors. On a 2K display, native macOS scaling can look soft and awkward. BetterDisplay lets you fine‑tune scaling and rendering, with a visibly sharper result.

If you use external monitors—especially 2K—this is worth installing.

3. AltTab

Project: https://github.com/lwouis/alt-tab-macos

macOS’s built‑in app switcher doesn’t show window previews, which makes multitasking less intuitive. AltTab feels like Windows Alt+Tab:

Window thumbnails
Switch within one app or across all windows
Much better for multi‑window workflows

If you jump between many windows, the improvement is obvious.

4. MOS

Website: https://mos.caldis.me

A tiny “install and forget” app. Scrolling becomes noticeably smoother, especially if you use a mouse.

5. Stats

Project: https://github.com/exelban/stats

A lightweight menu‑bar monitor. I mostly use network status to check my IP, but it also handles CPU/memory/disk/temperature well.

Why I keep it: light, stable, and easy to configure.

6. Keka

Website: https://www.keka.io/en

A dependable compression tool on Mac. It supports common formats, has a clean UI, and is low‑maintenance. I install it and never think about it again.

7. Keyden

Project: https://github.com/tasselx/Keyden

A convenient TOTP authenticator that lives in the menu bar. One click to see codes. If you log in frequently, this saves a lot of phone switching.

8. Shell360

Project: https://github.com/nashaofu/shell360

An SSH client with a clean interface and sensible defaults. For me it’s “simple and comfortable,” with no obvious downsides so far.

9. MiaoYan

Project: https://github.com/tw93/MiaoYan

A Markdown note app by Tw93, and the one I’m currently using. The biggest strengths are the beautiful UI and restrained features—it doesn’t become bloated with plugins and heavy configs.

If you write a lot or keep notes, MiaoYan feels great.

10. ClashMac

My proxy needs are minimal; stability comes first. After running into odd issues with Mihome and Spleak, I landed on ClashMac for one simple reason: intuitive menu‑bar controls, easy config, and stable behavior.

That’s my long‑term Mac toolkit. The rest is fairly standard: full‑stack dev tools + common communication apps.

If you have better picks, feel free to share.

Walk Outward

Fri, 06 Feb 2026 18:00:00 +0800

I often read history late at night. I watch heroes stream by like fish crossing a river, and dynasties rise and fall like tides. One page is filled with prosperity and boldness, the next turns into smoke and ash. Those names are dazzling, almost blinding; yet after the brightness, silence arrives. The longer I look, the more I start to wonder: what can our struggles and convictions really leave behind?

Later I started reading poetry. A poet’s fate feels like a mirror: some carry ideals to the edge, some turn all their hopes into short lines during turbulent times. The lines are light, as light as a falling leaf, but they cross time and land on my desk today. I realized many people were not crushed by a single blow; they were pushed by their era, pushed to a place even they did not recognize.

Then I lifted my eyes to the stars. Humanity explores the universe and searches for life beyond Earth—it’s a magnificent undertaking. But when I pull the lens back to a larger scale—the boundless sea of stars, the slow drift of time—we are not that different from dust. When that smallness hit me, it felt like a hollow opening inside: every narrative of meaning seemed diluted. I grew lost and even began to doubt what effort was for.

In that confusion, I suddenly understood Liu Bang better. I never cared much for him before; he didn’t seem “perfect,” nor “noble.” But the more I read, the more I saw his rare pragmatism: he could bend or stand, advance or retreat, fight fiercely or withdraw when he had to. He did not cling to a rigid self-image of “how one must be,” but chose to live through change. The phrase “nothing is absolutely required, nothing is absolutely forbidden” gained weight in my heart—it isn’t going with the flow; it’s knowing your boundaries and walking the road within them.

That loosened me a little. I don’t have to force myself into being “someone who must be impressive.” I don’t have to compress life into a single line for the sake of being “right.” Maybe meaning isn’t something to prove; it’s something to experience. History may close its curtain, but we still have to walk through it. The universe may be vast, but every breath and heartbeat remains real.

I also realized I couldn’t keep sitting alone among books. Even the sharpest thinking, without the touch of the body and the feedback of reality, is just drawing circles in the air. I need to walk outward—toward mountains and seas, streets and crowds, the sound of rain on an umbrella, a glance exchanged with a stranger. Even buying a hot meal at the market or stopping to smell flowers by the road does more to confirm: I am alive, and I still have a direction.

So I decided to bring my gaze back from the sky to people. I read history not to be discouraged, but to understand. I watch the stars not to deny meaning, but to cherish it. I read poets not to rehearse sorrow, but to learn honesty. I will keep thinking, but no longer sink into it alone. I will step outside, carry the waves inside me into reality, and let my steps answer the questions that keep circling in my mind.

That’s why I wrote this piece:

Not to give myself an answer, but a direction.
Not to prove I’ve understood the world, but to admit I’m still learning.
Not to escape my inner life, but to let life illuminate it.

If you are in a similar fog, I hope you can, like me, take one step outward—even if it’s just a small step. The world will respond in its own way—not necessarily grand, but real enough.

Hello, world

Thu, 05 Feb 2026 18:00:00 +0800

Welcome to your new blog!

This is a minimal starter post.
Add more posts under _posts_en/.