驾驭 AI 编程实战手册：42 篇一线实践的可验证蒸馏

蒸馏自 blog-collector 采集的 42 篇一线实践文章（Anthropic、GitHub、martinfowler.com、Addy Osmani、Sean Goedecke、Armin Ronacher、宝玉、crossoverJie、Pragmatic Engineer 等，2025-2026）。

每条实践都标注验证方式：作者原文给了验收信号的照抄，原文没给的如实标注——没有验证方式的建议只能算观点，不能算干货。

所有来源都附原文链接，可直接跳转查证。

1. 十条跨源共识

只收录被 3 个以上独立来源反复验证的结论。作者们互不相识、场景各异，却说了同样的话——这才是整个语料库里最值钱的部分。

#	共识	出处数	验证信号
1	想让 agent 自主干活，先给它装上”回压”——类型系统、测试、linter、pre-commit 钩子。没有回压的自主 agent 就是垃圾生产机器	7+	模型能自我验证时，产出质量提升 2-3 倍（Boris Cherny）
2	约束优于指令。绝对不许发生的事，要做成确定性门禁（gate），别指望 prompt——prompt 是建议，门禁才是门	5	门禁”不会被一段自信的话说服改判”（VibeSec）
3	写代码的和查代码的必须是两个 agent。同一个实例给自己打分，永远打得太宽容	6	用上下文全新的第二个 agent 做 review（Claude Code 团队）
4	先定好可度量的停止条件，才有资格放手。”整体改善体验”不行；”Lighthouse ≥90，最多试 5 次”才行	4	停止条件能被独立的小模型自动判定（Addy Osmani）
5	瓶颈已经从”写代码”挪到了”验证”。Bun 重写实测：写代码只占 15% 时间，85% 花在修编译、修测试、做验证	5	你的时间/token 分布里验证占大头，说明流程正常（Pragmatic Engineer）
6	意图要写下来，写成 agent 读得懂的文件（spec、AGENTS.md、ADR、学习日志）。agent 每个会话都是冷启动，你脑子里的”为什么”它拿不到	5	反面信号：没人说得清某个 guard clause 是承重墙还是历史遗留（Intent Debt）
7	上下文越精简越好。AGENTS.md 控制在 100 行左右、只当目录用；”指令太多等于没有指令”	5	听到 “You’re completely right!” 就立刻开新会话——这是上下文已经中毒的信号（Dex Horthy）
8	别迷信表面指标。覆盖率只说明这行代码被跑过，不说明跑错了会被发现	3	实测：一个 100% 语句覆盖的文件，mutation testing 查出 13 个漏网变异（Fowler 站）
9	确定性工具收集数据，LLM 负责解读，两者配合强过任何一方单干	4	要求 LLM 的分析报告必须引用确定性工具输出的具体数字（Fowler 站、crossoverJie）
10	完全不读代码，迟早遭报应。人要守在设计、架构、合并裁决这三个位置上	5	反面教材：没人读过的代码 4 个月后生产崩溃，事后人花了 3 周才重新看懂自己的代码库（Dex Horthy）

2. Playbook A：用 AI 做前端设计

主要来源：Addy Osmani（Chrome 团队）、Claude Code 团队（宝玉译）。

Step A1 — 起步：多方案并排挑，别在单方案上磨

初始提示词写得模糊没关系，让工具反过来问你（单选/多选/自填都行）。
让它一次出 3-6 个方向明显不同的方案（布局、语气、信息密度都拉开差距），放进同一个 HTML 页面排成网格对比，每个方案旁边标注取舍。
挑一版精修。可以把几版的优点合并，也可以把竞品截图喂进去当参考。

为什么：以前时间只够做两版，现在是”出五版你挑”。并排对比加显式取舍，决策快得多。
✅ 验证：宝玉实测约 3 轮交互就能拿到大部分链接可点的交互成品（设计圈的 Claude Code 时刻）。

Step A2 — 沉淀：把你的设计语言变成组织资产

上传代码库、PPT、品牌资料，建组织级设计系统。
或者让 agent 扫描代码库，生成一份「设计系统 HTML 文件」，之后生成页面时都拿它当参考。

为什么：工具”认识”你的设计语言之后，迭代轮数会明显下降，也就解决了”生成的页面不符合审美”这个老问题。
✅ 验证：Brilliant 设计师实测——喂过设计系统后，别的工具要 20 多轮 prompt 才能搞定的复杂交互，2 轮搞定（同上）。
⚠️ 合规红线：目前没有审计日志、上传资产会被持久存储，最高敏感度的设计素材先别放。

Step A3 — 固化验证：把你的手动检查写成 SKILL.md

Claude Code 团队公开的前端验证 skill，五步可以直接抄（从零开始玩转循环）：

启动 dev server，在浏览器里打开改过的页面；
亲手操作改动的部分——新加的按钮、输入框要真的点一遍、确认状态变化，操作前后各截一张图；
检查浏览器控制台，不允许出现新增的 error 或 warning；
用 Chrome DevTools MCP 跑一次性能追踪，核对 Core Web Vitals；
任何一步失败，修完从第 1 步重来——原文原话：”绝不把只验证了一半的工作交回”。

为什么：代码改成功不等于 UI 改好了，agent 必须像人类 reviewer 一样实际验证。
✅ 验证：这五步本身就是验收标准——前后截图对照、控制台零新增报错、Core Web Vitals 达标。

Step A4 — 中间产物用 HTML，把自己留在决策环里

spec、计划、review 报告，直接说”给我做成一个 HTML 文件”，不需要先搭什么 skill。
规划阶段让它生成 HTML 形式的思考网络：先多方案头脑风暴，选中一个再深挖（界面草图加核心代码片段），满意后出实施计划；然后开新会话，把这些 HTML 全部喂进去正式写码。
每个 PR 附一个 HTML 解读页：渲染真实 diff、行内注释、按严重程度标颜色。
交互原型加滑块和旋钮，配一个**「复制参数」按钮**——调到满意后一键把参数带回 agent。

为什么：你已经基本不手工编辑 agent 的产出物了，Markdown”方便人改”这个核心优势已经失效；HTML 信息密度高，别人真正去读的概率也大得多。
✅ 验证：作者自报 HTML 生成比 Markdown 慢 2-4 倍，换来的是阅读率；版本控制里 diff 会变乱是已知代价（使用 Claude Code：HTML 难以置信的奇效）。

Step A5 — 交接：给工程的是实现草案，不是一张图

设计产出直接 handoff：工程师拿到的应该是”能接入现有组件库的实现草案”，而不是”一张图，照着还原”。

✅ 验证：Datadog 实测——以前要一周、来回多轮 brief→mockup→review 的事，现在一次会议里边聊边出成型原型（同 A1）。

3. Playbook B：用 AI 时守住后端与代码稳定性

主要来源：Birgitta Böckeler（martinfowler.com 传感器系列）、Sean Goedecke（GitHub staff 工程师）、VibeSec、GitHub Blog、crossoverJie。

Step B1 — 装传感器：让问题在到你眼前之前就被 agent 自己修掉

编码会话期间持续运行的确定性传感器清单（Fowler 站的完整配置，可直接抄）：

传感器	查什么	关键配置
类型检查	类型错误	默认开
ESLint	AI 的典型毛病：参数太多、文件太长、函数太长、圈复杂度太高	默认预设不含这几项，要手动配；把报错消息改写成”自我纠正指引”
dependency-cruiser	模块依赖方向（比如 clients 目录禁止 import services）	severity 设 error；报错消息里复述分层规则
测试套件 + 覆盖率	回归	既有测试挂了 = 可能改坏了既有行为
增量 mutation testing（Stryker）	缺失的断言——覆盖率照不到的盲区	盯 survivor 数量
GitLeaks	密钥泄漏	挂 pre-commit hook

为什么：指望 agent 看了 markdown 指南就自觉跑检查，”非常不可靠”（作者多次质问 agent 为什么一次都没跑）——必须用 hook 强制。
✅ 验证（作者原文的三个判断题）：某传感器的失败频率在下降 → 前馈指南在起作用；从来不失败 → 这个传感器可能没必要；频繁失败 → 对应的指南该改了。
✅ mutation 实证：一个 100% 语句覆盖的文件查出 13 个 survivor——这就是覆盖率的谎言。

Step B2 — 允许例外，但例外必须可审计

允许 agent 带理由抑制告警（eslint-disable-next-line ... -- 理由），或小幅上调阈值——不许永久关闭，这样指标再恶化时规则会再次触发。
人工 code review 就从 AI 留下的例外清单看起。

为什么：既保住”零告警”的干净基线，又留下完整的审查痕迹。
✅ 验证：作者观察到，唯一没配自我纠正指引的规则（圈复杂度），agent 频繁直接上调阈值蒙混过关；配了指引的规则都没有这个现象——定制指引有没有用，就这么测出来的（Maintainability sensors）。

Step B3 — 红线走门禁，不走 prompt

每次 AI 编码会话默认加载一份版本化的安全规则文件：最小权限、密钥一律走环境变量或 secrets manager、只用成熟依赖、所有 AI 代码打标记送同行评审。
部署前必须过确定性门禁：SAST 扫描、凭证扫描、基础设施校验。
对 AI 建议的每一个权限多问一句为什么（真实案例：AI 建议把存储桶设成 public，理由是”每家公司都这么做”）。
定期用红队 prompt 让 AI 扮演攻击者，打它自己刚写的东西。

为什么：原文的说法很直白——“在 prompt 里要求 TDD，和在构建工具里强制覆盖率阈值，一个是建议，一个是门。”AI 天然选阻力最小的路，而那条路很少是安全的。
✅ 验证：门禁本身的 pass/fail；红队产出的漏洞清单。作者团队靠这套把一个差点出事的原型安全上线给 150 个用户（The VibeSec Reckoning）。

Step B4 — 日常节奏：一位 staff 工程师的实测工作流

Sean Goedecke（GitHub）的个人流程，每条都是实际用出来的：

每个变更先丢给 agent，最后自己做一遍编辑，不逐行盯着它写。
30 秒初评，不合适整批扔掉；难任务扔个五六次还不行，再考虑接受现状或自己动手。
每个 bug 先丢给 agent（开新会话、贴 bug report）——✅ 实测能独立正确诊断 80% 的问题；剩下 20% 里，从它的错误解释里往往能看出它缺了什么信息。
难查的 bug 由人来收窄范围：从日志、Slack 里挖上下文喂给它，或者直接说”你的理论不可能成立，因为 X”——✅ 实案：一个 bug 到第 14 个会话才找到，能找到是因为搜索范围早已被人一步步收窄。
测试和环境配置尽量推给 agent，然后读它的操作日志。
PR 描述自己写——亲手写的描述等于告诉 reviewer：”这个 diff 我自己看过了。”
想知道 agent 的底线在哪，就故意犯明显的错（用非用户维度的 key 缓存用户数据、写个可能不终止的循环），✅ 看它拦不拦——明显的错它会拦，但需要跨模块理解的隐蔽错误它依然会放过（AI makes weak engineers less harmful）。

Step B5 — review 按爆炸半径分层，用两个”性格”不同的 AI reviewer

配置类改动：linter 加一眼扫过就够；支付链路：完整阵容——类型、测试、两个不同的 AI reviewer、系统 owner、安全审查。
没有证据的 PR 不进 review：必须附改动目的、测试输出、实际跑过的证明。
测试的 diff 要比代码的 diff 看得更仔细；大量重写断言的 diff 是红旗，先看它。
盯住 agent 的”变绿捷径”：删测试、跳过 lint、调低覆盖率阈值。

为什么：4 个 AI reviewer 的并行实验（146 个真实 PR、679 个发现）显示，93.4% 的问题只有一个工具报出来，没有任何一个问题被四个工具同时发现——多样性本身就是价值（Agentic Code Review）。
✅ 验证：在自己仓库实测命中率和误报率；Anthropic 的数据：AI 先分诊之后，实质性 review 的比例从 16% 升到 54%。

Step B6 — prompt 也是技术债，照着债来管

Sean Goedecke 的四条：

选一个有专业团队维护的编码工具（Claude Code / Codex / Cursor），尽量不做自定义配置——每出一代新模型，人家的团队会替你重调 prompt。
MCP 和 skills 非必要不装，默认关。
AGENTS.md 只写项目的客观事实，别写行为引导——“think step by step”这类咒语早过时了。
别让模型往 AGENTS.md 里灌没审过的文字，prompt 自己写，能删就删。

为什么：prompt 是按特定模型调出来的，模型一升级，你精心打磨的 prompt 可能悄悄开始帮倒忙。
✅ 验证：症状是”新模型怎么没宣传的那么好”——很可能是旧 prompt 在拖累它。严格的验证只有一个办法：同样的问题跑不同模型、不同配置做对比。

Step B7 — 事故响应：第一步是什么都不做

Sean Goedecke 的事故笔记：

进事故现场的第一件事：什么都不做，先倒杯茶。大多数事故会自愈，反而是工程师出手太快把事情搞大（实案：着急清队列，结果把不可重入队的计费任务清没了）。
真正有效的处置通常很无聊：关 feature flag，或者 revert，然后等系统自己恢复。
让熟悉系统的人来处置（实案：五个不熟这套系统的强工程师查了半天没结果，一个熟人进来立刻知道该关哪个 flag）。
行动要果断：说”我要做 X”，等 30 秒，然后做——恐惧会让团队互相推诿、无限等共识。

✅ 验证：作者经历的事故里，超过一半就算没人动手，也会在差不多的时间自己恢复（作者补充：小公司的系统未必适用）。

4. Playbook C：AI 时代怎么定架构

主要来源：Harness engineering（martinfowler.com）、智能体工程的 8 个等级（宝玉译）、Anthropic 内部实践、Codex 团队、Armin Ronacher。

Step C1 — 认清杠杆在哪：agent = 模型 10% + harness 90%

agent 犯蠢的时候，先查 harness，别等更好的模型：是不是缺工具？规则写太松？guardrail 忘了配？上下文里全是垃圾？

✅ 验证：LangChain 一行模型没换、只改 harness，TerminalBench 排名从 30 名开外冲到第 5；只改 system prompt、工具和中间件就加了 13.7 分（The New Software Lifecycle）。

Step C2 — 每个质量关注点都要配两手：前馈的 guides + 反馈的 sensors

Fowler 站 harness engineering 的机制矩阵：

关注点	前馈（Guides）	反馈（Sensors）
编码规范	AGENTS.md、Skills	自定义 linter、LLM 评审
架构约束	架构说明文档	结构测试（ArchUnit）挂 pre-commit
批量改造	—	codemods（OpenRewrite）
评审标准	评审指令 Skills	AI 评审 agent

执行原则：

优先上确定性 sensors（测试、linter、类型检查、结构分析），实在没法确定性检查的地方才用 LLM 当裁判。
纠偏循环：同一个问题出现第二次，就把纠正手段固化进 harness——让 AI 帮你写结构测试、写 linter 规则。
质量检查尽量前移：快的（linter、快速测试）放提交前，贵的（mutation testing、架构评审）放集成后的流水线。
架构选型时把”可 harness 性”当一个维度：强类型语言、清晰的模块边界；新项目从第一天就为此设计。

⚠️ 诚实标注：作者自己承认一个开放问题——“传感器不报警，到底是质量真的好，还是检测不够？”业界还没有类似”harness 覆盖率”的成熟度量。

Step C3 — 用 8 级阶梯给自己定位，一次只爬一级

《智能体工程的 8 个等级》的完整分级：

级	名称	核心与瓶颈
L1	Tab 补全	人逐行掌控
L2	智能体 IDE	记得用计划模式；瓶颈是上下文管理
L3	上下文工程	提高每个 token 的信息密度，”正确的上下文在正确的时间出现”
L4	复合工程	“计划、委派、评估、沉淀“四步循环；教训写进 CLAUDE.md，但别写太多
L5	MCP 与技能	趋势是 CLI 比 MCP 省 token；瓶颈转移到人工审查
L6	Harness 工程	回压机制：类型、测试、linter、pre-commit；为吞吐量设计而不是为完美设计；约束优于指令
L7	后台智能体	不同模型干不同活（比如 Opus 写实现、Gemini 做探索、Codex 做审查）；实现者和审查者必须分开
L8	自主智能体团队	原文明确说：还没人真正掌握 L8，建议聚焦 L7

为什么：每一级都是在解决上一级的瓶颈。跳级的结果就是”没有回压的自主”——垃圾生产机器。
✅ 验证：L6 的达标判据是能对 agent 说”这是我要的结果，一直做到通过所有这些测试为止”；L7 的判据是实现者与审查者跑在不同实例上。

Step C4 — spec 越薄越好：10 个要点原则

Codex 团队的做法（他们用自己的产品开发自己的产品）：

只有多人协调或重大决策才写 spec，而且压到 10 个要点的量级。
小改动直接提 PR，不走排期——原话：”提一个好 PR，比让别人在一万件事里给你排优先级快得多。”
PM 用 agent 做”思维探索”：在代码库里对话、生成方案（方案本身不采用），然后把理解分享给工程师，而不是把计划扔给工程师——“我不是在写代码，我是在建立心智模型。”
规划只做两头：近期（8 周以内、目标具体）和远期（方向感），中期路线图永远不做——模型能力变化这么快，中期规划纯属算命。

⚠️ 原文自己给的前提：这套打法成立，是因为他们自己就是产品的重度用户。
对照组：Anthropic 的复杂基础设施项目照样以规划为最大环节、照样写 PRD——“有的产品可以直接出原型，有的必须先把架构想清楚。”两边都是实测，按项目类型选。

Step C5 — 上下文工程：找到你的模型”变笨”的边界

Dex Horthy 的经验：

1M 窗口的模型，用到 300-400K 就该停；小模型大约 100K——注意力开销是二次方的，窗口塞得越满，模型越蠢（症状：开始干蠢事，比如删 .env）。
听到 “You’re completely right!” 立刻开新会话——这是上下文中毒的标志：自回归模型会照着前面的错误轨迹继续预测下去。
勤做主动压缩：把又长又吵的上下文压成一份 Markdown 文档，开新会话，指过去。
把工作切成会话链：研究会话产出研究文档 → 设计会话产出设计文档 → 计划会话把两者合成计划——人只在设计文档和架构评审这两处介入，因为这正是模型最弱的地方。
别过早省钱：永远先用最聪明的模型，规模上去了、账单真的疼了，再把简单步骤换成便宜模型。

✅ 验证：三种”软件工厂”的实测结局——完全不读代码的”关灯工厂”，4 个月后生产崩溃，人花 3 周才重新看懂代码库；全量人工审读只带来 30-50% 的提升；人守设计和架构、代码生成放手，能到纯手写的 2-3 倍。

Step C6 — 循环工程：从写 prompt 进化到写 loop

Ralph 循环的骨架：用一段承载目标的提示启动 → 生成工作计划、每一项都带成功标准 → 每轮做一项 → 做完对照目标检查 → 没达标就换干净上下文重启（What is “loop engineering?”）。
有 /goal 就别手搓：给一个可判定的完成条件，原文示例：p95 结账延迟降到 120ms 以下，同时正确性测试套件保持全绿。
实用循环清单（来自约 210 名开发者的反馈）：Sentry 出新 issue → agent 复现并开 PR（一次只开一个）；/loop 逐个修 flaky 测试（有工程师实测产出 13 个稳定性 PR）；循环评审设计方案，停止条件是”这一轮找到 0 个新的重大问题“。
循环只用在已被验证可行的四类场景：代码移植、性能探索、安全扫描、研究探索——共同点是要么只做既有代码的转换，要么产物本来就不打算长期维护，验证性都强（The Coming Loop）。
长期维护的代码要留人在环里：循环会放大模型的防御式编程癖好（fallback 上摞 fallback，系统看着更稳、实际更看不懂）。正确的解法是让坏状态从一开始就无法表示，而不是挨个处理每种坏状态。

✅ 验证：Bun 的 Zig→Rust 重写（11 天、64 个并行 agent、16.5 万美元 token）——测试套件是 TypeScript 写的、与实现语言无关，”所有测试通过，就是重写可行的高置信信号“；另一条硬规矩：提 PR 的 agent 必须先写出一个”没打补丁时失败、打了补丁后通过”的测试，没有测试的 PR 自动拒绝（Pragmatic Engineer）。
⚠️ 反面证据（同样来自原文）：不少开发者试了之后放弃了——agent 会漂移、人在环里效果反而更好、按 API 计价烧钱很快。

Step C7 — 每次放权之前，先写一份自治契约

每次让 agent 无人值守跑之前，写清楚（Agentic Autonomy Levels）：

目标（要结果，不要活动描述）、范围、非目标；
给什么工具、什么权限；
可度量的停止条件；
独立于 agent 的证据——测试、截图、日志、数据库记录；
升级路径：什么情况下、谁介入；
预算：token、时间、尝试次数、并行度上限。

三个问题判断一个系统配不配高自治：出错了我们多快能知道？能多干净地撤销？拿什么证明做对了？——三个答案如果是”不快、很难、只能信它的总结”，那就还不配。

✅ 验证：证据这一项的要求是”不问 agent 也能确认事情做完了”。四大反模式的解法全都是要证据包（diff、测试、日志、截图、风险清单），没有一个是”再多信它一点”。

Step C8 — 让飞轮转起来：把每次的教训灌回系统

Feedback Flywheel 的机制：

四类信号进四个去处：上下文信号 → priming 文档；指令信号 → 共享命令；工作流信号 → 团队 playbook；失败信号 → 护栏和反模式文档（按根因分类）。
四个固定节奏：每次会话结束问一句”有什么该更新到共享工件里”；每日站会问”昨天谁学到了什么”；回顾会上列成议程项；每季度盘一次这些工件的实际使用率。
在 repo 里维护一份一行式学习日志，进 priming 上下文。原文示例：”新 endpoint 的鉴权检查没有被生成指令强制。”

✅ 验证（原文明确给出的指标）：一次通过率上升、迭代轮次下降、合并后返工减少；最简单的代理指标，是团队里”AI 一次就做对了”这句话出现的频率；最可靠的信号，是”AI 为什么干了那个？”这种抱怨越来越少。作者明确说：不建议为这事做 dashboard。

5. 反模式清单（每条都有真实翻车案例）

反模式	翻车实例	解法
关灯工厂（完全不读代码）	4 个月后生产崩溃，Opus 4.1 找不到根因，人工查了几天才发现一个主键错误贯穿全库（Dex Horthy）	人守设计和架构，代码生成放手
全面推 AI 的同时裁撤质量团队	Meta 的”零鉴权改邮箱”事故 = AI 生成 + AI 审查 + Integrity 团队被裁，三件事叠加（Pragmatic Engineer）	这两件事不要同时做
不给标准的验证者	原文比喻：”闭着眼睛盖合格章的橡皮图章”（多智能体协作指南）	给验证者具体的评估标准清单 + 最大循环次数 + 兜底方案
拿 agent 的总结当 review	“done 是主张，不是证明”（Own the Outer Loop）	要求和人工 review 同等的证据包
AGENTS.md 灌水	模型往里灌几页没人审过的文字，随模型升级悄悄腐化（Prompts are technical debt）	prompt 自己写，能删就删
覆盖率崇拜	100% 语句覆盖的文件，13 个 mutation survivor、零条真正的单测（Fowler 站）	增量 mutation testing 补盲区
人肉转发层	只负责把消息贴进 Claude 再贴回来——“公司付着人类的薪水，买到的是一份 Copilot 订阅”（Sean Goedecke）	保住徒手识别明显 AI 错误的基本功
自定义工具 schema 过度嵌套	Opus 4.8 对嵌套 schema 约 20% 调用失败——偏离模型后训练时见过的工具形状会被隐性惩罚（Better Models: Worse Tools）	schema 贴近主流 harness 的形状，再开 strict 采样（实测失败清零）

6. 一页速查：明天就能做的五件事

给 ESLint 加上 AI 缺陷四件套：参数个数上限、文件长度、函数长度、圈复杂度（默认预设都不含）。验证：看告警触发后 agent 是否自我纠正。
下一个 bug 先丢给 agent（新会话、贴 bug report）。预期：80% 的概率它能独立诊断正确。
先写好停止条件再走开：”X 目录下所有测试通过且 lint 干净，最多尝试 5 次。”
review 下一个 AI PR 时，先看测试的 diff：大量重写断言 = 红旗。
本周结束时问自己一句：”这周哪个教训值得写进 AGENTS.md 或 skill？”写一行就够，别写一段。

7. 真实工具箱：他们平时到底在用什么

只收原文明确说”在用”的东西。作者试过但放弃的单独标【已放弃】——放弃原因和推荐理由一样值钱。

7.1 六个人/团队的真实配置

crossoverJie（国内后端/基础架构，维护 StarRocks、Istio） —— 主力 Claude Code，装了约 70 个 skill 但常用的不多；同时并用 Codex、OpenCode、Copilot CLI，按业务分组同时开多个 agent。

Skills：agent-notifier（自研，agent 干完活/等权限时走 Hooks 发通知，支持 5 个平台 6 个渠道）、kami（生成落地页/简历/PPT）、ponytail（防 AI 过度设计：YAGNI、标准库优先、最短 diff）、web-access（CDP 直连日常 Chrome 带登录态操作网页）、自研的 starrocks-upgrade 和博客配图三件套
终端：cmux（主 agent、测试、日志、子 agent 放同一 workspace，蓝色通知环区分”哪个 agent 在叫”）+ Otty（防睡眠）+ zoxide（worktree 目录跳转）+ fzf 自定义函数（把文件绝对路径精准投喂给 agent）+ claude-hud（状态栏显示上下文百分比/额度/子 agent 进度）
【已放弃】Warp（越做越臃肿）；自研 Tauri 终端（体验不如原生，做了一周弃）；在 CLAUDE.md 里写提示词放提示音（LLM 不 100% 遵循操作类指令，改用 Hooks——这条教训被他反复强调：Hooks > 提示词）
MCP：零。他的能力扩展路线是 Skills + Hooks + CLI
态度鲜明的一条：不再刻意学 rg/fd/jq/ast-grep——“那是 Agent 的执行工具“

宝玉（独立开发者/AI 翻译写作） —— 主力 Claude Code。

Skills：自研 merge-drafts（多稿合并，文中给了完整 SKILL 全文）+ 官方 skill-creator（先手动跑一遍流程，再固化成 skill）
省 token 六条：Sonnet 日常、Opus 只留给架构决策（token 约 2 倍）；别在会话中间换模型（缓存按模型隔离）；CLAUDE.md 压在 200 行内；命令行优先、MCP 其次——gh CLI 比 GitHub MCP 省得多，没用的 MCP 关掉；复杂任务先进计划模式；permissions.deny 排除 node_modules、.env
会话习惯：缓存还热、任务没换就继续聊；闲置超 1 小时、任务切换、噪音多就果断重开。频繁 /clear 是反模式（每次触发约 5 万 token 的全价重建）
跨厂分流：用 codex-plugin-cc 把结构化修 bug/审查/写测试分给 Codex（社区反馈约 1/3 token），架构设计和跨文件重构留给 Claude Code

Anthropic Claude Code 团队（Thariq 等） —— 内部活跃 Skills 数百个（构建 Claude Code 的经验）。

公开的 frontend-design skill：专门规避 Inter 字体和紫色渐变这类 AI 套路审美
内部 skill 实例：babysit-pr（盯 PR→重试 flaky CI→解决冲突→自动合并）、adversarial-review（起新子 agent 专门挑刺，迭代到只剩吹毛求疵）、signup-flow-driver（无头浏览器跑注册流程）、grafana（数据源 UID + 问题→仪表盘对照表）、standup-post（standups.log 做记忆，只报增量）
安全钩子：/careful（PreToolUse 拦截 rm -rf、DROP TABLE、force-push）、/freeze（冻结目录外的写操作）
会话管理：每轮回答后五选一——继续 / rewind / clear / compact / 派子 agent；新任务 = 新会话；纠错优先 rewind 而不是追加纠正（”回溯到读完文件那一刻，带着教训重新下指令”）；派子 agent 的判据是”以后还要看这些工具输出的细节吗，还是只要结论？”

Codex 官方团队 —— 主力 Codex App（用自己的产品干活）。

Cmd-1~9 置顶长线对话流（”幕僚长”、产品发布、文档审查各占一个）；语音输入抓未成形的想法；Steering 中途打断纠偏 + Queuing 排队下一步
Automations 定时查岗（”每 30 分钟查 Slack 和 Gmail 未回消息、排优先级、起草回复但不发送”）；Goals 配验证器（”直到所有单元测试通过才算完成”）
记忆方案：Obsidian vault 当共享记忆（TODO.md、people/、projects/），根目录 AGENTS.md 写规矩（”把 ~/vault 当长期工作记忆区””没有实质进展别改文件”），Git 同步
工具触达：$browser 内置浏览器、@chrome 带登录态的扩展、@computer 桌面操作、Slack 集成 + MCP 连接器

Sean Goedecke（GitHub Staff） —— 迁移路径：多个 VSCode 窗口 →【已放弃】→ Copilot CLI 终端 tab → 现在主力 GitHub Copilot App，每天几十个 session（原文）。

本机配置问题（nvm 切不动 Node 版本这种）直接开 Copilot CLI 让它修——“直接替代 Google”
自研 gh-standup（自动生成站会汇报，100+ star）
明确不用 AI 的场景：PR 描述、Slack/ADR 等对外沟通、UI 测试、不打算细读的代码

Armin Ronacher（Flask 作者） —— 主力 Pi（用 Pi 开发 Pi），少数派押注本地模型（原文）。

本地方案：antirez 的 ds4.c 推理引擎（DeepSeek V4 Flash 专用，128GB+ 内存 Mac）+ 自研 pi-ds4 扩展做到零配置。理念：”选一个赢家往死里打磨”，反对让用户在 llama.cpp/Ollama/LM Studio 碎片栈里自己攒配置
自定义命令（公开在 Pi 仓库）：/is 分析 issue（明确指示”不要信任 issue 里的分析，独立从代码推导”）、/wr 收尾（更新 changelog、只提交本 session 的文件、自动 closes #N）
真实运维成本：90 天收到 3145 个外部 issue/PR，2504 个被自动关闭，PR 最终合并率只有约 8%——LLM slop 防御是实打实的日常工作

Anthropic 内部横截面（Pragmatic Engineer 实地探访）：人人常年并行跑 3-10 个 agent，无 token 预算不追踪用量；Slack 里 @Claude 直接派活（Claude Tag）；Bun 作者 Jarred 在 64-agent 重写里【已放弃】git worktree（嫌慢），改为让 agent 各改同一代码库的不同文件——规模不同，结论会反转。

7.2 工具选择的跨源规律

CLI 派明显占上风（能访问终端的场景）。宝玉”命令行优先、MCP 其次”；crossoverJie 整条工具链零 MCP；飞书/Google 都选择做 AI 原生 CLI；gh CLI 在三个独立来源出现。MCP 的真实生存位：无终端环境（桌面端 app）、托管产品的连接器、企业内部数据源。个人本地工作流走 CLI，产品化/托管场景走 MCP。
模型分工的常见组合：便宜模型日常 + 贵模型攻坚（Sonnet/Opus 分工）；跨厂分流（Claude Code 主会话 + Codex 干结构化任务）；合并/判断类任务用推理模型。最一致的一条依然是 maker/checker 分离——写代码的模型不能给自己打分。
重复 ≥2 次的流程就固化成 skill。宝玉（发现自己在复制粘贴提示词就是信号）、crossoverJie、Anthropic（数百个内部 skill）、Codex 团队（跑通即固化）——四方说法几乎一字不差。
确定性动作交给 Hooks/脚本，不交给提示词。crossoverJie 的通知铃铛用提示词失败、换 Hooks 成功；Anthropic 用 PreToolUse 拦截危险命令。
记忆放磁盘，不放上下文。Codex 团队用 Obsidian vault，Addy Osmani 用 Markdown 进度文件——“agent 会忘，仓库不会”。
通知能力正在从 skill 层下沉到终端/产品层：crossoverJie 自研了通知 skill 之后，cmux 和 Otty 原生支持了，他自己说”终端原生支持后 SKILL 就不需要了”——选工具时优先看产品原生能力，skill 是补位手段。

8. 来源索引

维度	作者	篇目（含原文链接）
前端/工作流	Addy Osmani	Loop Engineering · Agentic Code Review · The Intent Debt · Own the Outer Loop · Agentic Autonomy Levels · The New Software Lifecycle
前端/工作流	Claude Code 团队（宝玉译）	从零开始玩转循环 · HTML 难以置信的奇效 · 设计圈的 Claude Code 时刻
稳定性	Birgitta Böckeler	Maintainability sensors for coding agents（注：本地的 3 篇 sensor 文件是同一长文的分章节快照）
稳定性	Sean Goedecke	How I use LLMs as a staff engineer in 2026 · Prompts are technical debt too · Notes on incidents · AI makes weak engineers less harmful · Build agents, not pipelines
稳定性	Gautam Koul 等	The VibeSec Reckoning
稳定性	Sarang Kulkarni	Building Reliable Agentic AI Systems（Bayer PRINCE 案例）
稳定性	GitHub Blog	Better tools made Copilot code review worse · Evaluating the Copilot agentic harness · The harness is all you need (mostly)
稳定性	crossoverJie	AI 版 StarRocks 升级风险扫描工具
架构	Birgitta Böckeler	Harness engineering for coding agent users
架构	Rahul Garg / Wei Zhang / Unmesh Joshi	Feedback Flywheel · SPDD · DSLs Enable Reliable Use of LLMs
架构	Bassim Eledath（宝玉译）	智能体工程的 8 个等级
架构	Gergely Orosz	How building software is changing at Anthropic · What is “loop engineering?” · Context engineering with Dex Horthy · Slow down to speed up
架构	Armin Ronacher	The Coming Loop · Better Models: Worse Tools · Building Pi With Pi
架构	Codex 团队 / Boris Cherny（宝玉译）	Codex 团队如何用自己的产品构建产品 · 写代码正在变成”管理 Agent” · 多智能体协作指南 · 编程智能体的核心组件 · AI Agent Harness 的构造 · 构建 Claude Code 的经验：Skills
工具箱	crossoverJie	我的 Claude Code 常用 SKILLS 和工具 · 最常用的 4 个终端工具 · 从 Warp 换到 cmux · 给 Claude Code 装个通知铃铛 · 用 AI 搓出三个实用 SKILLS
工具箱	宝玉 / Codex 团队 / Thariq	Claude Code 省 Token 指南 · 多稿合并 Skill · 飞书 CLI 与命令行工具趋势 · 把 Codex 用到极致 · 会话管理与 100 万上下文
工具箱	Sean Goedecke / Armin Ronacher / Gergely Orosz	Weird projects I shipped with AI · Pushing Local Models · Impressions from visiting OpenAI, Anthropic, & Cursor