AI 写得越快，我反而越不安心
AI 写代码越来越快。
但在用它做完 loomet 的 MVP 后，我却越来越不敢让它继续改。
不是因为它不会写。
恰恰相反，它太会写了。
我提出一个新功能，它很快给出实现。不对，就继续调整；这里改一点，那里补一点，直到页面看起来可以用了。
功能出来了。
可我开始回答不了一些很基本的问题：
这次修改碰了哪些模块？
它为什么选择现在的实现方式？
功能的边界到底在哪里？
有没有引入新的 Bug？
最后，我应该依据什么验收？
AI 每次都在继续往前跑。
而我对项目的理解，好像慢慢落在了后面。
AI 写得越快，就越需要一套能让人停下来检查的流程。
AI 交付越来越快，我却开始追不上项目
loomet 是我做的一个串珠项目。
做 MVP 时，我和 AI 的合作方式非常直接：
我想一个功能，让 AI 实现。
AI 写完，我看结果。
不符合预期，就继续让它改。
如果目标只是快速把产品从 0 做到 1，这种方式没有什么问题。先做出来，先上线，再慢慢调整。
但是上线只是另一个开始。
MVP 完成以后，loomet 进入真正的功能迭代。每一次修改，都建立在前面很多次修改之上。
需求在变，代码在变，项目内部的关系也在变。
这个时候，“页面能用”已经不能代表功能真的做完了。
它可能遗漏了某个边界，也可能改变了原来的行为。更麻烦的是，我甚至不知道应该从哪里检查。
以前遇到这种情况，我会继续在对话框里追加一句：
“还是不对，再改一下。”
AI 当然会继续改。
但是每多改一次，项目离我脑子里的理解就更远一点。
最危险的状态，不是报错，而是“看起来正确”
一个明确的报错，反而没有那么可怕。
至少我知道它坏了。
真正让我不安的，是一个功能看起来能用，我却无法确认它是否真的正确。
它有没有改到不应该改的地方？
有没有破坏原来的功能？
这次实现，和最初的需求还是同一件事吗？
我后来才意识到，真正让我不安的不是 Bug。
Bug 总会出现。
让我不安的是：我没有判断它是否正确的依据。
我把所有开发动作，都混成了一句 Prompt
我曾经以为，换一个更强的模型，或者把 Prompt 写得更详细，问题就能解决。
后来发现，好像不是。
我把需求分析、方案设计、写代码、调试和验收，全都塞进了同一句：
“帮我实现这个功能。”
AI 只能一边猜我的需求，一边猜项目边界，再一边完成代码。
当最后结果不符合预期，我也很难判断：到底是需求没说清楚、方案选错了，还是实现本身出了问题。
所有问题混在一起，最后都变成“再试一次”。
这不是 AI 独有的问题。
换成一个真实的开发团队，如果产品、设计、开发和测试全都不分阶段，只靠一句话往前推进，项目一样会失控。
只是 AI 写得更快，也把这种混乱放大得更快。
AI 放大的不只有我的想法，也有我原来混乱的工作方式。
Skills 没有接管项目，它给每一步加了检查点
后来我开始使用 mattpocock/skills。
它不是一个让 AI 突然变聪明的超级 Prompt，而是一组可以组合使用的工程工作流。
Agent Skills 的形式其实很轻：一个 Skill 至少包含一份 SKILL.md，也可以附带脚本、参考资料和模板。任务匹配时，AI 才会读取对应的工作说明。
我更愿意把它理解成一套给 AI 准备的工作手册。
不同的问题，使用不同的手册。
我一开始甚至想过：能不能让这套 Skills 全盘接管 loomet 后续的迭代？
真正用下来，我发现“接管”不是重点。
它带给我的安心，恰恰来自我没有交出控制权。
每一个 Skill，都在回答一个原来让我不安的问题：
如果连方案是否可行都不确定，我会先用 prototype 做一次性验证，不急着把试验代码放进正式项目。
我要去哪里？
边界是什么？
为什么这样做？
现在做到哪里？
最后如何确认？
过程被拆开以后，这些问题终于有了各自的位置。
问题没有消失，但它们终于有了入口
我不想说，用了这套 Skills 以后，AI 就不会再写出 Bug。
没有这种事。
它也没有神奇地一次生成正确答案。
真正发生变化的，是我的反馈回路。
过去，我只能等 AI 写完，再根据页面结果反复调整。
现在，我可以在写代码之前确认边界，在实现过程中保留决策，在完成以后按照规格、测试和 Review 验收。
需求不清楚，就回到需求。
方案不确定，就先做原型。
功能偏离规格，就回到 Review。
出现 Bug，就先复现，再判断原因。
问题没有消失。
但它们不再全部挤在一句“还是不对”里面。
因为安心从来不是“保证不会出错”。
安心是出错以后，我知道从哪里开始。
PR 不再只是一段代码，而是一条可以回看的路径
以前和 AI 的很多开发过程，都留在一段越来越长的对话里。
功能做完，代码合并，对话也就慢慢失去了价值。
现在，我能留下的直接证据是 PR。
一条 PR 不应该只证明代码已经合并。
它还应该让我看见：
这个需求为什么出现？
实现之前明确了什么边界？
代码如何对应规格？
Review 发现了什么？
最后又是怎么完成验收的？
〔发布前补充一条真实 PR：标题；实现前明确的边界；implement 或 code-review 发现的问题；最后使用的测试、截图或人工验收路径。〕
有了这些记录，后来的我不需要重新翻完所有聊天，也不用猜当时为什么这样实现。
它是一条可以回看的路径。
一个人开发，流程不是官僚主义
独立开发者很容易跳过流程。
因为需求是我提的，代码是 AI 写的，验收也是我自己做。好像没有必要再写规格、拆 Ticket、做 Review。
但是一个人开发，不代表这些角色消失了。
只是所有角色都落在了同一个人身上。
当 AI 把写代码的速度拉得非常快，我更需要一个系统，帮我保存那些来不及一直记在脑子里的东西：项目边界、需求决定、任务上下文和验收标准。
流程不是为了让项目看起来专业。
它是我的外部记忆，也是我继续修改项目的底气。
如果你也开始不敢让 AI 改项目
不需要马上安装几十个 Skills。
先观察项目里最让你不安心的那个环节：
- 需求总是反复，就先做需求对齐；
- Bug 总靠猜，就先建立可重复的调试反馈回路；
- 功能做完无法验收，就先补规格和 Review；
- 一次迭代大到 AI 记不住，就先画一张跨会话的地图。
从一个真实问题开始，为它选择一个 Skill。
慢慢把藏在脑子里的开发经验，变成 AI 能够执行、自己能够检查的系统。
以前使用 AI，我更关心它一次能够完成多少功能。
现在我更关心另一件事：
当项目不断变化时，我还能不能看懂它、控制它，并确认每一次修改。
AI 依然写得很快。
它依然会犯错。
但我不再只能盯着它生成的结果，猜它到底做了什么。
需求变化时，我知道去哪里找决定。
功能完成时，我知道依据什么验收。
出现 Bug 时，我知道应该先建立怎样的反馈回路。
AI 没有替代我。
它帮我更快地实现想法，也逼着我重新看见自己的开发方式。
而这套 Skills 做的事情，是把那些原本藏在经验里的判断，慢慢变成清晰、可重复、可以检查的步骤。
这种感觉，是安心。
就够了。
如何开始
根据仓库目前的 README，在 Codex 和其他 Agent 中可以使用：
npx skills@latest add mattpocock/skills选择需要的 Skills，并包含 setup-matt-pocock-skills。安装后，在每个项目中运行一次设置流程，确定 Issue Tracker、标签和文档保存位置。