企业官网建设流程全解析

前阵子收到一个需求，整个文档里只有一样东西：项目标题 rea。正文空白，关键词空白，摘要空白，看上去像是交接时忘了粘贴内容。但这种事在真实工作中一点也不少见——很多项目在正式立项前都只有一个随手起的代号，真正的难点不是代号本身，而是怎么把这个代号翻译成一件能落地、能验收、能上线的产品。

所以我写下这篇复盘。我围绕代号 rea 走完了一遍从需求考古、产品定义、技术选型到开发验收、上线踩坑的完整流程，最终把 rea 做成一个"拍照回收估价工具"。如果你也接过类似只有代号的模糊需求，或者你正准备从零做一个轻量级的识别+报价系统，这篇文章可以直接给你一套可复用的思路和方法。

1. 从 "rea" 三个字母开始：把代号做成需求考古

1.1 代号来源的三类猜测：缩写、词根、还是随手敲的

拿到 rea 之后，我没急着问业务方"你要什么"，而是先做了一个动作：搞清楚这个代号是怎么来的。

绝大多数内部代号逃不出三种来源。第一种是缩写，比如"Resource Estimation App"、"Recovery Export Agent"这类英文短语的取首字母；第二种是词根，像 rea 可能是 ready、reason、realtime 的前半截；第三种最烦人，就是某个人在录入系统时随手敲的几个字母，连他自己都没想好是什么意思。

我们当时听了各种解释之后，团队内部很快收敛到了一个比较合理的猜测：rea 是 Recovery Estimation Automation 的缩写，直译过来是"回收估价自动化"。结合公司当时刚好在探索二手设备回收业务，这个解释在场景上说得通：卖家手里有一台旧手机，想知道它还能卖多少钱，能不能有人上门回收。如果 rea 能自动识别型号、判断成色、给出报价，这个业务就能跑起来。

1.2 代号考古四问：把模糊语境变成可讨论的上下文

猜测只是起点，真正让需求清晰起来的是下面这四个问题。我建议任何一个模糊项目在动手前，都先拉着相关人做一轮这样的"考古访谈"。

第一，这个代号是谁在什么场景下提出的。是产品经理在业务会上随口提的，还是技术负责人为了规划系统取的？提出者的角色往往决定了这个代号的真实含义和优先级。

第二，他想解决谁的什么问题。不要问"你想做什么功能"，要问"你的用户现在哪里疼"。如果最终用户是卖旧设备的小卖家，他们的痛点就是不知道行情、担心被压价、嫌上门流程麻烦；如果是回收商，痛点就是估价靠人工、效率低、标准不统一。

第三，这个需求出现的上下文里有没有零散的信息。哪怕只有三言两语也好，任何蛛丝马迹都算。比如"最近二手手机交易量大"，这就够我们推测 rea 至少要能识别手机。

第四，如果什么都不做会怎样。这个问题特别能逼出真实需求。如果答案是"无非慢一点，也能做"，那 rea 就不是核心系统，不值得投入大成本；如果答案是"人工估价一天只能处理几十单，业务根本起不来"，那自动化就是刚需。

1.3 把猜测写成一句可验证的愿景

考古结束以后，我在白板上写下了一句话：

用户用手机拍下一台旧设备，rea 在 10 秒内自动识别品牌型号、判断外观成色，并给出一个可成交的回收报价区间。

这句话看起来很朴素，但它是整个项目的锚点。它明确了对象（旧设备）、动作（拍照识别+成色判断+报价）、指标（10秒内）、输出（可成交的报价区间）。后面所有需求评审、技术选型、验收标准，都可以拿这句话来对答案。如果你也遇到模糊项目，请务必先做这件事：不要急着画原型写代码，先用一句话把项目愿景写下来，然后逼自己在场的人都签一个字。

2. 从"能估一切"砍到"先估手机和平板"：产品边界设计

2.1 用户旅程：先搞清楚一次完整使用长什么样

愿景有了，接下来是画用户旅程。我们当时在纸上画了五个步骤，非常粗糙，但非常有用。

用户打开入口，上传一张设备照片，或者手动输入品牌型号；rea 对照片做识别，先判断是什么品类，再定位具体型号；系统继续判断外观成色，比如屏幕有没有划痕、边框有没有磕碰；随后结合内置的行情数据算出一个报价区间；用户接受报价后，直接生成回收单，预约上门。

这条旅程画完，我们发现一个关键问题：识别和估价并不是一个环节，而是两个完全不同的技术问题。识别解决的是"这是什么、什么成色"，估价解决的是"这个状态现在值多少钱"。很多团队在做这类项目时会把它们混在一起，最后模型既没学好识别，也没法解释价格为什么是这个数。

2.2 功能优先级：把功能分成四类，而不是只分"要"和"不要"

因为代号里的信息太少，我们一开始收到的需求非常膨胀：有人要支持所有电子产品，有人要接入多家比价平台，有人要做社区闲鱼功能，还有人希望用户上传视频来检测屏幕是否原装。这些想法单看都有道理，但如果全做，项目半年都上不了线。

我们用一张优先级表把需求全部过了一遍。表格的思路供你参考，每一行写清功能、理由和投入成本。

事后复盘，这张表最大的价值不是把功能排了序，而是让所有人都能看到"不做什么"。模糊需求最大的风险就是什么都想要，如果不能主动砍边界，技术团队一定会被各种边缘功能拖死。

2.3 用"不做清单"给团队安全感

很多人不敢砍需求，是怕业务方觉得你在偷懒。我的经验是：砍需求的底气不来自沟通技巧，来自一份白纸黑字的"不做清单"。

我们当时明确写下了三件事：rea 不打算成为闲置交易平台，不直接对接第三方拍卖渠道，不做复杂的真伪鉴定。这些边界写进文档后，业务方不但没有反对，反而更放心了，因为他们知道团队没有雄心勃勃去造一个怪物，而是认真打磨一条主路径。

砍完边界之后，团队每个人都能背出 P0 的三件事：识别、成色、报价。这也成了后面每天站会检查的唯一目标。

3. 技术架构与核心实现思路：识别和处理分开，价格规则化

3.1 技术选型：为什么选"分类模型+规则引擎"，而不是端到端大模型

这是 rea 项目里我做的最关键的一个决策：不训练一个端到端的"图片进、价格出"的大模型，而是把流程拆成"识别模块"和"估价规则引擎"两个独立部分。

原因有三条。第一，端到端的定价模型需要大量"图片+成交价"的标注数据，我们当时能拿到的真实成交数据非常有限，强行训练只会得到一个解释不了、也不敢上线的大黑盒。第二，回收估价本身高度依赖行情变动，同一个型号同一个成色，上个月的价和这个月可能差出好几百，如果价格写在模型参数里，每次调价都要重新训练，完全不可持续。第三，业务上我们必须要能说清楚"为什么给这个价"，用户如果问起报价依据，我们需要给出"参考行情+成色系数"的白盒计算逻辑，而不是一句"AI算出来的"。

所以最终方案是：图像分类模型负责把品类、型号、成色识别出来，价格计算完全交给一段规则代码。识别是概率问题，可以用模型；价格是业务逻辑，必须用规则。把两者混在一起是这类系统最容易犯的错误。

3.2 三个核心模块与数据流

rea 在架构上只有三个模块，但每个模块都是独立可替换的。

输入接入模块负责接收图片、裁剪、压缩、纠偏，并调用识别模型；识别与估价模块是核心，内部跑一次分类模型得到品类型号，再接一个成色分类模型得到四档成色，然后把结果送到估价引擎；输出模块负责把报价区间、计算依据、回收单信息组装起来返回给前端。

数据流的顺序我也建议固定为：图片清洗先行、识别其次、估价最后。尤其图片清洗容易被忽略。实际测试中，很多用户上传的照片是反光的、模糊的、甚至带着手指头，如果不做预处理，模型准确率会掉得一塌糊涂。我们后来加了基础的旋转纠正、亮度归一化和画质过滤，整体识别准确率直接提了 7 个百分点。

3.3 数据模型：用代码把订单和报价说清楚

因为输入信息太少，我在设计数据模型时特别在意"可解释"三个字。每一个报价结果都要带上它的判断依据，单个数字没有任何意义。

# 简化版数据模型，用于记录一次估价请求 @dataclass class EstimateRequest: request_id: str image_url: str device_category: str | None # 品类，如 smartphone user_note: str | None # 用户补充，如"屏幕有划痕" @dataclass class ConditionScore: level: str # new / light / obvious / worn confidence: float # 模型置信度 reasons: list[str] # 人为可读的判断依据 @dataclass class PriceRange: low: int high: int reference_price: int # 参考行情价 condition_factor: float # 成色系数 market_factor: float # 行情波动系数 explain: list[str] # 给用户看的报价说明 @dataclass class EstimateResult: request_id: str model_name: str condition: ConditionScore price: PriceRange created_at: str

你可能注意到我特意加了一个 explain 字段。这是为了前端可以直接展示"这台机器参考行情为 3200 元，轻微使用状态按 0.88 系数折算，当前行情波动 0.95，最终建议 2600 至 2800 元"。用户看到这个解释，比看到一个冷冰冰的价格更容易接受，也更容易信任。

3.4 接口设计：一次请求只做一件事

接口我只设计了一个主入口，简单直接，POST /api/v1/estimate。请求只需要带图片地址和可选的用户补充文本，响应返回完整结果。这里放一个接口交互的大致格式，方便你理解整体协议。

// POST /api/v1/estimate { "request_id": "req_a1b2c3", "image_url": "https://example.com/uploads/device.jpg", "user_note": "边框有磕碰" } // 200 OK { "request_id": "req_a1b2c3", "model_name": "iPhone 14 Pro 128GB", "condition": { "level": "obvious", "confidence": 0.87, "reasons": ["屏幕可见明显划痕", "边框有磕碰"] }, "price": { "low": 2600, "high": 2800, "reference_price": 3200, "condition_factor": 0.85, "market_factor": 0.95, "explain": ["参考行情价 3200 元", "明显磨损状态按 0.85 折价", "当前行情波动 0.95", "最终区间为 2600-2800 元"] }, "created_at": "2025-01-12T10:30:00Z" }

一开始接口设计里是没有 explain 的，是我在开发后期主动加进去的。原因是一位测试同事提了一句："如果用户看到价格却没有理由，他一定会来质问人工客服。"这一句话让我意识到，白盒报价不只是技术选择，更是减少客服压力的产品决策。

3.5 估价策略：为什么给区间而不是给一口价

估价引擎的核心逻辑是一个乘数公式：最终报价区间等于参考行情价乘以成色系数再乘以行情波动系数。

计算公式可以写成：

low = round(reference_price × condition_factor × market_factor × 0.95) high = round(reference_price × condition_factor × market_factor × 1.05)

成色系数按四档设定：全新状态在 0.95 到 1.0 之间，轻微使用在 0.88 到 0.94 之间，明显磨损在 0.75 到 0.87 之间，严重损坏则低于 0.75。行情波动系数在前一天基础上计算，最新报价数据每小时同步一次。

给区间而不是一口价，是我的刻意设计。回收行业本来就存在同一台机器不同渠道报价不同的情况，一口价反而会让用户拿着系统报价去别家比，成交率并不高。区间报价既符合现实，又留给了线下回收人员一定的灵活空间，这是从业务侧倒推回来的技术参数。

4. 开发与验收：一半精力在模型之外的数据治理上

4.1 数据准备：干净数据是这类项目的生死线

很多人听到"识别模型"就兴奋，觉得这是整个项目最有技术含量的部分。实际做下来我发现，rea 项目 60% 以上的工作根本不是调模型，而是处理数据。

第一块是图片采集。我们当时从合作渠道收集了几千张真实二手设备照片，覆盖不同光线、不同背景、不同拍摄角度。真实数据比网上的商品图难处理得多，但这恰恰是上线后真正会遇到的场景。

第二块是图片脱敏和清洗。用户上传的照片里频繁出现快递单、手持身份证边缘、特征明显的家庭背景，这些内容虽然不影响识别，但涉及隐私，必须在入库前处理掉。我们还发现不少照片是二次截图，分辨率低、压缩痕迹明显，这类图片训练出来的模型在真实场景里会严重水土不服。

第三块是类别均衡。手机型号的数量分布非常不均，热门型号可能有几百张图，冷门型号可能只有个位数。如果不做重采样和增强，模型会对常见型号过拟合，冷门型号识别率趋近于零。我们后来采用了对少数类做简单重复采样、对多数类做随机擦除的方式，才把冷门型号的识别率从不到 40% 拉到了 70% 以上。

4.2 成色标准：不能靠标注师的主观感觉

成色判断是 rea 被质疑最多的地方。为什么相同的磨损程度，一个标注师给的是"轻微使用"，另一个给的是"明显磨损"？如果标注本身不稳定，模型学到的就是随机噪声。

我们的解决办法是：先定标准，再做标注。我把四档成色分别配上 12 张真实示例照片，每个档位拆成四个维度：屏幕、边框、背板、摄像头区域，每个维度写清楚什么程度算哪一档。标注之前，每个参与的人先做一轮标定测试，准确率达到 90% 以上才允许正式标注。这个过程看起来很笨，但对项目质量的提升是决定性的。

标准定好之后，模型输出的成色就不再是一个拍脑袋的标签，而是"基于可见划痕数量、磕碰面积、反光区域面积"得出的可复核结论。

4.3 验收指标：不要只盯准确率

如果只用一个指标来验收 rea，我一定选"报价可用率"，而不是模型准确率。

报价可用率的定义是：用户接受报价并发起回收单的比例。这个指标同时压测了识别准确率、成色判断合理性、价格区间设置和前端体验。识别错了肯定没人下单，价格区间离谱也肯定没人下单，成色判断太苛刻同样会劝退用户。

当时我们定的验收标准分三层，如下表所示。

这套指标最大的好处是让所有人知道：识别模型即使偶尔出错，只要报价可用率达标，系统就是可用的；反过来，如果准确率很好看但用户不买单，那也不过是自嗨。项目验收的时候，我们把业务层指标放在最上面，技术指标成为支撑而不是目标。

5. 上线之后踩过的三个坑：真实流量才是最好的测试

5.1 坑一：型号别名导致识别错乱

上线第一天，我们就发现了一个识别模型在测试集上根本暴露不了的问题：用户的输入里充满了别名。

有人把 iPhone 14 Pro Max 写成"苹果14pm"，有人写"14pro max港版"，还有人直接把商品标题粘贴进备注框，写着一长串"全新未拆封国行暗紫 256G 未激活"。这些别名对规则系统来说完全没有规律，导致部分请求被识别成了错误型号，报价也跟着错。

这个坑的根因是我把"型号识别"完全交给了模型，忽略了业务系统里应该有一张映射表。排查过程很有意思：我们拉出错误样本后发现，同一个型号在系统里被匹配出三种不同结果。随后我们加了一个"别名归一化"的预处理层，把常见别名、区域版本、颜色描述先做清洗，再进模型。修复之后，型号识别的准确率从 82% 提到了 91%。

提示：这类问题靠模型是解决不了的，必须用业务规则去兜底。凡是高频、有明确规则的输入，都应该在模型之前先用规则消耗掉。

5.2 坑二：反光照片把成色判断彻底带偏

第二个坑出现在成色模块。模型在训练集上表现不错，但真实用户特别喜欢在窗边、白墙前、灯光下拍照，玻璃屏幕反光严重。模型看到一片白花花的高光，直接判定为"严重磨损"，给出一堆低到离谱的报价。

用户当然不接受，反馈里充满了"明明是刚买的手机"这类的投诉。我们排查后发现模型并不是"笨"，而是反光区域确实模拟了磨损特征。修复办法分成两步：一是在图片预处理里增加高光检测，把反光区域识别出来并做去高光处理；二是在前端拍摄引导里加上"请避免反光"的提示与示例图。仅靠算法不行，还要引导用户把照片拍好，这类问题必须前后端共同解决。

5.3 坑三：一次弱网下的并发把服务彻底打爆

上线后的第三周，某天晚上我们收到大量超时告警。原因是回收业务做了一波推广，流量是平时的十倍，而估价服务里的模型推理进程全是单线程串行处理，图片上传还有一张张读满内存。请求一旦密集，内存和 GPU 直接打满，服务失去响应。

排查链路是这样的：先看到网关层延迟飙升，再定位到模型服务线程堆积，最后发现图片解码过程吃掉了大量 CPU。修复动作有三个：给图片上传加大小和分辨率限制；把模型推理改成批量异步队列；对单用户加限流，一分钟内最多估价 10 次。

上线后踩坑是没法完全避免的，但可以缩短修复时间。我后来把这三个坑都写进了一页纸的"上线检查清单"，每次发布前逐项检查一遍，后续这类系统性事故明显少了。

6. 如果现在重新做一个类似的"rea"项目

6.1 时间与成本：一个最小可用版本实际要花多少钱

很多小团队来问复现 rea 需要多少预算，这里给一个真实的估算口径，按三个人开发三个月计算。

如果只做手机品类，开源模型完全够用，不需要采购商业视觉服务。最大成本不在算法，而在数据清洗和标注标准统一上，这一点建议预算分配时真心实意地多给一些。

6.2 精力分配：识别、规则、体验的比例

再让我做一次，我会按 3:3:4 的比例分配精力。

30% 给识别模型。重点是数据清洗、标注、抽样和验证，而不是试各种新网络结构，因为真正拖后腿的几乎都是数据问题。30% 给估价规则。行情源要稳定，成色系数要经过真实成交回测，规则代码要写清楚注释，这块决定系统长期能不能用。剩下 40% 给交互体验。拍摄引导、加载状态、报价解释文案、异常兜底，这些看起来不性感，但用户最终感受到的 rea 就是由它们构成的。

技术圈容易把项目的成败押在模型上，我做完 rea 最大的体会恰好相反：模型只要"够用"就行，规则和体验才是用户能感知到的全部。

6.3 三个可以复用到下一个项目的小技巧

最后分享三个顺手就能用到别的项目上的技巧。

第一个技巧是保留代号历史。我们在代码仓库里建了一个 docs/codename.md，专门记录 rea 这个名字的来历、每次需求讨论的结论、以及我们砍掉过哪些功能。三个月后团队再回头看，很多人已经忘了当初为什么做某个决策，这份文档就是最好的解释。

第二个技巧是需求确认别用会议纪要，用"一句话愿景+不做清单"。这两个东西同时出现，才算一次真正明确的需求确认。否则讨论到后面，你永远不知道对方脑中的 rea 和你脑中的 rea 是不是同一个东西。

第三个技巧是上线前把"型号别名表"、"高光检测规则"、"限流阈值"这类边角能力写进检查单。这些能力单个看都很小，但缺了任何一个，线上都会以很难看的方式教育你。提前写下来，就像给自己的未来留一份保险。

如果你手头也有一个只有代号的模糊需求，别急着想办法套方案。先花一整天做考古，把代号变成一句话愿景，再把它拆成能验证的功能边界。大部分所谓的不确定，其实只是还没被翻译成工程语言而已。