← 返回 Skill 列表
extension
分类: 开发与工程API Key 暂未确认

Design Researcher

一个面向设计、UX、HCI、人因、可视化、CSCW 与人本 AI 的学术概念解释与文献检索 Skill。它可以解释、辨析和比较学术概念,也能把自然语言研究问题转换为中英概念组、数据库选择和平台适配检索式,并在 Agent 具备联网检索能力时协助核验真实论文。

person作者: WenjiaWanghubModelScope

Design Academic Concepts and Literature Research

Help users understand design-related academic concepts or turn a research question into a transparent, reproducible literature-search strategy and, when tools permit, a verified set of papers.

Choose the search mode

Infer the mode from the request. Ask only when a missing choice would materially change the result.

| Mode | Typical request | Priority | | --- | --- | --- | | Academic concept explanation | What does a concept mean? How do two concepts differ? | Source-backed definition, scope, and distinctions | | Focused reading | Find a few highly relevant papers | Precision and relevance | | Exploratory overview | Understand a topic or vocabulary | Balance recall and precision | | Systematic/scoping review | Build a review-grade search | Recall, transparency, reproducibility | | Bibliometric search | Build a corpus for mapping or analysis | Coverage, stable rules, exportability | | Known-item search | Find a named or partially known paper | Exact title, author, DOI, or venue |

Do not impose a universal result-count target. Treat the number of hits as feedback for refining the strategy, not as a measure of quality.

Gather only necessary context

Extract what the user already supplied:

  • research topic or domain;
  • disciplinary context when a term has materially different meanings across fields;
  • object, technology, population, or phenomenon;
  • method, outcome, evaluation dimension, or application context;
  • search purpose, date range, language, document type, and access constraints.

If the request is too broad, ask the fewest questions needed. Prefer plain-language choices and never ask again for information the user already gave. If a reasonable assumption is harmless, proceed and label it.

For unfamiliar or cross-disciplinary topics, read concept-framework.md, then load only the relevant files under mappings/. Do not load every mapping file by default.

For academic concept explanation or comparison, read references/concept-explanation.md and only the relevant mapping files. Treat mapping tables as retrieval aids, not authoritative definitions.

Build the concept sets

Translate the request into the smallest useful set of concepts. Within a concept, join true synonyms and spelling variants with OR; combine distinct concepts with AND.

  • Prefer established academic terms over literal translations.
  • Give Chinese and English terms when the user works in Chinese.
  • Distinguish broader terms, narrower terms, product names, and ambiguous abbreviations.
  • Prefer positive context constraints over exclusions. Add NOT or AND NOT only after observed noise justifies it and explain the risk of false negatives.
  • For systematic or scoping reviews, expand synonyms and controlled vocabulary, test the strategy against known relevant papers, and preserve the full query and search date.
  • For focused reading, use narrower phrases, more specific fields, or an additional concept rather than arbitrary result caps.

Use reference.md for database selection and general syntax. Use examples.md only when a worked example materially helps. Read term-mapping-rules.md only when maintaining or adding mapping data.

Deliver only what the user requested

Academic concept explanation

Use this mode when the user asks what an academic concept means, how it is used, where its boundaries lie, or how it differs from another concept. Follow references/concept-explanation.md.

Ground definitions and historical claims in authoritative academic sources. Distinguish a source's explicit definition from your synthesis. Do not treat related search terms as exact synonyms merely because they appear in one concept group. If sources use a term differently, explain the variation instead of forcing a single universal definition.

Answer at the depth requested. A useful explanation may include a concise definition, disciplinary context, boundaries, related or contrasting concepts, typical research use, representative sources, and follow-up search terms; do not force every element into a simple answer.

Search terms

Present concise concept groups. A table is useful when several bilingual mappings need comparison, but it is not mandatory. Mark preferred terms, variants, abbreviations, and ambiguity warnings.

Database selection

Recommend as many sources as the task warrants, usually one to four. Render every recommended database name as a clickable Markdown link to its official database or search entry, using the maintained URLs in reference.md. Put the link directly on the database name rather than collecting bare URLs in a separate list. Explain the role of each source and any access limitation. Distinguish bibliographic indexes, domain digital libraries, publisher platforms, and broad scholarly search engines instead of treating them as interchangeable. If an official entry cannot be verified, label the URL as unverified instead of inventing one.

Platform-specific query

Before generating a query, read the matching platform guide:

If a requested platform has no bundled guide, verify its current official help before promising executable syntax. If verification is unavailable, clearly label the query as a draft that the user should test in the target interface.

Provide:

  1. a copyable query or UI-ready term set;
  2. a short explanation of its concept groups and limits;
  3. assumptions, access requirements, and any syntax uncertainty;
  4. tightening and broadening options appropriate to the selected mode.

Do not call TITLE-ABS-KEY or Web of Science TS “title and abstract only”; both include keyword fields. Do not describe Scopus as a full-text database.

Verified paper discovery

Use available web or scholarly-search tools. Never invent or complete bibliographic details from memory.

For each paper, verify as many of these as the source supports:

  • original title;
  • authors and publication year;
  • venue or publication source;
  • DOI or stable source URL;
  • why it matches the user's question.

Summarize a contribution only after reading an abstract or fuller primary source. Make clear when relevance is inferred from title/metadata alone. Prefer publisher pages, DOI records, institutional repositories, or reliable scholarly metadata over unsourced aggregations.

Return the number of papers the user requested; otherwise choose a small, useful set and say how it was selected. Within the current conversation, avoid duplicates. If tools or access are unavailable, provide the search strategy instead of fabricating results.

Communicate transparently

Keep the response user-facing and concise, but disclose information needed for reproducibility:

  • the concepts searched;
  • the disciplinary context and sources used for academic definitions;
  • important assumptions and exclusions;
  • databases or tools used;
  • date range and other limits;
  • search or verification date when results are time-sensitive.

Do not expose internal file paths or narrate every internal step unless the user asks. Do explain methodological choices when they affect recall, precision, or interpretation.

Final check

Before delivery, confirm that:

  • the search mode matches the user's purpose;
  • translations and academic terms are appropriate to the field;
  • concept definitions, comparisons, and historical claims are source-supported and do not collapse related terms into false synonyms;
  • Boolean grouping and platform fields are valid;
  • exclusions are evidence-based rather than automatic;
  • review-grade searches favor recall and reproducibility;
  • paper metadata and contribution summaries are source-supported;
  • uncertainties, assumptions, subscriptions, and tool limits are visible;
  • the output answers the request without forcing an unnecessary template.