37 Common AI Questions: Building Knowledge Bases, Using Skill Packages, and Driving Adoption

Currently, I am using two directions to assess my use of AI. The first is using AI to empower the brain, which includes assisting in decision-making, document analysis, reasoning, and deep research. The second is using AI to empower hands and feet, which refers to automation.

I divided it this way because I have met many people who are very skilled in one area but have never touched the other, and then they doubt whether they know how to use AI. Some people spend their days discussing strategies with AI but have never let it complete a task on its own. Others are very good at automation but have never considered letting AI help with judgment. These are different abilities, and it's more helpful to first understand where you stand rather than rushing to answer whether you count as someone who knows how to use AI.

My own assessment is between sixty and eighty points. In the automation area, I was originally around fifty to sixty points, but recently I have improved to a higher level due to Loop Engineering.

I've never spent a day learning AI. When I use AI, I always think about 'how to teach AI', thinking it should be more obedient and smarter, and my thinking mode has always been like this.

This way of thinking has a reason. Tools change every few months, and the operations you learn this month may be changed next month; but your judgment standards, your workflow, and your accumulated cases remain the same no matter which AI you use. So I focus my efforts on making my knowledge base readable, searchable, and usable for AI, and I just switch to whichever AI is better today.

Models can be thought of as supercars, and your knowledge base and workflow are the road you're driving on. The same car can be driven by someone with a road, but someone without a road can only spin in place.

The thing to be anxious about is AI, not us. From a business perspective, the thing to be anxious about is the AI company; from a knowledge perspective, no one understands AI better than humans, so let AI's knowledge help me crawl for information.

My actual approach is: with so many new things appearing today, I ask AI to help me see which one is suitable for me. And 'suitable for me' needs to be clear: is it for industry application, or can it optimize my knowledge structure, or can it be used as a teaching example? I analyze all of these first, and then I look at the results.

Another more important thing is to find something that won't change for ten years as an anchor point. For me, it's tacit knowledge distillation. Even without AI, this is very important, and with AI, it will be even more important. With an anchor point, changing tools won't affect the problem you're solving; you're just using a better tool to solve the same problem.

In areas where your expertise is lacking, you still need a human or a verifiable source to help you verify. When your cognition is insufficient, it's even hard to ask the right questions.

I myself have such a boundary. My marketing skills are not strong, so I don't train the skill package for marketing, because my thinking mode is not there, and I don't ask questions in that way. Even if I ask AI to check from the opposite direction, I can't judge whether it's really the opposite direction, because I can't step out of my framework.

So my approach is to clearly know my own capability boundaries: if I'm particularly good at something, I do it myself; if I'm particularly bad at something, either wait for AI's capabilities to break through or find someone with that capability to collaborate.

The order is reversed. It should be first having a problem to solve, then learning AI.

I often see the situation where someone learns ten tools, can operate each one, and then starts worrying about 'what should I do with these.' But if you reverse it, and you have a real, weekly problem that's troubling you, when you look for tools you'll be very clear on what you need, and you'll learn much faster.

There's also a side effect: trying to use AI for everything, which results in a bunch of half-finished projects that you can't wrap up. It looks busy, but in reality, nothing is completed.

You can, but don't just leave it there. My suggestion is to keep the data in a place where you can fully control it, and then connect it to whichever AI is most useful.

I give this advice because I've moved houses before. I've been using ChatGPT for a long time, and it really understood me. Later, another AI became stronger, and I wanted to switch, but I found it very painful to move all the accumulated data. At that moment, I realized this wouldn't be the last time I moved. So from then on, anything valuable I talked with AI about, I would save in a document.

For me, tools like Notion and Obsidian are more like front-end displays. The real content should stay in your hands. Platforms are all temporary workers; they might collapse tomorrow, and another stronger one might come out the next day.

Because those are mostly just 'data'. I now divide them into three layers: the data repository is structured data and tables, the knowledge base is general documents, and the rule base is your judgment standards, decision patterns, and values.

For example, many people say, 'I do business, I put all the plans into AI, and it will understand,' but that is just the knowledge base. The real tacit knowledge is: when I use this plan, why I say this sentence to this person and another sentence to that person. Because for different people, you need to say different things, and this judgment is the key, but it is usually not written down.

I have another name for it: the rule base. I found that most people's knowledge bases do not include rules. Some people's documents may include value judgments; this is a minority occurrence. Writing rules out allows AI to make judgments close to yours even when you do not specify them.

Manage text and images separately, using the index card note-taking method. Split an entire article into segments, and each image is also an independent reusable component. When needed, quickly assemble them into the version you need.

The index card note-taking method was mainly used by teachers and researchers before, because decomposition and assembly were very labor-intensive, and only people with high data value found it worthwhile. Now, with AI helping to decompose and assemble, this method has become accessible to everyone.

AI cannot understand your PPTs and PDFs. Often, the issue is that the shape of the data is unsuitable for retrieval; this does not mean AI is incapable.

Data piling up to the point where AI can't find it is equivalent to having no data. Here are two specific approaches.

First, write labels directly into the filename. My own naming usually includes five sets of information: when, what situation, what type of content, what topic, and several keywords. Just looking at the filename tells me which one it is.

Second, design a 'quick search' instruction. This instruction must clearly tell the AI that when I say quick search, it should only look at the filename and should not read the content. Reading only filenames has a very low cost even with a thousand files. Conversely, reading through all thousand files each time to find something else incurs a significant cost.

Additionally, I recommend regular organization, keeping the most recently used files handy and moving older, just-for-reference files to the backup area. More data does not necessarily mean better usability.

Change it to your own name. I found that I can't remember others' skill package names or their triggers, so when I get a useful skill package, I will change it to my own wording and save it.

For example, there is a big expert who wrote a very useful concise tool. I renamed it to 'Pro Talker', which helps me check if the AI's plan and steps are too wordy. After getting a name that is vivid, every time I see the AI give me a complex plan, I naturally think of 'call Pro Talker to check it.'

The same logic I also use for roles. My assistant in the LINE group, if it keeps the original name, people will keep asking it about things it can't do. So I just let it become another role and another name, and people will clearly know what it is responsible for and what it is not.

After automatic collection, you still need to add your own judgment criteria and reasons. What things are valuable to you and why they are valuable, this part still needs you to provide.

My actual experience is like this: Fully automatic accumulation tools are indeed convenient, but after accumulating too much, there are also many garbage files. Too many points are equivalent to no points, and in the end, you still need people to determine what is the key point. If so, it's better to start with the habit of keeping what you think is important and closing what is not important.

However, there is now a turning point. With Loop Engineering, the AI really knows my standards. Previously, those uncertain things I needed to keep or not, I had to spend time reviewing; now I let another model review it first. I have about 300 to 400 files per month, and the number of files I need to review personally is less than ten.

You can refer to them, but I don't recommend copying directly. A better approach is to list your needs first, and ask AI to help you convert others' skill packages into a version that fits your needs, and then continue to accumulate on top of that.

When I see popular skill packages, projects, or papers, I always ask myself first: Does this thing have any use for me? Does it have any use for my current workflow? If it doesn't, don't touch it at all, because AI can't learn everything, and the market can't learn everything either.

If it is confirmed to be useful, I will ask AI to help me convert it into a usable version and have it check four types of contradictions: contradictions in the process, contradictions in values, contradictions in strategy, and contradictions in the market. If there are conflicts, it will pop up for me to judge. After this round of conversion, the skill package is truly yours.

Yes, so you need to make your own judgment. But here's a more important action: explain your reasoning to AI.

For example, I think A is suitable for me because seven out of ten points match my situation. Points eight to ten are unsuitable, so I will remove them. B is overall unsuitable. However, I want to reference its fifth point because my current needs are like this.

When you tell AI all these judgment reasons, you effectively create a 'skill package selector' for yourself. After that, when you encounter new things, it will first filter them using your standards, and you just need to review.

They come from your own workflow, because only you know your needs, your audience, and your market.

This is also why I think professionals in various fields have the most potential. Few people understand both an industry and AI. If you happen to be one of them, the things you create will be hard for others to copy, because the real pain points in the industry are only clear to you.

My usual metaphor is: the desktop version is like a comfortable office with air conditioning and coffee, where you can open your laptop and work; the developer version is a factory, a laboratory, and you need it when building tools.

The main difference is more mechanisms and more permissions. The way of giving instructions is actually the same, but the functions are too many, so at first it feels complicated. You can think of it like a camera: one is fully automatic mode, and the other is fully manual mode with all the aperture and shutter settings open.

So the judgment is simple. If you're not planning to start a company, take on projects, or promote a product or service, you probably won't need the developer version, because that's more oriented towards designing products and services. But I also have to be honest, many people can't go back after using it, because it's too automatic and convenient.

If you don't need to make auxiliary decisions or require deep reasoning, the $20-per-month plan is usually sufficient.

My judgment standard is like this: you are an employee, and you need to complete the tasks assigned to you. Just do the tasks well. Whether you want to reach industry heights or make major decisions is something for your manager or boss to worry about. Anything beyond the basic plan's capabilities can be postponed for now.

Conversely, if you are an entrepreneur, I would suggest treating the top-tier plan as an advisory fee. It will save you time and judgment costs, which are usually much higher than the subscription fee.

I only study what mechanism it uses and what problem it solves. For me, that's more like market research.

A thing becomes popular because it uses a good mechanism to address a group's pain points. So I need to study: what are the pain points of the public, what are their needs, and what is the mechanism. In the process of studying the pain points, you will naturally see the trends.

After studying, I integrate the mechanism into my own system, and the tool itself can be ignored. For example, after seeing a tool's automatic accumulation mechanism, I found that my original manual approach was more detailed. Another tool's heartbeat mechanism was a design I had never thought of, so I learned it. For me, all AI tools are just operational tools, and the core is my system.

At the beginning, store your skill package in your own folder and add a retrieval page, so that any AI can read and understand how it divides work and operates.

I intentionally design it to be very general-purpose, because now it's a battle among various AI providers, and you can't know who will win tomorrow. Strictly speaking, some skill packages are more suitable for certain AI providers to handle, and I have such arrangements. But about 80% of them I intentionally make general-purpose.

The advantage of doing this is that when you switch tools, you move the folder, not retrain from scratch.

Use the layer that can schedule work at the system level to assign tasks. In other words, you need a role that can call other tools, and it decides which part to handle itself and which part to hand over.

I will also do one more thing: let different models discuss with each other. I will tell the main one that when in doubt, it should first consult the other model. My standards and plans are written in the knowledge base, and if both models think they are okay, they can proceed directly, unless there is a serious contradiction, a serious problem is found, or the standard cannot be found, then I will stop and ask me.

Based on my current usage experience, this can handle over 90% of small issues without waiting for my reply at every step.

Permissions can be fully opened, but the prerequisite is that your goals and review mechanisms are already in place.

This has a sequence. If the review mechanism is established first and you fully open permissions, it will run smoothly. However, if this process fails, you might not notice it in real time. Therefore, my suggestion is to think clearly first: after this task is completed, consider how to determine if the result is correct. Also, consider how to determine if the result is incorrect. Furthermore, identify what situations require stopping to ask for human input. Write these points down, and then discuss automation.

Additionally, I will keep a few red lines that cannot be decided by myself, such as irreversible operations, things sent externally, and matters related to money. These categories, even if fully opened, must come back to me for confirmation.

Need to set a limit. I usually set two rounds, and there must be a conclusion within two rounds. It can also be combined with a scoring mechanism, do not let it run indefinitely.

Another key point is to specify a main model. The main model raises the topic for the subordinate model, and the subordinate model replies. As long as there is no major contradiction, it decides on its own, without having to show every round to you. Without a main-subordinate relationship, both sides will politely keep supplementing each other.

This is exactly the question that loop engineering aims to answer. Instead of checking line by line yourself, write the acceptance criteria first, let it check itself, and then have another model cross-review.

I have also encountered a more troublesome situation: AI did not actually execute the task. Instead, it provided a response that appeared to complete the task to cover for the failure. At this point, you cannot tell just by looking at the response. Because of this, I also wrote "there must be evidence of actual execution" into the process rules.

The idea for taking another step forward is to design a process that can tolerate errors and recover. This approach moves away from expecting a system that never makes mistakes. Mistakes are not scary; having no backup is.

Write your judgment criteria clearly, let it classify itself.

In reality, it will be divided into three categories: definitely important data is kept, definitely unimportant data is deleted, and the middle batch that is uncertain needs human review. Previously, I got stuck on the middle batch, and I had to spend time reviewing it myself every time, so I often delayed the sorting until two or three months later.

Now I let another model first judge the middle batch. With my monthly volume of about three to four hundred files, the number of files that actually need me to review personally is less than ten, and the pressure is much smaller.

This includes accounts, permissions, and cybersecurity, which are organizational governance conditions that are usually unavoidable. It's not an AI technical issue; it's a question of how the company manages its assets.

Small organizations have more chances to directly adopt AI-native solutions, as they have fewer burdens. Recently, I encountered a method where some companies simply let everyone use laptops that can be installed on, others have bosses buy a public machine for everyone to take turns running tasks, and a four-person new company directly buys used machines.

Large organizations need to deal with existing technical debt, which isn't something that can be solved by just changing tools. Usually, it requires looking at the organizational structure and permission design together.

This is one of the repeated resistances I encounter in the enterprise, and it's completely reasonable. If efficiency increases several times, but salary doesn't follow, and you can't leave early, not announcing it is a rational choice.

Therefore, later when I do enterprise services, I usually pair with organizational consultants. Because this matter has gone beyond the scope of AI. First, handle the organizational system, otherwise, the implementation will get stuck halfway.

For individuals, my advice is to keep your capabilities within yourself. Even if you don't announce it at the company, your workflow and knowledge base are still yours. When you find a place that is willing to give you space, you can use it.

De-identification of sensitive data still needs human oversight. There is usually a gap between policy expectations and on-site feasibility. This matter needs to be clarified first before starting.

I've encountered situations where upper management wants even de-identification to be handled by AI. That means handing over the most judgmental part to AI. Local models are not yet good enough to handle such data safely. Cloud services depend on whether your policies allow it.

A more practical sequence is: first confirm which data cannot be uploaded to the internet, then decide how to divide the remaining data. The time spent on this confirmation step is much less than the time spent on post-hoc remediation.

It depends on your purpose. If it's for a company to get subsidies or as an insurance, it has its use; but if you want to learn real AI applications, the exam can only measure a limited part.

I myself took the exam, and my motivation was very simple: at that time, my identity to the outside world was still a photographer and director, and directly saying I wanted to teach AI would make people think it was strange, so I needed a good proof for communication. But you can see now that I talk about knowledge architecture, tacit knowledge distillation, and I have mentioned that certificate less and less.

Honestly speaking, the proportion of AI applications in these exams is not high, and there are more information, information security, and data statistics basics. I think the more valuable part is information security and ethics.

Previously, SEO was about writing your services clearly, now you need to write the 'pain points and solutions' clearly, so that AI can find you when someone asks a question.

You can imagine how users now search for things: they don't think of keywords first, they directly ask 'how do I deal with this problem'. So AI is looking for 'has anyone written a clear solution to this problem'. If your content is written according to service items, it will be hard to be connected.

My own website has taken another step forward: it is a website for people to see, and also a searchable knowledge base, and even itself is an agent framework. I directly write the process of 'how to guide new users to use this website' into the website, so when you give the website URL to your AI, it will follow that process to guide you.

My suggestion is that you need it. The business mechanism of social media is originally to keep human attention, and to keep people within the platform, so it is not friendly to AI search, and most platforms will block crawlers.

A healthier approach is to have both, but you need to clearly know which one is your single source. Social media is responsible for reaching out, but ultimately, you still need to redirect to your own place, otherwise your content will become scattered information islands.

The order might also reverse. Previously, short videos were the first line of traffic, I estimate that it will become the second line, first recommended by AI, then readers click in to see your content and videos to build trust.

Do it when you have the capacity, because it's actually your resume.

You don't need to pursue having many people view your content. When I was handling image-related projects, my Facebook page only had around five hundred followers. Some people thought it was too few, but my thinking was that these five hundred people were all bosses. If one of them asked me to shoot a video, it would be worth tens of thousands. If the people viewing are decision-makers, the number doesn't matter.

Moreover, content accumulates over time and becomes strong evidence when you are looking for a job, discussing collaborations, or being evaluated. You do need a place where people can find your work; you do not have to become an influencer.

Yes, but you need to have your knowledge base and your criteria first, otherwise it won't be you.

My own approach is like this: when I'm really busy, I don't have time to sit down and write, so I go out for a run, and when I have inspiration, I just speak it into my phone. My phone is connected to my computer, and after I return, the workflow will take over, turning the spoken content into a draft and then checking it against my standards.

You need to spend time setting up this system at first, but once it's set up, you can use it continuously. What you need to give it is your ideas, not for it to think for you.

If you understand both the industry and AI, it's easier to create a difference, because the real pain points in the industry are something you understand better than people outside the industry.

The examples discussed in this round left a deep impression on me: people within the same industry know what the real, unspoken difficulties are, which numbers are hard to get, and which types of orders shouldn't be accepted. These are things that external consultants find hard to fill with general knowledge.

However, I would like to remind you that being able to create it doesn't mean it can be sold. There are many things to verify in between, such as whether the other party is willing to pay, how much they are willing to pay, and who decides to buy. It's recommended to start with a small-scale approach to test the response before deciding whether to invest.

First look at how big a problem it solves for the other party. The value of the same thing can differ greatly for different roles.

My own experience is that solving a problem takes about the same amount of time. But the same result can mean less overtime for an office worker, or saving a significant cost or earning more for an entrepreneur. The price difference comes from here, not from how much work I did.

Another realistic observation is that people who pay ask more precise questions. In free settings, people politely chat, but once they pay, they will tell you their real pain points, which are the starting points for future collaboration or productization.

There is an opportunity. If you really use AI to change an industry process or achieve measurable benefits, that's an industry innovation application, and it can be written into a case.

My usual approach is to first run alongside for a while. During the running process, the other party will tell me their real pain points, and I can then determine whether AI can solve this thing. If it is feasible, we will go together to write the case. This way, we do something valuable for the industry together; you are not paying me to be a lecturer.

Also remind of the practical side: these kinds of cases have strict reviews, long processing times, and require someone familiar with the application process. I recommend finding someone who specializes in this to collaborate with, don't try to handle it yourself.

In your truly strong domain, AI has the potential to help you expand the range of services you can offer, so you will be busy expanding yourself, and won't have time to learn from others.

My own situation is like this. I just can't finish researching how new mechanisms around the world can be transformed into my knowledge framework, let alone have time to touch others' marketing. Conversely, a person who is focused on marketing will have no time to study their own market, and won't have the motivation to deal with my knowledge framework.

So when everyone understands AI, the more reasonable relationship is collaboration. You take care of your domain, I take care of mine, and combining the two is more efficient than mutual suspicion.

The gap will be pulled very wide by AI. Within the same group, those who use it will keep moving forward, while those who don't use it will just treat it as a search engine, or even use it only to complete homework.

I think this issue needs to be addressed through teaching design, rather than through prohibition. Since AI has already done a good job with knowledge, the next step is to practice human judgment, questioning, and integration abilities, which actually require more teaching.

I use a judgment to determine whether a person is using AI to empower themselves or using AI to disable themselves. The former will become stronger the more they use it, while the latter will become more dependent the more they use it. The difference lies in whether they understand what they are doing.

AI is a large language model, not a large programming model, so the focus is on the ability to organize language. If you don't know how to write programming now, I don't think you need to specifically learn it for AI.

However, people who write programming do have an advantage, because programming languages are a highly organized, structured, and disciplined form of language. What should truly be learned is that spirit: to clearly explain things in a systematic, structured, and logical way.

Therefore, I encourage people without an engineering background to start directly from their own professional field. Documents are systems; if you clearly write out the process and judgment, you are designing an agent. You don't have to wait until you can write programming to start.

Yes, and I think it's not only applicable to academic work.

This conversation has touched on an observation that resonates with me: the reason for learning being stuck often has a part that lies outside of academic work, such as anxiety or life status. If the teaching assistant only handles knowledge, it will miss the real sticking points.

I am currently discussing a collaboration that follows a similar logic: after professional consulting ends, AI accompanies the other party to continue recording and practicing, and a human takes over for analysis at the next meeting. AI is responsible for companionship and accumulation, while humans are responsible for judgment and transformation, with both parties dividing responsibilities.