Skills 和插件：先跑通人工流程，再自动化

我曾经一次性安装很多 MCP 和插件，结果工具列表变得很长，授权请求变多，真正做任务时反而不知道应该调用哪个。后来我给自己定了一条规则：**没有手动重复三次的流程，暂时不自动化。**
MCP 适合连接外部系统，让 Codex 获取聊天框和仓库之外的实时信息。例如读取设计稿、查看错误监控、查询工单或访问内部知识库。它解决的是“上下文在哪里”的问题。
Skill 适合封装重复方法。它把触发条件、步骤、输入输出和必要脚本放在一起，让以后不必反复粘贴长提示词。它解决的是“这件事应该怎么稳定地做”的问题。
插件通常把 Skills、MCP 和相关能力打包，适合安装一整套与某个服务或工作流有关的能力。它解决的是“如何更方便地分发和启用一组能力”的问题。
判断是否值得接入，可以问三个问题：数据是否在项目外；数据是否经常变化；这个连接能否省掉持续复制粘贴。如果三个答案都是否，普通文件和提示词已经够用。
对新手最合理的升级顺序是：先完成一个纯本地项目；再写好 `AGENTS.md`；然后把重复出现的审查或发布流程做成一个 Skill；最后只接入一个真正需要的外部工具。能力是一层层长出来的，不是一次堆出来的。

我踩过的 10 个坑，以及更直接的修正方式
在错误目录启动。修正：启动后第一件事查看工作目录和文件清单。
一句话要求完成大型项目。修正：先定义最小闭环，把大目标拆成每轮可验收的任务。
没有 Git 检查点。修正：任务前提交一次，完成后查看 diff，再决定是否保留。
只描述想要什么，不说不能改什么。修正：明确依赖、接口、目录和数据安全边界。
把“运行成功”当成“需求完成”。修正：用用户动作写验收清单，运行测试只是证据之一。
发现 Bug 后让它大规模重构。修正：先要求根因分析，再做最小修改，最后补回归检查。
一开始就给全盘权限。修正：只读探索，工作区执行，高风险动作单独确认。
把所有规则塞进每次提示词。修正：长期规则写入 `AGENTS.md`，重复流程做成 Skill。
同一个长会话处理不相关任务。修正：一个会话对应一个连贯目标，过长就整理并压缩，分叉就新开。
相信最终总结，不看实际差异。修正：查看修改文件、命令输出、测试结果和 Git diff。Agent 的自述不是证据，执行记录才是。