最近把一个内部营销工具做出来了，想起来这事在我这拖了快 4 年，有点感慨，来记录一下。
工具本身没什么新概念，就是把公司里三个系统串起来：云策（人群和行为数据）、手铺（商品、订单、库存、供价、活动）、墨鱼（客服触达）。要做的事说穿了就是根据数据挑人、挑品、算活动，结果推给运营确认，确认完部分动作写回系统。单点看都不是特别难，难的是它横跨几个系统，而且规则很碎。
拖住它的不是代码，是链路。这几年思维导图画了一版又一版，产品方案过了一遍又一遍，中间还换了好几个产品同事。每换一个人我就得重新讲一遍：云策里用户行为怎么看，手铺的商品和订单怎么对应，墨鱼能做哪些触达，哪些客户不能乱发，哪些商品不能乱推，会员、优惠券、活动价各自什么规则……讲到后面我自己都烦了。
不是同事不行，是这种内部工具天生就碎。它不是标准 SaaS 功能，也不是清晰的单点需求，就是一堆业务经验堆出来的流程，这里查一下那里兜一下，边界判断一大堆。正常流程走下来是：我讲给产品，产品画图写方案，评审，技术评估，排期，开发，测试，上线。任何一环换人或者规则一变，重来。所以它就一直挂着。
这次的区别是，我把中间沟通链路压短了。自己拆业务规则，直接和 AI 一起做。不是一句“帮我做个智能营销系统”完事——那种肯定完蛋——是一段一段来：先接云策数据源，能查人群、行为、商品数据；再接手铺的商品、库存、供价、活动、会员；然后做营销动作，发券、发会员、活动补品、客服触达；再接墨鱼做主动推送；最后补试跑、审批、日志、执行历史这些兜底。
翻了下提交记录，集中开发就是 6.22 到 6.26 这几天。22 号做“前日热销 × 定价参考”的限时抢补品任务，23 号修云策 sku_id 和活动匹配的坑，24 号加发放会员动作，25 号接墨鱼推送和选品、定价、提案，26 号把品类秒杀的自动运营 Agent 收了一版，提案、写价、补品、回填、smoke 脚本都补上。
严格说不是 5 天做出一个完美系统，是一个拖了 4 年的想法，从动手到能上线试跑用了 5 天左右。对我来说这个差别已经够大了。
现在的流程大概是：云策拿数据（分群、行为、销量、转化、加购），手铺补商品信息（库存、规格、供价、活动状态、历史活动价），然后按规则生成一份建议——哪些商品适合进活动，哪些用户适合触达，哪些规格不能写价，哪些因为利润、库存或者重复报活动要排掉。
我没敢让它全自动执行。很多动作现在都是先“试跑”：只算结果，不真发券、不真写价、不真触达，先看这一次会影响多少人、哪些商品哪些规格、预计写什么价、有没有命中异常规则，我确认了才进正式执行。这种工具最怕的不是跑不起来——跑不起来大不了再调；怕的是跑得特别顺，把错事干完了。写错活动价、错发会员、错推客户，事后收拾起来要命。
所以兜底加了不少：全量触达要审批；变更型任务必须用负责人自己的手铺账号跑；执行历史记录覆盖了多少人；商品、sku 、供价这些关键字段跑 smoke 检查；多匹配宁可拒绝执行也不猜；能试跑的一律先试跑。这些东西以前要跟产品、开发、测试来回掰扯很多轮，现在我直接把业务风险讲给 AI ，它先做一版，我看结果，不对接着改。
回头看，感触最深的倒不是写代码快，是中间那些翻译环节没了。以前我脑子里的业务经验要先翻译给产品，产品翻译成方案，开发理解成实现，测试理解成用例，每过一层丢一点，谁都没错，但链路就是长。现在背景、规则、异常情况、验收标准直接丢过去，它不一定一次做对，但不嫌我啰嗦，也不用重新排期，错了就改，漏了就补。
我很多年不写代码了，现在也不逐行看，主要看结果：数据对不对，流程通不通，日志有没有，失败能不能知道，出错能不能停。这个用法可能跟很多技术同学不一样，我不做通用产品也不做 SaaS ，就是拿它清公司里那些“早该做但永远排不上期”的工具。这类需求以前最尴尬，有价值但不标准，是真需求但太碎，AI 出来之后，这类东西反而最适合先做出一个能跑的版本。
当然现在这套离完美还远。云策的数据口径会变，手铺有些接口字段很绕，墨鱼那边还要处理签名、错误码、会话状态。涉及价格、会员、优惠券、触达的动作我还是偏保守，半自动为主。但至少它跑起来了，不再停在思维导图和产品方案里。
想问问做过内部系统或运营工具的同学：跨多个系统的自动化，你们的试跑、权限、审批、回滚一般怎么做？特别是碰价格、会员、触达这种动作，是敢全自动，还是也留人工确认？
工具本身没什么新概念，就是把公司里三个系统串起来：云策（人群和行为数据）、手铺（商品、订单、库存、供价、活动）、墨鱼（客服触达）。要做的事说穿了就是根据数据挑人、挑品、算活动，结果推给运营确认，确认完部分动作写回系统。单点看都不是特别难，难的是它横跨几个系统，而且规则很碎。
拖住它的不是代码，是链路。这几年思维导图画了一版又一版，产品方案过了一遍又一遍，中间还换了好几个产品同事。每换一个人我就得重新讲一遍：云策里用户行为怎么看，手铺的商品和订单怎么对应，墨鱼能做哪些触达，哪些客户不能乱发，哪些商品不能乱推，会员、优惠券、活动价各自什么规则……讲到后面我自己都烦了。
不是同事不行，是这种内部工具天生就碎。它不是标准 SaaS 功能，也不是清晰的单点需求，就是一堆业务经验堆出来的流程，这里查一下那里兜一下，边界判断一大堆。正常流程走下来是：我讲给产品，产品画图写方案，评审，技术评估，排期，开发，测试，上线。任何一环换人或者规则一变，重来。所以它就一直挂着。
这次的区别是，我把中间沟通链路压短了。自己拆业务规则，直接和 AI 一起做。不是一句“帮我做个智能营销系统”完事——那种肯定完蛋——是一段一段来：先接云策数据源，能查人群、行为、商品数据；再接手铺的商品、库存、供价、活动、会员；然后做营销动作，发券、发会员、活动补品、客服触达；再接墨鱼做主动推送；最后补试跑、审批、日志、执行历史这些兜底。
翻了下提交记录，集中开发就是 6.22 到 6.26 这几天。22 号做“前日热销 × 定价参考”的限时抢补品任务，23 号修云策 sku_id 和活动匹配的坑，24 号加发放会员动作，25 号接墨鱼推送和选品、定价、提案，26 号把品类秒杀的自动运营 Agent 收了一版，提案、写价、补品、回填、smoke 脚本都补上。
严格说不是 5 天做出一个完美系统，是一个拖了 4 年的想法，从动手到能上线试跑用了 5 天左右。对我来说这个差别已经够大了。
现在的流程大概是：云策拿数据（分群、行为、销量、转化、加购），手铺补商品信息（库存、规格、供价、活动状态、历史活动价），然后按规则生成一份建议——哪些商品适合进活动，哪些用户适合触达，哪些规格不能写价，哪些因为利润、库存或者重复报活动要排掉。
我没敢让它全自动执行。很多动作现在都是先“试跑”：只算结果，不真发券、不真写价、不真触达，先看这一次会影响多少人、哪些商品哪些规格、预计写什么价、有没有命中异常规则，我确认了才进正式执行。这种工具最怕的不是跑不起来——跑不起来大不了再调；怕的是跑得特别顺，把错事干完了。写错活动价、错发会员、错推客户，事后收拾起来要命。
所以兜底加了不少：全量触达要审批；变更型任务必须用负责人自己的手铺账号跑；执行历史记录覆盖了多少人；商品、sku 、供价这些关键字段跑 smoke 检查；多匹配宁可拒绝执行也不猜；能试跑的一律先试跑。这些东西以前要跟产品、开发、测试来回掰扯很多轮，现在我直接把业务风险讲给 AI ，它先做一版，我看结果，不对接着改。
回头看，感触最深的倒不是写代码快，是中间那些翻译环节没了。以前我脑子里的业务经验要先翻译给产品，产品翻译成方案，开发理解成实现，测试理解成用例，每过一层丢一点，谁都没错，但链路就是长。现在背景、规则、异常情况、验收标准直接丢过去，它不一定一次做对，但不嫌我啰嗦，也不用重新排期，错了就改，漏了就补。
我很多年不写代码了，现在也不逐行看，主要看结果：数据对不对，流程通不通，日志有没有，失败能不能知道，出错能不能停。这个用法可能跟很多技术同学不一样，我不做通用产品也不做 SaaS ，就是拿它清公司里那些“早该做但永远排不上期”的工具。这类需求以前最尴尬，有价值但不标准，是真需求但太碎，AI 出来之后，这类东西反而最适合先做出一个能跑的版本。
当然现在这套离完美还远。云策的数据口径会变，手铺有些接口字段很绕，墨鱼那边还要处理签名、错误码、会话状态。涉及价格、会员、优惠券、触达的动作我还是偏保守，半自动为主。但至少它跑起来了，不再停在思维导图和产品方案里。
想问问做过内部系统或运营工具的同学：跨多个系统的自动化，你们的试跑、权限、审批、回滚一般怎么做？特别是碰价格、会员、触达这种动作，是敢全自动，还是也留人工确认？
Select Language