项目概览#

这个是用 curosr 基于对商详前端应用的理解，画的一个 svg （因为 curosr 是不支持画图）格式的图片。

整体上还是大概的描述出了项目的情况，包括项目结构，技术选型，以及一些子 package 的作用。但是整体的图片在细节上有非常多的问题，文字超出、重叠、对齐问题等，多次要求 ai 修改也不行，这就是在一个合理的能效比下 ai 能做出的最佳效果了，还凑合吧。

cursor 编辑器本身的一些实践#

指定具体的模型#

不要使用 auto 模式，关掉然后指定 claude-4 ，目前测试下效果是不错的。如果使用默认的 auto 模型，那么回答质量是非常不稳定的。

curosr rule 实践#

十句话让 cursor 提升 10 倍的编程水平（玩笑）

提升基本回答质量#

这个是之前忘了在哪里看到的一篇文章中提到的 cursor rule riper-5，实践以后觉得不错，就一直在用。

整体的指导流程如下：

实际使用的时候发现， Ai 对于这个指令的正向流程的跟随做的是很好的，但是在对于所有的逆向流程比如发现偏差或问题回到上一步这种流程，我实际使用下来的就没有遇到过它走到过这里。他每次都是非常的自信，给出的最终 review 都是 完美，很棒之类的对于自己的正向反馈；没有一次能够自己发现自己的问题，即使是很智障的问题，它自己也发现不了，所以还是少不了人为干预；
- 比如这个例子，他的回答看着质量非常高，图文并茂，看着好像很专业的样子，但是实际上它自己画的图片里面包含的功能比如 totolPrice 的计算、quantity 的计算等相关逻辑全部都没有，所以不能被表象骗到了；

但整体的实践以后，在日常的功能开发中能还是大幅提升回答质量的，而且即使有的时候不能帮你把代码写了，但是思考过程以及给出的多个参考方案，还是可以借鉴的；

但是对于过于简单的需求，可能回答过程太冗长了，等于绕了大半天路来解决一个可能一开始就能给出最佳答案的情况；

代码重构 review#

代码重构审查 rule

技术重构代码审查指南（Git Diff）

我是前端开发工程师，我有一份 Git
Diff 想让你审查。请你遵循以下技术检查清单，仔细检查并提供详尽的分析报告：

检查清单

一、代码组织与结构调整

判断是否仅是代码组织、架构、命名层面的调整，具体表现包括但不限于：

函数、方法或变量的名称调整
文件或目录结构的变更（如拆分或合并文件）
逻辑拆分或组合到不同函数或文件，但输入、输出、流程不变
增加或改进注释，不涉及逻辑变动
删除废弃代码，不影响现有流程

二、业务逻辑潜在变更

请细致检查改动是否影响业务逻辑或功能，包括但不限于以下情况：

输入参数的类型、数量、默认值是否发生变化
函数或方法返回值类型或结构是否改变
控制流（如条件判断、循环结构）是否发生逻辑上的变化
数据处理、计算方法或关键算法是否有调整
异步调用、API 请求或依赖外部服务逻辑是否发生变动
状态管理、缓存或数据存储逻辑是否有变化
新增或删除了业务关键函数、方法、接口或外部依赖

输出格式要求

请以以下格式输出你的审查报告：

概要结论

明确说明本次改动整体是否可能对现有业务逻辑造成影响。

仅组织、架构类改动

列出所有确认仅为结构、组织上的调整。

疑似影响业务逻辑的改动

明确指出代码改动位置（文件名、行数、函数或变量名）。
详细描述改动的性质（如参数、返回值、逻辑变化）。
评估可能带来的影响以及风险。

建议与风险控制措施

若存在疑似业务影响，请提供建议的应对措施（如增加单元测试、集成测试、代码审查等方法）来保证业务稳定性。

请务必细致、逐条检查，并提供充分的理由或代码片段作为支撑你的判断依据，以确保技术重构的安全性。

在每次有相对较大的改动以后，可以让 ai 帮我总结到底改了什么东西，哪些改动会影响原有的业务逻辑，哪些不会，同时给出一个整体的评价，告诉我是否需要进行回归测试之类的；

实际体验上每次有大的重构，我都会用不同的模型针对我的代码修改让 ai 基于这个 prompt 来回答；然后我来 review 最终是否是存代码重构还是可能会有业务逻辑修改；实际体验下来，还是比较可靠的；用不同的 ai 回答，是为了交叉验证以避免 ai 胡说八道骗我；

cursor mcp 实践#

目前在用的 mcp 如下：

一个是同事写的语雀 mcp，用来给 cursor 提供读取语雀文档的能力
一个是开源的 npm 包版本管理的 mcp，用来管理页面整体的依赖的

商详前端应用为 Ai 做的优化#

在 cursor 本身的能力加强以外，我们针对商详的前端应用，也做了一些为 cursor 定制或者说更加 ai 友好的改造。

Monorepo：每个模块之间完全独立，仅暴露固定 Api ，大幅降低代码之间的耦合度，为 Ai 理解整个仓库相对一般的前端应用更加容易#

首先通过 Monorepo 的能力，把整个商详的所有依赖工程都放到了一个应用下面，避免一些孤岛应用的存在，为 ai 理解整个项目提供了基础，不存在依赖以外 ai 不知道的代码。

同时商详前端已经做了多次改造，从技术栈上几乎已经完全和社区标准保持 7 一致，少有阿里内部的私有解决方案。也就是说从技术上来说，所有的技术框架、组件库以及解决方案都是最新的 ai 模型的固有知识，不存在 ai 不了解的阿里私域知识。

把一个应用的所有依赖都放到一个仓库可能会出现依赖混乱、过度耦合的问题，所以我们最终通过 Monorepo 隔离各个子 package 、子应用，让他们按照统一的规范来进行交互，为 ai 理解整个仓库的运行机制打下基础。

使用原子化 css 避免 css 复杂的作用域问题#

通过使用 tailwind css 方案，在技术上确保所有的样式都是独立的、不会互相干扰的样式。为 ai 在生成样式代码时，不需要理解整个项目的复杂 css 全局，只需要关心当下部分的内容。

项目级别的 cursor rule#

针对商详的特定项目情况，编写整个项目的 devGuid#

参考文档：https://code.alibaba-inc.com/sc/detail-fantasy/blob/master/project-rule.mdc

核心介绍项目的结构、开发理念，以及要注意的内容

针对 pc&wap 不同的特性编写不同的 curosr rule#

由于大模型上下文有限，所以在 project 级别只写了关键的规则，对于开发 pc 和 wap 时的不同规则则通过 globs: apps/wap/**/. alwaysApply: false 条件引用确保只对特定的文件修改生效 prompt。

针对每个独立的子 package 写了 README，供 ai 理解#

针对特定工作编写特定的 rule#

我最近在做 m 站的体验拉齐项目，涉及到老的 wap detail 代码的迁移和重构。

其中很大的一部分工作就是商详的模块的迁移，需要根据 App 的样式，pc 的数据，来迁移 wap 的模块，同时需要严格遵守我们的项目规范；所以专门为此写了特定的 rule，https://code.alibaba-inc.com/sc/detail-fantasy/blob/master/apps/wap/src/modules/wap_module_devGuide.mdc

内容的核心就是强调了我们的模块开发规范，以及如何使用项目中现有的工具和方法来完成工作，不要自己一通乱写。

通过 eslint 解决 ai 破坏同构的问题#

同构问题：结合 cursor rule 和 eslint ，实现 ai 生成的代码尽可能不破坏同构

通过 cursor rule 限制，但是无法完全保障，因为 ai 会一本道
通过 eslint 限制，可以约束 ai 的一些行为，

通过 swagger 生成前后端字段协议类型，约束 ai 的乱写乱画#

关键内容： detail.backend.d.ts ，基于后端接口生成前端需要的 ts 类型定义，和我们后端在商详落地了 swagger 作为前后端数据交互的文档。同时基于 swagger 生成的 openApi.json ，生成前端工程需要的 ts 类型定义文件。

解决 ai 不理解前后端数据交互模型的问题，给了 ai 能从前端代码上了解整个数据模型的可能。实践下来对 ai 的帮助非常大，让其能够通过字段命名理解字段含义并用在正确的地方，如果后端同学能够依照 swagger 的规范给字段编写详细的文档，那么效果可能会更好。

基于 swagger 的前后端接口约定规范

通过单元测试确保 ai 修改的代码有一定的保证#

由于商详的业务本身特性，会在前端有非常多的比较复杂的数据处理和计算。原本在非 ai 情况下都是有经验的前端同学参与，所以所有写业务逻辑、ui 逻辑都糅合在项目的 store 中，虽然说把逻辑单独提取出来是一个不错的优化点，但是在繁杂的业务需求下这个优先级是提不上来的。

但是由于我们需要 Ai 辅助全栈，也就是说有非前端经验的后端同学也要来开发前端的应用。那么原本复杂各种逻辑糅杂的 store 对于后端同学理解来说有点困难，而且对于 ai 修改这一块的代码也都心里没有底。所以我们在 wap 改造时把纯后端的数据处理逻辑，一些特定的业务逻辑都单独抽成独立的方法，在 store 中只是调用而已。这样的话，在绝大多数情况下这些代码可能不需要改动，store 的复杂度是可以急剧降低的，对于后端同学参与也相对友好一点。

所以我们改造的方向就是尽可能抽离这些相对固定的业务逻辑处理函数，收口在独立的 package 中。由于抽离出来的都是纯函数，所以也比较方便补足单元测试。

这样改造以后，对于核心业务逻辑基本上都抽离到独立的 package biz-core 中，上层 wap &pc（改造中）的 store 也只是对 biz-core 的调用，一般情况下不感知他们的具体逻辑。

这样即使 ai 修改代码存在不可控，但在修改以后任何代码以后只能能通过我的单元测试，那么业务逻辑风险基本可控。

大幅降低 store 的复杂度#

下面的图是我们页面的 store 的改造前后的对比，可以一眼看到他们之间的复杂度还是有非常大的简化的，当然一部分原因是 wap 端没有样品、物流模块本身业务复杂度上较低，但对于普通品本身的复杂度也是做了大幅简化。对于 ai 理解整个页面的状态也有帮助。

之前：

之后：

实际体验#

前端的 Ai 体验#

这个是我大约三周的开发过程中的一些我觉得有意义的记录，仅供参考。其中让我觉得最有用的两次：

[使用 mock 数据的模块进行打标]：我只需要功能，完全不关心实现，也完全不关心后续的维护，我也不想动脑子，所以这种问题交个 ai 非常合适，而且最终他也非常好的帮我实现了我想要的内容；
[为了店铺性能的录屏优化而做的一个需要后端支持的需求]：由于我对店铺本身渲染上有不错的理解，加上后端的指引，借助 ai 快速的完成了我要的东西，帮助巨大，节省 1.5d；

全栈的 Ai 体验#

在做完 Ai 改造以后，我们有全栈的同学进来参与需求开发，实际运行下来还是有帮助的。我们的后端同学能够在 ai 的帮助下，快速的完成一些简单的需求，复杂一点的需求多花一点时间也可以最终完成，解决了从无到有的问题，在一些情况下前后端同学可以快速补位支持业务。

但依然存在一些问题，有些样式的改造、组件的使用由于对前端工程的理解程度相对较浅，cursor 即使在各种 rules 的限制下也依然是会随意发挥，改使用组件的不使用组件，有现成方法的不用非要自己写，但是全站同学可能一下看不出来这些问题，只能从浏览器看这一块的改造展示是否 ok ，最终会导致一部分返工。

但总体上看，在一定程度上是可以人员的补位程度的。

小结#

我预估我的 cursor 使用的统计数据中，代码采用率可能在 40%～ 60%，但是实际的效率提升应该是在 15%～ 25% 之间，这之间的 gap 在于：

统计的代码采用率会远高于实际最终 merge 到主干的代码：因为每次他生成的代码我没有时间去详细的看到底对不对，所以我大部分时间下都是瞄一眼代码，没有问题就直接 accept 然后看效果是否满足预期，因为每次采纳代码也只是为了测试一下这次抽卡抽的成功与否，只有在满足预期以后才会最终 merge 这份代码或者修改以后再 merge 代码；实际的大多数情况下，都是同一个问题可能 accept 了三到五次甚至更多次以后，才勉强给了一个能用的版本，然后再上面进行修改后 merge ，所以实际的代码采用率应该在 20% 左右；

总结#

对于全栈（如果没有相应的技术背景）：可以快速的切入其他技术栈进行需求开发，但仅限于非常简单的需求，稍微有复杂度的需求就需要更长的时间沉淀和相关技术栈基础知识进行学习才可能支持的了；但是在特定情况下可以大幅提升效率。
对于前端自己：如果不抱着 curosr 能够提效的目的来用，那么提效比例大概是在 10%～ 20% 之间；如果抱着 cursor 一定要给我提效多少多少来用，那么整体上提效有限；
1. curosr 本身的 AiTab 功能就非常好用，日常开发中在不需要任何环境支持的情况下就可以提效 5%～ 10% 左右；
2. 对于一般的 ui 需求，如果是一次性的日抛 or 月抛代码，那么直接让 Ai 来搞，风险可控，提效不错；
3. 对于非最终上线功能，比如开发中需要一个临时的打标样式功能之类的最终不会上线的功能，那么可以全权交给 Ai ，只要最终不会改到我们的生产代码，那么多次对话以后就可以得到你要的效果，提效明显；
使用 Ai 的一些陷阱：对于一些复杂问题，直接让 ai 去写，可能在 n 轮对话以后， ai 确实给出了一个能够 work 的代码，但这个本身是一个陷阱，体现在两个方面：
1. 你自己直接上手写，可能花费的时间不会比 ai 写来的多，但是使用 ai 一直对话一直让它改，在这个过程中，你的脑子出力了，但又没完全出力，最终能够 work 的代码也只是你黑盒测试加肉眼粗略的白盒测试以后的结果，你觉得可以 work，就打算发上线了，毕竟开发时间已经耗费掉了；这个是时间上的陷阱，看似 ai 生成了代码，但短期看也没有提效；
2. 这份通过 ai 生成的解决一个复杂问题的代码，只要不是一个非常独立的模块，那么这份代码就变成了纯纯的负债，因为你作为开发这个代码的人，你也不完全理解这一块的逻辑，这个是很可怕的情况；虽然生成这份代码的过程中你是一直参与的，但是你的脑子可能并没有全程参与，最终虽然代码能够 work，但是为什么能 work 你仅仅只有一个模糊的概念而已；当真的出现问题，或者需要加功能的时候，你对代码本身没有完整的掌控了，此时你面临两个选择：
  1. 把之前 ai 生成的代码完整的吃透，然后基于它的代码来加功能；之前所谓的节省的时间有需要重来一遍，在效率上，整体就是降效而非提效了
  2. 继续把功能交给 ai ，让它在它的基础上去改，但是随着功能的迭代，ai 大概率会掌控不了这种情况，出现了拆东墙补西墙或者按下葫芦起了瓢的情况就会开始出现；

最终，在一开始你看似 ai 为你的大脑降低了负担，但实际上整体无论是从效率还是对项目的掌控上，都是下降的，负向的。所以不推荐对于复杂的多依赖的功能，使用 ai 来实现。需要加强的个人能力：要能感知模型的边界，在该用的地方用，不该用的地方不用，那么 ai 提升的就是很大的，否则可能很多情况下都是负向的；

其他#

一篇 ATA 文章中提到的内容，我觉得非常有帮助：

当写代码不再那么重要，程序员的能力要求必然发生变化。

**我们需要快速适应变化的能力** ：AI 技术发展日新月异，从开始写提示词调用大模型，再到模型微调和搭建工作流和智能体，到现在开始搞 MCP 等，从 DeepSeek-R1 、V3 到 DeepSeek-R1 0528 ，从 Claude 3.5 到 3.7 和 4 模型也在飞速发展。从 AI 只能写纯前端的“玩具”代码，到现在使用 Cursor 可以实现企业级的 AI Coding，也不过几个月甚至一两年的光景。

**我们需要更强的提出问题的能力** ：只有懂 AI ，又懂业务，才能发现问题，提出问题，进而解决问题。

**我们需要更强的任务拆解能力** ：能够感知模型边界，将任务拆解为大模型可以 Hold 住的粒度，才能更好地发挥出模型的效果。

**我们需要更强的架构设计的能力** ：代码不是资产，真正的资产是代码所实现的业务能力。每一行代码都需要维护、安全保障、调试和淘汰，本质上是负债。AI Coding 带来了提效，同时也带来了很多风险，技术债的积累，程序员编码能力退化等。新的 AI Coding 工具让程序员从基础的编码中解放出来，可以更专注于系统架构的设计。代码易得的时代，设计出复杂且连贯系统架构的人，比单纯会写代码的人更有价值。详情参见：[https://www.linkedin.com/posts/vbadhwar_sysadmins-devops-ai-activity-7333228313433227268-WNW4](https://www.linkedin.com/posts/vbadhwar_sysadmins-devops-ai-activity-7333228313433227268-WNW4?spm=ata.21736010.0.0.50de4238i2BGMr) （linkedin 帖子，需要开加速才能看）

**我们需要更强的需求理解能力** ： 快速理解需求，使用 AI 工具快速实现。

**我们需要更强的沟通表达能力** ：现在很多 AI Coding 团队反馈用户不懂如何提问。现在这个时代很多人说“提示词工程不重要了”，然而，很多特别好用的提示词依然需要精心设计。很多人并不能很好地表达需求，缺少输入，缺少明确的输出要求，任务粒度太粗，上下文不足等等问题非常突出。沟通表达能力不是人与人的沟通，还应该包括人与 AI 的沟通。随着 AI 能力的不断增强，我们的工作方式开始更多地和 AI 沟通，因此提示词工程，沟通表达能力非常重要。

**我们需要更强的批判性思维能力** ：AI 很容易出现幻觉，我们需要有能力评判出 AI 产出的内容是否正确。

**我们需要终身学习的能力** ：技术发展远比想象得更快，上面有一张图提到 60 岁程序“终身学习” 快速掌握新一代 AI Coding 工具，可以超越自己的能力限制，轻松编写代码。终身学习让人能够跟上时代发展的步伐，享受到时代发展的红利。值得庆幸的是， AI 的时代，学习成本进一步降低，可以创建各种有意思的智能体快速帮助我们学习和理解知识，已经是现在进行时。