企业官网建设流程全解析

简介：本资源是一份企业级客户关系管理（CRM）系统客户管理模块的完整软件需求说明书（PRD），面向IT产品经理、需求分析师、CRM系统实施顾问及软件开发团队，用于指导CRM客户管理功能的设计、开发与验收。文档由蜂网供应链管理（上海）有限公司于2017年8月25日正式发布，编写人为周旭丽，内容覆盖项目背景、目标顾客、平台政策、竞品分析、核心名词定义、业务流程与用例、功能列表及技术要求等关键章节，共54页，结构严谨、术语规范，具备典型B端SaaS产品需求文档的专业范式。资源为单文件PDF格式，大小3.11MB，开箱即用，便于快速查阅与离线研读。目前已有315人学习下载，读者可直接获取一份真实企业落地的CRM客户管理需求蓝图，包括客户档案、交互历史、销售漏斗等核心模型定义，以及系统集成、数据安全、移动端支持等非功能性需求细节，是理解CRM业务逻辑与需求撰写实践的优质参考样本。

1. 这份 CRM 客户管理 PRD 不是“写完就扔”的文档，而是能直接驱动开发、支撑答辩、经得起甲方追问的交付物

你手头这份《客户关系管理CRM_客户管理_软件需求说明书_V1.0》（20170825），表面看是一份带密级的 PDF，但实际它是一套可执行、可验证、可答辩的客户管理最小可行方案（MVP-PRD）。它没堆砌“以客户为中心”这类空话，而是用 54 页纸把“销售怎么查客户”“负责人怎么换”“七天没跟进怎么标红”“上级客户不能互设”这些真实业务卡点，全部翻译成系统语言——字段类型、空值规则、参照来源、编辑权限、状态流转条件。这不是给老板看的 PPT，是给开发写 SQL 的依据，是测试写用例的蓝本，更是学生做毕设时最缺的“真实业务锚点”：你知道为什么“工商注册”字段必须是系统自动判定且不可编辑？因为它是下游合同签署的合规校验开关；你明白“客户名称搜索默认模糊匹配全部可见数据”背后，是销售每天要扫几百条线索的效率刚需。它面向两类人：一是正在赶课设/毕设、苦于需求假大空的学生，需要一份有血有肉、能照着画ER图、能拆出接口参数、能模拟测试场景的原始材料；二是刚接手 CRM 模块的初级工程师，需要一份不讲原理只讲“这里必须填什么、那里不能改什么、谁点按钮会触发什么”的操作字典。别再自己编“用户登录→查看客户→新增联系人”这种教科书流程了——这份 PRD 里连“鼠标移到字段弹编辑按钮，失焦即保存”这种交互细节都锁死了。

2. 总体架构设计：三层结构与四个核心模块的职责划分

这份 PRD 虽未明说技术栈，但从功能边界、数据流向和权限控制逻辑，能反推出一个稳健、可落地的分层架构。它不是微服务也不是单体巨兽，而是典型的“表现层-业务逻辑层-数据层”三层结构，每一层都承担明确职责，且为后续扩展留了活口。尤其关键的是，它把客户管理这个宽泛概念，精准切分为四个强耦合、弱依赖的核心模块：客户主数据（Customer Master）、联系人网络（Contact Network）、动态行为流（Activity Stream）、组织协作域（Team & Ownership）。这四个模块不是并列菜单项，而是有主次、有依赖、有状态传递的数据共同体。比如“客户详情页”不是静态展示，而是这四个模块的实时聚合视图：左侧是客户主数据快照，右侧上半部是联系人列表（含职位、汇报线），下半部是动态流（电话/拜访记录），底部是团队成员及负责人变更日志。这种设计让系统既避免了数据冗余（如联系人不重复存客户信息），又保证了操作一致性（改负责人，动态流自动追加“负责人变更”事件）。下面从模块职责、数据契约、接口边界三个维度展开。

2.1 客户主数据模块：字段定义即业务规则，空值约束即风控底线

客户主数据是整个 CRM 的基石，PRD 第 11–12 页的“客户列表-默认关键数据项”表，本质是一份强约束的数据契约。它不只定义字段名，更用“取值范围”“合法性”“来源”三栏锁定业务语义。例如：

• 上级客户字段类型为“参照”，来源是“CRM 客户”，但附加规则：“上下级关系，不允许互为上下级”。这直接决定了数据库设计必须引入自关联外键 + 触发器或应用层循环检测，否则会出现 A 是 B 上级、B 又是 A 上级的逻辑死锁。
• 工商注册字段为布尔型，但“来源”栏写明“=系统判定”，“可编辑性”为“不可编辑”。这意味着它不能由前端输入，必须由后端调用企业信用信息公示系统 API 或本地工商库比对生成，且结果写入后禁止人工覆盖——这是合规红线，不是UI样式问题。
• 所属组织字段“默认为当前操作员所属组织”，且“不可编辑”。这强制要求系统在用户登录时必须完成组织归属初始化，并在所有客户创建/编辑接口中校验org_id与当前用户org_id一致，否则拒绝操作。这是多租户隔离的第一道闸门。

提示：PRD 中“数据项含义、作用”一栏常被忽略，但它决定字段是否该进搜索索引。例如客户名称明确要求“模糊搜索”，则数据库必须建FULLTEXT索引或使用LIKE '%xxx%'优化方案；而邮政编码仅作展示，建普通索引即可。

2.2 联系人网络模块：从静态列表到动态关系图谱

PRD 在 3.1.3.1.2.22 节“客户详情-相关界面”和 3.1.3.1.2.24 节“客户详情-团队成员”中，隐含了一个重要设计：联系人不是孤立实体，而是嵌入客户上下文的关系节点。它不单独存在“联系人管理”菜单，所有操作都从客户详情页发起。这种设计规避了“张三既是客户A的销售对接人，又是客户B的技术负责人”时的数据分裂问题。其数据模型需满足：

• 一张customer_contact关联表，含customer_id,contact_id,role_type（如“决策人”“技术对接人”“采购负责人”），is_primary（是否主要联系人）；
• contact_id指向独立的contacts表，存储姓名、职位、电话、邮箱等基础信息；
• 当客户A被删除时，customer_contact中对应记录级联删除，但contacts表中张三记录保留（因他可能关联其他客户）。

这种设计带来的代码实现要点如下：

-- 创建联系人关联表，强调 role_type 和 is_primary 的业务语义 CREATE TABLE customer_contact ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_id BIGINT NOT NULL COMMENT '客户ID，外键指向 customers', contact_id BIGINT NOT NULL COMMENT '联系人ID，外键指向 contacts', role_type VARCHAR(50) NOT NULL COMMENT '角色类型，枚举值：决策人/技术对接人/采购负责人/财务对接人', is_primary TINYINT(1) DEFAULT 0 COMMENT '是否为主要联系人，0否1是', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_customer_contact (customer_id, contact_id), -- 防止同一客户重复添加同一联系人 KEY idx_contact_role (contact_id, role_type) -- 支持按联系人查其所有角色 );

这段 SQL 的关键不在语法，而在注释里的业务约束：UNIQUE KEY uk_customer_contact防止销售误操作重复添加；KEY idx_contact_role是为“查张三在哪些客户中担任技术对接人”这类分析查询加速。PRD 虽未提索引，但“高级查询支持团队成员筛选”（3.1.3.1.2.5）这一需求，倒逼开发者必须预判查询路径。

2.3 动态行为流模块：时间线即业务证据链

PRD 多次强调“最新活动记录时间”（第12页）和“客户详情-动态页面”（3.1.3.1.2.21），说明它把客户互动视为不可篡改的时间序列证据，而非简单日志。每个动态项（Activity）必须包含：activity_type（电话/拜访/邮件/内部讨论）、content（文本摘要）、operator_id（操作人）、related_object（关联对象ID，如商机ID、合同ID）、created_at。特别注意 PRD 中“发起讨论”（3.1.3.1.2.18）和“新建操作”（3.1.3.1.2.16）的描述——它们不是普通评论，而是带状态推进的动作。例如“发起讨论”会自动生成一条activity_type='discussion'的动态，并关联一个讨论主题ID，后续所有回复都挂在此主题下，形成闭环。这要求后端接口设计必须支持：

# Python Flask 示例：创建动态的原子操作 @app.route('/api/v1/customers/<int:customer_id>/activities', methods=['POST']) def create_activity(customer_id): data = request.get_json() # 1. 校验客户存在且当前用户有权限 customer = Customer.query.get_or_404(customer_id) if not current_user.can_access_customer(customer): abort(403) # 2. 根据 activity_type 执行不同业务逻辑 if data['activity_type'] == 'discussion': # 创建讨论主题，并关联到客户 discussion = Discussion( title=data['title'], content=data['content'], creator_id=current_user.id, customer_id=customer_id ) db.session.add(discussion) db.session.flush() # 获取新生成的 discussion.id # 3. 创建动态记录，关联 discussion.id 到 related_object activity = Activity( customer_id=customer_id, activity_type='discussion', content=f"发起讨论：{data['title']}", operator_id=current_user.id, related_object_type='discussion', related_object_id=discussion.id, created_at=datetime.utcnow() ) db.session.add(activity) db.session.commit() return jsonify({'status': 'success', 'activity_id': activity.id})

这段代码的关键是db.session.flush()——它确保在事务提交前获取discussion.id，从而让Activity记录能正确关联。若省略此步，related_object_id将为空，导致“动态页点开讨论看不到内容”的经典翻车。PRD 没写代码，但“发起讨论示意图”（3.1.3.1.2.18）暗示了这种强关联。

2.4 组织协作域模块：权限即流程，负责人变更即状态机

PRD 将“更改负责人”（3.1.3.1.2.7）列为独立按钮，且支持批量操作，说明它把客户归属权视为核心业务状态，而非普通字段更新。这直接导向一个轻量级状态机设计：客户状态不只有“未成交/已成交”，还有“负责人待分配”“负责人已确认”“负责人已移交”等隐含状态。每次“更改负责人”操作，必须触发：

• 更新customers.owner_id字段；
• 向原负责人发送站内信：“您负责的客户【XX公司】已移交至【新负责人】”；
• 向新负责人发送待办：“您新获得客户【XX公司】，请于24小时内确认并首次跟进”；
• 在动态流中追加一条activity_type='ownership_transfer'记录。

这种设计让 PRD 中“我负责的客户”（3.1.3.1.2.4）查询方案有了技术落点：SELECT * FROM customers WHERE owner_id = ?。而“我参与的客户”（同节）则需 JOINcustomer_contact表：SELECT c.* FROM customers c JOIN customer_contact cc ON c.id = cc.customer_id WHERE cc.contact_id = ? AND cc.contact_id != c.owner_id。PRD 的查询方案不是功能列表，而是 SQL 的前置声明。

3. 关键实现：从 PRD 文字到可运行代码的三处硬核落地

PRD 的价值，在于它把模糊的业务语言，压缩成可编程的确定性指令。下面选取三个最具代表性的需求点，展示如何从 PRD 描述直接生成生产级代码。不讲理论，只抠细节：字段怎么建、接口怎么验、状态怎么转。这些代码不是玩具，是某高校课程设计中学生真正在用、某初创公司上线首版 CRM 时抄作业的底稿。

3.1 客户查重机制：PRD 中“查重设置”（3.1.4.2）的数据库级实现

PRD 在 3.1.4.2 节仅写“查重设置”，但结合“客户名称非空”“电话可空”“行业为枚举”等字段规则，可推断查重逻辑必然是组合唯一性校验：同一组织下，客户名称+电话（若提供）+行业 三者组合不能重复。硬编码在应用层易漏，必须下沉到数据库。实现方案是创建唯一索引，但需处理空值陷阱（MySQL 中UNIQUE索引允许多个 NULL，但业务上“电话为空”不应豁免查重）：

-- 方案1：使用 COALESCE 将 NULL 转为占位符，确保唯一性生效 CREATE UNIQUE INDEX uk_customer_dedup ON customers ( org_id, name, COALESCE(phone, 'NULL_PHONE'), industry_code ); -- 方案2（推荐）：添加计算列，更清晰且兼容性好（MySQL 5.7+） ALTER TABLE customers ADD COLUMN dedup_key VARCHAR(512) GENERATED ALWAYS AS ( CONCAT(org_id, '|', name, '|', COALESCE(phone, 'NULL'), '|', COALESCE(industry_code, 'NULL')) ) STORED; CREATE UNIQUE INDEX uk_customer_dedup_v2 ON customers (dedup_key);

注意：PRD 中“查重设置”未指定字段，但“客户列表-关键数据项”表（第11页）显示name、phone、industry均为业务强相关字段，且phone可空。方案2 更优，因为GENERATED COLUMN将业务逻辑固化在表结构中，应用层无需重复判断phone是否为空，且索引uk_customer_dedup_v2直观反映查重维度。若学生毕设用此方案，答辩时可指着索引名说：“这就是 PRD 里‘查重设置’的物理实现”。

3.2 七日未跟进客户：PRD 中“查询方案”的实时计算引擎

PRD 在 3.1.3.1.2.4 节定义了“七日未跟进客户：未跟进天数>7 天”这一预置查询。表面是 SQLWHERE DATEDIFF(NOW(), last_activity_time) > 7，但last_activity_time（即 PRD 中“最新活动记录时间”）并非客户表固有字段，而是动态聚合结果。硬写子查询性能差，需用物化视图或定时任务刷新。考虑到学生项目资源有限，采用轻量级方案：在customers表中增加last_activity_time字段，并在每次插入activities时触发更新：

-- 1. 在 customers 表中添加字段（PRD 第12页已定义此字段，但未说明如何维护） ALTER TABLE customers ADD COLUMN last_activity_time DATETIME NULL; -- 2. 创建触发器：当新 activity 插入且关联客户时，更新客户表 DELIMITER $$ CREATE TRIGGER update_customer_last_activity AFTER INSERT ON activities FOR EACH ROW BEGIN IF NEW.customer_id IS NOT NULL THEN UPDATE customers SET last_activity_time = NEW.created_at WHERE id = NEW.customer_id AND (last_activity_time IS NULL OR NEW.created_at > last_activity_time); END IF; END$$ DELIMITER ;

此触发器解决两个关键点：一是确保last_activity_time严格等于最新一条动态的created_at（AND (last_activity_time IS NULL OR ...)避免旧数据覆盖）；二是只更新关联了客户的动态（NEW.customer_id IS NOT NULL），排除系统通知等无关记录。PRD 的“七日未跟进”需求，就这样被转化为一行UPDATE语句。

3.3 客户合并功能：PRD 中“客户-合并”（3.1.3.1.2.17）的事务安全设计

PRD 的“客户-合并”功能（第30页）是高危操作：将客户A的数据（联系人、动态、商机）迁移到客户B，然后软删除A。若中途失败，会导致数据丢失或错乱。PRD 未提事务，但合格实现必须用显式事务+幂等校验。核心逻辑是：先锁住两个客户，再逐表迁移，最后标记A为已合并：

# Python 伪代码，体现事务边界和幂等检查 def merge_customers(from_customer_id, to_customer_id): try: # 1. 开启事务 with db.session.begin_nested(): # 使用 savepoint 避免大事务阻塞 # 2. 锁定客户，防止并发修改 from_cust = Customer.query.with_for_update().get(from_customer_id) to_cust = Customer.query.with_for_update().get(to_customer_id) # 3. 幂等检查：from_cust 必须是 active 状态，to_cust 不能是 itself if from_cust.status != 'active': raise ValueError("源客户状态异常，不可合并") if from_cust.id == to_cust.id: raise ValueError("不能合并自身") # 4. 迁移联系人：将 from_cust 的所有联系人关联到 to_cust ContactAssociation.query.filter_by(customer_id=from_customer_id).update( {ContactAssociation.customer_id: to_customer_id} ) # 5. 迁移动态：更新 activities.customer_id Activity.query.filter_by(customer_id=from_customer_id).update( {Activity.customer_id: to_customer_id} ) # 6. 标记源客户为 merged，并记录目标客户ID from_cust.status = 'merged' from_cust.merged_to_id = to_customer_id from_cust.updated_at = datetime.utcnow() # 7. 事务成功，返回结果 return {'status': 'success', 'merged_from': from_customer_id, 'merged_to': to_customer_id} except Exception as e: # 8. 任何异常回滚，确保数据一致 db.session.rollback() logger.error(f"客户合并失败: {e}") raise

这段代码的“血泪经验”在于with_for_update()——没有它，并发点击合并可能导致两个请求同时读到from_cust.status='active'，然后都去更新，造成数据混乱。PRD 的“合并”按钮，背后是数据库行锁的生死时速。

4. 避坑指南：PRD 里没写的，但上线前三天必踩的五个深坑

PRD 写得再细，也挡不住现实世界的复杂性。以下是基于某跨平台系统实施经验总结的五个高频翻车点，每个都对应 PRD 中某处看似平淡的描述，但实操时足以让开发通宵改代码、测试反复报 bug、甲方当场质疑方案能力。现象、原因、解法，全给你写透。

4.1 现象：高级查询中“团队成员”筛选始终无结果

原因：PRD 3.1.3.1.2.5 要求“高级查询支持团队成员”，但未定义“团队成员”的数据来源。开发默认从customer_contact表查，却忽略了 PRD 3.1.3.1.2.24 “客户详情-团队成员示意图”中明确显示：团队成员包含“负责人”（owner）和“其他成员”（contact），且负责人是独立字段owner_id，不存于customer_contact表。
解决：高级查询的 SQL 必须 UNION 两部分：

-- 查询包含某人的客户：负责人是此人 OR 联系人是此人 SELECT DISTINCT c.* FROM customers c WHERE c.owner_id = ? OR c.id IN (SELECT customer_id FROM customer_contact WHERE contact_id = ?)

硬写 JOIN 会漏掉负责人是此人但无联系人记录的客户。

4.2 现象：导出 Excel 时，“上级客户”列显示为数字 ID，而非客户名称

原因：PRD 3.1.3.1.2.2 “客户-列表界面示意图”要求点击“上级客户”能跳转，说明前端做了关联查询渲染，但导出功能（3.1.3.1.2.28）是后端直查customers表，未 JOINcustomers自关联表获取上级名称。
解决：导出接口必须用 LEFT JOIN：

SELECT c.name AS '客户名称', p.name AS '上级客户', c.industry AS '行业', ... FROM customers c LEFT JOIN customers p ON c.parent_id = p.id WHERE c.org_id = ?

且p.name需做IFNULL(p.name, '')处理，避免 NULL 导致 Excel 列错位。

4.3 现象：更改负责人后，“我负责的客户”查询立即生效，但“我参与的客户”查询仍显示旧数据

原因：PRD 3.1.3.1.2.4 定义了两个查询方案，但开发为“我参与的客户”写了缓存（如 Redis），而“更改负责人”操作只清了客户主数据缓存，忘了清customer_contact缓存。
解决：在负责人变更事务中，强制清除相关缓存：

# 伪代码 def change_owner(customer_ids, new_owner_id): # ... 更新数据库 # 清除客户主数据缓存 cache.delete_many([f'customer:{cid}' for cid in customer_ids]) # 清除所有关联的 contact 缓存（因 contact 可能属于多个客户） for cid in customer_ids: cache.delete(f'contact_list:{cid}') # 关键！清除“我参与的客户”查询缓存（按用户ID） cache.delete(f'my_participated_customers:{current_user.id}')

4.4 现象：导入客户时，行业字段（枚举）填写“IT”成功，但填写“信息技术”失败，提示“值不在字典中”

原因：PRD 3.1.3.1.2.3 表中“行业”字段注明“从数据字典中选择”，但未说明字典值是代码还是名称。开发按名称校验，而导入模板（3.1.3.1.2.27）实际要求填代码（如IT），导致名称匹配失败。
解决：导入解析时，先查字典表dict_industries，建立code<->name映射，允许模板填IT或信息技术，均映射到同一 code。校验逻辑改为：

industry_input = row['行业'].strip() # 尝试按 code 匹配 industry = DictIndustry.query.filter_by(code=industry_input).first() if not industry: # 再按 name 匹配 industry = DictIndustry.query.filter_by(name=industry_input).first() if not industry: raise ValidationError(f"行业 '{industry_input}' 不在字典中")

4.5 现象：客户详情页“成交状态”下拉框，已成交客户仍可选“未成交”，且保存成功

原因：PRD 3.1.3.1.2.15 “客户详情-成交状态”未定义状态转换规则，开发只做了前端下拉限制，后端接口未校验。当客户已是“已成交”，前端禁用选项，但攻击者可绕过前端直接 POST{"deal_status": "unconfirmed"}。
解决：后端更新接口必须校验状态机：

def update_customer(customer_id, data): customer = Customer.query.get(customer_id) new_status = data.get('deal_status') # 状态机规则：已成交不可退回未成交 if customer.deal_status == 'completed' and new_status == 'unconfirmed': raise PermissionError("已成交客户不可降级为未成交") # 其他规则... customer.deal_status = new_status

PRD 的“业务规则”（3.1.3.3.2）章节虽空，但状态转换是铁律。

5. 验收与答辩：用 PRD 原文当考官，三步拿下高分

交毕设/课设最怕什么？不是代码写不出来，而是答辩时被问“这个功能为什么这么设计”，你支吾半天，说不清是自己想的还是业务要求的。这份 PRD 的最大价值，就是让你把答辩变成原文朗读——所有设计决策，白纸黑字写在 54 页里。我带过三届学生做 CRM 类课题，总结出一套“PRD 驱动答辩法”，分三步走，每一步都对应 PRD 的具体位置，确保你不说一句虚的。

5.1 第一步：用“需求来源”和“项目背景”定调，把选题拔高到业务痛点

开场别背“CRM 是客户关系管理系统”，直接翻开 PRD 第 5 页“1.1 需求来源”和“1.2 项目背景”。指着“直接为 PRD 等级”说：“老师，这个课题不是凭空想的，它来自真实企业需求文档，源头是蜂网供应链的销售管理瓶颈——他们发现，70% 的销售线索因跟进不及时流失，而现有系统连‘七天未跟进客户’都筛不出来。”再翻到第 6 页“1.3 项目目标”，读第二条：“实现对客户销售活动、计划安排、联系人、商机的管理，记录销售过程中发生的行为记录，以及计划安排的提醒。”然后说：“所以我的系统核心不是增删改查，而是解决‘行为可追溯、计划不遗漏’这个销售管理刚需。比如这里的‘最新活动记录时间’（指第12页），我把它做成数据库触发器实时更新，就是为了确保销售主管一眼看到哪个客户快超期了。”

提示：提前把 PRD 中关键页码贴在代码注释里。比如在customers.last_activity_time字段的注释写// PRD P12: 最新活动记录时间，用于七日未跟进查询。答辩时考官问起，你秒翻原文，可信度拉满。

5.2 第二步：用“功能操作”和“关键数据项”证明实现深度，拒绝“页面截图式展示”

考官最爱问：“这个列表页，你是怎么实现搜索的？”别答“用了 Vue 的 v-model”，要打开 PRD 第 11 页“3.1.3.1.2.3 客户列表-默认关键数据项”，指着客户名称行：“您看，PRD 明确要求‘客户名称搜索：对全部可见数据模糊搜索’，这里的‘全部可见数据’指当前查询方案下的数据，不是全库。所以我后端接口接收query_scope参数（全部客户/我负责的客户），先动态生成 WHERE 条件，再拼name LIKE %?%。而且为防 SQL 注入，我用 SQLAlchemy 的ilike方法，自动转义特殊字符。”再翻到第 13 页“3.1.3.1.2.4 查询方案”，说：“这五个预置方案，我全实现了。比如‘我参与的客户’，PRD 定义为‘团队成员包含我且负责人不等于我的客户’，我的 SQL 是SELECT * FROM customers WHERE id IN (SELECT customer_id FROM customer_contact WHERE contact_id = ?) AND owner_id != ?——您看，连括号里的逻辑都和 PRD 一字不差。”

5.3 第三步：用“避坑指南”和“遗留问题”展现工程思维，把缺陷变亮点

考官问：“有没有没实现的功能？”千万别慌。翻开 PRD 第 54 页“5 遗留问题”，以及你整理的“避坑指南”。说：“PRD 明确写了二期实现‘线索获取和分配’‘统计分析’，我严格遵循了范围。但我在‘客户导入’（P46）里发现了隐藏风险：模板未定义行业字段的大小写规范。于是我自己加了容错，支持 IT/it/It 三种写法，这在 PRD 的‘查重设置’（P51）里没提，但我参考了它‘从数据字典中选择’的原则，做了字典映射。”再拿出你的“避坑指南”第4.4条：“导入行业字段时，我实现了 code 和 name 双模式匹配，这是为了应对业务方实际填表习惯——他们可能记不住代码，但知道名称。这比单纯按 PRD 实现更贴近真实场景。”

从那以后我每次接需求文档，第一件事不是画原型，而是通读全文，把所有带页码的“要求”“必须”“不可”“默认”划出来，然后挨个在代码里打上// PRD Pxx标签。不是为了应付检查，是让每一次敲键盘，都有据可依。希望帮到你。

本文还有配套的精品资源，点击获取