Simon Willison 的 《Agentic Engineering Patterns》（智能体工程模式） 是一份面向软件工程师的实践指南，重点探讨在 Coding Agents（如 Claude Code、OpenAI Codex、Cursor 等能自主生成并执行代码、运行测试的智能体）普及的新时代，如何高效、高质量地进行软件开发。

一、 核心理念：什么是智能体工程？

Agentic Engineering（智能体工程） 明确区别于 Vibe Coding（氛围编程）：

• Vibe Coding：通常指非程序员完全依赖 LLM 编写代码，自己不看也不理解代码细节。
• Agentic Engineering：专业软件工程师通过 Coding Agent 来放大（Amplify）自身的专业技能。工程师依然担任架构师与质量把关人的角色，而将重复性、确定性的机械操作交给 Agent。

1. 观念重塑：“代码变得极其廉价”

传统软件工程的核心约束是代码编写成本昂贵（写几百行优质代码需要数小时或数天），因此衍生出了大量的预先设计、工时评估与严格的 YAGNI（You Aren't Gonna Need It）原则。 在 Agent 时代：

• 初始代码的生成成本趋近于 0。
• 优质代码的维护与理解成本依然存在。
• 如果不对 Agent 生成的代码进行严格审查和测试，廉价的代码会迅速演变成庞大的技术债务（Technical Debt）。

在 AI 辅助编程风靡的今天，许多开发者沉浸于 Vibe Coding（氛围感编码）——直接抛出几句自然语言需求，交由 AI 自动生成代码。然而，这种“野蛮生长”的方式往往会导致需求理解偏差、架构快速腐化（Ball of Mud）、上下文遗忘以及越改 Bug 越多的困境。

Matt Pocock 的开源项目 mattpocock/skills 正是为了解决这一痛点而生。它不是一堆零散的 Prompt 集合，而是一套为 Claude Code、Codex 等 AI 编程智能体设计的系统化软件工程最佳实践。

官方体系将技能划分为两大类：

1. User-Invoked（用户触发）：由开发者在终端中通过命令显式调用（如 /grill-with-docs、/to-spec），用于任务编排与流程推进。
2. Model-Invoked（模型自主调用）：由 AI 在执行具体任务时自行判断并调用的工程纪律规范（如 /tdd、/codebase-design）。

工作流全景链路 (The Engineering Harness)

核心开发主流程遵循着从“模糊想法”到“高质量交付”的递进逻辑：

HTML 版本

1. OpenSpec 是什么

OpenSpec 是一套规约驱动开发（Spec-Driven Development）的工作流工具。它要解决的问题是：在 AI 智能体参与编码的场景下，如何让"想清楚 → 写计划 → 写代码"这三个动作不互相污染，并且让代码之外还有一份可追溯的事实来源。

1.1 两种产物

产物	位置	回答的问题	生命周期
specs（规格）	openspec/specs/<capability>/spec.md	系统现在是什么行为（已交付、已归档的能力）	长期存在，随每次归档增量演进
changes（变更）	openspec/changes/<change-name>/	这一次要改什么（尚未实现的计划）	完成后整体移入 changes/archive/

一句话：specs/ 是唯一事实来源，changes/ 是待实现的增量，archive/ 是它是如何达成的历史。

关键差别在于 specs/ 是能力（capability）维度、changes/ 是变更维度。同一个能力会被多次变更反复修改，每次修改只写"增量"（delta），不重写整份规格。

1.2 五步循环

每个变更都走同一条闭环，本项目严格落在这条闭环上：

flowchart LR
    E["1 · Explore<br/>和智能体一起想清楚"] --> P["2 · Propose<br/>Agent 起草方案（不写代码）"]
    P --> R["3 · Review<br/>你修正方案"]
    R --> A["4 · Apply<br/>Agent 逐项构建"]
    A --> AR["5 · Archive<br/>增量写入 specs 并归档"]
    AR -. "下一次变更" .-> E

若渲染环境不支持 Mermaid，可读作线性流程：Explore → Propose → Rev

macOS 录屏视频压缩工具使用说明

本工具是一个专为 macOS 设计的自动化脚本，它能帮助您将录屏或大体积视频文件压缩为高兼容性、恒定帧率（60 FPS）的 MP4 格式，有效解决体积过大以及剪辑时的“音画不同步”问题。

该工具设计为通过 macOS 的“快速操作”或 Automator 工作流程来调用，从而实现便捷的视频压缩操作。

• 作为“快速操作”使用：
• 设置“快速操作”： 您需要将提供的脚本保存为 Automator 工作流程的“快速操作”。
• 打开 Automator 应用（在“应用程序” -> “实用工具”中）。
• 选择 “文件”>“新建”。
• 选择 “快速操作” 并点击“选取”。
• 在顶部设置中，将“工作流程收到当前”修改为 影片文件（或 文件或文件夹）。
• 在左侧的库中，搜索并拖动 “运行 Shell 脚本” 到右侧的工作流程区域。
• 在“运行 Shell 脚本”模块中，将“传递输入”设置为 “作为自变量”（至关重要，请勿选错）。
• 将本工具的完整 Bash 代码粘贴到“运行 Shell 脚本”的文本框中。
• 选择 “文件”>“存储”，为您的快速操作命名，例如 “压缩录屏视频”。

• 使用方法：
• 打开 Finder，导航到您要压缩的视频文件（如 .mov 或 .mp4）所在的文件夹。
• 选中您希望压缩的视频文件（支持单选或批量多选）。
• 右键点击选中的视频，在弹出的菜单中选择 “快捷动作”（或顶部的“服务”菜单）。
• 点击您刚才创建的快速操作名称 “压缩录屏视频”。
• 系统会弹窗或通知提示已开始处理，工具将自动完成转码，并将压缩后的新视频（文件名附带 _compressed.mp4 后缀）保存在原始视频所在的同一文件夹中。

Agent MD 规范

/Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked/resources/plugins/workbuddy-builtin/skills/expert-manager/references/agent-md-spec.md

Frontmatter

⚠️ 重要：frontmatter 中不可添加 tools 字段

所有工具权限由系统统一分配，开发者无需也不能在 frontmatter 中声明 tools 字段。

必填字段

---
name: {与文件名一致，必须有业务语义}
description: {英文描述，AI 用来判断何时激活}
displayName:
  en: "{English display name}"
  zh: "{中文显示名称}"
profession:
  en: "{English profession title}"
  zh: "{中文职业头衔}"
maxTurns: {默认50}
---

可选字段

skills: [{skill-name}]   # 启动时预加载的 Skill

正文结构：普通 Agent / 团员

专家的本质

专家不是模型，是一个本地目录形态的插件包——三层结构：

层	载体	作用
元数据层	.codebuddy-plugin/plugin.json	这是谁、属于哪类、怎么展示
人格层	agents/*.md	你是谁、怎么思考、怎么输出
能力层	skills/ bin/（可选）	专业技能与可执行脚本

能力高低 ≈ Agent MD 质量，专业性全是提示词工程 + 流程约束的产物。

专家 vs 专家团

只差一个 expertType 字段：agent（单角色）/ team（主理人 + N 成员）。专家团多了 teamInfo{leadAgent, memberAgents[]}、members[]（主理人也在里面，role=lead）、settings.json。

几个关键设计

1. 身份覆盖机制：专家模式用独立模板 user-context-expert-identity.tpl，只注入 USER.md，主动放弃 SOUL/IDENTITY 默认人格，把人格完全交给专家 MD。所以专家 MD 里是首尾双重身份锚定（开头 IDENTITY DIRECTIVE + 结尾 Final Reminder）。
2. 发现靠显式注册，不是自动扫描——必须写进 marketplace 根目录的 marketplace.json。
3. 团队不是"模拟多角色"，是真实子智能体调度：TeamCreate → spawn → SendMessage 回传 → 主理人汇编。5 条红线（禁代写、禁直连、禁跳阶段等）本质是对抗大模型一气呵成的抄近道本能——这点不做约束，多角色必然退化为单人分饰多角。
4. 唯一标识四绑定：name / agentName / 目录名 / MD 文件名，改任一即断裂。

目标：完整还原 WorkBuddy 中「专家（Expert）」与「专家团（Expert Team）」的定义方式，并给出可移植到自建智能体的落地方案。 所有结论均来自本机实际安装文件，路径可溯源。

0. 结论速览

原文：The AI-Native SDLC playbook（Anthropic Applied AI 团队） 译者注：本文为完整中文翻译，英文术语首次出现时保留原文。

代码不再是瓶颈

组织已经开始以一年前难以想象的速度用 AI 编写代码，但围绕代码的流程并没有以同样的速度改变。

许多工程团队仍然沿用同样的审批关卡、评审、交接和策略，这使得使用 Claude Code 等智能体编程解决方案带来的生产力提升被拖延抵消。

软件开发生命周期（SDLC）是将软件从想法带到生产环境的过程。大多数组织运行的都是同样六个阶段的某种版本，涵盖规划、设计、构建、测试、部署和维护软件。传统上，每个阶段都是一个由不同角色负责的独立阶段：产品经理写需求，技术架构师把需求变成设计，工程师按设计实现，受监管企业的 QA 团队进行验证，发布团队负责上线，运维团队监控运行状况。工作在阶段之间通过文档、工单和签字确认来流转。

传统的软件开发生命周期（SDLC）流程繁重，是为了确保每一步的责任与控制。然而，传统 SDLC 的设计初衷是在「编写和实现代码」这一最耗时、最昂贵阶段的年代最大化效率——而这个前提已经不复存在。PRD、估点仪式和产品安全评审，本质上都是为了在长达数周、数月甚至数个季度的开发过程中强制对齐。

传统 SDLC 的另一点是：它的各种控制措施假设每一步都由人来执行。

原文：Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl 作者：Birgitta Böckeler（Thoughtworks 杰出工程师、AI 辅助交付专家，拥有 20 多年软件开发、架构与技术领导经验） 本文是"Exploring Gen AI"系列的一部分。该系列记录了 Thoughtworks 技术专家对使用生成式 AI 技术进行软件开发的探索。

我一直在尝试理解 AI 编程领域最新的流行语之一：规约驱动开发（Spec-driven development，SDD）。我研究了三个自称 SDD 工具的产品，并试图厘清截至目前它到底意味着什么。

定义

与这个快节奏领域中许多新兴术语一样，"规约驱动开发"（SDD）的定义仍在变化之中。以下是我从目前见到的用法中归纳出的理解：规约驱动开发意味着在用 AI 编写代码之前先编写一份"规约"（"文档先行"）。这份规约成为人与 AI 共同的真理来源（source of truth）。

GitHub："在这个新世界中，维护软件意味着演进规约。［……］开发的通用语言上移到了更高层次，而代码只是最后一公里的实现手段。"

Tessl："一种开发方法，其中规约——而非代码——是

00 摘要：10 条核心论断

这份报告不是工具评测，也不是范式百科。它的目标是回答一个工程决策问题：如果你要在 2026 年把 AI 编程从「个人提效」推到「团队与生产系统」，你该采用哪套范式、按什么顺序、用什么门禁？ 下面 10 条论断是全篇骨架，只读这一页也能拿走结论。

1. 位移点不在「写代码」，而在「定义意图 + 验证结果」。 代码正在从「资产」降格为「构建产物」。当重写一段代码的成本趋近于零，真正稀缺的是「为什么这么做」的可追溯记录与「这样做对不对」的判定能力。
2. 瓶颈已从生成迁移到验证。 生成的边际成本在两年内下降了一个数量级，验证的边际成本几乎没动。所有有效范式（SDD 的可执行验收标准、multi-agent 的 verifier 角色、TDD-as-gate）本质上都在做同一件事：压缩单位验证成本，而不是让评审更严格。
3. 规范的复兴不是复古，而是因为规范第一次变得可执行。 1980 年代的需求文档会腐烂，因为它不驱动任何东西。2026 年的 spec.md 直接驱动生成器、被 Git 版本化、被 CI 校验——可执行，才第一次值得写。
4. AI 是放大器，不是均衡器。 DORA 2025（n≈5,000）的核心结论：AI 放大高绩效组织的优势，也放大挣扎组织的失能。平台质量、数据生态、价值流管理决定收益的正负号，工具选择只决定幅度。
5. 个体提速的证据显著弱于感知，且高度依赖任务与代码库。 METR 的 RCT（16 名资深开发者 / 246 个真实任务）显示用时增加 19%，而参与者事后仍自认为快了 20%。用「感觉更快」做投资决策是危险的。
6. AI 改变的是缺陷的「结构」，而不只是数量。 Apiiro 在 Fortune 50 仓库的观测：语法错误下降 76%、逻辑 bug 下降 60%，但权限提升路径上升 322%、架构设计缺陷上升 153%。旧门禁（SAST + 人工 diff）恰好对新增的这一类是盲的。
7. 多 Agent 是一个分布式系统问题，不是「多开几个窗口」。 隔离（git worktree / devbox）、编排（blueprint / workflow）、合并策略、可观测性四件套缺一不可；经验并行度上限在 3–5，超过后协调成本吃掉全部收益。
8. 上下文工程是 agentic 时代的内存管理，Harness 是新的性能杠杆。 Anthropic 归纳为「写 / 选 / 压 / 隔」四类策略；产业侧报告显示，同一模型换一套 harness，标准基准可差 3 个百分点以上。
9. 角色迁移是 Coder → Conductor → Orchestrator，但「可完全委托」仅 0–20%。 Anthropic 2026 趋势报告：约 60% 的工作流已含 AI，可完全委托的任务却不到两成。这是协作悖论，是稳态，不是过渡态。
10. 安全与治理必须内建在生成路径，而不是事后扫描。 AI 生成代码的漏洞率在不同口径下为 25.7%（522 样本 / 5 个 SAST）到 45%（100+ 模型 / 80 任务）；更棘手的是斯坦福实验发现的系统性过度自信——用 AI 的人写了更不安全的代码，却更相信它是安全的。