个人作品集 · ToB 产品商业化
把高定制、难交付的问题产品，做成可销售、可配置、可交付的标准品。
这不是"重写一个新产品"的故事，而是"把一堆客户各自要求的定制，收敛成一套通用能力"的故事。这里介绍这次商业化改造做了什么，以及我在其中的角色。
问题是什么
这类安全产品很容易掉进一个陷阱：每来一个客户，就多一套专属定制；定制越多，版本越难维护，交付越慢，团队规模却越滚越大。产品没有变强，只是变重。
需求从哪里来
我的需求不是别人递到手上的，是自己去客户那里跑出来的。起点永远是客户业务上碰到的真实问题，产品和迭代是把对应能力补上去之后，自然带出来的结果。
这是一家大型银行总行的漏洞运营体系建设项目，我直接驻场，前后半年多，天天跟客户各业务部门的人打交道，一条条摸他们漏洞处置的实际流程。摸下来发现核心问题不是"产品功能不够"，而是现有安全能力撑不住业务侧的诉求：扫描器扫出来的、渗透测试挖出来的不同来源漏洞，在客户现有工单体系里根本流转不起来，责任人也定不清楚。方案、原型、路线图都是从这个现状里一步步长出来的，不是先有个产品去往客户身上套。系统验收后一直稳定运行，现在二期也在跟。
核心能力
标准化不是砍掉客户的个性化需求，而是把高频出现的诉求提炼成平台能力，让新客户接入时"配置即可用"，而不是"重新开发一遍"。
统一接入扫描器、渗透测试、攻防演练等多来源漏洞，同时打通资产台账与威胁情报数据，作为处置全链路的统一入口，避免同一问题在不同渠道重复处理。
核心能力按 CVSS/VPR 风险评分结合资产属性、业务规则自动给漏洞定级定责，减少人工逐条评估的重复劳动，让高风险漏洞第一时间被看见。
核心能力按资产归属、责任人、优先级规则自动分派处置任务；状态变化、审批推进等关键节点自动通知责任人，不用人工盯着系统反复查。
核心能力跟踪处置状态、超期预警和升级路径，让修复不再靠人工追进度。
核心能力标准化复测流程，确认修复真正生效，而不是"标记已修复"就算完成。
核心能力用户按自己的运营口径自选统计维度、时间范围和图表类型，饼图、柱状图等自助组合展示，不用再为每个客户的统计需求单独定制开发。
核心能力标准化方法论
每一条客户定制需求，先问一个问题：这是这一个客户的特例，还是很多客户都会需要的共性？答案决定它走哪条路径。
三个典型改造
这类商业化改造里最常见的场景，是客户提出一个看似专属的要求，实际背后是一类可复用能力。以下是三个有代表性的例子。
客户环境里的漏扫工具、CMDB、ITSM 各不相同，早期每接一个新系统就要重新开发一套对接代码。改造后，数据同步能力做成低代码集成引擎——认证、解析、过滤、清洗、归一化、字段映射拆成可配置节点，新系统对接从写代码变成拖拽配置，单系统对接成本从约 5 人天降至 1–2 天。维护成本更低、对接效率更高，而且每接入一个新系统就沉淀成一份可复用的系统资产，后续有相同对接需求的客户能直接复用，不用再从零开发一遍。
不同客户对漏洞自动化处置的要求千差万别：有的要求命中特定条件自动关闭误报漏洞，有的要求满足条件自动编辑漏洞属性，有的要求自动推进或关闭处置工单。早期这类需求靠人工逐条处理，或者为单个客户写死一套专属逻辑。改造后统一抽象成漏洞策略引擎——按资产属性、漏洞类型、风险评分等条件组合配置触发规则和执行动作，自动关闭指定漏洞、自动编辑漏洞属性、自动处置工单等场景都能通过配置实现，不需要为每个客户的处置逻辑单独开发。
客户对运营数据的统计诉求五花八门：有的要看修复率趋势，有的要按部门看漏洞分布，有的要按季度看 SLA 达成情况。早期做法是为每个客户的统计诉求单独开发统计页面。改造后做成可配置数据看板，用户自主选择统计维度、时间范围和图表类型（饼图、柱状图等），按自己的运营指标口径自由组合展示，不需要为每个客户的统计需求单独定制开发。
我在这次商业化里做了什么
这次改造的关键不是某一个功能做得多好，而是重新定义了产品经理和客户定制需求之间的关系。
系统梳理已有功能、客户反馈和内部缺陷，把分散的定制问题归类成可复用的能力域，划定哪些进平台、哪些走插件。
围绕数据接入、自动定级、分派通知、修复跟进和复测验证，把高频定制诉求沉淀为配置策略、数据接入、流程编排和数据看板，而不是一次性代码。
对真正无法通用的少数客户特例，采用插件化思路承接，避免为了少数客户拖慢主线迭代，也避免标品代码被定制逻辑污染。
推动 50+ 版本迭代、支撑 200+ POC 和 50+ 客户的持续交付；在人力收敛情况下独立承接双产品线并保持交付增长，定制开发量下降 70%+。
判断标准
这是这次改造里最常用、也最需要经验判断的一道取舍题。
销售、交付、客户现场反馈汇总，不遗漏个别声音。
按能力域分组，识别哪些诉求反复出现。
高频诉求进标品配置，低频特例走插件化。
配置化能力随版本统一发布，全体客户可复用。