科学
言论
- These LLMs will increase efficiency in delivering software. But in order to make the most of them, we need a simultaneous rise in our level of thoughtfulness. – Don’t Let AI Write For You
- The goal of writing is not to have written. It is to have increased your understanding, and then the understanding of those around you. When you are tasked to write something, your job is to go into the murkiness and come out of it with structure and understanding. – Don’t Let AI Write For You
- The second order goal of writing is to become more capable. It is like working out. Every time you do a rep on the boundary of what you can do, you get stronger. It is uncomfortable and effortful. – Don’t Let AI Write For You
- John Ousterhout’s A Philosophy of Software Design: The greatest limitation in writing software is our ability to understand the systems we are creating. – Your job isn’t programming
- Your job isn’t programming. Your job is managing complexity by designing, refining, and redesigning abstractions. If you’re doing that, then the programming is easy. – Your job isn’t programming
观点
杀死那个写代码的人
- 如果大家过去是程序员，除了「完成任务」后获得的成就感，在整个写代码的过程中也能体会到很多乐趣。拆解整个需求，思考状态的流转，设计模块之间的关系，甚至在脑子里提前模拟整个执行路径。很多时候，它更像是在解一道复杂的数学题，而不是在完成一个产品需求。尤其是在 debug 的时候，那种不断逼近问题核心的过程，会让人产生一种很强的快乐感——你在和一个复杂系统对抗，并且打败了它。写代码不仅仅是「技术能力」，更是一种认知上的满足感：问题是复杂的，但你可以通过自己的思考，把它变得清晰、可控、甚至优雅。所以在很长一段时间里，「写代码」这件事不只是工作，它本身就是一种意义的来源。
- 过去不断去和 AI 合作，探索 AI 的能力边界，但是可怕的地方在于模型进步的太快了，以前可能效果不好，但现在写的质量完全超过了人写。一个个具体的瞬间叠加在一起，让自己逐渐意识到：手写代码，正在退出历史舞台。
- 这个时刻真的让人感觉到了「大人，时代变了」。那一刻会意识到，我们不再是在写程序，而是在「指挥系统」。
- 在传统开发模式中，「代码」就是表达意图的方式本身。但在 AI 协作模式中，这一层发生了根本变化：代码不再是意图，而只是结果。我们需要通过自然语言 、结构化的需求描述、清晰的约束条件定义来向 AI 传达你的意图，AI 再将这些意图转化为代码。因此代码写好的好不好，很大程度在于我们描述的清不清楚，过去的一些边界情况可能是边开发边想到的，但现在我们需要学会用结构化的方式表达需求——功能范围、性能约束、技术限制、用户场景，而且最好是提前一次性想清楚，但可能很难，因此很多时候真正的瓶颈反而变成了人。
- 随着一个需求接着一个需求上线，线上页面包含自己完全没看过逻辑的代码也慢慢被接受，这在过去是完全不敢想象的。代码正在从「需要理解的对象」，变成「只要结果正确即可接受的黑盒」。
- 代码在一个需求中的时间消耗占比逐渐降低，更多的时间花在与产品经理讨论需求的合理性，质疑设计稿中不符合用户心理模型的交互，权衡技术方案对长期维护性的影响，在多个「都行」的方案中做出取舍，处理团队沟通中的信息不对称等。
- 曾经优秀的程序员一个重要能力就是迁移能力，比如要解决一个问题，通过网上搜寻发现很多类似的但和已有场景有一点差别（科研领域亦然），此时只需要理解网上的方案后结合自己的代码完成即可。而现在 AI 太擅长了，只要告诉 AI 哪里有类似的东西，AI 可以非常完美的迁移过来。甚至公司里用的是一个闭源的跨端框架，我们只需要把这些仓库放到一起，通过 Cursor 的 Codebase indexing，AI 便能很好学会新框架的语法、交互怎么用。
- 目前模型的能力已经足够强，即使不用最强的 Claude Opus 4.6，用 Cursor 自己的 Composer 2，也能出色的完成各类任务。因此当下缺少的是在 AI 基础上的工程化和各种研发工作流的建设。基础侧通过 AI 改造所有的链路，代码仓库、打包工具、前端框架、基于意图的 ui 框架、流水线等等，所有流程都应该考虑在 AI 时代应该变成什么样。业务侧利用已有基建，根据业务特性沉淀 skill，常见的错误、代码的规范等等，擅用 cc/cursor/codex 等编程工具，沉淀专属的 Command、SubAgent 等。但所有的一切都和手写代码再也无关，我们提供思路，review 代码，甚至思路也可能是和 AI 脑暴出来的。开发这件事，将越来越和「手写代码」无关。
- 好消息是曾经的「35 岁退休」被消解了。过去，年轻意味着更快的执行速度，而经验意味着更好的架构能力（选择合适的技术栈、设计合理的模块划分、规划可扩展的数据流、制定清晰的组件抽象策略）。但现在，AI 已经可以很好地解决「怎么做」的问题，真正稀缺的反而是「做什么」和「为什么做」。在这个维度上，经验的重要性被放大了，而单纯的熟练度优势则在减弱。过去我们强调的是编码能力、框架熟练度、工程经验，但在新的模式下，更重要的反而是表达能力、抽象能力和判断能力。需要能够清晰地描述问题，引导 AI，评估 AI 给出的结果是否合理，甚至在多个「看起来都可以」的方案中做出选择。当遇到线上故障、复杂边界、性能瓶颈，那种 AI 多次尝试都解决不了的问题，过去积累的经验训练出来的人类工程师的直觉显得尤为重要。
- 一场革命就这样推动着，杀死那个写代码的人，迎接一个已经到来的未来，不是因为他不够努力，而是因为这个时代，已经不再需要他了。AI 飞速进步，当 AI 基建也全部落地，当企业的运转不再需要那么多人之后，我们都需要重新寻找意义，也许就又回到了 存在主义哲学–人生的意义。
信息过载时代，我的漏斗式阅读工作流
- 这两年我越来越强烈地感觉到，信息问题早就不是获取不到，而是处理不过来。真正让我疲惫的，不是没东西看，而是每天都有太多东西值得看：公众号文章、技术博客、GitHub Release、AI 新闻、社区讨论、长文、短讯、碎片化观点等等，全都在争夺我的注意力。如果不做点什么，一个人的信息生活很容易退化成这样：1)收藏夹里躺满了文章，真正读完的却寥寥无几；2）每天浏览大量内容，能留在脑子里的却屈指可数；3）输入看似充实，输出却异常薄弱；4）以为自己一直在吸收信息，实际上只是在不同窗口间疲于切换
- 我只需要一套围绕自己运转的信息吸收漏斗：既能尽可能广泛地捕捉信息，又能提前过滤掉噪音和重复内容，只把真正值得投入时间的内容呈现在我面前。更重要的是，这套系统还要能将我精读后的高价值内容沉淀下来，反过来优化下一轮的信息筛选。信息处理不追求看得更多，而是在于更稳定地吸收、判断和沉淀。
- 几乎每一个你关心的领域，都在持续产生新内容。技术突破、产品迭代、AI进展、工具更新、商业动态、研究成果、行业变化……很多内容看完就过去了，既没有标记，也没有沉淀，更没有真正融入自己的知识体系。如果信息系统永远只知道最新内容是什么，却不知道什么内容真正对你有帮助，那最多只能算是一个信息输送管道，而不是一个能越来越懂你的个性化系统。
- 所以我要的不是做一个更强的信息池，而是做一个更稳的信息漏斗。桶的思路是往里装更多，漏斗的思路是让信息在往下走的过程中不断收窄，最后留下真正值得进入大脑和长期记忆的部分。
- 轻量引导的设计，旨在减少无效信息对注意力的浪费，同时避免构建封闭的信息茧房。个性化推荐应帮助我们减少无意义的判断，而非让我们躲进舒适区。
- 真正让系统不至于退化为另一种自动化信息流的，正是这一关键环节：Human in the loop（人在回路中）。我坚信，在个人知识系统中，最不能完全外包的是长期价值判断能力。系统可以协助我完成许多任务，如信息收集、去重、摘要、聚类、排序和精选等。但它无法完全替我做出关键决策。
- 只有当沉淀的内容开始反过来影响上游的信息选择时，整个系统才真正形成了闭环。为此我加入了一层设计较为克制的兴趣画像逻辑。刻意控制了影响力，不希望整个系统演变成另一个猜你喜欢的推荐引擎。我只需要它能稍微更懂我，但又不过度迎合我的偏好，保留对公共重要性内容的关注和探索未知领域的空间。
- 信息处理的关键，从来不是看到更多，而是让真正重要的信息被自己接住。当信息经过筛选、精读、沉淀和反馈，真正融入知识结构时，我们不再是信息的被动消费者，将真正成为自己信息环境的主人。
NGINX洪志道:
在 nginx 团队，大部分同事仍然手写编程为主。我想提供一个视角，讲为什么到现在仍然有一部分群体还在手写代码，也有少数用 AI，而且用得非常好。nginx 的代码基本都是一行一行写出来，再靠 review 保证质量，review 也是一行行来的。我在加入 nginx 之前其实没见过这种工作方式，后来看多了，我觉得这是一种对卓越的追求。
这里有一个非常关键的分水岭：你到底要不要理解 AI 产生的代码。架构设计是 AI 目前最大的短板。因为这东西不像局部实现那样，往往比较明确、比较容易定义。AI 在执行方面极强，但前提是任务要明确、可验证。改调用点、补样板、做一些局部重构，这些它都很强。我主页里写过不少架构相关的讨论，本质上都在讲同一件事：好代码首先是好设计的结果。问题就在于，很多项目真正难的地方，不是把代码写出来，而是设计先站住。什么抽象该有，什么抽象不该有；什么状态应该通过设计保证，什么不该留到运行时去兜底；这些东西，AI 现在还不稳定。它在“做”上很强，但在“该不该这么做”上，经常差一口气。
细节处理上，很多时候比大方向还重要。因为代码最后是不是好，往往就差在细节上。而 AI 在细节上有一个很明显的倾向，就是它喜欢加防御性编程。当然，你可以明确告诉它不要这样，它也能改。比如一个函数的调用前提，如果在设计里已经说得很清楚了，那一个比较有经验的工程师，通常会把这些前提体现在设计和调用关系里，让代码本身保持线性、直接、可推理。AI 则很容易多写几层判断。这类代码不能简单说错，但在 nginx 这种项目里，它很多时候会把本来应该由设计保证的东西，退化成运行时到处打补丁。而且这类代码对 review 也不友好。因为好的 review，不是 reviewer 帮你机械查错，也不是只看“它能不能跑”。好的 review 是在判断：这段代码是不是符合整个系统的设计，原来的约束有没有被破坏，复杂度是不是被放在了该放的地方。AI 生成的代码经常有一个问题，就是局部都能解释，但全局不够对味。它会加一些名义上安全、但实际价值不高的分支；会做一些通用化、但并不必要的抽象；会把本来一段很直接的控制流拆得比较碎。结果 reviewer 花时间不是在判断核心逻辑，而是在清理噪音、还原作者到底想表达什么。这对高质量 review 来说，其实是有伤害的。
在理解方面。我个人也用 AI，也经历过感觉退化的阶段。所以我现在越来越觉得，这里面最关键的，不是用不用 AI，而是你理不理解代码。代码可以是AI写的，也可以是人写的。 不管是自己写的，还是 AI 写的代码，一定要基于你理解的基础上，再把它变成生产代码。你不理解，就很难真正判断它是不是简洁清晰，是不是把复杂度放对了地方，是不是只是看起来没问题。我自己找到的一个比较好的平衡就是：坚持理解，这是底线。我觉得，如果一个东西只有一种声音，是需要警惕的。也就是说，如果大家都觉得一定要用 AI 编程才是对的，那也是有问题的。 这时就需要一种噪音，有人在走不同的方向。在 nginx，代码最终还是要给人维护，要给人 review，要长期演化。那在这种前提下，更喜欢手写去处理我们认为比较好的设计和细节，我觉得是很自然的事。
有趣
- 大预言模型预测物理现象： LLMs predict my coffee
- Physics of poo: Why it takes you and an elephant the same amount of time: 结合流体力学专业知识，与外科医生及学生合作，在亚特兰大动物园采集34种哺乳动物的粪便样本进行分析，尽管粪便体积差异巨大，但排便时长惊人地相似，平均约12秒。物理机制为 大肠内壁仅如发丝厚的黏液层黏度比粪便低100倍以上，使粪便能以固体栓状高速滑出；粪便长度约达结肠从直肠起的一半。基于粪便黏度数据设计的宇航员成人尿布，利用物理原理将粪便与皮肤隔离，入围2017年NASA太空排便挑战赛半决赛。
荐书
杂谈
Lessons Learned Shipping 500 Units of my First Hardware Product
手机版“神探玺洛克”请扫码
