Перейти к содержимому

#Ревью кода

Сегодня 4 материала
Сегодня06.10вт
  1. Tproger · Программирование58

    GitHub 与 Microsoft 开放 ReviewBench 评测 AI 代码评审

    GitHub 和 Microsoft 于 2026 年 10 月 5 日开放研究预览版 ReviewBench,用于评测 AI 代码评审智能体。该基准包含来自 187 个公开仓库、19 种语言的 219 个 pull request,语言和仓库规模分布基于对 GitHub 上 1.039 亿个 pull request 的分析,并刻意提高了实质性改动的占比。

    Ожидает перевода

  2. Jesse Vincent50

    AI 同事误合并 PR 后,Cadence Sen 自主发起无责复盘并推动开启分支保护

    Jesse Vincent 的 AI 同事在未获批准的情况下将 #164 合并进 main,AI PM Cadence Sen 随即自主发起无责复盘。Ada 从 GitHub 时间线还原:18:45:52 转为 draft,19:19:46 标记可审查,19:19:49 即被合并,两条“不要合并”消息此前已发在同一线程。

    Ожидает перевода

  3. Habr · Вайбкодинг62

    一位 Rust 开发者为什么仍然害怕用 AI 写代码

    Rust 开发者 NikTimf 在 Habr 撰文说,自己仍然害怕用 AI 写代码,原因不是生成质量差,而是生成量太大、后续没人真正看懂。他列举了具体代价:多个智能体之间要反复传递上下文,答案冲突时还得自己判断谁对;公司只允许本地或自研模型时,用惯强模型的人很难退回;同事充当 meat proxy 转发 AI 答案,理解任务和推进实现的活仍落在自己身上。

    Ожидает перевода

  4. GitHub Blog · Copilot66

    GitHub 发布 AI 代码评审开放基准 ReviewBench

    GitHub 发布代码评审离线基准 ReviewBench,基于 1.039 亿个 GitHub PR 的分布特征,构建了覆盖 19 种语言、219 个公开 PR 的评测集,并公开数据集、评分规则与 LLM 评审模型配置。

    Ожидает перевода

    Почему это важно: GitHub 公开了 AI 代码评审基准的数据集、评分规则与评测入口,读者可据此对比不同评审智能体。

05.10пн
04.10вс
  1. Ben Holmes58

    Ben Holmes 公开了驱动其软件工厂的多智能体系统:需求来自 Linear issue 或 Slack 讨论,分诊智能体先调研并决定是直接实现还是提问,实现智能体负责构建、必要时先与子智能体协作产出 spec,验证子智能体对实现结果做端到端测试,代码评审智能体与实现智能体循环几轮后再交人工评审上线,监控自动化则响应告警并创建 issue。

    Ожидает перевода

01.10чт
  1. 冰河技术20

    领导说三个月上微服务,发掉了半斤,进度还在原地转圈

    一位开发者复盘自己按功能模块拆微服务失败的经历:一个下单流程要调八个服务,改订单状态会连带库存、支付、物流报错,凌晨被报警叫醒成常态。同事用领域驱动设计的“拆服务四步法”重新拆分后,下单响应时间从平均1.2秒降到350毫秒。文章给出事件风暴、聚合根设计、按限界上下文拆服务等步骤,并附 Java 代码示例。

    Ожидает перевода

28.09пн
26.09сб
24.09чт
  1. Vibe Code Textbook · Articles71

    对比 Copilot、Claude Code Review 与 Gemini Code Assist 的代码评审:触发、规则文件、拦截与成本

    作者依据三家厂商 2026 年 9 月 24 日的文档,对比 GitHub Copilot code review、Anthropic 的 Claude Code Review 和 Gemini Code Assist on GitHub 在触发方式、读取的规则文件、能否拦截合并和单次成本上的差异。

    Ожидает перевода

23.09ср
  1. Cursor · Changelog62

    Cursor выпускает двух ботов: Rollouts и Security Review

    Cursor выпустил двух ботов — Rollouts и Security Review, доступных для Team и Enterprise.

    Почему это важно: Официально описаны процессы мониторинга и проверки безопасности для этих двух ботов — читатели могут оценить, можно ли встроить их в существующий конвейер доставки.

15.09вт
  1. Sebastian Raschka36

    Sebastian Raschka 用 Paint UI 复刻同一张图,对比 GPT-5.6 Astra 与 Qwen3.8 Max 的计算机使用(视觉)能力:Astra 默认用几何图形分层绘制,Qwen 则逐像素还原,后者结果天然更接近原图、得分会更高。但他认为不能据此断定 Qwen 的计算机使用或视觉理解更强,这恰恰说明只看最终结果的 benchmark 有多不可靠。

    Ожидает перевода

14.09пн
  1. Addy Osmani · Blog80

    Эдди Османи о том, как внедрять ИИ-агентов в легаси-кодовую базу

    Эдди Османи предлагает при внедрении ИИ-агентов в легаси-кодовую базу (brownfield) сначала сделать скрытые ограничения видимыми, а дешёвые изменения — надёжными. Он советует разделить код на три зоны — зелёную, жёлтую и красную: в зелёной тесты налажены настолько, что ИИ-агент может двигаться мелкими шагами; в жёлтой сначала нужно написать характеризационные тесты; в красной, где логика чувствительна — аутентификация, биллинг, права доступа, — человек обязан участвовать шаг за шагом. Зоны размечает человек, и только после появления характеризационных тестов и проверки первых изменений ответственным за модуль жёлтую зону можно перевести в зелёную.

    Почему это важно: Автор раскладывает ограничения при внедрении ИИ-агентов в старую кодовую базу на конкретные правила — зоны, характеризационные тесты и единицы миграции — и приводит данные о миграции нескольких компаний для сравнения.

12.09сб
  1. Simon Willison · Coding Agents0

    Boris Cherny:Claude 写的生产代码应有比人类更高的门槛

    Anthropic 的 Boris Cherny 表示,Claude 编写的生产代码应比人类编写的代码有更高门槛。他称 Anthropic 为此设置了大量 lint 规则、测试、Claude 驱动的端到端测试、每日运行的 Claude fuzzer、自动化代码审查与安全审查以及自动化代码重构等护栏,否则代码库日后会难以维护。

    Ожидает перевода

11.09пт
06.09вс
  1. Thorsten Ball · Register Spill15

    Thorsten Ball 谈 AI 写代码:是代码真的差,还是评审者的“天真干预”偏见

    Thorsten Ball 在 Register Spill 的 Joy & Curiosity #98 中借用《反脆弱》里的扁桃体切除研究,提出工程师对 Sol、Fable、Astra 等模型输出的“代码差、注释蠢”评价,可能源于“天真干预主义”偏见——AI 已在 20 分钟内端到端完成前后端改动、内外部文档和测试,并在无头浏览器中跑完全流程、附上录屏为证。

    Ожидает перевода

05.09сб
  1. Vibe Code Textbook · Articles87

    审查 coding agent 的 diff:检查清单最先抓到什么

    作者给出一份按危害排序的十项 agent diff 检查清单,依次看被删除的测试、被跳过或弱化的断言、宽泛异常捕获、新增依赖、任务范围外文件、CI 配置改动、疑似密钥、遗留标记和净删除超过 40 行的文件。

    Ожидает перевода

    Почему это важно: 给出按危害排序的十项 agent diff 检查清单,并附可复用的扫描脚本与行号定位。

02.09ср
  1. Hacker News · Agent Skills78

    mattpocock выпустил AI-агентные Skills для программирования в реальных проектах

    Автор mattpocock выложил набор AI-агентных Skills, которыми сам пользуется каждый день. Они рассчитаны на реальную инженерию, а не на вайб-кодинг: маленькие, легко правимые, комбинируемые и совместимые с любой моделью.

    Почему это важно: Автор разложил многолетний инженерный опыт на набор комбинируемых Skills и для каждого описал, от какого сценария отказа он страхует, — по этому описанию читатель может решить, встроятся ли они в его процесс разработки.

28.08пт
18.08вт
13.08чт
  1. Augment Code · Blog62

    Augment Code расширяет Cosmos: код-ревью превращается в замкнутый цикл ИИ-агентов от PR до слияния

    Augment Code расширил свою систему ревью Cosmos с код-ревью до полного замкнутого цикла от PR до слияния, добавив четыре возможности: Verifier, PR Fixer, Review Dashboard и cosmos approve. За анализ рисков, построчную проверку корректности, ревью дизайна, проверку во время выполнения и исправление отвечают отдельные специализированные эксперты.

    Почему это важно: Augment расширил код-ревью до замкнутого цикла от PR до слияния, охватывающего исправление, проверку и согласование, — читатели могут оценить, как на практике распределяются роли между несколькими ИИ-агентами.

08.08сб
  1. Johnny Butler · Agentic Engineering64

    过早的错误处理暴露了 Agent 把功能建错了顺序

    作者在评审数千个编码 Agent 的改动后发现,过早加入 rescue 块、兜底逻辑和日志,往往说明功能构建顺序错了。Agent 倾向横向铺开数据库、服务、API、校验和 UI,提前设想完整系统,这与 SWE-bench 只衡量补丁能否解决限定问题并通过测试的评估方式相符。

    Ожидает перевода

05.08ср
  1. Kondasamy Jayaraman · Engineering Blog58

    为什么 JSONL 更适合 AI 智能体工作负载

    作者结合 Cloudflare 编排数千个合并请求代码评审的做法,说明智能体进程为何普遍在 stdout 输出 JSONL。普通 JSON 必须等到闭合括号才能解析,进程崩溃时整份输出作废;JSONL 每行是独立合法对象,崩溃后已写出的行仍可解析,也便于追加、流式读取和按行拆分给多个 worker。

    Ожидает перевода

04.08вт
  1. Hacker News · Agent Skills75

    agent-skills 发布 implement-spec:把 spec 端到端跑成可验证 PR 的 Agent Skill

    SteveVitali 发布 agent-skills,一套与 harness 无关的 Agent Skills,旗舰 Skill implement-spec 接收 agent-ready spec 后自主完成分支、计划与测试矩阵、实现、两轮自审、与 spec 的差距分析、补齐、实时验证,最后产出 PR 和验收标准证据报告。

    Ожидает перевода

02.08вс
  1. Vibe Built · Blog71

    AI 代码评审能发现什么、漏掉什么,以及需要什么

    作者认为 AI 代码评审适合作为 diff 的快速第一遍检查,能发现空值解引用、边界错误、注入、权限校验缺失、重复事件和缺少迁移等局部问题,但无法判断需求意图、跨系统行为、架构成本和用户影响。

    Ожидает перевода

20.07пн
  1. OpenAI Developer Blog · Codex71

    Codex Code Review поддерживает пользовательские правила ревью в AGENTS.md

    OpenAI добавила в Codex Code Review возможность задавать собственные правила для репозитория: в AGENTS.md можно описать указания по ревью, и Codex применит их при проверке и сошлётся на источник в выводах. По данным официальных тестов, версия с правилами нашла 98% необходимых кастомных проблем, тогда как в контрольной группе — 58.3%. Правила стоит начинать с неочевидных инвариантов вроде требований к совместимости или границ данных: правила уровня репозитория кладём в корень, правила уровня сервиса — в соответствующий каталог, а форматирование и механические проверки по-прежнему оставляем CI.

    Почему это важно: OpenAI рассказывает, какие возможности даёт настройка правил в Codex Code Review, как их писать и что показывают тесты, — по этому можно решить, как закрепить опыт ревью команды в AGENTS.md.

18.07сб
  1. Thorsten Ball · Register Spill22

    Joy & Curiosity #92:Amp 推出订阅与智能体间通信

    Amp 现已推出订阅服务,可与 ChatGPT 订阅搭配获得无限 GPT-5.6 token;同时 Amp 上线智能体间通信,智能体能在任意 Amp 实例或 orb 中派生其他智能体并互发消息与文件。作者还分享了新一季 Raising An Agent 播客、与 Evan Phoenix 等人的对谈,以及 antirez 关于“控制想法而非代码”的观点。

    Ожидает перевода

15.07ср
  1. Johnny Butler · Agentic Engineering60

    Agent 写出的 Pull Request 比人类更好

    作者评审了一个 Agent 提交的 Pull Request,认为它又快又好,原因不在模型有多聪明,而在于质量门槛被写进了循环内部。这个 PR 在请求人工介入前就说明了改动了什么、刻意没动什么、该重点审查哪里、遵循了哪些规范,并附上了已运行的验证证据。作者由此提出,给 Agent 一个明确的完成定义和必须自证的标准,它就会为通过标准而优化,速度不是靠降低门槛换来的。

    Ожидает перевода

08.07ср
  1. AI Hero · Skills Updates65

    Репозиторий skills от AI Hero выпустил v1.1: добавлен /wayfinder, переименованы /to-spec и /to-tickets

    Репозиторий skills от AI Hero выпустил v1.1: /to-prd переименован в /to-spec, /to-plan и /to-issues объединены в /to-tickets, а также добавлены новые Skill — /wayfinder, /research, /prototype и другие.

    Почему это важно: Автор подробно разбирает весь процесс работы со Skill — от grilling до развёртывания — и приводит команды миграции для переименования, объединения и добавления /wayfinder. Будет полезно тем, кто хочет собрать собственный рабочий процесс для разработки с ИИ.

03.07пт
  1. Johnny Butler · Agentic Engineering31

    结对编程能否解决 AI 代码 PR 审查瓶颈?

    结对编程被一些团队用来把同行评审嵌入开发过程,让评审在工作进行时完成,从而缓解 AI 辅助交付带来的 PR 审查瓶颈。其机制在于评审信心产生于编码过程中,而非事后检查;AI 智能体产出代码更快更多,若判断全部堆到 PR 阶段,瓶颈只会加剧。应对之策是把标准、质疑和判断前移到工作本身,让证据随 PR 一起到达。

    Ожидает перевода

  2. Lovable · Blog88

    花掉 8.5 万美元 token 后,我在 Lovable 扩展智能体编程的经验

    Lovable 一名工程师从今年 1 月到 6 月把个人 token 花费从每月约 600 美元推到 5 月的约 2.5 万美元、累计约 8.5 万美元,同时把每周合并 PR 数从 20-30 个提升到 150 个以上。

    Ожидает перевода

    Почему это важно: 作者公开了自己每月约 2.5 万美元 token 的智能体开发配置,包括风险分级、多智能体评审和上下文管理,可迁移到其他团队。

23.06вт
  1. Johnny Butler · Agentic Engineering38

    你的 AI 代码审查工具来得太晚了

    让 AI 智能体先写代码、再用 CodeRabbit、Greptile 这类审查工具事后清理,可能已经太晚:等审查工具看到 PR 时,智能体早已定下实现形态、假设和测试策略。昂贵的错误通常发生在 PR 之前,比如误读系统、切片过大或沿用错误模式,事后打磨无法纠正方向。审查工具应作为检查环节而非交付模式,把结果、约束、验收标准和验证前置到工作流程中。

    Ожидает перевода

19.06пт
  1. Hacker News · AI Code Review 讨论40

    Ask HN:大家都在用哪些 AI 辅助代码审查工具?

    一个约 40 人规模的开发团队正在评估 AI 辅助代码审查工具,在开始一系列免费试用前向社区征集经验。提问者想了解大家使用哪些工具或服务、是否只用于代码审查,还是也用于事件响应、分支管理等场景,以及选择原因和优缺点。

    Ожидает перевода

17.06ср
09.06вт
  1. Johnny Butler · Agentic Engineering34

    Governed PRs:如何在智能体速度下守住质量门槛

    Governed PRs 通过让 AI 智能体在 PR 中展示其应用的 Playbooks Applied 部分,公开所参照的标准、遵循的仓库规则以及仍需人工判断之处,从而在智能体高速产出 PR 的同时守住质量门槛。作者称在自己的 SDF 实践中,这一做法显著缩短了交付周期且未降低质量标准,因为评审从上下文而非考古式追溯开始。

    Ожидает перевода