tech-solution-research（技术解决方案研究）

定位与边界

技术方案调研 vs 市场调研

本技能不做：市场规模估算、竞品商业分析、用户调研、定价策略、SaaS 产品商业对比（非技术维度）

触发条件

✅ 使用本技能当：

• "调研 X 技术方案" / "对比 X 和 Y" / "做技术选型"
• "X 框架怎么样？" / "X 和 Y 哪个更适合 Z 场景？"
• "输出 X 技术的实施建议" / "评估 X 技术的风险"
• "我们该用 X 还是 Y？" / "X 技术的优缺点是什么？"
• "调研浏览器自动化方案" / "对比几个 ORM 框架" / "评估 X 库的可行性"

典型场景示例：

• 浏览器自动化方案调研（Playwright / Stagehand / agent-browser / BrowserUse / WebMCP）
• 后端框架选型（Express / Fastify / Hono / Bun）
• 数据库方案对比（PostgreSQL / MongoDB / Redis / SQLite）
• 状态管理库评估（Zustand / Jotai / Redux / Valtio）
• SaaS 服务技术评估（如"Supabase vs 自建后端"的技术可行性）

❌ 不使用本技能（应转介其他技能）：

• 市场规模估算 → 使用 market-research 技能
• 竞品商业分析 → 使用 market-research 技能
• 纯产品选型（非技术维度） → 如"选哪个 CRM 系统"（业务功能优先）
• 用户调研/需求验证 → 需要人工访谈
• 纯业务决策（定价、市场进入） → 需要业务输入
• 紧急故障排查 → 使用调试/排障技能
• 单纯查文档/API 用法 → 直接 web_search / web_fetch 即可

边界模糊处理：如用户问题同时包含技术和商业维度，先完成技术调研部分，明确说明"商业维度建议用 market-research 技能补充"。

核心设计：Multi-Source Evidence Orchestration

本技能不是 simple web search aggregation，而是多源证据编排与仲裁。

7 个 Source Lanes

证据优先级与冲突仲裁

证据可信度（从高到低，默认）：
1. runtime-test（自己实测）
2. official-docs（官方文档）
3. platform-native（平台一手数据）
4. github（真实代码/问题追踪）
5. community-discourse（开发者经验，需交叉验证）
6. internal-assets（可能有偏见或过时）

冲突仲裁规则：
- 实测 vs 官方声称不一致 → 以实测为准，标注"官方声称 X，实测 Y"
- 平台一手数据 vs 二手社区总结冲突 → 以平台一手数据为准，标注二手解释可能失真
- 多个 community-discourse 来源一致 vs 单一相反意见 → 采纳多数，标注少数观点
- 官方文档版本 vs GitHub 最新 release 不一致 → 以 GitHub release 为准，标注文档可能过时
- 缺失实测数据 → 必须标注"待补核"，不得将二手信息当作实测
- 无法仲裁的冲突 → 并列呈现双方证据，标注"存在争议，建议实测验证"

标准工作流

1. 范围界定 → 2. 候选生成 → 3. 多源采证 → 4. 实测 → 5. 评分 → 6. 结论

1. 范围界定（Scoping）

• 明确业务场景、约束条件、成功标准
• 确定评估范围（必须有的功能、可选功能、排除条件）
• 输出：调研范围文档

2. 候选生成（Candidate Generation）

• 从各 source lanes 收集候选方案
• 初步筛选（排除明显不满足约束的）
• 输出：候选方案清单（3-5 个为宜）
• 候选锁定：清单确定后不得随意扩展，如确需增加需记录理由

3. 多源采证（Evidence Collection）

• 并行从 7 个 lanes 整理证据
• 统一证据 schema（见 references/evidence-schema.md）
• 输出：证据矩阵

强制 source routing（必须遵守）：

• 涉及 X/Twitter → 必须优先使用 feedgrab，趋势补充用 last30days / x-hot-topics-daily，必要时再用 agent-browser 页面验证
• 涉及 小红书 → 必须优先使用 xiaohongshu skill，补充用 feedgrab
• 涉及 GitHub → 必须优先使用 GitHub/gh CLI 数据，再补社区口碑
• 涉及 ClawHub → 必须优先使用 registry / 已安装技能 / skill metadata
• 涉及 Moltbook → 必须优先使用 moltbook-global 作为平台/内部内容资产入口
• 降级记录要求：如上述平台原生工具不可用，必须明确记录"降级原因 + 降级到的替代方案"，不得伪装成一手数据

证据新鲜度要求：

• GitHub 数据（star、issues、commits）：整理时间 ≤30 天
• 社区讨论/帖子：优先 ≤6 个月内容，超过 1 年需标注"可能过时"
• 官方文档：记录文档版本/最后更新时间

4. 实测（Runtime Validation）

• 对 top 2-3 候选进行关键功能/性能实测
• 记录测试环境、步骤、结果
• 输出：实测报告（如无法实测，必须明确标注"待补核"及原因）

5. 评分（Scoring）

• 使用 7 维评分体系（见下文）
• 加权计算（权重根据场景调整）
• 输出：评分表
• 权重调整记录：如偏离默认权重，需说明理由

6. 结论（Conclusion）

• 推荐方案 + 备选方案
• 风险清单 + 缓解措施
• 实施路径（分阶段）
• 输出：最终报告（见 references/report-template.md）

7 维评分体系

评分方法：每个维度 1-5 分，可根据场景设置权重。详细评分标准见 references/scoring-rubric.md。

参考权重（根据场景选择）：

• 内部工具（效率优先）：功能 20% / 性能 10% / 开发体验 25% / 成本 15% / 集成 15% / 安全 5% / 维护 10%
• 对外产品（质量优先）：功能 25% / 性能 20% / 开发体验 10% / 成本 10% / 集成 10% / 安全 15% / 维护 10%
• 创业 MVP（速度优先）：功能 30% / 性能 10% / 开发体验 20% / 成本 20% / 集成 10% / 安全 5% / 维护 5%
• 企业核心系统（稳定优先）：功能 15% / 性能 15% / 开发体验 10% / 成本 10% / 集成 15% / 安全 20% / 维护 15%

输出要求

核心章节（8 部分，缺一不可）

1. 候选方案清单：3-5 个候选，简述各自特点
2. 证据矩阵：各方案在各 source lane 的证据摘要
3. 7 维度对比表：结构化评分
4. 推荐方案：明确推荐 + 理由
5. 备选方案：次优选择 + 适用场景
6. 风险清单：已知风险 + 缓解措施
7. 实施路径：分阶段实施建议（PoC → 试点 → 推广）
8. 引用/证据清单：所有引用来源的完整列表

强制检查清单（发布前必须完成）

Source Coverage Checklist（必须全部满足）：

• [ ] 每个候选方案至少 5 条证据
• [ ] 证据覆盖至少 4 个 source lanes
• [ ] platform-native lane 已尝试（如不可用需记录降级原因）
• [ ] GitHub 数据已整理（star/issues/commits）
• [ ] 实测状态已明确（已完成 或 标注"待补核"及原因）
• [ ] 无单一来源结论（关键结论需≥2 个独立来源支持）

报告质量 Checklist：

• [ ] 8 个核心章节完整
• [ ] 7 维度评分有证据支持（每个评分附证据 ID）
• [ ] 推荐方案理由清晰（≤3 条核心理由）
• [ ] 风险清单具体可操作（至少 3 条风险）
• [ ] 实施路径有明确里程碑和成功标准
• [ ] 所有引用来源可追溯（有 URL 或路径）
• [ ] 证据新鲜度符合要求（GitHub≤30 天，社区≤6 个月优先）

报告模板：见 references/report-template.md（必须使用该模板）

Guardrails（红线）

必须遵守（违反=报告不合格）

• ❌ 禁止单一来源：不得仅基于单一来源（尤其是营销文案）下结论
• ❌ 禁止抄袭营销文案：官方营销内容必须经第三方或实测验证
• ❌ 禁止缺失实测不标注：如无实测数据，必须明确标注"待补核"及原因
• ❌ 禁止伪装 platform-native：如无法使用平台原生工具，必须记录降级原因
• ✅ 必须多源交叉验证：关键结论需至少 2 个独立来源支持
• ✅ 必须标注证据等级：每个结论需标注证据来源和可信度
• ✅ 必须说明适用场景：推荐方案需明确"在 X 场景下推荐，因为 Y"
• ✅ 必须完成 coverage checklist：发布前逐项勾选确认

常见陷阱

适用与不适用场景

✅ 适用场景

• 技术选型决策（框架、库、工具、服务）
• 架构方案对比（单体 vs 微服务、同步 vs 异步）
• 新技术评估（是否引入团队）
• 技术债务分析（是否重构/替换）
• 供应商技术评估（SaaS、API 服务的技术可行性）

❌ 不适用场景

• 市场规模估算 → 使用 market-research 技能
• 竞品商业分析 → 使用 market-research 技能
• 用户调研/需求验证 → 需要人工访谈
• 纯业务决策（定价、市场进入） → 需要业务输入
• 紧急故障排查 → 使用调试/排障技能
• 单纯查文档/API 用法 → 直接 web_search / web_fetch

与 ClawHub 技能的关系

本技能是编排型技能，不是某个单技能的薄包装。

可能调用的工具/技能（根据场景选择，非硬依赖）：

• web_search / web_fetch / multi-search-engine：通用搜索
• agent-browser / playwright-mcp：浏览器自动化实测
• github（gh CLI）：GitHub 数据整理
• feedgrab / xiaohongshu / x-hot-topics-daily / moltbook-global：平台原生数据
• 其他 ClawHub 技能：如已集成相关工具

原则：source-first / tool-first 兼容，不硬依赖某个具体技能名。如某工具不可用，降级到其他来源并记录原因。

快速开始

# 触发示例（自然语言）
"调研浏览器自动化方案，对比 Playwright、Stagehand、agent-browser"
"我们该用 Express 还是 Fastify？需要性能对比"
"评估一下用 Supabase 替代自建后端的可行性"

预期输出：

• 10 分钟内：初步候选清单 + 证据矩阵
• 30 分钟内：完整报告（含评分和推荐）
• 如需实测：标注实测计划 + 初步结论（实测后更新）

References

详细模板和标准见：

• references/evidence-schema.md：统一证据 schema
• references/report-template.md：报告模板（必须使用）
• references/workflow.md：详细工作流
• references/scoring-rubric.md：评分标准

版本历史

• 0.3.0（2026-03-30）：结构性改进 — 新增强制性 source coverage gate、重构 platform-native lane 为"必须优先"、明确触发边界排除项、增加证据新鲜度要求、统一清理重复内容
• 0.2.0（2026-03-29）：方向性优化 — 完善 7 源编排框架、冲突仲裁规则、评分体系
• 0.1.0（2026-03-29）：初版 — 核心框架 + 工作流 + 评分体系