Anti-SEO Deep Consumer Researcher
Detailed rules, scoring criteria, and category examples: see INLINECODE0
Tool Availability & Graceful Degradation
This skill works best with web_search + web_fetch, but web_search is optional. If your environment does not have web_search available (e.g., no API key configured), the skill will automatically degrade to use built-in Bing scraping scripts instead.
Detection (run at skill startup)
At the very beginning, before any research steps, determine which search mode to use:
- 1. Full mode (preferred): If
web_search tool is available in your environment, use it directly for all search operations as described in the workflow below. - Fallback mode: If
web_search is NOT available (tool missing, API key not configured, or returns errors), use the built-in fallback script for ALL search operations:
CODEBLOCK0
The fallback script uses DuckDuckGo HTML search as the primary engine (most reliable, no captcha), with Bing HTML as automatic fallback — zero API keys needed. It outputs the same JSON format as web_search results.
Fallback Mode Workflow Adjustments
When in fallback mode, apply these adjustments throughout the entire workflow:
| Original (Full Mode) | Fallback Mode Replacement |
|---|
| INLINECODE8 | INLINECODE9 |
| INLINECODE10 |
python scripts/web_search_fallback.py "query" --site xxx.com |
| Step 2c: AI uses
web_search for forum searches | Use
platform_search.py with
--dual-window --append-year flags |
| Step 4.5: AI uses
web_search for safety events | Use
deep_dive_search.py with
--safety-only flag, OR
web_search_fallback.py |
Important: web_fetch is STILL used normally in fallback mode for fetching specific page content. Only web_search is replaced.
All other steps (credibility scoring, conflict resolution, brand scoring, report generation) work identically in both modes — they process search results regardless of how those results were obtained.
Architecture Overview
Language Detection → AI Category Adaptation → AI Multi-layer Search (forum posts + e-commerce reviews + social comment sections) → Script Scoring → AI Semantic Analysis → Dynamic Multi-dimensional Scoring → Report
- - Language & Region Layer: Detect user's language from query, generate region-specific platform config, search templates, and keyword dictionaries
- Category Layer: AI generates
category_profile JSON (evaluation dimensions/weights/pain point keywords/safety risks/platform weights/e-commerce search strategy) - Search Layer (3-tier data sources):
-
L1 E-commerce Review Layer (highest priority): Indirect search for real buyer reviews (e.g., Amazon reviews, JD follow-up reviews, depending on region)
-
L2 Social Comment Section Layer (second priority): Search for "debunking" feedback in comment sections of promotional posts
-
L3 Forum Post Layer (traditional): AI uses
web_search (or
web_search_fallback.py when
web_search is unavailable) +
site: for targeted community searches
- - Scoring Layer:
credibility_scorer.py (regex pre-filter + category signal injection + data source tier weighting) → ai_credibility_analyzer.py (AI deep analysis for gray zone 30-85 scores) - Multi-dimensional Scoring:
brand_scorer.py (dimensions/weights from profile, safety capping is category-adaptive) - Report Layer:
generate_report.py (dynamic table headers + data source distribution stats, from profile dimension definitions)
Multi-language & Multi-region Adaptation
Core Principle: This tool adapts to any language and region. The AI detects the user's language from their query and generates ALL region-specific configurations dynamically in the category_profile.
Language Detection Rules
- 1. Detect the language of the user's query (Chinese, English, Japanese, Korean, etc.)
- Infer the target market/region from context (e.g., Chinese query → China market; English query about "best vacuum" → likely US/UK market; Japanese query → Japan market)
- ALL subsequent search queries, keywords, and report text MUST match the detected language and region
- If the user explicitly mentions a region (e.g., "available in the UK", "sold on Amazon Japan"), use that region regardless of query language
Regional Platform Mapping
The AI MUST generate appropriate platform configurations based on the detected region. Below are reference mappings (the AI should adapt these based on actual availability and relevance):
China (zh-CN):
| Tier | Platforms | Examples |
|---|
| L1 E-commerce | JD.com, Taobao, Pinduoduo | Review aggregation posts, follow-up reviews |
| L2 Social Comments |
Xiaohongshu, Zhihu | "Debunking" comments under promotional posts |
| L3/L4 Forums | V2EX, Chiphell, NGA, Baidu Tieba, SMZDM, Douban, Bilibili | Community discussions, in-depth reviews |
United States / English-speaking (en-US):
| Tier | Platforms | Examples |
|---|
| L1 E-commerce | Amazon, Best Buy, Walmart | Verified purchase reviews, long-term reviews |
| L2 Social Comments |
Reddit, YouTube comments | Comment sections debunking sponsored content |
| L3/L4 Forums | Reddit (subreddits), Head-Fi, AVSForum, Wirecutter comments, Slickdeals | Community discussions, enthusiast reviews |
Japan (ja-JP):
| Tier | Platforms | Examples |
|---|
| L1 E-commerce | Amazon.co.jp, Rakuten, Kakaku.com | Purchase reviews, price comparison reviews |
| L2 Social Comments |
Twitter/X, note.com comments | Real user feedback under promotional content |
| L3/L4 Forums | Kakaku.com forums, 5ch, Price.com | Community discussions, expert reviews |
South Korea (ko-KR):
| Tier | Platforms | Examples |
|---|
| L1 E-commerce | Coupang, Naver Shopping | Purchase reviews |
| L2 Social Comments |
Naver Blog comments, Instagram | Real feedback |
| L3/L4 Forums | DC Inside, Naver Cafe, Clien | Community discussions |
Europe (various):
| Tier | Platforms | Examples |
|---|
| L1 E-commerce | Amazon (regional), Trustpilot | Purchase reviews, trust scores |
| L2 Social Comments |
Reddit, YouTube, regional social | Comment section feedback |
| L3/L4 Forums | Regional forums, Reddit (subreddits) | Community discussions |
Regional Regulatory Authorities
Safety event searches must include the correct regulatory bodies for the target region:
| Region | Regulatory Bodies |
|---|
| China | SAMR (State Administration for Market Regulation), CFDA |
| US |
FDA, CPSC, FTC |
| EU | EFSA, ECHA, national agencies |
| Japan | MHLW, CAA, NITE |
| South Korea | MFDS, KCA |
Regional Marketing Signal Adaptation
Each region has different marketing manipulation patterns. The AI MUST generate region-appropriate marketing signals in category_profile:
China: SEO manipulation keywords (e.g., marketing buzzwords, "zhong cao/ba cao" patterns), fake review indicators, WeChat marketing patterns
US/UK: Affiliate link indicators, sponsored content disclaimers, Amazon vine/incentivized review patterns, influencer disclosure signals
Japan: Stealth marketing (ステマ) indicators, PR article patterns, affiliate blog signals
Universal: Excessive superlatives, zero-defect descriptions, brand-official language repetition
Data Source Tier Strategy
Problem: Over-reliance on search-engine-indexable "post-type" content (forum answers, review articles) where the ad-to-content ratio is high. E-commerce platforms' real purchase reviews and social platforms' comment section feedback have higher information density and higher cost of astroturfing, but are dynamically loaded and cannot be directly indexed by search engines.
Solution: Use indirect search strategies (search for "review compilation posts", "follow-up review summaries", "negative review roundups", etc.) to access e-commerce reviews and comment section data.
| Data Source Tier | Source | Core Value | Base Credibility Weight |
|---|
| L1 E-commerce Reviews | Platform purchase reviews (indirect) | Real buyers with real money, long-term follow-up reviews | 0.85 |
| L2 Comment Sections |
Social platform comment sections (indirect) | Real "debunking" feedback on promotional content | 0.75 |
| L3 Forum Posts | Community forums (per region) | Enthusiast deep experience, comparisons | Uses platform_relevance |
| L4 Independent Posts | Q&A platforms, review sites | Systematic review frameworks | Uses platform_relevance |
Key Constraint: E-commerce review layer and comment section layer searches should account for no less than 30% of total search volume.
Workflow (7 Steps)
Step 1: Interactive Requirements Confirmation
Core Principle: Research cannot be interrupted once started (time-consuming and token-intensive), so requirements must be confirmed before starting. Better to ask one more question than to research in the wrong direction.
Mandatory Confirmation Items (MUST ask user if missing):
- - Target Category: What does the user want to buy? — Never assume the category
- Budget Range: What is the price range? — Never use a default budget
- Core Use Case or Pain Point: What is the main purpose? What matters most? — Never assume the need
Conditional Confirmation Items (proactively ask when relevant):
- - When significant version/channel differences exist (e.g., domestic vs. import versions, regional variants) → confirm variant preference
- When brand preference is apparent → confirm whether to limit to specific brands
- When user needs are ambiguous → use multiple-choice questions to confirm
Confirmation Format: Use short multiple-choice or open questions, max 3 questions.
After confirmation, output task_config (for reference in subsequent steps):
CODEBLOCK1
Skip confirmation only if ALL conditions are met:
- 1. Category is clear (e.g., "recommend a $200 gaming keyboard")
- Budget is clear (has specific numbers or clear range)
- Use case is clear (e.g., "for gaming", "for my baby")
Step 1.5: AI Category-Adaptive Analysis
Before searching, generate category_profile JSON, strictly following this Schema:
CODEBLOCK2
Constraints: 3-6 dimensions, max 0.4 weight per dimension, weights sum to 1.0. Platform weights adjusted per category. [product] placeholders in search_templates are replaced with actual product names during search.
CRITICAL: The regional_platforms, marketing_signals, authenticity_signals, ecommerce_search_strategy, comment_section_strategy, safety_search_config, and report_labels fields are ALL dynamically generated by the AI based on the detected locale. They must be in the user's language and appropriate for the user's region. The scripts will read these from the profile and use them instead of hardcoded defaults.
Step 2: Multi-layer Data Source Search (with E-commerce + Comment Section + Result Adaptation)
Search in 3 tiers from highest to lowest data source priority, ensuring high-value sources get priority coverage.
Step 2a: E-commerce Review Indirect Search (L1, ≥15% of total)
E-commerce platform reviews are dynamically loaded — search engines cannot directly index them. Use indirect strategies from ecommerce_search_strategy.search_templates.
Tag results with source_layer: "L1_ecommerce", base_weight: 0.85.
Step 2b: Social Comment Section Indirect Search (L2, ≥15% of total)
Search for real "debunking" feedback in comment sections. Use templates from comment_section_strategy.search_templates.
Tag results with source_layer: "L2_comment_section", base_weight: 0.75.
Step 2c: Forum Post + Independent Post Search (L3/L4, ≤70% of total)
Full mode: Use web_search + site: for targeted searches on platforms from regional_platforms.
Fallback mode: Use python scripts/platform_search.py or python scripts/web_search_fallback.py --site [domain] instead.
Search Balance Strategy: 40% neutral + 20% positive + 40% negative.
Dual Time Window: Each search group combines current year (instant window) + no year limit (historical window).
Platform Priority: Sort by platform_relevance weight, skip platforms with weight < 0.2.
Search Keyword Construction (in the user's language):
- - Neutral: INLINECODE54
- Positive: INLINECODE55
- Negative: INLINECODE56
Search Result Adaptation:
| Sufficiency | Condition | Strategy |
|---|
| Sufficient | Total ≥30 AND ≥5 per product | Proceed normally |
| Mostly Sufficient |
Total ≥15 AND ≤1 product underserved | Supplement search for underserved product |
| Insufficient | Total <15 OR multiple products underserved | Remove site: restriction, expand time window, add platforms |
| Severely Insufficient | Total <8 | Niche category mode: lower scoring thresholds, note data limitations in report |
CODEBLOCK3
Step 3: Content Fetching & Analysis
INLINECODE57 to retrieve valuable posts (containing usage duration, multi-person discussion, no marketing keywords in title).
Step 3.5: Category Parameter Structured Extraction
Extract structured parameter tables for candidate products based on evaluation_dimensions[].key_parameters.
Step 4: Dynamic Deep Dive (with E-commerce Review Deep Dive)
Execute negative long-tail searches for high-frequency models, using keywords from pain_point_keywords.
E-commerce review deep dive: For each candidate model, execute additional e-commerce review searches using templates from the profile.
CODEBLOCK4
Step 4.5: Safety Event Search
For each candidate brand, search for safety events across the web. Two-tier classification: general layer (recall/death/removal) + category layer (safety_risk_types). Use keywords from safety_search_config.
CODEBLOCK5
Step 5: Credibility Assessment
CODEBLOCK6
Scoring Architecture: Regex pre-filter → Category signal injection (from profile) → AI semantic analysis (gray zone 30-85) → Weighted fusion
Step 5.5: Evidence Conflict Arbitration
When the same product receives contradictory reviews from different sources:
CODEBLOCK7
Arbitration rules: Non-commercial sources > commercial sources, long-term feedback > short-term feedback, high credibility > low credibility.
Step 6: Multi-dimensional Scoring
CODEBLOCK8
| Score | Verdict |
|---|
| ≥70 | Recommend (use report_labels.recommend) |
| 55-69 |
Conditional Recommend (use
report_labels.conditional_recommend) |
| 40-54 | Caution (use
report_labels.caution) |
| <40 | Avoid (use
report_labels.avoid) |
Safety Capping: food (threshold 30) > personalcare (25) > electronics (20) > durablegoods (15)
Step 7: Report Generation
CODEBLOCK9
The report MUST be written in the user's language (as specified by category_profile.language). All section headers, verdicts, labels, and analysis text must match the user's language.
Key Rules (Non-skippable)
- 1. Confirm requirements before searching — Budget, category, and use case are all mandatory; ask user if any are missing
- Never assume user needs — If user says "recommend a phone" without budget or use case, ask first
- Generate category_profile before searching — It is the foundation for all subsequent steps
- Search twice — After broad search, always do targeted negative deep dive on high-frequency models
- Append year to searches — Include current year and previous year
- Negative search ratio ≥40% — Actively search for negatives; finding none means search depth is insufficient
- Safety events MUST be searched — Top recommended brands must pass safety event screening
- Adapt search results — Expand when insufficient, trim when excessive
- High-engagement content needs scrutiny — High upvotes/likes ≠ authenticity (applies to Zhihu, Reddit, etc.)
- Prioritize long-term feedback — "Used for 2 years" is 10x more valuable than "just bought, looks great"
- Cross-validation is core — Commercial review says good + niche forum complains → trust the latter
- Profile is the sole category knowledge source — Script hardcoded values are only fallback
- E-commerce review layer is mandatory — Every research must include e-commerce review indirect search (L1), ≥15% of total
- Comment section layer is mandatory — Every research must include social comment section search (L2), ≥15% of total
- Follow-up reviews > unboxing — Long-term follow-up reviews (3+ months) are far more valuable than unboxing reviews
- Comment sections > post body — Real "debunking" feedback in comment sections takes priority over the post's own conclusions
- Match user's language throughout — ALL search queries, scoring labels, and the final report MUST be in the user's language
反SEO深度消费者研究员
详细规则、评分标准和类别示例:参见 references/SKILL_REFERENCE.md
工具可用性与优雅降级
本技能最佳运行环境为 websearch + webfetch,但 websearch 为可选工具。若您的环境没有 websearch 可用(例如未配置 API 密钥),技能将自动降级,使用内置的必应抓取脚本替代。
检测(技能启动时执行)
在开始任何研究步骤之前,首先确定使用哪种搜索模式:
- 1. 完整模式(首选):如果您的环境中 websearch 工具可用,则直接使用它进行下述工作流程中的所有搜索操作。
- 降级模式:如果 websearch 不可用(工具缺失、API 密钥未配置或返回错误),则对所有搜索操作使用内置的降级脚本:
bash
替代:web_search(电竞椅 推荐 避坑 2025)
使用:
python scripts/web
searchfallback.py 电竞椅 推荐 避坑 2025 --count 10 --days 365
替代:web_search(site:reddit.com office chair review)
使用:
python scripts/web
searchfallback.py office chair review --site reddit.com --count 10
多站点搜索(独立搜索每个站点):
python scripts/web
searchfallback.py 电竞椅 推荐 --sites zhihu.com,v2ex.com,smzdm.com --count 5
一次调用完成搜索并获取内容(减少往返次数):
python scripts/web
searchfallback.py 电竞椅 避坑 --count 10 --fetch-content --fetch-limit 3
降级脚本使用 DuckDuckGo HTML 搜索作为主要引擎(最可靠,无验证码),并以必应 HTML 作为自动降级——无需任何 API 密钥。它输出与 web_search 结果相同的 JSON 格式。
降级模式工作流程调整
在降级模式下,对整个工作流程应用以下调整:
| 原始(完整模式) | 降级模式替代方案 |
|---|
| websearch(query) | python scripts/websearchfallback.py query --count 10 |
| websearch(site:xxx.com query) |
python scripts/web
searchfallback.py query --site xxx.com |
| 步骤 2c:AI 使用 web
search 进行论坛搜索 | 使用 platformsearch.py 并添加 --dual-window --append-year 标志 |
| 步骤 4.5:AI 使用 web
search 进行安全事件搜索 | 使用 deepdive
search.py 并添加 --safety-only 标志,或使用 websearch_fallback.py |
重要提示:在降级模式下,webfetch 仍然正常用于获取特定页面内容。仅替换 websearch。
所有其他步骤(可信度评分、冲突解决、品牌评分、报告生成)在两种模式下完全相同——它们处理搜索结果,无论这些结果是如何获得的。
架构概览
语言检测 → AI 类别自适应 → AI 多层搜索(论坛帖子 + 电商评论 + 社交评论区)→ 脚本评分 → AI 语义分析 → 动态多维评分 → 报告
- - 语言与区域层:从查询中检测用户语言,生成特定区域的平台配置、搜索模板和关键词词典
- 类别层:AI 生成 category_profile JSON(评估维度/权重/痛点关键词/安全风险/平台权重/电商搜索策略)
- 搜索层(3 层数据源):
-
L1 电商评论层(最高优先级):间接搜索真实买家评论(例如亚马逊评论、京东追评,取决于区域)
-
L2 社交评论区层(第二优先级):搜索推广帖子评论区中的辟谣反馈
-
L3 论坛帖子层(传统):AI 使用 web
search(或当 websearch 不可用时使用 web
searchfallback.py)+ site: 进行针对性社区搜索
- - 评分层:credibilityscorer.py(正则预过滤 + 类别信号注入 + 数据源层级加权)→ aicredibilityanalyzer.py(AI 深度分析,针对 30-85 分的灰色地带)
- 多维评分:brandscorer.py(维度/权重来自 profile,安全上限根据类别自适应)
- 报告层:generate_report.py(动态表头 + 数据源分布统计,来自 profile 维度定义)
多语言与多区域自适应
核心原则:本工具适应任何语言和区域。AI 从用户查询中检测其语言,并在 category_profile 中动态生成所有特定区域的配置。
语言检测规则
- 1. 检测用户查询的语言(中文、英文、日文、韩文等)
- 从上下文中推断目标市场/区域(例如,中文查询 → 中国市场;关于best vacuum的英文查询 → 可能为美国/英国市场;日文查询 → 日本市场)
- 所有后续的搜索查询、关键词和报告文本必须与检测到的语言和区域匹配
- 如果用户明确提及某个区域(例如available in the UK、sold on Amazon Japan),则使用该区域,无论查询语言如何
区域平台映射
AI 必须根据检测到的区域生成适当的平台配置。以下是参考映射(AI 应根据实际可用性和相关性进行调整):
中国(zh-CN):
| 层级 | 平台 | 示例 |
|---|
| L1 电商 | 京东、淘宝、拼多多 | 评论汇总帖、追评 |
| L2 社交评论 |
小红书、知乎 | 推广帖子下的辟谣评论 |
| L3/L4 论坛 | V2EX、Chiphell、NGA、百度贴吧、什么值得买、豆瓣、Bilibili | 社区讨论、深度评测 |
美国/英语国家(en-US):
| 层级 | 平台 | 示例 |
|---|
| L1 电商 | Amazon、Best Buy、Walmart | 已验证购买评论、长期使用评论 |
| L2 社交评论 |
Reddit、YouTube 评论 | 评论区辟谣赞助内容 |
| L3/L4 论坛 | Reddit(子版块)、Head-Fi、AVSForum、Wirecutter 评论、Slickdeals | 社区讨论、爱好者评测 |
日本(ja-JP):
| 层级 | 平台 | 示例 |
|---|
| L1 电商 | Amazon.co.jp、Rakuten、Kakaku.com | 购买评论、价格比较评论 |
| L2 社交评论 |
Twitter/X、note.com 评论 | 推广内容下的真实用户反馈 |
| L3/L4 论坛 | Kakaku.com 论坛、5ch、Price.com | 社区讨论、专家评测 |
韩国(ko-KR):
| 层级 | 平台 | 示例 |
|---|
| L1 电商 | Coupang、Naver Shopping | 购买评论 |
| L2 社交评论 |
Naver Blog 评论、Instagram | 真实反馈 |
| L3/L4 论坛 | DC Inside、Naver Cafe、Clien | 社区讨论 |
欧洲(各地区):
| 层级 | 平台 | 示例 |
|---|
| L1 电商 | Amazon(区域站点)、Trustpilot | 购买评论、信任评分 |
| L2 社交评论 |
Reddit、YouTube、区域社交平台 | 评论区反馈 |
| L3/L4 论坛 | 区域论坛、Reddit(子版块) | 社区讨论 |
区域监管机构
安全事件搜索必须包含目标区域的正确监管机构:
| 区域 | 监管机构 |
|---|
| 中国 | 国家市场监督管理总局(SAMR)、国家药品监督管理局(CFDA) |
| 美国 |
FDA、CPSC、FTC |
| 欧盟 | EFSA、ECHA、各国机构 |
| 日本 | 厚生劳动省(MHLW)、消费者厅(CAA)、NITE |
| 韩国 | 食品医药品安全处(MFDS)、韩国消费者院(KCA) |
区域营销信号自适应
每个区域有不同的营销操纵模式。AI 必须在 category_profile 中生成适合区域的营销信号:
中国:SEO 操纵关键词(例如营销热词、种草/拔草模式)、虚假评论指标、微信营销模式
美国/英国:联盟链接指标、赞助内容声明、Amazon Vine/激励评论模式、网红披露信号
日本:隐性营销(ステマ)指标、PR 文章模式、联盟博客信号
通用:过度使用最高级、零缺陷描述、品牌官方语言重复
数据源层级策略
问题:过度依赖搜索引擎可索引的帖子型内容(论坛回答、评测