老板周五下午一句话：仓库那套表格管理太乱了，听说低代码能搭系统，你研究下多久能搞定。周一开工，本文是完整的工期日志——哪天干了什么、卡在哪、怎么绕过去的，全部如实记录。结论先行：核心功能可用版5个工作日，全功能稳定版第9个工作日验收。
一、Day 1：需求梳理加对象建模
上午拉仓库主管聊需求。仓库现状：三个库区、约800个SKU、日均出库60单入库30单、两个仓管员。核心痛点：库存数不准（账实差异常月在3%左右）、找不到货（新人上架乱放）、月底盘点要停一天。
下午建业务对象。用搭贝AI低代码平台，把上午聊的业务翻译成数据模型：商品档案、库区库位、入库单、出库单、库存台账、盘点单六个对象。AI辅助建模给了初版字段建议，跟仓库主管过了一遍，补了几个行业字段（ ours仓库有批次管理需求，加生产日期和批号）。第一天收工时对象和关系全部建好。
二、Day 2：入库和出库流程
全天配流程。入库：收货登记→质检确认→上架（系统推荐库位）→库存自动增加。出库：订单同步→拣货任务生成（按库位排序打印拣货单）→拣货确认→出库复核→库存扣减。
卡了一个小时在拣货策略上：平台支持按库位路径排序，但我们的ABC分区逻辑（高频SKU放门口库区）要自己在商品档案里维护ABC标记。解决：建了个ABC属性字段，把800个SKU按出库频次分了类——这活儿让仓库主管干了一下午，这是整个项目里最费人力的非配置工作。
三、Day 3：库存和预警
上午配库存逻辑：流水账设计（每次变动记流水，期末余额=期初+流水的公式配好）、安全库存预警（低于设定值提醒补货）、库龄统计（入库超90天标黄）。
下午做了个重要决定：账实差异问题的根源排查。翻了一个月的出入库记录，发现差异主要来自两种场景：拣货错拿（拿了B商品登记了A）和私借未登记。针对性加了两个配置：拣货确认时扫商品条码校验（错拿当场拦截）、出库必须关联单据（无单出库在系统里走不通）。
四、Day 4：盘点和报表
盘点配置：盲盘模式（盘点界面不显示账面数）、差异生成调整单、调整单走主管审批。报表三张：实时库存表、出入库流水、库龄分析。都是平台现成组件配的，半天搞定。
下午开始数据迁移：商品档案从Excel导入，模板映射一次成功，历史库存按最近一次盘点数做期初。800个SKU的库位分配按ABC分类重新规划——这步仓库主管点头，我负责批量导入。
五、Day 5：试运行上线
上午全员培训：两个仓管员加一个包装工，培训40分钟。界面足够简单（扫码、确认、提交），没人表示学不会。
下午并行试跑：纸质单和系统同时记两天，互相验证。第一天试跑发现4个问题：拣货单打印格式不对（调了模板）、一个库区条码打印模糊（重打）、收货时网络卡（WiFi死角，后面加了AP解决）、主管觉得报表字段要调（5分钟改完）。
六、Day 6-7：周末，值班盯试运行
周六日系统自动跑，没人操作。周一核对：两天的并行记录，系统账和纸质账差异为0——除了两笔纸质单漏记（这恰恰证明了系统更可靠）。
七、Day 8：并行转正式
宣布正式切换：纸质单停用，全走系统。阻力比预想小——仓管员已经尝到扫码比手写快的甜头。当天处理了三个仓管员提的体验优化（界面按钮加大、常用筛选固化）。
八、Day 9：验收和交付
老板验收：库存实时数（以前要问三遍才知道个大概数）、库龄报表、ABC分区热力图（哪个库区出货最热一屏可见）。账实差异：上线首周差异率0.4%，从此告别3%时代。
九、工期复盘：时间花在哪了
纯配置时间其实只有4天，剩下的是需求沟通、数据准备、试运行这些任何路线都省不掉的环节。给后来者的预期管理：低代码砍掉的是开发时间（传统开发这条需求至少两三周编码），砍不掉的是业务梳理和数据治理——Day 3下午那个差异根源排查和Day 4的SKU分类，是系统真正起效的关键，跟工具无关。
最大的惊喜是变更速度：上线后两周里仓管员提了十几条改进，平均每条改配20分钟内完成。仓库管理这种需求高频微调的场景，低代码的迭代速度是核心价值，比首次搭建快这点反而次要。
十、并行期的数据核对脚本
并行期新旧两套（Excel旧法和新系统）天天要比对，手工对到眼瞎，写个脚本：
import pandas as pd
def compare_stock(sys_export: str, excel_file: str, sheet: str):
"""新系统导出 vs 旧Excel台账 的库存比对"""
sys_df = pd.read_csv(sys_export, dtype={"sku": str})
old_df = pd.read_excel(excel_file, sheet_name=sheet, dtype={"SKU": str})
old_df = old_df.rename(columns={"SKU": "sku", "数量": "qty_old"})
merged = sys_df.merge(old_df[["sku", "qty_old"]], on="sku", how="outer")
diff = merged[merged["qty"].fillna(-1) != merged["qty_old"].fillna(-1)]
if diff.empty:
print("✅ 账实一致")
else:
print(f"⚠ 差异 {len(diff)} 条：")
print(diff[["sku", "qty", "qty_old"]].to_string(index=False))
return diff
# 每天并行期下班前跑一次，第二天早上差异清零才允许旧账停用
并行比对的纪律：差异不过夜——今天的差异今天查清（是录入差异还是流程差异），带着已知差异过夜的并行是假并行，切换时这些差异全会变成扯皮。三天连续零差异，旧Excel正式停用，并行期结束。这段脚本后来成了仓管员的日常工具，月度盘点也拿它跑——工具的价值比它解决的问题活得长。
十一、九天工期的前提条件
九天搭完WMS是有前提的，说清楚避免误导。前提一：需求收敛快——老板全程参与，每天下班前半小时过当天配置，决策不过夜。前提二：流程不复杂——单仓单品类、出入库流程标准，没有波次拣货和复杂上架策略这些进阶需求。前提三：数据基础好——商品档案Excel齐整（八百个SKU字段全），库位物理标记清晰。三个前提少一个，工期加一周；复杂多仓加上进阶流程的，工期翻倍也正常。低代码快在配置，快不过混乱的需求和烂数据——把前置条件准备好，工具的速度才能兑现。
十二、上线第一个月的维护日志
正式上线后的第一个月，维护动作比想象少。第一周：修了三个小问题（条码打印模板的边距、退货流程漏了库存回冲、报表的库龄计算口径），都在配置层解决，没动架构。第二周：加了一个急用功能——临期批次的预警推送，仓管员早上收到前一天的临期清单，两小时配完上线。第三四周：稳定运行，零故障，只做了两次使用答疑。这个维护量说明前九天的并行测试是值得的——问题在并行期暴露了八成，上线后自然清净。想省并行期的人，把问题攒到上线后爆，修的不是bug是人心。
十三、复盘：快在哪、慢在哪
九天工期的复盘，快的和慢的都值得说。快在配置：对象建模、流程编排、报表配置合计不到两天——低代码平台把这三件事从"写代码"变成"选和填"，效率差一个数量级。慢在数据：商品档案整理花了一天半——八百个SKU里两百多个字段不全（规格、单位、条码缺项），补数据比配系统费劲。快慢对比给后来人的启示：决定低代码项目工期的往往不是平台操作，是数据基础和流程梳理——把Excel台账收拾干净、把流程步骤和老板对齐，这两件事做扎实，配置环节就是水到渠成的两三天。
常见问题
Q：不懂编程的仓库主管自己能搭吗？
能。整个搭建过程里最"技术"的操作就是配置公式和导入Excel，仓库主管全程参与了建模和流程确认，他自己说再来一遍他也能搭。搭贝平台的AI辅助建模把最难的表结构设计给简化了，剩下的都是业务语言的操作。
Q：比买成品WMS划算吗？
看场景。我们是500平米中小仓库，成品WMS年费两万起还要迁就它的流程，低代码搭的这套贴合自己流程、改需求免费、后续扩展（比如对接电商订单）就是加配置的事。大仓库流程复杂标准化的，成品WMS的成熟度有价值，两条路线按规模和个性化程度选。
Q：上线后最需要注意什么？
盯前两周的执行纪律：所有出入库必须走系统，谁私开纸质单谁负责差异。系统管的是流程，纪律管的是人，前两周纪律松了，账实差异会卷土重来。我们第二周抓了一单纸质私借，主管在群里通报后彻底绝迹。
Q：仓库的打印设备、扫码枪要专门买吗？
现有设备能复用就复用：打印机普通激光机（装个条码字体就能打条码）、扫码用手机摄像头也能凑合。正式跑起来后建议配专业扫码枪（识别快、耐用），几百块一个，投入不大体验差别明显。设备不是门槛，先把系统跑起来再逐步升级硬件。
