标签: #code-review
关于 GPU、LLM、MLOps、Kubernetes 以及心态的文章 · 13 篇
同时跑五个智能体真的会快五倍吗 —— 并行作业的瓶颈不在生成
专门用来同时运行多个编码智能体的环境正在变多。Orca 就是其中之一，它主打把一条提示词撒给多个智能体、把每个都隔离到各自的 git worktree 里，再比较结果并合并其中一个。但提高吞吐并不会让瓶颈消失，只会让它换个位置。本文用排队论的一行结论指出它换到了评审与合并上，并整理了在装工具之前只用 git worktree 就能试同一套工作流的方法。
2026-08-09 · 13 分钟阅读 #developer-tools#git#worktree#code-review#workflow同一家公司的两个项目，为什么在 AI 贡献上得出了完全相反的结论
OpenJDK 在 2026 年 4 月全面禁止了由生成式 AI 产出的贡献，而同属甲骨文旗下的 GraalVM 在同一时期明确允许使用 AI 编码助手。两个项目用的是同一份贡献者协议。本文把三份文档并排来读：OpenJDK 的原文、GraalVM 的政策文件，以及两者都参考过的 Linux 内核文档。结论是：这个差异并不是对 AI 的态度差异，而是「把评审负担记到谁头上」的设计差异；知道了这根轴，你也就能写出自家仓库的政策。
2026-08-09 · 12 分钟阅读 #culture#open-source#ai#policy#code-review交付物变便宜之后，评价会挪到哪里 —— 丹麦为什么选择了口头答辩
丹麦教育部推出了一揽子即时措施，要求在家完成的考试作业必须经过口头答辩。当写作成本趋近于零，光看交付物就什么都判断不了，评价便从产出物挪向了作者身份的证据。本文先按原文如实梳理这项公告到底宣布了什么、三项措施各自瞄准什么，再区分清楚把这套逻辑挪到招聘作业和代码评审上时，哪些地方成立、哪些地方会断。
2026-08-09 · 12 分钟阅读 #assessment#hiring#code-review#education#engineering-culture摩擦消失后留下的不是眼光，而是养出眼光的那条路消失了
2026 年 8 月引发热议的随笔 Taste Is All That Is Left 说：随着「做东西」变便宜，唯一还稀缺的能力就是判断什么值得做。本文认同这份诊断，并再往里走一步。眼光是「努力」这台过滤器的副产品；过滤器一旦被拿掉，留下的并不是眼光，而是养出眼光的那条路一起消失了。所以真正需要的是一套刻意恢复摩擦的具体习惯，本文整理了个人与团队各自该改变什么。
2026-08-09 · 11 分钟阅读 #career#craft#ai#code-review#mentoringGitHub 堆叠 PR 完全指南 —— 原生堆叠 PR 解决了什么，又原样留下了什么
2026 年 7 月 30 日，GitHub 把 Stacked Pull Requests 推进了公开预览阶段。把一次大改动拆成若干个带有依赖顺序的小 PR、并行评审、再一并合并的这套工作流，现在由 Web 界面和 gh-stack CLI 扩展原生提供支持。本文梳理堆叠(stacking)真正解决的问题、GitHub 原生实现做了什么又没做什么、当基础分支发生变化时触发的"变基级联(rebase cascade)"要付出多大代价，以
2026-07-31 · 20 分钟阅读 #github#stacked-pr#code-review#git#developer-workflow教人的代码评审，伤人的代码评审 — 同一条意见为什么结果不同
代码评审有三个目的：发现缺陷、传播知识、共享代码所有权，但多数团队只做了第一个，把后两个丢掉了。本文梳理了谷歌的批准标准 — 评审者不是要求完美的人，而是判断代码是否明确变好的人 — 以及强度前缀带来的差别、按观察和影响和建议拆开的句式、200到400行这个PR体积通说的出处及其局限、能减少往返的PR说明，还有被评审一方的技巧。也会谈到评审从技术活变成权力游戏时的信号。
2026-07-26 · 16 分钟阅读 #career#code-review#engineering#feedback#teamworkAI 代码评审到底能不能用 — 测量证据揭示的准确率与误报
AI 代码评审工具的营销话术里充斥着「80% 的 PR 不需要人类评论」这样的数字，但真正把精确率和误报率一起公开的地方几乎没有。把公开的测量结果收集起来看，方向大体一致 — 在开源 PR 上，AI 评审评论真正带来代码变更的比例因工具而异，只有 0.9～19.2%，远低于人类评论的 60%(Gan 等，GitHub Actions 16 款·仓库 178 个·评论 22,326 条)。而在一家把评论解决写进政策强制执行的企业案例里，同
2026-07-17 · 38 分钟阅读 #ai#code-review#static-analysis#evaluation#software-engineering当代码生成变得廉价，哪些技能会升值 — 贬值的与升值的
当代码生成变得廉价而充裕，价值不会消失，而是会转移 — 转移到仍然是瓶颈的那一侧。眼下这个瓶颈是验证、判断与集成。本文基于 Jason Wei 的「验证的不对称性」、DORA 2025(吞吐量上去了，但交付不稳定性仍在持续攀升)、LinearB 对 810 万个 PR 的分析(AI 生成的 PR 等待评审的时间长 4.6 倍)、Stack Overflow 2025(66% 的开发者把「几乎正确但又不完全正确」列为头号困扰)，梳理了什么
2026-07-12 · 22 分钟阅读 #career#software-engineering#ai#skills#code-reviewLLM 倦怠 — 当工作从"创造"变为"审阅"
开发者 Alec Scollon 的随笔《I Think I Have LLM Burnout》在 Hacker News 上引发热议。因为它精准地道出了这样一种感受：一天的工作从"编写"代码，悄然变成了"审阅"模型写出的东西。本文忠实地梳理他的观点，并补上一份平衡的视角。生成变便宜了，验证却没有，审阅 AI 的输出是实实在在的认知劳动。工具在样板代码和陌生领域里能显出价值，但疲惫来自同样错误的反复、频繁的上下文切换，以及"把一切都塞进
2026-07-11 · 10 分钟阅读 #llm#developer-experience#burnout#ai-tooling#code-reviewAI 代码审查工具的兴起 — 自动化审查正在改变团队
AI 代码审查工具正以开源形式大量涌现，重塑着开发工作流。本文从 Git diff 分析、缺陷检测、规约强制，到与人工审查的角色分工、误报管理、CI 集成，做一次实务视角的梳理。
2026-06-29 · 33 分钟阅读 #devops#ai#code-review#ci-cd#developer-tools写出会被快速合并的 PR 和提交信息
很快就被审阅完、很快就被合并的 PR，都有一些共同点。小而目的单一的 PR、Conventional Commits、提交正文里写的是"为什么"而不是"改了什么"、上传前自己先做一遍自我审查、包含背景·变更·测试三部分的 PR 说明、对审阅者的共情，以及堆叠 PR。节省审阅者的时间，就是让自己的 PR 更快通过的捷径。
2026-06-26 · 13 分钟阅读 #git#code-review#collaboration代码评审的对话术：不带冲突地给予和接受反馈
代码评审既是找出缺陷的技术活动，也是人与人之间的对话。本文讨论评审代码而非评审人的框架，用 Conventional Comments 区分 nit 与 blocker，用提问代替命令，小 PR 为何能获得真正的评审而大 PR 只会被盖橡皮图章，称赞做得好的地方，作为作者如何优雅地接受反馈，以及评审者与作者各自承担的双向责任。
2026-06-26 · 23 分钟阅读 #code-review#communication#engineeringGitHub Copilot 编码代理实战指南：将云端后台任务安全引入团队的方法
本文以 GitHub Copilot 编码代理最新的 Cloud Agent 工作流程为基准，梳理团队应该在哪些场景使用它、哪些场景不该用、需要哪些护栏，以及应该如何与 Claude Code 这类以终端为先的代理分工使用。
2026-04-12 · 9 分钟阅读 #github#copilot#coding-agent#cloud-agent#pull-request