AI 编程助手改变了我的工作方式——18个月后的真实复盘
AI 编程助手改变了我的工作方式——18个月后的真实复盘
适读人群：在用或者想用AI编程工具的工程师 | 阅读时长：约15分钟 | 核心价值：一个真实用户18个月后的诚实反思，不是广告，也不是反AI
2023年秋天，我开始认真用AI编程助手。
不是偶尔试试，是作为工作流程的一部分每天用。那段时间我一边在做AI应用开发，一边在用AI工具开发AI应用，有一种奇怪的递归感。
18个月过去了，我想认真回答这个问题：它改变了什么，没改变什么，带来了什么新问题。
不是为了推荐什么工具，只是觉得诚实的使用复盘比那些"效率提升300%"的标题更有价值。
真实改变了的东西
1. 写样板代码的时间几乎归零
这一条是实实在在的。
以前写一个新的Repository类、配置一个Spring Bean、写一个Controller，这些我叫做"肌肉记忆代码"——我脑子里清楚要写什么，手就是要打那些字，没有任何思维含量，纯粹的时间消耗。
现在这些基本上是描述一下，确认一下，改几个细节，done。
我估算过，我日常工作里大约有30%的时间是在写这类没有思维含量的代码。这30%，AI工具帮我压缩到了大概5%。
不要小看这个数字。那25%的时间不只是省下来了，更重要的是它不再消耗我的注意力。以前写了两小时样板代码之后，我需要一段时间才能进入真正需要思考的状态。现在这个切换成本低了很多。
2. 跨语言能力的边界扩展了
我的主力语言是Java，但工作里不可避免地会碰到Python（脚本、模型相关）、Shell（自动化）、偶尔的JavaScript（前端集成）。
以前每次切换语言，我都要在"能用"和"用得好"之间来回打架，Google的频率很高。
现在AI工具扮演了一个"语言转接头"的角色——我用Java的思维描述我想做什么，工具给我Python实现，我审查逻辑、确认正确、可能调整几处，然后跑起来。
这不是我的Python能力提高了，而是我可以在更大的范围内工作，不再被语言本身卡住。
3. 调试的起点变了
以前调试流程通常是：看报错→想可能原因→Google或者翻文档→假设→验证。
现在通常是：看报错→扔给AI工具描述上下文→看它给出的分析和假设→我判断哪个方向有价值→验证。
这不是AI替代了我的判断，而是AI帮我快速生成了"待验证假设列表"，让我跳过了"从零开始想可能是什么问题"的阶段。
在某些场景下（特别是陌生库的报错），这个加速效果非常明显。
4. 文档质量提高了，但方式出乎意料
我以前对写注释和文档是有抵抗心理的，不是不知道重要，是觉得麻烦，总是推迟。
现在这件事变容易了，但不是因为AI帮我写文档——而是因为我在描述给AI的时候，本质上是在迫使自己把问题说清楚。"给AI解释这段代码在做什么"这个动作，让我更清晰地思考了代码设计，然后文档写起来自然也更容易。
这个副作用我没有预料到，但它是真实的。
没有改变的东西
1. 架构设计依然是人的工作
这一条我很确定。
不是说AI不能生成架构方案，它可以，而且有时候给的建议角度不错，可以作为参考。
但架构决策本质上是在约束条件下做trade-off：你的团队规模是多少、系统未来的增长方向在哪、维护成本和开发速度怎么平衡、哪些需求三个月后会变、哪些会稳定。
这些约束不只是技术问题，是对具体业务和具体团队的理解。AI工具没有这些上下文，就算你描述给它，它也无法真正"感受"这些约束对设计的影响。
我的架构讨论从来不是"让AI设计然后我改"，而是"我在脑子里想清楚之后，可能用AI工具做一些技术选项的对比分析"。
2. 代码审查能力没有被替代，反而更重要
这一点有点反直觉。
理论上AI生成了代码，我只要审查就好，审查比从头写应该更轻松。
实际上我发现，审查AI生成的代码需要更高的注意力，原因是：AI生成的代码在形式上通常是"看起来对的"——命名规范、格式正确、逻辑通顺。问题往往藏在微妙的地方：边界条件处理不够、性能假设不成立、安全性考虑遗漏。
这些问题靠"读起来流畅"的感觉是发现不了的，需要真正的code review能力。
某种程度上，AI工具让"代码看起来好"变容易了，但也让"代码真的好"的要求更高了，因为你不能再靠"这段代码是我自己一行一行写的，我应该没有手滑"来作为隐含质量保证。
3. 对业务逻辑的判断能力
AI不懂你的业务。
这句话说起来简单，但含义很深。
有一次我描述了一个功能需求，AI给出了一个技术上完全正确的实现，但逻辑里有一个我们业务规则的隐性约束它不知道——这个约束不在文档里，是历史遗留下来的一个特殊case，只有做过这个系统的人才知道。
如果我审查不仔细，这个问题会上线，然后在某个特定场景下出故障。
这类问题的频率比你想象的高。每次发现这类问题，都是在提醒我：AI工具的能力边界在"给定上下文内的技术实现"，而不是"理解你的系统和业务的全部"。
带来的新问题
这一部分我觉得最值得认真写。因为大部分对AI编程工具的讨论都停在"好处是什么"，很少有人认真谈代价。
1. 某些基础技能确实在退化
这是真的，我不想回避。
我发现自己写纯算法的手速下降了。以前写一个二分查找或者某个常见数据结构操作，手上有肌肉记忆，现在有时候要想一下。
更明显的是某些API的记忆度降低了。以前我对Stream API、Collections工具类、日期时间API的细节记得比较清楚，因为每天都在用、都在手打。现在很多我是描述意图让AI生成，确认一下，用了，但没有把细节内化。
这是不是问题？我的判断是：在实际工作中，这不是严重问题，因为AI工具就在那里，需要的时候查一下就好。但在技术面试场景、在白板编程场景、在没有网络的紧急排障场景，它会暴露出来。
我对这个的处理是：周期性地做一些不使用AI工具的编程练习，保持基础手感。就像开了自动驾驶很久，还是要定期手动开一会儿，保持感觉。
2. 对"自己真的理解了吗"更难判断
这是我觉得最隐蔽的问题。
以前写代码，理解程度和代码质量有相关性——如果你没真正理解，代码通常写不对，会出错，调试过程会让你意识到理解有缺口。
现在可以生成"看起来对的"代码，然后跑通了测试，但你对这段代码的理解深度可能并不够。这个缺口在当下不会暴露，但在后续需要修改这段代码、或者排查与这段代码相关的bug时，会突然冒出来。
我现在的应对方式是：对于核心业务逻辑，AI生成之后我会强迫自己用自然语言在注释里解释这段代码的每一个关键判断——如果我解释不清楚，说明我理解不够，需要深入看。
3. Prompt能力成了新的技术债务点
这个问题不大，但值得一提。
当你写了一大批依赖AI工具生成的代码，你的"工作流程"里有了一层新的"如何描述需求给AI"的能力。这部分能力不容易文档化，不容易转移给其他人，而且随着AI工具版本更新，以前好用的描述方式可能变得不好用。
这是一种新形态的"只有我知道这块怎么用"的知识孤岛，值得注意。
4. 注意力分散的倾向
有AI工具在，碰到一个问题，反应很快变成了"问AI"，而不是"想一想"。
大部分时候这是对的，效率确实更高。但有一类问题，在"想一想"的过程中能产生有价值的理解和认知，而"直接问AI得到答案"会跳过这个过程。
我说的不是鸡汤意义上的"独立思考"，而是很具体的工程认知积累：某些bug的调试过程本身是在帮你理解系统行为，某些算法问题的思考过程本身是在建立你的抽象能力。这些不应该全部被AI工具短路掉。
我现在的工作方式
整合了18个月的经验，我的工作方式是这样的：
用AI工具的场景：
- 样板代码、重复性代码，全部交给AI
- 跨语言实现，AI生成我审查
- 单元测试的骨架生成（测试逻辑和覆盖范围我决定）
- 报错分析，AI提供假设列表，我判断和验证
- 文档和注释的初稿生成
不用AI工具或者谨慎用的场景：
- 架构决策和系统设计
- 核心业务逻辑的实现（AI可以参与，但我要一行行理解）
- 安全相关的代码
- 性能敏感的路径（AI生成的代码不总是考虑了性能）
定期做的"无AI练习"：
- 每周至少有半天时间不开AI工具，自己写、自己查
- 目的不是证明自己不需要AI，而是保持基础手感
这不是一套普适的规则，是对我的工作特点最合适的方式。你的情况可能不同。
18个月后，我的结论是：AI编程工具是真实有价值的，不是炒作。但它改变的不是"工程师能做什么"，而是"工程师把时间和精力花在哪里"。
变化里有机会，也有需要认真对待的代价。两者都值得清醒地看待。