用 Flutter 做一本"业务之书"：把二手手机行业理解沉淀成可阅读的产品
当一个行业足够复杂，最好的知识沉淀方式不是堆文档，而是写一本书。
引言：从资料堆到业务之书
做业务分析久了，总会遇到一个问题：分析成果怎么沉淀？
Excel 表格、流程图、接口文档、源码分析报告……资料越来越多，但真正能让人理解业务的却很少。新同事入职，面对几十份文档，不知道从何看起；老员工离职，带走的是脑子里的业务理解，留下的是散落在各处的碎片。
我在做二手手机回收业务分析时，也遇到了这个问题。分析了一百多个业务节点，梳理了几十万字的源码证据，但始终觉得缺点什么——缺一个能让业务理解”活”起来的载体。
于是，我做了一个尝试：用 Flutter 写了一个桌面应用，把业务分析成果做成了一本可以阅读的”业务之书”。
这个项目从 8 月开始构思，9 月初基本完成。现在写这篇博客，是对这个项目的回顾和总结。
核心理念：像书一样阅读业务
1. 不是资料检索，是阅读路径
传统知识库的思路是”搜索”：输入关键词，返回相关文档。但业务理解不是这样工作的。
当你想理解”估价线索”这个业务节点时，你不只是想看到一篇文档，你想知道：
- 它在整个回收链路中的位置
- 它解决什么问题
- 谁参与、对象是什么、状态怎么流转
- 它和上下游的关系
这些问题，不是一篇文档能回答的，而是一本书的章节结构才能说清楚。
所以”业务之书”的主阅读路径是：
1 | 左侧目录 → 业务节点 → 节点下文章 → 右侧正文 |
资料检索只做辅助，不作为主要阅读入口。
2. 节点名 = 业务大纲
传统文档分类喜欢用”用户模块””订单模块”这种技术视角。但业务之书不同，它的节点名直接表达业务链路中的位置：
- R-01 估价线索
- R-02 创建回收订单
- R-03 流程配置分流
- R-04 回收报价定价
- R-05 确认议价退回
- R-06 履约收货
- R-07 检测质检
- R-08 打款结算
- R-09 入库转销售
看到这些节点名，你就知道一笔回收交易是怎么一步步走完的。这不是文档分类，这是业务地图。
3. 业务与技术分层
这是”业务之书”最重要的设计之一。
每篇文章都有对应的”技术证据”，但技术证据不参与主阅读流。正文用业务语言讲运作：角色、对象、动作、状态、钱流、货流、库存、售后、清结算。技术证据放在底层，记录源码入口、接口、表名、字段、状态枚举，用来校准业务结论。
这样做的好处是：
- 业务人员可以只看正文，理解业务运作
- 技术人员可以深入证据层，核对实现细节
- 新人可以先读正文建立全局观，再按需深入
正文和技术证据的关系，就像地图和卫星图：地图告诉你路怎么走，卫星图告诉你地形是什么样的。
4. 去品牌化，沉淀行业理解
分析时尽量避开具体公司名，把内容沉淀成对二手手机行业的业务理解。品牌名只作为证据来源、历史材料或对标案例出现。
这样做有两个好处：
- 内容可以跨公司复用，不绑定特定业务
- 思考的是”行业应该怎么做”，而不是”某公司怎么做的”
内容结构：23 个节点，构建完整业务地图
“业务之书”当前包含 8 个业务分类，23 个核心节点：
上篇：国内回收业务
回收业务是最核心的业务线，包含 9 个节点：
- 估价线索：用户正式卖机前，平台如何把一次询价行为沉淀成可转化的线索
- 创建回收订单：从线索到订单，用户做出卖机决定的那一刻
- 流程配置分流：不同机型、渠道、成色如何走不同的回收流程
- 回收报价定价：估价价如何产生，如何随市场波动
- 确认议价退回：用户对报价不满意时，如何议价或退回
- 履约收货：用户寄出机器后，平台如何收货、验货
- 检测质检：收货后如何检测，检测结果如何影响价格
- 打款结算：检测完成后，如何给用户打款
- 入库转销售：回收的机器如何进入销售环节
下篇：国内销售业务
销售业务同样包含 9 个节点：
- 回收入库：回收机器进入库存
- 库存商品化：库存机器如何变成可售商品
- 上架销售：商品如何上架到各销售渠道
- 门店商城成交：用户在门店或商城下单购买
- 买家报价竞价：B2B 场景下，买家如何报价竞拍
- 标准销售出库：订单确认后如何出库发货
- 买家收货履约：买家收到机器后的确认流程
- 销售售后退换：售后问题如何处理
- 销售清结算：销售款项如何清算
附篇：支撑能力
除了回收和销售两条主线，还有 5 个支撑节点：
- 定价报价：定价策略和报价算法
- 运营增长：用户增长和运营策略
- 技术架构：系统架构和技术选型
- 海外与硬件：海外业务和硬件检测
- 行业策略：行业趋势和商业模式
每个节点都包含两篇文章：
- 业务模型：讲业务运作，用连续段落叙述
- 技术证据：讲结论依据，记录源码和数据库证据
技术实现：Flutter 桌面应用
为什么选择 Flutter？
做这个应用时，我考虑过几个方案：
- 静态网站：简单，但阅读体验不够好
- Electron：跨平台，但太重
- 原生 macOS 应用：体验好，但开发成本高
- Flutter：跨平台、轻量、UI 表现力强
最终选择 Flutter，主要因为：
- 一套代码，多端运行：macOS、Windows、Linux 都能跑
- UI 表现力强：可以实现复杂的阅读布局和交互
- 开发效率高：热重载、Widget 复用，迭代快
- 性能好：编译成原生代码，启动快、内存占用小
技术架构
应用采用单文件多 part 的结构：
1 | // main.dart |
这种结构的好处是：
- 逻辑清晰，每个 part 负责一个功能模块
- 共享状态方便，不需要复杂的依赖注入
- 代码量不大时，维护成本低
核心功能
阅读体验：
- 阅读进度自动保存
- 自动滚动（慢、中、快三档）
- 字号和阅读宽度可调
- 键盘快捷键（↑/↓ 滚动、Page Up/Down 翻页、←/→ 切换章节）
内容组织：
- 左侧目录按业务节点展开
- 节点页显示业务说明和阅读重点
- 文章按阅读顺序排列
- 技术证据固定在节点最后
搜索与定位：
- 辅助关键词搜索
- 节点悬停显示业务简介
- 点击书名回到总纲
写作挑战：让业务文章像书一样
做这个应用最难的不是技术，而是写作。
1. 从分析报告到业务叙述
技术分析习惯写：”这个接口返回 status 字段，0 表示待处理，1 表示已完成。”
但业务之书要求写：”当一台机器被检测完成后，它的状态从’待检测’变成’已检测’，这意味着平台可以开始给用户打款了。”
同样的信息，前者是技术文档，后者是业务叙述。业务叙述要回答：这个动作解决了什么问题？对人和交易意味着什么？
2. 从碎片到体系
源码分析是碎片化的：今天分析估价接口，明天分析支付逻辑。但业务之书要求把这些碎片组织成体系：一笔回收交易从头到尾是怎么走完的？每个环节解决了什么问题？
这需要反复梳理、不断调整。有时候写完一篇文章，发现它应该属于另一个节点；有时候发现两个节点之间有重叠，需要重新划分边界。
3. 从具体到抽象
分析时很容易陷入具体公司的实现细节：”闪回收的估价接口调用的是 /api/quote/v2。”
但业务之书要求抽象出行业通用的业务逻辑：”估价接口的核心是收集机器信息、计算参考价格、记录用户意向。”
这种抽象不是忽略细节，而是把细节放在技术证据层，正文只讲业务运作。
效果与反思
效果
这个应用目前包含：
- 23 个业务节点
- 23 篇业务模型文章
- 23 篇技术证据文章
- 总计约 10 万字
它的价值在于：
- 新人入职：14 天学习作答计划，快速建立业务全局观
- 业务讨论：有了统一的业务语言和参考框架
- 知识沉淀：业务理解不再依赖个人记忆，而是沉淀成产品
反思
做得好的地方：
- 业务与技术分层，让不同角色各取所需
- 以业务节点为大纲，阅读路径清晰
- 像书一样叙述，比文档更容易理解
可以改进的地方：
- 内容更新成本高，每次业务变更都要同步更新文章
- 缺少版本管理，无法追溯业务演进历史
- 没有协作功能，多人维护时容易冲突
未来方向
1. 内容动态化
当前内容是内置的 Markdown 文件，更新需要重新打包。未来可以考虑：
- 从远程加载内容
- 支持增量更新
- 版本管理和回滚
2. 协作与评论
业务理解不是一个人的事。未来可以加入：
- 多人协作编辑
- 文章评论和讨论
- 业务变更通知
3. 智能辅助
AI 可以帮助：
- 自动生成业务模型初稿
- 从源码自动提取技术证据
- 智能问答，解答业务疑问
写在最后
“业务之书”的尝试，本质上是在回答一个问题：当行业足够复杂，最好的知识沉淀方式是什么？
我的答案是：不是文档，不是 Wiki，而是一本书。
书有章节、有结构、有叙述、有重点。它不是碎片的堆砌，而是体系的构建。当你读完一本书，你得到的不是零散的知识点，而是一个完整的认知框架。
用 Flutter 做这个应用，不是为了炫技，而是为了让这个”书”的载体更好用。Flutter 的跨平台能力、UI 表现力、开发效率，让它成为实现这个想法的合适选择。
如果你也在做业务分析，也在思考如何沉淀业务理解，不妨试试这个思路：把分析成果做成一本书。
项目信息
- 项目名称：二手行业业务之书
- 技术栈：Flutter (macOS)
- 内容规模：23 个业务节点，46 篇文章
- 版本：1.1.0
本文首发于 David’s Blog，转载请注明出处。