2026 年 11 月 2 日：我写了一份 16 章的企业级 CRM 规划方案，写得很细，但它终究只是一份文档。于是我亲手把它设计、搭建成了一个能点、能切主题、手机端也能预览的在线原型，再对着规划原文一页一页做验收。这篇文章是一次完整的复盘：为什么做、怎么规划、关键设计怎么取舍、开发怎么分批推进、验收时抓到了哪些问题，以及我从中得到的几条判断。
👉 在线体验：https://feiw3440-cell.github.io/crm-prototype/（建议用电脑打开；手机端预览入口在地址后加
#/mobile）📌 文中的客户、公司和人名（“南京某某科技”“张三”等）都是演示用的虚构数据。
一、起因：规划写得再细，点不动就不算数
CRM 是一个很容易“看起来都对”的东西。客户、线索、商机、合同、回款，每个词都熟，列一张模块表、画几张流程图并不难。但真正的问题往往藏在页面和页面之间：线索转化时客户重复了怎么办？报价改了价格，已经批过的版本怎么处理？漏斗上写的百分比，到底是什么意思？
这些问题只写在文档里，很难被发现；做成一个能点的东西，它们会自己冒出来。
所以我给自己定了一个目标：不只是保存一份规划，而是把它做成一个可以点开、可以走流程、可以被检查的原型，并且做完之后，逐页对照规划原文验收。
我写的这份规划方案有 16 章，从产品定位、功能架构、权限、页面设计、业务流程、审批、数据设计，到移动端、异常场景、实施计划和验收标准，都有。它开头就定下了一个判断：
CRM 不只是客户资料管理工具，而是覆盖从获取客户，到销售成交，再到订单交付、客户服务和持续复购的完整业务系统。
我把这句话当成这次原型的“验收口径”：只做一个客户列表加几张图表的展示型后台，不算完成。
二、先看全局：6 个经营问题、15 个模块、一条主线
1. 从问题出发，而不是从功能出发
规划方案一开始就列了 6 个系统最终要回答的经营问题。我觉得这是整份方案里最值钱的一页，因为后面每个模块都能追问：它在回答哪个问题？
- 客户从哪里来？线索是否及时处理？
- 客户由谁负责？客户信息是否完整？
- 销售进展到哪一步？下一步应该做什么？
- 哪些商机可能成交？销售业绩能否预测？
- 合同、订单、回款和交付是否顺畅？
- 哪些客户需要维护？如何提高续费率与复购率？
注意第 4 条：“销售业绩能否预测”。后面“赢率”的故事，就出在这里。
2. 15 个一级模块
规划方案 4.1 的左侧导航一共 15 个一级模块：工作台、线索管理、客户管理、联系人管理、商机管理、产品管理、报价管理、合同管理、订单管理、回款管理、活动管理、交付管理、服务管理、数据分析、系统管理。
另外有两项能力不单独占一个菜单，而是贯穿所有模块：审批中心（第七章）和移动端（第十一章）。
3. 一条主线：从线索到复购
规划方案第十六章把最关键的业务链路总结成一句话：
线索 → 客户 → 联系人 → 商机 → 报价 → 合同 → 订单 → 回款 → 交付 → 售后 → 续费复购
我把它画成了一张流程图，并在每个节点下面标了这一步“最关键的控制规则”：
这张图我一直放在手边，因为它帮我回答了一个很实用的问题：页面做得对不对，看它有没有把上一步的结果带进来、把下一步的入口放出去。
举几个这条线上的规则（都来自规划原文）：
- 线索：录入后要查重（手机号、公司名参与重复检测）；转化时先检查客户是否已存在，存在就关联，不重复建；转化后要保留原始线索和跟进历史。
- 客户：有保护期；超期没有有效互动，会先发回收提醒，满足规则才释放到公海；已签约、正在履约、有未处理投诉的客户不自动释放；释放和再次领取都不能删除历史跟进、合同和订单。
- 商机：初步接触、需求确认、方案沟通、报价谈判、商务审批，最后赢单或输单；每次变更阶段都要留下变更前后阶段、变更人、变更时间和备注；禁止直接标记赢单，必须满足成交条件。
- 报价：按版本管理；折扣超出授权要逐级审批；通过后锁定已审批版本，改价格要生成新版本或重新审批。
- 回款：按回款计划登记实际收款，支持分批收款、部分核销，逾期要提醒。
线索详情页上，“重复提示”和“转化客户 / 商机”按钮就是这条规则的落点：转化前先看到可能重复的线索，再决定关联还是新建。
回款页则把计划回款和实际到账放在同一张表里，逾期的行直接标红：
4. 怎么排优先级
规划方案对“先做什么”给了两套说法。第十三章把开发分成四期：基础版（登录权限、线索、客户、联系人、跟进、基础报表）、销售过程（商机、产品、报价、合同、审批）、交易与履约（订单、回款、交付、服务）、智能化与集成（企业微信、ERP / 财务集成、电子签章、AI 客户助手、AI 销售助手、智能报表、自动化工作流等）。第十六章又按 P0 到 P3 排了优先级，并且特别提醒：第一版最容易犯的错误，就是模块太多、功能太复杂，迟迟无法上线。
这和我这次的目标并不冲突，原因是：做真实系统，一定要分期；但做原型是为了验证整套规划，没有后端的负担，所以我把 15 个模块的页面都铺开了，让整份规划可以整体评审。真要开发，就应该按分期来。这一点我觉得很重要，不然会把“原型做得全”误当成“第一版可以一次做全”。
三、关键设计决策：我替规划做了哪些取舍
决策 1：客户是主档案，其他一切都是独立对象
规划方案第二章有一条设计原则：不要把所有业务信息塞进一个客户页面。 线索、联系人、商机、报价、合同、订单、回款、服务工单都是独立业务对象，通过关联关系汇总到客户档案。
原型里是这样落地的：客户详情页用 Tab 汇总联系人、跟进、商机、报价、合同、订单、回款、服务、关系图、附件和操作日志，但每个对象都有自己的列表页和详情页，并且每个客户的详情页只显示这个客户自己的数据，不会所有客户共用同一份假数据。
我的观点：“独立建模、关联汇总”比“一个大页面”难做，但只有这样，后面的权限、统计和报表才有可能做对。
决策 2：一个客户只有一个主负责人，变更必须留痕
规划方案的规则是：同一客户原则上只有一个主负责人，可以有协同负责人；换负责人时，要保存原负责人、新负责人、变更时间和原因。公海里的客户不属于任何人的私有客户。
原型里有一个“公海规则配置”页，线索公海和客户公海各一套规则：几天未跟进自动释放、哪些客户受保护不自动释放、领取限制、保护期、退回公海是否需要审批、分配方式。
这页的真正价值是：把“公海”从一个概念变成了一组可以评审的参数。 产品经理最怕的是“大家都说公海，但每个人脑子里的公海不一样”。
决策 3：折扣审批要逐级，已批报价不能被悄悄改掉
规划方案写的是原则：折扣在授权范围内可直接提交，超过销售人员权限找销售经理，超过经理范围找销售总监，低于价格底线要总经理或财务审批；报价通过后锁定已审批版本。
原型里我把它落成了一组具体的示例阈值（≤5% 自动通过，≤10% 销售经理，≤20% 销售总监，超过 20% 或低于价格底线走总经理或财务负责人）。这几个数字是原型里的示例，不是规划原文，真实业务需要按企业授权来配置。
还有一条规则我特别坚持：已审批通过的报价再被修改，会生成新版本，并且审批状态回到草稿重新审批，不覆盖原来批准的内容。 这条来自规划方案 5.7 和第十二章“已审批报价修改”。
审批中心把这些规则串了起来：待我审批、我发起的、我已审批、抄送我的四个视图，审批详情里有流程节点、历史意见、附件，以及同意、拒绝、退回修改、转交、加签、抄送等操作。
决策 4：金额一律按“分”的整数计算
规划方案 9.4 要求金额用精确小数计算，不用浮点数。原型里的做法是金额以“分”为单位保存和计算，展示时再换算。后面我会讲到，这条规则也不是一次就做对的。
决策 5：把需求说明和原型放在同一个地方
这是我最喜欢的一个决策。每一个页面（电脑端的路由和手机端的每一屏）右边都有一个“需求文档”面板，里面固定 12 个要素：页面名称与所属模块、页面目标、使用角色与权限、入口与跳转、页面布局与元素、字段说明、交互与操作规则、业务规则与状态流转、异常与边界场景、关联数据与接口、验收标准、版本与变更记录。
面板有隐藏、半隐藏、展开三种状态；每个要素下的条目可以新增、编辑、删除，顶部能搜索，也能导出和导入 JSON、恢复默认。
为什么这么做？因为评审原型最大的浪费，是“原型在一个文件，说明在另一个文件，两边对不上”。放在同一个页面里，评审的人对着看就行，改的人也不容易漏改。
决策 6：纯前端，没有后端，并且承认这一点
原型用 Vue 3、Element Plus 和 ECharts 做成，托管在 GitHub Pages，没有后端。所有依赖库都放在项目里，离线也能打开。这意味着有些东西只能写在需求文档里，没法真的实现，比如：Excel 导入导出、定时提醒和公海自动回收、登录权限与字段脱敏、持久化审计日志。我宁愿在文档里写明“这是正式版的口径”，也不去做一个假装有效的假功能。
此外原型有粉、天蓝、白、灰四套主题，手机端的预览会跟着主题一起切换。
四、开发：先定约束，分批推进，每一批都跑测试
整个原型由我自己规划、设计、搭建和验收，其中编码环节借助 AI 编码工具提效。真正花功夫的地方，是下面这套做法：先把约束写清楚，把工作拆成小批，每一批都有测试兜底，最后再对着规划原文验收。
1. 先写一份开发约定，再动手
不能一句“做个 CRM”就开工。项目里有一份开发约定文件，把规则提前写死。其中最关键的几条：
- 所有界面文字必须是中文；
- 所有依赖库用相对路径，不引用 CDN，必须离线可用；
- 源码按文件拆分，用一个
build.js拼成单文件index.html，不许手改生成的 index.html； - 每个路由都必须登记一个文档 key，也就是每个页面都必须有自己的需求文档；
- 列表必须是真分页，行数据足够多，统计卡数字由实际数据算出来，不许再写死“共 1,268 条”这种假数字；
- 每个客户的详情页必须用它自己的数据。
规划原文也一并放进了项目里（spec/crm-plan.txt），并且约定写得很直接：页面字段、规则和验收标准与规划方案冲突时，以规划方案为准。
2. 分批做：一批一件事
我没有一次性做完，而是把工作拆成一批一批，每一批只解决一类问题：
| 阶段 | 内容 |
|---|---|
| 框架与数据 | 路由注册表、四套主题、需求文档面板；数据层 |
| 核心页面（上） | 真分页、线索/商机/客户详情；联系人与关系图、客户合并、产品与价格表、报价列表 |
| 核心页面（下） | 合同、订单；活动、交付、服务工单；数据分析、系统管理、公海规则、审批模板与统计 |
| 手机端 | 手机端框架与首页、客户、日程、待办、我的；线索、商机、跟进、审批、回款、工单、通知 |
| 需求文档 | 每个页面的需求文档（电脑端和手机端） |
| 对齐规划方案 | 每一块都重新对照规划原文校对（第五节详述） |
| 口径修正 | 修正“赢率”和“漏斗展示宽度”的混淆 |
3. 每一批都要过测试这一关
每做完一批，我都会运行全部测试（tests/all.sh）：有失败，就先修到全部通过，才算这一批完成；而且不许靠删测试、改弱测试来“通过”。变更和结论则记录在 SPEC-ALIGN.md 和 PROGRESS.md 里。
4. 测试到底测了什么
一共 8 个测试文件，用无头浏览器打开页面：
- 冒烟测试：把 87 个路由逐个打开，检查控制台没有报错、页面有内容、需求文档面板存在；
- 数据自检：检查数据层的一致性；
- 客户详情全覆盖：遍历所有客户，检查详情页没报错、客户名和编号正确、各 Tab 能切换、不同客户的内容不全相同；
- 关键流程：检查状态流转是否真的写回数据（比如工单受理再指派处理人，合同提交审批）、分页、搜索跳转；
- 手机端：底部五个 Tab、签到、新建线索、阶段更新、审批、工单等流程，以及主题切换后手机框跟着变色；
- 主题与文档面板：四套主题互不相同，面板三种状态、增删改和导入导出；
- 文档完整性：每个路由和每个手机屏都必须有完整的 12 要素文档，不能是占位骨架。
这些测试都通过了，但这里有一个我后来想得很清楚的观点，放在下一节讲。
五、验收：对着规划原文逐页核对，抓到了什么
1. 测试全绿，不代表对
所有测试都通过，听起来很漂亮，但它说明的只是：页面不报错、有内容、流程能走通。它说明不了“做出来的东西是不是规划要的东西”。
所以第一轮做完之后，我专门做了一轮“对齐规划方案”：电脑端按模块分成 11 块，手机端分成 2 块，每一块都用同样的步骤来检查：
- 先回到开发约定，再读规划原文中指定行号范围的章节（比如商机批次读 5.5、6.3，再加第十二章异常场景和第十四章验收标准里与本模块相关的行，以及权限和通用规则）；
- 对每个页面核对字段、枚举、状态流转、审批触发条件，页面和需求文档与规划明显矛盾就改；
- 在变更记录里按页面写清：改了什么、依据哪一章、规划里有但没实现的是什么以及为什么；
- 最后跑测试，不过不收工。
这个“未实现也要写清楚”的要求，我觉得和“实现了什么”同样重要。
2. 最典型的一个问题：赢率 ≠ 漏斗宽度
规划方案 5.5 在商机阶段漏斗上写了一串百分比：
初步接触 100%、需求确认 80%、方案沟通 60%、报价谈判 40%、商务审批 25%、赢单 / 输单 15%。
紧接着有一句话：“此处比例用于展示阶段顺序，不代表实际销售转化率。”
而商机字段表里另有一个字段“成交概率”，说明是“按阶段或人工配置”。
也就是说，规划里本来就有两组完全不同的百分比：一组是漏斗图上每一层画多宽，一组是一个商机成交的可能性。但它们长得太像了：都是百分比，都跟着“阶段”走，只是一个越往后越小，另一个应该越往后越大。
验收时我发现，这两个概念在原型里没有被分清：商机看板的列头写着“阶段示意 100% / 80% / ……”，列表和详情里则是“成交概率”，页面上没有明确告诉读的人这两组数是两回事，也没有一个用赢率算出来的预测金额。 我回头翻代码历史，数据层里这两组数其实是不同的字段，所以更准确地说，问题出在页面表达和口径说明上，而不是算错了数。
修正做了五件事：
| 漏斗展示宽度 | 赢率 | |
|---|---|---|
| 数值 | 100 / 80 / 60 / 40 / 25 / 15% | 初步接触 10%、需求确认 25%、方案沟通 45%、报价谈判 65%、商务审批 85%、赢单 100%、输单 0% |
| 用途 | 只用来决定漏斗图每一层画多宽 | 用来算加权预测金额 |
| 来源 | 规划方案 5.5，原文注明不代表转化率 | 原型假设，待业务确认 |
| 代码里的名字 | funnelWidth（原来叫 ratio） |
prob |
- 漏斗那组百分比改名为“漏斗展示宽度”，只用来控制图的宽度；
- 页面上所有叫“成交概率”的地方统一改叫“赢率”；
- 赢率按阶段固定默认值（原型假设，待业务确认，这组数在修正前的数据里就有，修正时把它们统一固定下来并标注清楚），赢单记 100%，输单记 0%；
- 新增加权预测金额 = 预计金额 × 赢率，按“分”计算避免浮点误差，只统计还没结束的商机；
- 在商机看板列头、列表、详情、工作台漏斗提示、数据分析的销售漏斗报表和手机端商机列表头部，都把加权金额展示出来。
比如下面这个商机，预计金额 ¥340,000，处于“报价谈判”阶段，按默认赢率（原型假设，待业务确认）65%，加权预测金额就是 ¥221,000：
看板每一列的列头现在写的是“漏斗展示宽度”，并且多了“加权预测”：
销售漏斗报表里，图表仍然按展示宽度画，但右边写明了口径：展示宽度不是转化率，也不是赢率；默认赢率是原型假设，待业务确认。
这件事教给我的：示意图上的数字，不一定是业务参数。拿到一个百分比，第一件事不是用，而是问它是干什么用的。另外，我也在需求文档里加了一条：把漏斗宽度当赢率展示，属于验收不通过的情形。
3. 第一版没有逐页对照原文
第一版的字段，是按“常规 CRM 的习惯”做的，没有逐页对照规划原文。于是才有了上面那一整轮对齐：每个页面的字段、规则和验收标准按第五章重写，审批按第七章，手机端按第十一章。
教训：做的时候就要以需求原文为依据，不能凭摘要和印象。摘要里丢掉的，往往正好是细节。
4. 对齐过程中抓到的其他问题
这些是 SPEC-ALIGN 变更记录 里写明的真实问题：
| 问题 | 怎么处理 |
|---|---|
| 工作台“我的待办”四个数字是写死的，顶部栏待办角标也是“审批数 + 8”写死的 | 改成按真实数据计算 |
| 审批中心的“平均审批用时”“驳回率”是写死的 | 改成按审批流水计算 |
| 工作台的“本月已回款”存在单位错误：回款以“分”保存，却按“万”去除，金额放大了 100 倍 | 先除以 100 再换算成万，并补了一笔 11 月的回款数据让它有数可看 |
| 销售漏斗的月/季/年切换，点了数据不变 | 改成按预计成交日期重新统计，切换后重绘 |
| 价格表明细缺失时，“相对标准价”算出 NaN | 改成按回退后的展示价格计算 |
| 已审批的报价被修改（规划要求不覆盖原批准内容） | 生成新版本，审批状态回到草稿重新审批 |
你会发现，这些问题有一个共同点：都不会让页面报错，所以测试没有抓到它们。 它们只有在“拿着规划原文，问这个数字是怎么来的”的时候才会暴露。
5. 手机端
规划方案第十一章规划了移动端，面向外勤、拜访、审批和工单处理场景。原型里手机端预览页在电脑页面里嵌了一个手机框，底部五个 Tab：首页、客户、日程、待办、我的，再往下是线索、商机、跟进、审批、回款、工单、通知等页面，按文档里登记的页面算一共 26 屏。手机框使用的也是同一套主题变量，主题切换后自动跟随。
六、这个原型的边界：哪些是真的，哪些没做
我不想让看的人误会，所以把边界直接写出来。
做到了的：
- 15 个模块的主要页面、详情页和主流程的状态流转，可以在浏览器里点；
- 列表是真分页，统计卡由数据算出来，每个客户有自己的数据；
- 工作台、商机、报价、审批、回款等页面的关键口径，都能和需求文档对上；
- 每个页面都有一份 12 要素的需求文档，能改能导出。
没做、或只是模拟的：
- 没有后端：Excel 导入导出、定时提醒和公海自动回收、登录权限与字段脱敏、持久化的审计日志，都只在需求文档里写了说明；
- 手机端的拍照、语音、定位是模拟的；
- 部分批量操作只是示例提示；
- 阶段、赢率和字典配置是静态的；
- 默认赢率（初步接触 10% 到商务审批 85%）是原型假设，待业务确认；
- 还没覆盖：一个联系人归属多个客户、竞争对手主数据、区域价格表、商机阶段回退审批。
七、心得：我的几条判断
- 需求要拆成“问题”，而不是“功能”。 6 个经营问题让每个模块都有了存在的理由，也让验收有了方向。
- 示意图上的数字不等于业务参数。 赢率和漏斗宽度这件事不会让程序崩，却会让整个业绩预测失真。
- 测试全绿不等于做对。 自动测试只能验证“不坏”，验证“对不对”要靠对照原文的验收。这两件事要分开做，并且都要留痕。
- “未实现”要和“已实现”一样认真写。 我把每一块没做的点和原因都记了下来，评审的人才知道原型的边界，也不会被一个看起来很完整的页面骗过。
- 需求文档和原型放在一起。 12 个固定要素强迫每个页面都回答同样的问题，也让缺口一眼可见。
- 以原文为准，不靠摘要。 摘要省的是读的人的时间，丢的是做的人的上下文。
- 原型不等于第一版。 15 个模块可以在原型里全铺开，但真正上线要按分期、按优先级来。
八、接下来的想法
这些都还没定，以实际情况为准：
- 和业务确认默认赢率，如果确认不了，就让它变成可配置项；
- 补上原型还没覆盖的几个场景，比如一个联系人归属多个客户、商机阶段回退审批；
- 如果要进入真实开发，按规划方案的分期从基础版开始，先做让销售能用起来的部分。
如果你也在做产品规划，欢迎点开在线原型，随便挑一个页面，对着右边的需求文档面板看看：说明和页面对不对得上？有想法欢迎留言交流。
相关链接
把 16 章 CRM 规划做成能点的原型：15 个模块、一条主线，和一个差点做错的“赢率”
本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
评论交流
欢迎留下你的想法