企业官网建设流程全解析

• AI 技能
• 人工智能
• AI 评测
• 开发工具

搜索自动补全（Autocomplete）看似简单——用户每敲一个字符就返回建议——但真实工程中，它横跨排名算法、多语言拼写容错、个性化隐私、滥用防御和亚百毫秒延迟预算等多个复杂战场。本指南基于 guide/scenario/search-autocomplete.md，演示如何使用 autoresearch 的/autoresearch:scenario场景探索引擎，对搜索自动补全系统进行 12 个维度的系统性故障模式挖掘；读完你将领会如何构造场景命令、如何解读生成的 Situations（含前置条件、预期结果、失败信号与缓解措施），以及如何沿scenario → debug → security → fix链条把发现转化为实际修复。

一、场景命令：一次 25 轮迭代的完整配置

原指南给出的种子命令如下，可直接复制到你的 Claude Code 会话中运行：

/autoresearch:scenario --domain software --depth standard --focus edge-cases Scenario: User types a search query and receives real-time autocomplete suggestions — with typo correction, personalization, trending results, and abuse-resistant ranking Iterations: 25

逐项拆解该命令的语义（对照 guide/autoresearch-scenario.md 中的全量参数表）：

从命令实现看（见 claude-plugin/commands/autoresearch/scenario.md），Iterations: 25属于**有界（bounded）**运行，引擎会在current_iteration >= max_iterations时退出循环；只有显式声明Iterations: unlimited才会无界运行。安全上，/autoresearch:scenario是纯探索、不做代码修改，符合 SKILL 中"所有结果仅记录、不自动发布"的安全不变量（见 claude-plugin/skills/autoresearch/SKILL.md）。

输出目录约定：运行会创建autoresearch/scenario-{YYMMDD}-{HHMM}/目录，内含scenarios.md（按维度组织、维度内按严重度排序）、edge-cases.md（全量扁平严重度列表）与scenario-results.tsv（机器可读迭代日志，表头为iteration\ttimestamp\tscenario\tdimension\tclassification\tseverity\tdescription）。

二、为什么要探索搜索自动补全：隐藏在表面之下的复杂度

原指南的开场判断值得全文引用："搜索自动补全看似简单——边输入边显示建议；但表面之下：排名必须在相关性、流行度与个性化之间取得平衡；拼写容错必须处理多种语言；建议必须在 100ms 内更新；系统还必须抵御试图注入建议的对抗性操纵。"

这决定了场景探索需要覆盖的关键维度权重：

• 边界条件（Edge case）——空查询、单字符、纯 emoji、超长查询、特殊字符
• 规模（Scale）——10,000 次查询/秒、建议索引更新延迟、冷缓存表现
• 数据多样性（Data variation）——多语言查询、混合文字输入、RTL（右向左）语言、CJK（中日韩）字符
• 滥用（Abuse）——建议轰炸（suggestion bombing）、SEO 操纵、攻击性建议注入
• 时间性（Temporal）——趋势查询突发峰值、季节性建议、陈旧热门建议

这些维度正是/autoresearch:scenario的 12 个探索维度中与本主题强相关的子集。完整的 12 维度清单如下（摘自 guide/autoresearch-scenario.md）：

探索引擎的工作方式为"种子分析 → 分解为 12 维度 → 每轮生成一个 Situation → 分类（维度+严重度）→ 补充上下文 → 记录 → 重复"（Seed analysis → Decompose into 12 dimensions → Generate ONE situation per iteration → Classify → Expand with context → Log → Repeat）。关键机制有二：

1. 维度均衡覆盖：每一轮会优先挑选"探索最少的维度"，避免所有结果扎堆在某一个维度上；
2. 饱和检测（Saturation detection）：当连续 3 轮在已覆盖维度内只产出低严重度变体时，Claude 会报告饱和并提出提前终止或转移焦点（见 guide/autoresearch-scenario.md 的 How It Works 一节）。

对分类结果，引擎使用new（真正新颖的边界情况）/extension（基于既有发现的扩展）/duplicate（已覆盖，跳过不记录）三类标签，严重度取值critical / high / medium / low——这些语义直接体现在 claude-plugin/commands/autoresearch/scenario.md 的 Iteration Loop 四阶段（Review → Generate → Classify → Log）中。

三、六种已生成 Situation 的完整解读

下面完整呈现原指南针对上述种子场景生成的六个 Situation。每个 Situation 都是"前置条件 → 场景描述 → 预期结果 → 失败信号 → 缓解措施"的标准化结构，这也是/autoresearch:scenario输出块的标准格式（对照 guide/autoresearch-scenario.md 的 Example Output Block）。

Situation #1 —— 首字符拼写错误击穿前缀匹配

• 维度：边界条件 |严重度：High
• 前置条件：用户想搜索 "restaurant"；自动补全基于前缀（trie）匹配
• 场景：用户输入 "restaruant"（'r' 与 'u' 交换的拼写错误）。前缀匹配失败，因为 "restar..." 无法命中任何建议前缀。尽管 "restaurant" 是排名第 1 的查询，用户却看到零建议。
• 预期结果：输入 3+ 字符且无精确前缀匹配时触发模糊匹配。建议显示："restaurant"（你是想找？）、"restaurant near me"、"restaurant reservations"。编辑距离 ≤ 2 纳入考虑。
• 失败信号：常见查询显示空建议下拉框；用户手动纠错或放弃搜索；自动补全对易拼错查询提供零价值。
• 缓解措施：
  • 混合匹配：先前缀匹配，回退到编辑距离匹配（Levenshtein ≤ 2）
  • 语音匹配（Soundex/Metaphone）：针对"发音正确但拼写错误"的查询
  • 在前缀 trie 之外建立 n-gram 索引以支持子串匹配

Situation #2 —— 趋势查询注入的攻击性建议

• 维度：滥用 |严重度：Critical
• 前置条件：自动补全建议部分来源于趋势搜索量；一个协调组织在 1 小时内提交了 50,000 次针对某攻击性短语的搜索
• 场景：该攻击性短语进入"趋势"建议池。用户输入某个常见词的前 3 个字符，就看到攻击性短语成为顶部自动补全建议。截图在社交媒体上病毒式传播。
• 预期结果：趋势建议在进入建议索引前经过黑名单过滤。突发的量异常触发异常检测："查询 'xyz' 在 1 小时内量暴增 10,000% —— 暂扣审查。"
• 失败信号：攻击性建议在人工审查介入前展示给数百万用户；公关危机；应用商店审查投诉。
• 缓解措施：
  • 所有建议在展示前过黑名单过滤器（脏话、仇恨言论、侮辱性词汇）
  • 对建议量做异常检测：突发峰值必须人工批准后才能上浮
  • 新出现的建议有 12 小时隔离期（quarantine period），之后才能出现在自动补全中
  • "编辑推荐"与"自然"建议双轨分离，赋予不同信任等级

Situation #3 —— 使用 IME 组字输入 CJK（中日韩）字符

• 维度：数据多样性 |严重度：Medium
• 前置条件：用户使用 IME（输入法编辑器）输入日语；IME 有组字状态，字符在被提交前处于下划线/高亮状态
• 场景：自动补全在每次按键时触发。IME 组字期间，输入框中是未完成的假名，提交后将变成汉字。自动补全搜索这些未完成假名，返回无关建议。用户提交汉字后，自动补全以正确查询再次触发。
• 预期结果：自动补全检测到 IME 组字状态并抑制建议，直到组字提交完成。建议只在compositionend事件触发，而不是在中间的input事件触发。
• 失败信号：IME 组字期间建议下拉框快速闪烁，显示无关结果；下拉框可能遮挡 IME 候选列表，导致选字困难。
• 缓解措施：
  • 监听compositionstart/compositionend事件——组字期间抑制自动补全
  • 对 CJK locale 使用更长防抖延迟（300ms）
  • 若检测到组字中，显示轻微的"正在输入…"指示器代替建议

Situation #4 —— 个性化建议泄露私有搜索历史

• 维度：权限 |严重度：Critical
• 前置条件：自动补全基于用户搜索历史做个性化；用户在共享/公共电脑（图书馆、自助终端）上搜索
• 场景：下一个用户开始输入 "h"，看到上一个用户的个性化建议："how to file for divorce"、"hepatitis symptoms"、"help for depression"。私有搜索历史被暴露。
• 预期结果：个性化建议仅绑定已验证会话。共享/公共电脑被识别（无持久认证、隐身模式），只收到通用热门建议。会话清理清除个性化数据。
• 失败信号：敏感搜索历史对下一个用户可见；隐私侵犯；潜在法律责任。
• 缓解措施：
  • 个性化要求已验证会话——匿名会话只获得通用建议
  • 自动补全下拉框中醒目提供"清除最近搜索"
  • 会话超时（15 分钟不活动）清除个性化缓存
  • 隐身/私密浏览模式：零个性化、零历史

Situation #5 —— 目录更新后建议索引陈旧

• 维度：时间性 |严重度：Medium
• 前置条件：电商站点有 500,000 个商品；隔夜（目录导入）新增 5,000 个商品；自动补全建议索引每晚重建
• 场景：营销团队上午 9:00 发送邮件推广新产品线。客户点开邮件并搜索新产品。自动补全返回零建议，因为索引尚未重建（计划在次日凌晨 2:00）。
• 预期结果：建议索引支持增量更新。新产品在目录导入后 15 分钟内完成索引。或者：建议索引无匹配时，对商品数据库做实时回退查询。
• 失败信号：搜索推广产品的客户看不到建议；转化率下降；客服工单："我找不到邮件里的产品。"
• 缓解措施：
  • 增量建议索引更新（由目录变更触发，而非仅夜间重建）
  • 实时回退：trie 返回零结果时，直接用 LIKE/trigram 匹配查询商品数据库
  • 营销活动上线前预热建议索引

Situation #6 —— 查询a]击垮基于正则的建议过滤器

• 维度：边界条件 |严重度：Medium
• 前置条件：建议匹配使用由用户输入构造的正则；输入净化不完整
• 场景：用户输入a]（或a[、a(、a*）。正则引擎抛出"unterminated character class"（未终止字符类）异常。自动补全端点返回 500。客户端静默失败——之后每次按键都不再显示建议，直到页面刷新。
• 预期结果：构造正则前转义用户输入。a]按字面匹配。无服务器错误。以 "a" 开头的查询建议正常返回。
• 失败信号：记录 500 错误；自动补全在用户整个会话中静默失效；若错误率足够高，监控告警触发。
• 缓解措施：
  • 构造模式前转义用户输入中的所有正则特殊字符
  • 自动补全使用字面字符串匹配（trie/前缀）而非正则
  • 客户端：自动补全端点返回 5xx 时重试一次，然后优雅降级（隐藏下拉框，不阻塞搜索）

四、链式编排：把场景发现转化为修复

/autoresearch:scenario的产物是待验证的故障假设，真正价值在后续链条中兑现。原指南给出了三条已配置的链条，每一条都通过handoff.json协议无复制粘贴地传递上下文（协议结构见 guide/chains-and-combinations.md：source_command、timestamp、scope、goal、findings、hypothesis_queue、summary）。

scenario → debug：追踪边界故障

/autoresearch:debug Scope: src/search/**, src/autocomplete/**, src/suggestions/** Symptom: Edge cases — regex crash, CJK IME handling, stale index, typo tolerance gaps Iterations: 15

/autoresearch:debug是"科学方法 × autoresearch 循环"的缺陷猎人：每轮形成一条可证伪假设、运行一个实验，把已确认与已证伪的结果都记录到debug-results.tsv，然后跟进下一条线索（见 guide/autoresearch-debug.md）。Situation #6 的正则崩溃、Situation #3 的 CJK/IME 处理、Situation #5 的陈旧索引、Situation #1 的容错缺口，恰好对应 debug 的六种调查技术（二分搜索、差分调试、最小复现、执行跟踪、模式搜索、逆向推导）中各有用武之地。

scenario → security：审计注入、操纵与隐私泄露

# Audit for injection, suggestion manipulation, and privacy leaks /autoresearch:security Scope: src/search/**, src/autocomplete/** Focus: Regex injection, suggestion bombing, personalization privacy, XSS in suggestion display Iterations: 10

这条链直接对应 Situation #2（建议轰炸/操纵）、Situation #4（个性化隐私泄露）与 Situation #6（正则注入）的严重威胁。/autoresearch:security使用 STRIDE 威胁建模 + OWASP Top 10 + 4 个红队对抗人格，且要求每条发现都附代码证据（file:line + 攻击场景），不做理论性漏洞假设（见 guide/autoresearch-security.md）。与自动补全相关的典型映射包括：S（Spoofing）— 建议伪造；T（Tampering）— 建议注入篡改；I（Info Disclosure）— 个性化历史泄露；D（DoS）— 正则 ReDoS 与无界建议请求。

predict → scenario：专家预判播种场景

/autoresearch:predict --chain scenario,debug,fix Scope: src/search/** Goal: Harden autocomplete against edge cases and adversarial manipulation

--chain scenario,debug,fix是逗号分隔的顺序执行语法：predict 先由 5 个专家人格对src/search/**做风险分析并产出排名发现与假设队列，scenario 以此为种子继续枚举边界情况，debug 沿风险区域狩猎缺陷，fix 做根因优先的级联感知修复。整条管线符合 guide/chains-and-combinations.md 中"predict → scenario,debug,fix,ship"全质量管线的降级版——每一阶段的输出都会锐化下一阶段的输入。

handoff.json由每个支持--chain的命令在调用下一目标前写入；以 scenario 为源时，其结构为version "2.1.0"、source "scenario"、timestamp、status、results_tsv路径、findings（按严重度组织的场景列表）与config{scenario, domain, scope}（见 claude-plugin/commands/autoresearch/scenario.md 的 Chain Handoff 一节）。

五、领域专属 Tips：自动补全场景探索的三个关键认知

性能即功能（Performance IS the feature）

自动补全必须 100ms 内响应。任何增加延迟的场景要素（模糊匹配、个性化查询、实时回退）都必须对照延迟预算评估。场景探索之后应加跑一轮以指标为导向的优化循环：

/autoresearch Goal: reduce p95 autocomplete latency Metric: p95 autocomplete latency in ms (lower is better) Verify: npm run bench:autocomplete | grep "p95"

这也正是 SKILL 中"经典模式（Classic）"的用法：在Metric:/Verify:存在时进入 modify → verify → keep/discard 循环（见 claude-plugin/skills/autoresearch/SKILL.md）。

用真实拼写错误模式测试，而非随机突变

常见拼写错误遵循键盘相邻布局规律（例如 'e' 与 'r' 相邻）。随机字符交换无法代表真实用户行为，应使用真实拼写错误数据集或键盘距离模型来评估模糊匹配。这与 Situation #1 直接相关——真实键盘错位模式决定了编辑距离阈值与候选排序策略的有效性。

多语言自动补全是一个独立问题

CJK、阿拉伯语（RTL）与拉丁文字具有根本不同的输入方式。对多语言场景应单独运行一次聚焦数据多样性的场景：

/autoresearch:scenario --depth standard --focus>
更多场景实战：guide/scenario/README.md（含实时聊天、多租户 SaaS、CI/CD 部署、医疗预约、内容审核、IoT 固件更新等 11 个领域指南） |场景命令参考：guide/autoresearch-scenario.md |链条组合：guide/chains-and-combinations.md