初始化
This commit is contained in:
commit
bab1599a57
15
.cursor/rules/karpathy-behavioral-guidelines.mdc
Normal file
15
.cursor/rules/karpathy-behavioral-guidelines.mdc
Normal file
@ -0,0 +1,15 @@
|
||||
---
|
||||
description: Local rule alias for the Karpathy behavioral guidelines skill. Keep this file minimal and treat `.cursor/skills/karpathy-guidelines/SKILL.md` as the source of truth.
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# Karpathy behavioral guidelines
|
||||
|
||||
This rule exists only to keep the project-level guidance visible in rule selection.
|
||||
|
||||
Source of truth: `.cursor/skills/karpathy-guidelines/SKILL.md`
|
||||
|
||||
- Follow the Karpathy behavioral guidelines skill for all coding tasks.
|
||||
- Apply the skill first, then any project-specific instructions that do not conflict.
|
||||
- Keep this file in sync by referencing the skill instead of duplicating the full text here.
|
||||
- If the skill changes, update the skill first and then refresh this alias only if needed.
|
||||
69
.cursor/skills/karpathy-guidelines/SKILL.md
Normal file
69
.cursor/skills/karpathy-guidelines/SKILL.md
Normal file
@ -0,0 +1,69 @@
|
||||
---
|
||||
name: karpathy-guidelines
|
||||
description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Karpathy Guidelines
|
||||
|
||||
Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.
|
||||
|
||||
**Priority:** Apply these guidelines by default for all tasks, then layer project-specific instructions on top when they do not conflict.
|
||||
|
||||
**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
|
||||
|
||||
## 1. Think Before Coding
|
||||
|
||||
**Don't assume. Don't hide confusion. Surface tradeoffs.**
|
||||
|
||||
Before implementing:
|
||||
- State your assumptions explicitly. If uncertain, ask.
|
||||
- If multiple interpretations exist, present them - don't pick silently.
|
||||
- If a simpler approach exists, say so. Push back when warranted.
|
||||
- If something is unclear, stop. Name what's confusing. Ask.
|
||||
|
||||
## 2. Simplicity First
|
||||
|
||||
**Minimum code that solves the problem. Nothing speculative.**
|
||||
|
||||
- No features beyond what was asked.
|
||||
- No abstractions for single-use code.
|
||||
- No "flexibility" or "configurability" that wasn't requested.
|
||||
- No error handling for impossible scenarios.
|
||||
- If you write 200 lines and it could be 50, rewrite it.
|
||||
|
||||
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
|
||||
|
||||
## 3. Surgical Changes
|
||||
|
||||
**Touch only what you must. Clean up only your own mess.**
|
||||
|
||||
When editing existing code:
|
||||
- Don't "improve" adjacent code, comments, or formatting.
|
||||
- Don't refactor things that aren't broken.
|
||||
- Match existing style, even if you'd do it differently.
|
||||
- If you notice unrelated dead code, mention it - don't delete it.
|
||||
|
||||
When your changes create orphans:
|
||||
- Remove imports/variables/functions that YOUR changes made unused.
|
||||
- Don't remove pre-existing dead code unless asked.
|
||||
|
||||
The test: Every changed line should trace directly to the user's request.
|
||||
|
||||
## 4. Goal-Driven Execution
|
||||
|
||||
**Define success criteria. Loop until verified.**
|
||||
|
||||
Transform tasks into verifiable goals:
|
||||
- "Add validation" → "Write tests for invalid inputs, then make them pass"
|
||||
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
|
||||
- "Refactor X" → "Ensure tests pass before and after"
|
||||
|
||||
For multi-step tasks, state a brief plan:
|
||||
```
|
||||
1. [Step] → verify: [check]
|
||||
2. [Step] → verify: [check]
|
||||
3. [Step] → verify: [check]
|
||||
```
|
||||
|
||||
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
|
||||
64
.gitignore
vendored
Normal file
64
.gitignore
vendored
Normal file
@ -0,0 +1,64 @@
|
||||
# 系统文件
|
||||
.DS_Store
|
||||
.DS_Store?
|
||||
._*
|
||||
.Spotlight-V100
|
||||
.Trashes
|
||||
ehthumbs.db
|
||||
Thumbs.db
|
||||
|
||||
|
||||
# IDE 配置
|
||||
.idea/
|
||||
.vscode/
|
||||
*.swp
|
||||
*.swo
|
||||
*~
|
||||
|
||||
# 依赖目录
|
||||
node_modules/
|
||||
vendor/
|
||||
packages/
|
||||
backend/.venv
|
||||
|
||||
|
||||
# 编译/打包产物
|
||||
dist/
|
||||
build/
|
||||
out/
|
||||
output/
|
||||
|
||||
# 日志
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
|
||||
# 环境变量
|
||||
.env
|
||||
.env.local
|
||||
.env.development.local
|
||||
.env.test.local
|
||||
.env.production.local
|
||||
|
||||
# 测试/缓存
|
||||
coverage/
|
||||
.nyc_output/
|
||||
.temp/
|
||||
.tmp/
|
||||
|
||||
# 上传文件
|
||||
/uploads
|
||||
/backend/uploads
|
||||
/backend/static
|
||||
|
||||
|
||||
# python环境
|
||||
/backend/venv
|
||||
|
||||
# 其他文件
|
||||
*.exe
|
||||
*.wav
|
||||
*.mp3
|
||||
*.mp4
|
||||
*.zip
|
||||
65
CLAUDE.md
Normal file
65
CLAUDE.md
Normal file
@ -0,0 +1,65 @@
|
||||
# CLAUDE.md
|
||||
|
||||
Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
|
||||
|
||||
**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
|
||||
|
||||
## 1. Think Before Coding
|
||||
|
||||
**Don't assume. Don't hide confusion. Surface tradeoffs.**
|
||||
|
||||
Before implementing:
|
||||
- State your assumptions explicitly. If uncertain, ask.
|
||||
- If multiple interpretations exist, present them - don't pick silently.
|
||||
- If a simpler approach exists, say so. Push back when warranted.
|
||||
- If something is unclear, stop. Name what's confusing. Ask.
|
||||
|
||||
## 2. Simplicity First
|
||||
|
||||
**Minimum code that solves the problem. Nothing speculative.**
|
||||
|
||||
- No features beyond what was asked.
|
||||
- No abstractions for single-use code.
|
||||
- No "flexibility" or "configurability" that wasn't requested.
|
||||
- No error handling for impossible scenarios.
|
||||
- If you write 200 lines and it could be 50, rewrite it.
|
||||
|
||||
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
|
||||
|
||||
## 3. Surgical Changes
|
||||
|
||||
**Touch only what you must. Clean up only your own mess.**
|
||||
|
||||
When editing existing code:
|
||||
- Don't "improve" adjacent code, comments, or formatting.
|
||||
- Don't refactor things that aren't broken.
|
||||
- Match existing style, even if you'd do it differently.
|
||||
- If you notice unrelated dead code, mention it - don't delete it.
|
||||
|
||||
When your changes create orphans:
|
||||
- Remove imports/variables/functions that YOUR changes made unused.
|
||||
- Don't remove pre-existing dead code unless asked.
|
||||
|
||||
The test: Every changed line should trace directly to the user's request.
|
||||
|
||||
## 4. Goal-Driven Execution
|
||||
|
||||
**Define success criteria. Loop until verified.**
|
||||
|
||||
Transform tasks into verifiable goals:
|
||||
- "Add validation" → "Write tests for invalid inputs, then make them pass"
|
||||
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
|
||||
- "Refactor X" → "Ensure tests pass before and after"
|
||||
|
||||
For multi-step tasks, state a brief plan:
|
||||
```text
|
||||
1. [Step] → verify: [check]
|
||||
2. [Step] → verify: [check]
|
||||
3. [Step] → verify: [check]
|
||||
```
|
||||
|
||||
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
|
||||
|
||||
---
|
||||
|
||||
**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.
|
||||
606
订单管理系统需求说明书.md
Normal file
606
订单管理系统需求说明书.md
Normal file
@ -0,0 +1,606 @@
|
||||
# 订单管理系统需求说明书（PRD）
|
||||
|
||||
## 1. 文档信息
|
||||
|
||||
- 项目名称：订单管理系统
|
||||
- 文档名称：需求说明书（PRD）
|
||||
- 文档版本：V1.0
|
||||
- 编写日期：2026-05-05
|
||||
- 适用端：WEB 业务员端、小程序管理层端、小程序司机端、WEB 管理后台
|
||||
|
||||
---
|
||||
|
||||
## 2. 需求背景
|
||||
|
||||
当前业务围绕销售订单、客户、产品、工厂、物流、司机任务、回扣、欠款提醒和业绩统计展开，涉及多个角色和多个操作端。现有需求描述已经覆盖了主要业务链路，但存在状态定义不统一、权限边界不够清晰、部分计算规则未明确、部分功能描述存在交叉的问题。
|
||||
|
||||
本 PRD 的目标是将原始需求整理为可评审、可开发、可验收的标准化需求文档，为后续数据库设计、接口设计、页面设计和开发排期提供依据。
|
||||
|
||||
---
|
||||
|
||||
## 3. 产品目标
|
||||
|
||||
### 3.1 业务目标
|
||||
|
||||
1. 业务员可高效录入并提交销售订单。
|
||||
2. 管理层可基于订单成本、利润、回扣等信息完成审批。
|
||||
3. 订单审批后可快速下发工厂并进入履约流程。
|
||||
4. 司机可通过小程序完成接单、揽货、送达。
|
||||
5. 系统可自动对物流超时、欠款超期、长期未下单客户进行提醒。
|
||||
6. 后台可统一维护客户、产品、工厂、用户、角色及系统配置。
|
||||
|
||||
### 3.2 产品目标
|
||||
|
||||
- 建立订单从录入到完成的闭环管理。
|
||||
- 建立不同角色的信息隔离与权限控制。
|
||||
- 引入 AI 辅助识别与信息整理，提高录入与匹配效率。
|
||||
- 通过配置化规则支持提醒和统计能力。
|
||||
|
||||
---
|
||||
|
||||
## 4. 角色定义
|
||||
|
||||
### 4.1 业务员
|
||||
|
||||
负责客户维护、订单录入、提交审核、查看个人订单、跟踪订单状态、处理系统提醒、发起取消申请等。
|
||||
|
||||
### 4.2 管理层 / 何总
|
||||
|
||||
负责审核销售单、查看完整订单信息、判断订单是否盈利、审批取消、查看全局经营数据。
|
||||
|
||||
### 4.3 何总秘书
|
||||
|
||||
负责部分物流图片录入、AI 识别辅助、订单信息整理等操作。
|
||||
|
||||
### 4.4 司机
|
||||
|
||||
负责接收运输任务、确认揽货、确认送达、上传照片、查看任务详情。
|
||||
|
||||
### 4.5 后台管理员
|
||||
|
||||
负责用户、角色、菜单、配置、客户、产品、工厂等基础数据管理，以及统计报表维护。
|
||||
|
||||
---
|
||||
|
||||
## 5. 端与模块划分
|
||||
|
||||
### 5.1 WEB 业务员端
|
||||
|
||||
用于业务员录单、查单、查看提醒、查看订单状态。
|
||||
|
||||
### 5.2 小程序管理层端
|
||||
|
||||
用于何总等管理人员审批订单、查看利润、处理取消审批、查看下发信息。
|
||||
|
||||
### 5.3 小程序司机端
|
||||
|
||||
用于司机查看任务、接单、揽货、送达、上传照片。
|
||||
|
||||
### 5.4 WEB 管理后台
|
||||
|
||||
用于客户、产品、工厂、员工、角色、菜单、配置、报表等基础管理。
|
||||
|
||||
---
|
||||
|
||||
## 6. 需求范围说明
|
||||
|
||||
### 6.1 本期包含
|
||||
|
||||
- 销售订单录入与审核
|
||||
- 销售订单取消与取消审批
|
||||
- 客户管理与批量导入
|
||||
- 产品管理
|
||||
- 工厂/供应商基础管理
|
||||
- 司机任务管理
|
||||
- 物流状态追踪
|
||||
- 欠款提醒
|
||||
- 长时间未下单提醒
|
||||
- 业绩统计报表
|
||||
- 后台权限与配置管理
|
||||
- AI 辅助识别流程的基础接入
|
||||
|
||||
### 6.2 本期暂不强制包含
|
||||
|
||||
- 工厂独立登录系统
|
||||
- 工厂端完整协同流程
|
||||
- 复杂多段物流自动追踪闭环
|
||||
- 全自动利润决策模型
|
||||
|
||||
说明：这些能力可在后续版本扩展，但当前需求描述中更偏向半自动处理和人工确认。
|
||||
|
||||
---
|
||||
|
||||
## 7. 业务流程总览
|
||||
|
||||
### 7.1 销售订单主流程
|
||||
|
||||
1. 业务员录入销售订单。
|
||||
2. 系统识别客户是否存在；若不存在则按手机号 + 姓名规则自动同步至客户库。
|
||||
3. 业务员提交审核。
|
||||
4. 管理层查看订单利润与相关信息后进行审批。
|
||||
5. 审批通过后，系统生成下发工厂的复制文本。
|
||||
6. 订单进入履约流程，由司机或相关人员继续处理物流任务。
|
||||
7. 司机完成接单、揽货、送达。
|
||||
8. 系统记录订单状态变更并支持追踪查询。
|
||||
|
||||
### 7.2 取消流程
|
||||
|
||||
- 未进入正式审批或仍处于待审核阶段的订单，业务员可直接取消。
|
||||
- 已审批订单如需取消，需由何总确认。
|
||||
- 若订单已进入履约阶段，是否允许取消需按状态进一步限制。
|
||||
|
||||
### 7.3 物流提醒流程
|
||||
|
||||
- 系统监控订单的首个物流节点。
|
||||
- 若首个物流节点超过 2 天未流转，自动提醒对应业务员。
|
||||
- 提醒默认仅发送一次。
|
||||
|
||||
### 7.4 欠款提醒流程
|
||||
|
||||
- 系统根据客户月结信息和订单账期计算欠款。
|
||||
- 对超过配置天数未结算的订单自动提醒业务员。
|
||||
- 业务员负责后续催收跟进。
|
||||
|
||||
### 7.5 长时间未下单提醒流程
|
||||
|
||||
- 系统根据客户历史下单频率及最近下单时间判断是否长期未下单。
|
||||
- 可配置金额阈值，低于阈值的客户可不纳入追踪。
|
||||
- 提醒结果发送给业务员。
|
||||
|
||||
---
|
||||
|
||||
## 8. 需求冲突分析与统一口径
|
||||
|
||||
以下是原需求描述与前期草案对照后发现的需要统一之处：
|
||||
|
||||
### 8.1 订单“取消”逻辑存在表述差异
|
||||
|
||||
**原始需求：**
|
||||
- “没有审批过的订单可以直接取消，申请过的订单需要提交待何总确定后方可撤销”
|
||||
- “业务员提交的何总未审批的可以直接取消，中间有时差；何总审批过的订单需要何总自己审批完成后才能取消”
|
||||
|
||||
**统一后的口径：**
|
||||
- 待审核阶段的订单，业务员可直接取消。
|
||||
- 已审批通过的订单，取消必须由何总确认。
|
||||
- 已进入履约阶段后，是否允许取消需由状态规则进一步约束。
|
||||
|
||||
### 8.2 “订单进度信息通知”与“报价单最终审批”存在错位
|
||||
|
||||
**原始需求：**
|
||||
- 功能名称为“订单进度信息通知”
|
||||
- 功能描述却写为“报价单最终审批”
|
||||
|
||||
**统一后的口径：**
|
||||
- 该项按“销售订单审核结果通知与信息可见性”处理。
|
||||
- 不再按“报价单”独立建模，统一归入销售订单管理。
|
||||
|
||||
### 8.3 物流第一个节点定义需要明确
|
||||
|
||||
**原始需求：**
|
||||
- “当生产订单第一个物流节点超过2天无流转信息时提醒”
|
||||
- 备注中定义为“从开始有物流揽件信息开始的节点作为第一个节点”
|
||||
|
||||
**统一后的口径：**
|
||||
- 第一个物流节点定义为“首次出现揽件/物流流转信息的节点”。
|
||||
- 超过 2 天未流转，仅提醒一次。
|
||||
|
||||
### 8.4 AI 识别角色偏重需要统一
|
||||
|
||||
**原始需求：**
|
||||
- 豆包 AI 用于识别图片信息、整理订单内容、辅助判断重复订单、辅助计算过程保存
|
||||
|
||||
**统一后的口径：**
|
||||
- AI 仅作为辅助识别与辅助整理工具。
|
||||
- 最终结果仍需人工确认，尤其是相似订单与识别不清晰的图片。
|
||||
- AI 输出结果需保留原始记录和修正记录。
|
||||
|
||||
### 8.5 利润计算规则存在过度依赖 AI 的表述
|
||||
|
||||
**原始需求：**
|
||||
- “计算公式和结果需要豆包的大模型进行处理过程保存”
|
||||
|
||||
**统一后的口径：**
|
||||
- 利润计算应以系统规则为准，AI 可辅助提取和展示计算过程，但不作为唯一计算依据。
|
||||
- 系统应保留计算过程、公式和结果，供管理层审核。
|
||||
|
||||
### 8.6 工厂权限描述与“只作为字典数据”存在差异
|
||||
|
||||
**原始需求：**
|
||||
- 部分工厂看到内容不同、权限不同
|
||||
- 后台中又说明工厂“只作为字典数据，供管理员查看”
|
||||
|
||||
**统一后的口径：**
|
||||
- 当前版本工厂表作为基础字典维护。
|
||||
- 下发工厂时仅生成可复制文本，不建设工厂独立端。
|
||||
- 若未来确需不同工厂查看不同信息，可在后续版本做扩展。
|
||||
|
||||
### 8.7 新客户判定规则已明确，但需要和批量导入规则统一
|
||||
|
||||
**统一后的口径：**
|
||||
- 新客户识别以“手机号 + 姓名同时匹配”为准。
|
||||
- 批量导入时同样按此规则去重。
|
||||
|
||||
### 8.8 欠款提醒起算节点需配置化
|
||||
|
||||
**原始需求：**
|
||||
- 订单日期、对账日期、发货日期三种口径都可加上，由后台设置
|
||||
|
||||
**统一后的口径：**
|
||||
- 欠款超期提醒起算节点支持配置化，默认可选：订单日期、对账日期、发货日期。
|
||||
|
||||
---
|
||||
|
||||
## 9. 功能需求说明
|
||||
|
||||
## 9.1 销售订单管理
|
||||
|
||||
### 9.1.1 销售单录入并提交审核
|
||||
|
||||
**功能描述：** 业务员录入销售订单，包括客户信息、物流信息、订单信息、回扣信息等，并提交审核。
|
||||
|
||||
**业务规则：**
|
||||
- 如客户不存在，则根据手机号 + 姓名自动同步到客户库。
|
||||
- 提交后订单进入待审核状态。
|
||||
- 订单提交信息需记录提交人、提交时间。
|
||||
|
||||
**输出结果：**
|
||||
- 生成订单记录
|
||||
- 生成审核任务
|
||||
- 记录订单初始状态
|
||||
|
||||
### 9.1.2 查看个人历史销售订单
|
||||
|
||||
**功能描述：** 业务员查看自己历史提交的销售订单。
|
||||
|
||||
**权限规则：**
|
||||
- 仅能查看与本人关联的订单。
|
||||
- 显示字段按权限脱敏。
|
||||
|
||||
### 9.1.3 销售订单状态查询与追踪
|
||||
|
||||
**功能描述：** 查看订单状态与物流信息。
|
||||
|
||||
**业务规则：**
|
||||
- 物流信息对接快递 100 接口。
|
||||
- 支持订单及物流节点查询。
|
||||
|
||||
### 9.1.4 销售订单取消
|
||||
|
||||
**功能描述：** 业务员取消订单，或发起取消申请。
|
||||
|
||||
**业务规则：**
|
||||
- 待审核前可直接取消。
|
||||
- 已审批订单需何总确认。
|
||||
- 操作需记录取消原因与操作日志。
|
||||
|
||||
### 9.1.5 物流消息提醒
|
||||
|
||||
**功能描述：** 首个物流节点超时提醒业务员。
|
||||
|
||||
**业务规则：**
|
||||
- 首个节点定义为首次揽件/首次物流流转。
|
||||
- 超过 2 天无流转仅提醒一次。
|
||||
|
||||
### 9.1.6 订单进度信息通知
|
||||
|
||||
**功能描述：** 订单状态变化后向相关角色推送通知。
|
||||
|
||||
**权限规则：**
|
||||
- 业务员只看自己相关订单的有限信息。
|
||||
- 何总查看订单全部信息，包括数量、成本、回扣、利润、报价等。
|
||||
|
||||
### 9.1.7 物流图片录入与 AI 识别
|
||||
|
||||
**功能描述：** 何总秘书在泰兴工厂等场景下录入物流图片，并借助 AI 辅助识别订单信息。
|
||||
|
||||
**业务规则：**
|
||||
- 支持自动识别与人工修正。
|
||||
- 识别失败时可人工输入。
|
||||
- 相似订单需人工判断是否重复。
|
||||
|
||||
### 9.1.8 长时间未下单提醒
|
||||
|
||||
**功能描述：** 对长时间未下单客户自动提醒业务员。
|
||||
|
||||
**业务规则：**
|
||||
- 支持配置沉默周期。
|
||||
- 支持配置金额阈值。
|
||||
- 低于阈值客户可不提醒。
|
||||
|
||||
---
|
||||
|
||||
## 9.2 销售单审批管理
|
||||
|
||||
### 9.2.1 销售单最终审批
|
||||
|
||||
**功能描述：** 管理层根据订单信息进行最终审批。
|
||||
|
||||
**业务规则：**
|
||||
- 系统自动匹配产品表，计算成本、利润和利润率。
|
||||
- 审核页需展示计算过程与结果。
|
||||
- 可一键通过或退回。
|
||||
- 退回后业务员需收到通知。
|
||||
|
||||
**待确认项：**
|
||||
- 利润率阈值是否作为自动通过标准。
|
||||
- 成本缺失时如何处理。
|
||||
- 运费、税费、回扣是否计入利润。
|
||||
|
||||
### 9.2.2 审批通过后下发工厂
|
||||
|
||||
**功能描述：** 审批通过后生成可复制文本，供业务人员下发给工厂。
|
||||
|
||||
**业务规则：**
|
||||
- 当前不要求工厂端系统对接。
|
||||
- 不同工厂生成内容可不同，但本期以文本复制为主。
|
||||
|
||||
### 9.2.3 审批取消订单
|
||||
|
||||
**功能描述：** 对已审批订单进行取消审批。
|
||||
|
||||
**业务规则：**
|
||||
- 与业务员端取消逻辑统一。
|
||||
- 取消过程留痕。
|
||||
|
||||
### 9.2.4 回扣设置
|
||||
|
||||
**功能描述：** 录单时标记订单是否存在回扣，并录入金额。
|
||||
|
||||
**业务规则：**
|
||||
- 回扣金额计入利润计算。
|
||||
- 回扣信息可作为审核依据。
|
||||
|
||||
---
|
||||
|
||||
## 9.3 司机任务管理
|
||||
|
||||
### 9.3.1 查看任务详情
|
||||
|
||||
**功能描述：** 司机查看自己可执行的任务。
|
||||
|
||||
**可见信息：**
|
||||
- 取货地址
|
||||
- 取件内容
|
||||
- 数量
|
||||
- 关联工厂
|
||||
- 所属业务员部分信息
|
||||
|
||||
**不可见信息：**
|
||||
- 客户敏感信息
|
||||
- 财务敏感信息
|
||||
- 非任务相关内容
|
||||
|
||||
### 9.3.2 接单
|
||||
|
||||
**功能描述：** 司机确认接收任务。
|
||||
|
||||
### 9.3.3 确认揽货
|
||||
|
||||
**功能描述：** 司机拍照上传收货记录，并同步给业务员。
|
||||
|
||||
**业务规则：**
|
||||
- 提交前可撤回。
|
||||
- 提交后不可撤回。
|
||||
- 图片存储至 COS。
|
||||
- 通过微信订阅消息通知相关人员。
|
||||
|
||||
### 9.3.4 确认送达
|
||||
|
||||
**功能描述：** 司机确认送达仓库并更新任务状态。
|
||||
|
||||
---
|
||||
|
||||
## 9.4 产品管理
|
||||
|
||||
### 9.4.1 产品录入
|
||||
|
||||
**功能描述：** 录入产品基础信息，用于后续订单报价和成本核算。
|
||||
|
||||
**建议字段：**
|
||||
- 产品名称
|
||||
- 规格
|
||||
- 单位
|
||||
- 分类
|
||||
- 成本价
|
||||
- 售价
|
||||
- 状态
|
||||
- 备注
|
||||
|
||||
### 9.4.2 产品查询
|
||||
|
||||
**功能描述：** 支持按名称、规格、分类等条件查询产品。
|
||||
|
||||
---
|
||||
|
||||
## 9.5 工厂/供应商管理
|
||||
|
||||
### 9.5.1 维护合作工厂信息
|
||||
|
||||
**功能描述：** 维护合作工厂及供应商基础信息。
|
||||
|
||||
**业务规则：**
|
||||
- 当前作为字典数据使用。
|
||||
- 不要求工厂独立登录系统。
|
||||
|
||||
---
|
||||
|
||||
## 9.6 客户管理
|
||||
|
||||
### 9.6.1 客户信息录入与查询
|
||||
|
||||
**功能描述：** 录入和查询直接客户信息，支持批量导入。
|
||||
|
||||
**业务规则：**
|
||||
- 姓名 + 电话作为重复校验标准。
|
||||
- 支持导入模板。
|
||||
- 重复数据支持去重或提示。
|
||||
|
||||
### 9.6.2 欠款及超期提醒
|
||||
|
||||
**功能描述：** 系统自动统计月结客户欠款总额，并推送超期提醒。
|
||||
|
||||
**业务规则：**
|
||||
- 月结信息维护在客户资料中。
|
||||
- 起算节点可配置为订单日期、对账日期、发货日期。
|
||||
- 提醒对象为业务员。
|
||||
|
||||
---
|
||||
|
||||
## 9.7 员工管理
|
||||
|
||||
### 9.7.1 员工信息维护
|
||||
|
||||
**功能描述：** 管理后台维护员工基础信息。
|
||||
|
||||
**说明：** 当前原始需求未展开详细字段，后续可补充。
|
||||
|
||||
---
|
||||
|
||||
## 9.8 业绩统计报表
|
||||
|
||||
### 9.8.1 月度 / 季度 / 年度业绩统计
|
||||
|
||||
**功能描述：** 系统统计销售数据并生成可导出报表。
|
||||
|
||||
**统计维度：**
|
||||
- 订单数量
|
||||
- 订单金额
|
||||
- 工业品 / 日用品分类
|
||||
- 排除电商平台订单
|
||||
|
||||
**业务规则：**
|
||||
- 产品分类需在产品表中维护。
|
||||
- 电商平台订单需在订单数据中有来源标识。
|
||||
- 支持导出。
|
||||
|
||||
---
|
||||
|
||||
## 9.9 后台系统管理
|
||||
|
||||
### 9.9.1 后台用户管理
|
||||
|
||||
管理系统登录用户。
|
||||
|
||||
### 9.9.2 角色管理
|
||||
|
||||
管理业务员、管理层、司机、秘书、管理员等角色权限。
|
||||
|
||||
### 9.9.3 菜单管理
|
||||
|
||||
管理不同角色可访问的菜单。
|
||||
|
||||
### 9.9.4 配置管理
|
||||
|
||||
支持维护提醒周期、金额阈值、物流超时规则等配置项。
|
||||
|
||||
---
|
||||
|
||||
## 10. 权限与可见性规则
|
||||
|
||||
### 10.1 业务员
|
||||
|
||||
可查看自己订单、自己的客户、自己的任务及系统提醒。
|
||||
|
||||
### 10.2 管理层
|
||||
|
||||
可查看全量订单信息、成本、利润、回扣、报价、审批记录等。
|
||||
|
||||
### 10.3 司机
|
||||
|
||||
可查看任务信息、取货地址、取件内容、数量等，不可查看敏感财务信息。
|
||||
|
||||
### 10.4 管理员
|
||||
|
||||
可管理系统全部基础配置、用户、角色、菜单、字典及统计信息。
|
||||
|
||||
---
|
||||
|
||||
## 11. 订单状态建议
|
||||
|
||||
建议订单状态定义如下：
|
||||
|
||||
- 草稿
|
||||
- 待审核
|
||||
- 已通过
|
||||
- 已退回
|
||||
- 待下发工厂
|
||||
- 待司机接单
|
||||
- 已接单
|
||||
- 已揽货
|
||||
- 已送达
|
||||
- 已取消
|
||||
|
||||
如后续需要补充生产或发货环节，可增加：
|
||||
|
||||
- 生产中
|
||||
- 已发货
|
||||
- 已完成
|
||||
|
||||
---
|
||||
|
||||
## 12. 配置项建议
|
||||
|
||||
后台建议支持以下配置项：
|
||||
|
||||
- 物流首节点超时时间
|
||||
- 长时间未下单周期
|
||||
- 欠款提醒超时时间
|
||||
- 欠款提醒起算节点
|
||||
- 金额阈值
|
||||
- 提醒方式
|
||||
- 订单利润判断阈值
|
||||
- 是否允许某些状态取消
|
||||
|
||||
---
|
||||
|
||||
## 13. 验收标准建议
|
||||
|
||||
### 13.1 订单录入
|
||||
|
||||
- 可完成订单新增、客户自动识别、提交审核。
|
||||
- 新客户按姓名 + 手机号规则写入客户库。
|
||||
|
||||
### 13.2 审核流程
|
||||
|
||||
- 审核时可看到计算结果和计算过程。
|
||||
- 可通过、退回并触发消息通知。
|
||||
|
||||
### 13.3 取消流程
|
||||
|
||||
- 待审核订单可直接取消。
|
||||
- 已审批订单需何总确认取消。
|
||||
|
||||
### 13.4 司机任务
|
||||
|
||||
- 司机可接单、揽货、送达。
|
||||
- 揽货可上传照片并同步通知。
|
||||
|
||||
### 13.5 提醒流程
|
||||
|
||||
- 物流超时提醒可触发一次。
|
||||
- 欠款提醒和长时间未下单提醒可按配置生效。
|
||||
|
||||
### 13.6 报表
|
||||
|
||||
- 可查看月度、季度、年度业绩统计并导出。
|
||||
|
||||
---
|
||||
|
||||
## 14. 待确认问题
|
||||
|
||||
以下问题建议在进入开发前最终确认：
|
||||
|
||||
1. 利润计算公式最终版本是什么？
|
||||
2. 运费、税费、回扣是否全部计入利润？
|
||||
3. 订单进入履约阶段后，取消是否允许？
|
||||
4. 工厂文本内容是否需要区分工厂类型？
|
||||
5. AI 输出是否允许人工修改并覆盖？
|
||||
6. 月结客户的结算字段具体有哪些？
|
||||
7. 电商平台订单如何识别来源？
|
||||
8. 订单最终状态是否需要“已完成 / 已结算”？
|
||||
|
||||
---
|
||||
|
||||
## 15. 版本说明
|
||||
|
||||
本 PRD 为基于当前需求描述整理的 V1.0 草案，后续可根据业务确认继续迭代。当前文档已对原始需求中的冲突点进行统一口径处理，并将功能结构整理为可开发的标准 PRD 格式。
|
||||
35
需求描述.md
Normal file
35
需求描述.md
Normal file
@ -0,0 +1,35 @@
|
||||
需求描述
|
||||
|
||||
|
||||
| 平台 | 角色 | 模块 | 功能名称 | 功能描述 | 问题描述 | 问题解决描述 |
|
||||
| :--------: | :--: | :------: | :---------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------: |
|
||||
| WEB版 | 业务员端 | 销售订单管理 | 销售单录入，并提交审核 | 包含客户物流信息，新客户自动同步到客户数据库 | 新用户判断标准 | 根据手机号和姓名一起匹配 |
|
||||
| | | | 查看个人历史销售订单 | | | |
|
||||
| | | | 销售订单状态查询与追踪 | 包含订单和物流信息查询 | 对接那家快递平台 | 快递100接口 |
|
||||
| | | | 销售订单取消 | 没有审批过的订单可以直接取消，申请过的订单需要提交待何总确定后方可撤销 | "没有审批过的订单可以直接取消" — 那已提交但未审批的算哪种状态？建议明确状态机：草稿→待审批→已审批→生产中→已完成 | 1. 业务员提交的何总未审批的可以直接取消，中间有时差；2. 何总审批过的订单需要何总自己审批完成后才能取消 |
|
||||
| | | | 物流消息提醒 | 当生产订单第一个物流节点超过2天无流转信息时，系统自动推送提醒给对应业务员，便于及时跟进催发。 | **"第一个物流节点超过2天无流转"** — "第一个节点"定义模糊？是工厂发货还是揽收？提醒频率？只提醒一次还是循环提醒？ | 1. 第一节点的定义：从开始有物流揽件信息开始的节点作为第一个节点。2. 提醒频率：一次 |
|
||||
| | | | 订单进度信息通知 | 报价单最终审批 | 这行写的是"报价单最终审批"，但模块是销售订单，**需求错位**，需确认是文案错误还是功能错位 | 功能错位：业务员可以查看订单已有与自己关联订单的信息。只能看到订单的数量和报价。何总（管理员）看到的是整个订单的信息，包括订单的数量、成本、回扣、利润、报价等所有的方便判断该订单是否盈利的信息。 |
|
||||
| | | | （何总秘书）如果是泰兴工厂，需要录入物流图片，自动识别/手动，自动匹配对应的订单（根据产品规格数量，发送地址匹配订单） | | 自动识别匹配订单的逻辑复杂 — 根据"产品规格+数量+地址"匹配，但同一客户可能有多笔相似订单，匹配准确率如何保证？失败后的兜底方案？ | 借助豆包AI大模型，进行识别图片中订单的信息，然后将内容进行整理交给后台。相似的信息需要业务员自己去判断一下，是否订单重复。识别不出来的图片需要业务员使用输入后修改下。 |
|
||||
| | | | 长时间没下单提醒 | 长时间没下单提醒 按照订单匹配下单频率，且可以设置金额限制，低于1000元以下的小客户就不需要追踪了 | 是取历史平均间隔？最近一笔距今多久？**"可设置金额限制"** — 谁设置？在后台配置？ | 这个可以在后台管理页面设置相关信息：1. 多久没下单的用户；2. 下单金额低于多少的用户 |
|
||||
| 小程序端 | 管理层端 | 销售单管理 | 销售单最终审批 | 系统根据订单信息自动匹配产品表，计算出成本、利润及利润率，展示给审核人员（何总）。需要体现计算过程和公式，审核人员可一键通过（赚钱）或退回（亏本）。若退回，业务员需要及时收到通知 | ⚠️ **"自动匹配产品表计算成本利润"** — 产品表是否已维护完整成本数据？如果产品表无此规格怎么办？ <br>⚠️ **"需要体现计算过程和公式"** — UI展示形式？展开面板还是弹窗？ <br>⚠️ **"一键通过（赚钱）或退回（亏本）"** — 逻辑过于简化：利润率多少算"赚钱"？需可配置阈值，否则何总每次都要人工判断 | 1. 订单录入的时候，由豆包AI大模型进行逻辑处理，然后返回准确的信息。2. 计算公式和结果需要豆包的大模型进行处理过程保存。3. 将净亏多少需要表示清楚，方便判断 |
|
||||
| | | | 销售单审核通过后后台下单，分配给工厂（只需要提供一段文字供复制） | 需选工厂发货（分自提和直送），生成一段话供复制，复制给工厂负责人，备注不同工厂的权限不同（自提单只有产品采购信息，无联系方式， 泰兴和马甸，宣堡工厂可以看到除了合同价外的一切信息）<br>1 直接发货—》 泰兴和马甸工厂<br>2 外送工厂，通知AB生产加工，由司机自提，最终送至总部仓库 | 🔴 **核心逻辑混乱**： <br>1. "生成一段话供复制" — 这是**半自动化**，不是系统对接，工厂端无系统？那后续工厂进度如何同步回系统？ <br>2. **权限控制复杂**：自提单隐藏联系方式、不同工厂看到的信息不同 — 需在数据库层做字段级权限控制，开发成本高 <br>3. **"外送工厂→AB加工→司机自提→送总部仓库"** — 这个流程涉及多段物流，系统中如何追踪？状态如何流转？ | 1. 自提：生成与订单内容相关的话：数量、类型，用户可以直接复制信息；2. 泰兴、马甸、宣堡这几个工厂生成的内容为订单的数量、价格信息 |
|
||||
| | | | 审批取消订单 | 审批过订单需要何总确认审批 | ⚠️ 与业务员端的"取消"逻辑重复，需统一：业务员申请取消 → 何总审批取消，还是何总直接取消？ | 和之前的一样， |
|
||||
| | | | 回扣设置 | 设置回扣是否完成 | ⚠️ **过于简略**："设置回扣否完成" — 是标记提成发放状态？还是计算金额？回扣规则是什么？ | 业务员在提交订单的时候，如果该订单有回扣，需要标明出来，并指出回扣的金额数量，在计算该订单是否盈利的逻辑中需要考虑到回扣 |
|
||||
| | | | 查看历史销售订单 | | | |
|
||||
| 小程序端 | 司机端 | 任务管理 | 查看任务详情 | 可以查看产品规格，所属业务员，其他信息不暴露，由于哪些工厂加工 | ⚠️ **"由于哪些工厂加工"** — 文案不通顺，应为"由哪些工厂加工"？ <br>⚠️ **"其他信息不暴露"** — 需明确"其他"范围：客户信息？价格？业务员联系方式？ | 可以看到去哪里取货的地址、取件内容、数量等信息，涉密信息看不到 |
|
||||
| | | | 接单 | | | |
|
||||
| | | | 确认揽货 | 拍照上传记录收货，并同步给业务员 | ⚠️ 状态流转是否可逆？如误点"送达"能否撤回？ <br>⚠️ **"拍照上传"** — 照片存储策略？有效期？压缩规则？推送方式？微信订阅消息？还是小程序内消息？ | 可以撤回，在提交之前可以撤回，提交后就撤回不了了。照片存储在cos里面，微信订阅推送 |
|
||||
| | | | 确认送达 | 货物送达仓库，变更任务状态 | | |
|
||||
| 管理后台（WEB端） | | 产品管理 | 产品录入 | 录入产品的基本信息，用于后期报价关联生产的价格核算 | ⚠️ **"用于后期报价关联生产的价格核算"** — 需要哪些字段？成本价？市场价？规格参数？BOM清单？目前信息不足，无法设计表结构 | |
|
||||
| | | | 产品查询 | | | |
|
||||
| | | 工厂/供应商管理 | 维护所有合作工厂及供应商信息 | | ⚠️ 与"下单给工厂"的权限控制关联，需确认工厂账号体系：工厂是否登录本系统？还是仅作为数据字典？ | 只作为字典数据，供管理员查看 |
|
||||
| | | 销售单管理 | 查看历史销售单 | | | |
|
||||
| | | 客户管理 | 直接客户的信息录入和查询 | 批量导入 | ⚠️ 导入模板格式？字段校验规则？重复数据处理？ | 设计导入模版，根据姓名和电话进行校验，重复数据去重处理 |
|
||||
| | | | 接收欠款及超期提醒 | 系统自动计算月结客户的欠款总额，对超过30天未结算的订单，自动推送提醒给对应业务员，提醒催收。 | ⚠️ **"月结客户"** — 结算方式是否在客户资料中维护？ <br>⚠️ **"超过30天未结算"** — 起算点是订单日期？发货日期？对账日期？ <br>⚠️ 提醒给谁？业务员还是财务？ | 存入客户的资料中；起算节点三中类型的都加上，订单日期、对账日期、发货日期，可以在后台设置。内容提醒给业务员，需要让业务员去处理 |
|
||||
| | | 员工管理 | | | | |
|
||||
| | | 业绩统计报表 | 查看整体月度/季度/年度业绩 | 系统自动统计销售数据，按工业品、日用品拆分，剔除电商平台的订单，生成可导出的报表，方便核对提成。订单数量，订单金额。 | ⚠️ **"按工业品、日用品拆分"** — 产品分类标准？在产品表中维护？ <br>⚠️ **"剔除电商平台订单"** — 如何识别电商平台订单？订单来源字段？ <br>⚠️ **"方便核对提成"** — 提成计算逻辑仍未明确，报表无法设计 | |
|
||||
| | | 后台系统管理 | 后台用户管理 | | | |
|
||||
| | | | 角色管理 | | | |
|
||||
| | | | 菜单管理 | | | |
|
||||
| | | | 配置管理 | 可以设置未收到订单提醒的周期时长 | **"未收到订单提醒的周期时长"** — 与前面的"2天物流提醒"是同一配置？还是独立配置？ | 单独配置 |
|
||||
|
||||
Loading…
Reference in New Issue
Block a user