别再死磕怎么写提示词了，给模型喂对上下文才真正决定成败

很多人把精力花在研究怎么写出所谓的“完美 Prompt”上，试图通过微调几个形容词或者增加几句指令来让 LLM 表现更好。但我实操了这么多项目后发现，比起琢磨提示词怎么写，怎么构建“上下文（Context）”其实要关键得多。

简单来说，提示词是告诉 AI “要做什么”，而上下文是给它 “做这件事所需的所有信息”。

举个例子，如果你让 AI 写个 FastAPI 的 CRUD 接口，你加再多要求（比如指定 Python 3.12、要求带 JWT 认证），这依然是在做 Prompt Engineering。但如果你在请求之前，自动把项目的 API 文档、现有的代码规范、甚至之前讨论过的架构决定全部塞给它，这时候 AI 输出的质量会有质的飞跃。这时候起作用的不是你指令写得好，而是它掌握的信息全。

现在的 AI 应用逻辑早就变了，一个高质量的回复通常是这样组合出来的：

• 检索到的文档片段
• 向量数据库里的知识
• 实时 API 的调用结果
• 用户的历史偏好和系统预设规则

这种把碎片化信息精准地组装起来喂给模型的过程，就是 Context Engineering。

我之前尝试过一个对比实验，同样的任务，一个是用极其精细的提示词引导，另一个是给它提供了完整的相关代码上下文。结果发现，后者生成的代码几乎不需要修改就能直接运行，而前者虽然格式正确，但逻辑上和我的现有项目完全脱节。

如果你在做开发，建议把 AI 系统当成软件工程来设计。不要试图写一个巨大的、包罗万象的 Prompt，而应该设计一套自动化机制，在用户提问的一瞬间，精准地把最相关的上下文抓取过来。

比如现在很火的 Model Context Protocol (MCP)，本质上就是把上下文的来源从简单的文档扩展到了 GitHub 仓库、本地文件系统和数据库。当模型能直接感知到你的整个开发环境时，你根本不需要写什么复杂的提示词，直接说“帮我改这个 Bug”，它就知道该看哪个文件。

一个实操的小建议：不要把 AI 对话框当成知识库，那些好用的例子和决策应该结构化地存储在外部，在需要时作为上下文注入，而不是指望通过长对话让模型记住。