AI 行人才培养路线图：我从面试思考和两个工具开发中学到的事

这篇还是和 AI 闲聊后整理出来的一段想法。原始表达比较散，后来请 AI 帮忙顺了一下。

前一段时间，我一直在想 AI 编程、AI 协作、AI 对工程师的影响。想得多了以后，反而觉得可以先收一收。

宏观上的事情，可能会进入一段很长的社会拉锯战。这个不是我一个人能想清楚的，也不是我现在真正能处理的。对我来说，更现实的问题是：

如果以后 AI 会长期参与开发，那一个工程师应该怎样训练自己？

我把这段时间做 ZeroTraceBrowser 和 ZeroTraceMobile 的经历回头看了一遍，发现里面其实有一条很清楚的路线。

一开始，我只是让 AI 帮我写代码。后来，我开始让 AI 帮我整理设计。再后来，我发现自己做的不是一个个孤立工具，而是一套逐渐成形的个人工具链。

这篇文章不是教程，也不是给别人定标准。只是把我自己的体验写下来，算是给这段时间的 AI 研究画一个阶段性的句号。

第一阶段：AI 写代码，我跟着救火

最开始做 ZeroTraceBrowser 的时候，我对“图片浏览器”其实没有什么概念。

当时的想法很简单：

不就是一个图片浏览器吗？

所以我直接让 Codex 帮我实现浏览界面。然后把上一个 AI 项目里做过的导入工具接进来，做成图片导入和去重的入口。数据先用 JSON 保存。

一切看起来都挺好。

有导入界面，有重复查看界面，有删除恢复界面，图片也能浏览，数据也能保存。照这个感觉，好像两三天就能结束。

结果最后做了两个星期。

问题是从时间线开始变复杂的。

我给一览画面加了时间线功能以后，整个系统的复杂度突然上来了。页面之间开始互相牵扯，处理逻辑互相调用，哪里都像是在补洞。

那时的代码还能跑，但我自己已经开始找不到逻辑在哪里了。

后来回头看，问题并不是 AI 不会写代码。AI 确实很快把功能写出来了。但我没有先把系统结构想清楚，就让它不断往里面加东西。

结果就是：

• 功能越来越多。
• 页面越来越乱。
• 调用关系越来越绕。
• 每个地方都像是在给另一个地方打补丁。

这是我在 AI 编程里踩到的第一个大坑：

AI 可以很快帮你写出功能，也可以很快帮你写出混乱。

如果人没有先定义结构，AI 并不会自动替你把系统收住。它会顺着当前代码继续写，而当前代码如果已经开始歪了，后面的代码只会更歪。

第二阶段：我开始意识到，结构比功能更重要

ZeroTraceBrowser 第一版能跑以后，我反而开始不安心。

因为我看到了那些混乱的调用关系。虽然项目不大，还跑得动，但我知道这样继续下去迟早会出问题。

于是我开始让 AI 帮我重构。

这一次重点不再是“加功能”，而是重新分清楚：

• 哪些逻辑属于导入。
• 哪些逻辑属于浏览。
• 哪些逻辑属于重复检查。
• 哪些逻辑属于删除和恢复。
• 时间线应该在什么情况下更新。
• 页面之间到底该不该互相知道对方的状态。

这一步花的时间，比最初做功能还多。

但做完以后，系统明显安静了很多。

后来我又开始做数据库化。原来 JSON 跑得很快，我以为换成数据库以后会更专业、更稳定。结果现实很直接：程序反而跑不动了。

这时我才发现，数据库不是换上去就自动变快。查询方式、写入方式、索引、缓存、更新时机，这些都要重新考虑。

尤其是时间线更新。一开始程序不断更新时间线，像是自己停不下来。后来重新定义了时间线的更新原则，哪些时候需要更新，哪些时候不应该动。这个原则确定以后，系统才终于平静下来。

再后来，我又发现各个页面还在互相打补丁。于是又重新规划每个页面的职责和边界，让每个页面各安其位。

到这里，我才真正明白一件事：

AI 编程里，最重要的不是让 AI 多写代码，而是让系统有边界。

没有边界，AI 越能写，系统越容易膨胀。

有了边界，AI 才能变成真正的助手。

第三阶段：先和 AI 聊设计，再让 AI 写代码

做完 ZeroTraceBrowser 以后，我又开始做 ZeroTraceMobile。

这个工具要解决的问题很具体：把 Android 手机上的照片传到本地的 ZeroTraceBrowser 图片管理库里。

它需要做到几件事：

• 能把照片传到 ZeroTraceBrowser。
• 尽量保证照片都能传完。
• 不重复传输已经传过的照片。
• 手机待机时也能继续传。

如果按照我最开始做 ZeroTraceBrowser 的方式，可能就是直接让 AI 开始写代码。

但这次我没有这么做。

我先把前一个项目里留下来的经验带过来：开发前先和 AI 聊设计。

我让 AI 帮我整理需求，拆分模块，设计接口，最后形成设计文档和接口文档。等我看完以后，觉得方向没有问题，再让 AI 开始实现。

ZeroTraceBrowser 侧的开发几乎就是一句话：

按照设计文档，把接口实现出来。

然后它就结束了。

这件事给我的冲击很大。

因为同样是 AI 写代码，前后的体验完全不同。

第一次做 ZeroTraceBrowser 时，我是边写边救火。功能出来得很快，但后面要花很多时间补结构。

做 ZeroTraceMobile 时，我先把结构、接口和边界写清楚，再让 AI 实装。结果编码本身反而变成了很短的一段工作。

当然，中间也有很尴尬的地方。

我没有 Android 开发经验。为了构筑环境、理解 Android 的基本概念、选择开发框架，我花了好几天。很多时候不是代码难，而是我自己还不知道 Android 项目应该怎么组织。

但准备工作做完以后，我把设计文档放到 ZeroTraceMobile 的目录里，让 Codex 理解文档，再开始实装。结果很快就完成了。

当我把 ZeroTraceMobile 发布到 Android 手机上，看着它真的开始把照片传到 ZeroTraceBrowser 侧时，我是有点惊讶的。

这个开发过程短到一种很奇怪的程度：我甚至还没来得及真正学习 ZeroTraceMobile 的代码，它就已经跑起来了。

第四阶段：AI 写得快，不代表人可以不懂

不过，这里也不能得出一个太轻松的结论。

ZeroTraceMobile 很快跑起来，不代表我就真的掌握了 Android 开发。相反，它让我更清楚地看到一个问题：

AI 可以帮我跨过很多实现细节，但不能替我承担理解不足带来的风险。

如果只是做一个能跑的版本，AI 很强。

但如果我要长期维护它，还是得知道：

• Android 后台任务为什么会停。
• 文件权限和照片读取权限怎么处理。
• 网络传输失败后如何恢复。
• 手机待机时系统会怎样限制应用。
• PC 侧接口如何保证幂等。
• 重复传输如何判断。

这些东西不能完全交给 AI。

AI 可以解释，可以生成代码，可以帮我查问题。但最后要不要这样设计，出了问题怎么判断，哪些风险能接受，还是人的责任。

所以我觉得，AI 行人才不是“不需要学习的人”。

恰恰相反，AI 行人才更需要知道自己哪里不懂。

区别只在于：以前不懂一个领域，可能要先学很久才能动手。现在可以边和 AI 协作边建立理解。但这个理解过程不能省略。

省略了，人就会变成只会启动 AI 的人。

第五阶段：工具不是孤立的，工具链才是方向

ZeroTraceBrowser 和 ZeroTraceMobile 做完以后，我开始有一种感觉：

我不是在做两个工具。

我是在慢慢形成一套自己的本地照片管理工具链。

ZeroTraceBrowser 负责本地浏览、导入、去重、时间线、删除恢复。

ZeroTraceMobile 负责把手机照片稳定传到本地。

以后可能还会有更多小工具，比如自动整理、批量处理、同步状态检查、日志查看、网页操作自动化等等。

这些东西如果各做各的，就只是很多小工具。

但如果它们共享同一套数据边界、接口规则和工作流程，就会慢慢变成一个生态。

这时 AI 的角色也变了。

一开始，我让 AI 写功能。

后来，我让 AI 按设计写模块。

再后来，我开始让 AI 帮我整理工具之间的关系：

• 数据从哪里进来。
• 哪个工具负责写入。
• 哪个工具只负责读取。
• 哪些状态可以共享。
• 哪些边界不能打穿。
• 出错以后应该在哪里恢复。

这可能才是我现在最想留下来的经验：

AI 时代真正值得训练的，不是单点功能开发能力，而是工具链构建能力。

一个工具可以很快写出来。

但一套工具链要长期可用，就必须有边界、流程、文档和维护方式。

我理解的 AI 行人才

如果要给“AI 行人才”下一个很朴素的定义，我现在会这样说：

AI 行人才不是最会让 AI 写代码的人，而是能让 AI 在自己的结构里工作的人。

这里面至少有几种能力。

第一，是拆问题的能力。

不能把一个模糊的大问题直接丢给 AI，然后期待它自动变成可靠系统。人要先把问题拆成模块、接口、数据流和可验证的步骤。

第二，是判断边界的能力。

哪些地方可以让 AI 自由发挥，哪些地方必须收住。哪些模块可以互相调用，哪些模块只能通过接口交流。哪些数据可以自动更新，哪些数据必须谨慎写入。

第三，是文档化的能力。

我以前可能没那么重视设计文档。但 ZeroTraceMobile 的经历让我感觉到，文档不是形式。对 AI 协作开发来说，文档就是上下文，就是约束，也是人的判断留下来的痕迹。

第四，是验证能力。

AI 写完以后，不能只看“它说完成了”。要跑起来，要看日志，要走流程，要看数据有没有重复，要看失败以后能不能恢复。

第五，是承认自己不懂的能力。

不懂 Android，就先把 Android 的基本概念补起来。不懂数据库性能，就回头看查询和写入。不懂时间线为什么乱跑，就重新定义更新原则。

AI 可以让人更快动手，但不能让人跳过理解。

给 2026 年工程师的路线图

如果把这段经历压成一条路线图，大概是这样：

第一步，不要急着让 AI 写代码。先把问题说清楚。

第二步，不要只要功能。先让 AI 帮你整理设计、接口、数据流和边界。

第三步，设计没问题以后，再让 AI 实装，而且每次实装范围尽量小。

第四步，跑起来以后，不要马上继续加功能。先看结构是否清楚，状态是否稳定，页面之间有没有互相打补丁。

第五步，开始把单个工具放进更大的工具链里看。它的数据从哪里来，到哪里去，和其它工具是什么关系。

第六步，保留文档。因为文档不仅是给人看的，也是以后让 AI 重新理解系统的入口。

这条路线并不高大上，也没有什么神秘感。

它更像是一个很普通的工程习惯：

先想清楚，再让 AI 做。

做完以后，再确认自己真的能解释。

结语

回头看 ZeroTraceBrowser 和 ZeroTraceMobile，我觉得自己不是突然掌握了什么 AI 秘技。

更像是慢慢明白了一件普通的事：

AI 很强，但它需要被放进结构里。

没有结构，它会把混乱也放大。

有了结构，它会把人的意图变成很快能验证的东西。

所以我现在对 AI 时代工程师的理解，反而变得更朴素了。

工程师还是要负责系统。

只是以前我们主要亲手写代码，现在我们还要学会写清楚意图、边界、接口和验证方式。

代码可以更多交给 AI，但系统不能完全交给 AI。

这大概就是我从 ZeroTraceBrowser 和 ZeroTraceMobile 学到的事。