对话者的引导路径
实操验证 → 发现问题 → 追问本质 → 引入参照 → 评估方案 → 落地实现
关键引导动作
1. 用实测结果推翻理论
"使用测试 A：删除水印元素，没有恢复"
没有接受我给出的测试步骤就完事，而是动手验证，用事实说话。这直接暴露了我遗漏的问题——删的是根元素而非子元素。
2. 反问真实场景，拉回现实
"在实际生产中，会找到 watermark 本身吗？"
这一问把讨论从"技术上能不能"拉到"用户会不会这样做"。答案显然是会——类名太明显了。迫使我承认这不是边缘 case，而是真实漏洞。
3. 引入外部参照物，避免闭门造车
"阅读 pub-sdk 的水印实现，它做到了哪种程度？值得迁移吗？"
不是让我凭空设计方案，而是先看同类实现怎么做的。这让对比分析有了锚点，结论更客观——借鉴架构思路，不照搬整体实现。
4. 在动手前追问方案质量
"思考，这是一个好的方案吗？还会有机会绕过吗？"
在我提出"监听父节点"方案后，没有直接说"加上"，而是先让我评估方案的边界。这一步避免了盲目实现一个看似解决但实际仍有盲区的方案。
5. 确认方向后才下指令
"加上"
只在充分讨论完局限性（CSS 注入、暂停 JS 等仍无法防）之后，明确知道"这不是银弹但值得做"的前提下，才给出执行指令。
值得复用的引导模式
| 模式 | 做法 | 效果 |
|---|---|---|
| 实测驱动 | 先动手试，用结果质疑结论 | 避免 AI 的理论正确但实际错误 |
| 场景追问 | "实际生产中会这样吗？" | 把 AI 从理想假设拉回现实约束 |
| 引入参照 | "看看别人怎么做的" | 让 AI 有对比基准，避免从零推导 |
| 方案质疑 | "还能绕过吗？" | 逼 AI 诚实暴露方案局限性 |
| 分步决策 | 先评估再执行，不急着写代码 | 确保方向正确后再投入实现成本 |
一句话总结：不轻信 AI 的第一个答案，用事实验证、用场景追问、用参照对比，确认方向后再动手。
