北京
一张合影几乎完美：光线好，人都在框里，是个值得留下的瞬间。然后你发现，有个人眨眼了。
对开发者来说，这看起来像个小图像编辑任务。但真实需求更苛刻：把眼睛睁开，同时保留用户已经喜欢的照片里的一切。MomentRescue 是一个照片修复项目，其 Open Eyes 工作流背后有一个工程问题——当请求的改动很小时，如何约束一次生成式编辑？
先定义什么允许被改
“把这张照片变好”是开放式请求。“修复所选人物闭着的眼睛”边界窄得多。这个区别应该出现在系统设计里，而不只是提示词里。一份有用的约定是：每次操作只选一个人；在眼睛周围划定修复区域；该区域之外的原始像素保持不变；输出单独的文件，原图完整保留。
模型可能生成超出你打算使用的范围。最终哪些生成像素进入成片，仍由应用决定。这就是“请求克制”和“强制执行克制”的区别。
把生成和合成分开
一条实用的概念流程是：原图 → 检测人脸并确认所选人物 → 准备人脸裁剪和可选参考 → 生成候选修复 → 将候选对齐到原坐标 → 通过有界的眼部遮罩混合 → 对比、审阅、导出。这是设计提纲，不是完整实现，也不代表所有照片修复工具都这样工作。
关键分离在于：产出一个候选，与接受像素进入最终照片，是两件事。对不透明 RGB 图像，基础混合是：
- function blendPixel(original, candidate, maskAlpha) {
- const a = Math.max(0, Math.min(1, maskAlpha));
- return original.map((channel, i) =>
- Math.round(channel * (1 - a) + candidate[i] * a)
在允许区域之外，maskAlpha 必须为零；在边界处，渐变过渡可以柔化接缝。困难的工作围绕这个小公式：坐标映射、对齐、遮罩放置，以及处理眼镜边缘。柔和的遮罩救不了没对齐的眼睛。另外，保留解码后的像素，与逐字节保留原始文件不是一回事——导出可能改变压缩和元数据。
参考是证据，不是保证
闭着的眼睑藏着信息。没有可靠的“锐化”操作能揭示眼睑下真实的双眼。同一个人的睁眼参考能提供视觉线索，但角度差异很大的清晰参考仍可能匹配不佳。挑选参考的实用建议很具体：选同一个人、双眼可见；优先相近的头部角度和光照；试试同场拍摄的相邻照片；避开墨镜、严重模糊或像素占比极小的脸。如果参考里有多个人，界面也要在其中确认匹配的人。参考减少猜测，但不证明生成结果准确。
两个尺度看结果
现有的一次 Open Eyes 测试使用合成人物，是产品演示，不是客户照片、背书或基准，结果会有差异。修复前，中间的人闭着眼；修复后是现有测试结果。整图视角回答“照片整体还协调吗”；近距离检查回答另外的问题：双眼视线方向是否相容？眼睑贴合脸型吗？镜框是否连续？有没有可见的混合边界？一个结果可能通过一种视角而败在另一种。
“完成”和“好”是两回事
API 响应只说明处理结束了，不说明这个人看起来还像他自己。一次聚焦修复可以用三项独立检查评估：第一项可以在导出前比较遮罩之外的解码图像来自动完成，另外两项仍需视觉判断。有用的评估用例包括小脸、侧脸、眼镜、不匹配的参考，以及不止一人眨眼的合影。一张干净的演示图无法证明这些情况下的表现。
对范围很窄的 AI 编辑来说，输出边界本身就是功能的一部分。同样的问题适用于移除干扰物、修复文档区域，或改动产品图里的一个物体：系统究竟被允许重写输入的哪些部分？答案清晰，才有具体的东西可实现、可检查、可测试。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
