设计混合搜索系统时，如何分阶段收集需求、生成架构并验证部署

在 Google Cloud 上设计结合语义向量搜索与结构化 SQL 过滤的混合搜索方案时，按需求发现、架构设计、验证、打包四阶段推进并逐段获得用户确认。

适用场景

解决思路

1. 阶段严格分离：在需求发现阶段只提问澄清，不要推荐、提议或勾勒任何架构设计、云服务或组件映射，避免在范围明确前过早承诺架构或产生幻觉。
2. 遇到要求“获得批准后再继续”的步骤时，必须停止执行，向用户展示已完成的任务，等待用户明确批准，不得在同一回复中继续执行后续任务或生成进一步指导。
3. 所有生成内容必须先查参考资料：先查 Product Mapping 和 Design Recommendations，若不足则用 Google Developer Knowledge MCP 服务器（https://developerknowledge.googleapis.com/mcp，工具 search_documents、get_documents、answer_query）、https://github.com/google/skills 的相关技能以及官方 Google Cloud 文档来支撑。
4. 生成方案设计、架构图和文档时，先查最新 Google Cloud 文档确认产品名称，注意旧名到新名的映射（如 Vertex AI→Gemini Enterprise Agent Platform、Vertex AI Embedding→Text embedding on Gemini Enterprise Agent Platform、Vertex AI Matching Engine→Vector Search），但底层 API、Terraform 资源和 IAM 角色可能仍保留旧标识符。
5. 需求发现第 1 步：让用户描述功能需求，包括目录数据集细节（如电商服装、零售商品、专利库）、搜索模态（自然语言文本、视觉搜索、属性过滤）、用于分面过滤的元数据属性（如 category、sub_category、color、gender、price）以及质量检查（重排序、LLM 验证）。
6. 需求发现第 2 步：必须明确要求用户描述全部六类非功能需求，不得省略：安全隐私合规（如私有 VPC 端点、Private Service Connect、Direct VPC Egress、访问控制）、可靠性（高可用、故障转移、灾难恢复 RTO/RPO、区域 vs 多区域 AlloyDB 拓扑）、成本（计算、数据库实例、Gemini Enterprise Agent Platform API 调用预算）、运维卓越（监控、日志、仪表盘、自动化部署）、性能（目标 P95 查询延迟如 <100ms、向量搜索召回目标如 >95%、目录规模、QPS 预期）、可持续性（碳足迹、低碳区域选择）。
7. 需求发现第 3 步：询问工作负载当前是否运行在其他云厂商或本地；若回答“是”，让用户描述当前部署架构；若“否”则进入下一步。
8. 需求发现第 4 步：让用户描述对其他工作负载、产品或工具的依赖（如现有库存数据库、ERP 系统、Java 或 Python 等应用运行时语言）。
9. 需求发现第 5 步：审查用户已提供的信息，检查功能需求、非功能需求和依赖之间是否存在歧义、冲突或矛盾，必须将所有需求相互比对。对每个歧义/冲突/矛盾：指出具体矛盾点并解释为何这些需求不兼容、无法同时满足（不要把根本性矛盾当作设计选择问题来问）；请用户澄清其取舍偏好；若用户委托你决定（如回复“你觉得怎么好就怎么做”或“你决定”），则给出明确建议、解释理由并请用户批准。在所有歧义和矛盾解决前，不得推荐或生成任何架构设计或 Google Cloud 产品建议。
10. 需求发现第 6 步：将用户提供的功能与非功能需求汇总成一份统一的需求摘要。
11. 需求发现第 7 步：向用户展示需求摘要并获得批准（用户必须明确说“是”或“我批准”）后才能进入阶段 2；在确认摘要并解决所有歧义矛盾前必须停止，不得生成架构图、架构描述或产品建议。
12. 架构任务 2.1 第 1 步：为工作负载的每个组件推荐合适的产品和功能，优先 Google Cloud 产品，且推荐必须与 Product Mapping 参考一致。
13. 架构任务 2.1 第 4 步：向用户展示产品推荐并获得批准（用户必须明确说“是”或“我批准”）后才能进入任务 2.2；在确认产品推荐前必须停止，不得生成架构图。
14. 架构任务 2.2 第 1 步：用 Mermaid 格式（https://github.com/mermaid-js/mermaid）生成架构图，展示各组件间的数据流和请求流，必须同时显式展示摄取管道和服务管道。示例：摄取管道为 Catalog Data→AlloyDB 表（apparels）→分面 B-Tree 索引→文本嵌入（text-embedding-005）→ScaNN 向量索引；服务管道为 User Browser→Cloud Run Web App→MCP Toolbox for Databases→AlloyDB 单查询混合搜索（ScaNN 向量搜索 + SQL WHERE 过滤）→ai.rank 重排序器→Gemini Pro ai.generate 质量验证→验证结果→User Browser。
15. 架构任务 2.2 第 2 步：生成描述，解释每个组件的用途、组件间关系以及任务流或数据流。
16. 架构任务 2.2 第 3 步：向用户展示架构图和描述并获得批准（用户必须明确说“是”或“我批准”）后才能进入任务 2.3；在确认架构描述前必须停止，不得生成设计建议。
17. 架构任务 2.3 第 1 步：基于工作负载需求生成设计建议和最佳实践，以最优配置架构中的每个组件；需考虑阶段 1 收集的功能与非功能需求，与 Design Recommendations 参考对齐；针对非功能需求使用技能 google-cloud-waf-security、google-cloud-waf-reliability、google-cloud-waf-cost-optimization、google-cloud-waf-operational-excellence、google-cloud-waf-performance-optimization、google-cloud-waf-sustainability。
18. 架构任务 2.3 第 2 步：向用户展示设计建议并获得批准（用户必须明确说“是”或“我批准”）后才能进入任务 2.4；在确认设计建议前必须停止，不得生成部署指导。
19. 架构任务 2.4 第 1 步：生成部署指导，包括：AlloyDB DDL 与 SQL 安装脚本（扩展 google_ml_integration、alloydb_scan，表、B-Tree 索引、ScaNN 向量索引、混合搜索 SQL、Gemini 验证 CTE）；Cloud Run 上的 MCP Toolbox 部署配置；Python Cloud Run Function shim 部署命令；应用部署命令（gcloud run deploy {app_name}）；创建所需基础设施的 Terraform 代码或 gcloud CLI 命令。部署指导必须与 Related Guidance 参考及 https://github.com/google/skills/tree/main/skills/cloud 中的相关技能一致。
20. 架构任务 2.4 第 2 步：向用户展示部署指导并获得批准（用户必须明确说“是”或“我批准”）后才能进入阶段 3；在确认部署指导前必须停止，不得生成方案验证内容。
21. 验证任务 3.1 第 1 步：制定预部署计划，在不实际开通资源的情况下静态验证方案是否满足需求：用 dry-run 命令（如 terraform plan 或受支持时的 gcloud ... --dry-run）验证基础设施语法并预览将开通的资源；对网络路由拓扑、防火墙规则和 IAM 执行静态核查，对照最佳实践。
22. 验证任务 3.1 第 2 步：向用户展示静态验证计划，获得批准（用户必须明确说“是”或“我批准”）后执行 dry-run 命令。
23. 验证任务 3.1 第 3 步：排查并修复 dry-run 检查中发现的错误或策略偏差，直到验证通过。
24. 验证任务 3.2 第 1 步：询问用户是选择现在部署基础设施以进行实时运行时验证，还是直接跳到阶段 4。
25. 验证任务 3.2 第 2 步：若用户选择部署基础设施，在用户部署后生成运行时验证命令（使用 curl、ping 或 gcloud 等工具）交给用户执行，以测试实时端点可达性、网络路径和负载均衡路由；排查部署或运行时路由问题直到检查通过。
26. 打包阶段第 1 步：将阶段 2 生成的最终文本产物按 Output Template 模板整合为单个 Markdown 文件 solution-architecture-guide.md。
27. 打包阶段第 2 步：请求用户允许在其工作区写入代码文件。
28. 打包阶段第 3 步：用户允许后，将最终代码文件写入用户工作区。

适用边界 · 注意事项

• 不要用于仅需简单关键词搜索的场景。
• 不要用于需要独立非关系型向量数据库的场景。