我最近在用Claude Code搭个人网站。前前后后做了一周，功能全部跑通，编译通过，服务器正常运行。当时还蛮有成就感的。
作为一个又菜又爱卷的外行人士，能用AI写出一个完整的Web项目，觉得已经挺好了。
直到我装了一套配置，跑了一次代码审查，发现自己的挺好和真正的专业标准之间，差距比想象中大。
老金老师推荐的仓库
我最近在跟老金老师学Claude Code课程，他推荐了一个GitHub仓库叫everything-claude-code（简称ECC）。
作者Affaan Mustafa在2025年9月参加了Anthropic和Forum Ventures在纽约举办的黑客松，用Claude Code在8小时内构建了一个完整产品，拿了冠军和15000美元的API额度。之后他把10个月的日常使用经验，整理成了一套开源的Claude Code配置集。
我一开始以为这就是一个提示词合集。装上以后仔细看了看它的结构，发现没那么简单。
冠军的思路：给AI一套完整的工作环境
ECC的结构大概长这样：
.claude/
├── agents/ ← 15个专职代理（代码审查、安全审计、架构设计...）
├── skills/ ← 30多个技能定义（编码规范、后端模式、TDD流程...）
├── hooks/ ← 自动化钩子（编辑后自动格式化、提交前自动检查...）
├── commands/ ← 30多个快捷命令（/code-review、/build-fix、/tdd...）
└── rules/ ← 底层规则（代码风格、安全标准、测试要求...）
看起来只是文件分类，但仔细想想，它其实是一个分层的工作体系：
Rules是底层标准。 代码风格怎么写、安全底线在哪里、测试覆盖率要多少——这些是不随任务变化的基本原则。类似于一家公司的制度手册。
Agents是专职角色。 code-reviewer只管代码审查，security-reviewer只管安全审计，architect只管系统设计。每个代理只做一件事，但做得很专业 。这和Unix的设计哲学一样——小而专，组合使用。
Skills是工作流程。 比如TDD技能定义了"先写测试→跑失败→写实现→跑通过→重构"的完整流程。技能不是知识点，是"做事的方法"。
Hooks是自动检查。 编辑了Go文件？自动跑gofmt。编辑了TypeScript？自动跑类型检查。提交代码？先检查有没有console.log。这些检查不需要你记得去做，它们在后台自动发生。
Commands是快捷入口。 输入/code-review就启动审查流程，输入/tdd就进入测试驱动开发模式。降低了使用门槛。
这五层之间的关系是：Rules定义标准，Agents按标准执行，Skills提供流程，Hooks保证自动化，Commands方便触发。它们不是孤立的配置文件，而是一套互相配合的工作系统。
还有一个设计细节值得注意：ECC用了渐进式加载的方式管理技能。Claude的上下文窗口是有限的（200K token），如果把30多个技能的全部内容一次性塞进去，窗口会被迅速占满。所以ECC只把技能的元数据（名称和简短描述）放在系统提示里，Claude根据当前任务判断需要哪个技能，再动态加载完整内容。这样既保证了能力覆盖，又不浪费上下文空间。
这个设计让我意识到：冠军花10个月积累的，不是怎么跟AI说话的技巧，而是怎么给AI搭建一个完整工作环境的方法。
一次审查的结果
装好ECC后，我让它自己扫描了整个项目。
结果发现了4个CRITICAL级别的安全问题（输入验证缺失、无速率限制、无CSRF保护、密钥管理风险），2个HIGH级别问题（文件上传无限制、Markdown渲染XSS风险），外加若干代码质量问题。整体评分7/10——结构好，但安全加固严重缺失。
这些问题之前的Claude完全没提过。不是因为它检测不出来，而是我根本不知道应该给它一份该检查什么的清单。
我让Claude按优先级逐个修复。安装Zod做输入验证、添加rehype-sanitize防XSS、实现速率限制和CSRF保护、限制文件上传类型和大小。全部修复后TypeScript检查通过。
这件事给我的收获
第一个收获：配置不是设置，是在编码工作方法。
装ECC之前，我以为配置Claude Code就是写几个提示词、设几个参数。看完ECC的架构才明白，真正的配置是在回答代码质量的标准是什么？安全审查应该检查哪些维度？测试应该怎么做？出了问题应该怎么排查？
这些问题的答案，就是一个团队的专业经验。Affaan把自己的经验编码成了rules、agents、skills、hooks。装上这套配置，相当于你的Claude Code继承了一个资深开发者的工作习惯和审查标准。
第二个收获：AI的能力边界，很大程度上是由使用者划定的。
同一个模型，在我不装ECC的时候，它帮我写代码、调样式、搭后台，都做得不错。但它只做我让它做的事——我让它写代码，它就写代码，不会多想一步。装上ECC以后，它有了该主动检查什么的意识，因为agents和skills里已经写好了检查清单和工作流程。
模型的智力没变，变的是它的工作范围。这个范围是配置决定的。
第三个收获：这和上篇文章聊的Skills是同一个逻辑。
上一篇文章讲到MCP让AI能伸手操作外部系统，Skills让AI有了做事的方法论。ECC正好是这两层能力的一个完整实现。它的agents和skills就是在告诉AI你应该怎么工作，而不只是你能连接什么。
如果说MCP是基础设施，Skills是方法论，那ECC这类配置集就是实践范本——有人把方法论落地了，你可以直接用，也可以在它的基础上调整成适合自己的版本。
第四个收获：对非技术背景的人来说，配置可能比编程更重要。
我是一个跨学科的大学老师，不是程序员。我大概率不会自己从零写一套code-reviewer代理。但我可以装一套成熟的配置，理解它的逻辑，然后在使用中逐渐调整。这就像你不需要会造汽车，但你需要知道怎么调座椅、调后视镜、设导航——这些配置决定了你的驾驶体验。
配置AI这件事，本质上是在回答一个问题：你希望你的AI搭档，以什么样的专业标准来工作？这个问题的答案，就是你和AI之间真正的协作协议。
同一个Claude，裸跑和配好的，看到的东西完全不是一个量级。
如果你也在用Claude Code，评论区聊聊你的配置心得呀。觉得有用的话，顺手转发给还在"裸跑"的朋友们——毕竟，让好工具发挥真正实力这件事，值得被更多人知道。