一套超火的开发流程Skills:用工程纪律驯服你的编程Agent

Matt Pocock 大概是 TypeScript 社区里最广为人知的面孔之一了。他的 Total TypeScript 课程和 YouTube 频道帮无数开发者搞懂了类型系统。但最近他在 GitHub 上火起来的原因不太一样:他把自己日常使用的 AI Coding Agent 的 skills 集合开源了,仓库名叫 mattpocock/skills,短短时间就冲到 89K+ stars、7.8K forks,总安装量 140 万次。这些 skills 不是"帮我写个登录页"那种 prompt 模板,而是直接从他 .claude 目录里拿出来的、每天在用的一套工程化开发流程。

Pocock 这套 skills 的深层逻辑是:AI 不会取代软件工程的基本功,它只是把基本功的重要性放大了。需求分析、领域建模、测试策略、架构设计——这些在 AI 出现之前就存在的实践,现在不仅没有过时,反而因为开发速度的提升而变得更加关键。

他解决的四个核心问题,全部对应经典软件工程文献中的原则:

问题一:Agent 没有按你想要的方式做。 来自《程序员修炼之道》——"没人确切知道自己想要什么"。解法 /grill-me 的本质是把传统开发中靠开会、写 spec 来对齐的过程用 Agent 的盘问能力自动化了。

问题二:Agent 过于啰嗦。 来自《领域驱动设计》的"统一语言"概念——团队需要共享术语表。解法 /grill-with-docs 在项目中维护 CONTEXT.md,不仅让对话简洁,还让命名、文件结构、代码组织都围绕同一套语言展开。

问题三:代码不工作。 来自 Kent Beck 的极限编程——"反馈速度就是你的速度上限"。解法 /tdd + /diagnose 构建了写代码→验证→调试→修复的完整反馈闭环。

问题四:代码变成泥球。 来自 Ousterhout 的深模块理论——"最好的模块是深的,用简单的接口提供大量功能"。解法 /improve-codebase-architecture 给了 Agent 发现和修复架构问题的能力。

Pocock 做的事情,本质上是用一套可复用的指令模板,把几十年的工程纪律"焊"进了 Agent 的工作流里。如果你已经厌倦了"Agent 又写了一堆没法用的代码"的循环,这套 skills 值得花一个下午试试。效果怎么样,跑一次 /grill-with-docs 就清楚了。

四、FAQ

Q1:这些 skills 只能用于 Claude Code 吗?

不止。通过 skills.sh 平台安装后,支持 Claude Code、Codex、Cursor、GitHub Copilot、Windsurf 等主流 AI 编程 Agent。本质上 skill 就是 Markdown 指令文件,如果你的 Agent 支持读取本地文件作为上下文(大多数都支持),直接把 SKILL.md 的内容喂给它就行,不一定需要 skills.sh 这个中间层。

Q2:这和 Cursor Rules / .cursorrules 有什么区别?

思路相似但层次不同。Cursor Rules 是静态的全局或目录级规则("始终使用 Tailwind CSS"、"用 TypeScript 严格模式"),适合设定约束。Pocock 的 skills 是交互式工作流——/grill-with-docs 会主动盘问你、更新文档、创建 ADR,它是一个有状态的对话过程而不只是一段静态指令。两者可以共存:用 Cursor Rules 设定基础约束,用 skills 驱动具体开发流程。

Q3:18 个 skill,太多了。从哪个开始用?

最小启动路径只有三步:/setup-matt-pocock-skills(一次)→ /grill-with-docs(每次动手前)→ /tdd(写代码时)。这三个覆盖了需求对齐和编码质量的核心环节,已经能解决大部分"Agent 写了一堆废代码"的问题。其余 skills 等遇到具体场景再按需取用:bug 排查用 /diagnose,代码腐化了用 /improve-codebase-architecture,issue 太多用 /triage

Q4:CONTEXT.md 和 ADR 会不会让项目变得很重?

恰恰相反。CONTEXT.md 只存术语定义(比如"PartialRefund: 针对单个 LineItem 发起的退款"),不存实现细节。ADR 的创建门槛很高——必须同时满足"难以逆转 + 缺上下文很奇怪 + 真实权衡"三个条件才写。大多数日常决策不会触发 ADR。这两个文件的体积通常很小,但 Agent 读取后能大幅降低沟通成本。

Q5:我怎么自己写一个 skill?

目录结构非常简单:创建一个文件夹,里面放一个 SKILL.md 文件,顶部用 YAML frontmatter 写 namedescription,正文写工作流指令。可以参考 /write-a-skill 这个 skill 来引导创建,或者直接 fork 现有的 skill 改内容。skills.sh 平台支持发布你自己的 skill 集合。

Q6:团队里多人使用,会不会每个人的 CONTEXT.md 不一致?

CONTEXT.md 和 ADR 文件是提交到 Git 仓库里的,所以天然就是团队共享的。团队成员只需要 git pull 就能同步最新的术语表和架构决策。如果多人同时用 /grill-with-docs 修改了同一个文件,Git 合并冲突也很容易解决(纯 Markdown 文本)。

Q7:项目已经有 CLAUDE.md 了,会冲突吗?

不会。CONTEXT.md 是领域术语表,docs/adr/ 是架构决策记录,和 CLAUDE.md(通常是项目级别的 Agent 行为指令)是互补关系。你可以把这三个文件理解为:CLAUDE.md 告诉 Agent "怎么做",CONTEXT.md 告诉 Agent "说的是什么",ADR 告诉 Agent "为什么这么决定"。

参考资料

爽呆了,不费吹灰之力,我把scapy翻译成了Go语言

创建需求文档

1
❯ /prd 将 https://github.com/secdev/scapy port到Go语言,保持它的功能和便利性

PRD → Goal → After-Goal:AI 辅助全流程研发实践

想给大模型训推任务灵犀诊断平台增加「自我演化」的功能,尝试使用claude code的最新的/goal命令,记录从需求拆解到代码合入的完整流程,供同学参考。

最近两周codex、hermes相继发布/goal斜杠命令,这一周 claude code也不甘示弱,跨速发布了它的 /goal 斜杠命令。本文将/goal斜杠命令 + /prd技能 + /after-goal技能,实现了一个产品特性研发全自动化的流程,探索出一个AI+实践的新案例。

背景

01-背景

在百度内部研发场景中,一个功能从需求到上线通常经历:写 PRD → 拆卡片 → 写代码 → 提 CR → 合入 → 关卡片。这套流程环节多、工具分散(iCafe、iCode、Gerrit),每一步都要手动操作,容易遗漏步骤。

借助 Claude Code 的 Skill 机制,我们可以将这套流程固化成三个阶段,每个阶段对应一个 Slash Command:

阶段 命令 做什么
需求拆解 /prd 生成 PRD 文档,拆分为可实现的 iCafe 卡片

阅读全文

Goal, goal, goal! 三个智能体几乎同时推出的新功能

一个巧合,还是一个拐点?

2026 年 4 月底到 5 月中旬,AI 编程助手的赛道上发生了一件罕见的事:三家最活跃的智能体——OpenAI 的 Codex CLI、Anthropic 的 Claude Code、以及 Nous Research 的 Hermes Agent——在不到两周的时间窗口内,先后推出了各自的 /goal 斜杠命令。

这并非简单的功能追赶。/goal 背后代表的,是 AI 编程助手从"你问我答"的工具,走向"你定目标,我来完成"的自主智能体的关键一步。三家几乎同时落子,说明行业对这一方向的共识已经形成:持久化目标追踪 + 自主循环执行,将是下一代 AI Agent 的标配能力。

本文将从技术实现、设计哲学和行业趋势三个维度,拆解这三个 /goal 命令的异同,试图回答一个问题:当 AI 学会了自己"定目标、追目标、达目标",开发者的角色将如何改变?


一、OpenAI Codex CLI:最工程化的目标系统

发布时间:2026 年 4 月 30 日(Codex v0.128.0)

Codex 的 /goal 是三者中架构最精密的。OpenAI 用 5 个 PR、约 15,000 行代码,在 10 天内完成了整个实现。据 OpenAI CEO Greg Brockman 的描述,这是"built-in Ralph loop++"——把社区里流行的自主循环模式直接做进了产品。

阅读全文

软件又一次站在了十字路口——卡帕西的Software 3.0

软件又一次站在了十字路口。这一次,说话即编程。

旧程序员的消亡和新程序员的诞生

旧金山——2017年,一位名叫安德烈·卡帕西(Andrej Karpathy)的年轻人工智能研究员坐在特斯拉的办公室里,观察着一件奇怪的事情:他身边越来越多的代码不是人类写的,而是神经网络从数据中"学"出来的。他把这个发现写成了一篇文章,标题只有两个词——"Software 2.0"。

那篇文章后来成了硅谷被引用最多的技术论文之一。八年之后,卡帕西又来了。这一次,他在Y Combinator的AI创业学校登台,宣布了一个新的时代:Software 3.0

阅读全文

当 Karpathy 说"Wiki 能杀死 RAG",整个 AI 界花了五周时间证明他可能是对的

当 Karpathy 说"Wiki 能杀死 RAG",整个 AI 界花了五周时间证明他可能是对的

2026年4月4日,Andrej Karpathy 在 GitHub 上发布了一段不到3000字的文字。没有代码,没有论文,没有基准测试——只有一个想法。

五周之后,这段文字收获了超过5000颗 Star、5000次 Fork,以及评论区里660多条回复。十几个开源项目从中破土而出,一批创业公司以此为核心融资,YouTube 上出现了数十个深度解析视频,中文技术社区里"LLM Wiki"四个字的搜索量在一个月内翻了四十倍。

这一切发生得如此之快,以至于很多人还没来得及搞清楚一个问题:Karpathy 到底说了什么?


一个简单到令人不安的观察

Karpathy 的核心论点可以用一句话概括:RAG 是一种没有记忆的知识获取方式。

检索增强生成(Retrieval-Augmented Generation)是当前 AI 行业最主流的知识管理范式。它的原理很直接——你上传一堆文件,当你提问时,系统从文件中检索出相关片段,让大模型基于这些片段生成回答。NotebookLM、ChatGPT 文件上传、几乎所有的企业级 AI 知识库,都走这条路。

阅读全文

Codex CLI 最佳实践:从入门到精通

Codex CLI 最佳实践:从入门到精通

OpenAI Codex CLI 是一款运行在终端中的 AI 编程智能体,采用 Rust 编写,主打高性能与高度可配置性。但工具再强,用不好也是白搭。这篇文章不是参考文档——它是一份实战经验总结,告诉你怎么把 Codex 用出最大价值。


一、心态转变:别把 Codex 当一次性助手

这是最重要的一条。OpenAI 官方说得明白:当你不再将 Codex 视为一次性的助手,而是将其视为一个可以随着时间推移不断配置和改进的队友时,它的效果会最好。

具体来说,这条演进路径是这样的:

  1. 给正确的任务上下文 — 每次对话的基础
  2. 用 AGENTS.md 做长期指导 — 不再重复啰嗦
  3. 配置 Codex 匹配你的工作流 — 省去每次手动设置

阅读全文

我把 Karpathy 的 AutoResearch 搬到了软件开发领域,效果炸了-纽约时报风格

他把 Karpathy 的自动研究方法搬到了软件开发领域,然后离开了电脑

一位中国开发者借鉴人工智能先驱的思路,让多个 AI 智能体在无人监督的情况下自主完成代码编写、审核与合并。


撰文 / 2026年5月


三月的一个深夜,旧金山,Andrej Karpathy 在 GitHub 上发布了一个仅 600 行 Python 代码的项目。他没有召开新闻发布会,没有录制精心编排的产品演示,只在仓库里放了一份简洁的说明文档和一段不到十分钟的介绍视频。

阅读全文

Harness Engineering:当 AI Agent 变得足够强大,真正的工程才刚刚开始

Harness Engineering:当 AI Agent 变得足够强大,真正的工程才刚刚开始

2025年11月26日,Anthropic 的工程博客上发表了一篇文章。标题平淡得像一份内部备忘录:"Effective harnesses for long-running agents"。作者 Justin Young 没有宣布新产品,没有展示基准测试的飞跃,只是描述了一件事:如何让 Claude 在跨越多个上下文窗口的长时间任务中不崩溃。

三个月后,OpenAI 发布了自己的版本。他们的团队用三个工程师、零行手写代码,在五个月内构建了一个百万行代码的生产级产品。GitHub 上一个名为 awesome-harness-engineering 的资源库在几周内成为行业里被引用最频繁的文档之一。LangChain 发布了 Deep Agents——一个被明确定义为"agent harness"的开源运行时。Martin Fowler 的网站上出现了专题文章。36氪、知乎、腾讯云开发者社区的中文解析文章接踵而至。

他们都在讨论同一件事。

只是这件事,还没有一个公认的中文翻译。有人叫它"驾驭工程",有人叫它"约束工程",有人干脆不翻译,就叫 Harness Engineering。


一个反直觉的前提

Harness Engineering 的起点是一个令很多人不适的观察:你的 Agent 效果不好,可能不是模型的问题,是你的问题。

更准确地说,是你围绕模型搭建的那层基础设施——或者更准确地说,那层基础设施的缺失。

HumanLayer 的博客用了一个刻薄的标题:"Skill Issue: Harness Engineering for Coding Agents"。文章的核心论点是:大多数人对 AI Agent 的失望,本质上是一种 skill issue——不是模型的 skill,而是使用者的 skill。你没有给 Agent 足够的上下文,没有设置正确的约束,没有提供验证手段,没有建立反馈回路。Agent 失败了,你归咎于模型,但实际上是你的 harness 不够好。

阅读全文

别再用 TODO 管 AI Agent:多智能体协作需要一块真正的看板

别再用 TODO 管 AI Agent:多智能体协作需要一块真正的看板

如果你真的开始把 AI Agent 用进日常工作流,很快会发现一个问题:任务本身不一定难,难的是任务之间的协作能不能可观察可恢复可交接

传统 TODO 列表能记录“有什么事要做”,但很难回答两个更关键的问题:

  1. 这件事为什么卡住?
  2. 下游 Agent 接着做时,应该接收哪些上下文?

Hermes 的 Kanban 系统解决的正是这个问题。它不是把 Trello 或 Jira 简单搬进 Agent 世界,而是把看板变成一个多智能体任务中枢:任务会在 Triage、Todo、Ready、In progress、Blocked、Done 这些状态之间流转,父子依赖可以自动晋升,每次运行都有记录,完成任务时还可以留下结构化的 summary 和 metadata,供下游 Agent 继续使用。

阅读全文