AI AI 工具指南
常见问题解决库

Prompt 里写着过时的年份，把模型锚在错的 context

2026 年了 prompt 还写着 2023，模型于是推荐 GPT-4、引用旧定价、提过时框架。最快修复：在运行时动态注入当前日期。附诊断表和怎么确认修好了。

发布于: 更新于: 作者: AI Productivity Guide Team 🌐 查看英文版本

最快修复： 打开你的 system prompt，删掉每一处硬编码年份和 “as of 2023” 那类句子，改成在运行时注入真实日期（Python 里就是 Today's date is {datetime.now().strftime('%B %d, %Y')}，其他技术栈用等价写法）。然后把同一个请求重跑一遍，确认模型不再引用旧版本。下面的内容是帮你找出剩下的过时锚点、并防止它们再回来。

你的 prompt 模板是 2023 年写的，至今还带着一句 “Consider the current state of AI in 2023 when answering.”。现在是 2026 年 6 月。模型老老实实把答案锚到 2023：推荐 GPT-4（早被 GPT-5.5 和 Gemini 3.1 Pro 取代）、引用 2023 定价、提到现在已经停更的框架。模型的事实没旧，是你告诉它一个错的年份。过时年份字符串、硬编码日期、“as of X” 锚点，是长生命周期 prompt 里的静默毒药。

这种 bug 几乎过不了 QA——回复读起来仍然流畅权威。它在用户发现”等等，这个推荐是几年前的”那一刻爆掉，信任清零。

你属于哪一类？

你看到的症状最可能的原因跳到
模型推荐 GPT-4、报 2023 价格、提已死掉的工具system prompt 里硬编码年份或 “as of 2023”原因 1、7 -> 第 1 步
回复里出现字面 {{current_year}} 或 {{date}}插值从没接上原因 2 -> 第 1 步
输出模仿带日期的 few-shot 例子（“In 2023…“）few-shot 例子里写死了年份原因 3 -> 第 3 步
明明给了 context，模型还用 “as of my knowledge cutoff” 拒答cutoff 免责声明在跟你的 RAG 打架原因 5 -> 第 2 步
答案引用了一篇真实但 2 年前的检索文档过时的 RAG chunk 锚住了模型原因 4 -> 第 6 步
模型坚称”今天是 2024 年 3 月”硬编码的”今日日期”字符串原因 6 -> 第 1 步

常见原因

1. instruction 里硬写年份

"You are a helpful AI assistant trained on data up to 2023."三年前写的，从没更新。模型现在表现得像还在 2023，对更近期的东西都躲着不说。注意到 2026 年 6 月这是双重错误：旗舰模型（GPT-5.5、Claude Opus 4.7、Gemini 3.1 Pro）实际带着 2025 年的训练数据，一句 “2023” 等于白白丢掉模型本来就有的知识。

怎么判断：grep prompt 里的 20\d\d。每个年份串都是 staleness 候选。

2. “current year” 没插值进去

模板写 "As of {{current_year}}"，但插值引擎没接上，字面 {{current_year}} 字符串直接到模型。模型可能解读成”没指定年份”，更糟时当成 placeholder 自己去填。

怎么判断：发请求看模型真正收到了什么。渲染后的 prompt 里看到字面 {{...}} 就是插值断了。

3. few-shot 里带日期

few-shot 例子写 “In 2023, the iPhone 15 released…”。现在 2026 跑现代 query，模型按 2023 的引用模式输出。

怎么判断：审 few-shot 例子里的日期引用。任何具体年份都会锁住时间帧。

4. RAG 语料是旧文档

retrieval 系统取出 2023 年写的文档。即使 system prompt 是 2026 的，retrieved content 也会把模型锚到 2023 的事实。

怎么判断：看 top retrieved chunks 的发布日期。超过 2 年 + 用户问的是当下事——RAG 在喂旧 context。

5. “knowledge cutoff” 行跟任务冲突

system prompt 写 “Your knowledge ends at October 2023”，但用户问的更近期的事其实就在你提供的 context 里。模型拒答或编造，而不是用那段 context。这里有两个坑同时咬人：免责声明本身就过时了（当前旗舰训练到 2025 年、不是 2023），而且它主动压住了你刚递给模型的信息。

怎么判断：response 出现 “as of my knowledge cutoff” 或 “I don’t have information about”——但这些事实其实在你提供的 context 里。注意 Anthropic 把 reliable knowledge cutoff（知识最完整的日期）和 training data cutoff（更宽的数据范围）分开列，所以把单一 cutoff 日期抄进 prompt，即便它是最近的，也很脆。

6. system prompt 里硬写今日日期

写 “Today is March 15, 2024.”从没更新。几个月后模型仍以为今天是 2024 年 3 月 15 日。

怎么判断：搜字面日期串。system prompt 里任何过去的日期都是嫌疑。

7. prompt 里写死定价或版本号

“Our service costs $20/month and runs on GPT-4.”半年后你涨到 $30、切到 GPT-5.5。prompt 里还是旧数字，面向用户的 assistant 还在报 $20。

怎么判断：prompt 里任何具体数字（价格、版本号、模型名）都是 staleness 候选。

最短修复路径

第 1 步：动态注入当前日期

from datetime import datetime, timezone
now = datetime.now(timezone.utc)
system_prompt = f"""
You are a helpful assistant.
Today's date is {now.strftime('%A, %B %d, %Y')} (ISO: {now.date().isoformat()}).
Treat any context provided below as current information.
"""

永远不硬写年份——从 runtime 注入。消费级应用其实就是这么做的：claude.ai、ChatGPT、Gemini app 都在每次对话开头把当前日期拼进它们隐藏的 system prompt，这正是它们能锚在正确时间的原因。你是在为自己的应用复刻这个做法。

当日期边界是任务的一部分时（报表、“本周到期”、排期），还有两个细节很关键：

  • 带上星期几和 ISO 8601 日期（如上）——Monday, June 22, 2026 (ISO: 2026-06-22) 比 06/22/26 更难被误读，后者模型可能按别的地区格式去解析。
  • 当顺序或”最近”重要时，再传用户时区和请求时间戳，并明确定义模糊词：User timezone: America/New_York. Request timestamp: 2026-06-22T09:00:00-04:00. Treat "recent" as the last 30 days.别让模型自己猜 “recent” 是什么意思。

第 2 步：有 RAG 时移除 “knowledge cutoff” 免责

通过 RAG 提供 context 时，模型不应该退回到 “I don’t know recent events”：

You have access to retrieved documents below. Treat them as your
source of truth, even if more recent than your training cutoff.
Do NOT add disclaimers about your knowledge cutoff.

到 2026 年 6 月，当前旗舰（GPT-5.5、Claude Opus 4.7/Sonnet 4.6、Gemini 3.1 Pro）在给了 web-search 或 retrieval 工具时，已经很少以 cutoff 为由拒答——它们会去搜、然后回答。如果模型死活回 “I can’t access information after my cutoff”，几乎一定是你 prompt 里的过时免责声明压过了这个行为。直接删掉免责声明，别跟模型掰扯。

第 3 步：审 few-shot 例子的日期

每个 few-shot 例子里，把具体年份替换成 [YEAR] 或删掉日期：

BEFORE: "In 2023, Apple released the iPhone 15..."
AFTER:  "Apple released the iPhone 15 in [YEAR]..." (或者直接删日期)

日期重要的话，用相对时间或注入当前日期。

第 4 步：季度审 prompt 模板

# prompts/customer-support.yaml
last_reviewed: 2026-05-01
next_review: 2026-08-01
content: |
  ...

CI 在 next_review < today 时挂掉，强制 refresh。

第 5 步：版本控制 + diff prompt 改动

把 prompt 当代码。改 prompt 的 PR 必须高亮变更，reviewer 抓出过时的日期 / 版本引用。

第 6 步：RAG 在时间敏感话题上按新鲜度过滤

if is_time_sensitive(query):
    chunks = retrieve(query, filter={"publish_date": {"gte": "2025-01-01"}})
else:
    chunks = retrieve(query)

时事 query 别让 2 年前的文档锚住模型。

第 7 步：用 date-shifted 输入测试

测 prompt 时问不同年份的事件。如果模型死活不能承认某个固定 cutoff 之后的事，说明 prompt 里藏了 cutoff。

怎么确认修好了

三个快速检查，按顺序来：

  1. **看渲染后的 prompt，不是模板。**把真正发给 API 的字符串打日志读一遍。里面不能有你没打算保留的 20\d\d 字面年份、不能有 {{...}} placeholder，且要有一个真实的当前日期。绝大多数”我修好了”的翻车，都是模板看着对、渲染出来错。
  2. **问模型它以为今天几号。**发一句 “What is today’s date, and what is the most recent model or pricing you can recommend?”。回复应该回显你注入的日期、并给出当前选项（比如 GPT-5.5 或 Gemini 3.1 Pro），而不是 GPT-4 或 2023 定价。
  3. **把当初出问题的请求重跑一遍。**那个过时好几年的推荐现在应该是最新的了。把这条请求原封不动留作回归测试，下次改 prompt 后这个 bug 才不会悄悄回来。

哪些情况可能不是你操作错了

有些模型权重里硬写了 knowledge cutoff——它真的不知道某日期之后的事，新 system prompt 也救不了。那种情况的修复是 RAG 或 web 工具、不是改 prompt。Anthropic 在它的模型文档里逐个模型公布了确切 cutoff 日期，并且如上所述区分了 “reliable” 和 “training data” 两种 cutoff；在断定某模型不可能知道某件事之前，先查一下你所用服务商的对应页面。

容易误判的情况

“模型旧了”——然后直接去升级模型。有时模型是最新的、瓶颈在 prompt。升级前永远先看一眼渲染后的 prompt。

预防建议

  • system prompt 里 current_date 永远动态注入、不硬写。
  • 季度（至少）审 prompt 里的日期、版本、价格。
  • prompt 模板当 versioned code 看，PR 必须 diff-aware。
  • RAG 在时间敏感话题上按新鲜度过滤检索。
  • 有 retrieval 层时移除 “knowledge cutoff” 免责声明。
  • 例子里用 [YEAR] 或相对时间（“last year”）代替硬日期。

FAQ

  • 直接告诉模型 “you’re current as of today” 行吗？ 有用，但前提是 prompt 其他地方不能有旧引用跟它打架。一句 “today is X” 压不住下面五句 “as of 2023”。冲突也要一起修掉。
  • 接了 RAG 之后模型训练 cutoff 还重要吗？ 弱化了，但检索拿不到内容时仍影响一般推理。带 retrieval 或 web 工具的现代旗舰不该以 knowledge-cutoff 为由拒答——如果你的会，先怀疑 prompt 里的过时免责声明，再去怪模型。
  • “reliable knowledge cutoff” 和 “training data cutoff” 有什么区别？ reliable cutoff 是模型知识最完整、最可靠的截止日期；training data cutoff 是数据范围更宽的那一端，通常晚几个月。这就是为什么把单个 cutoff 日期写进 prompt 很脆。最好根本别在 prompt 里复述 cutoff——给当前 context，让模型去用。
  • 我”修好”模板后模型怎么还说 2023？ 几乎可以肯定你改了模板、但发出去的是缓存的或另一份渲染出来的字符串。把真正的 API 请求打日志读一遍——字面年份或断掉的 {{placeholder}} 一般还在里面。
  • 我的用户分布在不同时区，该注入哪个日期？ 注入 UTC，再加上用户的 IANA 时区（比如 America/New_York），当日期边界重要时再加一个请求时间戳，这样模型才能正确解析 “today” 和 “this week”，而不是瞎猜。

相关阅读

标签: #Prompt 工程 #排查 #llm-output #stale-context #prompt-maintenance #evergreen

相关文章