程序员被AI代替这种言论，这几年随着AI Agent能力越来越强，这种趋势变得越来明显。从今年开始，身边的所有同事都在使用AI编程了，甚至没有谁敢说：“AI无法替代自己”。大家使用的越多，就越觉得AI能力越强，很多事情都不再需要自己亲自动手来做，AI都可以替自己做了。
那么作为程序员的我们，难道就只能被动的等着被淘汰吗？
我们先来盘点一下，程序员的工作流程：
- 对接需求。理解清楚业务或者产品的需求，包括这个需求为什么要干，以及具体要干点什么。
- 设计方案。理解当前的技术架构，然后基于需求，在当前的技术架构上，权衡落地成本，设计可行性的方案。
- 编写代码。基于设计方案，进行代码编写，完成整体的功能。
- 自我验证。编写单元测试，验证编写代码的质量。
- 辅助测试。转测给测试人员进行验证，并且辅助测试完成整体的集成验证，以及各种异常场景的补充。
- 生产发布。测试验证完成，确保功能的正确性以及可靠性，准备发布方案，完成生产的发布。
在整体的这个生产过程中，哪些环节是AI最容易替代的？
- 很明显应该是3和4。只要我们把设计方案做成AI可以理解的标准化，编写代码和自我验证，是业界可以通用的一套标准化流程，AI最擅长，也可以做得很好。
- 1和2对于AI来说，它缺少前期的训练数据，还不了解我们各个业务系统，还依赖于我们去定义目标和制定标准，还需要我们去投入时间，协助它来做好。
- 5和6对于AI来说，更多的是权限开放的问题。辅助测试，主要是确保测试发现的问题是真bug，而不是环境或者其他外界因素引发的非问题，确认清楚后，更新设计方案并且让AI重新优化代码即可。至于生产发布，目前对于公司来说估计还不敢直接让AI生成的代码，直接发布上线生产，肯定还是需要人来验证和负责，最终由人来完成发布，毕竟AI不担责，人才能承担责任。
AI越来越强后，它替代的不是程序员，而是只会写代码的程序员 。当编码从核心技能变为基础工具时，真正的竞争力在于：
- 定义问题的能力。AI能够高效协助我们解决各种各样的问题，但是什么是问题，什么不是问题，AI无法直接给出答案。对于编写好的程序代码来说，AI能够知道程序运行有没有报错，但是它可能无法直接理解，程序的可靠性、可扩展性、可维护性，这些审美的能力要贴合具体的业务和架构，才能给出合适的答案。
- 系统设计的宏观思维。从整体业务系统或者架构层面去理解系统设计，不要只是解决单个工程或者模块的问题，这样AI即使要理解你的思维，也需要足够多的上下文，才能够理解清楚。现在claude code, opencode 都是基于单个工程来完成编码，宏观的系统设计可能会涉及到十几个工程或者系统的交互，这对AI agent智能体本身的上下文挑战就很大。
- 跨领域的知识整合。开发向前对接的是产品，向后对接的是数据分析，跨领域就是不能只局限在开发的视角，要进一步放大自己的领域知识。对自己的工作，能够做到端到端的交互，不要再依赖产品帮你对接业务，不要再依赖数据分析帮你呈现价值。我们要能够直接交付业务价值，具备直接成事的能力，这样会进一步扩宽自己的生存空间。
- 人机协作的 orchestration 能力。这个能力，也可以叫做沟通能力。之前作为一个管理者，最重要的就是沟通能力，把控好各个事情，然后交代给各员工去完成，能够把交代的任务沟通清楚，同时要兼顾各员工的能力和情绪。现在AI来了，不需要这么复杂了，只要你能够按照AI的沟通规范，把任务布置好，AI就能够任劳任怨的替你完成。沟通和协作效率，就会得到质的提升，这也是AI来临后，公司内部可以完成人员大量精简的原因。
- 深度思考的能力。AI来临后，我自己这段时间写作的时间也减少了。我更多的时间在阅读，即使想要写作时，也总是先依赖AI帮我写作一版，然后自己再修修改改。这样对自己深度思考的能力其实减弱了，包括结构化表达的能力也降低了，AI可以替代我们完成很多事情，但是无法把知识和能力直接贯入我们的大脑。AI写作的结构和套路，玩得再好，也没有办法直接变成我们自己真正完成理解的东西。人类的学习还是得依赖费曼学习法，你无法一步达成，还是得慢慢来，先阅读，再理解，并完成输出，最终才能沉淀为自己的经验和法则。
