2025-2026
算法能力平台化系列(一)
将内部自研算法融入工艺研发流程,连接参数推荐、工程师调整、实验执行与结果回传等链路,让模型持续更新迭代,最终形成可协作、可优化的研发闭环、工程师的生产力工具

Context
在企业内部工艺研发流程中,用户主要围绕「新隔膜产品的 CCA 图层配方」、「优化石墨颗粒的混配比例与粒径,以提升振实密度」等多类研发场景进行实验,以获取最佳数据,自研贝叶斯优化算法可实验前给出推荐参数,把试错成本前置
对象
实验工程师(任务驱动、对错误敏感、依赖经验与历史案例)
收益
实验前完成筛选与判断,而不是把算法当成专家才能操作的黑箱
价值
少开一轮无效实验;推荐能被改、被回传,模型才能迭代
为什么要做产品化?

Before_ 人工对接链路
工程师等待算法人员出参,相似任务反复沟通;参数调整与实验结果分散,难以沉淀复用
After_ 平台化闭环
工程师可自主获取并调整推荐参数,实验结果统一回传;过程可追溯、方案可复用、模型可持续迭代
Research
由于需求属于内部定制化场景,无成熟的产品对象,传统 UX 思路无法直接使用,需要依赖对业务流程的建模
“ 在无界面设计之前,将算法在迭代的逻辑进行内化,结合工程师做完一轮实验的步骤,收成同一条产品回路,最后通过原型探讨细节 ”

Methods:
1、原理
抛开界面,先搞清贝叶斯优化在迭代什么(目标、采集、回传)
2、建模
和算法同事多轮对齐沟通,设计前期用流程框架代替无竞品调研
3、验证
原型在算法能跑和人能用之间来回调整,基于v1的版本进行评审迭代
Research ·
Challenge
项目初期,算法还没被拆解为产品,项目前期按算法专家的输入需求完成出了 v1.0 demo设计,初期演示里暴露出一系列问题,包括工程师使用难度大、不敢拿去实验等
首页没有「第一步要做什么」,用户对路径不确定、没有明确起点,任务易被交回算法同事
通常情况下涉及的参数字段较多,被要求填几十个字段,易出现填不清,填怕填错等问题
在初期演示中,用户对 AI 生成的参数推荐结果带有质疑:
“ 我不知道算法是怎么得出数据的,能不能直接用还得问算法专家 ”
“ 结果看起来像个黑箱,不敢贸然实验 ”

Design Goals
用户先能快速上手,完成参数优化的完整链路后,最后愿意回传实验数据,持续提升模型准确性

项目边界
a. 企业内部自研工具,当前服务内部小范围实验工程师群体
b. 早期阶段以“深度理解 + 快速迭代”为主,优先打通可落地闭环,而并非追求规模化指标
「Goal A」
从熟悉的研发目标出发,帮助工程师顺利开始
Solution:建立为以研发目标为起点、逐步承接系统各项的任务的工作台
首页缺少以研发任务为中心的明确起点,创建过程又提前暴露模型等系统概念,用户需先理解平台,才能快速上手


「Goal A」
从熟悉的研发目标出发,帮助工程师顺利开始
Solution:建立以研发目标为起点、逐步承接系统各项的任务的工作台
通过轻量新人导航,帮助新用户能在短时间内建立的认知,带着用户迈出第一步
「Goal B」
让工程师快速建立可校验、可复用的任务场景
Solution:从手动填表,到人机共建研发任务
初版设计仅考虑源数据可能的形式各不相同,在输入给到用户宽泛的自由度,但实际评审中暴露出明显问题
过程低效
输入边界模糊
易出错

将 [ 全量填表 ] 改成 [先确认场景/目标,再生成对应参数框架 ]

「Goal B」
让工程师快速建立可校验、可复用的任务场景
Solution:从手动填表,到人机共建研发任务
面对几十个参数,真正耗时的不是输入数字,而是寻找字段、判断是否相关或是否遗漏。因此,将配置方式从“逐项创建字段”调整为“系统预选参数集合

通过用户选择应用场景配置相关参数集,加减少无关信息干扰(交互切换场景+选择&删除)
「Goal B」
让工程师快速建立可校验、可复用的任务场景
Solution:从手动填表,到人机共建研发任务
由于参数优化在输入的框架下是固定的,AI可以将自然语言转移为结构化的初稿,用户再进行校准,本版本为下一阶段的初步概念
「Goal C」
让推荐结果用户可理解、可修改、愿回传
Solution:从手动填表,到人机共建研发任务
先让工程师看懂,再决定是否使用(推荐以建议呈现,同时提供依据与可改范围,把最终决定权留给工程师)

Transferable Capabilities
整个反复打磨的过程中,帮助我逐渐形成了一种新的工作思路
“ 面对无竞品、无成熟用户范式的业务需求 ”
