不要再把 LLM 當成搜尋引擎使用

Most devs use modern language models wrong. They open a chat window, paste an error stack trace, and wait for a magic snippet. When it works, they celebrate. When the model hallucinates a nonexistent method on a standard library class, they complain that AI is overhyped.

The core mistake is treating an LLM like a deterministic search engine or a junior dev who actually knows your codebase. It is neither. It's a spatial compressor of human text, mapping tokens across multi-dimensional vector spaces. Feed it vague prompts and you get average code. Want production-grade output? Treat the interaction like an API design problem.

Look at how this plays out in practice. Ask an LLM to write a complex database migration or an asynchronous worker loop from scratch and you invite disaster. The model samples from the most common patterns on the public internet, which usually means deprecated libraries, unhandled race conditions, and zero error boundaries.

Flip the workflow. Use the model as a strict transformation engine. Feed it your exact architectural constraints, your types, and your failure modes as explicit parameters.

Picture needing a robust parser. Instead of asking for a parser, provide the grammar rules and the exact failure states you expect. The mental shift is simple. You aren't asking the model to think. You are asking it to interpolate between boundaries you defined.

# Bad prompt approach:
# "Write me a Python function that parses incoming webhook payloads safely."

# Structural engineering approach:
# Define the strict input schema and error boundaries first.
from pydantic import BaseModel, ValidationError

class WebhookPayload(BaseModel):
 event_id: str
 timestamp: int
 data: dict

def parse_webhook(raw_bytes: bytes) -> WebhookPayload:
 # Force the LLM to work within explicit parsing boundaries
 # rather than inventing arbitrary validation logic.
 pass

Constrain the output space and the hallucination rate drops fast. The model stops guessing your validation preferences because you handed it Pydantic and said, fill in the transformation logic between these exact types.

This points to how engineering teams will structure developer tools next. We are moving past general-purpose chat interfaces. The real speed comes from building domain-specific wrappers that inject your team's internal documentation, SDK versions, and linting rules directly into the context window before the model ever sees the prompt.

If your devs still copy-paste code snippets from a browser-based chat window, you are losing velocity. Treat prompt engineering like systems programming. Build the harness, define the types, and let the inference engine do the heavy lifting only inside safe, walled gardens.