订单履约管理系统（Fulfillment V2）

业务背景

合作方习惯在微信群里提交发货地址和商品数量，云仓按消息发货，供应商则在月底集中核对。订单、发货、退换货与财务信息散落在聊天记录和 Excel 中。

核心痛点

• 多个角色对订单和售后的信息理解不同，缺少共同数据来源。
• 云仓以发货为中心，难以额外承担复杂的财务系统操作。
• 历史订单修改后，月底已核对的账单可能与系统实时数据产生差异。

我的职责

需求收集、跨角色流程抽象、AI 工程任务设计、验收与问题排查

解决方案

• 设计外部结构化申请、运营审核、库存分仓、仓库发货、物流售后与月结对账的闭环。
• 按合作方、运营管理员和云仓划分操作界面与数据访问边界。
• 保留仓库 XLSX 批量上传下载的操作习惯，并通过关键标识校验关联履约明细。
• 采用 Draft → Lock → Snapshot 的月结快照方案，防止已确认账单随历史订单变化。

AI 协作方式

我把不同参与方的口头需求翻译成业务规则、权限和异常流程；ChatGPT 帮助推演页面—API—数据库的约束；Codex/Kimi Code 在既有实现上完成限定范围的修改、测试与排障。

实施过程

• 还原合作方、供应商、云仓、运营财务的实际发货路径。
• 建立商品/SKU、仓库、订单与售后业务规则。
• 将批量仓库履约和月度锁账快照纳入方案。
• 历史材料记录订单审核 HTTP 500 的 SQL/事务链路排查与定向修复。

资料记载的成果

• 形成覆盖申请、审核、发货、售后和月结的业务系统方案及真实开发案例报告。
• 工作台案例资料描述了合作方、运营与仓库三类用户的操作边界。
• 已有真实开发与排障记录，但本轮未重新验证所有模块在最新生产环境的可用性。
• 没有可靠的前后基线，不写“效率提升 X%”或“成本降低 X 元”。

技术栈

业务流程建模、XLSX 批量履约、SQL / 数据库、API、Playwright、Codex、ChatGPT

图集

相关附件

真实性说明

订单工作台 7 页报告记录业务背景、流程设计、版本 v0.2.1 和开发实践；不能仅凭案例文字视为当前生产系统的所有功能均可用。

历史任务数字仅代表当时记录，不代表当前系统运行结果。