如何看待王垠对 Cursor 等 AI 编程的评价不懂 (English)

Generated: 2026-06-24 11:03:13

---

Recently, it seems like everyone around me is using Cursor to write code.

Last year, I did something—I gathered the entire team in the conference room, slammed the table, and said: "Everyone, use Cursor! Unlimited access, the best models, go all in!"

At the time, there were murmurs. A senior frontend developer frowned and said to me, "Boss, the code this thing writes… can we really trust it?"

I told him to try it for a month.

A month later, frontend positions started disappearing. Not because of layoffs—we simply didn’t need that many people anymore. Product managers were using Cursor themselves to write documentation and design interactive prototypes. Previously, an e-commerce backend required three frontend developers and one backend developer, with requirement reviews, sprint planning, integration testing, and QA—two weeks of work. Now, one person can go from requirements to launch in three days.

The efficiency was undeniable.

By now, you might be thinking—Wang Yin got proven wrong, didn’t he?

Hold on.

Three months later, problems started popping up one after another.

---

Let’s start with the trap of missing requirements. AI always misses requirements, and you never know what it missed.

We were building a management module for an e-commerce backend. The requirements document was very clear: "Support filtering orders by time range, support filtering by order status, support filtering by amount range."

Clear enough, right?

A developer used Cursor to generate the filter page in minutes. It looked perfect. Click, test, approve, launch.

Only after using it did we realize—the order status dropdown didn’t include "Cancelled." The time filter couldn’t span across months. The amount range was a text field that crashed if you entered anything non-numeric.

Why? Because the requirements description never mentioned these edge cases. You thought you made yourself clear, the AI acted like it understood, but the delivered product was missing several key points.

Wang Yin quoted Dijkstra, and I think it’s spot on: "Natural language makes it easy to express statements whose absurdity is not immediately obvious."

When you write requirements, your mind is full of default assumptions—"Of course 'Cancelled' counts as a status," "Cross-month filtering is just common sense." But none of those assumptions made it into the document.

The AI filled the gaps you didn’t even realize existed—by guessing. When it guessed right, you were happy. When it guessed wrong, you took the blame.

I fell into this trap no fewer than five times. Now, our team has a rule: requirements must come with acceptance test cases, and those cases must cover abnormal scenarios. Every single detail omitted by natural language has to be explicitly spelled out.

---

Another trap: code without roots, impossible to modify later.

The code Cursor generates runs fine. But three months later, when you want to add a new feature, you find yourself wading through a tangled mess.

One of my team’s projects used Cursor to generate a user management module. Full functionality: CRUD, permissions, logging. It looked complete.

But the internal structure? Query logic was scattered across three files. Transaction control was sometimes in the Service layer, sometimes in the Controller layer. Even the log format wasn’t consistent.

Modifying a single query meant digging through dozens of files. Code reviews became impossible—every generation produced a different coding style.

Wang Yin put it clearly: natural language descriptions inherently lack architectural constraints.

When you ask the AI to "write a user management module," that sentence contains no information about layering, dependency relationships, or interface design. The AI can only fill in the gaps based on the average code samples it’s seen—and those samples are largely mediocre code copy-pasted from the internet.

Back when I was at TDengine, I personally wrote tens of thousands of lines of C code. The "one table per device" design wasn’t something we came up with on a whim—it came from hard-won experience. For structured decisions like this, the AI might generate a SQL query that looks correct, but the critical details will be wrong—it doesn’t understand the nature of time-series data.

AI-generated code looks correct, but it isn’t genuinely correct. Whether you can tell the difference depends entirely on the depth of your own expertise.

---

And then there’s this: the longer the context, the dumber it gets.

You start a new conversation, ask the AI to write a basic function, then say, "Add a search feature," "The search should support fuzzy matching," "Fuzzy matching should support Chinese pinyin," "Optimize performance—if the data volume exceeds 100,000, consider using indexes."

The first three instructions work fine. By the fourth, it starts digging up old history—pulling in incorrect information from earlier in the conversation, even reintroducing bugs you had previously fixed, because it "thinks" that old version was correct.

I spent a solid hour debugging. Eventually, I discovered that a bug introduced in the third iteration had been "fixed" in the fifth iteration—by re-introducing an earlier error.

I almost smashed my keyboard.

Wang Yin says: narrow interfaces, clear constraints, efficient collaboration. The same applies to AI coding. Don’t drag a single conversation out too long. When you notice it getting dumber, start a new conversation without hesitation.

---

AI won’t replace you, but people who use AI will. This conclusion is the opposite of what many expect.

I’ve seen colleagues with strong algorithmic skills use Cursor like a rocket. They know exactly which parts of the generated code need changing and