Project Overview#

This is an SVG image drawn using Cursor, based on an understanding of the product detail frontend application (because Cursor does not support drawing).

Overall, it roughly describes the project situation, including project structure, technology stack selection, and the roles of some sub-packages. However, the overall image has many detailed issues, such as text overflow, overlap, and alignment problems. Despite multiple requests for AI to modify it, it couldn’t. This is the best effect AI can achieve under a reasonable efficiency-to-cost ratio, so it’s acceptable.

Practical Experience with the Cursor Editor Itself#

Specify a Concrete Model#

Do not use auto mode. Turn it off and specify claude-4. Current tests show good results. If you use the default auto model, the quality of responses is very unstable.

Cursor Rule Practices#

Ten Sentences to Make Cursor 10x Better at Programming (Joke)

Improve Basic Response Quality#

This is a Cursor rule riper-5 mentioned in an article I saw somewhere before. After practicing it, I found it good and have been using it ever since.

The overall guidance process is as follows:

In actual use, I found that AI follows the positive flow of this instruction very well, but for all reverse flows, such as detecting deviations or problems and returning to the previous step, I have never seen it follow through. It is always very confident, and its final reviews are always positive self-feedback like perfect, great; it has never been able to find its own problems, even very obvious ones, so human intervention is still indispensable;
- For example, in this case, its response looks very high quality, with rich text and images, appearing very professional, but in reality, the image it drew itself completely lacks related logic such as totalPrice calculation and quantity calculation, so don’t be fooled by appearances;

However, after overall practice, it can still significantly improve response quality in daily feature development, and even if it sometimes can’t write the code for you, the thought process and multiple reference solutions provided are still valuable;

But for overly simple requirements, the response process might be too verbose, which is like taking a long detour to solve a problem that could have been given the best answer from the start;

Code Refactoring Review#

Code Refactoring Review Rule

Technical Refactoring Code Review Guide (Git Diff)

I am a frontend developer, and I have a Git
Diff I'd like you to review. Please follow the technical checklist below, carefully examine it, and provide a detailed analysis report:

Checklist

I. Code Organization and Structure Adjustments

Determine if the changes are solely at the level of code organization, architecture, and naming, including but not limited to:

Name adjustments for functions, methods, or variables
Changes in file or directory structure (e.g., splitting or merging files)
Logic split or combined into different functions or files, but inputs, outputs, and processes remain unchanged
Addition or improvement of comments, without involving logic changes
Deletion of deprecated code, not affecting existing processes

II. Potential Business Logic Changes

Please meticulously check if the changes affect business logic or functionality, including but not limited to the following situations:

Whether the type, quantity, or default values of input parameters have changed
Whether the return type or structure of functions or methods has changed
Whether control flow (e.g., conditional statements, loop structures) has undergone logical changes
Whether data processing, calculation methods, or key algorithms have been adjusted
Whether asynchronous calls, API requests, or external service dependency logic has changed
Whether state management, caching, or data storage logic has changed
Whether business-critical functions, methods, interfaces, or external dependencies have been added or removed

Output Format Requirements

Please output your review report in the following format:

Summary Conclusion

Clearly state whether the overall changes might impact existing business logic.

Organization and Architecture-only Changes

List all confirmed structural and organizational adjustments.

Changes Potentially Affecting Business Logic

Clearly indicate the code change location (filename, line number, function or variable name).
Describe in detail the nature of the changes (e.g., parameters, return values, logic changes).
Assess potential impacts and risks.

Recommendations and Risk Control Measures

If there are suspected business impacts, please provide recommended countermeasures (e.g., adding unit tests, integration tests, code reviews, etc.) to ensure business stability.

Please be sure to check meticulously, item by item, and provide sufficient reasons or code snippets to support your judgment, ensuring the safety of technical refactoring.

After each relatively large change, I can ask AI to summarize what was changed, which changes will affect existing business logic and which will not, and also provide an overall evaluation, telling me whether regression testing is needed or not;

In practice, for every major refactoring, I use different models to have AI respond to my code changes based on this prompt; then I review whether it’s purely code refactoring or if there might be business logic modifications. The actual experience has been quite reliable. Using different AI responses is for cross-validation to prevent AI from fabricating information and misleading me;

Cursor MCP Practices#

The MCPs currently in use are as follows:

One is a Yuque MCP written by a colleague, used to provide Cursor with the ability to read Yuque documents.
The other is an open-source npm package version management MCP, used to manage the overall dependencies of the page.

Optimizations Made to the Product Detail Frontend Application for AI#

In addition to strengthening Cursor’s own capabilities, we have also made some customizations or more AI-friendly modifications to the product detail frontend application.

Monorepo: Each Module is Completely Independent, Exposing Only Fixed APIs, Greatly Reducing Coupling Between Code, Making it Easier for AI to Understand the Entire Repository Compared to General Frontend Applications#

Firstly, by leveraging Monorepo capabilities, all dependent projects of the product detail page are placed under a single application, avoiding the existence of isolated applications, which provides a foundation for AI to understand the entire project, ensuring no code is unknown to AI beyond dependencies.

At the same time, the product detail frontend has undergone multiple refactorings, and its technology stack is almost entirely consistent with community standards, with few Alibaba internal private solutions. This means that, technically speaking, all technical frameworks, component libraries, and solutions are inherent knowledge to the latest AI models, and there is no Alibaba-specific private knowledge that AI doesn’t understand.

Placing all dependencies of an application into a single repository might lead to dependency confusion and excessive coupling. Therefore, we ultimately use Monorepo to isolate various sub-packages and sub-applications, allowing them to interact according to unified specifications, laying the foundation for AI to understand the entire repository’s operating mechanism.

Using Atomic CSS to Avoid Complex CSS Scope Issues#

By using the tailwind css solution, we technically ensure that all styles are independent and do not interfere with each other. This means that when AI generates style code, it doesn’t need to understand the entire project’s complex global CSS; it only needs to focus on the current section’s content.

Project-Level Cursor Rules#

Writing a Project-Wide `devGuide` for the Specifics of the Product Detail Project#

Reference document: https://code.alibaba-inc.com/sc/detail-fantasy/blob/master/project-rule.mdc

Core introduction to the project’s structure, development philosophy, and points to note.

Writing Different Cursor Rules for PC & WAP’s Distinct Characteristics#

Due to the limited context of large models, only key rules are written at the project level. Different rules for PC and WAP development are referenced using globs: apps/wap/**/. alwaysApply: false conditions to ensure prompts only apply to specific file modifications.

Wrote a `README` for Each Independent Sub-package for AI Comprehension#

Writing Specific Rules for Specific Tasks#

I’m currently working on a mobile site experience alignment project, which involves migrating and refactoring old WAP detail code.

A significant part of this work is the migration of product detail modules, requiring WAP modules to be migrated based on App styles and PC data, while strictly adhering to our project specifications. Therefore, a specific rule was written for this: https://code.alibaba-inc.com/sc/detail-fantasy/blob/master/apps/wap/src/modules/wap_module_devGuide.mdc

The core content emphasizes our module development specifications and how to use existing tools and methods in the project to complete work, avoiding arbitrary coding.

Solving AI’s Isomorphism-Breaking Issues with ESLint#

Isomorphism issue: Combining Cursor rules and ESLint to ensure AI-generated code disrupts isomorphism as little as possible.

Limited by Cursor rules, but not fully guaranteed, as AI tends to follow a single path.
Limited by ESLint, which can constrain some of AI’s behaviors.

Generating Frontend and Backend Field Protocol Types via Swagger to Restrain AI’s Arbitrary Code Generation#

Key content: detail.backend.d.ts, which generates frontend ts type definitions based on backend interfaces, and our backend has implemented Swagger for product details as documentation for frontend-backend data interaction. Additionally, based on the openApi.json generated by Swagger, ts type definition files required by the frontend project are generated.

This solves the problem of AI not understanding the frontend-backend data interaction model, giving AI the possibility to understand the entire data model from the frontend code. In practice, this has been extremely helpful for AI, allowing it to understand field meanings through naming and use them correctly. If backend developers could write detailed documentation for fields according to Swagger specifications, the effect might be even better.

Frontend and Backend Interface Convention Specification Based on Swagger

Ensuring AI-Modified Code Has Certain Guarantees Through Unit Tests#

Due to the inherent characteristics of the product detail business, there is a significant amount of complex data processing and calculation on the frontend. Originally, in non-AI scenarios, experienced frontend developers were involved, so all business logic and UI logic were intertwined within the project’s store. While extracting logic separately is a good optimization point, under complex business requirements, this priority couldn’t be elevated.

However, since we need AI to assist full-stack development, meaning backend developers without frontend experience also need to develop frontend applications. The previously complex store, with its intertwined logic, is somewhat difficult for backend developers to understand, and there’s also uncertainty about AI modifying this part of the code. Therefore, during the WAP refactoring, we extracted pure backend data processing logic and some specific business logic into separate methods, which are merely called within the store. This way, in most cases, these codes might not need modification, and the store’s complexity can be drastically reduced, making it relatively more friendly for backend developers to participate.

Thus, our refactoring direction is to extract these relatively fixed business logic processing functions as much as possible, consolidating them into independent packages. Since the extracted functions are pure functions, it’s also relatively easy to supplement them with unit tests.

After this refactoring, core business logic is largely extracted into the independent biz-core package. The upper-layer WAP & PC (under refactoring) stores merely call biz-core and generally do not need to be aware of its specific logic.

This way, even if AI modifies code in an uncontrolled manner, as long as any modified code passes my unit tests, the business logic risk is essentially controllable.

Significantly Reducing Store Complexity#

The images below show a comparison of our page’s store before and after refactoring. You can see at a glance that their complexity has been greatly simplified. Of course, part of the reason is that the WAP side lacks sample and logistics modules, which inherently have lower business complexity. However, the complexity of regular products themselves has also been significantly simplified. This also helps AI understand the entire page’s state.

Before:

After:

Actual Experience#

Frontend AI Experience#

These are some meaningful records from my development process over approximately three weeks, for reference only. Among them, the two most useful instances for me were:

[Tagging modules using mock data]: I only needed the functionality, completely unconcerned with the implementation or future maintenance, and I didn’t want to think too much. So, entrusting such problems to AI was very suitable, and ultimately, it helped me achieve what I wanted very well;
[A backend-dependent requirement for optimizing store performance screen recording]: Because I have a good understanding of store rendering itself, coupled with backend guidance, I quickly completed what I needed with AI’s help. It was a huge help, saving 1.5 days;

Full-Stack AI Experience#

After completing the AI transformation, full-stack colleagues joined in on demand development, and it proved helpful in practice. Our backend colleagues were able to quickly complete some simple requirements with AI’s help, and even more complex requirements could eventually be completed with a bit more time, solving the problem of starting from scratch. In some cases, frontend and backend colleagues could quickly fill in to support the business.

However, some issues still exist. Due to a relatively shallow understanding of frontend engineering, Cursor, even with various rule constraints, still tends to act arbitrarily in style modifications and component usage. It might not use components where they should be used, or write custom code when existing methods are available. However, full-stack colleagues might not immediately spot these issues and can only check if the modified display in the browser is okay, ultimately leading to some rework.

Overall, however, it can facilitate personnel cross-functional support to a certain extent.

Summary#

I estimate that in my Cursor usage statistics, the code adoption rate might be between 40% and 60%, but the actual efficiency improvement should be between 15% and 25%. The gap between these figures lies in:

The reported code adoption rate is much higher than the code actually merged into the main branch: Because I don’t have time to meticulously check if every piece of code it generates is correct, most of the time I just glance at the code, accept it if it seems okay, and then check if the effect meets expectations. Each acceptance is merely to test whether this ‘gacha pull’ was successful. Only after meeting expectations will I finally merge this code or modify it before merging. In most actual cases, for the same problem, I might accept three to five or even more times before getting a barely usable version, which then requires further modification before merging. Therefore, the actual code adoption rate should be around 20%.

Conclusion#

For full-stack developers (without relevant technical background): They can quickly dive into other tech stacks for demand development, but this is limited to very simple requirements. Slightly more complex requirements would necessitate longer periods of immersion and learning foundational knowledge of the relevant tech stack to be supported. However, in specific scenarios, efficiency can be significantly boosted.
For frontend developers themselves: If not used with the explicit goal of Cursor boosting efficiency, the efficiency improvement ratio is roughly between 10% and 20%. If used with the expectation that Cursor must deliver a certain level of efficiency, then the overall efficiency gain is limited.
1. Cursor’s own AiTab feature is very useful; in daily development, it can boost efficiency by about 5% to 10% without needing any environment support.
2. For general UI requirements, if it’s one-off daily or monthly disposable code, then letting AI handle it directly is suitable, with controllable risk and decent efficiency improvement.
3. For non-final production features, such as a temporary tagging style feature needed during development that won’t go live, it can be fully entrusted to AI. As long as it doesn’t ultimately alter our production code, you can achieve the desired effect after multiple conversations, resulting in significant efficiency gains.
Some Traps of Using AI: For complex problems, directly asking AI to write the code might result in a working solution after ‘n’ rounds of conversation, but this itself is a trap, manifesting in two aspects:
1. If you write it yourself, it might not take more time than AI writing it. However, constantly conversing with AI and asking it to revise means your brain is engaged but not fully engaged. The resulting working code is merely the outcome of your black-box testing combined with a rough visual white-box test. You deem it workable and decide to deploy it, as development time has already been spent. This is a time trap: seemingly AI generated the code, but in the short term, there was no efficiency gain.
2. This AI-generated code solving a complex problem, unless it’s a very independent module, becomes a pure liability, because you, as the developer of this code, don’t fully understand its logic, which is a terrifying situation. Although you were involved throughout the code generation process, your brain might not have been fully engaged. Ultimately, while the code works, you only have a vague idea of why it works. When problems truly arise, or new features need to be added, you no longer have complete control over the code itself. At this point, you face two choices:
  1. Fully grasp the AI-generated code and then add features based on it; the time supposedly saved earlier now needs to be spent again, resulting in an overall decrease, not increase, in efficiency.
  2. Continue to hand over features to AI, letting it modify based on its existing code. However, as features iterate, AI will likely lose control of the situation, leading to ‘robbing Peter to pay Paul’ or ‘patching one hole only to open another’ scenarios.

Ultimately, while AI initially seems to reduce your mental burden, in reality, overall efficiency and project control both decline, becoming negative. Therefore, it is not recommended to use AI for complex, multi-dependent features. A personal skill that needs strengthening: the ability to perceive the model’s boundaries. Use AI where it’s appropriate, and don’t use it where it’s not. If you do this, AI’s boost will be significant; otherwise, in many cases, it might be negative.

Other#

Content mentioned in an ATA article, which I found very helpful:

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

**我们需要快速适应变化的能力** ：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 的时代，学习成本进一步降低，可以创建各种有意思的智能体快速帮助我们学习和理解知识，已经是现在进行时。