能否写出一个能根据自我需要而进行编程的程序? (English)

Generated: 2026-06-22 13:40:15

---

Let me tell you a true story.

My cousin is a high school sophomore flunking programming class. Ask him, "What's a variable?" and he'll stammer and mumble. Last month, out of the blue, he came to me and said he wanted to build something—a tool that would automatically calculate the total scores and rank the students in his class. I said, "Sure, but you'll need to learn the basics first." He thought that was too much trouble and grumbled, "Way too complicated."

So he tinkered on his own and used Codex instead. He just typed a few plain-English sentences, and bam—he actually built the thing. It threw a bunch of errors along the way. He couldn't read the English error messages, so he just copied them and pasted them back. Codex analyzed the errors, fixed the code itself, and after a couple rounds, it worked. He barely wrote a single line of code by hand.

That got me thinking. We're always talking about "automatic programming." Can you really write a program that writes itself based on your requirements? Yes, you can—but it depends on the situation. I tested this myself, and the result surprised me.

---

Let's start with the conclusion: Yes, but not in the way you imagine

I've been writing code for over a decade—from C++ to Java to Python. I've used plenty of code-generation tools. Isn't a compiler itself a form of automatic programming? The Dragon Book says a compiler reads a program in one language and outputs an equivalent program in another. The real question is: How do you define the "input"—the requirements?

Telling your boss, "I want an e-commerce system," in natural language is a completely different level of abstraction from a programmer writing "public class UserController extends BaseController." In the first case, the AI will probably guess your real intent wrong. In the second, that's just what a compiler does. You might think the AI isn't smart enough, but the truth is: you didn't explain clearly enough.

---

The pits I fell into—believe me, they're painful

Last year I got an itch: I wanted to build a tool that auto-generates PowerPoint presentations.

We had hundreds of coworker-made PPTs at the company. My idea was to extract slides from them and assemble new presentations. The plan sounded beautiful: first, parse every PPT offline into a Markdown document, recording the page number and a content description. Then have a large language model plan a storyline based on a topic, and pick slides from the library.

Sounds perfect, right? It all crashed and burned. The LLM planned the PPT structure logically enough, but the final product was completely unusable—the slides jumped between ideas, the style was inconsistent, and it looked like a collage gone wrong. Then I found out the company computers couldn't install any AI tools—security policies blocked everything. And to top it off, even if it did generate something, I still had to manually review the whole thing. At that point, I might as well have done it myself. It took time, it was frustrating—what was I even doing this for? The project was scrapped. It wasn't that the technology couldn't do it; it's that the gap between "it works" and "it works well" is miles wide.

---

So what scenarios actually make automatic programming worth it?

From my own experience, three types of scenarios really shine.

One is repetitive boilerplate code. For example, in Java with the Spring framework—if you have a good API document and a database script, you can automatically generate all the Beans, Controllers, and Services. All that's left is to fill in the business logic. Let AI handle the grunt work; keep the creativity for yourself.

Another is personal little tools. Not long ago, I wanted to make a simple check-in app for my kid. I opened a few apps, but they all required a subscription. The functionality wasn't complicated, so I just used Cursor and developed one myself—without writing a single line of code. I described what I needed, fixed bugs by describing them, described some more, and within a week, it was live. I used uni-app with Alibaba Cloud's free tier—one month free, then you can renew indefinitely. From idea to launch, the cost was nearly zero.

And then: test cases. Auto-generate test cases from your API documentation, then run them with an open-source library. Once the code is written, basic testing is basically one-click. You just focus on the logic, and AI covers your back.

---

What's the real bottleneck? You might not believe it

It's not the technology. It's the ability to "clearly state your requirements."

Look at all those success stories—Codex, Cursor, Lingguang (the Magical Light) from Ant Group. At the core is that the user was able to clearly describe what they wanted. This is simpler than learning to program syntax, but by no means easy. I've seen so many people tell an AI "Make me an app," and then when the AI asks for specifics, they just say, "I don't know." It's like walking into a restaurant, saying "Feed me something," and expecting the chef to deliver—no matter how good the chef is, it won't end well.

There's also this: Are you okay with the AI guessing wrong? Natural language is inherently ambiguous. You say "input." Does that mean keyboard input? File input? Single entry? Batch? In human conversation, we fill in these implied meanings automatically. An AI might not get it right. So the hardest part has never been writing the code—it's translating the "I want this" inside your head into clear human language.

---

My approach now has completely changed

To be honest, my whole way of writing code has transformed. It's not that AI replaces me—it's that I've learned how to use AI.

First, always use the best large model. I'm currently on the latest GPT; I'll switch to Claude when it updates. Next, you must write test cases—I use pytest for Python, and I can have AI write those too. Refactor often—I recommend combining Refactoring to Patterns with AI for double the effect. Most importantly, you need to understand the goal and the implementation process. The goal isn't something you can define perfectly in one shot—it needs constant refinement. And the understanding of the process can only come from hands-on practice: you should be able to explain, step by step, what each step does, without the tool. The whole cycle is: define the goal → AI generates code → run tests → find problems → adjust the goal, and repeat. The AI does the work; your job is to think clearly.

---

Let me say something different—a fresh take on "automatic programming"

Everyone in the tech circles is hyping up "Vibe Coding"—programmers using natural language to command AI to write code. It's fast, yeah, but you still need to know tech: you have to understand what a codebase looks like, and you need to be able to read error logs when things go wrong.

The Ant Group's Lingguang team came up with a new concept called "Wish Coding" (Xu Yuan Programming). It targets the remaining 99%—people who don't know how to code. You don't need to read a single line of code, and you don't need to worry about runtime environments. Just say into your phone, "Make a soft-boiled egg timer," and thirty seconds later, a real, usable little tool pops up. Commercial software companies would never care about these tiny, personalized needs—they need to find common pain points among millions of users to make it profitable. But now AI has driven the cost of custom software down to nearly zero. A single person's one-minute whim can become a real tool.

---

Finally, something practical you can take and use

If you want to learn to write programs yourself, I suggest two paths.

Go the "tough guy" route: Don't start with C or discrete math. Just learn the HTML5 trifecta plus JavaScript. The large models are best at writing H5 code, and it runs directly in the browser—no deployment needed. But here's the thing: when you're first learning, don't ask the large model. The sense of accomplishment you get from independently writing a simple page is a hundred times greater than using AI to