Rednote Research

RedNote Community Intelligence

Research a topic with a RedNote/Xiaohongshu-first lens. Default to public-web mode, but support an optional login-enhanced path when the user explicitly wants fuller coverage. Expand queries deliberately, collect signals from multiple source types, separate evidence from vibe, and return a concise report that is honest about uncertainty.

Access modes

Read references/access-modes.md when deciding whether to stay in public-web mode or offer login-enhanced browser review. Read references/login-enhanced-workflow.md when the user explicitly chooses deeper access and you need an execution pattern for authenticated review. Read references/minimal-user-input-paths.md when public-web access is weak and the user prefers not to log in. Read references/account-summary-template.md when the task is to summarize a creator/account or recent posting behavior.

Default behavior:

• start in public-web mode
• do not assume login
• if the user wants fuller account-level, recent-post, or comment-level coverage, offer the login-enhanced path as an explicit choice
• if the user declines login, ask for the smallest useful seed input instead of giving up
• state in the final answer whether findings came from public-web mode or login-enhanced mode

Core operating rules

• Treat RedNote as a signal-discovery layer, not final proof.
• Prefer a few inspectable sources over many shallow snippets.
• Separate direct evidence, repeated anecdote, platform chatter, and rumor.
• Put dates on fast-moving claims whenever possible.
• Do not imply access to hidden comments, full threads, or app-only media.
• If a page is inaccessible, do not overclaim from the search snippet alone.
• Keep modality explicit: text-page, screenshot, image, video, gif, audio, or transcript.
• Separate extraction from interpretation: OCR/ASR output is evidence, not automatic truth.
• When media access is partial, say exactly what is visible and what remains uninspectable.

Default workflow

1. Clarify the subject, time scope, geography, output goal, and whether the user wants no-login mode or login-enhanced mode.
2. Start in public-web mode unless the user explicitly chooses login-enhanced mode.
3. Build a compact query set with mixed query families.
4. Search broadly across RedNote, official sources, media, and supporting review sites.
5. If public-web coverage is too thin for the task, explain that and offer login-enhanced browser review as the next step.
6. Extract recurring claims, contradictions, and missing evidence.
7. Score credibility separately from risk or recommendation strength.
8. Deliver a short report with links, caveats, next checks, and a brief note about which access mode was used.

1) Clarify the research target

Identify:

• canonical name in Chinese and English
• aliases, abbreviations, nicknames, hashtags, old names
• category: education, policy, gossip, local, or general
• geography if relevant: city, district, mall, campus, country, online/offline
• time scope: latest 7 days, latest month, current season, or broader background
• user intent: reputation check, update scan, controversy synthesis, shortlist, comment analysis, or post/video analysis

If the prompt is broad, infer likely aliases before searching.

For account-summary tasks, ask for the smallest useful identifier if available: profile URL, user ID/handle, screenshot, copied title list, or 3-5 recent note links. If the user wants fuller coverage and agrees to log in, switch from public-web mode to login-enhanced browser review instead of pretending public-web search is complete. If the user does not want login, read references/minimal-user-input-paths.md and ask for the least burdensome seed material that will improve coverage.

2) Build queries

Use scripts/query_builder.py when deterministic query expansion would help, especially if you need a media-focused query set or a starter claim log schema. Use scripts/recovery_query_builder.py when your starting point is weak public-web evidence: a thin search snippet, partial title, OCR fragment, subtitle line, hashtag, price, or visible date that needs recovery-oriented search pivots.

Prefer a mixed query set instead of one giant keyword dump:

• overview: baseline discovery
• latest: newest updates and recent turns in sentiment
• trending: hot discussion and rumor-tracking discovery
• comment: comment-area reactions and repeated talking points
• review: reputation, quality, warning signs, user experience
• recommendation: worth-it, shortlist, comparison, local picks
• verification: official notices, registration records, named responses, implementation details

Typical source patterns:

• site:xiaohongshu.com <entity> <modifier>
• site:www.xiaohongshu.com <entity> <modifier>
• <entity> 小红书 <modifier>
• <entity> <modifier>

Category hints:

• education: 口碑, 避雷, 退费, 课程质量, 就业, offer, 合同, 维权
• policy: 政策, 新规, 通知, 官方回应, 执行, 解读, 影响
• gossip: 爆料, 八卦, 翻车, 塌房, 争议, 后续, 聊天记录, 回应
• local: 推荐, 探店, 菜品, 排队, 价格, 服务, 环境, 值不值, 避雷
• general: 评价, 口碑, 体验, 真实反馈, 怎么样, 值不值

Query-building heuristics:

• Start with 8-16 queries, not 40+.
• Mix discovery queries with 2-4 verification queries.
• Add geography for local or policy tasks.
• Use a narrow time scope for fast-moving topics.
• Search aliases and nicknames when drama or local slang is involved.
• For cross-market topics, run both Chinese and English variants.

3) Search public-web sources

Prefer breadth before depth. Search first, then fetch only the strongest pages.

Target source mix:

• RedNote/Xiaohongshu indexed pages and snippets
• official statements, brands, schools, stores, regulators, or platform notices
• reputable media reports for disputes or policy coverage
• maps/review/listing sites for local businesses
• forums and other community sites only as supplementary anecdotal signals

Search heuristics:

• favor recency for policy, gossip, and local recommendations
• keep a short source list with one-line relevance notes
• search exact names, aliases, hashtags, and comparison targets
• cross-check surprising claims with at least one non-RedNote source when possible
• if the task is about a specific account and public-web search returns thin results, say so explicitly instead of overclaiming; then offer the login-enhanced path or ask for a few seed links/screenshots

4) Extract claims and discussion patterns

Normalize findings into compact bullets with fields like:

• claim type: complaint / praise / neutral fact / official claim / media report / rumor / recommendation
• theme: pricing, quality, service, fraud risk, policy impact, taste, queue, environment, controversy, support, etc.
• evidence snippet
• source URL
• source class
• visible date
• repetition count if multiple sources echo the same point

Read references/output-patterns.md when you need output templates or comment clustering patterns. Read references/claim-log-schema.md when the task is evidence-heavy, rumor-sensitive, or needs claim-by-claim tracking. Read references/multimodal-capture.md when screenshots, images, videos, gifs, subtitles, or audio cues materially affect the answer. Read references/public-web-recovery.md when the first page is partial, blocked, snippet-only, or clearly weaker than the underlying media/discussion. Use scripts/claim_log_tools.py to initialize, normalize, or summarize a structured claim log when you have enough evidence items that manual tracking will become noisy.

Post / comment / screenshot / image / video / gif / audio analysis

Stay explicit about what is and is not directly observable from public-web access.

Break analysis into layers:

1. Surface metadata — visible title, caption, date, platform text, source URL.
2. Observed media evidence — visible text, OCR-able text, subtitles, scene details, sequence, speaker labels, or audio/transcript clues.
3. Content summary — what is clearly shown, spoken, or claimed.
4. Reaction summary — visible comment themes, sentiment split, repeated jokes, skepticism, support.
5. Credibility check — firsthand evidence vs repost vs edit-heavy clip vs rumor relay.
6. Open questions — what would require login, in-app rendering, browser automation, direct file access, frame extraction, OCR cleanup, or ASR.

If the user provides screenshots, transcripts, fetched page text, or media files, analyze those directly and keep extraction separate from interpretation.

Claim-first working pattern

When the topic is messy, do not jump straight from search results to a vibe summary.

Use this loop instead:

1. list the 2-6 decision-relevant claims
2. attach evidence items with explicit modality and access level
3. downgrade anything that remains snippet-only or relay-only
4. summarize only after the strongest claim/evidence pairs are visible

Good trigger conditions for a claim log:

• rumor-heavy controversies
• screenshot-led accusations
• policy interpretation disputes
• local recommendation tasks with sharply conflicting chatter
• any answer where you need to explain why one repeated claim is still weak

5) Verify before concluding

Read references/verification-patterns.md when the task involves rumors, policy changes, business legitimacy, or claims that could materially affect a decision.

Default verification moves:

• find the earliest visible source, not just the loudest repost
• separate claim, response, and confirmed consequence
• check whether the page is firsthand, quoted, scraped, or relayed
• look for official names, dates, location details, and implementation language
• for local businesses, compare RedNote chatter with maps/review data or official menu/hours pages
• for policy topics, prioritize primary notices over interpretation posts
• for gossip, keep anonymous screenshots and clipped media at rumor level unless independently corroborated
• for screenshots, note whether key text is fully visible, cropped, or OCR-uncertain
• for videos, distinguish caption-level evidence from frame-level evidence
• for audio claims, distinguish direct transcript, ASR-derived wording, and second-hand paraphrase