这份清单只收「有人真的跑过一遍」的文档：给出机制的工程博客、给出数字的落地报告、给出判断的实践者自述。 分两个栏目——技术大牛（个人实践者的方法论）与公司（团队级的生产化经验）， 均按公开发布时间降序，并按可复用程度给 1–5 星。
个人视角的价值在于「可模仿」：他们公开的是自己每天怎么开窗口、怎么写规则文件、在哪一步停下来人工看一眼。 以下 10 位作者都在生产环境里长期使用，而不是评测一次就写结论。
Simon Willison（Django 联合创造者）· Talking Postgres Ep 42；亦见其持续更新的《Agentic Engineering Patterns》
测试通过与「意图正确」是两件事。解释动作同时验证理解深度与意图保真，这是 agent 时代唯一低成本的双重校验。
bisect 定位回归、revert 救场、子 agent 只为省上下文而不为炫技Jarred Sumner（Bun 作者）· Rewriting Bun in Rust，Simon Willison 转述与拆解
「如何评审一个 +100 万行的 PR？」答案是：不要评审代码，要评审生成代码的流程。
Addy Osmani（前 Google Cloud AI Director）· The New Software Lifecycle，Google 白皮书配套长文
「把标准设在 eval，而不是 demo。」同一句话决定了你落在 vibe coding 还是 agentic engineering。
Andrej Karpathy · Sequoia AI Ascent 2026 对谈；概念首发于 2026.02.04 的 X 长帖
Agent 是「有尖刺的实体」：能力很强、随机性很高。工程的职责是把它放进有边界、有验证、有回滚的流程里。
Birgitta Böckeler（Thoughtworks Distinguished Engineer）· martinfowler.com
只有反馈没有引导，agent 会重复犯同样的错；只有引导没有反馈，agent 会把规则编码进去却永远不知道是否奏效。
Giles Edwards-Alexander（Thoughtworks EMEIA CTO）· An Accidental Blackboard
10 个工程师 4 天造出航司 IROps 系统。真正的发现不是速度，而是多个 agent 自发用 repo 里的 plan 文件完成了协同。
Mitchell Hashimoto（Vagrant / Terraform / Ghostty 作者）· My AI Adoption Journey
「我不打算跑多个 agent，也不想跑。」在一个人人比并行数的时期，这是最有信息量的反向样本。
AGENTS.md 每一行都对应一个历史失败案例Boris Cherny（Claude Code 创造者，前 Meta Principal Engineer）· How I Use Claude Code
「给 Claude 一个能验证自己工作的方式，最终质量会提升 2–3 倍。」其余 12 条都是这句话的配套。
CLAUDE.md，看到 Claude 做错就补一条——他称之为 Compounding Engineering（复利工程）/permissions 预授权代替 --dangerously-skip-permissionsBirgitta Böckeler（Thoughtworks）· martinfowler.com，Exploring Gen AI 系列
「上下文工程 = 策展模型看到的东西，以得到更好的结果。」所有配置最终都是一堆 markdown，区别只在加载时机。
Gene Kim & Steve Yegge· Vibe Coding: Building Production-Grade Software（IT Revolution）
写给组织而非个人：当模型写掉大部分代码，意图与心流比语法更重要，但质量纪律一条都不能少。
团队级文档的看点是「约束条件下的取舍」：几百万行遗留代码、支付级合规、移动端编译链、几千名工程师的治理。 2026 年的一条主线很清楚——瓶颈从「生成」移到了「验证」与「环境」。
Shopify Engineering· We gave AI agents a mobile dev environment
「把工作交出去的能力，已经超过了把工作跑起来的能力。」瓶颈不在模型，在机器与可观测性。
Meta Engineering· Forum 应用的 AI 原生工程实践
「弱信号不会消除约束，它只是把约束从写代码移到评审那些看起来完成、其实没有的代码上。」
Uber Engineering· Running a Software Factory Efficiently at Uber Scale（AI Engineer 2026）
70% 以上的 PR 由 agent 产出之后，真正难的不是生成代码，而是把每次会话的成本逐项归因。
Anthropic Engineering· Best practices for Claude Code（持续更新）
几乎所有最佳实践都源于同一个约束：上下文窗口会很快填满，而填满后性能下降。
/goal 条件 → Stop hook 确定性闸门 → 换模型做第二意见（干活的不许给自己打分）Ctrl+G 可直接改计划）→ Implement → CommitAnthropic· How Anthropic teams use Claude Code
最有价值的是「任务分类直觉」：产品边缘的抽象任务可异步放养，核心业务逻辑必须同步盯着改。
Google Developers Blog· Driving the Agent Quality Flywheel from Your Coding Agent
「优化器永远不给自己的工作打分」——一个看似小的架构选择，决定了你是在改进 agent 还是在刷指标。
Google Cloud· Behind the scenes: How we build, test, and scale Google Agent Skills
一个写得含糊的 skill 会拖垮整个 agent 体验，所以「谁能发布」必须有一道自动化的门。
Google / Flutter 团队· AI makes it easy to migrate. Flutter makes it easy to scale.
并行的 agent 会引入「非确定性漂移」：两边单测都过，三周后线上转化率掉 3%，因为重试时机行为不同。
Airbnb Engineering· Enzyme → React Testing Library 大规模迁移
成功的驱动不是更强的模型，而是「每个文件都必须过 Jest + lint + tsc」这道闸门——agent 无权宣布自己完成。
Microsoft· Introducing Command Line, and the new rules for builders（Build 2026）
「代码是一次性的。」当代码可弃，评审就可以毫不留情，spec 反而成了那个耐久产物。
Google· Addy Osmani / Shubham Saboo / Sokratis Kartakis，50 页免费白皮书
「你的主要产出不是代码，而是生产代码的那个系统。」这是全篇最该被记住的一句。
Cloudflare Blog· Orchestrating AI Code Review at scale
「把所有 diff 塞进一个万能 prompt」必然产出噪音——幻觉语法错误、给已有错误处理的函数提「建议加错误处理」。
Ryan Lopopolo（OpenAI）· Harness engineering: leveraging Codex in an agent-first world
「人掌舵，agent 执行。」5 个月、3→7 人、约 100 万行代码、1,500 个 PR、零行手写代码。
AGENTS.md，都由 Codex 自己生成docs/，做渐进式披露；另设 doc-gardening agent 定期扫过时文档Stripe· Minions: Stripe's one-shot, end-to-end coding agents（Part 1 / Part 2）
「对人好用的工具，对 LLM 也好用。」Minions 没有独立基建，直接跑在工程师日常用的 devbox 上。
腾讯技术工程· 经媒体报道转述
「把 AI 当打字员用，天花板很低；把 AI 当施工队用，才有真正的效率革命。」
阿里 ATH 事业部· Experts Mode，经报道转述
按需求临时组建「AI 工程专家团」——后端、前端、测试、审查员各在独立上下文里并行。
字节跳动· 企业版 SOLO 模式 +《2026 企业级 AI 编程实践手册》，经报道转述
把内部「用 TRAE 开发 TRAE」的经验沉淀成方法论——这条自举路径本身比数字更有参考价值。
只收「描述了怎么做、而不只是宣布做了什么」的文档：必须包含机制、约束或度量中的至少两项。 纯产品发布稿、纯评测对比、纯观点社媒帖不入表。
日期为原文公开发布时间。其中数条仅能确证到年或半年（标注为斜体），按已知区间就近归位， 不影响主题排序的正确性。
AGENTS.md 改成「每条对应一个真实失败案例」，而不是抄一份通用规范