先有业务流，再有软件
真正从事外贸销售后，我看内部工具的方式发生了变化。一个页面可以很漂亮，但如果它没有贴合询盘如何变成订单、订单如何进入打包，以及管理者如何回看业绩和成本，它依然不能解决问题。
TradeFlow 最初面对的是很多看起来很小、却每天重复发生的时刻：同一份客户资料被复制到多个位置，产品信息在报价与 PI 之间发生变化，打包信息到得太晚，业绩数据又在业务结束后重新统计。单独看，每个问题都不大；连在一起，就会产生等待、不确定和重复返工。
设计交接，而不只是设计页面
真正值得设计的单位不是某一张页面，而是人与职责之间的交接。销售需要判断询盘是否值得跟进，运营需要完整订单信息，仓库需要准确的产品、数量和箱规，管理者需要能够回溯到真实订单的数据。
- 询盘信息应该直接进入商机，而不是再次录入。
- 确认后的报价应该延续到订单和 PI。
- 打包、库存、物流与报关应该共享同一套产品事实。
- 业绩与薪资应该由业务记录推导，而不是另起一张表重算。
AI 应该进入可验证的流程
当 AI 能减少一个具体步骤时，它才真正有价值，例如起草询盘回复、汇总业务数据或辅助市场研究。如果它只是一个与权限、记录和后续动作都没有关系的聊天窗口，价值会很快下降。在 TradeFlow 中，我更希望把 AI 放在业务流旁边，同时让关键写入可审阅、核心规则保持确定。
上线之后学到的事
生产系统与原型带来的经验完全不同。数据迁移前需要备份；一个看似方便的字段，可能已经成为多个模块共同依赖的契约；移动端用户会暴露桌面测试发现不了的交互问题。很多时候，最有效的改进不是再加功能，而是去掉重复请求、缓慢跳转或含义不清的状态。
对我来说，最重要的结果不是做了多少页面，而是真实团队可以使用同一条连贯流程，并且系统能够在不损害数据可信度的前提下继续成长。
最新核查改变了什么
当前完整系统是私有项目，旧公开原型链接已经不能代表它，因此我直接移除了错误入口，而不是继续把读者带到失效仓库。最新服务端测试共 234 项，通过 211 项；剩余 23 项全部集中在一套管理集成测试，暴露的是授权夹具隔离问题。代码审计还确认了原始 SQL 执行、SQL 与参数日志、大型服务模块和较多历史类型债。这些问题不会否定产品价值，但它们清楚定义了下一阶段可靠性路线：查询隔离、日志脱敏、测试确定性和模块边界优先于继续扩张页面。