源码商城卖的是「已经做完的东西」，需求墙接的是「还没做的东西」。买家把类目、预算、周期、技术栈写清楚，系统按四维算匹配度，把需求推给能接的开发者；开发者报「价格 + 周期 + 方案」，买家逐份比完再选一个人开工。
| 维度 | 权重 | 怎么算 |
|---|---|---|
| 类目 | 35 | 需求类目与开发者主攻类目一致得满分；相近类目按跨度递减 |
| 技术栈 | 25 | 需求列的技术栈被开发者覆盖的比例，覆盖越多分越高 |
| 预算 | 20 | 落在开发者历史成交区间内得满分；过低扣分，过高不额外加分 |
| 周期 | 20 | 工期与开发者当前负载匹配度；排期满的开发者会被压分 |
匹配度只决定「谁能先看到」，不决定「谁中标」——选谁由买家自己定，报价低不等于拿走。
| 字段 | 要求 |
|---|---|
| 标题 | 一句话说清做什么，不写「求大神」 |
| 类目 | 电商 / SaaS / 知识库 / 小程序 / 组件库 / 其它，决定推给谁 |
| 预算 | 给区间或上限；写「面议」的投标质量明显更差 |
| 周期 | 期望交付天数，用来算匹配度与违约口径 |
| 技术栈 | 必须用什么、可以用什么，写清楚少返工 |
| 说明 | 验收标准、已有素材、上线时间、是否要交付源码 |
需求编号 PZ-DM-YYMMDD-XXXX，投标编号 PZ-QT-YYMMDD-XXXX。
| 步骤 | 发生什么 | 谁确认 |
|---|---|---|
| 01 发布 | 六项校验通过后上墙，按匹配度推给开发者；同时开一条需求会话 | 买家 |
| 02 投标 | 开发者交「报价 + 周期 + 方案」，可改价，每次改动都进会话留痕 | 开发者 |
| 03 比稿 | 买家在需求卡里逐份对照报价与方案，看得见谁改过价 | 买家 |
| 04 选定 | 选一份转「已选定」，需求会话记下选了谁、多少钱、多少天 | 买家 |
12 家门店、线上下单门店自提，要接现有 ERP 库存；预算 ¥15,000，35 天，技术栈不限但必须交付源码。
现有知识库要加订阅套餐、按量计费与开票入口；预算 ¥8,000，20 天，要求 Java 或 Node。
现有后台 5 万行表格卡顿，要换虚拟滚动并保留筛选与导出；预算 ¥3,000，7 天。
需求墙做的是撮合与留痕：需求、报价、选定、沟通记录都在站内，事后能导出对账。做不到的也写在这里——平台不代收项目款、不做验收仲裁、不审核开发者资质等级（那要服务端与实名库）；需求一旦成交，付款与验收请沿用订单与交付回执那套流程，别在站外转账。
