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.
- Start in public-web mode unless the user explicitly chooses login-enhanced mode.
- Build a compact query set with mixed query families.
- Search broadly across RedNote, official sources, media, and supporting review sites.
- If public-web coverage is too thin for the task, explain that and offer login-enhanced browser review as the next step.
- Extract recurring claims, contradictions, and missing evidence.
- Score credibility separately from risk or recommendation strength.
- 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 INLINECODE8 - 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 - INLINECODE13 : newest updates and recent turns in sentiment
- INLINECODE14 : hot discussion and rumor-tracking discovery
- INLINECODE15 : comment-area reactions and repeated talking points
- INLINECODE16 : reputation, quality, warning signs, user experience
- INLINECODE17 : worth-it, shortlist, comparison, local picks
- INLINECODE18 : official notices, registration records, named responses, implementation details
Typical source patterns:
- - INLINECODE19
- INLINECODE20
- INLINECODE21
- INLINECODE22
Category hints:
- -
education: 口碑, 避雷, 退费, 课程质量, 就业, offer, 合同, 维权 - INLINECODE24 : 政策, 新规, 通知, 官方回应, 执行, 解读, 影响
- INLINECODE25 : 爆料, 八卦, 翻车, 塌房, 争议, 后续, 聊天记录, 回应
- INLINECODE26 : 推荐, 探店, 菜品, 排队, 价格, 服务, 环境, 值不值, 避雷
- INLINECODE27 : 评价, 口碑, 体验, 真实反馈, 怎么样, 值不值
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.
- Observed media evidence — visible text, OCR-able text, subtitles, scene details, sequence, speaker labels, or audio/transcript clues.
- Content summary — what is clearly shown, spoken, or claimed.
- Reaction summary — visible comment themes, sentiment split, repeated jokes, skepticism, support.
- Credibility check — firsthand evidence vs repost vs edit-heavy clip vs rumor relay.
- 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
- attach evidence items with explicit modality and access level
- downgrade anything that remains snippet-only or relay-only
- 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
6) Score credibility and decision risk
Read references/scoring-rubric.md when you need the full rubric.
Use at least two separate judgments:
Credibility score (0-5)
- - 5: official documents, regulator notices, court/government records, direct statements, reputable reporting
- 4: detailed firsthand post or review with dates, screenshots, prices, names, or concrete specifics
- 3: specific but weakly corroborated anecdote or snippet
- 2: vague anecdote, repost, engagement bait, or SEO page
- 1: obvious rumor or unsourced assertion
- 0: cannot inspect or verify
Risk / caution / recommendation score (0-5)
Interpret the second score according to task type:
- - education / reputation / policy / gossip: higher means more caution or downside risk
- local recommendation: higher can mean stronger recommendation confidence only if you label it explicitly; otherwise keep it as caution risk to avoid ambiguity
Weight repeated, independent, recent, and specific evidence more heavily than loud but vague posts.
7) Deliver the report
Keep the report concise and decision-oriented.
Choose the smallest fitting format:
A) Quick snapshot
- - Subject:
- Category:
- Time scope:
- Overall signal: positive / mixed / caution / high risk / inconclusive
- Confidence: low / medium / high
B) Findings
- - 3-6 bullets, strongest evidence first
C) Evidence list
Use compact bullets when tables are awkward:
D) Discussion clusters
- - cluster name
- representative wording pattern
- approximate repetition count
- confidence note
E) What remains unverified
- - missing items that public-web access cannot confirm
F) Suggested next checks
- - official notice or registration lookup
- a more recent search window
- map/review cross-check for local places
- direct in-app or browser review if the user wants deeper comment or media extraction
Fast paths
Quick reputation check
- 1. Build a mixed
overview + review + verification query set. - Search 6-12 strong queries.
- Capture 5-10 sources.
- Score each source.
- Return a short summary plus caveats.
Latest update or policy scan
- 1. Use
latest + trending + verification. - Bias toward the last 7-30 days.
- Separate official update from community interpretation.
- State whether the trend is confirmed, contested, or still rumor-level.
Local recommendation scan
- 1. Use category
local. - Mix review, recommendation, complaint, and verification queries.
- Cluster themes: taste, price, queue, service, environment, location convenience.
- Return a shortlist plus tradeoffs, not just one winner.
Comment or post analysis
- 1. Collect visible text, screenshots, snippets, or transcript first.
- Cluster reactions into 3-5 themes.
- Mark what is directly seen vs inferred.
- State clearly when deeper extraction would require login, browser automation, or direct media processing.
- If the user wants deeper comment-level coverage, offer login-enhanced mode as an explicit escalation path.
- If the user declines login, ask for screenshots or copied comment text instead of pretending the full thread was inspected.
Account summary or recent-post scan
- 1. Start with public-web mode and gather any inspectable profile URL, note URLs, snippets, mirrors, or search-engine traces.
- Read
references/account-summary-template.md for output structure. - If the goal is a broad impression only, summarize from public-web evidence with caveats.
- If the goal is recent-post completeness, tell the user public-web coverage may be partial and offer login-enhanced browser review.
- If the user chooses login-enhanced mode, read
references/login-enhanced-workflow.md and follow the controlled authenticated-review path. - If the user does not want login, read
references/minimal-user-input-paths.md and ask for a few seed links, screenshots, or copied note titles to improve coverage. - Distinguish clearly between account-level observations, note-level evidence, and anything missing because of access limits.
Screenshot / image-led analysis
- 1. Capture the page context plus image-visible text, prices, dates, names, and watermarks.
- Note image legibility and likely OCR uncertainty.
- Separate image-contained claims from caption-contained claims.
- If the page itself is weak, pivot on the strongest visible fragment with
scripts/recovery_query_builder.py. - Log the strongest inspectable claim(s) before summarizing.
Video / subtitle / gif-led analysis
- 1. Capture caption, visible duration, upload date, and any subtitle/on-screen text.
- Distinguish clip content from commentary about the clip.
- If you only have snippet-level access, keep conclusions provisional and pivot on distinctive subtitle fragments or overlays with
scripts/recovery_query_builder.py. - Say whether frames or the original file would materially improve confidence.
Audio / transcript-led analysis
- 1. Identify whether you have direct audio, subtitles, ASR text, or only quoted paraphrases.
- Treat transcript quality as part of the evidence rating.
- Avoid overreading tone, sarcasm, or exact wording without direct audio access.
- If the only foothold is a quoted line, subtitle fragment, or repost caption, use
scripts/recovery_query_builder.py to search for the earliest visible source or mirrors. - Log the spoken claim separately from reactions to it.
Reliability caveats
- - Search indexing can lag behind live app discussion.
- Viral repetition does not equal verification.
- Snippets can omit qualifiers or updates visible only on the landing page.
- Local quality and policy enforcement can change quickly; recency matters.
- Platform anti-bot controls can make no-login account research much thinner than in-app browsing.
- If evidence stays thin after cross-checking, say
inconclusive rather than stretching.
Recommended product posture
Treat this skill as a dual-mode RedNote research tool:
- - public-web mode for broad research, weak-clue recovery, and no-login investigations
- login-enhanced mode for fuller account, recent-post, and comment review when the user explicitly opts in
When neither mode is enough on its own, use a hybrid path:
- - public-web evidence + a few user-provided links/screenshots
技能名称: rednote-research
详细描述:
小红书社区情报
以小红书/红书优先的视角研究某个话题。默认使用公共网页模式,但当用户明确希望获得更全面的覆盖时,支持可选的登录增强路径。审慎地扩展查询,从多种来源类型收集信号,将证据与氛围区分开来,并返回一份对不确定性坦诚的简洁报告。
访问模式
在决定是保持公共网页模式还是提供登录增强的浏览器审查时,请阅读 references/access-modes.md。
当用户明确选择更深层次的访问,并且你需要一个经过身份验证的审查执行模式时,请阅读 references/login-enhanced-workflow.md。
当公共网页访问较弱且用户不希望登录时,请阅读 references/minimal-user-input-paths.md。
当任务是总结一个创作者/账户或近期的发帖行为时,请阅读 references/account-summary-template.md。
默认行为:
- - 从公共网页模式开始
- 不假设用户已登录
- 如果用户想要更全面的账户级别、近期帖子或评论级别的覆盖,将登录增强路径作为一个明确的选择提供
- 如果用户拒绝登录,则要求提供最小有用的种子输入,而不是放弃
- 在最终答案中说明发现结果来自公共网页模式还是登录增强模式
核心操作规则
- - 将小红书视为信号发现层,而非最终证据。
- 优先选择少数可检查的来源,而非大量浅层片段。
- 区分直接证据、重复传闻、平台讨论和谣言。
- 尽可能为快速变化的主张标注日期。
- 不要暗示可以访问隐藏评论、完整帖子或仅限应用内的媒体。
- 如果页面无法访问,不要仅凭搜索片段过度断言。
- 保持模态明确:文本页面、截图、图片、视频、GIF、音频或文字记录。
- 将提取与解释分开:OCR/ASR输出是证据,而非自动事实。
- 当媒体访问不完整时,准确说明哪些是可见的,哪些仍无法检查。
默认工作流程
- 1. 明确主题、时间范围、地域、输出目标,以及用户是想要无登录模式还是登录增强模式。
- 除非用户明确选择登录增强模式,否则从公共网页模式开始。
- 构建一个包含混合查询系列的紧凑查询集。
- 在小红书、官方来源、媒体和支持性评论网站上进行广泛搜索。
- 如果公共网页覆盖范围对于当前任务来说过于薄弱,请解释这一点,并提供登录增强浏览器审查作为下一步。
- 提取重复出现的主张、矛盾和缺失的证据。
- 将可信度评分与风险或推荐强度分开。
- 交付一份包含链接、注意事项、后续检查以及关于使用了哪种访问模式的简短说明的报告。
1) 明确研究目标
确定:
- - 中英文规范名称
- 别名、缩写、昵称、标签、曾用名
- 类别:教育、政策、八卦、本地 或 综合
- 相关地域:城市、区域、商场、校园、国家、线上/线下
- 时间范围:最近7天、最近一个月、当前季度或更广泛的背景
- 用户意图:声誉核查、更新扫描、争议综合、候选名单、评论分析、帖子/视频分析
如果提示比较宽泛,在搜索前推断可能的别名。
对于账户总结任务,如果可用,要求提供最小的有用标识符:个人资料URL、用户ID/昵称、截图、复制的标题列表或3-5个近期笔记链接。如果用户想要更全面的覆盖并同意登录,则从公共网页模式切换到登录增强浏览器审查,而不是假装公共网页搜索是完整的。如果用户不想登录,请阅读 references/minimal-user-input-paths.md,并要求提供最不繁琐的、能改善覆盖范围的种子材料。
2) 构建查询
当确定性查询扩展有帮助时,特别是当你需要一个以媒体为中心的查询集或一个初步的主张日志模式时,使用 scripts/query_builder.py。
当你的起点是薄弱的公共网页证据时:一个浅层的搜索片段、部分标题、OCR片段、字幕行、标签、价格或可见日期,需要使用面向恢复的搜索支点,请使用 scripts/recoveryquerybuilder.py。
优先选择混合查询集,而不是一个巨大的关键词转储:
- - 概览:基线发现
- 最新:最新更新和近期情绪转变
- 热门:热门讨论和谣言追踪发现
- 评论:评论区反应和重复谈论点
- 评价:声誉、质量、警示信号、用户体验
- 推荐:值得、候选名单、比较、本地精选
- 验证:官方通知、注册记录、指定回应、实施细节
典型的来源模式:
- - site:xiaohongshu.com <实体> <修饰词>
- site:www.xiaohongshu.com <实体> <修饰词>
- <实体> 小红书 <修饰词>
- <实体> <修饰词>
类别提示:
- - 教育:口碑, 避雷, 退费, 课程质量, 就业, offer, 合同, 维权
- 政策:政策, 新规, 通知, 官方回应, 执行, 解读, 影响
- 八卦:爆料, 八卦, 翻车, 塌房, 争议, 后续, 聊天记录, 回应
- 本地:推荐, 探店, 菜品, 排队, 价格, 服务, 环境, 值不值, 避雷
- 综合:评价, 口碑, 体验, 真实反馈, 怎么样, 值不值
查询构建启发式规则:
- - 从8-16个查询开始,而不是40多个。
- 将发现查询与2-4个验证查询混合。
- 为本地或政策任务添加地域。
- 对快速变化的话题使用狭窄的时间范围。
- 当涉及戏剧性事件或本地俚语时,搜索别名和昵称。
- 对于跨市场话题,同时运行中文和英文变体。
3) 搜索公共网页来源
优先广度后深度。先搜索,然后只获取最强的页面。
目标来源组合:
- - 小红书索引页面和片段
- 官方声明、品牌、学校、商店、监管机构或平台通知
- 针对争议或政策报道的知名媒体报道
- 针对本地企业的地图/评论/列表网站
- 论坛和其他社区网站仅作为补充性的轶事信号
搜索启发式规则:
- - 对于政策、八卦和本地推荐,优先考虑近期性
- 保持一个简短的来源列表,并附上一行相关性说明
- 搜索确切名称、别名、标签和比较目标
- 尽可能用至少一个非小红书来源交叉核对令人惊讶的主张
- 如果任务涉及特定账户,且公共网页搜索结果薄弱,请明确说明,而不是过度断言;然后提供登录增强路径或要求提供一些种子链接/截图
4) 提取主张和讨论模式
将发现结果规范化为紧凑的要点,包含如下字段:
- - 主张类型:投诉 / 赞扬 / 中性事实 / 官方声明 / 媒体报道 / 谣言 / 推荐
- 主题:定价、质量、服务、欺诈风险、政策影响、口味、排队、环境、争议、支持等
- 证据片段
- 来源URL
- 来源类别
- 可见日期
- 如果多个来源重复相同的观点,记录重复次数
当你需要输出模板或评论聚类模式时,请阅读 references/output-patterns.md。
当任务证据密集、对谣言敏感或需要逐条追踪主张时,请阅读 references/claim-log-schema.md。
当截图、图片、视频、GIF、字幕或音频线索对答案有实质性影响时,请阅读 references/multimodal-capture.md。
当第一个页面不完整、被屏蔽、仅有片段或明显弱于底层媒体/讨论时,请阅读 references/public-web-recovery.md。
当你拥有足够多的证据项,手动追踪会变得杂乱时,使用 scripts/claimlogtools.py 来初始化、规范化或总结结构化的主张日志。
帖子 / 评论 / 截图 / 图片 / 视频 / GIF / 音频分析
明确说明哪些是公共网页访问可以直接观察到的,哪些不是。
将分析分解为几个层次:
- 1. 表面元数据 — 可见标题、说明文字、日期、平台文本、来源URL。
- 观察到的媒体证据 — 可见文本、可OCR文本、字幕、场景细节、序列、说话者标签或音频/文字记录线索。
- 内容摘要 — 明确展示、讲述或声称的内容。
- 反应摘要 — 可见的评论主题、情绪分布、重复的笑话、怀疑、支持。
- 可信度检查 — 第一手证据 vs 转发 vs 重度剪辑片段 vs 谣言接力。
- 未解决问题 — 哪些需要登录、应用内渲染、浏览器自动化、直接文件访问、帧提取、OCR清理或ASR。
如果用户提供了截图、文字记录、获取的页面文本或媒体文件,请直接分析这些内容,并将提取与解释分开。
###