让 AI 工具更专业：全能编程 rules 能力集成
大模型层出不穷、版本日新月异，但绝大多数按通用方向训练。如果手头不是最顶级的模型，又想让它输出达到专业前端工程师/架构师水准，就要给模型"上锁"——用 rules 把专业约束固化进项目。这节从社区资源出发，提炼一套项目级前端 rules。
通用模型 vs 专业输出
通用大模型的训练目标是覆盖面，不是垂直深度。同样的需求，"通用输出"与"专业输出"的差距体现在：组件范式的选择、类型的设计、安全边界意识、测试用例的覆盖角度。想缩小差距，靠的不是换更强的模型，而是把专业程序员的判断固化为约束——这就是 rules（第3章讲过机制，本节落地到项目）。
rules 与 skills 的分工（一句话回顾）：rules 是约束，每次对话都加载，像门禁逐条生效；skill 是能力，模型按描述按需加载，不占常驻上下文。编程规范属于"每次写代码都必须遵守"的约束，所以走 rules。
社区资源版图
不用从零写。社区已有大量现成的规则合集，先看再提炼：
- everything-claude-code：Claude Code 配置全家桶合集（agents/skills/hooks/commands/rules），GitHub 10 万 star 量级的社区事实标准之一。其 rules 部分可按关键词检索——按开发环节（develop 等）找，也可按语言（TypeScript、Go、Python 等）找，覆盖代码规范、hooks、范式、安全、测试几大类
- awesome-claude-code：精选资源合集（配 awesomeclaude.ai 可视化目录），含 Anthropic 官方最佳实践与 CLAUDE.md 写法
- clauderules.net 等规则目录站：收录 120+ 社区维护的框架/语言 CLAUDE.md 规则（Next.js、React、TypeScript、Python、Go、Rust），开箱即复制
- 各类 "rules 2.0 / optimized" 合集：非常全面的 frontend rules，动辄几百行
来源标注：以上为 2026-10 检索所得，star 数与收录量随时间变化；引用前自行复核仓库现状。
两个极端的坑
直接搬社区资源会遇到两类问题：
坑一：全量照搬。几百行的 frontend rules 看着全面，但对具体项目的适配性差——里面一半的规则与你无关，噪声稀释了真正重要的约束，模型还要为无关规则付出注意力。
坑二：过于简单。有些规则只有一句话指引，模型每次都得现场去读对应的网页文档才能落实。在有了 Context7 这类文档 MCP 之后，"教模型去哪查文档"的规则价值大幅下降——这部分能力已经由工具层接管。但简单合集里的"最佳实践"条目仍然诱人，弃之可惜。
出路：不要二选一，让模型替你做取舍。
大杂烩提炼法
大杂烩正是大模型擅长的事。做法：
- 把多个规则源的链接/文本复制进对话：everything-claude-code 里按语言找到的 TypeScript rules、某个合集里看到的 develop 环节 rules、安全 rules、你欣赏的最佳实践段落——以及你自己的项目（标杆项目/团队文档/现有代码库）
- 附上关键提示词：
"从上面的这些项目和 rules 中，提炼适合于本项目的前端规则。我的要求是：覆盖面要全，同时要适配于本项目的技术栈；提炼的要精炼综合；从范式、代码风格、安全、测试、语言等角度来丰富这套 rules。输出到本项目的
.claude/rules/下，创建一个 frontend 的开发规则文件。"
- 模型自己做两件事：选择适合本项目技术栈的规则，剔除冗余与不适用项。这正是"覆盖面全"与"适配本项目"两个要求的调和过程——人来做这个取舍要逐条读几百行，模型几轮就能收敛
注意：部分社区链接需要外网访问，模型读取失败时提醒它使用本地代理工具；或预先把关键规则文本抓下来贴进对话，绕开网络依赖。
产出结构：对照真实仓库的 rules 目录
提炼结果落在 .claude/rules/ 下（真实仓库 ai-chat-ui 的最终形态，每个文件对应一个提炼角度）：
| 文件 | 角度 | 核心内容摘录 |
|---|---|---|
frontend-typescript.md | 语言 | 严格模式全程保持；禁 any（拿不准用 unknown+收窄）；导出类型=公共 API 从 core 统一导出；as 只用于有依据的收窄；异步一律 try-catch 且中断不算错误 |
frontend-vue.md | 范式 | 一律 Composition API + <script setup lang="ts">；状态只用 provide/inject + composable，不引入 Pinia；禁止直接改 props，双向绑定走 defineModel；v-for 禁用 index 作 key；SSR 兼容（document/window 包进 onMounted） |
frontend-security.md | 安全 | v-html 只渲染 DOMPurify 消毒后的内容且消毒在最后一次拼接之后；禁止 eval/new Function/javascript: URL；密钥只在宿主侧，库代码零密钥；URL 协议白名单（http(s)/blob:/data:image）；objectURL 用完 revoke；新增依赖先查漏洞（供应链） |
frontend-testing.md | 测试 | 测试放 __tests__/ 镜像 src 结构、不与源码混放；用例覆盖正常/边界/异常三场景；断言预期值必须独立于实现（防同义反复）；mock 边界只在 adapter/fetch/storage/timer；新测试必须先见过一次红灯 |
几个条目值得展开：
- 测试规范里的"正常/边界/异常"：前端组件设计最常漏的是异常场景与过渡场景——"过渡"本质也是边界（流式中途中断、上传一半失败、空列表到有数据的切换），把它显式写进 rules，模型的用例设计就有了完整框架
- Composition API 还是 Options API：官方已切向 Composition API（逻辑结构与逻辑复用更好），rules 默认锁定 Composition API；如果团队确实写不惯，在 rules 里改成按 Options API 输出即可——约束服务于团队，不是反过来
- TypeScript 的超集地位：无论写页面还是 Node 服务端，TS 都已是默认选项。主流前端运行时已原生支持 TS（或有多条直接运行 TS 的运行时/编译方案），不需要为此降级写 JS——模型也拿得到这些方案的最新信息
复用方式
这套产出有两种复用路径：
- 直接采用：把本项目的 rules 文件复制到你的项目，按技术栈微调
- 再提炼：告诉你的模型"基于上面这些 rules，根据我们的项目进行提炼/整改/融合"——模型非常善于做这件事，你的项目特征（框架版本、测试工具、部署形态）会被吸收进规则里
此后任何拿到这个项目的人（或任何模型），都在同一套约束下编码——这就是"拿到项目就自动专业"的含义。
小结
- 通用模型要输出专业代码，靠 rules 固化约束，不靠频繁换模型；rules（每次加载的约束）与 skills（按需加载的能力）分工明确
- 社区资源两个极端都有坑：几百行全量合则适配性差，过简合集依赖现场读文档（Context7 时代已无必要）
- 大杂烩提炼法：多规则源 + 自己的项目一起丢给模型，要求"覆盖面全 + 适配本项目技术栈 + 从范式/代码风格/安全/测试/语言角度提炼"，输出到
.claude/rules/ - 产出对照真实仓库四文件：frontend-typescript（语言）/ frontend-vue（范式）/ frontend-security（安全）/ frontend-testing（测试）
- 外网资源读取失败时用代理工具兜底，或预抓文本绕开网络依赖
本章组件能力建设到此完整：多模态输入与思考渲染、工具调用可视化、多会话与 mock 服务、vue-i18n 国际化、API 审查打磨、rules 工程化。下一章进入测试环节。
↑