Feed several code anchors to the encoding model

Sun, 05 Jul 2026 23:04:15 +0800

When writing requirements for coding models, I increasingly tend to include a few names that can be searched in the repository: function names, component names, CSS class names, or interface paths. Without these terms, the model may still be able to complete the task, but it often has to spend an extra round guessing “which piece of code does this sentence correspond to.”

For example, just write:

Adjust the disabled state of the login button, prevent repeated clicks while submitting, and also gray out the style.

A human can identify where the “login button” is based on the visual impression of a page, but a coding model may be confronted with dozens of buttons, multiple login entry points, and implementations scattered across components, state management, and style files. It must first map the phrase “login button” from natural language to the specific symbols in the repository, and only then can it determine whether to modify the event handler, state variables, or CSS.

If the requirements are modified as follows, the search space will be much smaller:

Adjust the submission state of handleSubmit in LoginForm. Disable .login-submit during submission to prevent duplicate requests; the existing error notification behavior remains unchanged. Acceptance: clicking again before the request completes will not send a second request, the button appears in a disabled style, and it is restored after the request finishes.

What’s truly useful here is not that the prompts become longer, but that there are a few more anchors that can be landed on in code.

The Model Is Making Predictions, But the Agent Still Needs to Find the Code First

Current mainstream large language models typically split input into tokens and progressively predict subsequent tokens based on existing context. Transformer’s self-attention mechanism allows tokens in a sequence to establish connections with each other; after large-scale pre-training and subsequent alignment, the model can follow instructions, explain code, and generate modification plans. However, “being able to generate based on context” is not the same as “naturally knowing where the login button is placed in your current repository.”

The coding agent has an additional layer of work: it invokes file search, text retrieval, read, and test tools to bring the relevant code from the repository into the model’s context. At this stage, the function name handleSubmit and the class name .login-submit serve a dual purpose.

The first layer is retrieval anchors. A phrase like “login button” in natural language can match copy, comments, tests, and multiple components; precise symbols can be handed directly to text-search tools to quickly locate definitions, references, and adjacent tests. Reading fewer irrelevant files not only saves time and tokens, but also reduces the chance of unrelated code cluttering your judgment.

The second layer is semantic constraints. handleSubmit suggests that the change is related to the submission flow, .login-submit narrows the visual state to a specific selector, and LoginForm further provides the component boundary. Together, they reduce the ambiguity around “which button exactly, and which layer should hold the state.” The model is still doing probabilistic generation, but there are fewer plausible interpretations, making it easier for the next step to unfold along the correct code path.

That’s also why I’d rather call this approach “providing coordinates” than a “prompting trick.” It helps both the model and the toolchain around the model. Even if you switch to a different coding model, as long as it also needs to search the repository, these coordinates remain valuable.

A Good Requirement Is More Than Just a String of Keywords

Having only the symbol name is not enough. Although the following writing style is easy to search for, it still doesn’t tell you what to change it to:

LoginForm, handleSubmit, .login-submit, optimize it.

The format I use more often now includes four categories of information:

Information	Purpose	Example
Code Anchors	Narrow down the search scope	`LoginForm`, `handleSubmit`, `.login-submit`
Target Behavior	Explain what happens after the change	Prevent duplicate requests during submission
Preservation Items	Prevent accidental changes to adjacent behaviors	Existing error messages remain unchanged
Acceptance Criteria	Provide an endpoint for implementation and testing	The second click does not send a request, and the request state is restored after it ends

File paths, test names, interface names, and error message text can also serve as anchors. Prioritize names you have personally verified and that are highly recognizable; you don’t need to pile in every related symbol just to appear specific. Usually one or two entry functions, a component, or a style name is already enough to let the agent start searching; the remaining call relationships should be verified by it from the code, rather than being filled in from memory by the requirement writer.

Also be wary of incorrect coordinates. When functions have been renamed, class names are reused in multiple places, or the requirement actually points to a different page, precise yet wrong keywords will lead the model astray faster. A safer approach is to add a sentence like “the name may have changed, please search to confirm first,” or provide both the page behavior and visible text so the agent can cross-verify.

So the more practical conclusion is not “stuff more keywords into the requirements,” but rather: translate the human’s impression of the page into coordinates that the repository can search, then constrain modification outcomes with behavior and acceptance criteria. The former reduces the cost of finding code; the latter reduces the room for writing incorrect code. When both parts are present simultaneously, the efficiency gains of coding models become more stable.

References

写作附记

Original Prompt

When writing requirements with large models, if you can include some keywords, such as: associated function names, associated frontend style names, it can make the model more efficient. Briefly explain the principles of LLM, explain the principles of current large models, and explain why what I do is better.

This piece preserves the on-site judgment that “function names and style names can boost coding efficiency,” and adds the distinction between language model generation and coding agent retrieval. It trims out full Transformer tutorials, model generation comparisons, and generalization prompt checklists, preventing mechanism introductions from overshadowing the main thread of engineering questions.

LLM on Uncle Xiang's Notebook

Feed several code anchors to the encoding model

The Model Is Making Predictions, But the Agent Still Needs to Find the Code First

A Good Requirement Is More Than Just a String of Keywords

References

Original Prompt