Claude 研发与 Dot 测试：知识库 MCP 实测新模式
当前正在进行知识库 MCP 的实测，采用“Claude 负责研发、Dot 负责测试”的协作模式。Claude 熟悉代码架构与系统搭建，适合主导功能开发及解决研发难题；Dot 则模拟新学员视角，依据任务书验证产品说明的可操作性。
开发者常因熟悉环境而忽略用户痛点，如预装软件、历史配置等隐形知识。对于刚付费的学员而言，面对的是一台全新电脑和基础文档。引入 AI 进行全流程盲测，旨在发现研发自检中遗漏的使用障碍，核心目标是验证非技术背景用户能否仅凭网页指引和接入信息独立完成部署。
图 1 学员实际看到的知识库接入页（网页截图于 2026 年 11 月 13 日）
实测流程：从环境检查到工具链验证
本次测试任务书设定 Dot 为刚付费的 L2 学员，在云电脑环境中执行以下操作：
- 环境预检：记录系统环境，确认 Node.js、Git、uv、Python 等依赖是否预装。
- 知识库接入：严格遵循网页说明，将知识库接入 Codex。
- 功能验证：提问“日本站雨天产品差异化思路”，检查是否成功调用知识库并引用条目编号。
- 工具链测试：咨询自动化上架方案，根据推荐依次安装 OpsKit、ListingKit、SelectKit、AdsKit，执行体检及离线演示，最后检查更新状态。
通过上述步骤，对知识库接入、回答质量、工具推荐及安装流程进行全方位检查，最终以实测记录作为验收依据。
图 2 接入页列出的四个套件及安装流程
测试规范：保留“卡点”而非自行修复
任务书强调一项关键原则：遇到问题优先依据文档解决；若文档无法解决，需详细记录问题并尝试其他方法，同时明确标注该步骤超出了说明范围。
AI 具备较强的自主解决问题能力，如自动补全依赖或修改配置。这在研发阶段是优势，但在用户体验测试中，若 AI 悄然解决所有障碍仅反馈“安装成功”，将掩盖普通用户的真实痛点。因此，测试报告必须保留完整证据链，包括版本号、环境信息、操作步骤、预期与实际结果的差异、报错原文及必要截图。即使绕过问题，也需如实记录原始卡点。
闭环迭代：研发与测试的协同机制
Claude 基于 Dot 提供的详细记录，判断是需要修改代码还是补充文档。修复完成后，由 Dot 在相同条件下复测，研发侧同步进行独立检查，共同验证对外交付的可用性。
图 3 研发与测试配合方式示意图
此外，测试设有明确边界。当涉及亚马逊 SP-API、Google Ads、Anthropic API Key 或 1688 登录等需要外部授权的场景时，仅记录所需条件并暂停，本轮重点在于验证接入与安装体验，真实业务操作留待后续专项测试。
这种分工模式值得持续推广：Claude 保障研发的连续性，Dot 坚守用户视角。最终关注的核心指标是：学员在何处受阻，以及如何优化说明文档以支持其独立完成下一步操作。
案例依据：本次聊天记录及《知识库 MCP 实测任务书 Momoko》；配图来源：跨境杨少知识库公开接入页。