Photo Inventory
把“自动整理照片”重新定义为高风险文件治理，而不是再做一个图库。
- 关键判断
- 高风险操作必须可预览、可暂停、可恢复；不确定时默认保留。
- 实际结果
- 真实扫描 35,678 个文件，0 错误；安全迁移 28,118 个，可恢复隔离 2,505 个。
B 端产品经理
复杂业务与工程数字化
擅长基于真实场景、业务价值、错误成本与交付约束，判断复杂业务中真正值得解决的问题，识别需要验证、延后或不做的需求；在明确产品边界与优先级后，将需求转化为研发可执行的业务对象、流程、状态与约束，并推动落地验证。兼具产品设计与交互落地能力。
Cui Song · 机械设计制造本科 · 2 年航空发动机制造工艺工程背景 · 长期参与测绘、GIS 与港航工程数字化
港航工程
工程建设
测绘地理信息
房地产
金融投资
教育
制造业
10年复杂数字产品
5年港航 · 测绘数字化
10+B 端行业数化项目
从模糊需求到可验证结果
问题定义识别真正问题、业务对象与用户任务
产品判断明确边界、优先级、约束和不做什么
推进交付把方案补成可设计、可研发、可验收的细节
真实验证用实际数据、运行结果与异常场景持续修正
三项核心项目
每个项目先给判断和结果，再展开完整过程。
测绘云
把停留在功能名和按钮的需求，补成跨端对象、字段、状态、异常与责任。
- 关键判断
- 先闭合现场作业链路；自动化执行条件未闭合前，不承诺全面接管。
- 实际结果
- 三版水文移动端、多组跨端方案与 16 项交付前提问题；部分方案进入开发、联调与现场。
倾废监管
从地图画面优化转向监管对象关系和追踪路径重构。
- 关键判断
- 以项目、船舶、许可证和倾倒区的关联关系组织信息，而非堆叠独立页面。
- 实际结果
- 形成从地图对象进入详情、沿关联关系继续追踪并原路返回的完整方案。
工作经历
独立产品实践
个人产品负责人 · AI 协作实现
2026.03 - 至今
发起并持续使用 Photo Inventory：以自己约 300GB 照片库为对象，完成首次完整扫描 35,678 个文件（0 错误）、安全迁移 28,118 个、可恢复隔离 2,505 个；负责问题定义、产品边界、优先级与真实验收。另完成 YUYU 手作集的产品定义与后端数据架构方案
中交集团 · 上海达华测绘科技
UI 设计师
2021.02 - 2026.02
正式职位：UI 设计师；实际责任：需求产品化、交互方案、界面交付、研发验收与阶段性项目推进。在测绘云等需求颗粒度不足的项目中，把只有功能名称和按钮的需求补成项目、任务、测点、人员、设备等对象的字段、状态、异常和跨端流程，并持续校对研发实现
好屋集团
UI / UE 交互设计师
2019.03 - 2021.02
负责好屋系列 App 与小程序的 UI / UX；以好屋合伙人 APP 为主，参与多轮 UX / UI 升级，围绕经纪人报备、客户管理和内部审批梳理核心流程、信息架构与视觉体系；在报备流程中加入防误触机制与任务入口分层，把 Web 端原型改造成适配 iOS / Android 操作习惯的移动端方案
东方新华投资管理有限公司
产品及 UI 设计师
2018.07 - 2018.11
参与金融交易中心产品设计，梳理产品框架、业务信息与信息架构
上海知氏教育（集团）
高级 UI 设计师
2017.07 - 2018.04
负责 App、Web 与教育平台的 UI / UX、设计规范和研发验收，参与多客户端复杂交付
上海出奇科技有限公司
UI 设计师 / 顾问
2016.07 - 2017.06
直接对接客户需求，独立完成 App 与 Web 产品的信息架构、交互方案和 UI 视觉交付
东安实业发展有限公司
机械加工工艺工程师
2014.08 - 2016.03
从事航空发动机制造工艺技术支持，熟悉三维 CAD 建模、装配、工程图与 BOM，了解设备参数与车间现场约束；这决定了后续做设备管理与监测类系统时的判断起点
Photo Inventory｜把“自动整理照片”重新定义为安全治理
整理已经存在多年的文件夹式照片库：识别重复、相似、版本与事件关系，并用预演、校验、隔离和恢复保护真实文件操作。
核心产品案例 · 2026不再做一个图库：把旧照片整理定义为安全治理
成熟图库解决浏览和搜索；Photo Inventory 处理旧目录、原片与编辑版关系，以及真实移动和删除带来的不可逆风险。
我的工作
- 以约 300GB 的个人照片与视频定义问题、优先级、交互和安全规则。
- 借助 AI 协作完成技术实现，并持续使用、提出 Bug、推动改进与验收。
把安全设计成逐级提高的操作授权
产品把“看清楚”和“真的改文件”拆开。每当操作风险提高，用户都能先看到范围、停下来检查，并保留回退路径。
01只读盘点
先建立文件基线，不改动原库
02人工判断
以事件、文件夹和相似组批量审阅
03方案预演
展示逐文件去向、冲突和空间条件
04冻结范围
执行前锁定清单，防止边做边变
05校验执行
暂存、移动并逐项记录结果
06隔离与恢复
普通删除先进入可恢复隔离区
从一次性扫描报告，迭代成可以长期使用的资料库
真实使用中，产品逐步加入 Finder 变化同步、相似照片对比、快速筛选、隔离恢复、增量备份与本地 OCR；首页只保留当前最常用的任务入口，并持续显示安全规则。
把逐张翻看，改成围绕“做决定”的连续处理
我关注的不只是信息有没有展示，而是用户能否在同一个上下文里看清差异、修正结果并继续下一项，减少在列表、详情和操作页之间反复跳转。
相似照片大图对比
把一组相似照片放进沉浸式大图窗口，点击即可逐张切换，同时保留序号、尺寸、文件大小和系统建议。用户可以保留当前、选择多张、全部保留或暂不判断，保存后直接进入下一组。
OCR 处理弹窗
左侧查看、缩放和旋转原图，右侧校正识别文字；处理后可提取到本地记事本并保留照片、只删除识别结果，或把照片移入可恢复隔离区。完成一张后自动进入下一张。
通过持续使用推动产品收敛，而不是继续增加功能
AI 可以快速实现方案，但真实使用暴露了“逻辑完整”不等于“用户愿意继续”。我多次停止扩张，改为保护存量、减少状态和降低判断成本。
继承已有目录
不为了形式统一打散旅行、婚纱照原片／精修等既有成果；未审阅目录默认原样保留。
减少决策，而非增加待办
否定“封存、冷藏、待消化”等新层级，转向事件、文件夹和相似组的批量判断；拿不准默认保留。
用 AI 的能力边界定义产品边界
在这类高风险操作里，要设计的不是 AI 能做什么，而是它不被允许做什么。三条规则决定了整个产品形态。
把永久删除权留给人
AI 和算法只提供候选，人做终审；任何算法都不获得永久删除权。
优先本地模型，敏感数据不出机器
OCR 走本地 Apple Vision，云端图片识别默认关闭 —— 敏感数据不出机器。
让人的判断优先于算法
AI 可以快速实现方案，但“逻辑完整”不等于“用户愿意继续”；多次停止扩张，把判断权留给人。
用数万文件验证方案，而不是停在原型和功能清单
数据来自本地项目数据库的聚合统计，记录了产品在真实照片库中的使用规模。
35,678首次完整扫描文件，记录为 0 个扫描错误
28,118完成安全迁移的文件
2,505进入可恢复隔离区的文件
29.5 GiB可恢复隔离内容，并非已永久节省空间
测绘云｜把模糊水文需求补成可交付的跨端作业链路
这是一个连接测绘后台与船上作业现场的 B 端系统：后台准备项目、任务、测点和资源，现场人员录入水文数据、签名并在弱网下保存，资料回传后由 Web 端查看过程成果。我主要参与需求产品化、现场流程补全、项目推进与可行性判断。
企业项目 · 约 2022—2024我的工作
- 正式岗位：UI 设计师；实际责任：需求产品化、交互方案、界面交付与研发验收。
- 责任边界：没有完整产品所有权；最终验收与业务指标不由我负责。
- 补全需求中的对象、字段、页面、状态与异常。
- 2023.10—2024.01 兼任项目推进，承担需求转译、排期沟通与风险汇报。
判断真正的问题：目标与交付条件长期不匹配
项目被描述为覆盖采集、处理、存储、发布和分析的完整平台，但需求经常停在功能名、按钮或粗略原型，跨模块字段、状态、异常和责任没有同步明确。本案例聚焦已形成局部链路的水文移动端与配套后台。
接手以后，我改变的是需求进入研发的方式
2023 年 10 月末接手实际推进后，我将模糊问题改成可讨论的方案，将跨部门沟通集中到单一接口，并在继续承诺前说明交付前提。
原来的问题功能名代替需求
原型经常只有一个按钮或一句功能说明，字段、状态、异常和跨模块影响留给设计与研发猜。
我的行动先把需求补成可讨论的方案
与需求负责人逐项开会，追问对象、页面、字段、操作顺序和异常；提供 PRD 参考并持续要求把确认结果写回文档。
发生的变化形成可进入设计开发的细节
完成三版移动端及多组 Web 设计，后期 PRD 格式和内容也有所改善。
原来的问题全员周会成为冲突现场
需求方、项目组和两个部门之间缺乏信任，沟通消耗不断挤压实际工作。
我的行动改为单点需求转译
取消全员周会，由我作为沟通桥梁；同时与双方部门负责人同步项目和人员问题，并用纪要向本部门领导持续汇报。
发生的变化直接冲突减少
项目沟通能够继续推进；冲突集中到我这里，组织信任与人员积极性仍未解决。
原来的问题质量责任不断互相转移
需求不完整、实现偏差和 Bug 混在一起，缺少清晰版本、回归和验收依据。
我的行动提出文档、测试与版本改进建议
要求需求变更进入 PRD，持续校对前端实现；向测试负责人咨询减少 Bug 的方法，并提出自动化测试和旧 Bug 回归。
发生的变化问题有了明确记录
部分实现逐步逼近设计稿，但测试机制没有完整落地
原来的问题需求方缺少专业产品支持
业务设想无法稳定转成完整 PRD；跨部门又缺乏信任，由我长期代为补全也不是可持续方案。
我的行动建议需求部门引入专业产品人员
建议由对方所在部门招聘专业产品人员，协助梳理业务并产出完整 PRD；同部门协作更容易建立信任，也能从源头提高需求输出质量。
发生的变化建议未被采纳
方案没有落地，后续需求质量仍主要依赖逐项追问和沟通补全。
原来的问题部门准备整体接手
产品承诺很大，核心自动化链路和组织条件却没有闭合，接手意味着同时继承历史承诺。
我的行动给出承接风险判断
针对数据处理需求整理 16 项问题，拆开人工与自动处理链路；建议本部门不要在交付条件尚未闭合时全面接管。
发生的变化本部门最终未全面接管
项目随后交由需求部门新负责人继续推进
把现场工作压缩成可执行流程，而不是只补几个按钮
我重点重构了两类现场任务：用前置依赖管理复杂记录，并减少高频作业中的页面跳转。
把复杂施测表变成有顺序、有状态的录入流程
“5 施测记录”不会在进入页面时一次性展开；只有前四项、尤其是测点基础配置完成后才出现。记录页在同一屏展示需要填写什么、哪些已经完成，并采用大字号、大点击区、格式化录入和快捷开关，适应船上现场操作。
1基础信息未完成时，不提前展示施测记录
2完成测点基础配置后，再开放下一阶段
2在同一屏展示录入项目与完成状态
把“选择测点 → 跳转页面 → 再点一次查看数据”压缩到同一页面
我把测点列表、定位信息和测量项目放在同一工作面：左侧始终保留测点上下文，右侧直接查看和录入当前测点数据；编辑测点时先暂存选择，确认后再更新列表，避免边选边跳动。首页快捷入口同时把当前采样、作业资源和设备状态从深层菜单提到首屏。
3把正在进行的业务状态与入口提到首页
4测点列表持续保留，切换时不丢失当前上下文
5选择先暂存，确认后再统一更新测点列表
把业务规则做成状态、约束和恢复路径
这里展示的不是零散小功能，而是同一种产品方法：先找出“谁在什么状态下可以做什么”，再把责任、风险和反馈放进操作流程。
把现场设备从并列按钮改成线性生命周期
我提出设备按照“开始使用—结束使用—再次使用”推进，开始后不可直接删除，高影响操作需要确认。人员选择中的负责人替换与普通成员增删，也沿用了同一套角色化逻辑。
6设备按“开始—结束—再次使用”呈现生命周期
7开始使用前进行确认
7删除前进行确认
让监控状态与成果进度更容易读取
成果展示用绿／橙黄／灰和成果数量表达项目进度，让完成、进行中和未开始的状态更容易读取。
继续设计和排期前，先问清执行条件和异常路径
我从数据处理和预约机制两类需求中识别交付风险，不在执行条件尚未闭合时直接进入全面设计与排期。
拆开人工处理与自动处理链路
针对数据处理子系统，我整理 16 项问题，核对数据来源、处理主体、软件调用方式、输入输出与异常责任，判断自动处理的执行条件是否闭合。
把预约机制补成可讨论的完整场景
针对预约机制，我继续追问多人占用、预约修改、断线重连、时间冲突和未保存数据等状态，避免只画出正常流程。
现场验证暴露了办公室环境看不到的约束
2023 年 9 月，现场团队形成问题记录。这里仅保留约束类型，不公开完整内部缺陷清单。
弱网与本地数据
设备占用与权限
运行性能
户外可读性
最终留下的可验证成果
我把大量模糊需求补成了可讨论、可设计的方案，部分设计进入现场和运行页面，并在后期整理 16 项问题、说清了关键交付风险。项目整体未形成正式验收和量化结果。
- 三版水文移动端及多组跨端设计由本人独立完成。
- 早期链路形成 Web—App—Web 演示，重构版本进入现场。
- 持续校对前端，使指挥中心主要结构逐步逼近设计稿。
- 整理 16 项交付前提问题并说明风险，本部门未在条件未闭合时全面接管；项目后续由需求部门新负责人继续。
其他决策片段
YUYU 手作集｜面向手作创作者的个人品牌小程序
我的工作
- 进入开发前，先完成产品定义、信息架构与后端数据结构设计，明确页面、内容关系、字段与技术边界。
- V1 明确 15 项不做、6 个核心数据集合和 3 档图片策略，完成 6 个页面高保真设计。
当前状态：开发前确认微信个人主体能力无法支持预期方案，项目停止在产品定义、界面设计与后端数据架构阶段。
围绕产品边界做出的关键决策
-
01
内容体验优先
弱化标题、分类与作者，让作品图片成为第一层体验
-
02
先定义产品边界
V1 排除支付、登录和互动等 15 项功能，集中完成内容展示
-
03
结构与安全一起设计
建立可扩展的内容关系和三档图片策略，前台不返回敏感字段
借助 AI 推进方案的方式
Stitch 辅助视觉探索 → Figma 建立设计源 → Codex 协助整理 PRD、数据模型与技术方案
智慧工地｜24 小时状态半小时间隔热力图
设备的“当前正常／异常”无法说明问题发生在何时、持续多久或是否反复出现。我将塔吊多项运行参数按行、过去 24 小时按半小时间格展开，并用颜色区分正常、离线和不同异常持续时长。
让异常的时间位置、频率与跨度一眼可见
时间位置快速定位异常出现在哪个半小时间格
频率与跨度区分偶发、反复与连续异常
多参数比较在同一视图中比较回转、高度、倾角等状态
好屋合伙人｜报备链路交互优化
围绕房产经纪人的连续报备任务，我检查了楼盘选择、客户录入、提交与再次进入等关键环节，把“不顺手”进一步拆成页面跳动、反馈滞后、误触覆盖和流程没有闭环等具体问题。
先让核心流程更容易完成
从报备入口、楼盘选择到客户录入，先解决任务难找、过程被打断和规则难理解的问题。
让核心入口更容易到达
- 问题
- 报备入口分散在不同页面，层级也不统一，用户需要反复寻找
- 改进
- 将一键报备提升为首页一级入口，并在相关页面保留快捷入口
选择越多，操作越容易被打断
- 问题
- 已选楼盘不断撑高页面；达到 5 个上限后，用户再次选择才会收到提示
- 改进
- 将已选内容收进固定区域，显示选择数量，避免列表随选择过程不断跳动
在用户操作前反馈限制
- 问题
- 原选择达数量上限依赖 Toast 被动提示，楼盘选择与查看规则的点击范围也不清晰
- 改进
- 达到上限后直接置灰未选楼盘，并重新划分选择楼盘与查看规则的点击区域
输入规则不该靠反复失败理解
- 问题
- 电话号码被拆成三个独立输入框，用户点击不同位置时，只能输入对应位数
- 改进
- 将三个输入区域在视觉上组织成一个完整号码，降低理解和切换成本
把分散操作整理成连续流程
- 问题
- 楼盘、客户信息和快捷选择混在同一页面，信息层级和操作顺序不够明确
- 改进
- 重新组织页面结构，让用户按确认楼盘、填写客户、提交报备的顺序完成任务
再降低用户犯错的概率
核心流程梳理后，继续检查误触、数据覆盖和任务完成后的去向。
避免误触覆盖已填信息
- 问题
- 快速选择客户的整行都能点击，滑动时容易误触，并直接覆盖已填信息
- 改进
- 先将点击范围缩小到加号，后续再增加“新增或替换”的确认提示
完成任务后给出明确出口
- 问题
- 报备成功后缺少下一步引导，用户只能不断返回，重新寻找后续入口
- 改进
- 根据报备来源，分别提供继续报备、查看客户、返回楼盘或返回首页
最后展示一次失败与修正
这次调整没有成功，却让我重新确认了隐号功能真正要解决的问题。
界面更简单，不等于目标正确
- 问题
- 我最初合并了电话号码输入框，却误解了“隐号”的目标，仍要求用户填写完整号码
- 改进
- 确认隐私需求后，允许隐号状态下不填写中间四位，并重新调整录入提示
这次失败改变了什么
先确认功能目标，再判断是否应该简化界面
倾废监管系统｜地图监管对象与轨迹信息重构
负责人让我自行研究并优化既有系统。我没有只调整界面样式，而是重新组织项目、船舶、许可证与倾倒区之间的关系，让监管人员可以从地图对象进入详情、沿关联关系继续追踪，再回到原来的查看路径。
让地图对象成为监管关系的入口
把倾倒区与关联工程集中到同一详情
把轨迹、许可、工程与影像整合进船舶详情
收起低频搜索，重建地图信息层级
背景、能力与联系
目标方向：B 端产品经理 / 平台产品经理
优势能力：复杂业务梳理、产品方案设计、信息架构与交互落地
产品工作能力
业务对象建模 / 流程与状态设计 / 需求边界与优先级 / 异常路径 / 跨端信息架构 / 研发协作与验收
AI 协作
用于需求澄清、方案审查、文档整理、原型实现与真实数据验证；关键判断和验收由本人负责。
微信
cscscs
专业背景
沈阳航空航天大学
机械设计制造及其自动化
职业资质
人工智能训练师（三级 / 高级工）
