16 篇内容
作者是腾讯架构师，文章记录他对「强者」与「超级个体」两条路径的辨析。他承认绩优主义给了自己纪律、结果导向和抗压能力，但也指出它把自我价值等同于成绩，使人把职场关系普遍理解为被评判关系，从而造成长期内耗。转变起点是一次视角切换：把「别人应该怎么对我」换成「我能为对方做什么」，并用 toB 客户、toC 用户、供应链伙伴来类比领导、下属与平级同事。他进一步主张超级个体靠信念而非胜负定义自己，核心能力是服务、信念定力以及在 AI 放大个人产出时敢于「选择不做什么」。文章自承局限：用客户与服务框架理解人与人的关系带有工具化倾向，如何在框架中真正尊重具体的人仍是未解课题。
收录理由在于它把工程师常见的绩效焦虑、被评判感和协作内耗拆解成可描述的机制，并给出服务视角、信念驱动与取舍边界这类可迁移思路，而非泛泛励志。适合处于职业中段、希望在绩优主义与 AI 放大个人能力背景下重新思考定位的工程师与团队负责人阅读。其框架偏个人自省、缺少可验证数据，宜作思考参照而非执行方法论。
这篇 Oxide RFD 讨论前员工重新加入公司的招聘政策。作者以 Sun Microsystems 曾欢迎前员工回归为引，指出 Oxide 鼓励员工自由离开，以降低回归障碍。核心判定是：前员工申请开放职位时不应简化流程，而须像初次应聘一样提交材料，并更新内容以反映在 Oxide 及离开后的经历，而非复用旧材料。这既能促使申请人反思回归动机，也便于与未曾共事过的同事建立了解，并允许申请不同岗位。文章强调统一流程有助于维持招聘透明度和团队协作。其局限是篇幅较短，主要面向 Oxide 内部文化，缺少更广泛的数据和工程实践验证。
推荐收录。文章直接给出 Oxide 前员工回归的明确判定：必须走与普通候选人相同的申请流程并提交更新材料，而非复用旧材料。其“让离开更容易也让回归更自然”及用统一流程维护透明与协作的思路，对工程管理者和招聘负责人有迁移价值；局限是篇幅短、偏组织文化，不涉及技术实现。
本文是 Oxide 的 RFD 537，说明公司远程化后从录制 All Hands 扩展到几乎所有会议，并正式确立“录制每个会议”的政策。作者以透明、团队协作、严谨、同理心与节俭等价值论证录制会议：可减少转述失真、方便回看、帮助新人融入和缺席者追赶，并沉淀技术细节。政策除晨间闲聊、招聘/1:1 等人事会议及拒绝录制的外部会议外，要求计划会议、临时讨论、调试、客户与合作伙伴对话都录制，推荐 Google Meet 自动录制与转录。文中给出有疑问先询问、随时可补录等原则，安全与隐私引用 RFD 455；其适用边界是依赖 Oxide 文化与 Google Meet 生态、需参与者同意，受合规隐私限制的组织要调整。
推荐收录。该 RFD 不是简单宣布政策，而是逐条论证录制会议的透明、协作、严谨、同理心等价值，并给出 Google Meet 自动录制步骤、必录/不录清单和例外处理，可作为工程组织制定会议与知识留存规范的参考。适合远程协作团队、工程管理者及关注工程文化的读者；迁移时需结合隐私合规、外部参会者同意和存储安全，不宜直接照搬。
Oxide Computer 的 RFD 576（作者 Bryan Cantrill）系统讨论工程组织应如何规范使用大语言模型。文章以责任、严谨、同理心、团队协作、紧迫性五个价值观（按优先级排列）为判断基准，强调人类始终在环并须为 LLM 产出负责。随后逐类拆解用途：作为读者、研究者、编辑、写作者、代码审查者、调试者和程序员，分别给出适用方式与边界，例如研究须回归原始来源、公共与个人写作应避免代笔、贴近生产的代码需自审且进入同行评审后不宜整体重生成。文章还归纳三类反模式：强制使用、羞辱使用者与拟人化。它是一份政策与价值观导向的准则，可迁移性强，但属经验判断，未提供实验或量化验证。
推荐收录。它把 LLM 使用从工具技巧上升为可执行的团队规范：用价值观排序支撑具体规则，并对阅读、研究、写作、代码审查与编程等场景给出差异化边界，还点名强制使用、羞辱与拟人化三类反模式。适合工程负责人、技术写作者和正在制定 AI 使用规范的团队参考，其框架可迁移到其他组织的治理讨论；局限在于它是政策主张而非实证研究。
这篇 Oxide 公开 RFD 复盘 2021 年修订职位描述（JD）的决策，并提出未来撰写 JD 的方法。作者主张公开 JD 首要服务候选人，用具体工作内容吸引合适人才，而非罗列完美资格清单。标题应使用外部可理解的通用名称，避免过窄或过泛；正文按“日常职责—有帮助的特质—为什么来 Oxide”三部分组织，并强调职责不等于资格。文章还建议采用积极、透明、非竞争性的语气，避免“rockstar”“blame”等被滥用的词，最后附一份 control plane 软件工程师示例 JD。其经验适用于系统软件/基础设施公司的招聘沟通，对其他组织仅具参考价值，且部分内容带有公司自我推广色彩。
推荐收录：它给出了可操作的 JD 写作框架，包括三部分结构、标题通用性、职责与资格分离、避免 startup 话术等具体规则，并附有真实示例。适合工程管理者、招聘负责人和关注工程文化的读者参考，可迁移到技术团队招聘沟通；但内容主要基于 Oxide 自身实践，通用性有限，且包含公司福利与文化宣传，需与更广泛的招聘研究配合阅读。
文章分享了Salesforce为数千名软件工程师构建代理工程赋能策略的实践经验。作者指出企业级代理工程的核心瓶颈并非模型能力，而是组织学习能力：工程师自然会产生不同工作模式，但缺乏共享语言会导致实践碎片化。为此，他们设计了一个四阶段熟练度框架（AI辅助、验证、编排、原生），以行为变化而非工具熟练度衡量进展，并通过AI训练营、周会、教练指南等项目帮助工程师实践跨越。文章最后提出四条可迁移原则：规模化共享期望、学习旅程优于评估框架、行为变化是关键指标、学习文化重于任何框架。文章侧重组织赋能和文化建设，但未提供具体量化效果数据。
推荐收录。该文从工程组织赋能的角度提供了真实、系统的转型经验，提炼出的熟练度框架和原则可直接迁移到其他大型工程团队，尤其适合技术领导者和团队管理者参考。它避免了纯工具推广，强调了行为改变和共享语言的重要性，具有长期参考价值。
这篇文章围绕“AI是否会取代软件工程师”展开，核心观点是否定的：作者认为，现有证据并不支持“AI能力达到某个阈值就会引发大规模裁员”的叙事，尤其在软件工程这样监管壁垒较低的行业里，这一判断更具代表性。文章引用纽约州 WARN 通知中的 AI 披露数据，指出首个完整年度里提交的 160 多家公司没有一家勾选 AI 相关裁员原因，说明至少在公开就业数据上还看不到明显替代效应。作者进一步分析开发工作并不主要耗费在“把代码打进电脑”这一环节，而在于决定要做什么、验证交付是否正确并承担责任，以及对代码库、业务和运行环境的深层理解。文章因此强调，AI 更像是在加速部分执行步骤，而不是消除软件工程师的核心价值。其局限在于它是基于现有数据和定性分析的论证，不等同于对未来长期就业趋势的严格预测。
推荐收录，因为文章直接给出了可核查的证据链：就业数据、任务拆解调查和对工程师工作的定性分析，共同支撑“AI尚未替代软件工程师”的判断。适合关注职业规划、团队管理和 AI 时代工程角色变化的读者阅读；它的可迁移价值在于帮助读者把注意力从“写代码速度”转向需求定义、验证与领域理解，但需要注意它不是严格实验结论，而是基于现有证据的论证。
文章围绕 FDE（Forward Deployed Engineer）在 AI 时代的角色演变展开，核心观点是 FDE 不是“高级外包”，而是一套把前线客户经验蒸馏为行业模板、SOP 和产品能力的机制。作者进一步分析了传统 IT 协作链路的信息衰减问题、AI 如何消融能力边界、FDE 容易滑向驻场外包的风险，以及哪些条件决定 FDE 能否真正形成可复用资产。文章最后结合腾讯云客户成功团队，提出从需求翻译者转向现场闭环者的能力模型与组织形态建议。
推荐收录，因为文章不是停留在岗位概念讨论，而是给出了 FDE、客户成功和产品/产研协同之间的结构化判断框架，能帮助读者理解 AI 时代服务型团队如何升级为解决方案型团队。它对做企业服务、云厂商、行业解决方案和技术销售协同的读者都有较强迁移价值，尤其适合思考组织分工、能力模型和知识复用机制的人阅读。
文章围绕开源项目中“刷PR”“刷贡献”现象展开，指出在 AI Agent 和外包式辅导推动下，部分提交者会用看似有效但实际无价值的 PR 消耗维护者精力。作者结合 vLLM 的具体案例，提出维护者可能不得不走向“know your contributor”的身份核验思路，并强调应优先识别真实用户、真实场景带来的问题。文章的核心结论是：当贡献的真实性变得难以辨别时，开源协作会从“欢迎所有提交”转向更重视来源可信度和使用场景证明。
推荐收录，因为它不是简单情绪表达，而是从维护者视角讨论了开源协作在 AI 时代面临的新摩擦和治理成本。对开源维护者、社区运营者和贡献者都有参考价值，尤其适合理解如何平衡开放性、审核成本与贡献真实性。
这篇文章从 Instacart Economics Team 的一手数据出发，分析 AI 如何改变 applied scientist 的职责边界与工作组合。作者用 2023-2025 年的 GitHub PR、代码行数和任务分类结果说明：AI 一方面显著提高了标准化、可模式匹配任务的产出效率，另一方面也把 frontend、platform/tooling 等原本门槛更高的工作变成了“最低可用能力”范围内的可执行任务。文章还进一步讨论了平台化的取舍，指出在人机交互式 UI 平台和 machine-interactable tools/agentic skills 之间，AI 可能改变平台应当被构建的形式而不只是降低构建成本。
推荐收录，因为它不是泛泛讨论“AI 会改变工作”，而是结合经济学理论和团队真实产出数据，给出了可观察、可讨论的角色重构证据。对于做数据科学、应用科学、机器学习工程和内部工具建设的读者，这篇文章对任务分工、能力边界和平台化策略都有较强迁移价值。
这篇文章围绕“大组织内过度推行 AI Coding 是否会适得其反”展开，核心观点是：在核心业务和大型组织中，AI 编码带来的短期提速可能会被需求膨胀、系统复杂度上升、review 退化和组织激励错配迅速抵消。作者进一步指出，单靠渐进式重构并不能根治问题，真正的矛盾在于需求控制、交付节奏、团队治理和历史复杂度管理，而这些往往比“提效”更难推动。
推荐收录，因为它不是在讨论 AI Coding 的工具技巧，而是在分析大组织里 AI 采用后的组织性副作用、流程失衡和长期维护成本，这类判断对技术管理者和资深工程师有较强参考价值。文章能帮助读者从“生成率”和“交付速度”之外，重新审视需求质量、架构可维护性和团队激励对 AI 落地的真实约束。
这篇文章是 Brendan Gregg 解释自己加入 OpenAI 的个人职业选择与工作动机，核心围绕 AI 数据中心在成本、能耗和规模上的压力，以及性能工程在其中的价值。作者结合与多位从业者、朋友和普通用户交流的经历，说明 ChatGPT 已经成为大众高频工具，这种真实使用场景改变了他对 AI 落地的判断。他还回顾了自己从少年时期想做“Orac”式对话系统，到后来从事数据中心性能工作的长期兴趣脉络，强调自己希望把性能优化方法直接用到 ChatGPT 性能团队。文中也交代了他在 OpenAI 的岗位、远程办公地点、初始项目方向，以及会继续使用 eBPF、Ftrace、PMCs 等手段寻找更大优化空间。整体属于职业决策与岗位展望，而非系统化技术教程，技术细节主要停留在方法与方向层面。
推荐收录，因为文章直接给出了顶级性能工程师选择 AI 公司与岗位的依据：真实用户规模、算力/能耗压力、团队能力和个人兴趣的交汇。适合关注 AI 基础设施、性能工程或职业转型的读者参考，但需要注意它是带强烈个人色彩的叙述，不是可复用的完整方法论。
文章回顾了 Anthropic 性能工程团队如何设计并多次重做 take-home 面试，以在 AI 辅助普及后仍能区分候选人。原题是模拟加速器上的树遍历优化，要求候选人逐步完成并行化、SIMD/VLIW 利用、调试和工具构建，因此在早期能有效筛出强工程师，也确实招到了多位高绩效员工。随着 Claude Opus 4 和 4.5 在两小时约束内逐步追平甚至超过优秀人类，作者不得不把题目改成更陌生、更受限的谜题式优化问题，并减少那些模型已经轻松掌握的维度。文章总结出评估设计应兼顾真实工作、高信号、足够深度以及对 AI 的开放使用，但也承认越强调“抗模型”越容易牺牲岗位真实性和可解释性。最后作者公开了原始题目作为挑战，并用成绩对比说明人类在无限时间下仍有优势，但在短时约束下可区分性正在迅速下降。
推荐收录，因为文中给出了清晰的直接证据：原始 take-home 曾有效招人，但已被 Claude Opus 4/4.5 在 2 小时约束内追平甚至超越，迫使团队重设评估方式。适合负责面试设计、技术招聘和 AI 时代能力评估的人阅读，可迁移价值在于如何构造高信号任务与识别失效边界。
文章以 Intel 新 CEO 强调“坦诚批评”为背景，回顾作者作为客户与 Intel 长期会议往来的经历，以及后来在公司内部看到“站在另一侧”的感受。作者指出，面对硬件供应商时，客户如果能给出直接而具体的技术反馈，往往能推动产品改进，但前提是要准备充分、留下书面记录，并注意知识产权和会议纪要中的措辞。文中给出了一套可执行做法：会前研究参会者、坚持技术批评而非情绪化攻击、确认是谁在场、追问资源和进度、拒绝被动充当免费培训对象，并在必要时直接升级到高层。作者的结论是，真正有用的“狠话”不仅要敢说，还要花同样大的力气持续跟进，否则再正确的意见也会被稀释或被忽略。该建议主要适用于供应商沟通、评审会议和跨公司协作场景，不适合替代法律或商业谈判判断。
收录价值在于它不是泛泛地鼓励“勇敢表达”，而是给出了可落地的供应商反馈流程、会议纪要和升级机制。适合经常与硬件/平台供应商或跨团队评审打交道的工程师、技术负责人参考。
本文讨论在什么情况下应成立计算机性能工程团队，以及这类团队的投资回报如何评估。作者从多年在 Netflix、Intel 等公司的经验出发，指出性能工程的主要价值不只是降本，还包括降低延迟、提升可扩展性与可靠性，以及加快研发推进。文中详细列举了团队的工作范围：测试和推动新软硬件采纳、构建内部观测与分析工具、深入定位瓶颈和尾延迟、调参优化、做容量规划与知识分享等。作者给出粗略的组建门槛和规模建议，例如当基础设施支出达到百万美元级别就应考虑专职人员，并强调已有的 SRE/高级开发者会部分覆盖这类工作。文章也说明这些建议更适用于技术消耗型公司，且实际收益依赖栈的复杂度、现有优化基础和团队成熟度。
文中直接给出了性能工程团队的职责边界、ROI 构成和规模判断规则，并用 Netflix、Sun 等案例说明其可迁移的判断方法。适合负责基础设施、SRE、技术管理和成本优化的读者参考，但结论依赖公司体量与技术栈复杂度，不宜机械套用。
这篇文章是 Brendan Gregg 对“极端远程办公”三年经历的个人复盘，核心事实是他在澳洲为美国公司工作，累计参加了 77 次凌晨 1 点到 6 点之间的会议，折合约 102 小时清醒时间。作者用这些数据说明跨时区远程并不等于轻松，真正的成本来自频繁被打断、睡眠被切碎、以及 Daylight Saving 带来的排班混乱。文章还给出一组具体做法：统计并公开不合理会议、尽量不抱怨工时、用每日日志和周报维持产出感、提前明确录制/取消会议、并把家庭办公室与音视频设备配置好。作者进一步指出，远程工作常被误解为“不够投入”，并可能在晋升和机会分配上产生 out of sight, out of mind 的职业风险。全文的价值主要在于提供了跨时区远程工作的真实代价、沟通策略和组织偏见，而不是一套可普遍复制的最佳实践。
推荐收录，因为文章用 77 次凌晨会议、102 小时清醒时间等具体数据，直接展示了跨时区远程工作的真实成本，并总结了可操作的沟通与自我管理方法。适合远程员工、管理者和分布式团队参考，但读者也需注意它是个人经验，且明显带有澳洲-美国时差这一特定场景。