最近看到一项关于著名画家伦勃朗的研究：他那些栩栩如生的自画像，可能借助了镜面组成的光学投影装置，把影像投射到绘画表面，辅助处理比例与明暗
如果一位画家借助投影辅助绘画，他的作品就不再体现手艺，作品价值就被贬低了吗？
我们很容易把手艺理解成某种未经辅助的劳动：画家必须徒手画准比例，程序员必须亲手敲出代码。仿佛工具替代的步骤越多，人的价值就越少
但投影即使能够提供准确的轮廓，也不会因此决定一幅画值得表达什么。取舍、色彩、笔触，以及画面最终传达的感受，并不等同于轮廓的准确性
这让我们可以重新审视程序员与 AI 的关系：手艺究竟存在于每一个必须亲手完成的步骤里，还是存在于对作品的理解、判断和责任之中？
如果手艺不只是亲手完成每一道工序，那么哪些能力是能够作为程序员手艺，值得自己长期拥有的？
我认为有这样三种能力：判断力，决定什么值得做；理解力，弄清结果为什么可信；学习力，让自己持续有能力解决新的问题
01 什么值得做
AI 已经能够参与软件开发中的许多步骤：写方案、写代码、解释源码、补测试、帮助排查问题。但它能做什么，并不能直接回答我应该让它做什么
对于工具的选择，我们可以采取这样的思路：先明确对自己最重要的目标，以及支撑这些目标的关键活动，再判断工具是否对它们产生实质性的正面影响，而且利大于弊
对程序员而言，这首先意味着区分问题与方案。例如，对于一个降低高峰期任务排队时间的需求，你选择的是做一个自动扩容的方案；如果根因在调度策略，扩容可能只是把低效变成更高的账单
实现变得便宜，并不会让需求自动变得合理。相反，当 AI 能迅速把一个想法变成代码时，我们更需要判断：问题是否真实，目标是否明确，是否存在不用新增代码的解决方式
这种判断也适用于工具本身，每件工具都可能有用，但局部的好处不等于整体的收益。一个工具可能节省编码时间，却增加审查成本；可能迅速给出答案，却让人过早停止调查；也可能让我们同时推进更多任务，却失去整块思考的时间
因此，工程判断不是寻找一个看起来最先进的方案，而是在约束下做取舍：性能提升值不值得额外复杂度，通用设计值不值得长期维护，现在可以接受哪些技术债，又有哪些风险不能留到上线以后
能够说明选择依据、适用条件、代价和退出方式，比单纯列出某个方案的优点更重要。这个标准也帮助我们避免为了采用新工具，反过来寻找值得使用它的任务
AI 生成结束，不等于已经走完通向可靠交付的路，判断 AI 是否改善了工作，还需要把账算完整。如果代码生成只花十分钟，审查和返工却花了两天，那么十分钟完成开发只是把后面的工作从统计中删掉了
更合理的评价单位，是从问题提出、实现、验证到后续维护的完整过程：它是否缩短了总耗时，是否减少了缺陷，是否让系统更容易理解和修改？只有把收益与代价放在一起，才知道自动化是否真的带来了进步
02 为什么可信
选择了值得解决的问题，还需要回答另一个问题：AI 给出的方案，为什么可以接受？
一段解释听起来合理，一份代码能够运行，都不等于我们已经理解了它。程序员需要建立自己的系统模型：数据如何流动，状态由谁持有，哪些约束必须始终成立，失败之后如何恢复，修改会沿哪些路径影响其他部分
这不是要求背下每一行源码，而是形成能够预测行为的理解。例如，看到任务延迟上涨，能够区分时间花在计算、排队、I/O 阻塞，还是重试放大上；接受一个优化方案之前，能够说明它改变了哪一段路径，以及可能把成本转移到哪里
AI 可以加速源码定位和调用链梳理，但我们仍要对照当前版本的实现，检查关键解释是否成立。没有对状态、并发、存储、网络和失败模式的基本认识，就很难发现一个流畅答案中隐藏的错误
AI 编程圈中常见 loop/graph engineering 的讨论：通过循环或图结构组织多个 AI 编码智能体，分配实现、检查和修改等工作。这类编排本身并不意味着无人监督，但容易让人进一步期待，把整个工程过程都交给自动循环
我并不反对自动化实现本身，但把 AI 当作"许愿池"，相信"让智能体相互检查、不断循环，人就可以离开，最后自然得到高质量软件"的想法值得商榷
在 loop 中多轮 AI 审查不能自动证明结果正确；因为不同智能体可能共享盲点，也可能共同接受错误前提。一个实现和一组测试如果来自同一个错误假设，测试通过也可能只说明两者保持了一致。所以，工程质量仍需要独立的尺度来检验
AI 编程中人的参与不应退化为点击同意；当然，审查深度可以与风险匹配，但关键设计为什么成立、接受了哪些局限、失败时如何定位和回滚，负责交付的责任方都需要有自己的认识
03 如何持续进步
判断力和理解力都不是凭空产生的。它们来自过去积累的知识、反复修改过的代码，以及那些猜错之后重新寻找原因的经历
因此，使用 AI 不仅有眼前的交付收益，也有长期的学习影响。一个任务更快完成，并不意味着完成它的人也获得了相应的能力
对于已经掌握的重复劳动，例如格式转换、接口骨架、常规测试样板，让 AI 代劳通常很合理。机械重复并不会因为是亲手完成，就自动产生学习价值
但对于自己正在建立的核心能力，就不应该完全跳过思考过程。例如，一个正在学习并发控制的人，如果始终直接接收完整实现，就可能绕过识别竞态、构造反例和理解同步边界的过程；下一次条件发生变化时，他仍然无法判断
因此，让 AI 代劳需要区分场景：
- 交付模式：可以让 AI 起草，自己重点验证
- 学习模式：可以先独立推导，再让 AI 提供反例、质疑假设或解释遗漏
工具可以托举成果，自己的根仍需要持续浇灌；当然不要没苦硬吃，值得保留的不是所有困难，而是那些能够形成关键能力的困难
学习是否发生，可以用一个简单的问题检验：离开当前答案，面对一个条件略有变化的问题，我还能做出判断吗？如果只能复述解释，却不能预测变化带来的影响，知识就还没有真正变成自己的能力
真正的学习需要经历识别知识缺口、寻找可靠资料、动手实验、接受反馈、修正理解，再把所得用于新的问题。AI 可以参与每一步，但不能用一次顺畅的问答替代整个过程
这也是技术基本功仍然值得练习的原因。判断力与理解力不是脱离技术知识的软能力：没有一定的编码经验，以及数据结构、操作系统、网络和数据库基础，就很难建立准确模型，也很难识别 AI 的错误
04 结语
AI 不像一台只给画家提供轮廓的投影机，它会解释问题、推荐方案，甚至生成一套听起来完整的理由。它影响的不只是我们的动作，还可能影响我们的判断
所以，在 AI 时代，程序员的手艺中应该包含选择方向、理解结果和持续进步的能力：
- 判断力：不因为 AI 能做就决定去做，也不因为生成得快就认定值得；用目标、约束和实际结果判断取舍
- 理解力：可以委托实现，但不能跳过对关键机制的理解；用自己的系统模型提出解释，用独立证据决定是否接受
- 学习力：把重复劳动交给工具，把形成能力的练习留给自己；不仅完成眼前任务，也增强解决下一个问题的能力
投影可以帮助画家确定轮廓，却不会替画家决定画什么。AI 可以帮助程序员完成更多实现，但什么值得建设、什么结果可信、自己要持续掌握什么，仍然需要认真对待
AI 时代的手艺，不在于每一步都亲手完成，而在于用判断力选择作品，用理解力把握作品，用学习力获得创造下一件作品的能力