夜雨聆风
最近在用 xwave 配合 AI Agent 做 RTL 调试。跑完几个测试用例之后，我没有像往常一样只让 AI 输出 debug 结论，而是多问了一步：让它把使用 xwave 过程中遇到的不顺手的地方也总结一下。
于是有了一份详细的工具使用反馈。这份反馈让我看到了很多自己平时注意不到的粗糙边角——有些是设计时没意识到的摩擦，有些是知道但没觉得多严重的细节，在 AI 的连续高强度调用之下全暴露出来了。
这篇文章记录一下这份反馈说了什么，以及我从中学到了什么。
AI 反馈了什么
AI 的反馈按模块分类，每条都附了具体场景和复现方式。
Event 表达式语法。&& 两侧有空格时会报语法错误，必须写成 a&&b 才能通过。AI 在反馈里写道，它尝试了引号转义、括号隔离、反斜线等多种方式均失败，最后偶然发现去掉空格才解决。它还指出文档中的示例 (vld || rdy) && !bp 带有空格，与实际解析行为不一致。建议要么修复 parser 支持空格，要么让错误信息提示正确格式。
信号路径发现。FSDB 中的信号路径与 RTL 层级不完全对应，generate 展开后的命名也不直观。AI 每次需要查信号时，都要先 scope -recursive | grep <hint> 再手工复制完整路径。建议增加模糊搜索功能，比如直接用片段名就能拿到候选路径列表。
Session 管理。每次重新编译仿真后 FSDB 变化，旧 Session 变 stale。AI 得手动 session kill 再 open。建议增加 reopen 或 open --force，自动检测 FSDB 变化并重建 Session。
批量操作。list add 遇到不存在的信号返回非零退出码，在 shell 脚本中用 && 串联时会中断后续添加。建议提供 --force 选项或批量导入文件的方式。
数据输出。event export 的 JSON 模式偶发输出空内容，AI 三次尝试均失败，最终回退到 grep 解析非 JSON 输出。建议排查空输出问题，或增加 CSV 作为备选机器可读格式。
此外还提了一些其他建议：scope -recursive 输出过大需要内置过滤、缺少信号值变化的时点查询、xwave 和 xtrace 的 Session 管理各自独立不便切换等等。
从这份反馈里我看到了什么
最让我注意的是反馈的风格。AI 不会像人类工程师那样“凑合用”——遇到空格语法报错，工程师可能试两次就记住“哦，这里不能加空格”，下次避开。AI 会反复尝试不同的转义方案，把每一次失败都记录下来，然后在反馈里写清楚：试了哪些方式、为什么都不行、最终怎么偶然解决的、文档和实际行为哪里不一致。
这种“不绕路”的特质，在工具开发上反而是好事。我自己用 xwave 时，很多小坑凭经验瞬间绕过，甚至意识不到它们存在。AI 没有经验，它在每个坑面前都停下来，并且留下一份详细的坑位记录。
另外一点是调用密度的差异。我自己测试工具，一天可能跑几十条命令。AI 在一次完整的 debug 流程中会连续调用上百次——信号快照、事件统计、条件过滤、交叉比对。这个密度把那些低频使用中不明显的粗糙面全部放大了：比如 Session 管理，偶尔手动 kill + open 不觉得麻烦，但 AI 每轮调试都要做这件事时，摩擦就累积成了反馈文档里的专门章节。
闭环才是关键
这份反馈让我意识到，让 AI 用工具这件事本身可以变成工具迭代的驱动力。以前工具改什么、什么时候改，主要靠我自己偶尔碰到问题，或者想起来某个地方可以优化。现在每次 AI 用完都能输出一份结构化的体验报告，粗糙面被系统性暴露。工具改进的速度，从“开发者偶尔想起”变成了“每次使用都在推动”。这个闭环一旦转起来，工具成熟的节奏就不再依赖个人的使用频率和记忆力。
