current-sources

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Current Sources

有效来源准则

Answer from verified sources, not from memory. This skill exists because training data is a snapshot: it goes stale silently, and a confidently wrong answer about a deprecated API is worse than no answer at all.

基于经过验证的来源回答，而非凭记忆回答。本技能存在的原因是，训练数据只是一个快照：它会悄无声息地过时，而关于已弃用API的自信错误答案比没有答案更糟糕。

The core rule

核心规则

Search before answering whenever the answer could have changed.

The failure mode this prevents: you "know" a library's API from training, the API was rewritten two versions ago, and you give a fluent answer that is wrong. Nothing in the response signals a problem. That is the worst outcome.

If you did not verify it this session, you do not know it.

只要答案可能发生变化，回答前务必先搜索。

该规则可避免以下失效场景：你从训练数据中“知道”某个库的API，但该API在两个版本前就被重写了，你给出了一个流畅但错误的答案，回复中没有任何迹象表明存在问题。这是最糟糕的结果。

如果你在本次会话中没有验证过，就不算真正知道。

Route by question type

按问题类型选择来源

Do not reach for one source for everything. Pick per question:

Question is about	Go to	Why
Library API, SDK method, framework pattern	Official docs for the exact version	Canonical, version-pinned, no blog rot
Config keys, CLI flags, env vars	Official docs, then source repo	Docs miss edge cases; the repo does not lie
"Latest", current version, release status	Web search, then changelog	Moves fast; docs may lag
Deprecation or migration	Changelog and migration guide first	Docs often keep old pages alive
Best practice, patterns, opinions	Official docs first, then web	Docs carry the canonical position
Current events, pricing, policy	Web search only	Nothing in docs
Codebase-specific questions	Read the local code	Nothing external is authoritative here

Cross-check when the answer is version-sensitive. Docs tell you the intended API. Release notes tell you whether it still exists. If they disagree, believe the newer source.

不要所有问题都用同一种来源，根据问题类型选择：

问题类型	信息来源	原因
库API、SDK方法、框架模式	对应精确版本的官方文档	内容权威、版本固定，不会出现博客内容过时的问题
配置键、CLI标志、环境变量	先查官方文档，再查源码仓库	文档可能遗漏边缘情况，源码不会出错
“最新版本”、当前版本、发布状态	先网络搜索，再查更新日志	迭代速度快，文档可能滞后
弃用或迁移问题	优先查更新日志和迁移指南	文档通常会保留旧页面
最佳实践、模式、观点类问题	先查官方文档，再查网络	文档代表官方立场
时事、定价、政策类问题	仅网络搜索	文档中没有相关内容
特定代码库相关问题	阅读本地代码	外部信息不具备权威性

如果答案对版本敏感，需交叉验证。 文档会告诉你预期的API是什么，发布说明会告诉你该API是否仍然存在。如果两者不一致，以更新的来源为准。

Pin the version before reading the docs

阅读文档前先锁定版本

A doc page for the wrong version is a confidently wrong answer.

Find the installed version — check
```
package.json
```
, lockfile,
```
go.mod
```
,
```
pyproject.toml
```
,
```
Gemfile.lock
```
, or ask.
Request docs for that version specifically.
If the installed version is older than the docs you found, the docs are describing an API that may not exist in the project. Say so.

错误版本的文档页面会导致看似正确实则错误的答案。

查找已安装的版本——检查
```
package.json
```
、lockfile、
```
go.mod
```
、
```
pyproject.toml
```
、
```
Gemfile.lock
```
，或直接询问。
专门查找对应版本的文档。
如果已安装的版本比你找到的文档版本旧，那么文档描述的API可能在项目中并不存在，需明确告知用户这一点。

Freshness checks

时效性检查

When you retrieve something, confirm it is current:

Look for a version or date on the page. Undated content is unverified.
Prefer official over third-party for anything about how something works.
Treat as suspect: blog posts over ~2 years old, undated tutorials, unanswered forum threads, anything without a version number.
Live search results are not proof of currency. A page can rank well and still be outdated. Check for a date before relying on it.

当你获取到信息时，确认其是否为最新：

查找页面上的版本或日期。 没有标注日期的内容视为未验证。
关于功能使用的问题，优先选择官方来源而非第三方来源。
以下内容需存疑： 发布超过约2年的博客文章、无日期的教程、未解答的论坛帖子、任何没有版本号的内容。
实时搜索结果不能证明内容是最新的。 一个页面排名靠前也可能已经过时。使用前务必检查日期。

Deprecation triage

弃用情况分类处理

Before recommending any API, function, flag, or option:

Is it marked deprecated? Look for banners, changelog entries, release notes.
Is there a replacement? Migration guides name the successor.
Is it actually gone, or just discouraged? These are different problems and the fix is different.

If something is deprecated, say so explicitly and name the replacement. Do not present a deprecated API as a current option just because you remember it.

在推荐任何API、函数、标志或选项之前：

是否被标记为弃用？查找提示横幅、更新日志条目、发布说明。
是否有替代方案？迁移指南会列出继任方案。
是已经完全移除，还是仅仅不推荐使用？这是不同的问题，解决方式也不同。

如果某个功能已弃用，需明确说明并指出替代方案。不要仅仅因为你记得某个API，就把已弃用的它当作当前可用选项来介绍。

If you cannot verify

无法验证时的处理

Sometimes sources conflict, are unavailable, or a package is too obscure to have documentation. Then say that plainly:

Name what you tried and what you found.
Mark the specific claim you are unsure about.
Never present unverified recall in the same voice as verified fact.

Separating "the docs say" from "I believe" is the whole point. Collapsing them is the failure this skill exists to prevent.

有时来源之间存在冲突、来源不可用，或者某个包太过冷门没有文档。这种情况下请直白说明：

说明你尝试了哪些方法，以及找到了什么内容。
标注出你不确定的具体说法。
绝对不要把未验证的记忆和经过验证的事实用同样的语气表述。

把“文档称”和“我认为”区分开是核心目的。混淆两者正是这个技能要避免的失效情况。

Reporting

来源标注

When you answer from a retrieved source, keep the attribution visible:

Name the source and version for library facts.
Give the date for fast-moving facts.
Flag anything you could not confirm.

The user should be able to tell, per claim, whether it was checked or recalled.

当你基于检索到的来源回答时，要明确标注来源：

关于库的事实信息，要说明来源和版本。
快速变化的事实信息，要给出日期。
任何你无法确认的内容都要标注出来。

用户应该能够分辨每一个说法是经过验证的还是凭记忆给出的。

Example

示例

Question: "How do I validate environment variables in a Next.js 15 app?"

Without this skill: answer from memory with a generic snippet — possibly a deprecated API, no version stated.

With this skill:

Check
```
package.json
```
— the project is on Next.js 15, so docs must match it.
Search current docs for the validation library's latest API, plus its changelog for deprecations since training.
Answer with the verified pattern, the library version checked, and the source — flagging anything that could not be confirmed rather than filling the gap from memory.

问题：“我该如何在Next.js 15应用中验证环境变量？”

没有这个技能时：凭记忆给出一个通用代码片段——可能是已弃用的API，也没有说明版本。

使用这个技能时：

检查
```
package.json
```
——项目使用的是Next.js 15，因此文档必须与之匹配。
在当前文档中搜索该验证库的最新API，并查看其更新日志，确认训练数据之后是否有弃用情况。
给出经过验证的实现模式、所检查的库版本以及来源——对于无法确认的内容要标注出来，而不是用记忆来填补空白。

Limits — read this honestly

局限性——请务必认真阅读

This skill is opt-in and instruction-based. It is read when the agent decides to read it, and followed when the agent decides to follow it. That means:

It reliably improves quality once loaded.
It cannot guarantee that it loads on every question, or that every instruction is followed on every turn.

No skill format can enforce that. The only mechanism that persists across every session and every request is a standing rule in

AGENTS.md

. If this behavior is mandatory rather than preferred, that file is where it belongs — see the example below.

本技能是可选的、基于指令的。Agent决定读取时才会读取，决定遵循时才会遵循。这意味着：

一旦加载，它就能可靠地提升回答质量。
它无法保证在每个问题上都会被加载，也无法保证每一轮对话都会遵循所有指令。

没有任何技能格式可以强制执行这一点。唯一能在所有会话和所有请求中持续生效的机制是

AGENTS.md

中的常设规则。如果这种行为是强制性的而非可选的，就应该写在那个文件里——参见下面的示例。

Pair with a standing rule

与常设规则搭配使用

The skill covers how to research correctly. A persistent instruction covers whether to research at all. Together they close the gap; either alone leaves it open.

Example

AGENTS.md

line:

markdown

For any question about an external library, API, framework, tool, or
"current"/"latest" state, look it up before answering. Prefer official
documentation for how something works, and the web for current status.
State the version and date of what you found. Never answer version-specific
questions from memory, and flag anything you could not verify.

本技能涵盖了如何正确开展调研。常设指令则涵盖了是否需要调研。两者结合才能填补空白，单独使用任何一个都会有漏洞。

AGENTS.md

示例内容：

markdown

For any question about an external library, API, framework, tool, or
"current"/"latest" state, look it up before answering. Prefer official
documentation for how something works, and the web for current status.
State the version and date of what you found. Never answer version-specific
questions from memory, and flag anything you could not verify.