从一次「定价犹豫」说起
假设你是一家软件服务商的运营同学，手里有一套已经打磨成熟的扫码点餐系统。你要把它放到应用市场上去卖，此时你面前站着两个买家：一个是连锁餐饮老板，明确要买成品，今天就要上线；另一个是本地商超负责人，想做一个会员积分小程序，但需求还很模糊，连要不要打通收银系统都说不准。
同一件商品，面对两种买家，该标价，还是不该标价？
这个看似简单的选择，恰恰是整个应用市场项目里最核心的产品设计之一：价格态。它决定了买家看到的是「立即购买」还是「立即咨询」，也决定了商家后续的全部作业——是回询盘、聊需求，还是发源码、交付订单。本文不展开讲某个按钮或某个字段，而是围绕这条「上架—审核—成交—交付」的主链路，讲清楚这个项目为什么这样设计，以及它如何闭环。
项目定位：不是又一个商品货架
应用市场这个项目，从第一天起就没有把自己定位成“软件版的淘宝”。如果只是把软件源码挂上去标个价，那它和一堆网盘链接没有区别。真正的难点在于：软件交付不是一个瞬间动作，而是一条服务链。买家买的不是一个文件，而是一个能跑起来的业务结果。
因此，项目把商品分成了三种售卖方式，官方叫法是「价格态」：
- 未定价（inquiry）：买家看不到价格，主按钮是「立即咨询」。适合定制类、需求不明确的企业服务。商家的主作业是回复询盘，谈工期、谈范围、再约演示。
- 标价（priced）：明码标价，主按钮是「立即购买」。适合标准化程度高的框架应用、独立软件，买家付费后生成订单，商家按交付说明发货。
- 免费（free）：买家登录后直接获取，商家维护版本和说明，一般无收款。适合引流款、试用版、主题模板。
这个设计的出发点很朴素：把“能不能直接卖”这个判断，从平台审核前置到商家上架时自己选。 商家最懂自己的商品是标准品还是定制服务。平台不做一刀切，而是给出三种明确的价格态规则，让商品以合适的姿态进入市场。
围绕价格态，还配了一条硬性约束：改价格态或改价后，必须重新提交审核。 这不是为了增加操作成本，而是防止商品在“免费”和“标价”之间反复横跳，损害买家信任，也防止商家把未定价商品标成 0 元冒充免费，扰乱货架秩序。
核心场景：一个非标定制项目的完整旅程
我们用一个贯穿全文的场景来理解整个项目。
某天，一家区域连锁超市的负责人通过官网浏览，在一件「企业服务—会员数字化方案」商品上点了「立即咨询」。他留了手机号，提出了自己的需求：想做会员积分系统，但不确定是否需要对接已有的 ERP，也不确定预算。
这个动作，在商家工作台端触发了一条「待回复询盘」。醒目地展示在四项核心指标的第一位。
商家运营同学点进询盘详情，看到三件事：买家原文、联系方式、这件商品的只读卡片。详情页刻意把商品卡做成只读，目的是让商家在回复时始终记得——买家是从哪件商品来的，咨询的是哪件商品。询盘绑定商品和店铺，回复时不能改绑、不能把单子转到别的店。
在咨询时段内，商家回复了工期预估、是否能含 ERP 对接模块、是否要再约一次演示。买家在「我的咨询」里看到回复。此刻双方还处于「聊」的状态，没有订单产生。只有当后续改价上架并经平台审核通过，买家才会真正下单，这笔询盘才可能转化为一笔标价订单。
接下来的故事顺理成章。商家提交了一个带有明确价格的方案版本，平台审核通过后，买家完成支付。工作台「待交付订单」指标 +1。商家按商品类型填写交付说明，标记「交付中」，买家可见进度；源码包或服务工单交付完成后，商家标记「已交付」。至此，一个从咨询到交付的业务闭环才真正走完。
这个场景说明了项目的关键判断：询盘和订单是两件事，绝不能混为一谈。 询盘是需求确认过程，订单是交易承诺结果。如果系统一上来就逼着买家下单，非标服务压根谈不拢；如果系统不区分两者，商家就会在“聊需求”和“发货”之间手忙脚乱。价格态的价值，就是在这两者之间搭了一座桥——买家选择咨询，承接的是需求沟通；买家选择购买，承接的是交付履约。
工作台：不是菜单堆叠，而是经营仪表盘
当商家登录工作台，第一眼看到的是什么？四项指标：
- 待回复询盘：本店状态为“open”的咨询单
- 待交付订单：本店已支付或交付中的订单
- 待答问答：本店未回复的商品提问
- 在架商品：本店已通过审核、正在展示的商品
每一项都能点进去查看列表。这个设计刻意避开了复杂的菜单层级，把商家每天最需要关心的四件事直接放到首页首屏。一个做软件生意的小团队，不需要后台运营那样的全平台视角，只需要知道：今天有没有人要回、有没有货要发、有没有问题要答、店里摆了什么。
下方三块列表各展示不超过 5 条：最近待回复询盘（买家称呼、商品名、时间）、待交付订单（单号、商品、金额、状态）、本店热度较高的在架商品（标题、价格态、热度）。空态文案写成「本店暂无待办」，而不是「欢迎使用」——前者是业务语言，后者是营销套话。
从产品视角看，工作台的四个指标本质上对应着商家经营的四种“未完成事件”。系统不替商家做决策，但要把待办事项最短路径地推到他眼前。 这也是整个项目的交互设计原则：所有列表只出现本店数据，当前店铺与登录身份分开存储。商家只能看到自己的店，这一条从数据权限上就锁死了。
审核流：平台信任的守门员
当商家编辑完商品，点了「提交审核」，这条商品就进入了平台的审核管道。审核通过后，工作台「在架商品」加 1，买家端可见；被驳回则在消息中看到原因，改完再提。
这个流程看起来常规，但其中有三处设计值得注意。
第一，新商品或改价后，审核是强制卡点。 商品创建后、改价格态或改价后，状态回到「待审」。买家不可见。这意味着商家不能用“先低价上架吸引流量，再调高价”的套路，也不能用“先标低价促成咨询，再私下改价”的方式绕开平台规则。
第二，审核只看平台规则，不替商家做经营决策。 平台运营可以看全平台单据，但不替商家点「上架」。审核通过不代表平台保证商品质量，而是确认这条商品在类目、价格态、定价规则上符合平台秩序。商家仍然要自己面对市场的选择。
第三，驳回原因通过消息触达。 商家不需要在列表里猜“怎么突然不见了”，系统把原因直接推送到消息中心，改完再提。这降低了商家的理解成本，也提高了全平台的商品合规率。
审核流的意义，不只是“把关”，更是为价格态这个核心设计兜底。没有审核，价格态就会被滥用；有了审核，三种价格态才能真正成为一种可信的市场秩序。
明确范围取舍：什么不做，比做什么更重要
每个项目都要回答“做什么”，但真正体现产品成熟度的，是“不做什么”的边界。
这个项目至少在三个地方做了清晰的取舍。
第一，不做切店。 一期演示固定当前店铺，不提供切换功能。虽然技术上经营上下文与登录身份是分离存储的，但一期刻意只开放单店模式。原因是：切店带来的数据隔离复杂度会显著拉高测试和验收成本，而一期合作商的真实使用场景就是“一个店管到底”。等有真实多店需求时再开放切店，并且届时会阻断未保存的商品表单和进行中的询盘回复，确保不破坏已有订单归属。
第二，不替平台审核。 商家端没有任何“审他店”“改类目/排行/资讯”“替平台审核入驻”的入口。所有平台运营动作只发生在后台。页面底栏和操作菜单里没有这些入口，不给商家任何越权的可能性。
第三，不开放买家看不到的中间态。 比如未定价商品不生成订单、询盘不能直接转订单除非重新走审核、买家看不到他店的询盘回复草稿。这些约束的目的是保持买家视角的确定性——买家看到什么状态，系统就真的处于什么状态。
项目价值总结：一套可持续演进的货架规则
回到文章开头的那个场景。扫码点餐系统这件商品，如果标价，意味着你要承诺标准化的交付内容；如果不标价，意味着你要准备好应对各种定制咨询。价格态的选择，本质上是商家对自己服务能力的诚实评估。
整个应用市场项目最核心的产出，不是一堆页面和接口，而是一套让标准化商品和定制化服务在同一货架上和平共处的规则。三种价格态定义清楚了商品的售卖方式，审核流保障了规则的执行，工作台把经营待办可视化，数据隔离保护了商家的独立经营权。这套设计让平台可以逐步验证：哪些价格态的商品成交率更高、哪些类目更适合询盘转订单、哪些行业的标准品密度足以支撑标价售卖。
下一步的迭代方向也清晰可见：当询盘量上升时，可以考虑询盘分配策略和更细分的咨询标签；当订单量上升时，可以引入交付时效承诺和商家评分体系；当免费商品积累足够多时，可以设计免费转付费的引导链路。但这一切都建立在价格态这个地基之上——它先解决了“商品以什么姿态进入市场”的问题。
软件交易的本质是信任。而信任，从规则清晰开始。
