A few days ago, I was chatting with a friend, and he shared something quite interesting with me.
My friend runs a business reselling tokens, primarily serving B-end clients. Logically speaking, in recent years, AI has evolved from the initial Prompt Engineering to MCP, Context Engineering, Skill, and now the hottest trend, Harness Engineering. With countless engineering practices emerging in the industry, implementing AI in enterprises should no longer be a challenge. Yet, reality left him both amused and frustrated.
While providing services to clients, he often received feedback that AI wasn't performing well. Some complained about poor coding capabilities—even though they were using top-tier models, the generated code always had issues. Others felt that instruction-following was terrible; despite clearly stating their requirements, AI would often go off track. Some even found that after integrating the model into an Agent or workflow, the results were worse than simply chatting directly in the official chatbot.
These problems baffled him because his upstream was clean, and theoretically, such basic issues shouldn't occur. So he started checking logs, reviewing call records, and consulting peers. After several days of troubleshooting, he finally discovered that the problem wasn't with the model at all.
The clients complaining about poor coding performance weren't using the model's official Coding Agent but various third-party tools. Those complaining about poor instruction-following had programmers sending AI commands like just one sentence: "Fix this bug."
As for the clients integrating Agents or workflows, the situation was similar. They simply connected the API and expected it to magically "transform" on its own, like a fairy tale. They neither designed Prompts around specific business scenarios nor defined task flows, context structures, or acceptance criteria, let alone engaged in Context Engineering or Harness Engineering.
After learning the cause, my friend was almost amused. He initially thought he was dealing with some complex model issue, but after all that investigation, he found it was a problem already discussed two or three years ago during the Prompt Engineering era. In the end, he had no choice but to record several instructional videos and send them to clients, teaching them how to properly ask questions to AI.
This story somewhat shattered my stereotype of the current state of "AI implementation" in China. Over the past few years, self-media has almost hyped AI into a silicon-based deity. Concepts like AI programmers, AI employees, AI entrepreneurs, and AI companies have emerged endlessly. Much of the promotional content wildly suggests that as long as you integrate AI, even the most complex tasks will be effortlessly accomplished.
But the problems my friend encountered tell me that many enterprises are still stuck at the most basic stage from two years ago.
I have no intention of digging into the reasons behind this "reality," nor do I feel like criticizing those self-media outlets that talk nonsense. I just want to roughly explain "how to use AI correctly."
To use AI well, you must have a sufficient understanding of the capability boundaries of large language models as tools. The AI we discuss now refers specifically to large language model technology, not some imagined omnipotent artificial intelligence or silicon-based life form. Although Anthropic keeps releasing marketing reports like "LLMs are about to gain self-evolution capabilities," the reality is still far from that. And as a tool, it inevitably has its limitations.
To put it simply, first, AI has no memory.
Large models don't have continuous, stable, long-term memory like humans. What they know depends entirely on what's in the current context. If you close a conversation window and start a new session, it usually won't remember who you are or what you talked about before. Even if some products offer so-called "memory functions," they only store some historical information and reinsert it into the context when appropriate.
In some Agents, each instruction a user sends to AI includes not only the current command but also all information in the current conversation window, along with relevant information obtained from the system's knowledge base, memory system, environment info, repo search, and other methods.
Therefore, many users find that something they told AI yesterday is forgotten today. That's because it's essentially an empty black box that needs to be refilled with information every time it's used.
Second, AI still hallucinates.
Human memory is short. After being brainwashed by self-media, many people have long forgotten the experience from three years ago when AI tricked them out of their pants.
The essence of large language models is a black-box probability prediction system. Each generation is based on relevance, predicting information closer to the correct answer. Its specialty is "speaking nonsense with a straight face," but because technology has iterated to the point where it's increasingly good at approximating correct answers, people mistakenly believe everything it generates is factual.
In reality, AI itself doesn't know what facts are, so how can it generate facts?
"If the egg tastes good, don't worry about which chicken laid it." When using AI, we mainly consider practicality. As long as the results are useful, we generally overlook the mechanism behind them. But that doesn't mean we can trust it completely and accept all its outputs.
Third, attention drift caused by overly long context.
This is a phenomenon where AI forgets earlier information when the context becomes too long. Although various companies have been competing on context length in recent years, context length and attention quality are two different things. AI being able to read more content doesn't mean it can consistently focus on important information.
Many people have likely been burned by this. The first few rounds of conversation with AI go well, but as it goes on, it starts making things up. Even if you've laid out high-level principles, commands, and instructions earlier, it will gradually forget more and more requirements. If the task is complex with many changes, issues like goal drift, misplaced focus, and information confusion can arise. This is why many Agents become increasingly unstable as projects progress—longer context doesn't mean more focused attention.
After all that unpleasant talk, let's discuss general abstract methods for using AI well.
In summary, it boils down to three points: clarify the problem, define constraints, and design acceptance criteria. The problem determines the direction, constraints define the boundaries, and acceptance criteria determine the outcome.
Clarifying the problem means you need to ask a specific question.
For example, if you're thirsty and want an old friend to bring you a glass of water, you might say, "I'm thirsty." For an old friend, that's a specific problem because you've had countless similar conversations before. They know that means to bring you water, and they might even know your preferences—adding ice cubes and a slice of lemon.
But for AI, "I'm thirsty" isn't a problem; it's your state. The information it gets from that sentence is that you're thirsty, and then nothing else.
So you can't talk to AI the way you talk to a human. You need to clearly state your needs and turn your problem into a specific request. So you should say, "I need you to bring me a glass of water now, with three ice cubes and a 2mm thick lemon slice on the rim."
Similarly, you can't tell AI, "Fix this bug." You need to specify which page or service, and what error message appears during runtime.
Defining constraints means telling AI what tools you or it have to solve the problem.
Going back to the thirst problem, before AI brings you water, it doesn't know where your kettle is, where the ice is, or where the 2mm lemon slice is. So you also need to tell it: the kettle is in the kitchen, which is the third room on the left after leaving; the ice is in the fridge, which is in the kitchen; the lemon slice is in the pantry, which is in the living room, which is the first room on the right after leaving.
In some Agents, these constraints are terminal information, code dependencies, worktrees, etc. But if you're using a Chatbot instead of an Agent, it's best to provide this information along with your problem.
Designing acceptance criteria means clearly defining what result you expect.
This was already mentioned in the thirst problem: ice water and lemon slices are your acceptance criteria. Similarly, the acceptance criteria for "fix this bug" is "no more error messages during runtime."
If you ask AI to write a marketing plan—a relatively complex task without computer environment constraints—you need to clearly define the specific acceptance criteria for that plan. What length should it be? What modules should it cover? Does it need to include budgets for personnel, materials, and finances? What essential elements must be included? Should success cases be inserted?
The clearer the acceptance criteria, the easier it is to judge and correct AI's output. Otherwise, you'll end up with a pile of garbage information. Missing the point is the least of your problems; using a rocket engine to pull a horse-drawn cart isn't out of the question.
As long as you handle these three basic things, even without complex prompt techniques, AI's output will generally be decent.
Three years into AI, models are getting stronger, contexts are getting longer, and Agents are getting more complex, but many people are still facing the same problems as three years ago. Many people don't lack clever tricks for using AI; they just haven't shifted their mindset, polluted by the information environment of various silicon-based cult self-media, believing AI is some all-powerful technology that must answer every call.
In reality, it's just a better tool. A thug uses a wrench to collect debts, while a mechanical engineer uses a wrench to tighten screws. The same tool has different uses in different people's hands, but the key is still how you use it. The thug needs to know how to swing the wrench, and the engineer needs to know how to tighten the screw.
No matter what problem you're solving with AI, understanding the tool's characteristics is always the most important first step.