今年十月，我开始把工作重心转向 ToB 产品与 AI 落地交付。过去几年做过政企平台、建筑 SaaS，也处理过不少复杂项目，但我越来越想验证一个更具体的问题：进入一个不熟悉的企业后，能不能从一线需求出发，把工具推到真正有人使用的地方。
我没有先给自己限定垂类，更关心这套“理解业务、判断需求、快速做出来、真正有人用”的能力能否跨行业复用。制造业只是恰好出现了一个真实场景。
强哥是我认识多年的朋友，在浙江诸暨一家二十来人的纺织机械零件厂担任组装车间主任。厂里没有完整的管理系统，老板强控制、现场规则随时跟着急单变，订单、库存和图纸版本常年在微信群、纸单和人的记忆之间流转。强哥每天最疲惫的事，就是反复去现场清点、翻本子，临时拼凑答案来回复老板的追问。
强哥一开始就很清醒：在看到实际效果前，老板不可能拍板推一整套系统。但企业数据不能私下乱跑，进场前我们先跟老板把底线聊透了——哪些数据敏感、哪些允许录入、客户信息如何脱敏，以及系统随时可以整体移交、在厂内单机私有化部署。老板点点头同意了这套安全边界，允许我们先在强哥的职权范围内试跑。
于是我们把第一期直接缩到了强哥自己的职权范围内——我出开发和方法，他出真实场景和反馈；我免费做，他也不必因为朋友关系替我留面子。第一轮不搞全厂改造，就先做一个他愿意自己打开、确实能帮他少跑腿的工具。
他给我一个不替我美化问题的现场，我给他一本能少跑腿的账。
10月15日，我打了第一通电话。按照传统库存系统的逻辑，我问他能不能做到“入库录一次、领用减一次”。
强哥在电话那头直接判了死刑：“连录一次都不可能。”
那时的我，脑子里想的还是怎么把表单做得更简单。但仅仅一周后的10月22日，还是在那个抗拒录单的车间里，强哥自己拿着手机，在微信小程序里录完了代号化的客户、BOM（物料清单）和组件库存，并第一次用系统完成了组件盘点。
这七天里，我们跑通了从原型（Prototype）到现场实证（Evidence）的前半程。回看这一周，有三条核心判断被现场验证：
小厂不缺管库存的软件，缺的是一个录入后马上能让自己省事的业务节点。
范围收敛不是把功能做小，而是敢于放弃约 2000 种原材料和 300 种可售零件的全量精细建档，一期只抓约 30 种高频订单组件。
从一个高连接度的关键岗位切入，真实数据一旦跑通，结果会迅速流向老板和相邻车间——但这只是起点，下一步是让老板从“结果使用者”变成“内部推动者”，并带动第二个岗位进入实际协同。
一、 客户要的不是一套更大的系统
这家厂主做织袜机相关配件。最初听到的痛点非常标准：仓库乱、库存查不准、订单交付进度不清楚。如果照着这套说辞去写需求，最后一定会做成一套没人填数据的简配版 ERP。
在第一通电话的 64 分钟深访里，我顺着“哪一步出问题、谁真的在用、什么算成功”往下挖了三层，看到的却是另一幅景象。
厂里的仓库每年都要花大力气重新整理三四次，蓝筐、纸箱、标签分区做得井井有条，但只要生产一忙，过一阵又恢复原状。因为现场有三条隐性流程在支配日常运转：
制度让位于急单。老板是订单的直接来源，遇到熟客催货，老板会直接进车间插单、改优先级。任何要求“先建单、再审批、后领料”的刚性系统，在临时指令面前都会瞬间失效。
录入没有回报。车床边的工人只关心加工合格品，仓库领料只求快。如果让一线工人每天为了管理层的报表多花时间填单，结果必然是漏填、乱填，账实很快脱节。
旧办法虽然累，但路径最熟。订单发在微信群里，加工数量记在机台边的纸板上，客户与组件的对应关系装在车间主任脑子里。
全厂同时推一套新制度走不通，这也是为什么我们从一开始就决定单点切入——把首个节点定在组装车间主任强哥身上。
强哥处在整个工厂信息流的交汇处：他同时连接着订单接收、组装安排、部分库存管理和发货核对。老板每天问“某个客户的货还能发多少、缺什么”，全靠强哥去现场跑腿清点。
问题一下清楚了：老板要的是答案，而强哥缺的是一本能随时生成答案的账。
一期工程不需要全厂配合，只要让强哥录入一次数据，系统就能帮他算清组件库存、管住客户交付，让他自己在老板追问时不再满厂跑，这个节点就能立住。
二、 从两千种原材料收窄到三十个组件
选定首个业务节点后，接下来是敢不敢砍范围。
厂里大约有 2000 种原材料、约 300 种可以单独出售的零件，以及约 30 种经常作为订单出售的高频组件。如果按标准 ERP 的路子，第一步就得把全部原材料、可售零件和订单组件编码、建档、盘点期初库存。
还没等建完档，项目就会因为录入负担过重而停摆。
我和强哥梳理业务时发现，日常作为订单直接交付给客户的高频组件其实就那 30 种左右。这些组件包含不同的零件搭配，且与客户订单模板强关联；有时还会根据客户要求增减零件，在库存中互相转换。
于是我们在范围上做了明确取舍：
一期明确不做：不做约 2000 种原材料与 300 种可售零件的全量精细建档；不做财务应收应付；不做考勤与薪资；不做复杂的 APS 自动排产。
一期围绕主链路分步验证：以这 30 种高频订单组件为核心，第一周集中验证了客户代号化管理、组件库存录入、BOM 关系录入与组件盘点；而订单转组装工单、缺件生成零件工单以及组件转换的完整交互，则在试用过程中持续建设与打磨。
同时，为了兑现进场前跟老板敲定的数据安全边界，系统从底层做了三道约束：
客户全部采用代号化管理（不暴露真实客商全称与联系方式）、敏感字段做权限隔离、不碰任何财务与价格数据；整套环境采用容器化封装，跑顺后随时可迁入厂内单机私有化部署，数据支持一键完整导出。
把老板对“商业机密外泄”和“被系统绑架”的顾虑提前拆掉，真实业务数据才进得来。
在库存机制上，我也放弃了“账面绝对精准”的执念，设计了“单点录入 + BOM 反冲 + 允许负库存 + 盘点校正”的近似库存模型。
现场经常发生货先发走、单据后补的情况。如果系统因为账面库存不足就锁死操作，业务立刻就会退回纸笔。允许库存先扣成负数并保留流水，定期通过盘点校正并下钻解释差异——先在组织不规范的前提下让关键节点用起来，系统才有机会陪着业务走向规范。
三、 先做 Demo 再进厂，现场推翻了哪些想象
10月16日到20日，我没有写长篇方案，而是基于自研的多 Agent 研发流水线，先搭出了一套可交互的 Demo。
10月20日下午，我带着这套 Demo 进了诸暨的工厂。在车间和仓库转了一圈，现场看到的三个细节直接修正了我的产品设计。
第一个细节，是手写的纸质订单。 我原本以为订单是标准的“一单一品”列表。但现场的订单是一张二维矩阵：横向是客户，纵向是组件，交叉的格子里写着数量与交期，上面有许多划改痕迹和特殊标记。标准 ERP 的商品明细表在这里远不如一张纸直观。这直接促成了按客户订单模板录单、以及后续支持模板临时加行的设计。
第二个细节，是夹在数控车床边的纸质登记表。 机台旁满是油污，工人每半天休息前，会用手写方式在纸板上更新填报一次合格品数量。看到这一幕我就更加确信：在系统价值被证明前，绝不能要求一线工人改变习惯去手机上做实时报工。生产数据的采集节奏，必须顺应现场已有的半日汇总习惯。
第三个细节，是强哥对界面的直接反馈。 我给他演示移动端工作台，强哥看了一眼，提了两个非常具体的要求：“字要大、按钮要大；订单直接看大数字，去掉进度条。”
车间光线杂，干活时手上有油、步履匆忙，小按钮极易误触；加上厂里人员年纪偏大，装饰性的进度条不仅看不清，反而挤占了核心数字的空间。
现场调研结束后，我们立刻明确了交互改版方向：去掉进度条，把订单关键指标改成高对比度的大数字；放大字号与可点击区域；工作台重排、订单模板临时加行、用料核对与图纸批次提醒等优化项也按优先级排进了迭代队列。
现场不是用来给需求清单补字段的，现场是用来检验你设计的动作在真实物理环境里究竟会不会发生。
四、 苹果手机把项目从 APP 推向小程序
10月21日晚，后端正式环境就绪，移动端也从本地演示数据切到了真实接口。
就在准备交付试用时，一个具体的设备约束摆在了面前：我此前准备的移动端载体是安卓 APK 安装包，但强哥手里的主力设备是 iPhone 和 iPad。
原有安卓包无法覆盖强哥的苹果设备，如果不解决载体问题，真实试用就会在设备这一步直接中断。
好在移动端工程最初采用的是 uni-app 跨端源码。10月21日晚，我当即调整了交付组合：
大屏管初始化：让强哥当天晚上先用 iPad 的浏览器打开 Web 端，完成部分初始化数据录入。结构复杂的 BOM 关系和主数据，在大屏网页上核对更顺手，降低了移动端的启动负担。
微信小程序承接日常高频操作：连夜处理条件编译、接口域名与构建参数，把微信小程序推进为正式交付路径。
10月22日，微信小程序正式版可用。跨过了安装门槛，强哥在微信里直接打开了系统。
用户手里的真实设备就是最硬的产品约束。它不是上线后的附加适配项，而是决定试点能否启动的前提。
五、 从演示数据到组织可见的真实结果
10月21日晚到10月22日，项目跨过了从 L1（可交互原型）到 L2（真实数据小范围试点）的分水岭。
在老板此前同意的数据边界内，强哥先在 iPad 网页端完成部分初始化，10月22日正式转入微信小程序，独立录入了代号化的客户、组件库存和 BOM 关系，并拿着手机在仓库里发起了一轮组件库存盘点。
当真实数据跑进系统的那一刻，变化不仅发生在强哥手上，也开始向周围岗位传导：
强哥自己先省了事：以前老板问“某批货还能发多少、缺什么”，强哥得放下手里的活去现场清点；现在直接在小程序里查看库存与 BOM 展开，截图就能回复。
老板成为了第一个结果消费者：老板虽然没有登录系统，但已经开始接收强哥发来的系统截图，用系统产出的数字做业务判断。
相邻车间进入了观察范围：组装车间的工人和隔壁零件车间的主任，都已经知道厂里有一套工具在跑。强哥每天用手机查单、盘点的动作，让系统成了车间里可见的事实。
我和强哥都很清楚，现场其他人目前仍在观望。新工具在证明自己之前，没人愿意主动多承担一步操作。但我们对后续推进很有信心，因为支撑信心的不是“以后会做多少功能”，而是三个已经发生的事实：强哥不用临时清点就能回答老板了；订单组件、BOM 和库存第一次进入了同一个口径；大字号、大按钮和大数字真正适应了车间现场的手和眼睛。
第一周建立的是首个真实业务入口，多人协同尚未发生。但这套结果已经进入老板的业务判断，也成为车间里的可见事实。下一阶段的目标，就是把这种组织关注转化为第二个岗位的实际参与，并推动老板从“看截图的人”变成“内部支持者”。
六、 阶段校准：从跑通实证（E）到完成验证（V）
用一线交付工程的方法框架来审视，第一周我们完成了原型（P），并把真实客户、库存、BOM 与盘点接入了现场实证（E）。
但要走完 PEV 的最后一环——价值验证（Validation），并在组织内实现从单点落地（Land）到巩固扩展（Consolidate & Expand），接下来必须在三个地方收紧工程纪律：
1. 补齐 Validation 的量化基线
第一周证明了“强哥愿意用”，但回答一次老板询问到底能省多少时间、盘点差异有多少能被流水解释，当时没有留下可对比的基准数据。
迈向 V 阶段，不能只靠“用着顺手”的主观反馈。下一轮必须测出五项高频任务的新旧耗时对比、连续使用天数以及盘点差异的可解释性，用硬数据完成第一节点的验收。
2. 用一线使用动机去筛选第二个节点
强哥能用起来，是因为系统先帮他自己省了跑腿的力气，而不是替老板监控他。同理，把系统扩向第二个岗位时，也绝不能要求对方“为了配合管理多填一张表”。
目前组装工人和零件车间主任都在观察。下一步需要通过独立访谈摸清他们的真实痛点，按“痛点频率、当前数据基础、数据贡献、流程阻力与可测量性”五个维度，选出那个“点一下手机自己也能省事”的第二节点。
3. 执行严格的范围控制纪律
现场试用一旦开始，需求就会不断冒出来：工作台重排、订单模板临时加行、订单转组装工单、缺件生成零件工单、用料核对优化……
如果所有需求加上后台工程增强一起铺开，很容易拖垮核心体验。接下来的纪律很明确：每周只允许一个直接影响核心任务的改动进入试用，其余全部放进需求池；每次新增需求，必须写明它替换或延后了当前哪一项任务。
七、 第 2—6 周推进计划：引入第二节点与推动老板背书
小范围试点最关键的跃迁，是把单点价值变成组织共识。从第 2 周到第 6 周，我按四步推进：
第一步（第 2 周）：稳住首个节点，测出五项基线。 让强哥在无协助状态下，独立完成订单、BOM、库存和盘点的日常操作。同时，选定五个最高频问题（查某订单可发数量、查组件当前库存、查订单缺料、核对 BOM 关系、盘点一组组件），实测旧方式与系统方式的耗时与操作卡点，补齐 Validation 数据。
第二步（第 2—3 周）：把观望转成结构化反馈。 分别找老板、组装工人、零件车间主任和发货协作人聊一次。不问“你们要不要用系统”这种假问题，而是直接问“最近一次因为信息不准被耽误是什么时候”。摸清老板最想随时确认哪几个数字，摸清零件车间主任和发货协作人最怕系统增加什么负担。
第三步（第 3—4 周）：第二节点最小任务试点。 在零件车间主任和发货协作人之间选定一人，不开放全套菜单，只让其独立完成一个最小闭环任务——例如只做一次零件完工入库，或只做一次发货核对。跑出一组新旧方式对照，同时确保强哥的核心体验不因扩人而退化。
第四步（第 4—6 周）：交出两页证据包，推动老板正式支持。 当第一节点稳定、第二节点跑通最小任务后，准备一份不超过两页的证据包交给老板。里面只放五项内容：
五项高频问题的新旧耗时对比；
三个真实业务案例（订单发货、缺料判断、组件盘点中系统给出的结果）；
当前数据覆盖范围与盘点差异解释情况；
客户代号化与字段权限边界；
第二节点的试点方案。
不需要在没有数据的时候让老板“拍板全厂推广”。拿着这组已经跑出来的事实，我只向老板争取三件事：同意继续使用真实业务数据、指定第二节点参与人、约定两周后的复盘时间。
下一次去诸暨工厂，我的任务单上只有三件事：
站在旁边不插手，看强哥用小程序完整走完一次从接单到盘点的操作，记下所有卡顿和误触的位置。
针对那五个高频问题，和强哥一起把旧方式与系统查询的耗时基线测出来。
去隔壁车间找零件车间主任聊二十分钟，问问最近一次零件和组装对不上数是怎么发生的，看看那张每半天填一次的机台登记表，从哪一步能最自然地接进这套账本里。
评论区