-heXM.png)
-wtRB.png)
最近把《黑客与画家》重新翻出来看，前两章就让我停了下来。
一方面，这本书写于很多年前；另一方面，它对今天的软件开发、产品构建，尤其是 AI 时代的开发方式，依然有很强的穿透力。它不是在教人怎么写代码，而是在提醒我们：软件开发从来不只是执行需求，它本质上是一种创造活动。
这几年我一直在不同项目之间切换。前端会写 Vue、Next.js，移动端会碰 Flutter，小程序、后端、部署、数据库、支付链路、线上问题也经常一起扛。很多时候，工作的表面看起来像是在“不断交付功能”，但越做越能感觉到，真正决定结果的，从来不是把代码敲出来这件事本身，而是你如何理解问题、如何组织系统、如何判断什么值得做。
这也是为什么我读到“黑客与画家”这个比喻时，会有一种很强的共鸣。
一、学生时代奖励服从，真实世界奖励创造
第一章让我最有感触的一点，是作者在说：学校里的评价体系，往往并不等于成年世界真正奖励的能力。
青春期很容易把“受欢迎”“会来事”“擅长融入群体”误以为是更重要的天赋，但进入真实世界以后，真正持续产生价值的，往往是另一套东西：
独立思考
长时间专注
对问题的敏感度
把一个模糊想法慢慢做成现实的能力
这件事对开发者尤其明显。
很多程序员在学生时代并不一定是最适应集体评价体系的人。甚至恰恰相反，真正热爱创造的人，往往更容易沉浸在自己的兴趣里，对主流规则不那么敏感。但这并不意味着他们弱，只是他们的能力在那个阶段还没有被正确计价。
所以我现在越来越觉得，年轻时不要太相信那些短期排序。一个人的长期上限，很多时候不取决于他当时有多“合群”，而取决于他是否保留了对世界的好奇、对作品的要求，以及长期打磨自己的耐心。
二、工程师不是流水线工人，更像是在约束中创作的人
书里最核心的判断之一，是黑客和画家其实有相似的工作方式。
他们都不是严格按照一张预先画好的施工图去执行。真正的创作，往往是在动手过程中逐渐成形的。画家不可能在落笔之前就百分之百知道整幅画最后长什么样，程序员也很难在写第一行代码之前，就把整个系统的所有细节一次性想清楚。
这和很多公司里流行的线性想象不一样。很多人会以为，产品先写完整规格，设计再补齐细节，开发最后照着实现，整个过程就会变得可控。但实际做项目的人都知道，这通常只是一种管理上的理想状态。
真实情况往往是：
需求一开始就是模糊的
用户自己也说不清真正要什么
架构问题常常是在开发过程中才暴露出来
交互是否合理，很多时候要上线后才能看见反馈
也就是说，软件不是先被完整设计出来，再被机械实现出来；软件是在设计、实现、试错、反馈里一步一步长出来的。
这一点，我这几年感受非常深。尤其是在做业务项目时，很多需求文档看上去写得很满，但一旦真进到代码层、数据层、用户路径里，问题就会立刻变得具体起来。到底字段怎么建、边界怎么划、异常怎么兜、用户到底会不会这样操作，这些都不是纸面上能一次性决定的。
所以如果把工程师理解成“接单然后写代码的人”，其实是低估了这份工作的本质。工程师真正重要的部分，不只是实现，而是创作过程中的判断。
三、为什么我越来越认同“先做原型，再收反馈”
《黑客与画家》里有一种很强的产品观，我非常认同：先把东西做出来，尽快让真实用户接触，再根据反馈调整。
这不是鼓励粗糙上线，更不是鼓励不负责任，而是在承认一个现实：
很多正确答案，只有在真实使用发生以后才会出现。
这几年无论是做后台系统、移动端应用，还是一些偏独立产品方向的尝试，我越来越不相信“闭门把方案想到完美再上线”这件事。因为软件一旦离开真实场景，很多讨论都只是想象。
用户不会按照 PRD 里的理想路径使用产品。 他们会跳步骤、会误触、会看不懂、会忽略你以为很明显的按钮，也会在你完全没想到的地方卡住。
所以“Make something people want”这句话到今天还是有效。不是做一个自己觉得高级的东西，而是做一个用户真的愿意用、真的能解决问题、真的愿意留下来的东西。
对于我这种长期在多项目切换、偏实战型的开发者来说，这个提醒尤其重要。因为技术人最容易掉进去的一个坑，就是把“我能不能做出来”误当成“这个东西值不值得做”。
前者是能力问题，后者是方向问题。方向错了，执行越快，偏得越远。
四、大公司优化的是稳定，小团队争夺的是新机会
书里还有一个判断我很喜欢：大公司往往不是靠“做出最好的产品”获胜，而是靠体系、分发、渠道和既有优势获胜。
这句话放到今天依然成立。
大公司天然会压缩波动，因为它们承受不起高方差。流程要稳定，风险要可控，结果要可预期。这样做没有问题，但副作用是，很多真正有创造力、但一开始看起来不那么标准的东西，很难在这种环境里长出来。
而小团队、独立开发者，甚至个人开发者的机会，恰恰经常出现在这些“还没有被标准化”的新领域。
为什么 AI 时代会让很多开发者重新兴奋起来？原因之一就在这里。
新工具、新工作流、新产品形态还没有完全固化，巨头虽然强，但很多细分需求、局部场景、垂直问题仍然有人可以切进去。尤其对于能同时理解产品、技术和用户的人来说，这种窗口期是非常珍贵的。
我自己这两年也越来越明显地感受到：真正值得做的，往往不是去和巨头在成熟市场里比“谁更完整”，而是在一个新问题刚刚出现的时候，比别人更快理解它、验证它、做出第一个足够有用的版本。
五、最好的学习方式，依然是做东西和看源代码
书里说，画家靠动手画来学习，黑客也应该靠动手写来学习。我很认同。
我自己的很多能力，并不是从系统课程里长出来的，而是在一个个具体项目里被逼出来的。一个线上 bug、一条支付链路、一次部署故障、一个奇怪的状态同步问题，往往比一大段抽象理论更能让人真正理解系统是怎么运作的。
另一个很重要的学习方式，是看优秀的源代码。
不是只看功能结果，而是看别人怎么拆模块、怎么组织状态、怎么处理边界、怎么命名、怎么取舍。很多“工程感”不是背概念学会的，而是在反复观察优秀实现之后慢慢建立起来的。
这一点放到 AI 时代反而更重要了。
因为现在代码生成越来越便宜，复制一个能跑的结果越来越容易，但“为什么要这样组织”“这段代码能不能长期维护”“这里的抽象是不是过度了”，这些问题并不会自动消失。甚至因为 AI 加快了产出速度，理解代码、判断代码的能力变得更稀缺了。
六、AI 让写代码更快，但没有让“做作品”变简单
我读这本书时一直在想，如果 Paul Graham 看到今天的 AI Coding，会怎么理解“黑客像画家”这件事。
我的判断是：这个比喻不但没有过时，反而更成立了。
因为 AI 正在把“执行”这部分工作快速压缩。很多过去需要手敲、查文档、来回试错的事情，现在几分钟就能完成。但这并不代表软件开发突然变成了一件更机械的工作，恰恰相反，它把工程师往更上层推了。
以后更重要的问题会变成：
你到底要解决什么问题？
这个问题的优先级是否足够高？
系统边界应该怎么划？
哪部分可以交给 AI，哪部分必须自己盯住？
什么样的结果才算真的完成？
也就是说，AI 也许会让“写代码的人”变多，但不会自动让“能做出好作品的人”变多。
真正的差距，会逐渐转移到审美、判断、产品感、系统感，以及对用户真实需求的理解上。
从这个角度说，工程师以后更像导演，也更像编辑。代码不再只是亲手一行行写出来的产物，而更像一个持续被塑形、被选择、被修正的作品。
七、真正伟大的产品，最终还是回到对人的理解
书里反复提到一个点：伟大的黑客必须理解用户，必须有同理心。
这句话看起来像常识，但真正做产品时最容易被忽略。
因为技术人天然喜欢从“系统如何设计更优雅”出发思考问题，但用户不关心你的架构漂不漂亮。用户只关心三件事：
这东西我能不能马上用
它能不能稳定帮我解决问题
它值不值得我继续留下来
如果一款软件需要用户不断阅读说明书、适应开发者的思路、迁就复杂流程，那它通常已经输了。
程序写出来当然能在机器上运行，但更重要的是它先要能被人理解、被人使用、被人信任。
这几年做项目，我越来越觉得，很多产品做不起来，不是技术做不到，而是做的人没有真正站在用户那边。大家忙着堆功能、忙着赶交付、忙着解释自己为什么这么设计，却没有认真回答一个更基本的问题：
用户为什么要在今天打开你这个产品，而不是关闭它？
结语：重读这本书，不是在怀旧，而是在重新校准自己
《黑客与画家》最打动我的，不是它讲了多少“编程技巧”，而是它重新把开发者从“技术执行者”拉回到了“创造者”的位置上。
这对我来说是一种提醒。
在日常工作里，我们太容易被需求、进度、脚手架、兼容性、线上问题和各种碎任务切碎，久而久之，会误以为开发就是不断接单、不断修补、不断把功能拼上去。
但如果只剩下这些，工程师的工作就会越来越像流水线。真正能让这份工作重新有生命力的，仍然是创造，是判断，是审美，是对作品的要求，是对用户问题的敏感。
AI 会继续降低执行门槛，但也正因为如此，开发者更需要重新回答一个问题：
当代码越来越容易生成时，我们究竟还要凭什么做出真正属于自己的作品？
这大概也是我接下来想继续写这本书读后感的原因。
后面如果继续写，我会很想展开聊几件事：
为什么“好品味”在软件里比想象中更重要
为什么创造者要尽量靠近用户，而不是只靠近流程
为什么 AI 时代更需要长期主义，而不是只追求短期效率
这不是一本只属于旧互联网时代的书。
如果今天你也在一边写代码，一边思考产品、AI、工作方式和未来怎么变化，那它依然值得反复读。
评论