夜雨聆风我现在每天都在靠 AI 活命，老实说，我不知道这种状态还能持续多久。
这句话不是我说的。是一个在印度工作的 SDET(Software Development Engineer in Test) 在 Reddit 上发的帖子。他五个月前加入了一家美国财富 500 强公司的印度分部。头衔上写的是高级 SDET，干的活是独立贡献者(干的活是只管技术、不带人的独立岗)——这其实正是他想要的。
但问题出在工作内容上。他面对的是大量遗留功能，需要维护、增强、定期测试。几乎没有文档。工作完完全全聚焦在后端系统上，没有用户侧功能可以验证。光搞清楚预期行为是什么这件事，本身就是个挑战。
他试着请教那些了解系统的人。要么太忙，要么懒得花时间解释。只能靠自己。
一、AI 成了外挂大脑
他的工作方式是这样：在 VS Code 里写非常详细的 prompt，告诉 Claude 要测什么、目前发现了什么、遇到了什么问题。Claude 缺乏历史上下文和业务背景，不可能魔法般地解决一切。但它能给出一些有用的调查方向。他跟着这些方向走，收集更多信息，再喂回去，反复循环，直到把测试做完。（有点现在的loop engineering的感觉-只不过是全靠人）
做完之后，把发现分享给开发。有时候开发会调查他发现的问题。有时候开发会指出他遗漏的场景。
大多数情况下，AI 辅助的方式能帮他覆盖大部分需要测试的东西。
听起来似乎还行？可是问题在后头。
他说：我最大的担忧是，我感觉自己并没有真正建立起对系统本身的理解。起初，AI 还像是一个帮我干活的工具。现在，感觉是 AI 在做思考，而我在充当系统和 AI 之间的传话筒。我收集信息，传给 Claude，照它的建议做，然后奔赴下一个任务。
因此，我很少对自己的测试有信心。如果哪天 AI 突然不可用了，我在很多任务上都会感到吃力，因为我仍然没有真正搞懂底层到底在发生什么。
他还说了一个他自己都未必确定的想法：管理层可能希望如此。通过让人们持续不断地把上下文喂进 AI，公司最终可以训练出足够好的系统，减少对人类员工的依赖。
有一件事他倒是在坚持做：把学到的一切都文档化。希望这些文档能帮到未来的同事，也能让自己有空的时候回头再来理解系统-（这是个好习惯，我感觉可以搞一个skill自动总结上下文然后往知识库里写）。
问题是他自己也清楚——这个有空的时候永远不会来。下一个任务、下一个增强、下一个版本。节奏不停，人一直靠 AI 撑过去。
二、你不认识这座城市了
帖子发出去之后，底下最打动我的一条回复来自 SouroDas，只有短短几行，但打得很准。
他说，你所描述的感觉让我想起 GPS 导航。你确实到达了目的地，但过了一段时间你意识到，你已经不认识这座城市了。
他还说，我不认为问题在于使用 AI。问题在于 AI 变成了建立心智模型的替代品。最近他一直在强迫自己回答一个问题：如果不用 AI，我能不能把这个系统讲给一个新同事听？如果答案是不能，那通常意味着需要慢下来，先把基础搞懂。
但他也补了一句：这不单纯是个人的失败。很多团队跑得比文档和知识分享的速度快太多了。你绝对不是一个人在面对这种感觉。
三、评论区里的一群自救者
这个帖子在 Reddit 上拿到了不少高质量的回复。有意思的是，几乎没有人否定他的感受。评论区更像是一群溺水者在互相递救生衣。
有人建议做白盒测试——看 PR 里改了什么，打断点一步步走，搞清楚系统是怎么流转的。不要把思考外包给 Claude，用 Claude 来帮你理解系统，而不是替你理解。
有人把自己的工作方式完整地写了出来：把被测代码的源码 clone 下来，放到和测试脚本同一个目录下，让 Claude 通读仓库，生成架构总结和依赖关系图。写新测试时，让 Claude 参考真实源码找到校验规则和错误信息。还让 Claude 帮他搭建了一套 Python CLI 工具——连接数据库、创建测试数据、清理数据、执行批处理任务、SSH 到 QA 服务器读日志。他的原话是：我已经不再需要写测试脚本了，我现在花更多时间去理解我测的应用，理解为什么做某些测试，怎么降低公司风险。
当然，有人提醒了代码上传的法律风险，他回应说他们公司有 Anthropic 企业合同，经过了法务和安全团队审查，确保零训练、零数据留存。没有这种保障的，千万别随便上传公司代码。
还有人给了一个非常具体的小技巧：预测式提问。在把日志、报错或代码片段喂给 AI 之前，先停 60 秒，写下你自己对问题或预期行为的假设。然后再去看 AI 是否同意你。这 60 秒的停顿，就是把你从传话筒拉回驾驶位的那只手。
另一位 QA 经理给出了一个角色的重新定义：把 Claude 当 QA，你自己是 QA 经理。你的工作是界定问题范围，分发给 QA，审查产出和结果。不是 AI 替代你，是你升级了。
也有人试图安慰他：你这是冒名顶替综合症，你在学习，你在增加价值，给自己三个月时间，如果还是感觉不好再考虑换。后端项目的完全理解本来就需要 6 个月到 1 年，遗留代码库可能更久。
还有人建议用 PlantUML 把系统依赖关系画下来，不靠视觉位置，而是用结构化的方式编码关系。建议去读 《Working Effectively with Legacy Code》。建议把 AI 当成同事——问它怎么做，同时要求它解释为什么这么干。
但所有这些建议背后，有一个东西是共通的：没有人说你应该停止用 AI。大家说的是，你得重新坐到驾驶位上。
四、我也是在靠 AI 续命
这篇文章我之所以想写，不是因为我是旁观者。我是亲历者。
我现在基本什么事都交给 AI 了，特别是写脚本和分析问题。之前还会打开 PyCharm 或者 Sublime Text 看看脚本长什么样，现在基本不看了。有问题反手扔给 AI，让它来解决。心情好的时候会去翻翻它分析问题的原因，忙起来的时候就全部交给它搞。
快是真的快。但真的好吗？
不说别的，就说万一以后面试让你手撕代码，你还能写吗？我想起了姚顺宇面试别人的一个细节：他让候选人在 24 小时内从零搭建一个强化学习项目。他说他并不反对候选人用 AI——他自己也坦诚会用。但前提是，候选人必须真正理解整个流程和系统，否则在跟他聊天的时候他一定能发现。
用 AI 不是问题。不理解自己交出去的东西才是问题。
评论区里有一个建议我觉得对现在的自己最有用：问 AI 之前，自己脑子里先过一遍。或者像抄书一样，把 AI 的回答自己再写一遍。笨办法，但笨办法往往管用。
这篇文章对我自己的警示挺大的。思考和总结不能外包给 AI。外包一次两次看不出来，外包久了，能力边界就在你完全没知觉的时候悄悄缩回去了。
GPS 导到目的地，和你自己认识路，是两回事。
都到这儿了，点个赞再走呗。
也欢迎大家在留言区讨论
我是村夫，下篇见。
