A_
图像内部设置与流程操作通过视觉进行分割
将“场景选择/尺度单位/识别区”这些高风险决策前置到同一设置面板
2025
算法能力平台化系列（二）
正负极 SEM 图像分析工具
研发工程师通过上传 SEM 图像样本，由模型进行快速分析，在内部完成从图像导入到数据分析结果沉淀的完整闭环
Context
业务背景
本项目将既有算法能力封装为可自助的软件流程，让分析从“依赖专家”走向“可用、可控、可复用”
对象
需要完成SEM图像分析并获取结论的研发工程师
收益
工程师能够按统一路径完成分析；结果用于汇报与记录；历史记录可沉淀、可复用
价值
解决业务场景痛点，将繁琐的人工沟通与交付转入系统
Challenge
业务当前痛点
经过多轮会议讨论与用户调研，提炼当下业务的核心阻碍
图像结果不统一，研发跨团队沟通成本高，难对齐、难复用
图像分析在内部高度依赖专家经验，过程不稳定、不可控
已有分析能力“停留在部分专家手里”，无法规模化沉淀
为了把能力从「专家手里」释放成「团队可规模化使用的工具」，将目标收敛为三项可落地的业务预期：
自主完成
工程师无需找算法同事也能完成一次分析与交付
结论可用
结果表达清晰、一致，能直接用于汇报/记录/沟通
可复用 & 沉淀
分析记录在项目中可回查、可对比，形成持续积累
Research
结果导向的业务流建模与体验洞察
基于业务预期，将工程师的分析工作拆为 “ 找—读—用—回 ” 四个关键断点，并把它们嵌入流程节点中作为设计重点
「 端到端工作流 」
Design
Opportunities
- 上传 SEM 图像（找）
同批次样本图像角度/倍率不一，用户需要花时间在找要看哪张
- 分析场景 & 尺度信息（读）
用户对选择哪个场景/尺度是否正确”缺乏确定感，怕一步选错导致的结果错误
- 查看分析结果（用）
用户需要要拿到能用于汇报/记录的结论，避免结果信息分散迫使用户反复判断
- 使用结果数据（回）
用户需要可交付的输出，希望能在能进行对比，以及避免较久时间后找不到、无法复用
在梳理出端到端工作流后，我发现仅靠功能 Demo 无法支撑工程师的真实分析情景与交付规范，因此通过“相似任务”下的成熟产品调研，融入与业务专家讨论的关键业务细节
调研策略：从 SEM 图像分析流程出发，寻找“相似任务”的成熟工具
a. 输入：从任务链路拆解（导入 → 选区 → 标定 → 分析 → 结果/导出）
b. 过程：哪些步骤是工程师默认需要但 Demo 缺失，与专家共同校验
c. 输出：补齐关键节点下的可优化项
Design Goals
业务目标与设计目标的对齐
为避免设计过早陷入界面层，将关键指标统一梳作为整个工具设计和评估的基础
「Goal A」
在项目上下文中快速定位任务
Solutions
用项目容器组织批量图像任务
通过查看样本图像会发现，不同角度、倍率和状态的图像混杂在一起，需要反复打开、核对和切换。因此，在批量的图像分析场景中，需要帮助用户快速找到目标与判断
「Goal B」
分析前降低启动分析的试错成本
Solutions
把高风险决策前置到分析设置
在批量 SEM 分析中，分析前是整条链路里“错误成本最高”的阶段，场景选错、尺度缺失、范围不清都会把返工推到分析之后，这将占据大量的时间成本
C_
提供识别区（ROI）作为可控入口
整图分析不一定符合业务意图，且部分场景会导致等待更久或引入无关区域；通过用户手动圈定重点区域，既贴合业务分析习惯，也能缩短等待并提升结果可预期性
B_
自助完成的可控步骤（上传→分析→结果）
让节点可见，工程师关键决策集中在当前步骤
D_
列表看图快速定位
以缩略图卡片承载批量的图像，贴合 SEM 场景以图像优先工作习惯
「Goal C」
模型输出读成可复核、可交付的结果
Solutions
用“结论—证据—细节”组织分析结果
在结果分析场景中，用户的核心目标是快速判断结果是否可信、是否可用于汇报或应用。设计重点不是堆叠更多数据，而是通过结论—证据—明细的结构，降低理解、复核与交付成本
data & meeting
SKetch
Product Thinking
算法 0-1 落地的产品思考
尽管「 工艺优化 」和「 图像识别 」两个功能在技术实现上有所不同，且可能模型仍有一些待突破的问题，但是针对这类需求的设计，我有了更多思考
算法类场景落地不是追求全自动化，而是要清晰划分人和算法边界，算法在合适的节点介入