先说工具全貌：hmharness 是一个开源的 HarmonyOS/OpenHarmony 开发智能体框架，把工程创建、检查、构建、签名、安装、启动、日志读取和结果验证接成本地工具链，让 AI 不只是生成代码，还要用本机环境证明结果；自进化行为受审批、预算、canary 和回滚约束。它不是 DevEco Studio 的替代品，而是开发智能体和鸿蒙工具链之间的验证层。本文只展开其中一环：TUI 原生选择复制。
终端 AI 工具最容易暴露问题的地方，往往不是模型能力，而是那些看起来很小的交互细节：想划选一段命令复制出来，鼠标却先被 TUI 抢走了；想用滚轮翻列表，又担心为了滚轮开启全局鼠标跟踪。对每天在终端里工作的人来说，这不是审美问题，是效率问题。
hmharness 的 TUI 最终选择是：不开启全局鼠标捕获，把选择和复制还给终端；滚轮通过 ?1007 alternate scroll 转成上下键；选择器保持键盘操作；无法完全排除的杂散 SGR 鼠标报文直接吞掉。
1. 全局鼠标捕获为什么会让复制变难
终端应用如果开启 1000、1002 或 1006 这类鼠标报告模式，终端会把拖选、滚轮和点击事件先交给应用，而不是交给终端自己的原生选择器。这样做的收益是应用能知道鼠标位置，代价是用户熟悉的“按住左键划选，右键或快捷键复制”被抢走了。
对一个开发智能体 TUI 来说，这个取舍不划算。用户经常需要把模型输出的命令、路径、错误栈和代码片段复制到别的窗口查资料或复现问题；这些高频操作不应该为了界面内点击而牺牲。
所以 public main 的行为被固定为：启动序列不包含 1000h、1002h、1006h。原生选择和复制在任何时候都可用，而不是只在某个模式关闭后可用。
2. 不捕获鼠标后，滚轮怎么办
去掉全局鼠标捕获后，hmharness 使用 ?1007 alternate scroll。这个模式让终端在备用屏幕里把滚轮事件翻译成上下方向键。
于是职责变成：
- 终端继续负责拖选、复制和粘贴；
- ?1007 负责把滚轮变成上下键；
- TUI 的 picker 收到上下键后移动选中项。
这不是“功能少了”，而是边界更合理：需要精确选择的动作留给用户和终端，需要列表导航的滚轮进入应用。测试中，/model picker 打开时，滚轮下滚等价于按下方向键下，滚轮上滚等价于方向键上。
3. picker 回到键盘优先，杂散报文被吞掉
既然不再开启鼠标报告，picker 就不再依赖 SGR 坐标点击。选择模型或历史会话时，用户用方向键移动，用 Enter 确认，用 Esc 退出。这也更符合终端用户的肌肉记忆。
但还有一个防御细节：即使当前应用没有开启鼠标报告，某些环境仍可能传来残留或异常的 SGR 报文。如果这些字节被当成普通输入，可能污染命令草稿或触发错误行为。hmharness 对这种报文的处理是直接忽略。
当前测试锁定了三件事：全局捕获永久移除；picker 是键盘驱动；杂散 SGR 点击不会进入输入框，也不会改变选择。
4. 怎么复现证据
本文事实钉在 public main 提交 c6fdd73422ef8cb05d41412ed448e7d4e8f5a226。对应 CI run 41398333044 已通过，汇总为 1068 tests / 1067 pass / 0 fail / 1 skipped。
本地只读复现命令：
git clone https://github.com/swsgbl/hmharness.git
cd hmharness
git checkout c6fdd73422ef8cb05d41412ed448e7d4e8f5a226
npm install
node --import tsx --test packages/cli/src/__tests__/tui.test.ts
本轮本地运行结果为 35 pass / 0 fail，其中直接覆盖本功能的测试包括：
- ?1007 滚轮在 picker 打开时转为上下键；
- 全局鼠标捕获永久移除，原生选择和复制始终可用；
- picker 键盘驱动；
- 杂散 SGR 点击被吞掉。
修复链包含提交 7d024a5d3a3e7e268d2c39a0e59793e1c74818c8，但本文不采用该提交信息或旧 changelog 里“picker 临时开启鼠标跟踪”的中间方案；验收以 public main 当前源码和测试为准。
安装与发布边界也要分清：npm 当前在线包是 @hmharness/cli@0.23.50，registry 读回的 gitHead 正是 c6fdd734...；GitHub Latest Release 仍是 v0.23.26，两者不能混写成同一个发布状态。
5. 这个细节为什么值得写成一篇文章
AI 终端的价值不只在于“模型回答了什么”，还在于它是否尊重用户原本的工作方式。一个会抢走鼠标划选的 TUI，哪怕功能再多，也会让开发者频繁回到鼠标模式、终端菜单和外部编辑器之间来回搬运。
hmharness 这次的取舍很明确：应用能力不能以削弱终端原生能力为代价。原生选择复制保留，滚轮导航保留，键盘 picker 保留，异常报文不进入输入。这种小交互的确定性，正好和整个项目的证据优先原则一致。
如果你在不同终端、不同 OS 或不同 Node 环境下遇到鼠标、滚轮、粘贴或选择行为差异，欢迎把环境版本和现象反馈到 GitHub Discussions #4。环境差异是当前最有价值的测试输入。
参考：
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。