English version

You think using AI means throwing a request at it and waiting for results.

That's the least effective way to use it.

Here's how most people use AI coding tools: Open the chat, type "build me a user authentication system," and watch the agent generate code from scratch. The code comes out. It doesn't run. Debug, tweak the prompt, regenerate. Still broken. After a few cycles, you start wondering: Is the AI bad, or am I?

Neither. You're just using it wrong.

There's a principle that's been around long before AI: "Don't reinvent the wheel. Whatever problem you're facing, someone has already solved it." This is usually applied to learning—don't stumble around in the dark when answers already exist. But few people realize this principle applies equally to how you use AI.

When you ask AI to "write code from scratch," you're asking it to do the thing it's worst at: making choices in an infinite possibility space.

Think about what's hidden behind a simple request like "user authentication system." Which framework? JWT or sessions? How should passwords be hashed? What's the refresh token logic? How do you handle errors? Every decision point is a guess. The AI has to infer your intent from five words. When it guesses right, that's luck. When it guesses wrong, that's a bug you'll spend an hour debugging.

And what does the AI base its guesses on? The "average answer" from its training data. It gives you something generic, reasonable, unlikely to catastrophically fail—but also unlikely to fit your specific context. It's like asking a consultant who knows everything but nothing about your company: "How should we do marketing?" They'll give you an answer. But it's an answer for the average company, not yours.

The problem isn't that AI isn't capable enough. It's that your input isn't specific enough.

Try a different approach.

Before you ask AI to build anything, go find a reference implementation that's already been validated. GitHub has millions of open-source projects. Find one that's well-written, stylistically clean, and logically sound. Spend ten minutes understanding its core structure: How is the code organized? What's the authentication flow? How does it handle edge cases?

Then feed that reference to the AI. Tell it: "Use this implementation as a reference for structure and style. Adapt it to my project. My stack is X. My specific requirements are Y."

You'll notice the output quality jumps dramatically.

Why? Because you've shifted AI's job from "create within infinite possibilities" to "adapt within defined constraints." You've given it an anchor, a frame of reference. It no longer needs to guess your preferred style—you've shown it through a concrete example. It no longer needs to design architecture from scratch—the architecture exists, it just needs to translate.

This is "imitation thinking" applied to the AI era.

Imitation isn't plagiarism. Imitation is acknowledging that in most mature domains, optimal solutions have already been discovered. Your job isn't to reinvent the wheel—it's to understand how the wheel works, then mount it on your own vehicle. AI is a powerful installation tool, but you have to show it what the wheel looks like first.

This approach generalizes to almost every AI use case.

Want AI to write an article? Don't just give it a topic. Find three articles in the same genre that you think are well-written. Analyze their structure: How do they hook the reader? How do they build arguments? How do they close? Then tell the AI: "Follow this structure and rhythm. Write about X."

Want AI to design a product feature? Don't just describe requirements. Look at how competitors handle it. Gather screenshots, flow diagrams, even code logic. Tell the AI: "Here's how Product A does it. Here's Product B's approach. I like A's interaction design but B's technical implementation. Combine them and adapt to my context."

Want AI to analyze data? Don't just throw it a spreadsheet. Find a few analysis reports in the same domain. See how others present findings, which metrics they focus on, what visualization styles they use. Then tell the AI: "Use this report's framework. Analyze my data."

Every time you give AI a concrete reference, you're helping it narrow the search space and increase output predictability.

There's a deeper benefit too: this method forces you to learn.

When you research existing implementations to feed the AI, you're building your own understanding of the domain. You start noticing things: "Oh, this architecture has these advantages. This is how you handle that edge case." These insights accumulate into judgment—the ability to evaluate whether AI's output is actually good.

Many people worry that using AI will make them dumber. That fear is valid in the "throw request, wait for result" mode—you genuinely learn nothing. But in the "find reference, understand it, have AI adapt" mode, you actually learn faster. You have a tireless teacher (the AI) who will explain any part of the reference code you don't understand, without ever making you feel stupid for asking.

So here's the actually effective way to use AI:

  1. Define the problem you're solving
  2. Find validated reference solutions
  3. Spend time understanding the core logic of those references
  4. Use AI for adaptation and synthesis, not invention This isn't laziness. This is leverage.

You're not the first person on Earth to solve this problem. Accept that. Then use the wisdom of those who came before, and let AI help you adapt that wisdom to your specific situation.

That's how you actually win in the AI era.

Chinese version

你以为，使用 AI 就是把一个请求扔过去，然后等结果出来。

这其实是用 AI 最低效的方式。

大多数人是这样用 AI 编码工具的：打开聊天框，敲一句「帮我做一个用户认证系统」，然后看着智能体从零开始生成一堆代码。代码出来了，却跑不起来。开始调 bug，改提示词，重新生成。还是不行。几轮下来，你可能开始怀疑：是这个 AI 不行，还是我不行？

都不是。只是你用错了方式。

有个原则，在 AI 出现之前就已经存在很久了：「不要重新发明轮子。你遇到的绝大多数问题，别人都已经解决过。」

过去我们把这条原则用在「学习」上——不要在一片黑暗里乱撞，当世界上已经有现成答案的时候。但很少有人意识到，这条原则同样适用于：你应该如何使用 AI。

当你让 AI「从零开始写代码」时，其实是在让它做一件自己最不擅长的事情：

在一个几乎无限的可能空间里，自己做所有选择。

想一想，「做一个用户认证系统」这几个字背后，藏着多少分叉：

  • 用哪个框架？
  • 用 JWT 还是 session？
  • 密码怎么哈希？
  • 刷新 token 的逻辑怎么设计？
  • 错误该如何处理？ 每一个决策点，都是一次猜测。

AI 只能从你那五个词里，试图「推断你的意图」。猜对了，是运气；猜错了，就是你之后一个小时要面对的 bug。

那 AI 是根据什么来「猜」的？

是它训练数据里那个「平均答案」。它会给你一个在统计意义上「还行」的方案：不至于完全炸掉，但极大概率也不适合你的特定场景。

这就像你请了一个知道世上所有公司知识的咨询顾问，却一点也不了解你公司，然后问 TA：「我们应该怎么做市场？」

TA 一定会给你一个答案。但那个答案，是给「平均公司」的，不是给你的。

问题不在于 AI 不够强，而在于：你的输入根本不够具体。

换一种方式试试看。

在你让 AI「构建」任何东西之前，先去找一个已经被验证过的实现。

GitHub 上有几百万个开源项目。挑一个：

  • 写得够好

  • 风格够干净

  • 逻辑够清晰 然后花十分钟理解它的核心结构：

  • 代码是怎么组织的？

  • 认证流程怎么走？

  • 边界情况是如何处理的？ 接着，把这个「参考实现」喂给 AI，对它说：

「用这个实现作为结构和风格的参考，适配到我的项目里。我的技术栈是 X，我的具体需求是 Y。」

你会明显感觉到，输出质量一下子提高了。

为什么？

因为你把 AI 的任务，从「在无限空间里创造」变成了「在有限约束下改写」。

你给了它一个锚点，一个参照系。

它再也不用猜你的偏好风格——因为你已经用一个具体例子告诉它了。

它也不需要从零设计架构——架构已经存在，它只需要翻译和迁移。

这就是把「模仿式思考」应用到 AI 时代。

模仿不是抄袭。

模仿的前提是承认：在大多数成熟领域，最优解早就被无数人反复试错、探索出来了。

你的工作，不是重新发明轮子，而是：

理解轮子是怎么运转的，然后把它装到自己的车上。

AI 是一个极其高效的「安装工具」，但前提是——你得先让它知道轮子长什么样。

这套方法几乎可以推广到所有 AI 使用场景。

想让 AI 写文章？

不要只给它一个「话题」。

先去找三篇你觉得写得很好的同类型文章，拆一拆：

  • 开头是怎么抓住读者的？
  • 中间是怎么搭结构、铺论证的？
  • 结尾是怎么收束、升华的？ 然后对 AI 说：

「按这种结构和节奏，来写 X 这个主题。」

想让 AI 设计一个产品功能？

不要只丢一堆「需求描述」。

先看看竞品是怎么做的，收集：

  • 截图
  • 流程图
  • 甚至部分代码逻辑 然后告诉 AI：

「这是产品 A 的做法，这是产品 B 的做法。我喜欢 A 的交互设计，但更偏爱 B 的技术实现。帮我结合二者，并适配到我的场景。」

想让 AI 做数据分析？

不要直接扔一个表格过去。

先找几份同领域的分析报告：

  • 别人是怎么呈现结论的？
  • 重点关注哪些指标？
  • 用了哪些可视化方式？ 然后告诉 AI：

「按这份报告的结构，来分析我的这份数据。」

每一次你给 AI 一个具体参考，其实都是在帮它：

  • 收窄搜索空间
  • 提高输出的可预期性 更深一层的好处在于：这种使用方式，会强迫你自己学习。

当你为了「喂给 AI」而去寻找、阅读这些参考实现时，你自己的理解也在同步建立：

  • 「哦，原来这个架构的优势在这里。」
  • 「原来这个边界情况是这样兜住的。」 这些细节，最后都会沉淀成一种能力：判断力。

也就是——分辨 AI 输出到底好不好的能力。

很多人担心「用 AI 会不会把自己用笨」。

如果你的模式是「扔需求 → 等结果」，这个担心其实挺合理的——你确实什么都没学到。

但如果你的模式是：「先找参考 → 自己吃透 → 再让 AI 适配」，那情况就反过来了：

你不仅不会变笨，反而会学得更快。

因为你多了一个永远不会烦、也不会对你翻白眼的老师——

一个你可以随时追问的 AI：

  • 「这段代码为什么要这么写？」
  • 「这个边界条件是怎么想到的？」
  • 「如果换一种架构会有什么问题？」 TA 会一遍一遍地解释给你听，直到你真正理解。

所以，一种真正「有效」的用 AI 方式，大概是这样的：

  1. 先把你要解决的问题说清楚
  2. 去找已经被验证过的参考解法
  3. 花时间搞懂这些参考的核心逻辑
  4. 把 AI 当作「改写与融合」工具，而不是「凭空创造」机器 这不是偷懒。

这是杠杆。

你不是这个星球上第一个遇到这个问题的人。

承认这一点，

然后，把前人积累下来的智慧，请 AI 帮你——

不是复制，而是适配到你的具体情境里。

这才是真正在 AI 时代获胜的方式。