AI 写代码越快，项目失控也可能越快。真正的问题不是模型会不会生成函数，而是它是否理解需求、是否遵守团队语言、是否能在已有架构里小步推进。如果把 AI 当成“随便说一句就自动完工”的代码喷射器，最后很容易得到一堆跑不通、难维护、没人敢改的代码。
Matt Pocock 开源的 mattpocock/skills 仓库，正好给了一个相反方向的示例：不要让 AI 接管整个开发流程，而是把 AI 放进成熟的软件工程约束里。
项目地址：https://github.com/mattpocock/skills
这套方法的重点不是某个神奇 prompt，而是一组可以组合的 agent skills。它们把需求澄清、领域建模、测试驱动、问题诊断、架构审查这些老派工程实践，重新包装成适合 AI 编程工具调用的工作流。
先解决对齐失败
AI 编程最常见的失败，是你以为它懂了，其实它只是顺着你的模糊描述开始猜。
grill-me 的思路就是反过来：在写代码之前，先让 AI 变成一个会追问的审稿人。它不会立刻开始实现，而是持续追问计划里的分支、边界和未决问题。
比如你说“做一个登录页”，它应该先问：
- 忘记密码怎么处理？
- 是否支持第三方登录？
- 登录失败时要显示什么错误？
- 账号锁定、验证码、风控是否在本期范围内？
- 成功后跳转到哪里？
这一步看起来慢，但它减少的是后面返工的时间。AI 生成代码的成本越低，需求没想清楚带来的浪费就越大。
把领域语言写进上下文
第二个问题是 AI 的“通用词汇病”。它不了解团队内部的业务叫法，只能用常见词来猜，于是变量名、函数名、文档描述都开始漂移。
grill-with-docs 解决的是这个问题。它不只是追问需求，还会结合项目里的 CONTEXT.md、ADR 或领域文档，检查用户表达是否和既有术语冲突。确认后的术语、边界和决策，可以继续沉淀回上下文文档。
这和领域驱动设计里的“统一语言”很接近。假设团队把 user 称为 customer，把 order 称为 transaction，那么 AI 在写代码时也应该继承这些叫法，而不是自己再发明一套。
上下文文档的价值不在于堆资料，而在于让 AI 少猜一点。
用 TDD 限制生成速度
AI 的危险之处在于它太快了。过去写出一大段坏代码需要时间，现在几秒钟就能生成几百行。速度本身不是问题，缺少反馈循环才是问题。
tdd skill 把经典的红绿重构流程放回 AI 编程里：
- 先为一个行为写失败测试。
- 再实现刚好让测试通过的代码。
- 然后重构。
- 按垂直切片继续推进。
重点是“一次一个行为”，而不是让 AI 一口气写完所有测试和所有实现。这样做可以把任务切小，也能让每一步都有可验证结果。AI 负责执行，人类负责确认方向和边界。
用诊断循环处理复杂问题
遇到 bug 时，很多 AI 会直接猜答案，然后连续改几轮，把问题越修越乱。
diagnose 的价值在于要求 AI 先建立反馈循环：
- 复现问题
- 最小化场景
- 提出假设
- 增加观测或日志
- 修复
- 补回归测试
这套流程不新，但在 AI 编程里尤其重要。因为 AI 很擅长快速尝试，却不一定擅长判断哪次尝试真正接近根因。诊断流程相当于给它加了一条轨道。
定期审查架构，而不是只看单个任务
单次任务跑通，不代表代码库变好了。AI 反复提交小改动后，最容易出现的问题是模块边界变模糊、接口越来越复杂、测试越来越难写。
improve-codebase-architecture 这类 skill 的意义，是让 AI 定期跳出当前任务，从更高层看代码库：
- 哪些模块职责开始混在一起？
- 哪些接口太复杂？
- 哪些路径难以测试？
- 哪些命名和领域语言不一致？
- 哪些重复逻辑应该收敛？
这不是让 AI 自动大重构，而是让它先给出结构化观察和改进方向。真正要不要改、改到什么程度，仍然需要开发者判断。
真正该限制的是自由度
这套方法论的核心可以压缩成一句话：AI 编程不是放任模型自由发挥，而是给它清晰的目标、上下文、测试和停止条件。
人类更适合负责问题定义、架构边界、业务取舍和验收标准；AI 更适合负责代码生成、测试补全、重复修改和局部重构。两者配合得好，AI 是放大器；配合得不好，它会把混乱也一起放大。
所以，软件工程基础没有因为 AI 变强而过时。恰恰相反，需求澄清、领域语言、TDD、诊断、架构审查这些能力，在 AI 时代变得更关键。
会写代码的人会越来越多。真正拉开差距的，是谁能把 AI 放进可维护、可验证、可长期演进的工程体系里。