提交
This commit is contained in:
151
README.md
151
README.md
@@ -84,7 +84,7 @@ Artisan Factory
|
||||
|
||||
## 4. 典型行业解决方案
|
||||
|
||||
匠厂已服务物流、制造、电商、财务、营销、人力等多个行业客户，并按职能沉淀了可复用的智能体能力。以下是将交付经验翻译为客户能直接理解的业务场景——实际项目会根据您的流程重新组合和开发，而非套用固定套餐。
|
||||
匠厂已服务物流、制造、电商、财务、营销、人力等多个行业客户，并按职能沉淀了可复用的智能体能力。以下是将交付经验整理为**更完整的行业与职能解决方案矩阵**——实际项目会根据您的流程重新组合和开发，而非套用固定套餐。
|
||||
|
||||
### 4.1 物流与货代
|
||||
|
||||
@@ -107,7 +107,7 @@ Artisan Factory
|
||||
|
||||
**价值**
|
||||
|
||||
减少机械查询、提高异常发现及时性，让业务员把时间放回客户沟通和异常处理。
|
||||
减少机械查询与手工抄录，异常更早进入待处理列表，让业务员把时间放回客户沟通和问题处理上。
|
||||
|
||||
### 4.2 跨境电商
|
||||
|
||||
@@ -131,7 +131,7 @@ Artisan Factory
|
||||
|
||||
**价值**
|
||||
|
||||
减少重复运营动作、提高资料整理效率，帮助团队更快发现异常。
|
||||
减少多平台重复操作，提升 Listing 与经营数据整理效率，帮助团队更快发现订单与库存异常。
|
||||
|
||||
### 4.3 淘宝 / 天猫电商
|
||||
|
||||
@@ -141,6 +141,7 @@ Artisan Factory
|
||||
- 客服咨询、售后、评价处理压力大
|
||||
- 店铺活动、价格、库存需要频繁检查
|
||||
- 多店铺运营数据汇总慢，难以及时掌握整体情况
|
||||
- 运营人员大量时间花在后台操作和表格整理上
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
@@ -153,7 +154,7 @@ Artisan Factory
|
||||
|
||||
**价值**
|
||||
|
||||
降低商品维护和后台巡检的重复劳动，让运营团队把精力放在活动策划和转化提升上。
|
||||
减少重复运营动作，提升商品资料和店铺数据整理效率，让运营把更多时间放在选品、活动和客户体验上。
|
||||
|
||||
### 4.4 制造业
|
||||
|
||||
@@ -207,6 +208,7 @@ Artisan Factory
|
||||
- 公众号、头条、搜狐、知乎、小红书等平台格式要求不同
|
||||
- 发布记录、链接、状态需要人工维护
|
||||
- 内容团队大量时间花在复制、排版、登录后台上
|
||||
- 线索采集和整理分散在多个渠道
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
@@ -229,6 +231,7 @@ Artisan Factory
|
||||
- 面试安排沟通成本高，协调多方时间繁琐
|
||||
- 员工制度咨询重复，HR 反复回答同类问题
|
||||
- 入职账号、权限、资料流程繁琐，容易遗漏
|
||||
- 考勤、薪酬、绩效数据核对工作量大
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
@@ -241,7 +244,7 @@ Artisan Factory
|
||||
|
||||
**价值**
|
||||
|
||||
减少 HR 事务性工作，让团队更聚焦人才评估、员工发展和组织建设。
|
||||
减少 HR 在筛选、沟通、答疑和资料处理上的重复工作，让 HR 更聚焦组织沟通和人才判断。
|
||||
|
||||
### 4.8 教育培训
|
||||
|
||||
@@ -251,6 +254,7 @@ Artisan Factory
|
||||
- 课程资料整理耗时，版本更新后同步慢
|
||||
- 作业、测评、反馈依赖人工，批改和汇总压力大
|
||||
- 教务通知和排课协调琐碎，容易遗漏或延迟
|
||||
- 学员学习情况汇总不及时
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
@@ -259,10 +263,11 @@ Artisan Factory
|
||||
- 作业批改辅助智能体
|
||||
- 学习反馈生成智能体
|
||||
- 教务通知智能体
|
||||
- 学员进度跟进智能体
|
||||
|
||||
**价值**
|
||||
|
||||
减轻教务和客服的重复劳动，让教师把更多时间用于教学质量和学员服务。
|
||||
帮助教务、老师和运营减少重复答疑与资料整理，把更多精力放在教学质量和学员服务上。
|
||||
|
||||
### 4.9 企业内部知识助手
|
||||
|
||||
@@ -284,15 +289,15 @@ Artisan Factory
|
||||
|
||||
**价值**
|
||||
|
||||
减少“问老员工”的依赖，加快新员工上手，让制度和产品知识随时可查、有据可依。
|
||||
减少“问老员工”的依赖，加快新员工上手，让制度、流程、产品和系统操作知识随时可查。
|
||||
|
||||
### 4.10 通用流程自动化
|
||||
|
||||
**客户痛点**
|
||||
|
||||
- 各行业都有表格整理、文件命名、批量录入、邮件处理、日报生成等重复工作
|
||||
- 这些工作规则相对明确，但分散在各部门日常操作中，长期占用一线员工时间
|
||||
- 缺乏统一工具，往往靠个人 Excel 技巧或临时脚本凑合
|
||||
- 流程看似简单，但每天都做，占用大量碎片时间
|
||||
- 同类工作由不同员工处理，格式和质量不稳定
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
@@ -301,10 +306,11 @@ Artisan Factory
|
||||
- 文件归档智能体
|
||||
- 数据录入智能体
|
||||
- 日报 / 周报生成智能体
|
||||
- 批量查询与核对智能体
|
||||
|
||||
**价值**
|
||||
|
||||
把各部门共性的重复劳动标准化、自动化，快速见效，也便于作为智能体落地的首个试点场景。
|
||||
先从最容易验收的小流程切入，快速验证智能体价值，再逐步扩展到更复杂的业务场景。
|
||||
|
||||
---
|
||||
|
||||
@@ -316,106 +322,99 @@ Artisan Factory
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某国际货代企业（客户名称已匿名处理），业务员需频繁向客户反馈物流状态 |
|
||||
| **原业务流程** | 业务员逐票登录船公司/航司网站或第三方平台查询轨迹，手工记录后回复客户；异常往往在客户催问时才发现 |
|
||||
| **主要问题** | 机械查询占用大量时间；异常发现滞后；同一客户多次催问增加沟通成本 |
|
||||
| **匠厂交付内容** | 运单轨迹查询智能体：按批次自动查询并汇总状态；对超时未更新、状态异常等情形生成提醒清单；配套执行日志与汇总报表 |
|
||||
| **人工确认节点** | 异常提醒发送给客户前，由业务员确认内容；不自动对外发送 |
|
||||
| **上线后变化** | 机械查询时间明显减少；异常项更早进入待处理列表；业务员回复客户时可直接引用汇总结果 |
|
||||
| **适用边界** | 需客户提供可查询的运单号和授权访问方式；部分船公司/渠道查询规则可能需单独适配 |
|
||||
| **客户类型** | 某国际货代企业（客户名称已匿名处理），主营海运拼箱与空运出口，业务员每日需向多家客户反馈在途货物状态 |
|
||||
| **原业务流程** | 业务员早晨打开 Excel 运单清单，逐票登录船公司网站、航司货况页或第三方轨迹平台查询；将状态手工抄入表格，再通过企业微信或邮件回复客户。遇到船期延误、清关停滞等情况，往往在客户主动催问后才着手核实 |
|
||||
| **主要问题** | 单票查询耗时长，批量处理时机械操作占用半天；异常发现滞后，影响客户体验；同一票多次查询结果分散，不便汇总复盘 |
|
||||
| **匠厂交付内容** | 运单轨迹查询智能体：导入当日待跟进运单清单，按船公司/渠道规则批量查询并归集状态；对超过设定天数未更新、状态跳变异常、到港未提货等情形生成待处理清单；输出汇总表与执行日志，支持按客户、航线筛选 |
|
||||
| **人工确认节点** | 异常提醒对外发送前，由业务员逐条确认表述内容；涉及赔偿、责任认定等事项不自动生成对外口径 |
|
||||
| **上线后变化** | 机械查询时间明显减少；异常项更早进入待处理列表；业务员回复客户时可直接引用汇总结果，减少重复登录查询 |
|
||||
| **适用边界** | 需客户提供可查询的运单号及各渠道授权访问方式；部分船公司反爬或登录规则变更时需单独维护适配 |
|
||||
|
||||
### 项目案例 2：某货代企业询价整理与报价草稿
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某货代企业（客户名称已匿名处理），销售团队每日收到大量询价 |
|
||||
| **原业务流程** | 销售从微信、邮件、Excel 等渠道复制询价信息，手工核对起运港、目的港、柜型、货量等字段，再查询运价表生成报价 |
|
||||
| **主要问题** | 询价信息格式不统一，整理耗时；报价草稿重复劳动多；新人不熟悉渠道和价格结构 |
|
||||
| **匠厂交付内容** | 询价整理智能体：从多渠道提取并标准化询价字段；结合客户运价规则生成报价草稿；输出结构化询价台账供销售审核 |
|
||||
| **人工确认节点** | 报价发送前必须由销售确认金额和条款；智能体不自动对外报价 |
|
||||
| **上线后变化** | 询价整理效率提高；报价草稿生成更快；销售可将更多时间用于客户沟通和议价 |
|
||||
| **适用边界** | 需客户提供历史询价样例和运价规则；复杂或非标询价仍需人工判断 |
|
||||
| **客户类型** | 某货代企业（客户名称已匿名处理），销售团队同时对接直客与同行，每日询价来自微信截图、邮件正文、Excel 附件等多种形态 |
|
||||
| **原业务流程** | 销售将各渠道询价信息复制到统一 Excel，手工补全起运港、目的港、柜型、货量、贸易条款等字段；再翻查内部运价表或向航线同事确认，最后整理成报价邮件发给客户。旺季时销售同时处理十几条询价，容易漏字段或报重报漏 |
|
||||
| **主要问题** | 询价来源分散、格式不一，整理占用大量时间；报价草稿重复劳动多；新人不熟悉各航线命名和附加费规则，出错率高 |
|
||||
| **匠厂交付内容** | 询价整理智能体：从微信文字、邮件、表格中提取并标准化询价字段，标注缺失项；结合客户运价规则与附加费模板生成报价草稿；输出结构化询价台账，供销售逐条审核后发送 |
|
||||
| **人工确认节点** | 报价金额、附加费、有效期等条款发送前必须由销售确认；智能体不自动对外报价，不代替商务谈判 |
|
||||
| **上线后变化** | 询价整理效率提高；报价草稿生成更快；销售可将更多时间用于客户沟通和议价，人工整理压力下降 |
|
||||
| **适用边界** | 需客户提供历史询价样例、运价表及附加费规则；复杂联运、特种柜、危险品等非标询价仍需人工判断 |
|
||||
|
||||
### 项目案例 3：某企业财务对账表自动整理与差异标记
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某有跨境及物流业务的企业（客户名称、财务系统名称已脱敏） |
|
||||
| **原业务流程** | 财务人员下载各渠道账单，手工整理为统一格式，逐行与内部系统数据核对，标记差异后逐笔追查 |
|
||||
| **主要问题** | 账单格式不统一，整理工作量大；月结期间压力大；差异项定位慢，容易遗漏 |
|
||||
| **匠厂交付内容** | 对账整理智能体：自动识别并归一化账单格式；按规则比对内部数据，输出差异清单；配套对账模板与执行日志 |
|
||||
| **人工确认节点** | 差异项的处理结论、调账和付款动作均由财务人员确认后执行 |
|
||||
| **上线后变化** | 对账表整理时间缩短；差异项定位更快；财务人员可集中精力处理有争议的条目 |
|
||||
| **适用边界** | 需客户提供历史账单样例和内部对账规则；首次上线建议从 1–2 个渠道试点 |
|
||||
| **客户类型** | 某有跨境及物流业务的企业（客户名称、财务系统名称已脱敏），每月需与多家承运商、海外仓、平台方核对运费与服务费 |
|
||||
| **原业务流程** | 月结前，财务人员从邮箱下载各渠道 PDF、Excel 账单，按内部模板手工整理字段；再导出业务系统明细，逐行比对单号、金额、币种、计费重量等；发现差异后标注颜色、写备注，逐笔联系业务或供应商核实 |
|
||||
| **主要问题** | 账单格式五花八门，整理阶段就占用大量时间；月结窗口短、压力大；差异项散落在多张表里，定位慢、容易遗漏重复计费或漏录 |
|
||||
| **匠厂交付内容** | 对账整理智能体：识别并归一化各渠道账单格式，映射到统一对账模板；按预设规则与内部明细比对，输出差异清单（多计、少计、单号不匹配等）；配套对账模板、差异分类规则与执行日志 |
|
||||
| **人工确认节点** | 差异项的处理结论、调账申请、付款审批均由财务人员确认后执行；智能体不自动修改财务系统数据 |
|
||||
| **上线后变化** | 对账表整理时间缩短；差异项定位更快；财务人员可集中精力处理有争议的条目，人工审核更聚焦 |
|
||||
| **适用边界** | 需客户提供历史账单样例和内部对账规则；首次上线建议从 1–2 个渠道试点，规则稳定后再扩展 |
|
||||
|
||||
### 项目案例 4：某制造企业供应商报价比对与采购建议
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某制造业客户（客户名称已匿名处理），采购部门定期向多家供应商询价 |
|
||||
| **原业务流程** | 采购员收集各供应商报价（邮件/Excel/微信），手工填入对比表，逐项核对后提交采购经理审批 |
|
||||
| **主要问题** | 报价格式不统一，整理费时；历史报价难追溯；新人不熟悉比价维度和供应商特点 |
|
||||
| **匠厂交付内容** | 供应商报价比对智能体：自动提取并标准化报价字段，生成对比表和采购建议草稿；支持按物料、供应商维度归档历史报价 |
|
||||
| **人工确认节点** | 最终采购决策和下单由采购经理确认；智能体仅提供整理和建议，不自动下单 |
|
||||
| **客户类型** | 某制造业客户（客户名称已匿名处理），原材料品类多，采购部门需定期向多家供应商询价并提交比价审批 |
|
||||
| **原业务流程** | 采购员发出询价后，陆续收到供应商邮件、微信文件或纸质扫描件；手工将报价填入对比表，核对单价、起订量、交期、付款方式、是否含运费等维度；整理完成后提交采购经理审批，历史报价多靠个人文件夹保存，检索不便 |
|
||||
| **主要问题** | 报价格式不统一，整理费时；比价维度多时容易漏项；历史报价难追溯，新人不熟悉各供应商报价习惯 |
|
||||
| **匠厂交付内容** | 供应商报价比对智能体：从邮件、Excel、图片报价单中提取并标准化字段；按物料生成横向对比表，标注最优项与异常报价；输出采购建议草稿，支持按物料、供应商归档历史报价供检索 |
|
||||
| **人工确认节点** | 最终供应商选择、合同条款和下单动作由采购经理确认；智能体仅提供整理和建议，不自动下单 |
|
||||
| **上线后变化** | 报价比对整理效率提高；采购建议更有据可查；比价规则可沉淀复用，减少对个人经验的依赖 |
|
||||
| **适用边界** | 需客户提供报价样例和比价维度；战略采购、非标物料等复杂决策仍需人工判断 |
|
||||
| **适用边界** | 需客户提供报价样例和比价维度；战略采购、独家物料、非标规格等复杂决策仍需人工判断 |
|
||||
|
||||
### 项目案例 5：某电商运营团队商品资料整理与 Listing 草稿生成
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某电商运营团队（客户名称已匿名处理），经营多平台跨境店铺 |
|
||||
| **原业务流程** | 运营从供应商资料、竞品页面、内部表格中提取商品信息，手工整理标题、卖点、属性后录入各平台后台 |
|
||||
| **主要问题** | 商品资料来源分散，整理重复；多平台格式要求不同，录入耗时；上新节奏快时人工压力大 |
|
||||
| **匠厂交付内容** | 商品资料整理智能体与 Listing 草稿生成智能体：从原始资料提取并标准化字段，按平台规则生成标题、详情草稿；输出待审核清单 |
|
||||
| **人工确认节点** | 商品上架、价格调整等操作由运营人员审核确认后执行；不自动发布 |
|
||||
| **上线后变化** | 商品资料整理效率提高；Listing 草稿生成更快；运营可将更多时间用于选品和投放优化 |
|
||||
| **适用边界** | 需客户提供商品资料样例和各平台字段规则；品牌调性和敏感表述需人工把关 |
|
||||
| **客户类型** | 某电商运营团队（客户名称已匿名处理），同时经营淘宝、天猫及跨境平台店铺，SKU 更新频繁 |
|
||||
| **原业务流程** | 运营从供应商提供的规格表、竞品详情页、内部产品库中提取信息；按各平台要求分别编写标题、卖点、属性、详情图文结构；上新高峰期需反复登录卖家后台录入，并手工维护一份商品资料总表供团队协同 |
|
||||
| **主要问题** | 商品资料来源分散，同一 SKU 在多平台重复整理；各平台字段长度、违禁词、类目属性要求不同，录入耗时；人工维护表格易与后台不同步 |
|
||||
| **匠厂交付内容** | 商品资料整理智能体：从原始资料提取并标准化 SKU 字段，合并去重；Listing 草稿生成智能体：按淘宝/天猫及跨境平台规则分别生成标题、卖点、属性草稿；输出待审核清单，标注各平台差异项与敏感词提示 |
|
||||
| **人工确认节点** | 商品上架、价格调整、促销活动设置等操作由运营人员审核确认后执行；不自动发布，不自动改价 |
|
||||
| **上线后变化** | 商品资料整理效率提高；Listing 草稿生成更快；运营可将更多时间用于选品、活动和客户体验优化 |
|
||||
| **适用边界** | 需客户提供商品资料样例和各平台字段规则；品牌调性、夸大宣传及平台敏感表述需人工把关 |
|
||||
|
||||
### 项目案例 6：某内容运营团队多平台文章发布自动化
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某内容运营团队（客户名称已匿名处理），需在多个自媒体平台同步发布内容 |
|
||||
| **原业务流程** | 编辑完成稿件后，运营逐平台登录后台，调整格式、上传配图、填写标签，手工记录发布链接和状态 |
|
||||
| **主要问题** | 多平台格式要求不同，重复操作多；发布记录分散，难以统一追踪；内容团队大量时间耗在后台操作上 |
|
||||
| **匠厂交付内容** | 多平台文章发布智能体：按各平台格式要求自动排版和发布；内容发布记录整理智能体：汇总发布链接、状态和时间；配套发布日志 |
|
||||
| **人工确认节点** | 文章发布前由编辑或运营审核确认；敏感内容和高风险账号不自动发布 |
|
||||
| **上线后变化** | 重复发布操作减少；发布记录整理更及时；内容团队可将更多时间用于选题和内容质量 |
|
||||
| **适用边界** | 需客户提供各平台账号授权和发布规范；部分平台界面变更时需同步维护适配规则 |
|
||||
| **客户类型** | 某内容运营团队（客户名称已匿名处理），为企业客户提供公众号、头条号、搜狐号、知乎等多平台内容分发服务 |
|
||||
| **原业务流程** | 编辑在 Word 或飞书完成定稿后，运营按各平台要求调整标题字数、段落格式、封面比例和标签；逐平台登录后台上传配图、粘贴正文、设置原创声明；发布后在共享表格中手工记录链接、发布时间和阅读量截图，周报时再汇总 |
|
||||
| **主要问题** | 同一篇文章需重复排版发布，操作琐碎；各平台后台界面不同，新人上手慢；发布记录分散，复盘和向客户汇报时需重新整理 |
|
||||
| **匠厂交付内容** | 多平台文章发布智能体：按各平台格式要求自动排版并执行发布；内容发布记录整理智能体：汇总各平台链接、发布状态和时间；配套发布日志，支持按客户、账号、日期检索 |
|
||||
| **人工确认节点** | 文章发布前由编辑或运营审核确认正文与配图；涉政敏感、客户品牌口径及高风险账号不自动发布 |
|
||||
| **上线后变化** | 重复发布操作减少；发布记录整理更及时；内容团队可将更多时间用于选题、改稿和转化跟进 |
|
||||
| **适用边界** | 需客户提供各平台账号授权和发布规范；部分平台界面或审核规则变更时需同步维护适配 |
|
||||
|
||||
### 项目案例 7：某企业 HR 简历初筛与面试协调
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某企业人力资源部门（客户名称已匿名处理），招聘需求量大、岗位类型多 |
|
||||
| **原业务流程** | HR 逐份阅读简历，按岗位要求手工筛选；协调面试官与候选人的时间，通过邮件或即时通讯反复沟通 |
|
||||
| **主要问题** | 简历初筛耗时，标准难以统一；面试安排沟通成本高；同类制度咨询反复占用 HR 时间 |
|
||||
| **匠厂交付内容** | 简历初筛智能体：按岗位 JD 和筛选规则输出初筛结果与推荐理由；面试协调智能体：汇总可用时间并生成协调建议；员工政策问答智能体辅助制度咨询 |
|
||||
| **人工确认节点** | 进入面试环节的候选人由 HR 最终确认；面试时间和地点发送前需 HR 审核 |
|
||||
| **上线后变化** | 简历初筛效率提高；面试协调沟通次数减少；HR 审核更聚焦，事务性工作压力下降 |
|
||||
| **适用边界** | 需客户提供岗位 JD、筛选标准和历史简历样例；最终录用决策仍由 HR 和用人部门做出 |
|
||||
| **客户类型** | 某企业人力资源部门（客户名称已匿名处理），业务扩张期同时开放销售、运营、技术等十余类岗位招聘 |
|
||||
| **原业务流程** | HR 每日从招聘平台导出简历，逐份阅读并对照 JD 标注是否进入下一轮；确定候选人后，通过邮件或企业微信与用人部门面试官、候选人多方协调面试时间；员工常就请假、报销、制度条款向 HR 重复咨询 |
|
||||
| **主要问题** | 简历量大时初筛占用整块工作时间；面试协调来回沟通多，改期频繁；制度类咨询打断 HR 核心招聘工作 |
|
||||
| **匠厂交付内容** | 简历初筛智能体：按岗位 JD 和硬性条件输出初筛结果与推荐理由，标注存疑项；面试协调智能体：汇总面试官可用时段，生成协调建议供 HR 确认发送；员工政策问答智能体：基于制度文档回答常见咨询并引用出处 |
|
||||
| **人工确认节点** | 进入面试环节的候选人由 HR 最终确认；面试邀请、时间变更通知发送前需 HR 审核；录用决策仍由 HR 与用人部门共同做出 |
|
||||
| **上线后变化** | 简历初筛效率提高；面试协调沟通次数减少；重复制度咨询减少，HR 审核更聚焦，事务性工作压力下降 |
|
||||
| **适用边界** | 需客户提供岗位 JD、筛选标准和经审核的制度文档；高端岗位、管理岗等需深度评估的候选人仍建议人工通读简历 |
|
||||
|
||||
### 项目案例 8：某企业内部 SOP / ERP 操作知识库助手
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某制造企业（客户名称、ERP 系统名称已脱敏），员工频繁查询操作流程和制度 |
|
||||
| **原业务流程** | 员工遇到操作问题先问老员工或翻找分散的文档；SOP 更新后难以及时同步到一线；新员工上手依赖口头传授 |
|
||||
| **主要问题** | 重复咨询多，老员工被打断频繁；文档版本不统一，查找困难；培训成本高、周期长 |
|
||||
| **匠厂交付内容** | 企业知识库与问答助手：导入 ERP 操作手册、SOP、制度文件和产品资料；支持自然语言查询并引用原文出处；配套知识更新流程说明 |
|
||||
| **人工确认节点** | 知识库内容更新由管理员审核后生效；涉及权限变更、财务操作等敏感问题引导至人工处理 |
|
||||
| **上线后变化** | 重复咨询减少；新员工上手更快；制度和产品知识查询更便捷，回答可溯源 |
|
||||
| **适用边界** | 需客户提供经审核的文档资料；知识库需随制度变更定期维护，不宜一劳永逸 |
|
||||
| **客户类型** | 某制造企业（客户名称、ERP 系统名称已脱敏），仓库、生产、采购等部门员工日常频繁查询系统操作与内部制度 |
|
||||
| **原业务流程** | 员工遇到“这个单据怎么录”“退货流程怎么走”等问题，习惯直接问邻座老员工或在各群重复提问；SOP 文档存放在共享盘多个文件夹，版本不一；新员工入职前两周大量时间花在跟岗记笔记上 |
|
||||
| **主要问题** | 重复咨询多，老员工频繁被打断；文档查找路径不统一，答非所问时有发生；制度或流程更新后，一线知晓滞后 |
|
||||
| **匠厂交付内容** | 企业知识库与问答助手：导入 ERP 操作手册、仓储 SOP、采购制度、产品资料等经审核文档；支持自然语言提问并引用原文段落；配置敏感问题（如权限变更、财务过账）转人工处理规则；提供知识更新与下架流程说明 |
|
||||
| **人工确认节点** | 知识库新增或变更内容经管理员审核后生效；涉及金额、权限、合规等事项自动引导至对应负责人，不直接给出操作建议 |
|
||||
| **上线后变化** | 重复咨询减少；新员工上手更快；制度、流程和系统操作知识查询更便捷，回答可溯源到原文 |
|
||||
| **适用边界** | 需客户提供经审核的文档资料；知识库需随制度与系统变更定期维护，不宜一劳永逸 |
|
||||
|
||||
更多项目案例可按行业继续整理为独立案例页，例如：
|
||||
|
||||
- 物流与货代项目案例
|
||||
- 制造业项目案例
|
||||
- 财务与对账项目案例
|
||||
- 电商运营项目案例
|
||||
- 市场营销自动化项目案例
|
||||
- 人力资源智能体项目案例
|
||||
更多项目案例请查看：[匠厂 AI 智能体项目案例库](./cases/README.md)
|
||||
|
||||
---
|
||||
|
||||
@@ -427,7 +426,7 @@ Artisan Factory
|
||||
| **是否能操作流程** | 需要人自己操作 | 能操作但理解弱 | 可理解、可执行、可审核 |
|
||||
| **适合场景** | 问答、写作 | 固定页面操作 | 跨系统、跨文档、跨流程的业务任务 |
|
||||
| **风险控制** | 依赖人工判断 | 脚本异常需维护 | 人工确认 + 日志追溯 + 异常回退 |
|
||||
| **价值重点** | 给建议 | 替代点击 | 让智能体参与日常工作 |
|
||||
| **价值重点** | 给建议 | 减少重复点击 | 让智能体参与日常工作 |
|
||||
|
||||
匠厂不是让 AI 直接盲目操作系统，而是把 **AI 理解能力、Python 技能、OpenClaw 自动化、RPA/API 集成和人工审核** 组合起来，让智能体在可控边界内处理真实工作——能读懂业务、能执行动作、能留痕追溯、关键节点有人把关。
|
||||
|
||||
@@ -459,6 +458,8 @@ Artisan Factory
|
||||
|
||||
试点周期通常为数周，具体取决于流程复杂度和数据准备情况。先跑通、再扩展，降低决策风险。
|
||||
|
||||
如果您想判断自己的流程是否适合先做试点，可以查看：[AI 智能体试点启动指南](./quick-start.md)
|
||||
|
||||
---
|
||||
|
||||
## 8. 我们如何交付
|
||||
@@ -559,7 +560,7 @@ Artisan Factory
|
||||
### 不适合
|
||||
|
||||
- 完全没有流程、没有样例数据可参考
|
||||
- 希望 AI 立刻替代所有相关岗位员工
|
||||
- 期望智能体无需人工复核即可承担全部岗位工作
|
||||
- 不愿意提供测试账号或样例资料
|
||||
- 高风险动作不愿设置人工确认节点
|
||||
- 期望不维护、不迭代的一次性项目
|
||||
|
||||
30
cases/README.md
Normal file
30
cases/README.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# 匠厂 AI 智能体项目案例库
|
||||
|
||||
以下案例来自匠厂实际交付或服务过的业务场景。因客户商业保密要求，部分客户名称、系统名称和业务数据已做匿名处理，但流程、问题和交付方式均来自真实项目经验。案例用于帮助客户判断：类似流程是否适合用 AI 智能体落地。
|
||||
|
||||
| 案例 | 适用行业 | 解决的问题 | 查看 |
|
||||
|---|---|---|---|
|
||||
| 某国际货代企业批量查轨迹与异常提醒 | 物流与货代 | 批量轨迹查询、异常提醒、客户通知草稿 | [查看](./logistics-tracking-alert.md) |
|
||||
| 某货代企业询价整理与报价草稿 | 物流与货代 | 询价字段提取、报价草稿、跟进提醒 | [查看](./logistics-rfq-quote.md) |
|
||||
| 某企业财务对账表自动整理与差异标记 | 财务与对账 | 账单归一化、差异标记、月结辅助 | [查看](./finance-reconciliation.md) |
|
||||
| 某制造企业供应商报价比对与采购建议 | 制造业 | 报价提取、比价表、采购建议草稿 | [查看](./manufacturing-supplier-quote.md) |
|
||||
| 某电商运营团队商品资料整理与 Listing 草稿生成 | 电商 | 商品资料整理、Listing 草稿、多平台字段差异 | [查看](./ecommerce-listing-ops.md) |
|
||||
| 某内容运营团队多平台文章发布自动化 | 市场营销 | 多平台发布、发布记录整理、状态追踪 | [查看](./marketing-multi-platform-publish.md) |
|
||||
| 某企业 HR 简历初筛与面试协调 | 人力资源 | 简历初筛、面试协调、员工政策问答 | [查看](./hr-resume-screening.md) |
|
||||
| 某企业内部 SOP / ERP 操作知识库助手 | 企业知识库 | SOP 问答、ERP 操作问答、新人培训 | [查看](./knowledge-base-assistant.md) |
|
||||
|
||||
如果您不确定自己的流程是否适合做智能体，可以先从一个高频、重复、可复核的小场景开始评估。
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回首页](../README.md)
|
||||
115
cases/ecommerce-listing-ops.md
Normal file
115
cases/ecommerce-listing-ops.md
Normal file
@@ -0,0 +1,115 @@
|
||||
# 项目案例：某电商运营团队商品资料整理与 Listing 草稿生成
|
||||
|
||||
## 1. 客户背景
|
||||
|
||||
某电商运营团队（客户名称已匿名处理），同时经营淘宝、天猫及跨境平台店铺，SKU 更新频繁。团队有运营、文案和客服分工，但商品资料整理和后台录入仍高度依赖运营手工完成。上新高峰期，同一 SKU 需在多平台重复维护标题、属性、详情结构。
|
||||
|
||||
## 2. 原业务流程
|
||||
|
||||
1. 运营从供应商规格表、竞品详情页、内部产品库收集原始资料
|
||||
2. 在共享 Excel「商品资料总表」中整理 SKU、规格、卖点、材质、尺寸等字段
|
||||
3. 按淘宝、天猫、跨境平台各自要求，分别编写标题、副标题、属性、详情图文大纲
|
||||
4. 登录各卖家后台，逐项录入或批量导入；检查类目、属性是否匹配
|
||||
5. 上新后由同事交叉检查违禁词、价格、库存是否与总表一致
|
||||
6. 活动期价格、库存变更时，再次登录多后台分别修改
|
||||
|
||||
各平台字段长度、必填属性、敏感词规则不同，人工维护总表与后台易不同步。
|
||||
|
||||
## 3. 主要问题
|
||||
|
||||
- 商品资料来源分散，同一 SKU 在多平台重复整理
|
||||
- 各平台字段与类目要求不同，录入耗时长
|
||||
- 人工维护总表与后台状态易脱节
|
||||
- 上新高峰期运营压力大，易漏填属性或触发平台违规提示
|
||||
- 品牌调性与敏感表述依赖个人把握，新人上手慢
|
||||
|
||||
## 4. 匠厂交付内容
|
||||
|
||||
**商品资料整理智能体**
|
||||
|
||||
- 从规格表、竞品页、内部表格提取并标准化 SKU 字段
|
||||
- 合并去重，输出统一商品资料底稿
|
||||
- 标注各平台差异项（字段长度、必填属性、类目映射）
|
||||
|
||||
**Listing 草稿生成智能体**
|
||||
|
||||
- 按淘宝/天猫及跨境平台规则分别生成标题、卖点、属性、详情结构草稿
|
||||
- 内置敏感词与常见违规表述提示（供人工复核）
|
||||
- 输出「待审核清单」，按 SKU 列出各平台待发布内容
|
||||
|
||||
**配套交付物**
|
||||
|
||||
- 各平台字段映射与类目规则配置
|
||||
- 商品资料总表模板
|
||||
- 执行日志与版本记录
|
||||
|
||||
## 5. 人工确认与风险控制
|
||||
|
||||
- 商品上架、价格调整、促销活动设置**由运营人员审核确认后执行**
|
||||
- 智能体**不自动发布**商品，**不自动改价**
|
||||
- 涉及品牌宣传口径、医疗/功效类敏感表述，仅生成草稿，不直接对外
|
||||
- 平台规则变更后，需人工确认映射是否仍有效
|
||||
|
||||
## 6. 上线后变化
|
||||
|
||||
- 商品资料整理效率提高，减少多来源复制粘贴
|
||||
- Listing 草稿生成更快，运营可将更多时间用于选品和活动策划
|
||||
- 多平台差异项提前标注，减少后台录入返工
|
||||
- 资料版本更可追溯，便于团队协同
|
||||
|
||||
## 7. 适用边界
|
||||
|
||||
**适合**
|
||||
|
||||
- 有商品资料样例和各平台字段规则说明
|
||||
- SKU 结构相对规范，类目映射可归纳
|
||||
- 团队接受「智能体出草稿、运营审核发布」流程
|
||||
|
||||
**仍需人工判断**
|
||||
|
||||
- 品牌调性、夸大宣传及平台敏感表述
|
||||
- 新品类首次上架的类目与属性选择
|
||||
- 大促期间复杂促销组合与价格策略
|
||||
|
||||
## 8. 可复用到哪些类似场景
|
||||
|
||||
- 跨境 Amazon Listing 与中文资料双向整理
|
||||
- 多店铺同款 SKU 信息同步与差异维护
|
||||
- 季节性上新批量的标题与卖点 A/B 草稿
|
||||
- 供应商来货资料不规范时的字段清洗
|
||||
- 下架商品信息归档与再上架复用
|
||||
|
||||
## 9. 建议试点方式
|
||||
|
||||
**第一步准备资料**
|
||||
|
||||
- 5–10 个典型 SKU 的原始资料（含供应商表、竞品参考）
|
||||
- 各平台后台字段要求截图或导出说明
|
||||
- 现有商品资料总表与上新 SOP
|
||||
- 近半年因填错属性/违禁词被驳回的案例（如有）
|
||||
|
||||
**试点范围**
|
||||
|
||||
- 先选 1 个平台或 1 条产品线
|
||||
- 试运行一批上新，对比人工全流程耗时
|
||||
|
||||
**验收关注点**
|
||||
|
||||
- 草稿可用率（需大改 vs 小改即可发布）
|
||||
- 敏感词提示是否减少驳回
|
||||
- 运营是否愿意持续使用总表协同
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回案例库](./README.md)
|
||||
[返回首页](../README.md)
|
||||
118
cases/finance-reconciliation.md
Normal file
118
cases/finance-reconciliation.md
Normal file
@@ -0,0 +1,118 @@
|
||||
# 项目案例：某企业财务对账表自动整理与差异标记
|
||||
|
||||
## 1. 客户背景
|
||||
|
||||
某有跨境及物流业务的企业（客户名称、财务系统名称已脱敏）。财务部门每月需与多家承运商、海外仓服务商、平台方核对运费与服务费。业务单据量大，账单来源包括 PDF、Excel、平台后台导出等多种格式，月结窗口紧，财务与业务需协同处理差异。
|
||||
|
||||
## 2. 原业务流程
|
||||
|
||||
月结前典型一周：
|
||||
|
||||
1. 财务人员从邮箱下载各渠道账单，按供应商建立文件夹
|
||||
2. 打开每份账单，对照内部「对账模板」手工抄写或复制：单号、日期、金额、币种、计费重量、费用类型等
|
||||
3. 从业务系统导出同期明细表
|
||||
4. 在 Excel 中逐行 VLOOKUP 或肉眼比对，发现不一致项用颜色标注并写备注
|
||||
5. 将差异清单发给业务同事或供应商核实，来回确认后更新台账
|
||||
6. 确认无误后，在财务系统中录入或触发付款流程
|
||||
|
||||
不同渠道账单列名、币种、合单规则各异，整理阶段往往占用月结前半周。
|
||||
|
||||
## 3. 主要问题
|
||||
|
||||
- 账单格式五花八门，归一化整理工作量大
|
||||
- 月结时间窗口短，财务与业务压力集中
|
||||
- 差异项散落在多张表和个人备注中，定位慢
|
||||
- 重复计费、漏录、单号不匹配等问题易在汇总阶段才暴露
|
||||
- 新人不熟悉各渠道计费规则，核对标准依赖老员工经验
|
||||
|
||||
## 4. 匠厂交付内容
|
||||
|
||||
**对账整理智能体**
|
||||
|
||||
- 识别 PDF、Excel 等账单格式，映射到客户统一对账模板
|
||||
- 支持按渠道配置字段映射规则（单号、金额、币种、费用类型等）
|
||||
- 输出标准化对账底表，供财务复核
|
||||
|
||||
**差异标记智能体**
|
||||
|
||||
- 按预设规则与内部业务明细比对
|
||||
- 自动分类差异类型：多计、少计、单号不匹配、币种/汇率差异、重复计费等
|
||||
- 生成差异清单，附建议核实方向
|
||||
|
||||
**配套交付物**
|
||||
|
||||
- 对账模板与差异分类规则文档
|
||||
- 各渠道字段映射配置说明
|
||||
- 每次执行的日志与差异处理记录表
|
||||
|
||||
## 5. 人工确认与风险控制
|
||||
|
||||
- 差异项的处理结论、调账申请、付款审批**均由财务人员确认后执行**
|
||||
- 智能体**不自动修改**财务系统或 ERP 中的账务数据
|
||||
- 智能体**不自动**发起付款或冲销
|
||||
- 规则无法识别的账单行进入「待人工分类」，不强行匹配
|
||||
- 涉及争议金额较大的条目，默认标记为「需复核」
|
||||
|
||||
## 6. 上线后变化
|
||||
|
||||
- 对账表整理时间缩短，财务减少手工复制与格式调整
|
||||
- 差异项定位更快，争议条目更早进入核实流程
|
||||
- 财务人员可集中精力处理有争议的条目，人工审核更聚焦
|
||||
- 对账过程留痕，便于月结复盘与审计抽查
|
||||
|
||||
## 7. 适用边界
|
||||
|
||||
**适合**
|
||||
|
||||
- 有历史账单样例和可描述的对账规则
|
||||
- 内部明细可导出并与账单按单号或关键字段关联
|
||||
- 愿意从 1–2 个渠道试点，规则稳定后再扩展
|
||||
|
||||
**仍需人工判断**
|
||||
|
||||
- 全新渠道或首次合作供应商，需先建立映射规则
|
||||
- 涉及合同解释、服务范围争议的金额差异
|
||||
- 合并计费、分摊规则复杂的特殊账单
|
||||
|
||||
## 8. 可复用到哪些类似场景
|
||||
|
||||
- 物流企业与船司、拖车行、报关行的 SOA 对账
|
||||
- 电商企业与支付平台、广告平台流水对账
|
||||
- 制造企业与供应商应付账款三单匹配前的账单整理
|
||||
- 海外仓仓储费、操作费账单与入库出库明细核对
|
||||
- 多主体、多币种合并对账前的底稿归一化
|
||||
|
||||
## 9. 建议试点方式
|
||||
|
||||
**第一步准备资料**
|
||||
|
||||
- 2–3 个主要渠道的近 3 个月历史账单样例
|
||||
- 对应的内部业务明细导出样例
|
||||
- 现有对账 Excel 模板与差异处理习惯说明
|
||||
- 财务同事整理的「常见差异类型」清单
|
||||
|
||||
**试点范围**
|
||||
|
||||
- 先选 1 个账单格式相对稳定、单量适中的渠道
|
||||
- 试运行一个完整月结周期，对比整理与差异定位耗时
|
||||
|
||||
**验收关注点**
|
||||
|
||||
- 字段映射准确率是否达到可复核水平
|
||||
- 差异分类是否符合财务现有习惯
|
||||
- 未识别行是否有清晰待办，避免静默遗漏
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回案例库](./README.md)
|
||||
[返回首页](../README.md)
|
||||
130
cases/hr-resume-screening.md
Normal file
130
cases/hr-resume-screening.md
Normal file
@@ -0,0 +1,130 @@
|
||||
# 项目案例：某企业 HR 简历初筛与面试协调
|
||||
|
||||
## 1. 客户背景
|
||||
|
||||
某企业人力资源部门（客户名称已匿名处理），处于业务扩张期，同时开放销售、运营、技术、职能等十余类岗位招聘。HR 团队人数有限，除招聘外还需处理入职、制度咨询与部分薪酬事务。招聘旺季每日收到大量简历，面试安排需在 HR、用人部门负责人与候选人之间多方协调。
|
||||
|
||||
## 2. 原业务流程
|
||||
|
||||
**简历初筛**
|
||||
|
||||
1. HR 每日从招聘平台导出或下载简历
|
||||
2. 打开岗位 JD，逐份阅读简历，对照学历、年限、技能、行业经验等硬性条件
|
||||
3. 在表格中标注「进入下一轮 / 待定 / 不合适」及简要理由
|
||||
4. 将初选名单发给用人部门，等待反馈
|
||||
|
||||
**面试协调**
|
||||
|
||||
1. 用人部门确认候选人后，HR 收集面试官可用时间
|
||||
2. 通过邮件或企业微信与候选人沟通时段，常需多轮改期
|
||||
3. 确定时间后发送面试邀请，更新招聘台账
|
||||
|
||||
**制度咨询**
|
||||
|
||||
- 员工就请假、报销、福利、考勤等问题反复咨询 HR，打断招聘工作
|
||||
|
||||
## 3. 主要问题
|
||||
|
||||
- 简历量大时，初筛占用 HR 整块工作时间，标准难以完全一致
|
||||
- 面试协调来回沟通多，改期频繁，台账更新滞后
|
||||
- 制度类重复咨询打断核心招聘任务
|
||||
- 多个岗位并行时，易混淆候选人状态
|
||||
- 用人部门反馈慢时，优秀候选人等待周期长
|
||||
|
||||
## 4. 匠厂交付内容
|
||||
|
||||
**简历初筛智能体**
|
||||
|
||||
- 读取岗位 JD 与筛选规则（硬性条件、优先项、排除项）
|
||||
- 对简历提取学历、年限、技能、项目经历等要素
|
||||
- 输出初筛结果、匹配理由与存疑项，供 HR 逐条确认
|
||||
|
||||
**面试协调智能体**
|
||||
|
||||
- 汇总面试官提交的可用时段
|
||||
- 结合候选人偏好生成协调建议（时间段组合）
|
||||
- 生成面试邀请邮件/消息草稿，HR 确认后发送
|
||||
|
||||
**员工政策问答智能体**
|
||||
|
||||
- 挂载经审核的员工手册、考勤制度、福利政策
|
||||
- 回答常见咨询并引用制度原文出处
|
||||
- 无法确定或涉及个案处理的问题，引导至 HR 人工
|
||||
|
||||
**配套交付物**
|
||||
|
||||
- 各岗位 JD 与筛选规则配置
|
||||
- 招聘台账字段与状态流转说明
|
||||
- 执行日志与候选人处理记录
|
||||
|
||||
## 5. 人工确认与风险控制
|
||||
|
||||
- 进入面试环节的候选人**由 HR 最终确认**
|
||||
- 面试邀请、时间变更通知**发送前需 HR 审核**
|
||||
- 录用、谈薪、发 Offer **仍由 HR 与用人部门共同决策**
|
||||
- 智能体**不自动**向候选人发送拒绝信（除非 HR 启用模板并确认）
|
||||
- 涉及歧视风险、特殊保护群体等敏感判断，仅提供参考，不自动淘汰
|
||||
|
||||
## 6. 上线后变化
|
||||
|
||||
- 简历初筛效率提高，HR 减少逐份通读的机械劳动
|
||||
- 面试协调沟通次数减少，协调建议更易获得共识
|
||||
- 重复制度咨询减少，HR 审核更聚焦
|
||||
- 招聘台账更新更及时，多岗位并行时状态更清晰
|
||||
|
||||
## 7. 适用边界
|
||||
|
||||
**适合**
|
||||
|
||||
- 有明确 JD 和可描述的筛选标准
|
||||
- 简历以标准 PDF/Word/平台导出为主
|
||||
- 制度文档经 HR 审核可供问答引用
|
||||
|
||||
**仍需人工判断**
|
||||
|
||||
- 高端岗位、管理岗、复合型岗位的深度评估
|
||||
- 文化匹配、软实力、面试现场表现
|
||||
- 劳动纠纷风险、特殊用工情形
|
||||
|
||||
## 8. 可复用到哪些类似场景
|
||||
|
||||
- 校招批量简历初筛与笔试安排
|
||||
- 外包/兼职岗位的快速筛选与排班协调
|
||||
- 猎头推荐简历与客户 JD 的预匹配
|
||||
- 新员工入职前 FAQ 与制度预习
|
||||
- 多城市岗位的分区域面试协调
|
||||
|
||||
## 9. 建议试点方式
|
||||
|
||||
**第一步准备资料**
|
||||
|
||||
- 2–3 个典型岗位的 JD 与筛选标准
|
||||
- 近一个月简历样例（含通过、淘汰、待定各若干）
|
||||
- 经审核的员工手册或制度 FAQ 文档
|
||||
- 现有招聘台账与面试邀请模板
|
||||
|
||||
**试点范围**
|
||||
|
||||
- 先选 1 个招聘量大、JD 清晰的岗位
|
||||
- 简历初筛与面试协调可分步上线
|
||||
|
||||
**验收关注点**
|
||||
|
||||
- 初筛推荐是否与 HR 判断大体一致，存疑项是否有用
|
||||
- 协调建议是否减少来回消息
|
||||
- 制度问答引用是否准确，误答是否有兜底转人工
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回案例库](./README.md)
|
||||
[返回首页](../README.md)
|
||||
128
cases/knowledge-base-assistant.md
Normal file
128
cases/knowledge-base-assistant.md
Normal file
@@ -0,0 +1,128 @@
|
||||
# 项目案例：某企业内部 SOP / ERP 操作知识库助手
|
||||
|
||||
## 1. 客户背景
|
||||
|
||||
某制造企业（客户名称、ERP 系统名称已脱敏），仓库、生产、采购、销售等部门员工日常频繁查询系统操作与内部制度。企业已上线 ERP 多年，但操作手册、SOP、制度文件分散在共享盘多个文件夹，版本不一。一线员工习惯「问邻座老员工」，新员工入职前两周大量时间花在跟岗记笔记上。
|
||||
|
||||
## 2. 原业务流程
|
||||
|
||||
**日常咨询**
|
||||
|
||||
- 员工遇到「这个退货单怎么录」「委外发料流程怎么走」等问题，在企业微信群或直接询问老员工
|
||||
- 老员工凭记忆回答，或花几分钟帮找文档中的某一页
|
||||
- 同一问题在不同群重复出现，HR 和 IT 也时常被 @
|
||||
|
||||
**文档查找**
|
||||
|
||||
- SOP 存放在共享盘按部门分的文件夹，命名不统一
|
||||
- 制度更新后，邮件通知一次，但一线是否阅读无法确认
|
||||
- 有人保存旧版 PDF 在桌面，导致按旧流程操作
|
||||
|
||||
**新员工培训**
|
||||
|
||||
- 入职培训讲解主要流程，细节仍靠师傅带
|
||||
- 笔记个人化，离职后知识随人走
|
||||
|
||||
## 3. 主要问题
|
||||
|
||||
- 重复咨询多，老员工频繁被打断，影响本职操作
|
||||
- 文档版本不统一，查找路径因人而异，答非所问时有发生
|
||||
- 制度或 ERP 流程更新后，一线知晓滞后，执行不一致
|
||||
- 新员工上手周期长，培训成本高
|
||||
- IT/HR 重复回答同类问题，难以沉淀为标准答复
|
||||
|
||||
## 4. 匠厂交付内容
|
||||
|
||||
**企业知识库与问答助手**
|
||||
|
||||
- 导入经审核的 ERP 操作手册、仓储 SOP、采购制度、产品资料等文档
|
||||
- 支持自然语言提问，返回答案并**引用原文段落**（可追溯出处）
|
||||
- 配置文档分类与权限范围（如部分制度仅内部职能可见）
|
||||
|
||||
**敏感问题转人工规则**
|
||||
|
||||
- 涉及金额过账、权限变更、合规审批等问题，自动引导至对应负责人
|
||||
- 不直接给出可能影响财务或合规的操作步骤
|
||||
|
||||
**知识更新流程**
|
||||
|
||||
- 文档新增、修订、下架的审核与生效说明
|
||||
- 版本记录，避免旧版答案继续对外
|
||||
|
||||
**配套交付物**
|
||||
|
||||
- 知识库初始导入清单与缺口分析
|
||||
- 管理员操作手册（上传、审核、下架）
|
||||
- 使用统计与未命中问题汇总（供持续补充知识）
|
||||
|
||||
## 5. 人工确认与风险控制
|
||||
|
||||
- 知识库**新增或变更内容经管理员审核后生效**
|
||||
- 涉及金额、权限、合规等事项**不直接给出操作建议**，引导人工处理
|
||||
- 智能体**不自动**在 ERP 中执行任何过账、改权限操作
|
||||
- 答案置信度低或文档无依据时，明确提示「建议咨询部门负责人」
|
||||
- 定期复核高频问题的答案是否仍与最新制度一致
|
||||
|
||||
## 6. 上线后变化
|
||||
|
||||
- 重复咨询减少，老员工被打断频率下降
|
||||
- 新员工上手更快，常见操作可自助查询
|
||||
- 制度、流程和系统操作知识查询更便捷，回答可溯源到原文
|
||||
- 未命中问题汇总为知识库迭代提供输入
|
||||
|
||||
## 7. 适用边界
|
||||
|
||||
**适合**
|
||||
|
||||
- 有经审核、可导入的文档资料（Word、PDF、Markdown 等）
|
||||
- 问题类型以「怎么做」「流程是什么」「字段含义」为主
|
||||
- 企业愿意指定知识库管理员持续维护
|
||||
|
||||
**仍需人工判断**
|
||||
|
||||
- 个案审批、例外处理、跨部门争议
|
||||
- 文档未覆盖的新业务或临时流程
|
||||
- 涉及安全、环保、质量事故等紧急处置
|
||||
|
||||
## 8. 可复用到哪些类似场景
|
||||
|
||||
- 物流企业内部操作 SOP 与船司特殊要求查询
|
||||
- 电商企业多平台后台操作手册问答
|
||||
- 财务共享中心报销制度与系统录入指引
|
||||
- 经销商/代理商产品资料与政策查询
|
||||
- 项目制企业的合同模板与审批流程说明
|
||||
|
||||
## 9. 建议试点方式
|
||||
|
||||
**第一步准备资料**
|
||||
|
||||
- 梳理 Top 20 高频问题及现有答案来源
|
||||
- 收集各部门经审核的操作手册、SOP、制度 PDF
|
||||
- 明确暂不上线的敏感文档范围
|
||||
- 指定 1 名知识库管理员与 1 名业务复核人
|
||||
|
||||
**试点范围**
|
||||
|
||||
- 先上线 1 个部门（如仓储）或 1 类问题（如入库出库）
|
||||
- 试运行 1 个月，收集未命中问题与错答案例
|
||||
|
||||
**验收关注点**
|
||||
|
||||
- 引用出处是否准确，员工是否信任答案
|
||||
- 转人工规则是否合理，避免「乱答」
|
||||
- 管理员更新流程是否可坚持执行
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回案例库](./README.md)
|
||||
[返回首页](../README.md)
|
||||
114
cases/logistics-rfq-quote.md
Normal file
114
cases/logistics-rfq-quote.md
Normal file
@@ -0,0 +1,114 @@
|
||||
# 项目案例：某货代企业询价整理与报价草稿
|
||||
|
||||
## 1. 客户背景
|
||||
|
||||
某货代企业（客户名称已匿名处理），销售团队同时服务直客与同行客户。业务覆盖海运整箱、拼箱及空运出口，航线多、附加费规则细。销售同事每日收到大量询价，来源包括微信文字、截图、邮件正文和 Excel 附件，旺季时单人同时跟进十余条询价并不罕见。
|
||||
|
||||
## 2. 原业务流程
|
||||
|
||||
1. 销售从微信、邮箱等渠道收到询价后，先判断信息是否完整
|
||||
2. 将要素复制到团队共用的 Excel「询价台账」，手工补全起运港、目的港、柜型、货量、贸易条款、货好时间等
|
||||
3. 翻查内部运价表，或向航线操作同事确认舱位与价格
|
||||
4. 套用邮件模板整理报价，核对附加费、本地费、目的港费是否遗漏
|
||||
5. 发送报价后，在台账中标注状态；若客户长时间未回复，靠个人记忆或日历提醒跟进
|
||||
|
||||
新人销售不熟悉各航线港口代码、船司命名和附加费结构时，容易漏项或报重报漏，需老员工复核。
|
||||
|
||||
## 3. 主要问题
|
||||
|
||||
- 询价来源分散、格式不一，整理要素占用销售大量时间
|
||||
- 报价草稿重复劳动多，同类航线反复查表、填表
|
||||
- 旺季多条询价并行时，易漏字段或混淆客户要求
|
||||
- 报价跟进依赖个人习惯，长时间未回复的询价缺乏统一提醒
|
||||
- 新人对运价规则和附加费理解不一致，出错后改报成本高
|
||||
|
||||
## 4. 匠厂交付内容
|
||||
|
||||
**询价整理智能体**
|
||||
|
||||
- 从微信文字、邮件正文、Excel 附件中提取询价要素
|
||||
- 映射到统一字段结构，自动标注缺失项（如未提供货好时间、柜型不明）
|
||||
- 输出结构化询价台账，供销售逐条确认
|
||||
|
||||
**报价草稿智能体**
|
||||
|
||||
- 结合客户运价表、协议价与附加费模板生成报价草稿
|
||||
- 支持多方案对比（不同船期、直航/中转、含/不含本地费）
|
||||
- 生成可直接发送的邮件正文草稿，保留可编辑字段
|
||||
|
||||
**配套交付物**
|
||||
|
||||
- 询价字段映射规则与缺失项检查清单
|
||||
- 运价与附加费引用逻辑说明
|
||||
- 执行日志与询价处理记录
|
||||
|
||||
## 5. 人工确认与风险控制
|
||||
|
||||
- 报价金额、附加费、有效期、付款条款等**发送前必须由销售确认**
|
||||
- 智能体**不自动对外报价**，不代替商务谈判与议价
|
||||
- 危险品、特种柜、联运复杂路径等非标询价，标记为「需人工判断」
|
||||
- 涉及大客户特价或低于成本报价，不自动套用规则，需销售授权后生成
|
||||
|
||||
## 6. 上线后变化
|
||||
|
||||
- 询价整理效率提高，销售减少手工抄录和补字段
|
||||
- 报价草稿生成更快，同类航线复用规则更稳定
|
||||
- 销售可将更多时间用于客户沟通和议价，人工整理压力下降
|
||||
- 询价台账更规范，便于主管查看跟进状态
|
||||
|
||||
## 7. 适用边界
|
||||
|
||||
**适合**
|
||||
|
||||
- 有历史询价样例和相对稳定的运价/附加费规则
|
||||
- 询价要素可归纳为结构化字段
|
||||
- 销售愿意在发送前保留审核环节
|
||||
|
||||
**仍需人工判断**
|
||||
|
||||
- 复杂联运、项目货、特种柜、危险品等非标询价
|
||||
- 需要现场看货或特殊装卸条件的报价
|
||||
- 涉及信用、账期、战略客户特价等商务决策
|
||||
|
||||
## 8. 可复用到哪些类似场景
|
||||
|
||||
- 同行询盘快速整理与舱位回复草稿
|
||||
- 投标应标文件中的运价表填充与历史投标复用
|
||||
- 报价后长时间未回复客户的跟进提醒与话术建议
|
||||
- 多销售共享的统一询价台账与状态看板
|
||||
- 新客户首次询价的要素完整性检查
|
||||
|
||||
## 9. 建议试点方式
|
||||
|
||||
**第一步准备资料**
|
||||
|
||||
- 近一个月各类询价样例（微信、邮件、表格各若干份）
|
||||
- 当前使用的运价表、附加费说明和报价邮件模板
|
||||
- 内部询价台账 Excel 或字段说明
|
||||
- 2–3 条「容易出错」的历史询价案例（供规则校验）
|
||||
|
||||
**试点范围**
|
||||
|
||||
- 先选 1–2 条主力航线或非标占比低的询价类型
|
||||
- 由 1–2 名销售试用 2 周，对比整理与出稿时间
|
||||
|
||||
**验收关注点**
|
||||
|
||||
- 字段提取准确率与缺失项提示是否实用
|
||||
- 报价草稿是否减少重复查表，而非增加核对负担
|
||||
- 销售是否愿意在现有流程中持续使用
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回案例库](./README.md)
|
||||
[返回首页](../README.md)
|
||||
116
cases/logistics-tracking-alert.md
Normal file
116
cases/logistics-tracking-alert.md
Normal file
@@ -0,0 +1,116 @@
|
||||
# 项目案例：某国际货代企业批量查轨迹与异常提醒
|
||||
|
||||
## 1. 客户背景
|
||||
|
||||
某国际货代企业（客户名称已匿名处理），主营海运拼箱与空运出口业务。操作部门有十余名业务员，分别对接不同航线和客户群体。客户对在途货物状态查询需求频繁，部分大客户要求每日或每班次收到在途汇总，对异常节点（甩柜、清关停滞、到港未提货等）响应时效要求高。
|
||||
|
||||
## 2. 原业务流程
|
||||
|
||||
每个工作日上午，业务员打开共享 Excel「当日待跟进运单清单」，按客户或航线分组，逐票处理：
|
||||
|
||||
1. 根据运单号判断应查询的船公司网站、航司货况页或第三方轨迹平台
|
||||
2. 登录对应系统，手工查询最新状态、预计到港时间、当前节点
|
||||
3. 将结果抄入 Excel 对应列，必要时截图留存
|
||||
4. 对重点客户，通过企业微信或邮件发送状态说明
|
||||
5. 若客户主动催问「为什么还没放行」「是不是甩柜了」，再回头逐票核实
|
||||
|
||||
旺季或船期波动时，同一业务员可能同时维护几十票在途货，查询与回复穿插进行，机械操作占用大量整块时间。
|
||||
|
||||
## 3. 主要问题
|
||||
|
||||
- 单票查询路径分散，批量处理时反复登录多个网站，机械操作耗时长
|
||||
- 异常往往在客户催问后才集中核实，主动预警不足
|
||||
- 同一运单多次查询结果散落在个人表格和聊天记录中，不便汇总复盘
|
||||
- 新人不熟悉各船公司查询入口和状态字段含义，查询质量依赖老员工
|
||||
- 管理层难以从个人表格快速看到「今日待处理异常」全貌
|
||||
|
||||
## 4. 匠厂交付内容
|
||||
|
||||
**运单轨迹查询智能体**
|
||||
|
||||
- 支持导入当日待跟进运单清单（运单号、船公司/渠道、客户、航线等字段）
|
||||
- 按预设规则调用各渠道查询能力，批量归集最新状态与关键节点时间
|
||||
- 输出统一汇总表，支持按客户、航线、业务员筛选
|
||||
|
||||
**异常提醒规则库**
|
||||
|
||||
- 配置「超过 N 天未更新」「状态跳变异常」「到港未提货超时」等规则
|
||||
- 命中规则的运单进入「待处理异常清单」，附简要说明与建议核实方向
|
||||
|
||||
**配套交付物**
|
||||
|
||||
- 执行日志：每票查询时间、来源、返回结果摘要
|
||||
- 汇总报表模板：便于业务员直接引用回复客户
|
||||
- 操作说明：面向业务人员的日常使用与异常处理指引
|
||||
|
||||
## 5. 人工确认与风险控制
|
||||
|
||||
- 异常提醒或状态说明**对外发送前**，由业务员逐条确认表述内容
|
||||
- 涉及赔偿、责任认定、客户索赔等事项，**不自动生成**对外口径或承诺性表述
|
||||
- 智能体**不自动**向客户发送消息、不修改 OMS/TMS 中的业务数据
|
||||
- 查询失败或渠道返回异常时，进入「需人工核实」列表，不静默跳过
|
||||
|
||||
## 6. 上线后变化
|
||||
|
||||
- 机械查询时间明显减少，业务员减少重复登录各船公司网站
|
||||
- 异常项更早进入待处理列表，客户催问前即可开始核实
|
||||
- 回复客户时可直接引用汇总结果，沟通更及时、表述更一致
|
||||
- 查询过程留痕，便于事后复盘某票状态变化时间线
|
||||
|
||||
## 7. 适用边界
|
||||
|
||||
**适合**
|
||||
|
||||
- 有相对稳定的运单号与可查询渠道
|
||||
- 查询规则可归纳（按船公司、航线、渠道映射）
|
||||
- 客户授权提供查询所需账号或访问方式
|
||||
- 愿意从「批量查询 + 异常清单」小场景试点
|
||||
|
||||
**仍需人工判断**
|
||||
|
||||
- 部分船公司反爬、验证码或登录策略频繁变更，需单独适配维护
|
||||
- 复杂索赔、责任界定、客户特殊口径需业务员现场确认
|
||||
- 新开通渠道或罕见运输方式，首次需人工验证查询逻辑
|
||||
|
||||
## 8. 可复用到哪些类似场景
|
||||
|
||||
- 空运 ULD / 航班货况批量查询与延误提醒
|
||||
- 跨境电商 FBA 尾程签收与上架异常监控
|
||||
- 报关放行进度追踪与查验预警
|
||||
- 拖车/派送签收状态汇总与客户通知草稿
|
||||
- 冷链温控异常监测与值班提醒
|
||||
|
||||
## 9. 建议试点方式
|
||||
|
||||
**第一步准备资料**
|
||||
|
||||
- 近两周待跟进运单样例（含运单号、渠道、客户）
|
||||
- 各渠道查询方式说明或测试账号
|
||||
- 当前业务员使用的 Excel 汇总表模板
|
||||
- 3–5 条您认为应触发「异常」的典型情形描述
|
||||
|
||||
**试点范围**
|
||||
|
||||
- 先选 1 条航线或 1 个客户群体的在途运单
|
||||
- 试运行 1–2 周，对比「人工逐票查」与「智能体汇总 + 人工确认」的差异
|
||||
|
||||
**验收关注点**
|
||||
|
||||
- 汇总表字段是否满足回复客户所需
|
||||
- 异常规则是否过松或过严
|
||||
- 查询失败项是否可追溯、可补查
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回案例库](./README.md)
|
||||
[返回首页](../README.md)
|
||||
117
cases/manufacturing-supplier-quote.md
Normal file
117
cases/manufacturing-supplier-quote.md
Normal file
@@ -0,0 +1,117 @@
|
||||
# 项目案例：某制造企业供应商报价比对与采购建议
|
||||
|
||||
## 1. 客户背景
|
||||
|
||||
某制造业客户（客户名称已匿名处理），生产装配类产品，原材料与零部件品类多、供应商分散。采购部门需定期向多家供应商询价，比价维度包括单价、起订量、交期、付款方式、是否含运费等。采购经理审批前，采购员需整理横向对比表并附简要建议。
|
||||
|
||||
## 2. 原业务流程
|
||||
|
||||
1. 采购员根据缺料清单或计划员需求，向多家供应商发送询价（邮件或企业微信）
|
||||
2. 陆续收到回复：邮件正文、Excel 附件、微信发来的图片或 PDF 扫描件
|
||||
3. 手工将各供应商报价填入「比价表」，逐项核对单位、币种、MOQ、交期、含税与否
|
||||
4. 标注最低价、交期最优项，写一两句采购建议
|
||||
5. 提交采购经理审批；历史报价保存在个人文件夹，检索不便
|
||||
6. 新人采购不熟悉各供应商报价习惯（是否含运、报价有效期写法等），易漏项
|
||||
|
||||
## 3. 主要问题
|
||||
|
||||
- 报价格式不统一，整理填入对比表费时
|
||||
- 比价维度多时容易漏项（如未统一含税口径）
|
||||
- 历史报价难追溯，无法快速对比「上次采购价」
|
||||
- 采购建议依赖个人经验，表述标准不一致
|
||||
- 旺季并行询价多，表格维护压力大
|
||||
|
||||
## 4. 匠厂交付内容
|
||||
|
||||
**供应商报价比对智能体**
|
||||
|
||||
- 从邮件、Excel、图片报价单中提取并标准化字段
|
||||
- 按物料生成横向对比表，统一单位与币种口径
|
||||
- 标注最优项、异常报价（偏离历史区间、交期明显过长等）
|
||||
|
||||
**采购建议草稿智能体**
|
||||
|
||||
- 基于比价结果生成简要建议（供采购员编辑）
|
||||
- 支持引用历史报价记录作对比说明
|
||||
|
||||
**历史报价归档**
|
||||
|
||||
- 按物料、供应商维度归档结构化报价
|
||||
- 支持检索「某物料近几次询价结果」
|
||||
|
||||
**配套交付物**
|
||||
|
||||
- 字段提取与比价规则配置
|
||||
- 比价表模板与审批附件格式
|
||||
- 执行日志
|
||||
|
||||
## 5. 人工确认与风险控制
|
||||
|
||||
- 最终供应商选择、合同条款、下单数量与价格**由采购经理确认**
|
||||
- 智能体**不自动下单**，不代替采购谈判
|
||||
- 战略物料、独家供应商、非标规格需标记「需专项评估」
|
||||
- 图片识别置信度低的字段进入「待人工核对」
|
||||
|
||||
## 6. 上线后变化
|
||||
|
||||
- 报价比对整理效率提高，采购员减少手工填表
|
||||
- 采购建议更有据可查，审批附件更规范
|
||||
- 比价规则可沉淀复用，减少对个人文件夹的依赖
|
||||
- 新人更快熟悉比价维度和供应商报价格式
|
||||
|
||||
## 7. 适用边界
|
||||
|
||||
**适合**
|
||||
|
||||
- 有报价样例和明确的比价维度
|
||||
- 询价回复以邮件、表格、可识别图片为主
|
||||
- 采购流程中已有「比价表 + 经理审批」环节
|
||||
|
||||
**仍需人工判断**
|
||||
|
||||
- 战略采购、长期协议价、独家物料谈判
|
||||
- 质量风险高、需现场审核的供应商切换
|
||||
- 交期与价格需综合权衡的紧急缺料场景
|
||||
|
||||
## 8. 可复用到哪些类似场景
|
||||
|
||||
- 委外加工费多家比价
|
||||
- 包装材料、辅料定期询价整理
|
||||
- 进口件汇率波动时的多供应商复询
|
||||
- 新供应商准入前的报价与历史价对比
|
||||
- 项目制采购的阶段性招标比价汇总
|
||||
|
||||
## 9. 建议试点方式
|
||||
|
||||
**第一步准备资料**
|
||||
|
||||
- 近半年 3–5 次询价的原始回复（含邮件、Excel、图片）
|
||||
- 现有比价表模板与审批流程说明
|
||||
- 采购经理关注的比价维度清单（必填项）
|
||||
- 2–3 个「曾出过问题」的比价案例（漏项、口径不一致等）
|
||||
|
||||
**试点范围**
|
||||
|
||||
- 先选 1 类物料或 1 个采购员负责的品种
|
||||
- 试运行 2–3 个完整询价周期
|
||||
|
||||
**验收关注点**
|
||||
|
||||
- 提取字段是否减少手工录入而非增加核对负担
|
||||
- 异常标注是否有帮助，避免误报过多
|
||||
- 历史报价检索是否真正被采购流程使用
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回案例库](./README.md)
|
||||
[返回首页](../README.md)
|
||||
118
cases/marketing-multi-platform-publish.md
Normal file
118
cases/marketing-multi-platform-publish.md
Normal file
@@ -0,0 +1,118 @@
|
||||
# 项目案例：某内容运营团队多平台文章发布自动化
|
||||
|
||||
## 1. 客户背景
|
||||
|
||||
某内容运营团队（客户名称已匿名处理），为企业客户提供品牌内容分发服务，覆盖公众号、头条号、搜狐号、知乎、百家号等图文平台。团队有编辑负责撰稿、运营负责多平台发布与数据汇总。客户常要求提供各平台发布链接与发布时间的周报。
|
||||
|
||||
## 2. 原业务流程
|
||||
|
||||
1. 编辑在 Word 或飞书文档完成定稿，附标题备选、摘要、配图说明
|
||||
2. 运营打开「平台发布 checklist」，按平台逐项处理：
|
||||
- 调整标题字数与段落格式
|
||||
- 裁剪或更换封面图比例
|
||||
- 登录后台上传配图、粘贴正文、填写标签与原创声明
|
||||
3. 发布成功后，将链接、发布时间复制到共享表格「发布记录表」
|
||||
4. 周末或月初，从各后台和表格汇总数据，制作客户周报
|
||||
5. 若某平台审核未通过，重新修改后再发，记录中需更新状态
|
||||
|
||||
同一篇文章发布 6–8 个平台时，运营半天时间常耗在重复排版与登录上。新人不熟悉各后台差异，出错率较高。
|
||||
|
||||
## 3. 主要问题
|
||||
|
||||
- 多平台格式要求不同，重复排版与发布操作琐碎
|
||||
- 发布记录靠手工维护，链接遗漏或状态不同步时有发生
|
||||
- 向客户汇报时需重新整理，复盘效率低
|
||||
- 新人培训成本高，各平台后台操作细节多
|
||||
- 内容团队时间被后台操作占用，选题与改稿投入被挤压
|
||||
|
||||
## 4. 匠厂交付内容
|
||||
|
||||
**多平台文章发布智能体**
|
||||
|
||||
- 读取定稿文档，按各平台格式规则自动排版
|
||||
- 在授权账号下执行发布流程（标题、正文、封面、标签等）
|
||||
- 记录每平台发布结果（成功、审核中、失败原因）
|
||||
|
||||
**内容发布记录整理智能体**
|
||||
|
||||
- 汇总各平台链接、发布状态、发布时间
|
||||
- 输出结构化发布台账，支持按客户、账号、日期筛选
|
||||
- 生成周报底稿（发布篇数、链接清单、异常说明）
|
||||
|
||||
**配套交付物**
|
||||
|
||||
- 各平台格式与发布规范配置
|
||||
- 发布日志与异常处理说明
|
||||
- 运营操作手册（审核、重发、跳过）
|
||||
|
||||
## 5. 人工确认与风险控制
|
||||
|
||||
- 文章**发布前**由编辑或运营审核确认正文、配图与标题
|
||||
- 涉政敏感、客户品牌口径、争议话题**不自动发布**
|
||||
- 高风险账号或首次发布的新账号，默认仅生成预览不自动提交
|
||||
- 智能体**不自动**回复评论、不修改已发布内容（除非单独配置且经确认）
|
||||
- 发布失败项保留错误信息，供人工处理
|
||||
|
||||
## 6. 上线后变化
|
||||
|
||||
- 重复发布操作减少，运营从多后台切换中释放出来
|
||||
- 发布记录整理更及时，客户周报底稿更快产出
|
||||
- 内容团队可将更多时间用于选题、改稿和转化跟进
|
||||
- 发布过程留痕，便于追溯某篇文章各平台状态
|
||||
|
||||
## 7. 适用边界
|
||||
|
||||
**适合**
|
||||
|
||||
- 有稳定的定稿格式与各平台发布规范
|
||||
- 可提供各平台授权账号或发布环境
|
||||
- 内容以图文为主，格式规则可归纳
|
||||
|
||||
**仍需人工判断**
|
||||
|
||||
- 涉敏题材、客户特殊口径、危机公关类内容
|
||||
- 平台界面或审核规则大幅变更后的适配
|
||||
- 需人工精选封面或强互动体裁的稿件
|
||||
|
||||
## 8. 可复用到哪些类似场景
|
||||
|
||||
- 企业官网 + 自媒体矩阵同步发文
|
||||
- 短视频多平台（抖音、快手、视频号）标题与描述批量发布
|
||||
- 知乎/CSDN 等技术文章多社区分发
|
||||
- 活动稿件定时发布与状态追踪
|
||||
- MCN 机构多账号内容排期与发布台账
|
||||
|
||||
## 9. 建议试点方式
|
||||
|
||||
**第一步准备资料**
|
||||
|
||||
- 近 10 篇已发布文章的原稿与各平台最终样式
|
||||
- 各平台账号授权方式与发布 SOP
|
||||
- 现有发布记录表与周报模板
|
||||
- 明确「绝不自动发布」的内容类型清单
|
||||
|
||||
**试点范围**
|
||||
|
||||
- 先选 2–3 个格式相近、审核稳定的平台
|
||||
- 试运行 2 周，由编辑全程审核后发布
|
||||
|
||||
**验收关注点**
|
||||
|
||||
- 排版还原度是否满足各平台要求
|
||||
- 发布记录是否完整、漏链是否减少
|
||||
- 失败重试与人工接管是否顺畅
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回案例库](./README.md)
|
||||
[返回首页](../README.md)
|
||||
@@ -1,4 +1,261 @@
|
||||
# client-ecommerce-taobao
|
||||
# 淘宝电商 AI 智能体解决方案
|
||||
|
||||
本页面面向淘宝店铺运营团队，说明匠厂如何围绕商品上架、内容优化、推广活动、客服售后与数据分析等真实业务流程，开发可落地、可执行、可追溯的 AI 智能体。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- 新品上架要填类目、属性、SKU、价格等多处信息，格式要求细，运营靠复制表格手工录入，易漏项错项
|
||||
- 标题、主图、详情页决定搜索与转化，但优化依赖个人经验，A/B 测试与复盘缺少统一方法
|
||||
- 直通车关键词、出价、活动节奏分散在多个后台页面，忙时顾此失彼，推广预算利用率难评估
|
||||
- 限时折扣、优惠券、大促排期靠 Excel 和群消息协调，活动前后价格与库存同步容易出错
|
||||
- 买家咨询、退款、投诉量大，常见问题重复回复，纠纷处理标准依赖老员工口头传授
|
||||
- 流量、转化、销售、评价等数据分散在淘宝生意参谋与自建表格，周报月报靠人工汇总
|
||||
- 竞品价格与销量变化需人工盯盘，供应商交期与质量信息散落在微信，预警不及时
|
||||
- 库存与价格变更涉及多 SKU、多链接，批量同步慢，橱窗排序与下架规则执行不一致
|
||||
|
||||
---
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
### 商品管理
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
上架字段多、批量改价改库存繁琐；类目与属性匹配不准导致流量受限；橱窗排序与下架规则执行靠人工记忆。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 新品发布智能体
|
||||
- 商品信息批量编辑智能体
|
||||
- 条件下架智能体
|
||||
- 类目与属性匹配智能体
|
||||
- SKU 规格与定价建议智能体
|
||||
- 价格与库存同步智能体
|
||||
- 橱窗排序优化智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
待审核上架草稿；批量修改预览表；类目/属性匹配建议；SKU 组合与定价方案；同步任务执行日志。
|
||||
|
||||
### 内容优化
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
标题与主图决定点击率，详情与短视频决定转化，但创作与优化节奏跟不上上新频率。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 标题优化智能体
|
||||
- 主图优化建议智能体
|
||||
- 详情页文案生成智能体
|
||||
- 图文种草内容生成智能体
|
||||
- 短视频脚本生成智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
标题改写方案与关键词布局建议；主图构图与卖点突出建议；详情页结构与卖点文案；种草图文大纲；短视频分镜与口播稿。
|
||||
|
||||
### 推广与活动
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
关键词研究、直通车出价、活动方案制定分散，缺少从「选词—投放—复盘」的连贯辅助。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 关键词挖掘与流量分析智能体
|
||||
- 直通车出价优化智能体
|
||||
- 促销活动方案规划智能体
|
||||
- 限时折扣与优惠券创建智能体
|
||||
- 直播话术与节奏规划智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
关键词优先级列表；出价调整建议；活动节奏与力度方案；活动配置草稿；直播环节与话术大纲。
|
||||
|
||||
### 客服与售后
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
咨询重复度高，退款与投诉处理标准不统一，评价中的问题归纳慢。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 买家咨询自动回复智能体
|
||||
- 退款退货处理与话术智能体
|
||||
- 投诉纠纷应对方案智能体
|
||||
- 买家评价分析智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
常见问题答复草稿；退款/退货处理步骤与话术；纠纷升级与补偿方案建议；评价主题与改进清单。
|
||||
|
||||
### 数据分析与监控
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
流量、转化、销售、绩效等指标分散查询，竞品与供应商信息靠人工跟踪，库存预警滞后。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 流量来源分析智能体
|
||||
- 转化漏斗分析智能体
|
||||
- 销售分析与备货预测智能体
|
||||
- 店铺经营巡检智能体
|
||||
- 周期经营报告生成智能体
|
||||
- 竞品监控智能体
|
||||
- 供应商交货监控智能体
|
||||
- 库存预警智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
流量与转化摘要；备货量建议；经营 KPI 巡检报告；周报/月报草稿；竞品变动清单；供应商异常提示；补货预警列表。
|
||||
|
||||
---
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
### 场景 1：标题与详情页内容优化
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
输入为已有商品信息，输出为草稿，不直接改后台；对搜索与转化影响大，验收标准相对清晰。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
目标商品链接与竞品参考；品牌用词规范；希望突出的卖点与禁用表述。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
标题改写方案；详情页结构与文案草稿；关键词布局说明。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
所有对外展示内容发布前由运营审核；涉及功效、对比、极限词等须负责人确认。
|
||||
|
||||
### 场景 2：买家咨询常见问答辅助
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
高频问题规则相对固定；可先内部试用答复草稿，再逐步开放给客服参考。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
历史咨询记录；现有 FAQ 与话术库；退款、换货、物流等政策说明。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
按问题分类的答复草稿；未覆盖问题清单；需升级人工处理的边界说明。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
涉及补偿、例外政策、纠纷判定的回复须客服主管确认；智能体不自动发送承诺性答复。
|
||||
|
||||
### 场景 3：直通车关键词与出价建议
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
建议型输出，不自动改账户设置；可对照一段时间数据验证建议是否合理。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
近期推广报表；目标 ROI 或 CPC 区间；重点主推 SKU 列表。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
关键词增删建议；出价调整方案；低效词清理清单。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
账户内实际改价、改词由推广专员确认后操作。
|
||||
|
||||
### 场景 4：销售分析与库存预警
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
基于已有销售与库存数据，规则可逐步校准；输出为备货建议而非自动采购。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
销售与库存导出样例；补货周期与安全库存习惯；大促系数说明（如有）。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
SKU 销量趋势摘要；备货量建议；断货与冗余风险提示。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
实际补货与生产计划由供应链或店长确认。
|
||||
|
||||
---
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 项目案例 1：某淘宝服饰店 — 标题优化与详情页生成
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 淘宝女装店铺，款式更新快，运营小组负责上架与日常优化，依赖搜索与自然流量 |
|
||||
| **原业务流程** | 运营根据拍图与面料信息手工写标题，凭感觉堆关键词；详情页从旧款复制改字，卖点与尺码说明常不统一；上新高峰期来不及逐款优化 |
|
||||
| **主要问题** | 标题与详情质量因人手波动大；关键词布局缺少方法，同款不同链接表现差异明显；详情页结构老旧，转化优化靠试错 |
|
||||
| **匠厂交付内容** | 标题优化智能体、详情页文案生成智能体、主图优化建议智能体；输出模板与字段检查清单；执行日志 |
|
||||
| **人工确认节点** | 标题与详情发布前由运营审核；涉及材质、功能宣称须负责人确认 |
|
||||
| **上线后变化** | 上新时可直接基于草稿微调，减少从零撰写；优化动作有字段级待办，交接更清晰 |
|
||||
| **适用边界** | 全新风格线、需专业摄影配合的主图决策仍须人工主导；智能体不自动改价或改库存 |
|
||||
|
||||
### 项目案例 2：某淘宝家居店 — 客服问答、评价分析与活动排期辅助
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 淘宝家居用品店，客服与运营岗位重叠，日常需处理咨询、退款与评价，并配合平台活动改价 |
|
||||
| **原业务流程** | 客服在千牛里重复回答尺寸、安装、物流问题；差评原因手工记录；活动前在 Excel 排期，再逐个设置折扣与优惠券，易漏设或时间重叠 |
|
||||
| **主要问题** | 咨询回复标准不统一，忙时响应慢；评价中的质量问题归纳滞后；活动配置分散，价格同步易出错 |
|
||||
| **匠厂交付内容** | 买家咨询回复智能体、评价分析智能体、促销活动规划智能体、优惠券/折扣创建辅助；常见问题库与升级规则；执行记录 |
|
||||
| **人工确认节点** | 涉及补偿、例外退款的答复须主管确认；活动力度与最终配置由店长审核；智能体不自动对外承诺 |
|
||||
| **上线后变化** | 常见咨询有统一答复参考，客服更多精力处理复杂单；差评主题更早进入产品反馈列表；活动排期有可视化草稿，减少漏设 |
|
||||
| **适用边界** | 复杂纠纷、平台判责申诉仍须人工处理；直播带货临场节奏与主播配合不宜完全脚本化 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂采用 **「理解—执行—连接—把关—追溯」** 的方式，让淘宝运营智能体在可控边界内参与日常工作：
|
||||
|
||||
1. **需求访谈** — 了解店铺品类、团队分工、在用 ERP/打单/客服工具及平台后台使用习惯
|
||||
2. **流程拆解** — 明确上架、推广、客服、报表等环节的输入、输出与审核规则
|
||||
3. **样例数据确认** — 用真实商品、咨询、推广报表样例验证规则与输出格式
|
||||
4. **智能体开发** — 按确认方案开发技能，在客户授权范围内对接必要数据源
|
||||
5. **小范围试运行** — 先选一条产品线或一个岗位试点，对照人工结果验收
|
||||
6. **培训上线** — 编写操作说明，培训运营与客服，明确人工确认节点
|
||||
7. **持续优化** — 根据大促、平台规则变化迭代模板、话术与预警规则
|
||||
|
||||
---
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- 商品信息整理、内容优化、推广建议、咨询答复、数据汇总等重复、可复核的工作
|
||||
- 有历史商品数据、咨询记录、推广报表等样例可供配置
|
||||
- 愿意在上架、改价、活动配置、对外回复等节点保留人工确认
|
||||
- 希望把标题规范、FAQ、活动 SOP 沉淀为可复用能力
|
||||
- 愿意从标题优化、咨询辅助等小场景试点，再逐步扩展
|
||||
|
||||
### 不适合
|
||||
|
||||
- 期望智能体不经审核自动改价、自动回复全部咨询或自动创建活动
|
||||
- 没有任何商品、咨询或报表样例可参考
|
||||
- 不愿提供测试样例或后台访问权限
|
||||
- 复杂纠纷判责、平台申诉等必须负责人决策的场景，不宜强行全自动
|
||||
- 仅想要通用聊天机器人，而不愿定义具体任务与验收标准
|
||||
|
||||
---
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂淘宝电商技能组，当前包含 **30** 个技能仓库。
|
||||
|
||||
@@ -87,3 +344,19 @@
|
||||
- **taobao-monitor-competitor** — 监控竞品价格与销量变化
|
||||
- **taobao-monitor-supplier** — 监控供应商交货周期与质量
|
||||
- **taobao-alert-inventory** — 库存预警推送补货建议
|
||||
|
||||
---
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
@@ -1,4 +1,260 @@
|
||||
# client-ecommerce-tmall
|
||||
# 天猫电商 AI 智能体解决方案
|
||||
|
||||
本页面面向天猫品牌与旗舰店运营团队，说明匠厂如何围绕合规质检、会员运营、大促营销、数据分析与跨境保税等真实业务流程，开发可落地、可执行、可追溯的 AI 智能体。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- 详情页、主图、活动页文案需符合广告法与平台违禁词规则，人工逐条检查工作量大，大促前更易遗漏
|
||||
- 最低标价、券后价、跨店满减叠加规则复杂，价格设置失误可能触发平台处罚或客诉
|
||||
- 品牌授权书、行业资质、平台提报材料有效期分散管理，临期才发现影响上新与大促报名
|
||||
- 店铺会员体量大但分层粗糙，高价值会员识别与流失预警依赖 Excel，权益活动缺少针对性
|
||||
- 大促招商规则长、变化快，报名字段多，运营手工对照规则填写，易漏项或报错了活动档位
|
||||
- 万相台无界版多计划、多波段投放，调价与素材轮换靠人工经验，缺少结构化复盘辅助
|
||||
- 小黑盒、新品首发、会场赛马等营销玩法的方案与素材要求各不同，准备周期长
|
||||
- 数据银行、策略中心标签丰富但语义分散，运营难以快速把标签洞察转化为动作
|
||||
- 天猫国际与保税仓货品调拨、关税核算涉及多系统数据，人工核对易错
|
||||
|
||||
---
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
### 合规与资质
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
详情与活动文案违禁词、极限词、虚假宣传表述难以及时扫清；标价与券后价合规监控缺少固定节奏；资质与授权临期无系统预警。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 详情页广告法与违禁词质检智能体
|
||||
- 最低标价/券后价合规监控智能体
|
||||
- 品牌授权与平台资质提报预警智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
违禁词与风险表述清单及修改建议；价格合规巡检报告；资质临期预警与待办列表。
|
||||
|
||||
### 会员运营
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
会员分层维度单一，高价值与流失风险会员识别滞后；积分商城与专享权益活动缺少结构化策划；VIP 咨询需专属接待标准。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 店铺会员多维分层与流失预警智能体
|
||||
- 会员积分商城与专享权益活动策划智能体
|
||||
- 品牌 VIP 尊享客服接待智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
会员分层标签与流失风险名单；权益活动方案草稿；VIP 咨询接待话术与升级规则。
|
||||
|
||||
### 大促与营销
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
大促招商规则提取与报名字段填写耗时；会场赛马主图与素材优化缺少对照标准；万相台多波段投放调价依赖经验；小黑盒/新品首发方案准备周期长。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 大促招商规则提取与智能报名智能体
|
||||
- 大促会场赛马主图优化智能体
|
||||
- 万相台无界版多波段投放与调价智能体
|
||||
- 天猫小黑盒/新品首发方案生成智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
招商规则摘要与报名字段对照表；主图优化建议与赛马要点；投放波段与出价调整建议；小黑盒/首发方案大纲与素材清单。
|
||||
|
||||
### 数据分析
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
数据银行、策略中心标签语义丰富但难快速解读；大牌号/微淘等内容 ROI 复盘靠人工拉数。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 数据银行/策略中心标签语义分析智能体
|
||||
- 大牌号/微淘动态内容 ROI 分析智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
标签洞察摘要与可行动建议；内容投放 ROI 对比与优化方向说明。
|
||||
|
||||
### 跨境保税
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
保税仓货品调拨、关税与成本核算涉及多源数据，人工表格易错、难追溯。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 天猫国际/保税仓货品调拨与关税核算智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
调拨建议与成本测算表；关税与合规项核对清单。
|
||||
|
||||
### 客服与纠纷
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
超级投诉与复杂纠纷升级路径不清晰，预案与话术依赖个人经验。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 超级投诉与纠纷高级介入预案智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
纠纷分级与责任人建议；介入话术与证据清单；升级节点说明。
|
||||
|
||||
---
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
### 场景 1：详情页违禁词与广告法质检
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
规则相对明确，输入为已有文案，输出为修改建议；大促前批量检查价值高，风险可控。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
详情页、主图文案样例；品牌禁用词库；历史被驳回或整改案例（如有）。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
风险词与表述清单；逐条修改建议；合规复检摘要。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
修改后的文案发布前由运营与法务/负责人确认；智能体不自动替换线上内容。
|
||||
|
||||
### 场景 2：大促招商规则提取与报名辅助
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
规则文档长但结构可解析；智能体辅助对照字段，人工最终提交，边界清晰。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
当期招商规则 PDF/网页；历史报名表格；店铺资质与可报类目说明。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
规则要点摘要；报名字段对照表；漏项与冲突提示。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
最终报名提交由运营负责人确认；涉及价格承诺、库存承诺须店长审批。
|
||||
|
||||
### 场景 3：会员分层与流失预警
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
基于已有会员与交易数据，输出为标签与名单，不自动发券；可先用于人工触达验证。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
会员与订单导出样例；现有分层习惯；希望关注的流失定义（如 N 天未购）。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
多维分层标签；高价值与流失风险会员名单；建议触达方向说明。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
实际发券、短信、专属权益由会员运营确认后执行。
|
||||
|
||||
### 场景 4：万相台投放波段与调价建议
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
建议型输出，不自动改账户；可对照一段投放周期验证建议是否合理。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
近期万相台报表；目标 ROI 或 CPA；大促波段计划（如有）。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
分计划/分人群表现摘要；调价与预算倾斜建议；低效计划清理清单。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
账户内实际调价、改预算由推广负责人确认后操作。
|
||||
|
||||
---
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 项目案例 1：某天猫美妆旗舰店 — 违禁词质检与大促报名辅助
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 天猫美妆品牌旗舰店，大促频次高，运营需同时维护日常详情与多次活动页，合规要求严 |
|
||||
| **原业务流程** | 运营写完详情与活动文案后，人工对照内部词库与广告法要点检查；大促前下载招商规则 PDF，逐项填报名表，常与同事交叉核对是否漏报档位或填错价格库存 |
|
||||
| **主要问题** | 违禁词与极限表述检查耗时长，忙时易遗漏；招商规则更新快，对照填写易错；同一商品多活动页口径不一致 |
|
||||
| **匠厂交付内容** | 详情页违禁词质检智能体、大促招商规则提取与报名辅助智能体；品牌词库与规则摘要模板；检查与报名执行日志 |
|
||||
| **人工确认节点** | 文案修改与活动报名提交前由运营负责人确认；涉及功效、医疗相关表述须品牌法务把关 |
|
||||
| **上线后变化** | 文案上线前有结构化风险清单，减少返工；报名表字段对照更清晰，漏项在提交前更容易发现 |
|
||||
| **适用边界** | 全新功效宣称、需检测报告支持的表述仍须人工撰写；智能体不自动提交平台报名 |
|
||||
|
||||
### 项目案例 2：某天猫服饰旗舰店 — 会员分层、万相台调价与 VIP 客服辅助
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 天猫服饰旗舰店，会员体量大，设有专属客服岗位，日常投放使用万相台无界版 |
|
||||
| **原业务流程** | 会员运营用 Excel 按消费金额粗分层级，流失会员靠人工筛；推广每日查看万相台多计划数据，凭经验调价；VIP 咨询由资深客服接待，标准话术分散在文档里 |
|
||||
| **主要问题** | 会员分层维度少，高价值与沉默会员识别慢；万相台计划多，调价缺少结构化建议；VIP 接待标准不统一，交接班信息不完整 |
|
||||
| **匠厂交付内容** | 会员多维分层与流失预警智能体、万相台多波段投放与调价智能体、VIP 尊享客服接待智能体；分层标签说明与接待话术库；执行记录 |
|
||||
| **人工确认节点** | 会员触达、发券、专属权益由会员运营确认；账户改价改预算由推广确认；涉及补偿与升级的 VIP 案例须主管确认 |
|
||||
| **上线后变化** | 会员运营有分层名单与流失预警作参考，触达讨论更聚焦；推广复盘有分计划摘要，调价讨论有据可依；VIP 接待有统一话术参考 |
|
||||
| **适用边界** | 品牌级公关危机、重大判责申诉仍须人工决策；跨境保税调拨涉及海关与财务口径，需专业岗位复核 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂采用 **「理解—执行—连接—把关—追溯」** 的方式，让天猫运营智能体在可控边界内参与日常工作：
|
||||
|
||||
1. **需求访谈** — 了解品牌架构、店铺类型（旗舰/专卖/国际）、岗位分工与在用工具
|
||||
2. **流程拆解** — 明确合规、会员、大促、投放、数据分析等环节的输入、输出与审核规则
|
||||
3. **样例数据确认** — 用真实文案、招商规则、会员与投放报表样例验证规则与输出格式
|
||||
4. **智能体开发** — 按确认方案开发技能，在客户授权范围内对接必要数据源
|
||||
5. **小范围试运行** — 先选一个大促场次或一条产品线试点，对照人工结果验收
|
||||
6. **培训上线** — 编写操作说明，培训运营、推广与客服，明确人工确认节点
|
||||
7. **持续优化** — 根据平台规则、活动玩法变化迭代词库、规则摘要与分层模型
|
||||
|
||||
---
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- 违禁词质检、报名对照、会员分层、投放建议、标签解读等重复、可复核的工作
|
||||
- 有历史文案、招商规则、会员与投放报表等样例可供配置
|
||||
- 愿意在文案发布、活动报名、发券、改价等节点保留人工确认
|
||||
- 希望把合规词库、会员策略、投放 SOP 沉淀为可复用能力
|
||||
- 愿意从违禁词质检或大促报名辅助等小场景试点，再逐步扩展
|
||||
|
||||
### 不适合
|
||||
|
||||
- 期望智能体不经审核自动改线上文案、自动提交报名或自动改投放账户
|
||||
- 没有任何文案、规则文档或报表样例可参考
|
||||
- 不愿提供测试样例或后台访问权限
|
||||
- 重大合规争议、平台申诉、品牌公关等必须高管或法务决策的场景，不宜强行全自动
|
||||
- 仅想要通用聊天机器人，而不愿定义具体任务与验收标准
|
||||
|
||||
---
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂天猫电商技能组，当前包含 **14** 个技能仓库。
|
||||
|
||||
@@ -52,3 +308,19 @@
|
||||
### 跨境
|
||||
|
||||
- **tmall-optimize-bondedWarehouse** — 天猫国际/保税仓货品调拨与关税核算
|
||||
|
||||
---
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
@@ -1,6 +1,244 @@
|
||||
# client-ecommerce
|
||||
# Amazon 跨境电商 AI 智能体解决方案
|
||||
|
||||
匠厂电商技能组，当前包含 **10** 个 Amazon 相关技能仓库。
|
||||
本页面面向 Amazon 跨境电商卖家团队，说明匠厂如何围绕 Listing、评论、库存、绩效等真实运营流程，开发可落地、可执行、可追溯的 AI 智能体。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- 多站点、多 SKU 上新时，标题、五点、描述、Search Terms 等字段格式要求不一，运营靠表格和模板手工填写，耗时长且易漏项
|
||||
- 已有 Listing 质量分偏低，但不知道优先改哪些字段、哪些词该替换，优化往往凭经验试错
|
||||
- 中文产品资料要同步到美欧日等站点，翻译后关键词本地化不足，影响搜索曝光
|
||||
- 关键词研究分散在第三方工具和表格里，优先级排序依赖个人判断，新品与老品策略难统一
|
||||
- 买家评论量大，差评原因归纳慢，产品改进与回复话术往往滞后
|
||||
- 竞品价格、排名、评论变化需人工定期查看，跟卖出现时取证和响应不够及时
|
||||
- 账号健康、订单缺陷率、迟发率等绩效指标分散在 Seller Central，巡检靠记忆和日历提醒，异常发现偏晚
|
||||
- FBA 与自发货库存分布在多个报表里，补货决策依赖 Excel 推算，断货与冗余库存交替出现
|
||||
|
||||
---
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
### Listing 管理
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
新品上架字段多、格式严，人工填写慢且易不一致；老品 Listing 质量分低但不知从何改起；多站点语言版本维护成本高。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 新品 Listing 创建智能体（标题/五点/描述/ST）
|
||||
- Listing 质量分优化智能体
|
||||
- 多站点 Listing 翻译与本地化智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
符合站点规范的 Listing 草稿；待优化字段清单与改写建议；目标语言 Listing 版本及关键词对照说明。
|
||||
|
||||
### 关键词与优化
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
关键词来源分散，优先级难统一；Search Terms 与标题、五点之间的词库协调靠人工维护。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 关键词挖掘与优先级排序智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
按搜索量、竞争度、相关性排序的关键词列表；建议布局字段（标题/五点/ST）分配方案。
|
||||
|
||||
### 评论与客服
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
评论量大，差评根因归纳慢；回复需兼顾平台规则与品牌语气，忙时容易模板化或遗漏重点。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 买家评论分析智能体（提炼产品改进建议）
|
||||
- 评论回复草稿智能体（含差评应对）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
评论主题与情感摘要；高频问题与改进建议清单；待审核回复草稿（区分公开回复与站内信场景）。
|
||||
|
||||
### 竞品与绩效监控
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
竞品动态需人工盯盘；跟卖出现后的截图与记录分散；账号绩效指标巡检无固定节奏，风险暴露滞后。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 竞品价格/排名/评论监控智能体
|
||||
- 跟卖监控与取证智能体
|
||||
- 店铺绩效巡检智能体（账号健康）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
竞品变动日报或预警清单；跟卖事件记录与取证材料整理；绩效指标巡检报告与异常项说明。
|
||||
|
||||
### 库存预警
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
FBA 可售天数、在途、季节性波动等因素交织，补货点靠人工估算，断货与积压风险难以及时平衡。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 库存预警与补货建议智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
按 SKU/ASIN 的库存水位摘要；建议补货量与补货时点；断货风险与冗余库存提示。
|
||||
|
||||
---
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
### 场景 1：新品 Listing 草稿生成
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
字段结构相对固定，输出便于运营逐项审核；不直接提交后台，风险可控；上新频次高的团队感受直接。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
产品卖点、参数、目标站点与类目；现有优质 Listing 样例；品牌用词规范与禁用表述说明。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
标题、五点、描述、Search Terms 草稿；字段完整性检查清单。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
所有 Listing 内容对外发布前由运营审核；涉及合规、认证、功效宣称等表述须法务或负责人确认。
|
||||
|
||||
### 场景 2：评论分析与改进建议
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
输入为已有评论文本，不涉及自动对外发送；可快速汇总差评根因，支撑产品与运营决策。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
近期评论导出或抓取样例；已知产品质量/物流/包装问题背景；希望关注的分析维度。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
评论主题聚类；差评原因排行；产品改进与 FAQ 补充建议。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
改进建议是否纳入产品迭代由产品负责人确认；对外回复仍走单独审核流程。
|
||||
|
||||
### 场景 3：库存预警与补货建议
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
规则可基于销量、在途、安全库存天数逐步校准；输出为建议而非自动采购，边界清晰。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
FBA 库存与销量报表样例；补货周期、MOQ、季节性系数；现有补货习惯与审批流程。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
按 SKU 的可售天数与预警等级；补货量与建议下单时点；断货/冗余风险提示。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
实际采购单、发货计划由供应链或运营主管确认后执行。
|
||||
|
||||
### 场景 4：店铺绩效巡检
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
指标定义由平台给出，巡检节奏固定；可先对内推送摘要，再扩展为定期报告。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
Seller Central 绩效报表访问或导出方式；内部异常阈值（如 ODR、迟发率）；责任人分工与升级规则。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
核心绩效指标快照；较上期变动说明；异常项与建议跟进动作。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
涉及账号申诉、政策解释、对外沟通的内容由运营负责人确认。
|
||||
|
||||
---
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 项目案例 1：某 Amazon 多 SKU 卖家团队 — Listing 草稿与优化辅助
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 以家居收纳品类为主的 Amazon 跨境卖家，美欧多站点运营，SKU 数量较多，运营小组分工负责上新与维护 |
|
||||
| **原业务流程** | 产品开发提供中文卖点与参数，运营按各站点模板手工撰写标题、五点、描述和 ST；老品质量分低时凭经验改标题或换图，缺少统一优先级；多站点版本靠翻译工具再人工润色 |
|
||||
| **主要问题** | 上新周期长，字段漏填与格式不一致时有发生；优化动作分散，难以批量提升质量分；翻译后关键词本地化不足，各站点维护成本高 |
|
||||
| **匠厂交付内容** | 新品 Listing 创建智能体、Listing 优化智能体、Listing 翻译智能体；统一输出模板与字段检查清单；执行日志与人工审核界面 |
|
||||
| **人工确认节点** | 所有 Listing 提交 Seller Central 前由运营审核；涉及认证、功效、合规表述须负责人确认 |
|
||||
| **上线后变化** | 运营从「从零写文案」转向「审核与微调草稿」；老品优化有字段级待办清单；多站点版本维护更集中、可追溯 |
|
||||
| **适用边界** | 全新品类、强监管类目或需专业检测结论的表述，仍须人工撰写与法务把关；智能体不自动提交后台 |
|
||||
|
||||
### 项目案例 2：某 Amazon 运营小组 — 评论分析、绩效巡检与库存预警
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 以 FBA 为主的 Amazon 卖家，客服与运营合并岗位，需同时关注评论、账号健康与补货节奏 |
|
||||
| **原业务流程** | 运营每日登录后台查看评论，手工记录差评原因；绩效指标靠日历提醒不定期查看；库存用 Excel 结合近 30 天销量估算补货，忙时易断货或积压 |
|
||||
| **主要问题** | 评论归纳滞后，产品问题发现偏晚；绩效异常无固定巡检节奏；库存预警依赖个人记忆，交接班信息不完整 |
|
||||
| **匠厂交付内容** | 评论分析智能体、店铺绩效巡检智能体、库存预警智能体；定期摘要推送到现有协作工具；关键节点执行记录 |
|
||||
| **人工确认节点** | 评论回复对外发送前由客服确认；补货建议转化为采购单须主管审批；涉及账号申诉的操作由负责人执行 |
|
||||
| **上线后变化** | 差评主题与改进建议更早进入待办；绩效异常有固定巡检摘要；补货讨论基于统一预警清单，减少重复查表 |
|
||||
| **适用边界** | 竞品监控、跟卖维权涉及平台政策与法律判断，智能体仅辅助信息整理，不替代最终决策 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂采用 **「理解—执行—连接—把关—追溯」** 的方式，让 Amazon 运营智能体在可控边界内参与日常工作：
|
||||
|
||||
1. **需求访谈** — 了解站点布局、SKU 结构、岗位分工与现有工具（ERP、领星、紫鸟等）
|
||||
2. **流程拆解** — 明确 Listing、评论、库存、绩效等环节的输入、输出与审核规则
|
||||
3. **样例数据确认** — 用真实 Listing、评论、库存报表样例验证规则与输出格式
|
||||
4. **智能体开发** — 按确认方案开发技能，对接必要数据源，保留执行日志
|
||||
5. **小范围试运行** — 先选 1 个站点或 1 条产品线试点，对照人工结果验收
|
||||
6. **培训上线** — 编写操作说明，培训运营与客服，明确人工确认节点
|
||||
7. **持续优化** — 根据大促、类目规则变化迭代模板、关键词策略与预警阈值
|
||||
|
||||
---
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- Listing 撰写、评论整理、库存推算、绩效巡检等重复、可复核的工作
|
||||
- 有历史 Listing、评论、库存报表等样例可供规则配置
|
||||
- 愿意在发布、回复、采购等关键节点保留人工确认
|
||||
- 希望把关键词策略、回复规范、补货规则沉淀为可复用能力
|
||||
- 愿意从 Listing 草稿或评论分析等小场景试点，再逐步扩展
|
||||
|
||||
### 不适合
|
||||
|
||||
- 期望智能体不经审核直接提交 Listing、自动回复全部评论或自动下单补货
|
||||
- 没有任何 Listing 样例、评论数据或库存报表可参考
|
||||
- 不愿提供测试样例或后台导出权限
|
||||
- 涉及账号申诉、知识产权维权等必须律师或高管决策的场景，不宜强行全自动
|
||||
- 仅想要通用聊天机器人，而不愿定义具体任务与验收标准
|
||||
|
||||
---
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂电商技能组，当前包含 **10** 个技能仓库。
|
||||
|
||||
| 技能 slug | 说明 |
|
||||
|---|---|
|
||||
@@ -41,3 +279,19 @@
|
||||
### 库存
|
||||
|
||||
- **amazon-alert-inventory** — 库存预警推送补货建议
|
||||
|
||||
---
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
@@ -1,4 +1,250 @@
|
||||
# client-edu
|
||||
# 教育培训 AI 智能体解决方案
|
||||
|
||||
本页面面向院校与培训机构客户，说明匠厂如何围绕**教务行政、学工、科研、行政办公、财务人事**等真实办事流程，开发可落地、可执行、可追溯的 AI 智能体。本方案聚焦**跨系统填报、通知下发、台账登记、审批发起**等行政场景，而非通用在线课堂或 LMS 教学功能。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- 开课计划、成绩录入、考场安排等需在 Excel 与教务系统之间反复搬运，期末与排考窗口压力大
|
||||
- 学籍变动（转专业、休学、留级）需同步更新学工、财务、宿管等多个系统，容易漏改或不一致
|
||||
- 奖助学金、违纪处分、宿舍分配等学工事务依赖辅导员汇总表，再逐条登录学生系统录入
|
||||
- 科研申报书格式检查、项目进度催报、成果登记分散在邮件与多个系统，行政老师跟进成本高
|
||||
- 收发文、会议纪要、公文签收跟踪在 OA 中步骤多，台账登记靠人工抄写
|
||||
- 经费月报、报销申请需从财务系统导出流水再填模板，附件上传与审批发起重复劳动多
|
||||
- 教职工入职档案、考勤异常上报等人事行政流程与 OA/人事系统衔接繁琐
|
||||
- 各系统界面老旧、无统一 API，大量工作仍是「导出 Excel → 核对 → 登录系统逐条填写」
|
||||
|
||||
---
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
### 教务管理
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
院系开课申请汇总后需登录教务系统逐条填报；教师提交的成绩 Excel 需逐课程录入；考场安排导出后需按班级/教师拆分通知；学籍变动需跨系统同步。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 总上报开课计划智能体（`aggregate-course-plan`）
|
||||
- 批量录入期末成绩智能体（`enter-grades-batch`）
|
||||
- 下发考场安排通知智能体（`dispatch-exam-notice`）
|
||||
- 跨系统同步学籍变动智能体（`sync-student-data`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
开课计划提交状态与未完成项；成绩录入进度与截图留存；考场通知发送记录；学籍同步对照表与异常项。
|
||||
|
||||
### 学工管理
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
违纪记录、宿舍分配、奖助学金名单需从汇总表登录学生系统逐条录入并发起流程。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 归档违纪记录智能体（`archive-disciplinary-record`）
|
||||
- 录入宿舍分配方案智能体（`assign-dormitory`）
|
||||
- 录入奖助学金名单智能体（`enter-scholarship-list`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
系统录入与审批状态；分配/公示流程进度；导出确认清单。
|
||||
|
||||
### 科研管理
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
申报书格式需人工检查页数与必填项；项目进度逾期未报需逐一催办；论文专利获奖、职称申报需逐条登录科研/OA 系统填写。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 检查申报书格式智能体（`check-application-format`）
|
||||
- 催报项目进度智能体（`remind-project-progress`）
|
||||
- 登记科研成果智能体（`register-research-output`）
|
||||
- 录入职称申报信息智能体（`enter-title-application`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
格式问题清单与修改通知；催报消息发送记录；科研成果与职称申报提交状态。
|
||||
|
||||
### 行政办公
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
会议纪要需按模板规范化后走 OA 审批；收发文需登记台账并跟踪签收；对外发文需创建流程并催办未签收单位。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 归档会议纪要智能体（`file-meeting-minutes`）
|
||||
- 登记收发文台账智能体（`register-document-log`）
|
||||
- 发送公文并跟踪签收智能体（`dispatch-official-doc`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
规范化纪要草稿与归档路径；当日收发文台账日报；签收状态与催办清单。
|
||||
|
||||
### 财务人事
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
新员工入职需在 OA/人事系统建档案、走审批；考勤异常需导出识别后生成月度报告；经费月报与报销需填表、传附件、发起流程。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 创建新员工入职档案智能体（`create-onboarding-profile`）
|
||||
- 上报考勤异常智能体（`report-attendance-anomaly`）
|
||||
- 生成经费执行月报智能体（`generate-budget-report`）
|
||||
- 提交报销申请智能体（`submit-reimbursement`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
入职档案与审批进度；考勤异常报告草稿；经费月报与报销审批状态；执行日志与截图留存。
|
||||
|
||||
---
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
### 场景 1：批量录入期末成绩
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
输入（教师 Excel）与输出（教务系统录入状态）清晰；期末窗口痛点集中；可先选若干门课程试点，截图留存便于验收。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
成绩 Excel 样例与教务系统字段对应关系；测试账号或授权方式；录入后截图规范。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
逐课程录入进度；失败/缺字段项清单；截图与执行日志。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
正式提交成绩前由教务老师或院系教学秘书确认；智能体不擅自修改已审核成绩。
|
||||
|
||||
### 场景 2：下发考场安排通知
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
规则明确（按班级/教师拆分）；减少期末手工发通知；可与教务导出流程衔接。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
考场安排导出样例；通知模板（邮件/OA/企业微信）；收件人规则。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
按班级/教师拆分的通知草稿或发送记录；未发送成功项清单。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
通知正文与收件范围发送前由教务或院系确认。
|
||||
|
||||
### 场景 3：总上报开课计划
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
每学期固定节奏；步骤可清单化；适合作为教务智能体入门项目。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
院系开课申请表样例；教务系统开课申请界面流程；汇总确认规则。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
各院系申请录入状态；汇总待确认项；统一提交记录。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
最终开课计划提交教务前由教务处确认。
|
||||
|
||||
### 场景 4：提交报销申请
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
行政与科研人员高频使用；表单字段相对固定；可先只做填表与附件上传，审批仍走原有流程。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
报销清单与发票样例；财务系统表单字段说明；审批流程规则。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
报销单草稿与附件上传状态；缺项提示；发起审批记录。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
报销单提交与金额认定由申请人及财务审核确认；智能体不自动完成付款。
|
||||
|
||||
---
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 项目案例 1：某院校教务办期末成绩录入与考场通知
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某院校教务处（客户名称、教务系统名称已匿名处理），每学期末需处理数百门课程成绩录入与全校考场安排通知 |
|
||||
| **原业务流程** | 教务老师接收各院系教师邮件发来的成绩 Excel，逐课程登录教务系统填写并提交，手工截图留存；从教务系统导出考场安排表，按班级拆分后登录 OA 或邮件系统逐批发送通知，并手工记录发送情况 |
|
||||
| **主要问题** | 期末窗口短，逐条录入与发通知占用大量时间；Excel 与系统字段不一致时反复沟通；缺少统一执行日志，出问题难以追溯是哪一门课、哪一班未处理 |
|
||||
| **匠厂交付内容** | 批量录入期末成绩智能体（`enter-grades-batch`）：读取成绩 Excel，按字段映射逐课程登录教务系统填写、提交并截图留存；下发考场安排通知智能体（`dispatch-exam-notice`）：导出考场表按规则拆分，批量发送通知并记录状态；配套执行日志与待处理清单 |
|
||||
| **人工确认节点** | 成绩正式提交与考场通知对外发送前，由教务老师确认；涉及成绩修改、补考等特殊情形不自动处理 |
|
||||
| **上线后变化** | 机械录入与通知发送效率提高；未完成项更早进入待处理列表；教务人员可将更多时间用于异常协调与政策解释 |
|
||||
| **适用边界** | 需客户提供成绩表样例、教务/OA 授权与字段映射；系统界面或流程变更时需同步维护适配 |
|
||||
|
||||
### 项目案例 2：某院校科研与行政办事跨系统填报
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某院校科研处与综合办公室（客户名称已匿名处理），负责项目申报格式初审、成果登记、收发文台账与经费月报等日常行政 |
|
||||
| **原业务流程** | 老师提交申报书 Word 后，行政人员手工检查页数与必填项并电话通知修改；论文专利汇总表需逐条登录科研系统登记；每日从 OA 抓取收发文记录填台账；月底从财务系统导出流水填经费月报模板再提交 OA |
|
||||
| **主要问题** | 格式检查与逐条登记重复劳动多；项目进度逾期未报需人工查系统再逐个催办；台账与月报依赖复制粘贴，忙时易漏项 |
|
||||
| **匠厂交付内容** | 检查申报书格式智能体（`check-application-format`）：自动检查页数/字数/必填项并标注问题；登记科研成果智能体（`register-research-output`）与催报项目进度智能体（`remind-project-progress`）；登记收发文台账智能体（`register-document-log`）与生成经费执行月报智能体（`generate-budget-report`）；配套执行日志 |
|
||||
| **人工确认节点** | 格式问题通知、成果登记提交、月报对外报送前由对应行政岗位确认；智能体不擅自修改已归档公文或财务数据 |
|
||||
| **上线后变化** | 格式初审与台账整理效率提高；催报与登记进度更可追踪；行政人员审核更聚焦例外与协调事项 |
|
||||
| **适用边界** | 需客户提供申报书样例、科研/OA/财务系统授权；涉密项目、特殊审批链路需单独配置规则 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂采用 **“理解—执行—连接—把关—追溯”** 的方式，让院校行政智能体在可控边界内参与日常工作：
|
||||
|
||||
1. **需求访谈** — 了解教务、学工、科研、行政、财务人事各环节及现有系统（教务、OA、财务、宿管等）使用情况
|
||||
2. **流程拆解** — 明确输入（Excel、导出表、Word、发票）、输出（系统录入状态、通知记录、台账）与字段映射
|
||||
3. **样例数据确认** — 用真实历史样例验证映射规则、通知模板与截图规范是否可行
|
||||
4. **智能体开发** — 按确认方案开发或组合技能，内部测试并保留执行日志
|
||||
5. **小范围试运行** — 先选 1 个环节（如单院系成绩录入或单项台账）试用，对照人工结果验收
|
||||
6. **培训上线** — 编写操作说明，培训教务/行政人员，明确提交与发送前确认节点
|
||||
7. **持续优化** — 根据学期节奏、系统改版、新增表单迭代规则
|
||||
|
||||
---
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- 重复、高频、规则相对明确的跨系统填报、通知、登记工作
|
||||
- 有 Excel 模板、OA 流程、系统导出样例可供字段映射配置
|
||||
- 愿意在成绩提交、通知发送、报销审批等关键节点保留人工确认
|
||||
- 希望把字段映射、通知模板、台账格式沉淀为可复用能力
|
||||
- 愿意从成绩录入、考场通知、单项台账等小场景试点，再逐步扩展
|
||||
|
||||
### 不适合
|
||||
|
||||
- 期望智能体承担完整在线教学（直播授课、在线作业、学习路径等）产品能力
|
||||
- 完全没有表单样例、系统账号或流程文档可参考
|
||||
- 期望智能体无需人工即可承担全部教务审核与财务审批责任
|
||||
- 不愿提供测试样例或系统操作授权
|
||||
- 涉密数据、高权限写操作不愿设置人工确认与日志追溯
|
||||
|
||||
---
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂教育行业技能组，当前包含 **18** 个技能仓库。
|
||||
|
||||
@@ -60,3 +306,19 @@
|
||||
|
||||
- **generate-budget-report** — 生成经费执行月报（从财务系统导出月度流水，按项目/部门汇总，填写月报模板并提交至 OA 存档）
|
||||
- **submit-reimbursement** — 提交报销申请（读取报销清单和发票图片，登录财务系统填写表单、上传附件、发起审批流程）
|
||||
|
||||
---
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
@@ -1,4 +1,273 @@
|
||||
# client-finance
|
||||
# 财务与对账 AI 智能体解决方案
|
||||
|
||||
本页面面向财务与对账职能客户，说明匠厂如何围绕真实业务流程，开发可落地、可执行、可追溯的 AI 智能体。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- 发票、账单、银行流水、平台对账单格式不统一，整理和录入占用大量时间
|
||||
- 月结、年结期间核对压力大，同一笔业务要在多个系统、多张表里反复查找
|
||||
- 重复报销、重复计费、漏录、金额差异等问题，往往靠人工逐条排查才能发现
|
||||
- 应收应付账龄、催款、付款安排依赖 Excel 和个人经验，容易遗漏或跟进不及时
|
||||
- 凭证编制、科目映射、报表勾稽规则复杂，新人上手慢、出错率高
|
||||
- 增值税、所得税等申报数据分散在业务系统和台账里，汇总核对费时
|
||||
- 多账户、多币种资金情况难以及时汇总，管理层看不到当日可用资金全貌
|
||||
- 费用报销、关联交易、异常交易等合规检查，常滞后于业务发生
|
||||
|
||||
---
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
### 发票管理
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
员工报销、采购付款、进项抵扣等环节，发票来源多、格式杂，人工录入慢且易错；重复发票、不合规发票难以及时发现。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 发票识别智能体
|
||||
- 发票验真与合规校验智能体
|
||||
- 发票去重与重复报销检测智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
结构化发票台账（金额、税额、销方、日期、发票号码等）；验真结果与不合规项清单；疑似重复报销预警列表。
|
||||
|
||||
### 银行/平台对账
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
银行流水、支付宝/微信/Stripe 等平台账单与内部账务、业务明细格式不一致，逐行核对工作量大，差异定位慢。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 银行流水智能对账智能体
|
||||
- 电商/支付平台流水对账智能体
|
||||
- 总账明细账勾稽核对智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
归一化对账表；已匹配/未匹配/差异项清单；按单号、金额、日期分类的差异说明草稿。
|
||||
|
||||
### 应收应付
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
应收账龄、催收优先级、应付付款安排分散在多个表格里，核销和对账依赖人工记忆和反复沟通。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 应收应付往来账核销智能体
|
||||
- 应收账款账龄分析与催收智能体
|
||||
- 应付账款付款计划编排智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
账龄分析表与催收优先级清单；核销匹配建议；按到期日和资金情况排列的付款计划草稿。
|
||||
|
||||
### 凭证与报表
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
从业务数据到记账凭证、三大报表、管理报表的转换环节多，科目映射和勾稽规则靠人工维护，报表编制周期长。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 记账凭证智能生成智能体
|
||||
- 凭证合规性自查智能体
|
||||
- 会计科目表标准化映射智能体
|
||||
- 三大报表自动生成智能体
|
||||
- 管理报表编制智能体
|
||||
- 多主体合并报表智能体
|
||||
- 同比环比与预算差异分析智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
待审核凭证草稿；科目映射对照表；资产负债表/利润表/现金流量表草稿；部门/项目/产品线损益表；差异分析说明。
|
||||
|
||||
### 税务与合规
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
增值税、所得税申报数据汇总繁琐；税负异常、费用超标、关联交易、审计底稿等合规工作滞后且依赖个人经验。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 增值税申报辅助智能体
|
||||
- 个人所得税计算与申报智能体
|
||||
- 企业所得税预缴与汇算清缴辅助智能体
|
||||
- 税负率监控与风险预警智能体
|
||||
- 报销单智能审核智能体
|
||||
- 费用政策合规检查智能体
|
||||
- 财务数据异常检测智能体
|
||||
- 关联交易识别与标记智能体
|
||||
- 审计底稿自动生成智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
申报数据汇总表与待核对项；税负监控预警；超标报销与政策违规清单；异常交易与关联交易标记表；审计底稿框架。
|
||||
|
||||
### 资金日报
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
多个银行账户、平台账户、外币账户的资金余额和当日变动分散查询，资金日报靠人工汇总，时效性和准确性难保证。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 多账户资金日报智能体
|
||||
- 现金流滚动预测智能体
|
||||
- 多币种折算与汇率应用智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
当日各账户余额与变动汇总；未来若干期现金流预测表；按统一本位币折算后的资金视图。
|
||||
|
||||
---
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
### 场景 1：多渠道账单对账与差异标记
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
规则相对明确，输入输出容易验收；月结痛点集中，见效直观；可先从一个银行或一个平台渠道试点。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
历史账单样例（PDF/Excel）；内部业务明细或总账导出样例；现有对账规则和差异分类习惯。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
统一格式对账表；差异清单（多计、少计、单号不匹配等）；执行日志。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
差异项的处理结论、调账申请、付款审批均由财务人员确认后执行；智能体不自动修改财务系统数据。
|
||||
|
||||
### 场景 2：发票识别与报销初审
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
发票样式虽多但字段结构相对固定；可显著减少录入和初审时间；风险可控，可先只做识别与验真，不自动入账。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
常见发票样例（纸质扫描、PDF、拍照）；费用报销制度与超标规则；现有发票台账或报销模板。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
结构化发票字段；验真结果；重复报销预警；超标与不合规项清单。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
发票是否纳入报销、会计科目归属、最终入账和付款动作由财务或审批人确认。
|
||||
|
||||
### 场景 3：银行流水与账务自动对账
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
银行流水格式相对稳定；匹配规则（金额、日期、摘要）可逐步完善；适合作为财务智能体入门项目。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
银行流水导出样例；对应期间账务明细；已知匹配规则与常见未达账项说明。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
已匹配清单；未达账项与差异项；对账进度汇总。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
自动匹配结果需财务复核；未明差异项的处理方案由人工判定。
|
||||
|
||||
### 场景 4：多账户资金日报
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
汇总逻辑清晰，不涉及复杂会计判断；管理层价值感知强；可先接 2–3 个主要账户验证。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
各账户余额查询方式或导出样例；日报模板与关注指标；本位币及汇率来源说明（如有外币账户）。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
按账户、按币种汇总的资金日报；较昨日/较上周变动说明；异常大额变动提示。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
日报对外报送前由资金或财务主管确认；涉及对外披露口径由人工把关。
|
||||
|
||||
---
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 项目案例 1：某企业财务对账表自动整理与差异标记
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某有跨境及物流业务的企业（客户名称、财务系统名称已匿名处理），每月需与多家承运商、海外仓、平台方核对运费与服务费 |
|
||||
| **原业务流程** | 月结前，财务人员从邮箱下载各渠道 PDF、Excel 账单，按内部模板手工整理字段；再导出业务系统明细，逐行比对单号、金额、币种、计费重量等；发现差异后标注颜色、写备注，逐笔联系业务或供应商核实 |
|
||||
| **主要问题** | 账单格式五花八门，整理阶段就占用大量时间；月结窗口短、压力大；差异项散落在多张表里，定位慢、容易遗漏重复计费或漏录 |
|
||||
| **匠厂交付内容** | 对账整理智能体：识别并归一化各渠道账单格式，映射到统一对账模板；按预设规则与内部明细比对，输出差异清单（多计、少计、单号不匹配等）；配套对账模板、差异分类规则与执行日志 |
|
||||
| **人工确认节点** | 差异项的处理结论、调账申请、付款审批均由财务人员确认后执行；智能体不自动修改财务系统数据 |
|
||||
| **上线后变化** | 对账表整理时间缩短；差异项定位更快；财务人员可集中精力处理有争议的条目，人工审核更聚焦 |
|
||||
| **适用边界** | 需客户提供历史账单样例和内部对账规则；首次上线建议从 1–2 个渠道试点，规则稳定后再扩展 |
|
||||
|
||||
### 项目案例 2：某企业发票识别与报销初审辅助
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某多主体、多部门的企业客户（客户名称已匿名处理），员工每月通过企业微信、邮件、扫描件提交大量报销发票 |
|
||||
| **原业务流程** | 财务助理逐张打开发票图片或 PDF，手工录入金额、税额、销方、发票号码等字段；再登录税务平台或第三方工具验真；对照费用制度检查是否超标、是否重复报销；整理通过后转交会计入账 |
|
||||
| **主要问题** | 发票来源分散、版式不一，录入耗时长；验真和去重要切换多个工具；初审标准依赖个人经验，忙时容易漏检重复票或不合规项 |
|
||||
| **匠厂交付内容** | 发票识别智能体：从图片、PDF 中提取并结构化发票字段，标注识别置信度低的项；发票验真与合规校验智能体：对接验真规则，输出验真结果与不合规提示；发票去重智能体：与历史报销库比对，标记疑似重复；配套报销初审清单与执行日志 |
|
||||
| **人工确认节点** | 发票是否纳入本次报销、费用类别归属、最终审核结论由财务或审批人确认；智能体不自动完成付款 |
|
||||
| **上线后变化** | 发票录入与初审整理效率提高；重复报销和验真遗漏更早进入待处理列表；财务助理可将更多时间用于异常项复核与沟通 |
|
||||
| **适用边界** | 需客户提供常见发票样例和费用制度；全电发票、境外发票等特殊类型需单独配置规则；复杂分摊和多笔合并报销仍建议人工处理 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂采用 **“理解—执行—连接—把关—追溯”** 的方式，让财务智能体在可控边界内参与日常工作：
|
||||
|
||||
1. **需求访谈** — 了解对账、报销、报表、申报等具体流程，以及现有 ERP/财务软件使用情况
|
||||
2. **流程拆解** — 明确输入（账单、发票、流水、台账）、输出（对账表、凭证草稿、报表）和判断规则
|
||||
3. **样例数据确认** — 用真实历史样例验证识别、匹配、映射规则是否可行
|
||||
4. **智能体开发** — 按确认方案开发技能，内部测试并保留执行日志
|
||||
5. **小范围试运行** — 在 1–2 个渠道、1 个主体或 1 个岗位试用，对照人工结果验收
|
||||
6. **培训上线** — 编写操作说明，培训财务相关人员，明确人工确认节点
|
||||
7. **持续优化** — 根据月结反馈扩展渠道、完善规则、增加报表维度
|
||||
|
||||
---
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- 重复、高频、规则相对明确的财务整理与核对工作
|
||||
- 有历史账单、发票、流水、台账等样例数据可供规则配置
|
||||
- 愿意在记账、付款、申报等关键节点保留人工确认
|
||||
- 希望把对账规则、科目映射、费用制度沉淀为可复用能力
|
||||
- 愿意从单渠道对账、发票识别等小场景试点，再逐步扩展
|
||||
|
||||
### 不适合
|
||||
|
||||
- 完全没有对账规则、科目表或制度文档可参考
|
||||
- 期望智能体无需人工即可承担全部财务判断和审计责任
|
||||
- 不愿提供测试样例或系统导出权限
|
||||
- 高风险动作（自动过账、自动付款、自动对外申报）不愿设置人工确认
|
||||
- 流程完全因人而异、无任何标准模板或样例
|
||||
|
||||
---
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂财务技能组，当前包含 **29** 个技能仓库。
|
||||
|
||||
@@ -94,3 +363,19 @@
|
||||
### 审计
|
||||
|
||||
- **build-audit-workpaper** — 审计底稿自动生成
|
||||
|
||||
---
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
@@ -1,4 +1,241 @@
|
||||
# client-hr
|
||||
# 人力资源 AI 智能体解决方案
|
||||
|
||||
本页面面向人力资源职能客户，说明匠厂如何围绕真实业务流程，开发可落地、可执行、可追溯的 AI 智能体。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- 招聘旺季简历量大，HR 逐份对照 JD 初筛，标准难以统一、耗时整块工作时间
|
||||
- 业务部门提出碎片化用人需求，JD 编写重复，各岗位描述质量参差不齐
|
||||
- 面试安排需在 HR、用人部门、候选人之间多方协调，改期频繁、沟通成本高
|
||||
- 员工就请假、报销、福利、考勤制度反复咨询 HR，打断核心招聘工作
|
||||
- 新员工入职涉及企业微信/钉钉、邮箱、OA 等多系统开户与权限，容易遗漏步骤
|
||||
- 月结前考勤异常、请假审批、绩效系数需人工核对后再算薪，核对工作量大
|
||||
- 工资条拆分与私密发放依赖手工操作，格式与安全要求难兼顾
|
||||
- 绩效考核季需整合全年 OKR/KPI 与周报，主管初评小结撰写重复劳动多
|
||||
- 入离职数据分散，司龄、部门流动率、流失风险分析靠 Excel，难以及时预警
|
||||
|
||||
---
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
### 招聘
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
各渠道简历格式不一，人工提取学历、年限、技能并对照 JD 匹配慢；JD 编写重复且合规性难保证。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 简历初筛智能体（`screen-resume`）
|
||||
- 职位描述拟定智能体（`draft-jd`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
简历匹配得分与初筛建议；存疑项标注；结构化 JD 草稿（职责、要求、合规表述）。
|
||||
|
||||
### 入转离
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
新员工录用后多系统开户、发欢迎信步骤多；入离职数据清洗与流动率分析依赖人工汇总。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 员工入职办理智能体（`onboard-employee`）
|
||||
- 人员流失分析智能体（`analyze-turnover`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
入职任务清单与执行日志；多系统账号创建状态；司龄分布、部门流动率与流失风险预警报告。
|
||||
|
||||
### 薪酬福利
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
算薪前需核对考勤异常、请假与绩效系数；工资条拆分与一对一发放操作繁琐。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 薪酬核算智能体（`calculate-payroll`）
|
||||
- 工资条发放智能体（`distribute-payslip`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
工资明细总表草稿（待 HR 审核）；个税计算明细；按员工拆分的电子工资条发送记录。
|
||||
|
||||
### 绩效
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
考核季需从多个系统调取 OKR/KPI 与周报，整合成客观初评小结供主管复核，整理工作量大。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 绩效数据总结智能体（`summarize-performance`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
员工绩效初评小结草稿；关键指标与周报摘要引用；待主管补充的主观评价项提示。
|
||||
|
||||
### 员工服务
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
员工手册、考勤制度、福利政策等咨询重复，HR 频繁被打断；答案口径不一致。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 员工政策答疑智能体（`answer-query`）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
带制度出处的问答回复；需转人工处理的敏感问题清单；咨询日志便于 HR 复盘缺口。
|
||||
|
||||
---
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
### 场景 1：简历初筛
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
输入（简历 + JD）与输出（匹配分、建议）相对明确；可显著减轻旺季初筛压力；风险可控，不替代最终录用决策。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
各岗位 JD 与硬性筛选条件；历史简历样例；「必过/必拒」规则说明。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
初筛结果列表（匹配得分、推荐理由、存疑项）；执行日志。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
进入面试环节的候选人由 HR 最终确认；高端岗、管理岗仍建议人工通读简历。
|
||||
|
||||
### 场景 2：员工政策问答
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
不涉及写回 HR 系统；可快速减少重复咨询；答案可引用制度原文，便于审计。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
经审核的员工手册、考勤制度、福利政策等文档；需转人工的问题类型清单。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
带出处的政策答复；无法回答或需升级的问题列表。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
涉及个案审批、薪酬调整、纪律处分等仍引导至 HR 人工处理；知识库变更需管理员审核后生效。
|
||||
|
||||
### 场景 3：职位描述（JD）拟定
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
业务部门需求常口头描述，标准化 JD 可缩短启动招聘周期；可先覆盖高频岗位模板。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
现有 JD 样例与岗位族分类；合规禁用表述说明；行业关键词偏好。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
结构化 JD 草稿；与口头需求的差异对照；待业务确认项清单。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
JD 对外发布前由 HR 与用人部门共同确认；薪酬范围、汇报关系等敏感信息不自动定稿。
|
||||
|
||||
### 场景 4：员工入职办理
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
步骤清单清晰，适合 RPA/脚本与智能体结合；遗漏步骤可对照日志追溯。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
入职 SOP 与各系统开户流程；账号命名与权限模板；欢迎信模板。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
各系统开户与通知执行状态；未完成项清单；执行日志。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
权限级别、特殊账号、合同签署等关键节点由 HR 确认后执行；智能体不擅自授予高权限。
|
||||
|
||||
---
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 项目案例 1：某企业 HR 简历初筛与面试协调
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某企业人力资源部门（客户名称已匿名处理），业务扩张期同时开放销售、运营、技术等十余类岗位招聘 |
|
||||
| **原业务流程** | HR 每日从招聘平台导出简历，逐份阅读并对照 JD 标注是否进入下一轮；确定候选人后，通过邮件或企业微信与用人部门面试官、候选人多方协调面试时间；员工常就请假、报销、制度条款向 HR 重复咨询 |
|
||||
| **主要问题** | 简历量大时初筛占用整块工作时间；面试协调来回沟通多，改期频繁；制度类咨询打断 HR 核心招聘工作 |
|
||||
| **匠厂交付内容** | 简历初筛智能体：按岗位 JD 和硬性条件输出初筛结果与推荐理由，标注存疑项；面试协调智能体：汇总面试官可用时段，生成协调建议供 HR 确认发送；员工政策问答智能体：基于制度文档回答常见咨询并引用出处 |
|
||||
| **人工确认节点** | 进入面试环节的候选人由 HR 最终确认；面试邀请、时间变更通知发送前需 HR 审核；录用决策仍由 HR 与用人部门共同做出 |
|
||||
| **上线后变化** | 简历初筛效率提高；面试协调沟通次数减少；重复制度咨询减少，HR 审核更聚焦，事务性工作压力下降 |
|
||||
| **适用边界** | 需客户提供岗位 JD、筛选标准和经审核的制度文档；高端岗位、管理岗等需深度评估的候选人仍建议人工通读简历 |
|
||||
|
||||
### 项目案例 2：某企业薪酬核算与工资条发放辅助
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某中型企业人力资源部门（客户名称已匿名处理），员工规模数百人，每月需核对考勤与绩效后完成算薪与工资条发放 |
|
||||
| **原业务流程** | HR 从考勤系统导出异常记录，对照 OA 请假审批与绩效系数表手工核对；在 Excel 中套用公式计算应发、扣款与个税，生成总表后逐人拆分工资条，通过邮件或企业内应用发送 |
|
||||
| **主要问题** | 考勤与请假数据分散，核对耗时长；公式与个税规则更新时易出错；工资条拆分与发送重复劳动多，忙时易漏发或格式不一 |
|
||||
| **匠厂交付内容** | 薪酬核算智能体（`calculate-payroll`）：自动拉取并核对考勤异常、请假审批与绩效系数，套用个税规则生成工资明细总表草稿；工资条发放智能体（`distribute-payslip`）：读取审核后的总表，拆分并一对一私密发送电子工资条；配套执行日志与异常项清单 |
|
||||
| **人工确认节点** | 工资总表定稿、个别调薪与扣款项由 HR 确认后发放；智能体不自动修改已归档薪酬数据 |
|
||||
| **上线后变化** | 算薪前核对与工资条整理效率提高；异常项更早进入待处理列表；HR 可将更多时间用于薪酬政策沟通与个案处理 |
|
||||
| **适用边界** | 需客户提供考勤导出样例、绩效规则与现有工资表模板；复杂股权激励、外籍员工税务等特殊情形需单独配置 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂采用 **“理解—执行—连接—把关—追溯”** 的方式，让人力资源智能体在可控边界内参与日常工作：
|
||||
|
||||
1. **需求访谈** — 了解招聘、入转离、薪酬、绩效、员工服务等具体流程及现有 HRIS/OA 使用情况
|
||||
2. **流程拆解** — 明确输入（简历、JD、考勤、制度文档）、输出（初筛结果、工资表、问答）与判断规则
|
||||
3. **样例数据确认** — 用真实历史样例验证筛选规则、算薪逻辑与知识库检索是否可行
|
||||
4. **智能体开发** — 按确认方案开发或组合技能，内部测试并保留执行日志
|
||||
5. **小范围试运行** — 在 1–2 个岗位族或 1 个流程环节试用，对照人工结果验收
|
||||
6. **培训上线** — 编写操作说明，培训 HR 相关人员，明确人工确认节点
|
||||
7. **持续优化** — 根据招聘季反馈、制度变更、系统改版迭代规则与知识库
|
||||
|
||||
---
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- 重复、高频、规则相对明确的人事整理、核对与答疑工作
|
||||
- 有 JD、制度文档、考勤规则、工资表模板等样例可供配置
|
||||
- 愿意在录用、算薪定稿、权限授予等关键节点保留人工确认
|
||||
- 希望把筛选标准、算薪规则、制度知识沉淀为可复用能力
|
||||
- 愿意从简历初筛、政策问答等小场景试点，再逐步扩展
|
||||
|
||||
### 不适合
|
||||
|
||||
- 完全没有 JD、制度或薪酬规则可参考
|
||||
- 期望智能体无需人工即可承担全部 HR 判断与劳动合规责任
|
||||
- 不愿提供测试样例或系统导出权限
|
||||
- 录用、定薪、权限变更等高风险动作不愿设置人工确认
|
||||
- 流程完全因人而异、无任何标准模板或样例
|
||||
|
||||
---
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂人力资源技能组，当前包含 **8** 个技能仓库。
|
||||
|
||||
@@ -37,3 +274,19 @@
|
||||
### 员工服务
|
||||
|
||||
- **answer-query** — 员工政策答疑，挂载企业员工手册、考勤制度、福利政策等知识库，作为 HR 虚拟助手全天候自动理解并精准回答员工的日常人事政策咨询
|
||||
|
||||
---
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
@@ -1,4 +1,339 @@
|
||||
# client-logistics
|
||||
# 物流与货代 AI 智能体解决方案
|
||||
|
||||
本页面面向物流与货代客户，说明匠厂如何围绕真实业务流程，开发可落地、可执行、可追溯的 AI 智能体。
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- 客户询价来自微信、邮件、表格、截图，格式不统一，业务员每天要花大量时间整理要素、反复确认起运港、目的港、箱型箱量和时效要求
|
||||
- 查舱位、查船期、查轨迹、查费用分散在多个网站、船司系统和内部表格里，机械查询占用一线大量时间
|
||||
- 客户催问「货到哪里了」「为什么还没放行」，异常往往在客户投诉前才被发现，被动响应多、主动预警少
|
||||
- 托书、发票、装箱单、提单、报关单之间信息不一致，改单、退单、查验时才发现错漏，处理成本高
|
||||
- 对账依赖人工逐行核对船司账单、拖车账单、客户 SOA，差异定位慢，月结期间财务和操作压力集中
|
||||
- 新人要熟悉各航线、各船司、各客户特殊要求，培训周期长，经验多在老员工脑子里，交接容易断档
|
||||
- 管理层想看航线利润、客户贡献、异常率，数据要从多个系统导出再手工汇总，报表往往滞后
|
||||
- 合规筛查、归类、禁限品判断依赖人工查清单、问同事，高峰期容易漏检或反复确认
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
### 询价与报价
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 从邮件、微信、附件中自动提取询价要素，减少手工抄录和漏项
|
||||
- 结合费率表、协议价和附加费规则，快速生成可对比的报价草稿
|
||||
- 报价后跟进提醒、成交率分析，帮助销售把精力放在客户沟通上
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 询价邮件整理智能体
|
||||
- 综合报价草稿智能体
|
||||
- 协议价与附加费核算智能体
|
||||
- 报价跟进提醒智能体
|
||||
- 投标应标文件辅助智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 结构化询价单（起运港、目的港、品名、箱型箱量、贸易条款、时效要求）
|
||||
- 多方案对比报价单（海运费、本地费、目的港费、杂费明细）
|
||||
- 待跟进客户清单与建议话术
|
||||
- 应标文件初稿与历史投标复用建议
|
||||
|
||||
### 轨迹查询与异常提醒
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 海运、空运、陆运、快递轨迹统一查询，减少多网站切换
|
||||
- 船期变更、中转延误、滞箱滞港、温控异常等主动提醒，而不是等客户来问
|
||||
- 订舱确认、VGM 截止、报关放行等关键节点进入待办列表
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 全程运单追踪智能体
|
||||
- 集装箱动态监控智能体
|
||||
- 运输异常预警智能体
|
||||
- 船期变更提醒智能体
|
||||
- 报关进度追踪智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 单票货物最新节点与时间线摘要
|
||||
- 异常待处理清单（延误、甩柜、查验、超期费等）
|
||||
- 关键截止时间提醒（截关、截 VGM、截补料等）
|
||||
- 客户可发送的状态说明草稿
|
||||
|
||||
### 单证与资料核对
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 从托书、PDF、Excel 中提取收发货人、唛头、品名、数量等要素，减少重复录入
|
||||
- 商业发票、装箱单、提单、报关单之间自动比对，提前发现不一致
|
||||
- 报关制单、产地证、保险单等单证草稿生成，操作员专注审核而非从零填写
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 托书解析与建档智能体
|
||||
- 跨单证一致性核对智能体
|
||||
- 提单与发票校验智能体
|
||||
- 报关制单辅助智能体
|
||||
- 合规与禁限品预检智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 结构化托书/订单信息
|
||||
- 单证差异对照表（字段、原值、建议修正）
|
||||
- 报关单及随附单证草稿
|
||||
- 合规风险提示清单（归类、品牌、危险品、制裁筛查等）
|
||||
|
||||
### 对账与财务
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 客户 SOA、船司账单、拖车账单自动匹配，差异行高亮，减少逐行核对
|
||||
- 共用费用分摊、多币种换算、凭证草稿生成，缩短月结整理时间
|
||||
- 应收账龄、逾期预警、催款话术分级生成，财务跟进更有节奏
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 对账单智能核销智能体
|
||||
- 承运人账单审核智能体
|
||||
- 共用费用分摊智能体
|
||||
- 对客开票草稿智能体
|
||||
- 应收逾期提醒智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 已对平/待确认差异清单
|
||||
- 重复计费、金额异常、科目错配提示
|
||||
- 分摊结果表与开票明细草稿
|
||||
- 分级催款话术与账龄摘要
|
||||
|
||||
### 客户服务与通知
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 常见问题、轨迹查询、业务咨询自动应答，减轻前台重复回复压力
|
||||
- 到港、放行、签收、异常等节点按客户偏好自动通知
|
||||
- 投诉分级升级、道歉函与补偿方案草稿，服务响应更规范
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 货代智能客服智能体
|
||||
- 客户节点通知智能体
|
||||
- 投诉升级路由智能体
|
||||
- 内部知识库问答智能体
|
||||
- 客户自助门户辅助智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 客户咨询答复草稿（含轨迹摘要与下一步建议）
|
||||
- 按模板生成的状态通知（邮件/消息草稿）
|
||||
- 投诉处理单与责任人分派建议
|
||||
- SOP、客户特殊要求、历史工单检索答案
|
||||
|
||||
### 经营分析
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
- 订单利润、航线贡献、客户价值分层自动汇总，管理层不必等手工报表
|
||||
- 销售漏斗、成交率、供应商绩效等分析定期输出，支持经营决策
|
||||
- 箱量预测、运价走势、现金流滚动预测辅助锁仓、谈价和资金安排
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 订单利润分析智能体
|
||||
- 航线与客户经营看板智能体
|
||||
- 销售漏斗诊断智能体
|
||||
- 供应商绩效报告智能体
|
||||
- 经营周报月报智能体
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
- 多维度利润排名与异常波动提示
|
||||
- 航线/客户/业务员贡献度摘要
|
||||
- 询价到成单转化率与胜负原因分析
|
||||
- 可钻取的 KPI 看板与定期经营报告
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
### 试点一：询价邮件整理 + 报价草稿
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 每天发生频次高，业务员感受直接，价值容易量化
|
||||
- 规则相对明确（港口、箱型、费率表、附加费），智能体输出便于人工复核
|
||||
- 不直接对外发送，风险可控
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 典型询价邮件/微信/表格样例（脱敏即可）
|
||||
- 常用航线费率表、协议价、附加费规则
|
||||
- 现有报价单模板与审批习惯
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 结构化询价单
|
||||
- 含多方案对比的报价草稿
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 询价要素是否提取完整、准确
|
||||
- 报价金额、贸易条款、有效期是否可对外发送
|
||||
|
||||
### 试点二：运单轨迹查询 + 异常提醒
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 查询动作重复、耗时，客户催问压力大
|
||||
- 接入轨迹数据源后，智能体可汇总状态并主动推送异常
|
||||
- 可先对内使用，验证节点准确性后再对客户开放摘要
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 常用承运人/船司/航司及现有查询方式
|
||||
- 内部异常定义（如延误天数、甩柜、查验、滞箱费阈值）
|
||||
- 客户通知模板与通知渠道偏好
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 单票轨迹时间线摘要
|
||||
- 异常待办清单与通知草稿
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 节点时间与状态是否与客户/承运人信息一致
|
||||
- 对外通知内容是否准确、语气是否合适
|
||||
|
||||
### 试点三：跨单证一致性核对
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 错单改单成本高，提前发现不一致能直接减少损失
|
||||
- 比对规则清晰（品名、数量、金额、唛头、收发货人等）
|
||||
- 适合在制单完成后、提交前作为固定复核环节
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 商业发票、装箱单、提单、报关单等典型样例（含历史改单案例更佳）
|
||||
- 各客户、各航线的字段要求与常见错漏点
|
||||
- 现有审核流程与责任人分工
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 字段级差异对照表
|
||||
- 建议修正项与风险说明
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 差异是否属实、是否必须改单
|
||||
- 涉及金额、品名、贸易条款的修正需操作主管确认
|
||||
|
||||
### 试点四：SOA 对账差异标记
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 月结对账痛点集中，差异定位慢
|
||||
- 匹配规则可逐步完善（柜号、提单号、费用科目、金额容差）
|
||||
- 智能体只做「标记差异」，核销与入账仍由财务把关
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 客户 SOA、内部台账、船司/拖车账单样例
|
||||
- 费用科目映射关系与常见差异类型
|
||||
- 现有对账流程与月结时间表
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 已匹配/待确认/无法匹配明细
|
||||
- 差异原因分类与跟进建议
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 差异是否可接受、是否需要追收或调整
|
||||
- 确认后的核销结果方可入账或对外回复
|
||||
|
||||
### 试点五：内部知识库问答（SOP / 客户特殊要求）
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
- 投入相对小，新人与跨岗同事立即可用
|
||||
- 不直接改动对外单证或财务数据，风险低
|
||||
- 可快速沉淀老员工经验，减少「问人」和重复培训
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
- 操作手册、SOP、航线指引、客户特殊要求文档
|
||||
- 历史工单或常见问题汇总（脱敏）
|
||||
- 希望覆盖的岗位场景（操作、销售、客服、报关等）
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
- 带来源引用的问答答复
|
||||
- 未覆盖问题清单，供后续补充知识库
|
||||
|
||||
**人工确认点**
|
||||
|
||||
- 涉及合规、放货、改单等关键操作时，仍须人工按制度执行
|
||||
- 新知识入库前由业务负责人审核准确性
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 案例一：某国际货代企业 — 询价整理与报价辅助
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 以海运出口为主的国际货代，销售与操作分岗，日询价量较大 |
|
||||
| **原业务流程** | 销售从邮件、微信收集询价，手工填入 Excel 或 OMS，再查费率表做报价，忙时易漏项、报价比价慢 |
|
||||
| **主要问题** | 询价要素整理耗时长；同一客户多次询价重复录入；报价版本多、难追溯；新人报价一致性差 |
|
||||
| **匠厂交付内容** | 询价邮件整理智能体、综合报价草稿智能体、报价跟进提醒；对接现有费率表与报价模板；执行日志与人工确认界面 |
|
||||
| **人工确认节点** | 结构化询价单发送前由销售确认；报价对外发送前必须人工审核金额与条款 |
|
||||
| **上线后变化** | 销售从「整理信息」转向「谈条款与成单」；报价草稿可追溯；漏项类差错在复核环节前置发现 |
|
||||
| **适用边界** | 非标特种货、需现场勘验或复杂合规论证的询价，仍须专家介入；智能体不替代最终报价审批权 |
|
||||
|
||||
### 案例二：某货代企业 — 轨迹汇总与异常待办
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 海空联运货代，客服需频繁回复客户在途状态，操作需跟踪甩柜、查验、滞箱等异常 |
|
||||
| **原业务流程** | 客服、操作分别在船司网站、承运人平台、内部表格查询，再手工回复客户或登记异常 |
|
||||
| **主要问题** | 查询分散、重复劳动多；异常发现偏晚；客户通知口径不统一；交接班信息易遗漏 |
|
||||
| **匠厂交付内容** | 全程运单追踪智能体、运输异常预警智能体、客户节点通知草稿；异常待办推送到现有协作工具；关键节点执行记录 |
|
||||
| **人工确认节点** | 对外通知发送前由客服或操作确认；涉及索赔、改配、费用承担的判断由主管确认 |
|
||||
| **上线后变化** | 客户在途咨询响应更快；异常进入待办而非散落在个人记事；班次交接有统一状态摘要 |
|
||||
| **适用边界** | 依赖承运人数据质量与更新频率；极端天气、港口罢工等需结合人工判断与客户沟通策略 |
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂按真实业务流程分步落地，不追求一步「全自动化」：
|
||||
|
||||
1. **需求访谈** — 了解岗位分工、系统现状、痛点优先级与合规要求
|
||||
2. **流程拆解** — 把高频环节拆成「理解 → 执行 → 人工确认 → 记录」可验收步骤
|
||||
3. **样例数据确认** — 用脱敏邮件、单证、对账单等样例校准规则与输出格式
|
||||
4. **智能体开发** — 按场景开发对应智能体，对接 ERP/TMS/邮件/表格等已有工具
|
||||
5. **小范围试运行** — 先选一条航线、一个客户群或一个岗位试点，收集反馈
|
||||
6. **培训上线** — 操作手册、现场培训、确认节点与异常处理约定一并交付
|
||||
7. **持续优化** — 根据日志与业务变化迭代规则、模板和知识库
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- 询价整理、轨迹查询、单证核对、对账标记等**高频、规则相对明确、可复核**的工作
|
||||
- 已有费率表、SOP、单证模板、对账习惯，愿意提供样例数据的企业
|
||||
- 希望在**人工确认前提下**减少重复录入、重复查询、重复汇总
|
||||
- 多系统并存（OMS/TMS/财务/邮件/Excel），需要有人把环节串起来
|
||||
- 希望把老员工经验沉淀为**可查询、可追溯**的智能体能力
|
||||
|
||||
### 不适合
|
||||
|
||||
- 期望「完全不经过人」就对外报价、放货、入账、报关申报
|
||||
- 没有任何样例流程或数据，且不愿意配合梳理业务规则
|
||||
- 核心系统接口、数据权限无法配合，智能体无法读取必要信息
|
||||
- 特种货、重大合规争议、索赔谈判等**必须专家判断**的场景，不宜强行全自动
|
||||
- 仅想要通用聊天机器人，而不愿定义具体业务任务与验收标准
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂物流与货代技能组，当前包含 **123** 个技能仓库。
|
||||
|
||||
@@ -303,3 +638,16 @@
|
||||
- **draft-internal-handover** — 班次与岗位交接文档自动生成
|
||||
- **log-operation-audit** — 操作轨迹与审计日志
|
||||
- **audit-compliance-log** — 合规操作日志审计
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
www.jc2009.com
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
@@ -1,4 +1,182 @@
|
||||
# client-manufacturing
|
||||
# 制造业 AI 智能体解决方案
|
||||
|
||||
本页面面向制造业客户，说明匠厂如何围绕采购、计划、仓储、质检、单证、财务等真实业务流程，开发可落地、可执行、可追溯的 AI 智能体。
|
||||
|
||||
制造企业往往已部署 ERP、WMS、MES 或 Excel 台账，但订单、BOM、库存、排程、质检记录、出口单据仍分散在邮件、微信、扫描件和多个系统界面中。匠厂不替代现有系统，而是让智能体在授权范围内完成提取、核对、生成、提醒与归档，由人工在关键节点把关，全程留痕可追溯。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- **数据分散**：销售订单、采购 PO、入库单、排程表、质检报告、商业发票、装箱单分布在 ERP、WMS、邮箱和共享盘，查询与抄录占用大量时间
|
||||
- **采购比价低效**：多家供应商报价格式不一（邮件正文、Excel、图片扫描），手工填入对比表易漏项，历史报价难检索
|
||||
- **计划与缺料联动慢**：插单、缺料、设备异常后，排程调整与采购催货、生产通知往往靠人工串联，异常发现偏晚
|
||||
- **仓储台账靠手工**：收货登记、出库核对、库位推荐、盘点差异比对重复录入多，账实不符定位慢
|
||||
- **质检与客诉文档重**：IQC/IPQC/OQC 报告、8D、良率分析依赖人工汇总；外观检验人力成本高、标准难统一
|
||||
- **出口单证审核耗时**：商业发票、装箱单、产地证等字段需跨单证比对（品名、数量、金额、唛头、HS 编码），错漏往往在报关前才暴露
|
||||
- **财务月结压力大**：供应商发票三单匹配、应付对账、费用报销录入格式杂乱，差异项散落多张表
|
||||
- **经营信息汇总滞后**：各部门数据需人工拼成日报或月报，管理层难以及时看到缺料、交期、回款等关键信号
|
||||
|
||||
---
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
以下按职能分组列举典型智能体方向。实际项目会按您的物料结构、系统环境和审批流程裁剪或二次开发，不必一次性全部上线。
|
||||
|
||||
### 采购与供应商
|
||||
|
||||
- **供应商报价比对智能体** — 从邮件、Excel、图片报价单提取并标准化字段，生成横向对比表与采购建议草稿
|
||||
- **物料需求计算智能体** — 按生产计划展开 BOM，输出采购清单与缺料提示
|
||||
- **采购单生成智能体** — 结合缺料清单与协议价/历史价生成 PO 草稿
|
||||
- **采购交期跟进智能体** — 追踪 PO 交货进度，逾期自动催货并记录
|
||||
- **供应商质量评分智能体** — 统计准时率、来料合格率，生成供应商排名
|
||||
- **新供应商评估智能体** — 整理资质文件，输出初步评估报告
|
||||
- **原材料价格波动预警智能体** — 监控铜、钢、塑料等大宗价格，超阈值提醒
|
||||
|
||||
### 生产计划
|
||||
|
||||
- **生产排程智能体** — 综合订单、库存、产能、物料约束生成排程建议
|
||||
- **产能负荷分析智能体** — 计算各产线负荷，识别瓶颈工序
|
||||
- **计划异常调整智能体** — 监控插单、缺料、设备异常，推送调整建议并通知相关部门
|
||||
- **缺料清单智能体** — 按排程实时计算缺料，推送紧急补货指令
|
||||
- **产能需求预测智能体** — 基于历史订单规律辅助人力与产线规划
|
||||
- **准时交货分析智能体** — 统计订单 OTIF，识别延误原因并生成改善报告
|
||||
|
||||
### 仓储库存
|
||||
|
||||
- **安全库存预警智能体** — 监控安全库存线，触发缺货预警与采购需求
|
||||
- **库位推荐智能体** — 按货物属性与出入库频次推荐库位
|
||||
- **拣货单生成智能体** — 按生产或出货需求生成拣货单，优化拣货路径
|
||||
- **入库登记智能体** — 识别送货单/入库单，完成收货登记
|
||||
- **出库处理智能体** — 按出货指令生成出库单并更新台账
|
||||
- **物料效期管理智能体** — 追踪临期物料，推送先进先出提醒
|
||||
- **盘点差异核对智能体** — 比对盘点数据与系统库存，生成差异报告
|
||||
|
||||
### 质量检验
|
||||
|
||||
- **外观缺陷视觉检测智能体** — 流水线外观缺陷实时识别（需现场相机与工位配合）
|
||||
- **不良原因分类智能体** — 对不良品自动分类并统计 TOP 缺陷
|
||||
- **质检报告生成智能体** — 自动生成 IQC/IPQC/OQC 报告草稿
|
||||
- **8D 报告起草智能体** — 根据客诉内容生成 8D 模板与纠正措施建议
|
||||
- **量测数据校验智能体** — 读取量测设备数据，超差自动预警
|
||||
- **包装标准检查智能体** — 核对唛头、标签、数量、防护是否符合客户标准
|
||||
- **良率趋势分析智能体** — 分析各产线/班次良率，识别异常波动
|
||||
|
||||
### 出口单证
|
||||
|
||||
- **出口单证校验智能体** — 校验商业发票、装箱单、产地证等完整性与跨单证一致性，输出修改清单
|
||||
- **HS 编码归类智能体** — 根据品名规格推荐 HS 编码并提示合规风险
|
||||
- **商业发票生成智能体** — 按出货信息生成发票草稿（价格、数量、唛头、贸易条款）
|
||||
- **装箱单生成智能体** — 根据出货数据自动生成装箱单
|
||||
- **原产地证填制智能体** — 辅助填写 CO / Form E / Form A 等证书
|
||||
- **合规认证检查智能体** — 检查 CE、RoHS、REACH 等认证状态并推送风险
|
||||
- **单证归档智能体** — 自动归档订单相关文件，建立可检索档案库
|
||||
|
||||
### 财务与经营日报
|
||||
|
||||
- **发票识别与三单匹配智能体** — 识别供应商发票，与 PO、收货单比对后写入系统草稿
|
||||
- **应付对账智能体** — 核对应付与采购订单，识别差异并生成对账报告
|
||||
- **订单成本与毛利分析智能体** — 汇总材料、人工、费用，输出毛利分析报告
|
||||
- **应收应付跟进智能体** — 跟踪回款与付款状态，逾期提醒
|
||||
- **费用报销提取智能体** — 从报销单、收据提取金额、类别、日期
|
||||
- **发票风险识别智能体** — 识别重复提交、金额异常等风险项
|
||||
- **财务月报摘要智能体** — 生成月度收支、应收应付汇总
|
||||
- **经营日报智能体** — 汇总各部门当日关键指标，推送管理层日报
|
||||
- **KPI 看板更新智能体** — 采集各部门 KPI，自动更新可视化看板数据层
|
||||
|
||||
此外，销售接单（询盘回复、订单提取、交期更新）、售后服务、HR 等职能亦有对应能力，可按需组合，见文末能力库附录。
|
||||
|
||||
---
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
建议从**高频、规则清楚、容易验收、有人工复核**的场景切入，验证价值后再扩展：
|
||||
|
||||
1. **供应商报价比对** — 输入多样、整理费时，产出对比表可直接用于审批，不涉及自动下单
|
||||
2. **出口单证一致性校验** — 错漏集中在字段比对，智能体输出修改清单，单证员复核后改单
|
||||
3. **采购交期跟进与催货提醒** — 规则明确，逾期清单便于采购每日处理
|
||||
4. **订单信息从邮件提取录入 ERP** — 减少销售/跟单重复录入 PO 要素
|
||||
5. **经营日报 / 缺料预警汇总** — 将分散表格与系统导出归并为一份管理层可读摘要
|
||||
|
||||
---
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 案例一：某制造企业供应商报价比对与采购建议
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某制造企业，原材料品类多，采购部门需定期向多家供应商询价并提交比价审批 |
|
||||
| **原业务流程** | 采购员发出询价后，陆续收到供应商邮件、微信文件或纸质扫描件；手工将报价填入对比表，核对单价、起订量、交期、付款方式、是否含运费等维度；整理完成后提交采购经理审批，历史报价多靠个人文件夹保存，检索不便 |
|
||||
| **主要问题** | 报价格式不统一，整理费时；比价维度多时容易漏项；历史报价难追溯，新人不熟悉各供应商报价习惯 |
|
||||
| **匠厂交付内容** | 供应商报价比对智能体：从邮件、Excel、图片报价单中提取并标准化字段；按物料生成横向对比表，标注最优项与异常报价；输出采购建议草稿，支持按物料、供应商归档历史报价供检索 |
|
||||
| **人工确认节点** | 最终供应商选择、合同条款和下单动作由采购经理确认；智能体仅提供整理和建议，不自动下单 |
|
||||
| **上线后变化** | 报价比对整理效率提高；采购建议更有据可查；比价规则可沉淀复用，减少对个人经验的依赖 |
|
||||
| **适用边界** | 需客户提供报价样例和比价维度；战略采购、独家物料、非标规格等复杂决策仍需人工判断 |
|
||||
|
||||
### 案例二：某出口型制造企业出口单证校验
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某出口型制造企业，单证部门每日需核对商业发票、装箱单、产地证及客户 PO 之间的一致性，再提交货代或报关 |
|
||||
| **原业务流程** | 业务员提供出货清单，单证员根据 ERP 出货数据手工填写发票与装箱单；逐份核对品名中英文、数量、件数、毛净重、金额、唛头、HS 编码、贸易条款；发现不一致时退回业务部门修改，旺季时多单并行，错漏往往在截关前集中暴露 |
|
||||
| **主要问题** | 跨单证字段多，人工比对易漏项；品名翻译与申报要素不统一；修改记录分散在邮件中，不便复盘 |
|
||||
| **匠厂交付内容** | 出口单证校验智能体：读取商业发票、装箱单、产地证草稿及 PO/出货清单；按预设规则比对关键字段一致性；输出错漏清单与修改建议；校验日志可按订单号检索；配合商业发票、装箱单生成草稿能力，减少重复录入 |
|
||||
| **人工确认节点** | 正式单证发送货代、报关及对外确认由单证员审核后执行；涉及价格、贸易术语变更须业务负责人确认 |
|
||||
| **上线后变化** | 单证复核由「全人工逐行看」转为「智能体先筛异常、人工处理差异项」；截关前因字段不一致导致的返工次数减少 |
|
||||
| **适用边界** | 需客户提供历史单证样例与字段映射规则；特殊贸易方式、监管条件变化时需同步更新规则库 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂采用 **「理解—执行—连接—把关—追溯」** 五层方式，让智能体在可控边界内参与日常工作：
|
||||
|
||||
| 层级 | 职责 | 说明 |
|
||||
|---|---|---|
|
||||
| **AI 负责理解** | 文本、文档、表格、邮件、异常描述 | 读懂业务语境，而非机械匹配关键词 |
|
||||
| **技能负责执行** | Python 技能、OpenClaw、RPA、API | 稳定、可复现地完成提取、生成、比对、提醒 |
|
||||
| **系统负责连接** | ERP、WMS、邮箱、共享盘、货代系统 | 在授权范围内打通数据与操作链路 |
|
||||
| **人工负责把关** | 下单、付款、对外发送单证等 | 高风险动作必须人工确认后放行 |
|
||||
| **日志负责追溯** | 每次执行完整记录 | 便于复盘、审计与问题定位 |
|
||||
|
||||
### 试点流程
|
||||
|
||||
1. **需求访谈** — 了解物料结构、审批链、现有系统与痛点环节
|
||||
2. **流程拆解** — 明确输入、输出、判断规则与异常处理
|
||||
3. **样例数据确认** — 用真实报价单、单证、入库单等样例验证方案
|
||||
4. **智能体开发** — 按确认方案开发并内部测试
|
||||
5. **小范围试运行** — 在采购组、单证组或计划组试用
|
||||
6. **反馈与优化** — 根据使用反馈调整字段映射与规则
|
||||
7. **正式上线与培训** — 编写操作说明，培训业务人员
|
||||
|
||||
试点周期通常为数周，取决于流程复杂度与数据准备情况。建议先跑通一个场景，再向关联环节扩展。
|
||||
|
||||
---
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- 重复、高频、规则相对明确的业务流程（比价、单证核对、交期跟进、日报汇总）
|
||||
- 需要跨 ERP、WMS、邮件、Excel、扫描件处理的任务
|
||||
- 有样例数据和人工复核机制
|
||||
- 愿意从小场景试点，逐步扩展
|
||||
- 希望把老师傅经验沉淀为可复用规则与技能
|
||||
|
||||
### 不适合
|
||||
|
||||
- 完全没有流程文档、没有样例单据可参考
|
||||
- 期望智能体无需人工即可承担采购、计划、单证等岗位的全部判断
|
||||
- 不愿意提供测试账号、样例报价或单证资料
|
||||
- 高风险动作（下单、付款、报关放行）不愿设置人工确认
|
||||
- 期望一次交付后长期不维护、不迭代
|
||||
|
||||
---
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂制造业技能组，当前包含 **68** 个技能仓库。
|
||||
|
||||
@@ -11,16 +189,16 @@
|
||||
| `analyze-turnover-risk` | 基于员工行为数据识别离职风险，提前预警关键岗位人员流失 |
|
||||
| `analyze-yield-trend` | 分析各产线/班次良率趋势，自动识别异常波动并推送改善建议 |
|
||||
| `answer-hr-policy` | 自动回答员工关于考勤/薪资/假期/福利的高频问题 |
|
||||
| `answer-product-faq` | 自动回答产品规格/认证/包装/MOQ 等高频问题，替代人工客服 |
|
||||
| `archive-document-record` | 自动归档单证文件，建立可检索的订单文件库，替代手工归档 |
|
||||
| `answer-product-faq` | 自动回答产品规格/认证/包装/MOQ 等高频问题，辅助客服处理重复咨询 |
|
||||
| `archive-document-record` | 自动归档单证文件，建立可检索的订单文件库，辅助完成文件归档整理 |
|
||||
| `calculate-attendance` | 自动汇总考勤数据，识别异常出勤，生成月度考勤报表 |
|
||||
| `calculate-capacity-load` | 自动计算各产线产能负荷，识别瓶颈工序并推送调整建议 |
|
||||
| `calculate-material-demand` | 根据生产计划展开 BOM，自动计算物料需求，输出采购清单 |
|
||||
| `check-inventory-accuracy` | 定期盘点数据与系统库存比对，自动识别差异并生成盘点报告 |
|
||||
| `check-packaging-standard` | 识别包装规格是否符合客户标准（唛头/标签/数量/防护），替代包装检验员 |
|
||||
| `check-packaging-standard` | 识别包装规格是否符合客户标准（唛头/标签/数量/防护），辅助包装检验识别异常 |
|
||||
| `classify-defect-cause` | 对不良品自动分类（外观/尺寸/功能/包装），统计 TOP 缺陷 |
|
||||
| `classify-hs-code` | 根据货物描述自动推荐 HS 编码，附合规风险提示 |
|
||||
| `compare-supplier-price` | 多供应商报价自动比对，生成最优采购建议，替代人工比价 |
|
||||
| `compare-supplier-price` | 多供应商报价自动比对，生成最优采购建议，辅助采购人员完成比价整理 |
|
||||
| `convert-document-format` | 自动将 PDF/图片/Excel 单据转换为标准数据格式，写入系统 |
|
||||
| `detect-compliance-risk` | 自动检查产品 CE/RoHS/REACH 认证合规状态，推送风险预警 |
|
||||
| `detect-invoice-fraud` | 识别异常发票（重复提交/金额异常/供应商异常），生成风险预警 |
|
||||
@@ -32,7 +210,7 @@
|
||||
| `extract-table-from-image` | 识别图片/扫描件中的表格数据，转换为结构化格式录入系统 |
|
||||
| `follow-up-payment` | 自动跟进客户付款状态，生成催款提醒，记录回款时间线 |
|
||||
| `forecast-production-demand` | 基于历史订单规律预测未来产能需求，辅助产线人力资源规划 |
|
||||
| `generate-certificate-origin` | 自动填写原产地证书（CO/Form E/Form A），替代单证员 |
|
||||
| `generate-certificate-origin` | 自动填写原产地证书（CO/Form E/Form A），辅助单证员完成填制草稿 |
|
||||
| `generate-commercial-invoice` | 自动生成商业发票，含价格/数量/唛头/贸易条款 |
|
||||
| `generate-cost-report` | 自动汇总订单成本（材料/人工/费用），生成毛利分析报告 |
|
||||
| `generate-daily-summary` | 自动汇总各部门当日数据，生成管理层日报推送 |
|
||||
@@ -40,26 +218,26 @@
|
||||
| `generate-labor-contract` | 根据岗位信息自动生成劳动合同草稿，含关键条款校验 |
|
||||
| `generate-material-shortage` | 根据排程实时计算缺料清单，推送采购紧急补货指令 |
|
||||
| `generate-order-confirmation` | 自动生成订单确认书，核对客户 PO 关键信息后发送 |
|
||||
| `generate-packing-list` | 根据出货信息自动生成装箱单，替代手工制单 |
|
||||
| `generate-packing-list` | 根据出货信息自动生成装箱单，辅助生成制单草稿 |
|
||||
| `generate-picking-list` | 根据生产/出货需求自动生成拣货单，优化拣货路径 |
|
||||
| `generate-proforma-invoice` | 根据客户确认信息自动生成形式发票（PI），替代手工制单 |
|
||||
| `generate-proforma-invoice` | 根据客户确认信息自动生成形式发票（PI），辅助生成制单草稿 |
|
||||
| `generate-purchase-order` | 根据缺料清单和供应商价格自动生成采购单 |
|
||||
| `generate-qc-report` | 自动生成质检报告（IQC/IPQC/OQC），含不良率、图片证据、结论 |
|
||||
| `generate-quotation` | 读取 BOM 和成本自动生成报价单，含利润率控制和 MOQ 建议 |
|
||||
| `handle-after-sale` | 识别售后诉求（退换货/补件/索赔），自动分类处理并回复 |
|
||||
| `inspect-defect-vision` | 视觉 AI 实时识别流水线外观缺陷，替代人工质检员 |
|
||||
| `inspect-defect-vision` | 视觉 AI 实时识别流水线外观缺陷，辅助质检人员识别异常 |
|
||||
| `manage-material-expiry` | 追踪物料有效期，临期自动预警，推送先进先出执行提醒 |
|
||||
| `monitor-customer-complaint` | 监控客户邮件/聊天中的投诉信号，自动分级并触发处理流程 |
|
||||
| `monitor-kpi-dashboard` | 实时采集各部门 KPI 数据，自动更新可视化看板，替代数据统计员 |
|
||||
| `onboard-new-employee` | 新员工入职培训智能问答 + 考核，替代 HR 培训专员 |
|
||||
| `monitor-kpi-dashboard` | 实时采集各部门 KPI 数据，自动更新可视化看板，辅助统计人员整理数据 |
|
||||
| `onboard-new-employee` | 新员工入职培训智能问答 + 考核，辅助 HR 完成培训问答与资料整理 |
|
||||
| `process-invoice-entry` | 自动识别供应商发票，完成三单匹配（PO/收货/发票），写入系统 |
|
||||
| `reconcile-accounts-payable` | 自动核对应付账款与采购订单，识别差异并生成对账报告 |
|
||||
| `record-inbound-stock` | 自动识别入库单/送货单，完成收货登记，替代仓管手工录入 |
|
||||
| `record-inbound-stock` | 自动识别入库单/送货单，完成收货登记，辅助仓管完成入库登记 |
|
||||
| `record-outbound-stock` | 根据出货指令自动生成出库单，更新库存台账 |
|
||||
| `reply-inquiry` | 自动回复客户询盘，识别产品/数量/交期，生成专业回复，7×24 小时 |
|
||||
| `schedule-interview` | 自动协调面试时间，发送邀约通知，跟进面试结果记录 |
|
||||
| `schedule-production-plan` | 综合订单/库存/产能/物料自动生成生产排程，替代计划员 |
|
||||
| `screen-resume` | 自动筛选简历，按岗位要求评分排序，替代 HR 初筛工作 |
|
||||
| `schedule-production-plan` | 综合订单/库存/产能/物料自动生成生产排程，辅助计划员生成排程建议 |
|
||||
| `screen-resume` | 自动筛选简历，按岗位要求评分排序，辅助 HR 完成简历初筛 |
|
||||
| `screen-supplier-quality` | 自动统计供应商交货准时率/来料合格率，生成评分排名 |
|
||||
| `summarize-customer-history` | 汇总客户历史订单/投诉/付款记录，生成客户画像供业务参考 |
|
||||
| `sync-erp-data` | 跨系统数据同步（ERP/WMS/CRM），消除人工重复录入 |
|
||||
@@ -169,3 +347,21 @@
|
||||
- **calculate-attendance** — 自动汇总考勤数据，生成月度考勤报表
|
||||
- **generate-labor-contract** — 根据岗位信息自动生成劳动合同草稿
|
||||
- **analyze-turnover-risk** — 基于员工行为数据识别离职风险
|
||||
|
||||
---
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
如果您不确定制造环节中哪个流程适合做智能体，可以先从供应商比价、单证核对、交期跟进或经营日报等高频场景开始评估。欢迎联系我们，做一次免费的流程适配沟通。
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
@@ -1,4 +1,216 @@
|
||||
# client-marketing
|
||||
# 市场营销与内容分发 AI 智能体解决方案
|
||||
|
||||
本页面面向市场营销与内容分发职能客户，说明匠厂如何围绕真实业务流程，开发可落地、可执行、可追溯的 AI 智能体。
|
||||
|
||||
---
|
||||
|
||||
## 1. 这个行业常见的问题
|
||||
|
||||
- 同一篇内容需适配公众号、头条、搜狐、知乎、百家号等多个平台，排版与字段要求各不相同
|
||||
- 短视频在抖音、快手、视频号等平台重复上传、填写标题标签，操作琐碎
|
||||
- 发布完成后，链接、状态、发布时间分散在表格或聊天记录里，复盘和向客户汇报时要重新整理
|
||||
- 内容团队大量时间花在登录后台、复制粘贴、调整封面比例，而非选题与改稿
|
||||
- B2B 线索分散在 1688、展会名单、表单等渠道，联系方式整理与去重依赖人工
|
||||
- 各平台后台界面更新频繁，新人上手慢，发布规范靠个人经验传递
|
||||
- 多账号、多客户并行服务时，难以统一查看「今天发了什么、发成功没有」
|
||||
- 敏感内容、品牌口径、原创声明等关键节点若缺少审核，存在合规风险
|
||||
|
||||
---
|
||||
|
||||
## 2. 匠厂可以落地的智能体
|
||||
|
||||
### 多平台图文发布
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
同一篇定稿需按各平台标题字数、段落格式、封面比例、标签规则分别调整并发布；人工逐平台操作耗时长、易漏项。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 多平台文章发布智能体（组合 `sohu-publisher`、`toutiao-publisher`、`zhihu-publisher` 等图文发布技能）
|
||||
- 公众号发布智能体（`gongzhonghao-publisher`）
|
||||
- 垂直社区发布智能体（如 `juejin-publisher`、`csdn-publisher`、`baijiahao-publisher` 等）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
各平台待发布/已发布状态清单；发布执行日志（账号、时间、平台、结果）；格式差异与缺失项提示。
|
||||
|
||||
### 短视频发布
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
短视频需在抖音、快手、视频号等平台分别上传、填写描述与话题，重复劳动多；多账号运营时进度难统一跟踪。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 短视频多平台发布智能体（组合 `douyin-publisher`、`kuaishou-publisher`、`shipinhao-publisher`）
|
||||
- 单平台短视频发布智能体（按客户主阵地择一试点）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
各平台上传与发布状态；视频标题、描述、话题字段草稿；失败重试与异常项清单。
|
||||
|
||||
### 线索采集
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
B2B 营销线索来自 1688 店铺、行业目录等渠道，联系方式提取、去重、入库依赖人工复制粘贴。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 1688 联系方式采集智能体（`1688-scrape-contacts`）
|
||||
- 线索整理与去重智能体（按客户 CRM 字段规则归一化输出）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
结构化线索表（公司、联系人、电话、来源页等）；重复项标记；采集执行日志。
|
||||
|
||||
### 发布记录整理
|
||||
|
||||
**能解决什么问题**
|
||||
|
||||
多平台发布完成后，链接、阅读量截图、发布状态需手工填入共享表格；周报、客户汇报时再二次汇总，容易遗漏或版本不一致。
|
||||
|
||||
**可落地智能体**
|
||||
|
||||
- 内容发布记录整理智能体（汇总各平台链接、状态、时间，对接客户台账模板）
|
||||
- 发布日志检索智能体（按客户、账号、日期、平台筛选历史发布）
|
||||
|
||||
**典型输出结果**
|
||||
|
||||
统一发布台账（平台、链接、状态、时间）；待补录项清单；可导出的周报/客户汇报草稿。
|
||||
|
||||
---
|
||||
|
||||
## 3. 推荐优先试点场景
|
||||
|
||||
### 场景 1：多平台文章发布
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
规则相对明确（标题、正文、封面、标签）；痛点集中、验收直观；可先选 2–3 个主平台试点，再扩展。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
各平台账号授权方式；历史发布样例与排版规范；封面尺寸、标签、原创声明等要求说明。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
按平台格式排版后的发布动作或待审核草稿；各平台发布状态；执行日志。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
正文、配图、敏感表述发布前由编辑或运营确认；高风险账号与涉政涉敏内容不自动发布。
|
||||
|
||||
### 场景 2：公众号发布
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
许多团队以公众号为主阵地，流程相对固定；可先跑通单平台再复制到其他渠道。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
公众号后台授权；历史推文样例；封面、摘要、原创与转载规则。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
排版后的图文草稿或发布结果；发布链接与时间记录。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
群发前由运营审核；菜单、留言、付费等高级设置仍由人工操作。
|
||||
|
||||
### 场景 3：短视频发布
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
上传与填表动作重复度高；可先从一个主平台（如视频号或抖音）验证，再扩展。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
平台账号授权；视频文件命名与描述规范；话题、@、挂载链接等规则。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
上传与发布状态；各字段填写结果；失败项与重试建议。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
视频内容、描述文案、挂载商品或链接发布前由运营确认。
|
||||
|
||||
### 场景 4：发布记录整理
|
||||
|
||||
**为什么适合先做**
|
||||
|
||||
不涉及各平台界面复杂适配；可与发布智能体配套上线，也可单独从「补录历史发布」切入。
|
||||
|
||||
**需要客户提供什么资料**
|
||||
|
||||
现有发布台账模板；各平台后台导出样例或历史链接清单；周报/客户汇报格式。
|
||||
|
||||
**输出什么结果**
|
||||
|
||||
统一发布记录表；缺失链接或状态异常项；按客户/账号/日期的汇总视图。
|
||||
|
||||
**人工确认点在哪里**
|
||||
|
||||
对外报送的客户汇报、数据口径由运营或客户经理确认；智能体不擅自修改已归档数据。
|
||||
|
||||
---
|
||||
|
||||
## 4. 项目案例
|
||||
|
||||
### 项目案例 1：某内容运营团队多平台文章发布自动化
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| **客户类型** | 某内容运营团队（客户名称已匿名处理），为企业客户提供公众号、头条号、搜狐号、知乎等多平台内容分发服务 |
|
||||
| **原业务流程** | 编辑在 Word 或飞书完成定稿后，运营按各平台要求调整标题字数、段落格式、封面比例和标签；逐平台登录后台上传配图、粘贴正文、设置原创声明；发布后在共享表格中手工记录链接、发布时间和阅读量截图，周报时再汇总 |
|
||||
| **主要问题** | 同一篇文章需重复排版发布，操作琐碎；各平台后台界面不同，新人上手慢；发布记录分散，复盘和向客户汇报时需重新整理 |
|
||||
| **匠厂交付内容** | 多平台文章发布智能体：按各平台格式要求自动排版并执行发布；内容发布记录整理智能体：汇总各平台链接、发布状态和时间；配套发布日志，支持按客户、账号、日期检索 |
|
||||
| **人工确认节点** | 文章发布前由编辑或运营审核确认正文与配图；涉政敏感、客户品牌口径及高风险账号不自动发布 |
|
||||
| **上线后变化** | 重复发布操作减少；发布记录整理更及时；内容团队可将更多时间用于选题、改稿和转化跟进 |
|
||||
| **适用边界** | 需客户提供各平台账号授权和发布规范；部分平台界面或审核规则变更时需同步维护适配 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 落地方式
|
||||
|
||||
匠厂采用 **“理解—执行—连接—把关—追溯”** 的方式，让内容分发智能体在可控边界内参与日常工作：
|
||||
|
||||
1. **需求访谈** — 了解内容生产流程、主阵地平台、账号矩阵与客户汇报要求
|
||||
2. **流程拆解** — 明确输入（定稿、配图、标签规则）、输出（发布结果、台账、日志）与各平台差异项
|
||||
3. **样例确认** — 用历史发布样例验证排版规则、字段映射与记录模板是否可行
|
||||
4. **智能体开发** — 组合或定制发布技能，内部测试并保留执行日志
|
||||
5. **小范围试运行** — 先选 1–2 个平台或 1 组账号试用，对照人工发布结果验收
|
||||
6. **培训上线** — 编写操作说明，培训编辑与运营，明确发布前审核节点
|
||||
7. **持续优化** — 根据平台改版、新增渠道、客户模板变化迭代规则
|
||||
|
||||
---
|
||||
|
||||
## 6. 适合与不适合
|
||||
|
||||
### 适合
|
||||
|
||||
- 多平台、多账号重复发布与记录整理工作量大
|
||||
- 有明确的发布规范、历史样例和台账模板可供配置
|
||||
- 愿意在正式发布、对外汇报等节点保留人工确认
|
||||
- 希望把各平台排版规则与发布日志沉淀为可复用能力
|
||||
- 愿意从单平台或 2–3 个主渠道试点，再逐步扩展
|
||||
|
||||
### 不适合
|
||||
|
||||
- 完全没有发布规范或历史样例可参考
|
||||
- 期望智能体无需人工即可承担全部内容审核与品牌把关责任
|
||||
- 不愿提供平台授权或测试账号
|
||||
- 高风险内容（涉政涉敏、医疗金融等）要求全自动发布且无人工审核
|
||||
- 内容形态完全非标、每篇排版逻辑无法归纳规则
|
||||
|
||||
---
|
||||
|
||||
## 7. 能力库附录
|
||||
|
||||
以下为匠厂在该方向沉淀的能力库，实际项目会根据客户业务流程重新组合、裁剪或二次开发，并非固定套餐。
|
||||
|
||||
匠厂市场营销技能组，当前包含 **16** 个技能仓库。
|
||||
|
||||
@@ -50,3 +262,19 @@
|
||||
### 种草社区
|
||||
|
||||
- **xiaohongshu-publisher** — 小红书批量发布
|
||||
|
||||
---
|
||||
|
||||
## 8. 联系我们
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回首页](../README.md)
|
||||
|
||||
139
quick-start.md
Normal file
139
quick-start.md
Normal file
@@ -0,0 +1,139 @@
|
||||
# AI 智能体试点启动指南
|
||||
|
||||
本页面帮助您在阅读方案与案例后，判断自己的业务流程是否适合先做一个 AI 智能体试点。匠厂建议从**小场景、可复核、可验收**的流程入手，验证价值后再逐步扩展，而不是一开始就建设「全公司大平台」。
|
||||
|
||||
---
|
||||
|
||||
## 1. 什么样的流程适合先做
|
||||
|
||||
适合作为首个试点的流程，通常具备以下特征：
|
||||
|
||||
- **高频重复**：每天都在做，占用一线员工大量时间
|
||||
- **规则相对明确**：输入、判断条件、输出格式可以描述清楚
|
||||
- **输入输出清楚**：有明确的「拿什么资料、产出什么结果」
|
||||
- **有样例数据**：能提供历史邮件、表格、账单、单据等真实样例（可脱敏）
|
||||
- **结果可以人工复核**：智能体产出草稿或清单，由业务人员确认后再执行
|
||||
- **不直接涉及高风险决策**：如自动付款、自动对外报价、自动报关放行等应设人工确认
|
||||
- **能在 2–6 周内小范围验证**：范围可控，便于快速看到是否值得继续投入
|
||||
|
||||
---
|
||||
|
||||
## 2. 不建议一开始就做什么
|
||||
|
||||
以下情况不适合作为首个试点，建议先梳理流程或缩小范围：
|
||||
|
||||
- **全公司级大平台**：一次覆盖所有部门、所有系统
|
||||
- **完全依赖智能体做最终判断**：无人工确认、无留痕、无回退
|
||||
- **没有流程和样例数据**：无法描述「现在人工怎么做」
|
||||
- **高风险全自动动作**：自动付款、自动下单、自动报关申报、未经审核即对客户发送消息
|
||||
- **规则经常变化且无人负责维护**：今天一套明天一套，没有文档化规则
|
||||
- **期望试点一次解决所有痛点**：容易导致范围失控、验收困难
|
||||
|
||||
---
|
||||
|
||||
## 3. 推荐的首批试点场景
|
||||
|
||||
| 场景 | 适合客户 | 输入资料 | 输出结果 | 风险控制 |
|
||||
|---|---|---|---|---|
|
||||
| 批量查轨迹与异常提醒 | 物流 / 货代 / 跨境 | 运单号、渠道账号、异常规则 | 轨迹汇总、异常清单 | 对外通知前人工确认 |
|
||||
| 询价整理与报价草稿 | 货代 / 制造 / 贸易 | 询价邮件、报价模板、价格规则 | 结构化询价单、报价草稿 | 报价发送前人工确认 |
|
||||
| 对账差异标记 | 财务 / 物流 / 电商 | 账单、内部明细、对账规则 | 差异清单、归一化表格 | 调账 / 付款人工确认 |
|
||||
| 企业知识库问答 | 制造 / 教育 / HR / 内部管理 | SOP、制度、操作手册 | 带出处答案、未命中问题 | 敏感问题转人工 |
|
||||
| 商品资料整理与 Listing 草稿 | 电商 | 商品资料、历史 Listing、平台规则 | 标题 / 卖点 / 属性草稿 | 发布前运营确认 |
|
||||
| 多平台内容发布 | 营销 / 代运营 | 定稿文章、平台账号、发布规范 | 发布状态、链接记录 | 发布前人工审核 |
|
||||
|
||||
更多可参考：[匠厂 AI 智能体项目案例库](./cases/README.md)
|
||||
|
||||
---
|
||||
|
||||
## 4. 客户需要准备什么资料
|
||||
|
||||
试点启动前，建议尽量准备以下材料（不必一次齐全，可访谈后逐步补充）：
|
||||
|
||||
| 类型 | 说明 | 示例 |
|
||||
|---|---|---|
|
||||
| **流程说明** | 当前人工如何处理，谁做、何时做、上下游是什么 | 流程图、SOP、口头说明整理稿 |
|
||||
| **样例数据** | 真实业务样例，可脱敏 | 询价邮件、对账单、运单清单、简历、商品资料 |
|
||||
| **系统账号或导出文件** | 若需查询或录入，说明访问方式 | 测试账号、Excel 导出、截图说明 |
|
||||
| **业务规则** | 判断条件、字段映射、异常定义 | 运价表、对账规则、筛选标准、违禁词清单 |
|
||||
| **输出模板** | 希望智能体产出的格式 | 报价单模板、对账表、汇总报表 |
|
||||
| **人工确认人** | 谁审核、谁放行 | 销售、财务、运营、HR 等岗位 |
|
||||
| **不允许自动执行的边界** | 明确哪些动作绝不能自动做 | 不自动付款、不自动对外报价、不自动改价 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 试点实施流程
|
||||
|
||||
匠厂典型试点按以下 7 步推进：
|
||||
|
||||
1. **需求访谈** — 了解业务流程、痛点、现有系统与人员分工
|
||||
2. **流程拆解** — 明确输入、输出、判断规则、异常处理与人工确认节点
|
||||
3. **样例数据确认** — 用真实样例验证方案可行性，补齐规则缺口
|
||||
4. **方案与边界确认** — 书面确认试点范围、不自动执行项、验收标准
|
||||
5. **智能体开发** — 按确认方案开发，内部测试与日志验证
|
||||
6. **小范围试运行** — 在 1–2 个岗位或班组试用，收集反馈
|
||||
7. **复盘与扩展建议** — 评估效果，决定是否扩展场景或优化规则
|
||||
|
||||
试点周期通常为 **2–6 周**，具体取决于流程复杂度与资料准备情况。
|
||||
|
||||
---
|
||||
|
||||
## 6. 试点验收看什么
|
||||
|
||||
试点是否值得继续，可从以下维度评估（不追求虚假量化承诺）：
|
||||
|
||||
- **是否减少重复整理 / 查询 / 录入**：一线员工主观感受与流程观察相结合
|
||||
- **输出结果是否可被业务人员使用**：草稿质量是否达到「小改可用」，而非推倒重来
|
||||
- **异常是否可追溯**：执行日志能否回答「做了什么、何时、结果如何」
|
||||
- **人工确认节点是否有效**：高风险动作是否确实经过人工把关
|
||||
- **是否具备继续扩展价值**：规则可否沉淀、能否复制到相邻流程
|
||||
|
||||
---
|
||||
|
||||
## 7. 常见问题
|
||||
|
||||
**没有 API 能不能做？**
|
||||
|
||||
可以。许多企业系统未开放 API，匠厂可通过 RPA、网页自动化、文件导入导出等方式，在授权范围内完成对接。是否可行需结合具体系统评估。
|
||||
|
||||
**可以先不接系统，只处理 Excel 吗？**
|
||||
|
||||
可以。不少试点从 Excel / 邮件 / PDF 整理入手，验证价值后再考虑与 ERP、OMS 等系统对接。
|
||||
|
||||
**会不会影响现有系统？**
|
||||
|
||||
智能体在授权范围内操作，不修改系统底层结构与权限体系。建议先用测试环境或沙箱账号验证；高风险动作设置人工确认。
|
||||
|
||||
**数据安全怎么处理？**
|
||||
|
||||
项目数据仅在客户授权范围内使用；可按需部署在内网或私有环境。具体安全要求可在需求阶段书面约定。
|
||||
|
||||
**试点失败怎么办？**
|
||||
|
||||
试点本身就是为了降低决策风险。若效果不达预期，可复盘是规则不清、样例不足还是场景不合适，调整范围或暂停扩展，已交付的文档与规则仍可保留供内部参考。
|
||||
|
||||
**能不能先做一个流程，不做平台？**
|
||||
|
||||
可以，而且我们推荐这样做。先跑通一个高频、可复核的小场景，再考虑是否扩展为更多技能或部门共用。
|
||||
|
||||
---
|
||||
|
||||
## 8. 下一步
|
||||
|
||||
如果您不确定哪个流程适合试点，可以先准备 **3 份样例数据**和**当前人工处理流程**说明，匠厂可以协助做一次流程适配评估。
|
||||
|
||||
欢迎联系我们沟通具体场景。
|
||||
|
||||
---
|
||||
|
||||
深圳匠厂科技有限公司
|
||||
Artisan Factory
|
||||
|
||||
企业 AI 落地专家
|
||||
咨询 · 产品 · 实施 · 培训 · 运营
|
||||
|
||||
深圳市宝安区锦驰商务中心 C 座 5 层
|
||||
陈德炼 · 18925203701
|
||||
[www.jc2009.com](https://www.jc2009.com)
|
||||
|
||||
[返回首页](./README.md)
|
||||
Reference in New Issue
Block a user