1. 先拆穿一个迷思AI编程助手提效的瓶颈从来不在模型过去半年我一直在帮团队里的前端同学调教各类AI编程助手发现了一个挺扎心的事实同样用Cursor、Claude Code、Codex这一档的工具有人能一天干完两天的活有人却觉得AI写出来的代码比手写还难改。区别根本不在模型聪明不聪明而在你有没有给模型一套稳定的上下文。最典型的场景是这样的我在重构一个老项目的数据请求层时让AI帮我封装请求方法。它连续给出了五个版本每一个都绕过了项目里已经跑了两年的统一拦截器。我当然可以用对话慢慢纠正但每次新开会话它又忘了。问题的根源不在于AI笨而在于我从来没告诉过它这个项目约定用拦截器、错误码要统一处理。这正是Rules要解决的事。前端的项目特点尤其考验这两样东西。组件多、目录复杂、样式方案不统一、状态管理各写各的AI生成的代码如果不符合项目风格融合成本会非常高。而Skills解决的是另一个问题当你不希望AI每次从零开始推导怎么写一个标准表单校验而是希望它直接调用一套已经被验证过的成熟打法时你需要把这种能力沉淀成可复用的技能模块。Rules和Skills说的直白点Rules是方向盘让AI始终沿着你划定的路线开Skills是工具箱让它在特定任务上拿出一套标准化的专业动作。两者配合起来前端AI编程助手才真正从话痨式问答变成项目里的熟练工。我的建议很简单先花一晚上把这两件事做起来比研究一百条提示词技巧都管用。接下来我就按自己的实操过程把Rules怎么立、Skills怎么做、踩过哪些坑一次性讲清楚。2. 立好Rules的四个层级别再把Rules写成万字文档2.1 全局Rules要管你的手而不是管项目的事很多人一上手就把项目里所有技术细节全部塞进Rules这其实是本末倒置。Rules也可以分全局和项目两个维度各自管的事完全不同。全局Rules维护的是你个人长期稳定的编码习惯。拿我自己的配置举例里面固定有一条除非用户主动要求否则不主动生成JSDoc注释通过清晰的函数命名表达意图。还有一条组件默认使用函数式写法避免Class Component。这些和某个具体项目无关但能保证AI在任何项目里产出的代码都贴合我的一贯风格。实操方式在Cursor里放到全局配置在Claude Code里放到用户级记忆文件。如果你用的是本地编程助手一类的工具也一定有类似的用户级规则入口。把个人偏好放这里的好处是换项目、换设备都无需重复配置。2.2 项目Rules要立决策点没必要复述文档到了项目层面常见错误就是COPY一整份几千行的技术方案文档进去。我一度也这么干过后果是AI开始过度遵守——连一个简单的状态更新都要强行套用复杂的reducer结构Reasoning变得僵硬代码远不如不设规则时灵活。正确的做法是把Rules集中在那些最容易产生分歧、最影响全局的决策上。我总结了一套前端项目Rules清单基本覆盖了大多数Vue/React项目的命门技术栈与构建工具明确核心栈如Vue 3 Vite TypeScript明确禁止使用哪些库比如样式统一用SCSS禁止引入Tailwind。目录结构约定比如页面对应src/views组件放src/components每个页面配套自己的样式文件。请求与数据流统一走src/utils/request.ts的axios实例错误码处理逻辑必须复用拦截器禁止在业务代码里到处写catch后手动弹错误提示。状态管理边界哪些数据进Pinia/Redux哪些数据用局部state要有一句话讲清楚否则AI经常会把只需要内部管理的数据上升到全局store。组件编码规范是否强推