Liwei Su

Today, when I was learning how to write a simple article time-estimate plugin in JS, I burned out. The reason was: I didn’t know how to learn a programming language.

Until I wrote this blog, I realized that I used to rely on just one or two learning methods: reading books + referencing roadmaps (I used to even pride myself on only reading books! What was I thinking?!). At the same time, I always firmly believed that for any piece of knowledge, there had to be a corresponding roadmap to reach it.

But I burned out.

When I think about it carefully: there is no such thing as a “roadmap.”

Let’s take learning Chinese as an example: outside of classroom learning, do we not learn Chinese? Watching comics, reading news, watching TV dramas, telling jokes with friends, acting in plays... there’s no so-called “path” here. My accumulation of Chinese knowledge feels more like planting seeds everywhere and letting them grow.

Now, let’s take the development of human science as another example:

Alexander Fleming accidentally discovered in 1928 that penicillin could kill bacteria.

Wilhelm Röntgen, in 1895, discovered a type of radiation capable of penetrating objects while studying cathode rays.

Arno Penzias and Robert Wilson, in 1964, accidentally discovered cosmic microwave background radiation while trying to eliminate noise from radio signals.

Damn, no wonder I couldn’t learn anything properly. It’s because of this.

I just used Bing to search for a webpage, and it showed me “No relevant results.”

But after I switched to a US IP, everything was fine.

I’ve always been troubled by the lack of a systematic way to take notes, and today it suddenly occurred to me that maybe I could develop a simple app focused on the top-down note-taking method and sell it.

Wait a sec, isn’t that exactly what OneNote is? Wow, I’ve turned into a Microsoft fan.

As the saying goes: “Don’t use AI unless you know what the heck it’s talking about.”

That’s true—today I used AI to help with my project, but later realized it was just talking nonsense, so I stopped using it.

Some advice after using AI like Grok and ChatGPT:

Don’t assume it’s reliable.

Only use it for repetitive tasks.

First Thought

After taking a shower, an idea popped into my head: life feels like continuous reasoning.

I used to think that constantly thinking was too abstract. But after giving it some thought, I realized that replacing it with constant reasoning makes it much easier to understand.

For example, in a MOBA game, we would calculate when the enemy will respawn and where they are most likely to go. How should we ambush them? How do we move the enemy? How do we force a team fight?

Or, for example, when managing a publicly listed company, the boss’s mind must have a mental picture that includes constantly changing information: the stock market, domestic and international markets, customers, competitors, employees, etc. From this, they can deduce a path for the company’s development.

This kind of reasoning, in my view, is about using limited information to infer an infinite number of details and events, then reconstructing a picture that matches your expectations.

To Elaborate…

Then I understood why technical roles will never be as high-ranking or well-compensated as leadership roles, because leaders have to handle far more information than technicians do.

Technical roles deal with things. Even though people might be involved, they add a lot of uncertainty. However, things give very limited and obvious results, so it’s easier to exhaustively check and analyze.

But leaders deal with people. The results are influenced by human nature and external circumstances, and they are nearly infinite and unpredictable. Often, it requires deep experience and logical deduction to make sense of them.

Many engineers have a poor impression of those higher-ups, but the truth is, those leaders are handling much more than you.

Once you become a leader yourself, that impression will change.

I’d like to share a learning flow that I’ve been using recently and feel works well for me: understand the MVP (Minimum Viable Product) → read books and organize a knowledge map → practice a project similar to the MVP → summarize.

I have to thank a friend of mine at Huawei for pointing this out to me: “People can’t learn things they don’t know.” I also read The One Thing, and I’ve benefited a lot from the book’s method of focusing on the most important points.

Background

When I was in elementary school, I dreamed of having an AI butler like Jarvis from Iron Man. However, I always thought it was unrealistic.

Now, I feel there’s a bit of hope. Although APIs are still expensive and AI is still quite primitive, time can smooth these things out.

What’s Needed

Embedded systems, databases, large models… There’s a lot to learn and do. For now, I’ll start by mimicking Xiaomi’s products and go from there.

Background

This is the first of three projects this month: building a customer service AI for the company website.

Process

Before starting the project, I had a rough goal in mind: the AI should be able to answer most of the questions visitors ask about the company, and it needs to be both accurate and fast.

At first, I wasn’t familiar with Dify, so I copied the official documentation structure into a mind map. When I was unclear, I would use the mind map to focus on the key points.

I began by practicing with an example project from the official website. However, when I tried to adapt it to my own use, I found the AI’s responses were slow and chaotic. After a whole day of work, the issue was still unresolved. It wasn’t until I got home that I realized: I shouldn’t have used multiple branches! This is a very simple customer service AI scenario—there was no need for multiple branches. Additionally, the knowledge base was definitely problematic.

The next morning, after removing the multiple branches, the response time improved significantly. I also reorganized the knowledge base structure and selected a different large model. The final result was OK: fast and able to handle light usage.

Conclusion

When building applications with Dify, keep the following points in mind:

Knowledge Base and its Processing: Don’t always rely on crawlers. When there’s no budget, using PDFs directly makes more sense. Also, Dify’s document splitting still has issues; after splitting, always check and revise it. Adding tags and writing good knowledge base descriptions will make the AI indexing more accurate.

Logical Structure: Logic that doesn’t fit the specific scenario can increase response time.

Choosing LLMs: Select the LLM based on the business scenario. Don’t blindly trust a few specific LLMs.

Continuous Debugging: Quick failures → quick adjustments → quick failures also applies here. After making a change (e.g., to the knowledge base or LLM), test it quickly, see how it works, and analyze the core issue.

There are definitely patterns to building these kinds of applications. Figure out the Minimum Viable Product (MVP) and focus on implementing that first.

Pending Issues

I don’t know how to stress test an AI application. What happens when more than 100 people use it at once? I’m not sure. But does Dify really have use cases for AI applications with over 100 users? I’m skeptical.

I don’t know the essence of AI. Even though I only need to call the interface, understanding it would allow me to see the core issues, like why switching the logic resulted in faster response times, etc.

I don’t understand why, even though the knowledge is in the knowledge base, the AI can’t find it. For example, the company address is in the knowledge base—I've added all the descriptions and tags—but the AI still can’t find it. In the end, I had to copy and paste the address into several other split sections, and then it worked.

我之前想去 SpaceX，后面想一下还是进国内的航天公司吧。

别人的永远是别人的，自己的永远是自己的。

Recently, I switched away from Arch Linux and returned to Windows. This time, it’s pretty much a permanent farewell.

I used to stick with Arch Linux just to deliberately stand out: i3, various quirky components, niche command-line needs… Looking back, it feels kind of silly.

When a tool needs to be persistently used, it means that tool has already lost its purpose.