这两天读到一篇关于 Anthropic Claude Code 和 Cowork 团队负责人的访谈整理。文章里最打动我的，不是“代码产出提高了多少倍”这种数字，而是一个更朴素的问题：如果写代码这件事突然没那么稀缺了，那我真正应该变强的地方是什么？
以前我很容易把“能不能写出来”当成问题本身。一个功能排不上期，一个页面没人做，一个脚本太麻烦，于是很多想法就停在“以后再说”。但现在这个借口正在变弱。很多过去要花半天查资料、搭环境、补样板代码的事情，现在可以先让 AI 做出第一版。它不一定对，但它能把事情从“没有开始”推到“可以检查”。
工作重心从实现转向判断
这其实改变了工作的重心。
我以前觉得工程能力最核心的是动手速度。现在我越来越觉得，第一层能力是判断：我到底要解决什么问题？第二层能力是验证：这个东西真的解决了吗？第三层能力才是实现：代码、脚本、页面、自动化流程。实现当然仍然重要，但它已经不再总是最卡人的那一环。
过去：想法 -> 手工实现 -> 结果
现在：定义问题 -> 人 / AI 实现 -> 验证结果 -> 承担责任
举个简单的例子。假如我要给个人网站加一个“随笔”板块，AI 很快就能帮我写 Liquid 模板、补 README、甚至生成一篇文章。但真正需要我判断的是：这个板块应该放在哪里？会不会影响另一台机器上的定时任务？文章分类要不要和 AI 技术日报分开？文件名会不会撞上自动生成脚本？
这些问题不是“多写几行代码”能解决的。它们更像是在问：我有没有理解这个系统怎么运转，有没有尊重已经存在的流程，有没有给未来的自己少挖坑。
AI 最危险的不是做不了，而是像做完了
文章里还有一个词我很喜欢：验证。AI 时代最危险的地方，可能不是它做不了事，而是它太会“看起来像做完了”。一个 PR 能跑出来，一个页面能打开，一段分析能写得很顺，但这不等于它真的可靠。
我自己也有类似感受。让 AI 改一段代码并不难，难的是我不能只看它说“已完成”。我需要看 diff，需要跑测试，需要确认它没有顺手改掉不该改的东西。写文章也是一样。AI 可以把文字润色得很漂亮，但如果里面混进了我没有经历过的故事、我不真正认同的判断，读起来反而会很假。随笔尤其如此，宁可朴素一点，也不要像一篇万能模板。
所以我觉得，以后写随笔也好，做工程也好，我都要多问自己几个很土的问题：
第一，这是不是我真的想表达的东西？
第二，它有没有一个具体例子，而不是一堆漂亮概念？
第三，如果别人按这个东西去理解我、使用我的工具，哪里最可能出问题？
第四，我有没有亲自试过？
这几个问题听起来没有技术含量，但很可能就是 AI 替代不了的部分。因为它们要求我对结果负责。
动作不等于进步
文章里还提到一种新的孤独感：以前几个人一起做系统，前端、后端、移动端、测试都要互相沟通；现在一个人可以同时开很多个 Agent，各干各的，效率变高了，但人和人的互动反而少了。我觉得这个观察挺真实。工具越强，人越容易缩进自己的小工作流里，最后一天做了很多事，却没有和别人真正对齐过。
这也提醒我，不能把“动作”当成“进步”。提交了很多代码，不等于产品更好了；发了很多文章，不等于表达更清楚了；开了很多 Agent，不等于方向更对了。真正的进步，应该能落到一个更具体的结果上：用户少踩了一个坑，读者更容易理解一个问题，未来维护的人更少困惑一点。
让工具逼我把标准说清楚
我现在对 AI 工具的态度，慢慢从“它能不能替我做事”，变成“它能不能逼我把标准说清楚”。如果我说不清楚什么是好，它就只能给我一个看起来还行的东西。如果我能说清楚边界、例子、验收方式，它反而会把我平时嫌麻烦但本来就该做的事补起来。
比如测试驱动开发就是这样。以前很多时候我也知道应该先写测试，但会嫌麻烦，想先把功能做出来再说。现在 AI 可以帮我先写一个失败的测试，再帮我改到通过。麻烦没有完全消失，但门槛低了很多。以前正确但难坚持的方法，现在变得更容易坚持，这可能才是 AI 对工程习惯最大的价值。
读完这篇文章后，我最大的感受是：AI 没有让人变得不重要，它只是把“人重要在哪里”重新暴露出来了。
以前我可以躲在实现细节里，说这个太难、排期不够、工具不支持。以后这些理由会越来越少。剩下的问题会更直接：我有没有判断力？有没有产品感？有没有验证意识？有没有对结果负责？
这听起来压力更大，但也更公平。因为真正值得练的东西，终于从“我能敲多快”变成了“我能不能把事情想明白，并且把它做实”。
参考：