01. AI 让我的代码变好了，我却没以前那么快乐｜工程师十年自述

2025 年 4 月，我用 Python 写了一个命令行工具，用来测试 Akamai 规则。

修改这类规则有个麻烦：动一处，别处可能跟着遭殃。因此，每次改动后都要跑大量回归测试。不同团队使用的编程语言又不一样，如果大家都用自己的语言重写一套测试，规则还没测完，协作成本可能先爆了。

我的办法是用 YAML 设计一套简单的测试语法。使用者不需要知道工具内部如何工作，只要按约定写清请求、条件和预期结果，就能添加测试案例。

一周后，我做出了第一个版本。它能读取文件夹里的测试内容，通过命令运行全部案例，再把结果显示在终端中。功能能用，代码也尽量写得便于维护，只是边角处还留着不少问题，准备以后慢慢收拾。

接着，我把需求和代码交给了 ChatGPT。

那时我还没用上 Claude Code 这类 Coding Agent，只能守着聊天窗口来回复制代码。我先把 Vitest 的输出发给它，希望它理解我想要的终端界面，再让它尝试写出初始版本。

不到三十分钟，可以运行的结果出来了。

代码当然有 Bug，但它已经知道哪里需要抽象、模块该怎么组织、功能怎样保持内聚。终端输出也像模像样。它不但自动补了单元测试，连边界情况都比我预想得更周全。

我没有删掉自己的版本，也没来得及感叹多久。接下来，我继续拆分功能：大约一成代码自己写，剩下九成交给 AI。等主体架构稳定后，我负责提出需求、检查结果，它负责实现。

项目跑得更快了，结果大概也更好。

可我没有以前那么快乐。

创造欲比“工程师”这个身份来得更早

小时候，我很喜欢电脑。

周末父母出门后，我会一个人偷偷玩到他们回来。听见钥匙插进门锁，我立刻拔掉电源，试图制造“一整天都没碰过电脑”的假象。

这招从没成功过。主机会发热，CRT 显示器关机后还会随着温度下降发出几声“嘎吱”。如果等父母进门才断电，那块显示器通常比我更诚实。

除了玩游戏，我也会拆开主机，把零件重新装回去，再拿 Windows 98 光盘重装系统。那时家用电脑经常出问题，也没什么现成的人可以问。我只能翻着电脑期刊，研究 MS-DOS、BIOS 和硬件设置。

做这些事没有明确目的。我只是想知道，电脑里面到底发生了什么。

有一次，我从同学那里换来一张盗版游戏光盘。除了想玩的游戏，里面还塞着 Dreamweaver 和 3ds Max。我不认识这两个软件，以为它们也是游戏，于是一个不落，全装了。

打开 Dreamweaver 后，我随手做了一个页面，又在旁边的代码窗口里敲了几个字符。页面立刻变了。直到上大学，看见高年级学生用 Dreamweaver 做毕业设计，我才意识到：小时候那次漫无目的的乱点，已经让我碰到了网页代码。

3ds Max 更让人困惑。软件打开后，里面有个可以调整的茶壶。我一直以为，只要把茶壶设置正确，就能进入后面的游戏环节。

我等了很久。游戏始终没有开始。

那时的我从没想过要成为软件工程师。我只是喜欢一种感觉：动一动某个东西，看它发生变化，再想办法弄明白，变化为什么会发生。

一个失败的博客，把我带进了软件行业

我曾在国内大学读过不到一年计算机科学与应用。大一时，日本留学签证办了下来，我放弃国内四年学业，来到日本重新开始，后来选择了商务专业。

2011 年，我正在日本读大学一年级。半工半读，每月收入不到七百美元。陪我时间最长的，是一台价值大约一百五十美元的华硕笔记本。

那时，我看到一个介绍旅游和消费的博客。网站设计不算复杂，瀑布流布局却很吸引人。日本旅游正在升温，我便冒出一个念头：我也可以做一个面向外国人的日本生活与旅行网站。

当天，我租下服务器，又去 GoDaddy 买了 jaforeign.com。名字由 Japan 和 foreign 拼在一起。现在看，又长又有点土；但在当时，这已经是我绞尽脑汁后的成果。

服务商明明提供一键安装 WordPress，我却主动选择了更折腾的路线。我照着网上的博客敲 Linux 命令，亲手在服务器上搭建 LAMP 环境。等 WordPress 正常运行、域名终于能够打开时，我以为最难的部分已经结束。

接下来，不就是写文章吗？

三天后，我写出了大约一百字。

问题并不复杂：我根本没有多少旅行经历。半工半读占去了大部分生活，剩下的时间又几乎全给了电脑、游戏和影视。我想做旅游内容，手里却没有多少可以持续讲述的东西。

博客最终只留下两篇没写完的文章。不到两个月，我退掉服务器，关掉了网站。

从产品角度看，它失败得相当彻底：没有稳定内容，没有读者，也没活多久。但我对搭建博客的兴趣没有跟着消失。服务器、Linux、LAMP 和 HTML，后来都成了我进入软件行业时为数不多的筹码。

我没找到适合自己的内容方向，却意外找到了一件愿意长期做下去的事。

“我等你很久了，以为你不会来了”

商务专业毕业后，我进入一家会计师事务所。大学期间学过不少簿记和会计课程，这份工作看起来顺理成章，做起来却完全不是那么回事。

每天面对数字和报表，我越来越清楚：如果未来几十年都要这样过，我大概坚持不了。

工作五个月后，我裸辞了。没有下家，也没有攒下足够的生活费。最困难的时候，我一天只吃一顿饭，最后还是向父母要了些钱。

我想转行做软件工程师，可搭建博客积累的那点经验，远远不够我通过大多数面试。

后来，一名招聘人员把我介绍到东京市区一家 IT 公司。办公室不大，大约能容纳三十个人。负责人听完我的经历，愿意先培训我，再让我进入项目。

我却觉得，自己也许还能找到更大的公司。

答应第二天报到后，我没有出现，继续去了其他面试。

三周过去，没有一家公司愿意录用我。

我只能再次给那位负责人发邮件。回到办公室，他见到我后说的第一句话是：

“我等你很久了，以为你不会来了。”

他问我这几周去了哪里，为什么没早点报到。我一边庆幸机会还在，一边不得不承认：当时的我，确实没有进入大公司做开发的能力。

培训期间，他让我用 PHP 和 HTML 写一个计算器。我当天完成了加减乘除，还实现了带括号的运算。页面很丑，但至少能算。

第一个正式任务来自一个用户管理系统。项目交给了公司在印度的团队维护，我负责商品列表页面，需要展示数据并提供过滤功能。项目使用 CakePHP。我从早上一直做到第二天凌晨五点，三天后仍然只完成了列表展示，过滤功能没能按计划做完。

这就是我软件工程职业的起点。

没有漂亮的逆袭，也没有突然显露的天赋。只是有人愿意给我一个入口。我交出一个丑陋的计算器，又在第一个项目里暴露了几乎所有能力不足。

此后十年，我从测试做到前后端开发，也接触过大数据、架构和云基础设施。2018 年，我加入乐天；2024 年，我进入迅销，继续做前端开发。

但真正让我确认自己喜欢创造软件的，从来不是职位名称。

作品被人用起来，创造才算完整

2017 年，我所在的团队使用 iView UI 开发一个内部 Dashboard。系统主要处理数据的增删改查，例如给数据添加标签，或者删除从 Twitter 抓取回来、但不符合要求的内容。

当时有个需求：让 Tag 组件支持选择状态。使用者可以通过点击控制某项特征，例如是否显示图片，或者在几个尺寸中选择一个。Element UI 已经有类似能力，我们使用的 iView 却没有。

既然项目需要，我便试着把这个功能补进 iView。

2017 年 10 月，我提交了 PR #2124，给 Tag 组件增加 checkable 和 checked 状态，同时补上事件处理和使用示例。维护者后来调整了部分实现，功能最终进入项目，我们的内部 Dashboard 也用上了它。

再后来，GitHub 上开始出现与这个功能有关的问题。

这意味着，真的有人在使用它。也有人在实际使用中遇到问题，需要它继续被修好。

每当看到一个陌生人借助我写的功能解决问题，我都会感到一种很难准确描述的快乐。它不只来自代码被合并，也不只是技术方案得到认可。更重要的是，我做出的东西进入了另一个人的工作，并在那里发挥了作用。

那时，我在意两件事。

一件是产品有没有人用，能不能解决真实问题。

另一件是实现过程中，我能不能进入那种高度专注的状态：注意力一点点收拢，周围的声音慢慢退去，脑子里只剩问题、结构和代码。几小时过去，人很累，满足感却也很完整。

对我来说，这两件事合在一起，才叫创造。

我总在搭建，却很少留下来运营

这股创造欲，也让我做过不少没有完成的项目。

2020 年开始远程工作后，通勤和办公室交流减少，我突然多出许多时间。我会拿这些时间做软件，把偶然冒出的想法变成 GitHub 上的小仓库。很多项目没有完成，也没有用户，但我仍然喜欢从空目录开始，一点点把结构搭起来。

rotalacss 是其中比较完整的一个。它基于当时流行的 Tailwind CSS，也参考了 Spectre.css 的组件设计。我认为原子化 CSS 能降低大型项目中的心智负担，于是想把 Tailwind 的使用方式与传统组件框架结合起来。

方向未必错。问题还是出在我身上：我喜欢早期搭建，却没有持续维护。

Pitayan Blog 又重复了同样的故事。

我原本想写技术文章，最后却一直在修改博客主题，把大量时间花在网站本身。文章也在写，可英语不是我的母语，当时又没有 AI，一篇往往要写十天。后来有两篇文章登上 Hacker News 首页，带来一阵流量，我却没能稳定更新下去。

作为产品，它们都没走多远。作为练习，又不能说毫无价值。rotalacss 让我更深入地理解了 CSS 框架设计；Pitayan 训练了我的英文写作，也让我第一次被较大规模的读者看见。

它们还共同暴露了一个反复出现的问题：我擅长把东西从零变成一，却不擅长陪它从一走得更远。

以前，我把这简单归结为缺乏毅力。现在回头看，也许还有另一层原因：比起运营一个已经存在的东西，我更迷恋从无到有时，那段注意力被完全吸进去的时间。

从写代码的人，变成委任 Agent 的人

现在，我每天都会在 Claude Code 和 OpenAI Codex 中委任开发任务。我会选择合适的 Skill，也会补充 Agent 完成任务所需的背景、步骤和约束。

需求明确时，我通常不再先动手写代码，而是先和 AI 讨论方案。需求还很模糊时，我也会让它参与梳理，把一个模糊的念头慢慢变成可以执行的任务。

同时委任多个 Agent 已经成了常态。不过，我通常让它们围绕同一个项目工作。项目一多，我就得不断切换上下文，而频繁的 context switch，对需要集中注意力的工作并不友好。

我的时间逐渐转向需求、架构、测试和产品判断。过去必须亲手完成的实现，如今大量交给 AI。有些任务自己写可能更快，但只要需求足够清楚，我还是会优先让 Agent 试试。

效率提高后，我当然感到满足。过去需要几天的工作，现在一天就能推进不少。以前因为时间不够而放弃的想法，也有机会变成原型。

只是，这种满足没以前那么丰满了。

过去写代码时，我会沿着问题一层层深入。命名、抽象、边界、异常处理，都要在脑子里走一遍。注意力也在这个过程中慢慢沉下去，直到进入心流。

现在，Agent 常常一次生成大片实现。我需要阅读、检查、调整，然后发出下一条指令。节奏快了，心流却更容易碎。

我仍会故意手写一些代码，保持自己对编程的敏感度。不是因为手写必然更好，而是太久不碰实现，我会慢慢失去判断 Agent 产出质量的基础。

对我而言，单纯“写前端代码”已经很难继续成为职业优势。AI 能在更短时间内生成相近、甚至更好的结果。我用十年培养出的能力没有全部消失，但其中最熟悉、也最容易展示的那一部分，正在迅速贬值。

参与到什么程度，作品才算自己的

如果只看产品结果，我应该欢迎这种变化。

我一直认为，作品价值取决于它能不能解决用户的问题。既然 AI 可以更快交付功能、提高测试覆盖率、减少重复劳动，那么坚持亲手写完每一行代码，反倒可能拖慢解决问题的速度。

可结果并不是全部。

如果一件作品由 AI 完成，问题、方向和取舍由我提出，我当然可以对外说：这是我的作品。

但在自己心里，我很难说得那么笃定。

大量细节没有经过我的手。抽象和实现由 Agent 包揽，整个东西也没有在我的脑子里被完整地走过一遍。我知道它能工作，却不再总能感到它是从自己身体里长出来的。

我并不认为，创造等于亲手敲下每个字符。即使不写具体代码，只要一个人参与了主体框架、实施方案和关键细节，真正想清楚问题该怎样解决，我仍然愿意把它看作创造。

难处在于，这条界线一直在移动。

今天的 Agent 已经能参与需求分析、架构设计、编码、测试和文档。未来还要由人完成多少环节，作品才仍然属于那个人？当人的工作渐渐只剩选择、批准和修正，这些行为还足以支撑过去那种“我是创造者”的感觉吗？

我最害怕的，并不是失去工作、职位或原有的竞争力。工作可以换，技能也可以重新学。

真正让我不安的是：我热爱的创造过程可能被不断压缩，最后只剩下验收结果。

我仍然会继续使用 Agent。效率带来的价值无法假装不存在，退回完全手写代码也不是答案。

只是，当我同时委任多个 Agent，看着它们以过去难以想象的速度生成代码时，偶尔还是会想起那个躲在家里玩电脑的孩子。

他拆开主机，重装系统，在 Dreamweaver 里随便敲下几个字符，看着页面立刻发生变化。那时没有用户，没有职位，也没有效率指标。他甚至不知道自己碰到的是代码，却能清楚地感觉到：

这件东西，经过了自己的双手。

如今，我还在创造软件，只是不再经常亲手写代码。效率问题已经解决，剩下的问题反而更难回答：

当一件作品越来越少经过我的双手和思考，我凭什么确认，它仍然属于我？