AI 能写出我看不懂的代码，这算我的能力吗？

01｜我好像突然拥有了开发能力

有时候，我觉得 AI 给人带来的最奇妙的体验，不是它能回答多少问题，而是它让一个人突然拥有了过去不具备的行动能力。

至少对我来说是这样。

我本科读的是经济学，并没有接受过系统的计算机专业训练。

以前想到一个产品创意，我会先考虑自己能不能做出来。

需要掌握什么编程语言？前端怎么实现？后端怎么办？数据库又是什么？

还没有开始，技术门槛就已经拦住了大部分想法。

后来，我开始接触 AI 编程工具。

事情突然变得不一样了。

我可以用自然语言描述一个需求，让 AI 帮我搭建页面、编写代码、修改交互，甚至解释那些我从来没有接触过的技术概念。

原本只存在于脑海里的想法，真的可以变成一个能够运行的网页。

那种感觉很奇妙。

就像一个人原本只会画房子的草图，突然有一天，面前出现了一支能够帮她施工的队伍。

只要说清楚想要什么，房子似乎就可以一点点建起来。

于是，我开始尝试做一些真正的项目。

有时是生活中观察到的小问题，有时是参加比赛时突然冒出来的创意，也有一些纯粹出于好奇的实验。

我开始接触前端、接口、部署、数据库，以及各种以前只听过名字的技术。

但一个问题也慢慢出现了。

如果这些代码并不是我独立写出来的，那么这个产品到底算不算我做的？

02｜代码能运行，不代表我能解释它

AI 编程有一个特别容易让人上瘾的地方。

反馈实在太快了。

提出一个需求，等待生成，运行项目，检查效果。

如果页面符合预期，就继续下一个功能。

如果遇到报错，把报错信息交给 AI，让它分析并修复。

很多问题确实可以这样解决。

但我逐渐意识到，这个过程有时会掩盖一个事实：

我知道怎样让 AI 帮我完成一件事，却不一定知道这件事究竟是怎样完成的。

比如，一个页面可以正常打开，我能够调整它的颜色、布局和交互。

可是，如果突然问我，这个项目的状态是怎样管理的，数据经过了哪些处理，某个依赖为什么存在，我未必能够马上回答。

更复杂的情况是，AI 可能为了修复一个问题，修改了其他地方的代码。

页面恢复正常了，我却不一定理解它为什么这样修改。

有时，一个报错消失了，另一个报错又出现了。

我继续询问 AI，继续修改。

直到项目终于可以运行。

表面上看，我解决了问题。

但仔细想想，我可能只是成功组织了几轮 AI 对话。

问题被解决了，不代表解决问题的能力已经完整地转移到了我身上。

这是两件不同的事情。

当然，我并不认为只有从头到尾独立手写代码，才算真正的开发。

现代软件工程本来就建立在大量已有工具、框架和开源项目之上。

很少有人会为了开发一个网站，先从零编写浏览器或者数据库。

借助工具并不是问题。

真正让我在意的是，当工具无法继续提供帮助时，我还剩下多少独立判断和处理问题的能力？

03｜我拥有了结果，却未必拥有过程

我开始尝试区分两种能力。

一种是完成任务的能力。

另一种是理解和掌控任务的能力。

它们有交集，但并不完全相同。

假设我通过 AI 完成了一个网站。

我提出了最初的需求，设计了用户流程，选择了界面风格，也不断测试和调整，最终把它部署到了线上。

这些工作当然有价值。

即使代码主要由 AI 生成，也不能因此否定我在其中的参与。

毕竟，AI 不会自动知道我想解决什么问题，也不会天然理解哪些体验是我真正想要的。

但与此同时，我也不能因为产品成功部署，就默认自己已经掌握了完整的软件工程能力。

如果让我脱离 AI，独立构建同样的系统，我可能还做不到。

如果项目出现复杂的安全问题、性能瓶颈或者难以定位的故障，我也可能缺乏足够的经验进行判断。

这并不矛盾。

我确实完成了一个过去很难独立完成的项目。

但我对项目的掌控程度，可能还远远落后于它表面呈现出的复杂程度。

这种差距有时会带来一种奇怪的错觉。

我的作品成长得很快，但我本人未必以同样的速度成长。

这句话让我想了很久。

一个人的 GitHub 仓库可以越来越丰富，页面可以越来越精致，功能可以越来越复杂。

但这些外在成果，究竟有多少已经转化成了可以迁移、可以复用、可以独立运用的能力？

我觉得这个问题值得认真回答。

至少，不能只通过完成了多少项目来回答。

04｜如果 AI 是我的外脑，我需要知道自己借用了什么

我并不反感依赖 AI。

恰恰相反，我觉得这是一种非常有价值的能力扩展。

人类本来就一直在借助外部工具延伸自己的能力。

计算器让我们不必手动完成所有运算。

搜索引擎让我们不必记住所有知识。

导航系统让我们不必提前熟悉每一条道路。

现在，AI 又进一步帮助我们完成写作、设计、分析和编程。

所以，我不觉得一个人必须拒绝 AI，才能证明自己拥有真正的能力。

但不同工具对人的影响，可能并不完全一样。

当我使用计算器时，通常知道自己想计算什么。

当我使用导航时，至少能够理解目的地在哪里。

而当我使用 AI 编程时，有时连自己应该检查什么都不知道。

这才是更值得警惕的地方。

因为我不仅在借用工具完成任务，还可能在借用工具替我判断任务是否已经正确完成。

如果我没有足够的知识去验证，就很容易把 AI 的自信当作结果的可靠性。

一个系统说「已经修复」，不代表问题真的消失。

一个模型说「代码没有问题」，也不代表不存在隐藏的风险。

尤其是当项目涉及用户数据、隐私、支付或者其他具有现实后果的功能时，这种依赖需要更加谨慎。

能力被工具放大以后，责任并不会自动转移给工具。

如果我把一个存在严重缺陷的产品交给真实用户，不能因为代码由 AI 生成，就认为这些问题与我无关。

这是我觉得 AI 编程最需要认真面对的一点。

它让创造变得更容易，却并没有让判断和责任同样变得简单。

05｜那我究竟应该学什么？

我曾经想过，是不是应该暂时停止使用 AI，从头开始系统学习编程。

像传统的计算机专业学生一样，先学语言、数据结构、算法，再学习框架和工程开发。

这当然是一条合理的学习路径。

但我又不太愿意完全放弃 AI 带来的实践机会。

因为很多时候，真正让我产生学习动力的，并不是某个抽象的知识点，而是一个具体的问题。

我想让页面完成某个交互，于是需要理解事件与状态。

我想保存用户输入，于是开始接触数据存储。

我希望网站能够被别人访问，于是不得不研究部署、域名与服务器。

这些知识并不是孤立出现的。

它们和一个个真实任务连接在一起。

所以，我现在更倾向于寻找一种折中的学习方式。

继续借助 AI 完成项目，但不能让自己永远停留在「描述需求、复制结果」的阶段。

例如，在修改一个功能之前，先尝试弄明白它涉及哪些文件、组件和数据流。

AI 给出代码后，不只是检查页面有没有变化，还要尝试理解关键的修改为什么有效。

遇到报错时，不立刻把所有信息交给 AI，而是先自己阅读错误提示，判断问题可能出在哪里。

对于常用的逻辑，尝试脱离 AI 写出一个简单版本。

而对于自己还没有能力验证的复杂功能，则明确承认它超出了当前的掌控范围。

这些事情听起来很基础。

甚至会让原本快速的 Vibe Coding 变慢。

但我开始觉得，这种慢未必是一种损失。

因为如果每一次开发都只追求尽快完成，我可能会拥有越来越多的项目，却始终停留在差不多的理解水平。

我不希望自己只是越来越擅长向 AI 提问。

我也希望自己能够逐渐理解它给出的答案。

06｜一个项目做完之后，我还剩下什么？

后来，我开始用另一个问题评价自己的项目。

不再只是问：我做出了什么？

而是问：做完这个项目之后，如果不看代码、不打开 AI，我还记得什么？

我是否能够解释它的核心流程？

是否理解为什么选择这个技术方案？

是否知道哪些地方容易出错？

如果要添加一个新功能，能不能大致判断需要修改哪里？

如果让我重新做一遍，哪些事情能够做得更好？

这些问题比统计代码行数更有意义。

因为代码行数可能由 AI 在几分钟内生成，而理解某个系统为什么这样运行，却需要更长时间的积累。

一个功能被实现，并不等于我真正掌握了相关知识。

但反过来说，也并不是只有完全掌握所有技术细节，项目才值得被完成。

我仍然认为，实践本身具有价值。

尤其是对于一个并非传统技术背景的人来说，能够把模糊想法变成具体原型，已经意味着可以接触过去难以进入的问题领域。

只是，这份价值需要被准确描述。

我可以说，我利用 AI 工具完成了一个产品原型。

可以解释自己负责了哪些需求分析、交互设计、测试和调整工作。

也可以坦诚说明，哪些代码依赖 AI 生成，哪些工程问题仍然需要进一步学习。

不必把所有成果都包装成独立开发能力。

因为真正可信的经历，不需要假装自己无所不能。

07｜真正的能力，也许是知道自己不能做什么

我以前总觉得，学习的目标是掌握越来越多的东西。

学会一门语言，熟悉一个框架，开发一个完整的应用。

随着 AI 工具越来越强，这种想法开始发生变化。

我现在觉得，能力不仅包括知道怎样完成一件事，也包括知道一件事什么时候超出了自己的能力范围。

我可以做一个演示原型，却未必能够保证它适合大规模真实用户使用。

我可以让 AI 帮忙实现某种交互，却未必理解它所有的安全风险。

我可以在短时间内尝试很多技术方向，却不意味着自己已经具备相应领域的专业深度。

承认这些差距，并不是否定已有的努力。

而是为了知道下一步究竟需要补上什么。

这也让我重新思考「学习」这件事。

以前，我们常常通过能不能独立完成某项任务，来判断一个人是否真正掌握了某项技能。

但在 AI 参与越来越多工作的情况下，这个标准似乎变得不够充分。

一个人即使不能独立写出全部代码，也可能具备很好的需求理解、系统拆解和产品验证能力。

另一个人即使能够熟练编写代码，也未必能够判断什么问题真正值得解决。

这些能力并不应该相互取代。

更不应该因为某一种能力变得容易获取，就认为其他能力不再重要。

对于我自己而言，我希望逐渐建立的，是一种更完整的能力组合。

既能提出值得解决的问题，也能理解解决方案如何运作。

既能够借助工具提高效率，也具备必要的独立验证能力。

既愿意探索新的技术，也知道什么时候应该寻求专业人士的帮助。

这可能比单纯追求「我会多少种编程语言」更符合我真正想做的事情。

08｜我不想永远只做一个会提需求的人

写到这里，我发现自己其实没有那么在意「AI 生成的代码究竟算不算我的」这个问题了。

至少，它已经不是最重要的问题。

更值得关注的，是我在这个过程中究竟承担了什么工作，又获得了什么能力。

如果我只是不断提出需求，把所有实现、测试和判断都交给 AI，那么即使最后得到一个完整的产品，也很难说自己已经理解了它。

但如果我能够逐渐掌握系统结构，理解关键逻辑，发现问题、验证结果，并且知道如何维护和改进，那么 AI 就不只是替我完成任务的工具。

它也可以成为帮助我学习和实践的一种方式。

我不认为所有人都必须成为专业程序员。

也不认为未来每一个做产品的人，都需要掌握完整的软件工程知识。

但至少对于我自己来说，我不想永远停留在只能描述想法、却无法判断实现过程的阶段。

因为当我越来越能够理解技术时，我也会拥有更多选择。

我可以更准确地评估一个想法是否可行。

可以在设计阶段预见一些实现上的限制。

可以与真正的工程师进行更深入的交流。

也可以更清楚地知道，一个原型距离可靠的真实产品还有多远。

最重要的是，我不必把所有判断都寄托在 AI 给出的答案上。

现在，我依然经常需要 AI 帮我写代码。

遇到不熟悉的技术时，我还是会向它提很多问题。

有些错误信息，我仍然需要反复查阅才能理解。

但这并不妨碍我继续学习。

我也不急着通过某个头衔，证明自己已经成为了什么样的人。

也许几年之后，我会具备更加扎实的工程能力。

也许我最终会更专注于产品设计、需求研究和应用落地。

这些方向都可以继续探索。

但无论选择哪条路，我都希望自己对所做的事情拥有越来越清晰的理解。

AI 可以帮我写出暂时看不懂的代码。

而我想做的，是让今天看不懂的东西，慢慢变成明天真正理解的东西。

---

2026 年 10 月 · 关于学习、工具与能力的一次自我观察

这篇文章记录的是我作为非计算机专业背景的 AI 工具使用者，在实际项目开发中的思考。它不是对 Vibe Coding 的否定，也不是一种通用的技术学习方法。

01 | I seemed to acquire the ability to build software overnight

Sometimes I think the most remarkable experience AI offers isn’t how many questions it can answer, but how it suddenly lets someone act in ways they couldn’t before.

At least, that is how it has felt to me.

I studied economics as an undergraduate and never received a systematic education in computer science.

When I used to have an idea for a product, my first concern was whether I could make it.

Which programming language would I need? How would I build the frontend? What about the backend? What even was a database?

Before I had started, the technical barrier had already stopped most ideas.

Then I began using AI coding tools.

Things changed suddenly.

I could describe a requirement in natural language and ask AI to help build a page, write code, adjust interactions, or explain a technical concept I had never encountered.

An idea that had existed only in my head could become a working website.

It was a strange feeling.

Like someone who could only sketch a house suddenly finding a construction team ready to help build it.

If I could explain what I wanted, the house seemed capable of taking shape, piece by piece.

So I began trying real projects.

Some came from small problems I noticed in daily life. Some were ideas that appeared during competitions. Others were experiments driven by curiosity alone.

I started encountering frontends, APIs, deployment, databases, and technologies I had previously known only by name.

But another question slowly emerged.

If I didn’t write the code independently, can I really say I made the product?

02 | Working code doesn’t mean I can explain it

There is something particularly addictive about AI coding.

The feedback is so fast.

Describe a requirement, wait for the output, run the project, inspect the result.

If the page looks right, move to the next feature.

If an error appears, give it to the AI and ask for an explanation and a fix.

Many problems can indeed be solved this way.

But I gradually realized that the process can hide something:

I know how to ask AI to help accomplish a task, yet I may not know how the task was actually accomplished.

A page might open correctly, and I might be able to change its colors, layout, and interactions.

But if someone suddenly asked how the project manages state, what happens to its data, or why a dependency exists, I might not be able to answer immediately.

It gets more complicated when AI changes code elsewhere to fix a problem.

The page works again, but I may not understand why those changes were necessary.

Sometimes one error disappears and another arrives.

I keep asking the AI. I keep making changes.

Eventually, the project runs.

On the surface, I have solved the problem.

Looking more closely, I may simply have organized several successful rounds of conversation with an AI.

A problem being solved doesn’t mean the ability to solve it has fully transferred to me.

Those are different things.

Of course, I don’t think development only counts when every line is handwritten from beginning to end.

Modern software engineering already relies on existing tools, frameworks, and open-source projects.

Few people build a browser or a database from scratch just to make a website.

Using tools isn’t the issue.

What matters to me is how much independent judgment and problem-solving ability remains when the tool can no longer help.

03 | I may have the result without having mastered the process

I began distinguishing between two kinds of ability.

The ability to complete a task.

And the ability to understand and control that task.

They overlap, but they aren’t identical.

Suppose I build a website with AI.

I define the initial requirements, design the user flow, choose the visual direction, repeatedly test and adjust it, and eventually deploy it online.

That work has value.

Even if AI generated most of the code, my involvement doesn’t disappear.

AI doesn’t automatically know which problem I want to solve, or inherently understand which experiences I actually want.

At the same time, successful deployment doesn’t mean I have acquired a complete set of software-engineering skills.

I might still be unable to build the same system independently without AI.

If the project develops a complicated security issue, a performance bottleneck, or a difficult fault, I may lack the experience to judge it properly.

There is no contradiction here.

I have completed a project that would previously have been hard for me to finish alone.

But my control over it may still lag far behind the complexity it appears to have.

That gap can create a curious illusion.

My work is growing quickly, but I may not be growing at the same speed.

I have spent a long time thinking about that sentence.

A person’s GitHub repositories can multiply, their pages become more polished, and their features become more complex.

How much of that visible output has turned into transferable, reusable abilities they can exercise independently?

I think that question deserves a serious answer.

The number of completed projects cannot provide it on its own.

04 | If AI is an external brain, I need to know what I am borrowing

I don’t object to relying on AI.

Quite the opposite: I think it is a valuable extension of what a person can do.

People have always used external tools to extend their abilities.

Calculators mean we don’t have to perform every calculation by hand.

Search engines mean we don’t have to remember every fact.

Navigation means we don’t have to know every road before leaving.

AI now goes further, helping us write, design, analyze, and program.

I don’t think refusing AI is necessary to prove that someone’s abilities are real.

But different tools may affect us differently.

When I use a calculator, I usually know what I want to calculate.

When I use navigation, I at least understand where my destination is.

When I use AI to code, I sometimes don’t even know what I should check.

That is the part that deserves closer attention.

I may be borrowing a tool to judge whether a task was completed correctly, as well as to complete it.

Without enough knowledge to verify the result, it is easy to mistake the AI’s confidence for reliability.

A system saying “fixed” doesn’t mean the problem has disappeared.

A model saying “the code is fine” doesn’t rule out hidden risks.

This reliance needs particular care when a project involves user data, privacy, payments, or other functions with real consequences.

Having my abilities amplified by a tool does not automatically transfer my responsibility to it.

If I give real users a seriously flawed product, I cannot treat those flaws as someone else’s concern simply because AI generated the code.

This is one of the aspects of AI coding I feel we most need to take seriously.

It makes creation easier, but judgment and responsibility remain difficult.

05 | What, then, should I learn?

I have wondered whether I should stop using AI for a while and learn programming systematically from the beginning.

Follow a more traditional computer-science path: a language, data structures, algorithms, then frameworks and engineering practice.

That is a reasonable way to learn.

But I am reluctant to give up the opportunities for practice that AI has opened.

Often, my motivation to learn comes from a concrete problem rather than an abstract topic.

I want a page to support an interaction, so I need to understand events and state.

I want to save user input, so I start learning about storage.

I want other people to visit the website, so I have to investigate deployment, domains, and servers.

These ideas don’t arrive in isolation.

They connect to actual tasks.

I am therefore leaning toward a compromise.

Keep using AI to complete projects, while moving beyond describing requirements and copying results.

Before changing a feature, for example, I can try to understand which files, components, and data flows are involved.

After AI produces code, I can look beyond whether the page changed and ask why the key changes work.

When an error appears, I can read the message and form an initial view of where the problem might be before immediately handing everything to AI.

For frequently used logic, I can try writing a simple version without AI.

For complex features I cannot yet verify, I can explicitly acknowledge that they exceed my current understanding and control.

These sound like basic things.

They may even slow down what was previously fast Vibe Coding.

But I am starting to feel that this slower pace needn’t be a loss.

If every development session is only about finishing quickly, I may accumulate more and more projects while remaining at roughly the same level of understanding.

I hope to improve at more than asking AI questions.

I also want to gradually understand its answers.

06 | What remains after a project is finished?

Later, I began evaluating my projects through a different question.

I ask more than “What did I make?”

I also ask: After finishing this project, what do I remember without looking at the code or opening an AI tool?

Can I explain its core flow?

Do I understand why I chose this technical approach?

Do I know where things are likely to go wrong?

If I added a feature, could I roughly identify what would need to change?

If I started again, what could I do better?

These questions matter more than counting lines of code.

AI can produce those lines in minutes. Understanding why a system works the way it does takes longer.

Implementing a feature does not mean I have mastered the relevant knowledge.

Equally, a project can be worth completing before I fully understand every technical detail.

I still believe practice has value in itself.

For someone without a traditional technical background, turning a vague idea into a concrete prototype already opens access to problems that were previously hard to approach.

That value just needs an accurate description.

I can say that I used AI tools to complete a product prototype.

I can explain which requirements, interaction designs, tests, and revisions I was responsible for.

I can also be honest about which code depended on AI generation and which engineering questions I still need to study.

I don’t have to package every outcome as evidence of independent development ability.

A credible account doesn’t require pretending I can do everything.

07 | Knowing what I cannot do may be part of real ability

I used to think learning was about mastering more and more things.

Learn a language, become familiar with a framework, develop a complete application.

As AI tools improve, that view is changing.

I now think ability includes knowing when a task exceeds my capabilities, as well as knowing how to accomplish it.

I can build a demo prototype without being able to guarantee it is suitable for large numbers of real users.

I can ask AI to implement an interaction without understanding every security risk it introduces.

I can explore several technical directions quickly without acquiring professional depth in each of them.

Acknowledging these gaps doesn’t deny the effort already made.

It helps me work out what I need to learn next.

It has also made me reconsider learning itself.

We have often judged whether someone mastered a skill by whether they could complete a task independently.

As AI participates in more work, that standard seems less sufficient on its own.

Someone unable to write all the code independently may still understand requirements, break down systems, and validate products well.

Someone fluent in programming may still struggle to judge which problems are worth solving.

These abilities shouldn’t replace one another.

And one ability becoming easier to access doesn’t make the others unimportant.

For myself, I hope to develop a more complete combination.

To identify worthwhile problems and understand how their solutions work.

To improve efficiency with tools while retaining the independent verification skills I need.

To explore new technologies and recognize when professional help is necessary.

That may fit what I want to do better than simply counting how many programming languages I know.

08 | I don’t want to remain someone who only describes requirements

By this point, I find myself less concerned about whether AI-generated code “counts as mine.”

At least, it is no longer the most important question.

What matters more is the work I take responsibility for and the abilities I acquire along the way.

If I keep describing requirements while handing implementation, testing, and every judgment to AI, receiving a complete product at the end hardly means I understand it.

But if I gradually learn the system’s structure, understand key logic, identify problems, verify results, and maintain and improve the project, AI can become part of how I learn and practice, as well as a way to finish tasks.

I don’t think everyone must become a professional programmer.

Nor do I think every product builder will need a complete software-engineering education.

For myself, though, I want to move beyond being able to describe an idea without being able to judge how it is implemented.

Understanding more technology gives me more choices.

I can assess an idea’s feasibility more accurately.

I can anticipate some implementation constraints during design.

I can have deeper conversations with engineers.

I can see more clearly how far a prototype remains from a dependable product for real use.

Most of all, I don’t have to place every judgment in the hands of AI.

I still often need AI to help me write code.

I still ask many questions when I encounter unfamiliar technology.

Some error messages still take repeated reading and research before I understand them.

None of that prevents me from continuing to learn.

I am not in a hurry to use a title to prove what kind of person I have become.

Perhaps I will develop stronger engineering skills over the next few years.

Perhaps I will focus more on product design, needs research, and bringing applications into real use.

Those directions remain open.

Whichever path I take, I hope to understand what I am doing more clearly over time.

AI can help me write code I don’t understand yet.

I want what I cannot understand today to become something I truly understand tomorrow.

---

October 2026 · A reflection on learning, tools, and ability

This article records my thoughts from using AI tools in real project development without a computer-science degree. It is neither a rejection of Vibe Coding nor a universal method for learning technical skills.