AI 輔助開發中，傾倒整個程式碼庫並非上下文工程

There is a moment in every AI-assisted project where the repo gets too big to paste. Most people solve it by pasting more. The context window is huge now, they reason, so I'll drop in the README, the router, the migrations, and the two most recent PRs.

Then the assistant confidently writes code that contradicts the architecture you already settled, reintroduces an endpoint you removed last sprint, and names a field that exists in no migration anywhere. Bigger context didn't help. It just gave the model more room to pick the wrong reference.

The model doesn't know what to ignore

A large context window is not a harness. It is a search problem the model loses, because it has to weight thirty documents at once and your README is three years out of date. If the real contract lives in a generated OpenAPI file but the README describes the v1 hand-rolled JSON shape, the model will sometimes read the README.

Dumping everything is the lazy version of context engineering. It offloads your job onto the token budget.

The three slices that actually decide the answer

After enough sessions, the set of documents that changes the outcome is small:

1. The thing you were just doing. The open files, the last failing test, the error trace. The model has no memory between sessions, and this is the slice people leave out. Without it, the assistant re-summarizes the repo and quietly reverts a decision you made an hour ago.

2. The hard constraint, in machine-readable form. The thing the assistant keeps getting wrong is usually a rule that exists nowhere as text. Field names, required-vs-optional, status codes, rate limits — these live in a contract, not a prose description. Pointing the assistant at that contract beats any paragraph you write about it. We eventually kept a local OpenAPI file that was last re-run against the live endpoint, and the rate at which the assistant invented endpoints dropped sharply; a human paragraph would never have carried that weight.

3. The boundary it must not cross. One sentence that says which file not to touch, which service is shared, which migration is already applied. Vague prose like "be careful" does nothing. A concrete prohibition names the thing.

Everything else is noise

The README, the architecture doc, the list of design decisions — these are for humans. They are also exactly the artifacts that rot. When the model has to choose between a stale markdown file and a live machine-readable artifact, the live one wins if you actually put it in front of it.

Context engineering, in practice, is the opposite of completeness. It is choosing the handful of references that survive contact with reality, and deliberately leaving the rest out. A 200k token window full of stale summaries is a worse assistant than a 20k window built from the files the session actually depends on.

What three things do you always paste in, that the model never seems to notice? That gap is probably where the invented endpoints come from.