Back to Details

research

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

High-Signal Research

高信噪比研究

The failure mode this kills: one search, then everything else confabulated from training data, padded with SEO articles written to rank for agents rather than to be correct. That produces confident, outdated, wrong answers. Research means reading current primary sources, not pattern-matching memory.
该方法解决的失效模式：仅进行一次搜索，其余内容全部由训练数据虚构而成，再用为吸引AI Agent排名而非追求准确性的SEO文章填充。这种方式会产生看似自信、实则过时且错误的答案。研究的本质是阅读当前的一手来源，而非匹配记忆中的模式。

Two hard rules

两条严格规则

  1. No coasting. One search is never the research. Run several varied queries, open multiple sources, and read them. Any claim about current or version-specific behaviour must trace to a source you actually opened this session — not to training data. If you're stating something from memory, say so, then go verify it.
  2. Source quality is gated. Prefer primary, high-signal sources. Actively distrust and avoid agent-bait. A wrong source is worse than no source.
  1. 不可敷衍了事。仅一次搜索绝非真正的研究。要执行多个不同的查询，打开多个来源并阅读。任何关于当前特性或特定版本行为的说法，都必须追溯到你在本次会话中实际打开的来源——而非训练数据。如果你是凭记忆陈述内容，请明确说明，然后去验证它。
  2. 来源质量需严格把控。优先选择一手、高信噪比的来源。主动质疑并避开“Agent诱饵”内容。错误的来源比没有来源更糟糕。

Source tiers

来源层级

Tier A — primary, trust first:
  • Official docs, specs, standards, RFCs for the actual thing.
  • The source code itself and its issue tracker / PRs / discussions on GitHub/GitLab — what the code does, and what the maintainers say.
  • Release notes / changelogs / migration guides (for "what changed" and "current version").
Tier B — secondary, good when corroborated:
  • Stack Overflow answers that are accepted or high-voted (check the date and the version they assume).
  • Reputable maintainer / practitioner engineering blogs (a named author with a track record, dated, with real detail).
  • Conference talks, well-regarded books.
Tier C — distrust / avoid:
  • SEO content-farms, listicles ("Top 10 …"), and "answer" sites that exist to capture search/agent traffic.
  • Undated, unattributed tutorials; content that just restates the docs with worse wording.
  • AI-generated filler. Anything where you can't tell who wrote it or when.
A级——一手来源，优先信任：
  • 对应技术的官方文档、规范、标准、RFC文档。
  • GitHub/GitLab上的源代码本身及其问题追踪器/PR/讨论区——代码实际的行为，以及维护者的表述。
  • 发布说明/变更日志/迁移指南（用于了解“变更内容”和“当前版本”）。
B级——二手来源，需交叉验证：
  • Stack Overflow上已被采纳或高票的回答（注意查看日期和其适用的版本）。
  • 知名维护者/从业者的技术博客（有明确署名作者、发布日期且内容详实）。
  • 会议演讲、口碑良好的书籍。
C级——质疑/避开：
  • SEO内容农场、列表文（如“Top 10……”），以及专为捕获搜索/Agent流量而存在的“问答”网站。
  • 无日期、无署名的教程；仅用更差的措辞复述官方文档的内容。
  • AI生成的填充内容。任何无法确定作者或发布时间的内容。

Smell test before you trust a page

信任页面之前的嗅探测试

  • Who wrote it, and do they have standing on this topic?
  • When — is it dated, and recent enough for the version in question?
  • Does it add signal over the official docs, or just rephrase them?
  • Does it show its work — real code, real output, specifics — or hand-wave?
  • Does it agree with the primary source? If a blog and the docs disagree, the docs (or the source code) win.
If a page fails the smell test, drop it and find a Tier A/B source instead. Don't launder a low-quality claim into your answer.
  • 作者是谁？他们在该领域是否有权威性？
  • 时间——内容是否有日期？是否适用于当前讨论的版本？
  • 它是否比官方文档提供更多有效信息，还是仅仅复述文档内容？
  • 它是否展示了实际操作——真实代码、真实输出、具体细节——还是含糊其辞？
  • 它是否与一手来源一致？如果博客与官方文档存在分歧，以文档（或源代码）为准。
如果某页面未通过嗅探测试，请放弃它，转而寻找A级/B级来源。不要将低质量的说法混入你的回答中。

Verify before you assert

断言前先验证

  • Cross-check every load-bearing claim against a primary source.
  • When sources disagree, say so and explain which you trust and why — don't silently pick one.
  • Cite what you actually read (the URL/source), not where you think the information lives.
  • If you couldn't verify something, label it unverified rather than stating it as fact. "I couldn't confirm this" is a valid, valued answer; a confident guess is not.
  • 针对每个关键论断，与一手来源进行交叉验证。
  • 当来源之间存在分歧时，请明确说明，并解释你信任哪一个及原因——不要默默选择其一。
  • 引用你实际阅读过的内容（URL/来源），而非你认为信息可能存在的地方。
  • 如果无法验证某内容，请标记为未验证，而非将其作为事实陈述。“我无法确认这一点”是有效的、有价值的回答；而自信的猜测则不是。

Source-driven implementation

基于来源的实现

When research feeds framework-specific code, the implementation decision must trace to official documentation for the detected version. Read dependency files first (
package.json
, 
pyproject.toml
, 
go.mod
, etc.), fetch the relevant official docs or source, implement the documented pattern, and cite the source in the handoff. Do not use blog posts, examples from memory, or training data as primary authority for current APIs.
当研究成果用于框架特定代码的实现时，实现决策必须追溯到对应检测版本的官方文档。首先读取依赖文件（
package.json
, 
pyproject.toml
, 
go.mod
, etc.），获取相关官方文档或源代码，按照文档记录的模式实现，并在交接时引用来源。不要将博客文章、记忆中的示例或训练数据作为当前API的主要依据。

When this feeds a build decision

当研究成果用于构建决策时

Choosing a library/tool from this research? Hand the candidates to [[library-first-development]] for the vetting step — adoption, maintenance, bus factor, license, security.
Original skill for Oisín's skills repo, with source-driven implementation guidance folded in from local oisin-pipeline material. Pairs with [[library-first-development]]; the same "verify, don't assume" discipline as [[fix]].
如果通过本次研究选择库/工具？请将候选对象移交至[[library-first-development]]进行审核——包括采用情况、维护状态、关键人员依赖风险、许可证、安全性。
本技能最初来自Oisín的技能仓库，融合了本地oisin-pipeline材料中关于基于来源实现的指导内容。与[[library-first-development]]搭配使用；遵循与[[fix]]相同的“验证而非假设”原则。