测试方案生成器

要解决什么问题

黑盒测试里，PRD 与 map-spec 设计文档往往用业务语言描述「版本切换」「分歧点优化」等能力，但真正可执行的是：请求里怎么构造流量、响应里哪些字段必须可判定。若方案里虚构协议字段，或预期写成「正常」「有效」「解析成功」，下游 search-data 筛数、diff 对比和功能 Case 都会建立在错误前提上。Test Plan Writer 只做一件事：在不执行测试的前提下，把设计文档收敛成标准化 test_plan.md，供后续 Phase 调度使用。

技能如何工作

输入以 feature、designDoc（.claude/workflow/.../design.md）为主；sourceFiles 可选，用于辅助读变更文件、提取 LOG 与 Apollo 相关关键字，缺失时降级为警告而非一律中断。

生成前门禁分两类：字段存在性（在 src/navi-guide/src/proto/thrift 与 protobuf 中检索并建来源表）与预期量化（具体数值/字段名/识别规则）为阻塞项；代码 diff 分析为警告项，未确认项须显性标注 [待确认: 需开发确认]。

主流程包括：从 designDoc 提取 trigger、预期行为与涉及字段；按协议区分请求字段（trigger）与响应字段（expected / affected）；设计场景（含灰度三态、边界维度）；为 diff 场景写仅含请求字段的 data_filter_conditions；评估 risk_level 与 required_phases、Diff/功能 Case/回归策略；输出含 test_scenarios、experiment_config、diff_config（含对照组 UNCHANGED）的完整方案，并做字段命名校验（与 proto 区分大小写一致）。

适用边界

• 职责：方案设计层，不跑 Jenkins、不替下游执行 diff。
• 字段：禁止用 C++ 内部变量或未序列化状态作为测试依据；无法映射到协议的概念须在说明中写清替代验证方式。
• 真相源：LLM-Wiki 等检索可辅助历史策略，字段是否存在必须以项目 proto 目录搜索结果为准。