什么是 vericoding？AI 生成代码时代的验证新范式

vericoding（AI 引导的认证程序精化）是一种以规范而非实现为核心的软件工程方法，由定理证明器（如 Rocq、Lean）充当认证器、AI 负责猜测实现，机器负责验证代码是否符合规范。它按梯度推进：从 Gherkin 场景的 BDD，到 specsaver 的可执行运行时契约，再到 axiomander 的机械化证明。Scidonia 用该方法证明程序行为并优化慢路径。

Awaiting translation

Rust 开发者：我不怕被 AI 取代，我怕的是和 AI 一起工作

Rust 开发者 Nikita 认为 AI 只加速了写代码这一段，上下文准备、审查、测试和修复仍要人来做，因此该按“到可上线改动”的时间算收益，而不是按模型首次响应算。

Awaiting translation

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

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

Awaiting translation

SWE-bench 分数到底测了什么：resolve rate 的生成过程与五篇论文的补充发现

SWE-bench 的百分比是智能体编程领域被引用最多的数字，但它比通常被引用的方式要窄得多。文章拆解了一次评测如何产出这个数字：提交是 JSONL 格式的补丁，在 Docker 容器中应用到 base_commit 并运行仓库测试，FAIL_TO_PASS 全部通过且 PASS_TO_PASS 不回归才算 resolved，默认是 pass@1。

Awaiting translation

读者无法分辨带水印的 AI 文本：一项基于 SynthID-Text 的测试

博主用 Qwen3-30B-A3B-Instruct-2507 在租用的 H200 上生成 30 条回答，其中部分用 SynthID-Text 加水印，让读者分辨哪条被水印。首轮 278 人平均得分 3.92/10，重排题目后 73 人平均 3.4/10，接近纯随机猜测的 3.33，说明读者无法识别水印。目前测验累计约 4700 份回答，均值 3.44/10。

Awaiting translation

AI 对研发效率提升到底有多大？开发者称写代码只占工作 10%

有开发者指出，AI 只提升了写代码的速度，但正经公司里 90% 的时间花在跨部门协调、审批和排期上，效率提升非常有限。他举例称一个涉及三个部门、5 个系统的紧急需求，光沟通协调就耗掉三天，最后自己只加了三行配置。另有开发者称，20-30 人的团队如今 3 人加 5 个 Claude 200 刀账号就能同时接 20 个项目。

Awaiting translation

智能体循环里的 TDD 是形式还是真价值？Martin Fowler 的对比实验

Martin Fowler 用 Sonnet 4.6 生成、Opus 4.8 盲评的方式，对小型、中型和较大型三类业务逻辑任务分别跑 TDD 与非 TDD 方案，结论是两者质量没有明显差异，非 TDD 方案在设计和测试质量上还多次略高，变异分数也没有实质差别。

Awaiting translation

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

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

Awaiting translation

Addy Osmani：智能体时代的代码质量取决于你给 Agent 设的约束

Addy Osmani 认为，Agent 每天产生数十万甚至上百万次改动，逐行人工评审已不可行，代码质量要靠在 Agent 周围设置质量门禁来保证。这些约束包括单元测试、属性测试、验收测试、变异测试，以及圈复杂度和行长等代码质量指标，并分布在改动开始前、Agent 工作过程中和能否进入生产三个环节。

Awaiting translation

Geoffrey Huntley 加入 Antithesis，用形式化验证与确定性测试消除代码 slop

Geoffrey Huntley 宣布加入 Antithesis，主张用形式化验证和确定性系统测试应对 AI 时代代码量激增带来的审查危机。他认为软件编写已被商品化，但验证与理解仍非免费，Antithesis 结合 LLM 对抗式代码审查与 pre-commit hook 驱动的语言分析器，可让人类和智能体交付可靠软件而无需掌握专门知识。

Awaiting translation

What is loop engineering, and how are leading software engineering teams using it?

Augment Code proposes loop engineering: designing agent loops that run from trigger to execution to validation to outcome, with agents handling the intermediate steps and humans stepping in only at checkpoints that require judgment. The article compares loop engineering with prompt engineering and context engineering as distinct layers, lays out five stages—trigger, execution, validation, outcome, and improvement—and describes four team-level loops already running in production: code review, ticket-to-PR, vulnerability remediation, and incident response.

AI 编程基准测不出什么：代码可维护性

AI 编程基准只衡量模型能否在限定条件下完成改动，却测不出它留下的代码库是否更难维护——重复逻辑、耦合收紧、多余抽象都不会让当前测试失败，代价在后续扩展或排查线上问题时才显现。作者主张把可维护性放进交付流程：仓库级规范、清晰的架构边界、有意义的测试与静态分析，并审查重复、复杂度、架构漂移和模式不一致。

Awaiting translation

Addy Osmani on software factories: the visible factory and the hidden factory, where validation is the bottleneck

Addy Osmani proposes that a software factory has three layers—loop, harness, and factory. The factory isn’t a smarter agent; it’s multiple loops with harnesses feeding into a single review gate, with humans controlling the outer loop.

AI 智能体的能力是真的，但工程纪律要自己补

当前 AI 智能体演示普遍在无限 token 预算、全新或精选代码库、无合规与运维压力的条件下运行，展示的是能力上限而非真实交付环境。AWS 副总裁 Marc Brooker 指出，智能体的机会受限于缺陷率，开发者调研中已有团队称其 AI 工具预算不可持续。作者建议只给智能体与验证能力和预算相匹配的自主权，用标准、检查项和可追踪的支出逐步放宽。

Awaiting translation

Agent 写出的 Pull Request 比人类更好

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

Awaiting translation

Addy Osmani：工程师要负责智能体的外循环

Addy Osmani 在 AI Engineer World's Fair 2026 闭幕演讲中提出，智能体负责内循环（调查、实现、验证、重复），工程师要负责外循环，即对系统结果的可问责性。

Awaiting translation

绿色通过从来不是你点合并的理由：AI 智能体自动合并 PR 的信任前提

一些团队开始让 AI 智能体在 CI 全绿后自动合并自己提交的 PR，不再有人工介入。但绿色检查之所以能作为合并信号，靠的是检查运行前人类对意图、测试保护范围和系统风险点的判断，CI 只是确认而非替代这一判断。作者认为自动合并只适合低风险、边界清晰且有历史记录的改动，信任需要靠一次次带证据的改动积累，而不是打开一个开关。

Awaiting translation

从代理网关到本地 Opus：AI 工程面试题深度追问清单

一份面向 AI 工程岗位的面试题追问清单，覆盖代理网关（如 OpenRouter/LiteLLM）、MCP/CLI、从零手写 Agent、多智能体编码流程、自定义 benchmark 以及本地部署约 27B-Q3_K_M.gguf 模型等方向。作者认为，这些题目的通用版本如今谁都能靠 vibe coding 一晚做出来，已失去简历价值，真正稀缺的是把任务打磨到"理想"状态的能力。

Awaiting translation

AI 编程智能体指令里的“Write Clean Code”只是愿望，不是可执行指令

针对 AI 编程智能体指令文件中常见的“写整洁代码”“用 TDD”“遵循 SOLID”等表述，作者指出这些说法本身没错，但都不是可自我执行的指令。智能体主要复用代码库中已有的模式，在好坏混杂的真实代码库里，这类指令只是表达愿望。作者主张改为展示好与坏的具体样例，并让智能体证明自己实际遵循了哪些模式、在哪里应用、如何验证结果。

Awaiting translation

Drew Breunig：问题在于提示词债，手调提示词就无法做到模型无关

Drew Breunig 提出提示词债概念，认为用自然语言手写提示词来定义系统行为会带来三重后果：迭代变慢、团队难以读懂、应用被锁死在单一模型上。他引用 Datadog 报告称其观测到的流量中最常用的模型是 GPT-4o，并举例 Fable 的系统提示词把同一条版权规则重复了六次、Claude Code 让 Opus 七次要求在一次响应中返回多个工具调用。

Awaiting translation

别再给产品加 AI：AI 原生设计的 10 个模式

作者结合 18 个月构建智能体系统的经历提出，AI 原生设计应先问“这块能不能删掉”，而不是“能不能加上 AI”，并称自己的技术栈随模型变强缩减了 60-70%。

Awaiting translation

我绝不会为了智能体速度放弃二十年的交付实践

面对 AI 编程智能体带来的提速压力，作者认为更快的代码生成不等于更快的软件交付，意图、验收标准、风险边界、验证、证据与评审等交付纪律不可让步。智能体只有在既有工作流内运作才能参与其中，工作越交给智能体，可评审性就越重要。这是 Software Dark Factory 背后的核心理念：智能体应强化而非取代经过验证的交付实践。

Awaiting translation

在信任自动合并 PR 之前，团队需要先补齐什么

越来越多工程团队在讨论让 AI 智能体自动合并 PR，但真正的信任问题不在模型本身，而在于变更意图是否明确可审、验收标准是否事先定义、风险边界是否划定、验证是否真正执行、智能体权限是否受限，以及是否有可审查的决策记录。缺少这些，自动合并只是让决策变快，而非交付变快。Software Dark Factory 正尝试把意图、标准、约束、验证和权限边界内建到工作流中，让治理先于速度。

Awaiting translation

编码智能体的表现取决于 harness，而非只取决于模型

作者认为编码智能体的 harness 是模型外的软件层，负责组装上下文、暴露工具、控制运行循环、执行权限并评估结果，因此同一模型在不同 harness 下表现会完全不同。

Awaiting translation

为什么 stripe_subscription_id.present? 是治理定时炸弹

作者指出用 stripe_subscription_id.present? 判断用户能否访问，是把支付状态和访问权限当成同一件事，随着免费试用、宽限期、合作方访问、管理员授权等场景出现，can_access?

Awaiting translation

Vibe coding 是原型方法，不是交付流程

作者 Aldrin 认为 vibe coding 适合用自然语言做低成本探索，比如脚手架、陌生 API、UI 变体和测试思路，但快速可见的草稿不等于功能可以被团队接手。

Awaiting translation

宝玉：与其说 AI 优先，不如说软件工程优先

宝玉点评《Why Your "AI-First" Strategy Is Probably Wrong》一文，认为这套打法本质是软件工程问题，AI 时代人成了瓶颈。

Awaiting translation

UC San Diego 研究 112 名专业开发者：资深开发者不 vibe coding，而是控制 AI 智能体

UC San Diego 研究团队通过 13 场实地观察和 99 名资深开发者的问卷（共 112 人，中位经验 10 年，使用 Claude Code、Cursor、GitHub Copilot、Windsurf）发现，专业开发者并不 vibe coding，而是通过规划和监督严格控制智能体。

Awaiting translation

Terminal-Bench 如何设计好的基准任务

Terminal-Bench 发布任务设计指南，提出好的基准任务应具备对抗性、难度和可读性：指令像给资深工程师那样清晰直接，测试只验证结果而非实现细节，允许替代解法并防止 reward hacking。难度应来自问题本身，而非苛刻的输出格式或隐藏假设。作者建议亲自运行任务、检查容器、执行 oracle 并观察真实智能体轨迹，失败运行尤其能揭示任务是否真正困难。

Awaiting translation

智能体时代的生产函数变了：实现不再稀缺，验证才是

作者认为，软件组织一直把人的实现时间当作稀缺投入，智能体打破了这个假设，因此策略必须可执行、验证必须随实现规模扩展。他以在大型 TypeScript 代码库开启 ESLint 的 no-await-in-loop 规则为例，发现 600 处违规，过去这需要昂贵的迁移，现在一个 PR 就能完成修复并补齐测试覆盖。

Awaiting translation

从 whenwords 到 Plumb：规范驱动开发三角如何保持同步

Drew Breunig 在 MLOps Community 的 Coding Agents 会议上分享了他构建无代码库 whenwords 的经验，并提出规范驱动开发不是单向方程而是三角反馈循环：写代码会反过来改进规范和测试。

Awaiting translation

Martin Fowler：软件工程循环中的人类与智能体，从 in the loop 到 on the loop

Martin Fowler 提出人类在 AI 辅助软件开发中应处于 on the loop 而非 in the loop，即构建和管理工作循环，而不是逐行检查智能体产出的代码。

Awaiting translation

Martin Fowler 谈 Harness Engineering：用约束换取 AI 代码可维护性

Martin Fowler 就 OpenAI 的 Harness engineering 实践发表初步思考，该团队以“完全不手写代码”为约束，用 AI 智能体维护一个超过 100 万行代码的产品，历时 5 个月。

Awaiting translation

Geoffrey Huntley 推荐智能体反向压力一文：用自动化反馈约束 Agent

Geoffrey Huntley 推荐 Moss 撰写的一篇关于智能体反向压力的文章，认为它值得关注 AI 上下文工程的人细读。文章的核心观点是，过去一年里表现最好的智能体应用，都在智能体周围搭建了结构，为它提供关于质量和正确性的自动化反馈，从而让它能承担更长周期的任务。

Awaiting translation

Harper Reed：AI 编程让瀑布模型变成 15 分钟一轮

Harper Reed 认为 AI 代码生成正把开发推向"15 分钟瀑布"：先写清规格、让模型生成、再审查，并可同时跑多个智能体分别写功能、文档和测试。他建议团队先用低风险内部项目做小范围试点、轮换成员参与，并把规格和架构文档沉淀到共享仓库。他还提醒 AI 容易过度测试基础逻辑，需频繁提交以便回滚。

Awaiting translation

如何应对编码助手不可靠的问题

Martin Fowler 针对编码助手不可靠带来的代码质量下降和浪费时间两类风险，提出一套评估建议可信度的自问清单：反馈回路是否够快、是否可靠、出错的影响范围有多大、是否需要很新的信息。

Awaiting translation

行内代码补全什么时候更有用

Martin Fowler 结合 Thoughtworks 内部使用 GitHub Copilot 的经验，分析行内代码生成在什么情况下更有用。他给出的有利条件包括技术栈更主流、问题更常见、生成片段更小、开发者更有经验、出错代价更低，并指出经验不足的开发者使用这类工具时任务耗时可能反而增加 7% 到 10%。他建议开发者花一段时间在安全区内外实验，逐步建立对工具适用边界的判断。

Awaiting translation

用三个 median 函数看 GitHub Copilot 辅助编码的能与不能

Martin Fowler 用 GitHub Copilot 生成 TypeScript 的 median 函数，Copilot 给出三个实现：第一个会修改输入数组，第二个用 slice() 复制后正确，第三个因忽略偶数长度而错误。他还让 Copilot Chat 先生成测试，测试覆盖了奇偶长度、负数与重复值，并让 ChatGPT 指出第三个实现的问题。

Awaiting translation