标签: #engineering
关于 GPU、LLM、MLOps、Kubernetes 以及心态的文章 · 16 篇
用文字说服 — 让设计文档和RFC获批的结构
写给那些要写设计文档、RFC、提案书、事故复盘建议的人。本文讲的是把想要的决定放在最前面,而不是按自己解决问题的顺序来写;讲清楚为什么"展示被否决的替代方案"是区分提案与广告的唯一标志;讲如何把"什么都不做"的成本变成数字;也讲如何应对那些只是快速浏览的决策者。最重要的是,讲如何写出那种会在你不在场的会议上被引用的段落。文章把一段薄弱的提案实际改写了一遍,并把文档中真正管用的招数整理成了一张表。
2026-08-02 · 22 分钟阅读 #career#writing#persuasion#design-doc#engineering重构的经济学：什么时候能回本 — 用变更频率计算
2026年7月30日发布在martinfowler.com上的The Economic Benefit of Refactoring一文，对一个约1.7万行的模块进行了15步重构，每一步都重新执行同一个变更请求，测得输入token从159,564个降到27,360个，减少了83%。这是个有意思的实验，但作者本人明确指出这只是单次实验，而且只针对一个绿地(greenfield)应用。本文把这个实验和既有证据(Tornhill与Borg针对
2026-07-31 · 22 分钟阅读 #refactoring#engineering#technical-debt#ai#metrics用 AI 搬迁代码库的实战流程 — 先把裁判立起来，测评审率而不是行数
本文从 2026 年上半年公开的大规模 LLM 迁移案例（53 万 5 千行 Zig 转 Rust、16 万 5 千行 Python 转 TypeScript）中抽出共同的流程，整理成一份可执行的顺序。关键在于顺序 — 在开始翻译之前先立起行为预言机，并且先确认这台预言机在被故意改坏的代码上真的会亮红灯。然后沿可验证的边界切分成队列，把完成判定交给磁盘状态，让每一步都保持可回退。要测的指标不是转换了多少行，而是人真正读过的差分比例，以及
2026-07-31 · 19 分钟阅读 #ai#migration#refactoring#testing#engineering系统设计面试准备法 — 被打分的不是答案,而是一步步收敛的45分钟
系统设计面试没有标准答案。所以被打分的不是你画了什么,而是你怎么一步步收敛的。把45分钟切成5分钟、10分钟、15分钟、10分钟、5分钟的时间预算,从内存访问到跨大陆往返、值得按数量级背下来的延迟阶梯,从一个DAU推出QPS和存储的粗略估算,以及最容易让候选人翻车的四个习惯。最后还讲了怎么把"我不知道"说成加分项而不是减分项。
2026-07-26 · 15 分钟阅读 #career#interview#system-design#engineering#job-search教人的代码评审，伤人的代码评审 — 同一条意见为什么结果不同
代码评审有三个目的：发现缺陷、传播知识、共享代码所有权，但多数团队只做了第一个，把后两个丢掉了。本文梳理了谷歌的批准标准 — 评审者不是要求完美的人，而是判断代码是否明确变好的人 — 以及强度前缀带来的差别、按观察和影响和建议拆开的句式、200到400行这个PR体积通说的出处及其局限、能减少往返的PR说明，还有被评审一方的技巧。也会谈到评审从技术活变成权力游戏时的信号。
2026-07-26 · 16 分钟阅读 #career#code-review#engineering#feedback#teamwork构建高效的 AI 智能体 — 五种工作流模式与智能体参考指南
把 Anthropic 的工程指南《Building Effective Agents》整理成了一份实战参考。文中厘清工作流与智能体的准确区分，介绍作为一切基础的增强型 LLM（检索·工具·记忆），并逐一讲解五种工作流模式（提示链·路由·并行化·编排者-工作者·评估者-优化者）各自的适用场景与示例。同时坦诚地写下自主智能体究竟是什么、何时该用智能体取代工作流，以及过度设计·失控循环·成本/延迟等失败模式。目标是为开发者和 AI 智能体提
2026-07-11 · 14 分钟阅读 #ai#agents#llm#engineering#anthropic像科学家一样调试：假设驱动的调试
与其盯着 bug 把代码改来改去,不如像科学家那样先立假设、做预测,再用实验去验证。把问题空间用二分搜索一点点缩小,搭出最小可复现示例,用 git bisect 揪出元凶提交,并且真正把错误信息读完。一份把「瞎猜」变成方法论的实战调试指南。
2026-07-03 · 22 分钟阅读 #debugging#engineering#productivity#fundamentals前线部署工程师(FDE)是什么
梳理 Palantir 让其大众化、如今又在 OpenAI、Anthropic 等 AI 公司的解决方案团队里重新火起来的前线部署工程师(FDE)这一角色。所谓 FDE，是被派驻到客户那里、把软件工程、产品、解决方案、外加一点销售与咨询混在一起、把客户真正的问题解决到底的人。本文梳理它与 SWE、SE、PM、咨询顾问的区别，以及为什么 AI 让 FDE 这个角色重新变得不可或缺。
2026-07-02 · 12 分钟阅读 #career#engineering#fde如何阅读别人写的代码
开发者花在读代码上的时间远多于写代码,但读代码这件事却从来没人教。找到入口点,不逐行阅读而是追踪数据,把测试和类型当作文档,用 grep 和 IDE 跳转画出调用图,实际跑起来打印调试,再改点东西看看什么会坏掉。这是一份快速掌控陌生代码库的实战策略。
2026-07-01 · 18 分钟阅读 #code-reading#engineering#onboarding#fundamentals代码中的命名：最难的简单事
"计算机科学中只有两件难事：缓存失效，以及命名"这句玩笑话里藏着几分真心。本文梳理好名字为什么应当揭示意图而非实现、名字长度与作用域的关系、为什么要避免匈牙利命名法、可搜索性、布尔值/函数/集合的命名惯例，以及把重命名当作一次独立重构来对待的方法。
2026-06-30 · 13 分钟阅读 #clean-code#engineering#fundamentalsFDE 打法手册：用「可丢弃原型」取胜
前向部署工程师(FDE)如何在几天之内,在客户的真实数据上做出能跑起来的演示,从而扭转局面。刻意留下、注定要丢弃的技术债,先排除风险的 spike,什么时候该硬编码,以最短路径抵达「aha 时刻」,期望管理,以及从原型迁移到生产环境。本文整理了一份在一线验证过的 FDE 原型开发打法手册。
2026-06-30 · 14 分钟阅读 #engineering#prototyping#fde工程师的沟通术：如何让技术决策获得通过
好的想法之所以没被采纳，通常不是因为想法本身不好，而是传达方式不好。本文讨论了如何用设计文档和 RFC 来提案、如何先用问题而不是解决方案来说服人、如何针对经营层和同事工程师调整不同的表达方式、在争论中落败后如何前进的「不同意但执行」（disagree and commit）、异步与同步沟通方式的选择、如何明确说出每个决定的代价，以及「强烈主张，虚怀若谷」如何异化为掩饰坏态度的借口这一陷阱。
2026-06-27 · 21 分钟阅读 #career#communication#engineering代码评审的对话术：不带冲突地给予和接受反馈
代码评审既是找出缺陷的技术活动，也是人与人之间的对话。本文讨论评审代码而非评审人的框架，用 Conventional Comments 区分 nit 与 blocker，用提问代替命令，小 PR 为何能获得真正的评审而大 PR 只会被盖橡皮图章，称赞做得好的地方，作为作者如何优雅地接受反馈，以及评审者与作者各自承担的双向责任。
2026-06-26 · 23 分钟阅读 #code-review#communication#engineering分布式系统教会我的恋爱技巧
重试与退避、超时、心跳、一致性模型、背压、优雅降级、幂等性、两将军问题，以及作为带 TTL 缓存的信任。让分布式系统变得困难的那些问题，和让人与人靠近变得困难的问题惊人地一致。本文尝试用工程师的眼光，重新解读恋爱。
2026-06-25 · 20 分钟阅读 #engineering#relationships#fun#distributed-systems从定制到平台：把 FDE 的工作产品化
前向部署工程师(FDE)与产品之间的反馈循环。从 N 个客户身上发现同一个模式，把它抽取为配置与抽象，并用三次法则判断什么时候不该泛化。为一个客户快速交付,与为所有人构建之间的张力,以及优秀产品是如何从前向部署工作中诞生的。
2026-06-24 · 12 分钟阅读 #product#engineering#fdeSQLite 无处不在
地球上部署最多的数据库既不是 Oracle,也不是 Postgres,而是 SQLite。它存在于你的手机、浏览器,甚至飞机里。本文梳理了它无服务器的单文件设计、何时能胜过客户端-服务器数据库、WAL 模式、用内存数据库做测试、通过 WASM 在浏览器中运行,直到用 litestream 保证持久性。
2026-06-15 · 18 分钟阅读 #databases#sqlite#engineering