第 1 章：四个失败模式
出处
来源：README.md · 状态：已读
一句话
Agent 加速的不是工程，是工程里那四种老失败：没对齐、没共用一套词、没有反馈、设计每天在烂。 这套 skill 不是新方法论，是把《程序员修炼之道》、DDD、XP、Ousterhout 已经写过的纪律，收成可调用的小件。
核心概念
四种失败，一层一层叠
Matt 在 README 里按观察顺序排，不是按插件清单排：
| # | 你看见的 | 真正碎掉的假设 | 修法 |
|---|---|---|---|
| 1 | Agent 没做我想要的 | 双方已经知道要什么 | 追问（grilling） |
| 2 | Agent 话太多 | 丢进项目就能学会黑话 | 共享语言（CONTEXT.md） |
| 3 | 代码不能跑 | 对齐了就会写对 | 反馈环（测试先行、诊断） |
| 4 | 建成一团泥 | 写得快不等于设计在变好 | 每天护住深度 |
顺序是验收顺序。第 3 章的词、第 4 章的规格，都建立在第 2 章的追问上。跳到第 4 个失败去「重构架构」，而第 1 个还没钉住，调查报告会推荐一套你并不同意的形状。
#1 没对齐，不是模型笨
"No-one knows exactly what they want"
David Thomas & Andrew Hunt, The Pragmatic Programmer
最常见的失败不是幻觉，是错位。你以为它懂了；看到产物才发现它从头就走偏。人与人之间早就这样；模型只是把反馈周期从「下周演示」压到「三分钟后的 diff」。
修法不是把 prompt 写得更长，而是让 agent 追着你问，直到设计树上每一枝都被走过。入口是 /grill-me（没有仓库）和 /grill-with-docs（有仓库，边问边写文档）。Matt 的口径：每次要改东西都用。机制在 02-grilling与对齐。
#2 话多，是因为没有项目自己的词
With a ubiquitous language, conversations among developers and expressions of the code are all derived from the same domain model.
Eric Evans, Domain-Driven Design
Agent 被空降进仓库，边做边猜黑话，于是 20 个词说一件事。Matt 自己的例子：course-video-manager 里，「课程某节被落到文件系统」收成一个词 materialization cascade。之后会话、变量名、文件名都走这个词。
共享语言不只是少说话：
- 变量、函数、文件按同一套词命名
- agent 更好找路
- 思考也更省 token，因为语言更短
这套能力嵌在 /grill-with-docs 里，不是另开一门课。Matt 说这可能是仓库里最酷的手法。机制在 03-共享语言。
#3 对齐了，代码照样是垃圾
"Always take small, deliberate steps. The rate of feedback is your speed limit."
The Pragmatic Programmer
对齐解决「做对的事」。第 3 个失败是「把事做对」：没有反馈，agent 在飞盲。需要的还是那一批环：静态类型、浏览器、自动测试。自动测试里，红-绿循环给的是稳定的反馈水平，不是「多写几个测试文件」。
两件配套的工具：/tdd 把红-绿收成纪律；/diagnosing-bugs 把难 bug 收成按阶段上锁的循环——没有已经跑红过的命令，不准猜。机制在 05-反馈环。
#4 泥球是速度的利息
"Invest in the design of the system every day."
Kent Beck, Extreme Programming Explained
"The best modules are deep. They allow a lot of functionality to be accessed through a simple interface."
John Ousterhout, A Philosophy of Software Design
Agent 让编码变快，也让熵变快。Matt 所谓「激进」的修法，其实是一句很旧的话：在乎代码长什么样。它嵌在每一层：/to-spec 写规格前先问你动哪些模块；/improve-codebase-architecture 每隔几天扫一遍，找出能加深的候选。它是调查，不是救援：真老的仓库它能找到候选，不会替你拆泥球。机制在 06-设计与深模块。
人打的入口，模型去拿的纪律
四个失败对应的不是四个文件，是两类调用权：
- 人打的负责编排，不会自己开火
- 模型去拿的负责纪律，任务对得上就会被拉进来
grill-with-docs 的 SKILL.md 只有一行，去调 grilling + domain-modeling。薄入口是组合点：追问的算法只写在一处，有仓库没仓库两套包装去用它。入口写厚了，第 2 章和第 3 章会各写一份「怎么问」。
对照 07-Skills：Cookbooks 说 skill 是按需三级展开的程序性知识。Matt 这套把同一原则用在过程上——人只看见入口的名字，纪律正文在任务对得上时才加载。
关键洞察
- 四种失败不是并列菜单。 没对齐就上测试，测试会把错的规格钉死；没共用一套词就写规格，规格里全是「account」这种三个意思的词。
- 引用全是 20 年前的书。 这是立场：基础比以往更要紧，因为 agent 把「不纪律」的后果放大了。新东西是把纪律收成可调用的小件，不是发明第四种敏捷。
- 「每次改都追问」听上去贵，其实是在买第 4 章的规格。 追问会话是一次决定的主键；规格是它活过窗口清空的副本。
个人思考
和仓库里已有判断对得上：Anthropic：The AI-native SDLC playbook 说代码不再是瓶颈、人守闸门；Warp：How Warp builds self-improving agents on Claude 说 agent 变好靠现场反馈沉淀进 skill。Matt 把闸门和沉淀收成一条更硬的话——过程也可以是 skill，而且必须小、可改、可组合。GSD / Spec-Kit 那种「接管全过程」的框架，失败时你连修哪一步都不知道。
下一章把第 1 个失败拆开：追问到底在问什么，一轮里问哪些，谁来找事实。