[AI Development Lab] 做了个精确截图Demo：固定尺寸和比例，不用再靠手抖

AI 242 views · 5 replies ·

一头牛

deepin product team

8 hours ago

Author

各位用户老爷大家好。

今年4月的时候，不是做了一波用户访谈。

sammy大哥说，建议给截图录屏加俩功能：

截图取色
按照固定比例/尺寸去截图。

加上之前截图录屏的公众号文章评论区。

也有其他用户提到：

牛哥表示，用户提到的，必须当个事办！

经过几轮调整和验证，前段时间做出了一个可以运行的 Demo。

文末包含了amd架构的deb包；也提供了源码，其他架构的用户可以自行用小U同学指导打包体验。

来看一下实际效果，顺便也简单复盘一下过程中重要的几个心得：

一、前置工作：先把需求讲清楚

别急着开写，先把功能和交互想清楚：

要增加什么能力？
尺寸和比例怎么切换？
输入、拖动后界面怎么变化？
设置要不要保留？
新面板怎么融入现有界面？
....

我还把现有工具栏和界面截图一起提供给 AI，避免它凭空设计一套新风格。

一个比较实用的流程是：

先让 AI 整理功能说明和交互流程；
再用 ChatGPT Image 2 生成一张功能示意图。

（下图为AI生成的功能说明，其中关于“锁定”功能，后续实际有调整）

图不一定是最终设计稿，但很适合提前发现入口、状态和流程上的问题。

方案对齐后再写代码，返工会少很多。

二、修改过程：AI 能写代码，但得把哪里不对说清楚

前面的功能说明和示意图确定后，就可以把 Git 地址、需求文档和参考图一起交给 AI，正式进入代码环节了。

基础功能其实很快就跑起来了。

但“能运行”和“真能用”，中间还是隔着好几轮体验。

实际测试时，陆续遇到了输入尺寸被旧数值覆盖、固定比例出现像素偏差、工具栏互相遮挡、窗口自动识别与固定尺寸冲突、深色模式和高分屏适配不完整等问题。

这些 Bug 具体怎么修，没必要一条条列出来给大家看。

真正值得总结的是：发现问题以后，我们应该怎么把修改要求描述给 AI。

1. 不要只说“这里有 Bug”，要把前后表现说清楚

最开始我也会直接告诉 AI：

这个输入框有问题，帮我修一下。

但这种说法其实信息量很低。

AI 不知道“有问题”具体指什么，也不知道修完以后应该达到什么状态。

后面我会尽量按照下面的方式描述：

当前表现：输入新的尺寸后，移动鼠标，输入框偶尔会重新显示之前的数值。
期望表现：编辑输入框期间，鼠标移动不应覆盖正在输入的内容；输入框失去焦点，或点击截图区域、截图区域外及其他工具按钮时，提交新尺寸并更新选区。

相比“优化一下输入逻辑”，这种说法有明确的触发条件、错误表现和最终结果，AI 修改起来会准确很多。

简单来说，尽量讲清楚三件事：

我做了什么；
现在发生了什么；
正确结果应该是什么。

2. 不只描述功能，还要把完整操作链路补齐

以截图取色为例。

只说“支持 Ctrl+C 复制色值”，功能当然也能做出来。

但复制之后呢？

是否退出截图？
怎么知道复制成功了？
反馈显示在哪里？
样式要不要和现有系统保持一致？

我最后给 AI 的要求大概是：

在截图状态按下 Ctrl+C 后，将当前色值复制到剪贴板，随后退出截图，并提示“已复制色值”。

当时提示方式考虑过两种：

屏幕中间弹一个 Toast；
沿用截图完成后的系统通知。

最后选择了系统通知。

一是和现有截图完成后的反馈保持一致；二是复制色值后也会退出截图状态，从整个流程来看，同样属于一次操作完成。

这样既能明确告诉我“已经复制成功”，又不会突然增加一套新的反馈样式。

这种思路其实很简单：做完一件事，要有结果反馈；相似的操作，尽量使用相似的反馈。

3. 多个功能打架时，要直接告诉 AI 听谁的

修改过程中，很多问题并不是某个功能没做出来，而是两个功能同时发生时，不知道应该以哪个状态为准。

比如：

正在编辑尺寸时，鼠标移动是否可以刷新数值？
固定尺寸后，鼠标移动到应用窗口上，是否还要自动识别整个窗口？
设置了 9:6，拖动选区后，是继续保留 9:6，还是根据取整后的像素重新计算比例？
从比例切回尺寸后，应该显示原比例，还是显示当前选区的真实像素？

这种时候不能只说“这里逻辑不对”，而是要直接定义优先级：

正在编辑输入框时，以当前输入内容为准，鼠标移动不得覆盖。

钉住尺寸或比例后，不再响应窗口自动识别产生的选区变化。

比例是持续约束，拖动选区只改变大小，不改变已设定比例。

从比例切回尺寸时，显示当前选区的真实像素，并在后续拖动时实时更新。

把“谁优先”写清楚，AI 才不会一边修好这里，又把另一边改坏。

4. 少说“自然一点”，多给具体场景

“位置合理一点”“适配高分屏”“交互自然一点”，这些话听起来没错，但 AI 很难直接执行。

最好换成具体的场景和结果。

比如工具栏遮挡：

当截图选区靠近屏幕底部，尺寸面板会与原有截图工具栏重叠。检测到下方空间不足或发生遮挡时，将尺寸面板移动到选区内部顶部。

再比如高分屏：

当前设备物理分辨率为 3120 × 2080，系统缩放为 175%。全屏截图时，面板显示为 1783 × 1152，但最终导出的图片实际是 3120 × 2080。尺寸面板应展示最终图片的真实像素，而不是内部使用的逻辑尺寸。

数字、触发条件、当前结果、预期结果都写出来以后，问题就非常明确了。

AI 不怕要求多，怕的是要求模糊。

5. 涉及界面，直接给参考图，别让 AI 自由发挥

尺寸面板第一次做出来时，功能虽然有了，但和现有截图工具栏的视觉风格并不完全一致。

后面我会直接把现有界面截图、图标和选中状态一起提供给 AI，并明确告诉它：

半透明背景参考原有截图工具栏；
选中态参考矩形工具的蓝底白色图标；
Tooltip 的字号和深色模式参考现有提示样式；
下拉、切换、图钉等图标直接使用提供的资源；
新面板的圆角、间距和透明度尽量与原应用保持一致。

能截图就别只用文字描述。

另外一个小tips：

如果写不出来，也可以截图另开一个对话，让AI先描述具体设计风格。

确认无误后，把参考图和文字描述一起刚到AI去写代码。

“参考这个效果”通常比“做得精致一点”有用得多。

6. 产品定义没想清楚时，先别让 AI 改代码

最典型的就是最开始的“锁”图标，这个也是sammy大哥体验后给我反馈的。

我的原意是：

选中后，下次截图继续使用当前尺寸或比例。

但实际体验时，很容易被理解成：

锁住以后，当前尺寸不能再修改。

这时继续让 AI 换各种锁图标，其实没有意义，因为问题并不在图标画得好不好，而是功能含义本身容易产生歧义。

所以我会先明确告诉 AI：

先讨论方案，不要直接修改代码。

然后让它一起分析锁、图钉、书签、星标分别可能传达什么含义。最终才确定使用“钉住”，并固定 Tooltip：

选中后，下次截图仍为该尺寸/比例。

7. 每轮修改，都要告诉 AI 怎么才算改完

后期我给 AI 的提示词，都会尽量带上简单的验收条件。

比如尺寸与比例切换：

从尺寸切换到比例时，将当前尺寸换算成比例；从比例切回尺寸时，显示当前选区的真实像素。之后拖动选区，尺寸输入框需要实时更新，比例输入框则继续保留原设定比例。

这样改完以后，就可以直接按照这条流程验证，而不是只看界面上有没有多出一个按钮。

对于比较复杂的问题，我一般会按照这个结构描述：

当前表现 → 期望表现 → 触发条件 → 边缘场景 → 参考样式 → 验收结果。

听起来有点像写需求文档，其实不用特别正式。

以“输入尺寸后，数值偶尔又变回旧值”为例：

当前表现：
在输入框中填写新的宽度或高度后，移动鼠标时，数值偶尔会恢复成修改前的内容。

期望表现：
编辑输入框期间，鼠标移动不能覆盖当前内容；输入完成后，再根据新数值调整截图区域。

触发条件：
输入框失去焦点，或者点击截图区域、截图区域外以及其他工具按钮时，都视为本次输入完成。

边缘场景：
输入尺寸超出屏幕可用范围时，自动使用当前能够容纳的最大尺寸。

参考样式：
输入框和交互状态沿用截图录屏现有工具栏的视觉效果。

验收结果：
分别验证输入宽度、输入高度、移动鼠标、点击其他区域、输入超大尺寸和拖动选区。新数值不能再被旧值覆盖，拖动后输入框也要同步更新。