AI PC发布以来被问得最多的一个问题就是本地跑大模型到底是不是跑分好看、实用拉胯如果你只拿它开浏览器、写文档、看视频答案可能确实如此但如果换一个场景——把一台AI笔记本当作业务工作流的开发与运行平台结论就会完全不同。这篇文章要记录的是围绕一条“周志催收工作流”的搭建过程。催收这个词听起来传统但在持牌金融机构的贷后管理里它恰恰是数据敏感、流程复杂、人工密集的典型场景。客户分群、触达策略、催记质检、报表生成每一个环节都有大量重复劳动。而把这一整条链路搬上一台华硕弘道AI笔记本让它用本地大模型完成部分判断和质检是我认为AI PC目前最值得落地的方向之一。为什么强调“本地”因为催收业务涉及客户姓名、手机号、欠款金额和沟通记录这些数据对隐私合规的要求极高不能随便送到外部大模型API。用AI笔记本部署7B级别的开源模型配合工作流脚本既能用上模型能力又能守住数据边界。这篇文章会从业务拆分、环境准备、核心代码、运行验证到常见问题完整过一遍。如果你想把手边的AI笔记本从“影音本”变成“业务自动化平台”这篇可以作为起点。1. 为什么用AI笔记本搭“周志催收工作流”先说清楚一个判断AI笔记本适合做工作流不是因为它的算力能打而是因为它提供了一个“数据不出设备”的本地闭环。这一点在贷后管理场景里非常关键。传统催收作业流程一线催收员每天打开Excel表格根据逾期天数、联系人状态、历史还款表现人工决定今天先打哪个客户、用什么话术。稍微规范一点的团队会有一个催收系统来做任务分配但到了催记质检环节往往还是靠组长抽听录音抽检率低漏检概率高。报表就更不用说日报、周报、月度复盘大部分靠下班后手工汇总。这些痛点用一套工作流可以拆解成四步名单进入后先做客户分群。逾期90天以上的、30天以上的、失联的、正常可触达的走不同策略。根据分群结果生成触达策略。短信提醒、自动语音、人工外呼、失联修复分别对应不同人群。催记回传后做合规质检。这一步交给本地大模型按预设的合规清单逐条检查话术。每天结束后自动生成报表分群数量、触达率、质检通过率一目了然。这个工作流最核心的收益不是把模型“用起来”了而是把业务里最容易被忽略的红线变成了系统规则。催收合规问题一旦出在真实业务里轻则投诉重则处罚。让模型先做第一道质检再让人工抽查能把风险大幅降低。当然这套方案也有明确边界本地AI笔记本适合做验证、Demo、小型团队落地以及数据敏感度高的场景。如果是日处理百万级数据的核心生产系统还是需要服务器集群。这个后面会详细说。2. 先搞清楚三个概念AI笔记本、AI工作流、端侧模型2.1 AI笔记本到底“AI”在哪AI笔记本通常指带有独立NPU神经网络处理单元、可以本地运行大模型的PC产品。和普通轻薄本的区别可以从三个角度理解算力组成不同。普通笔记本只有CPU和GPUAI PC额外加了NPU专门处理神经网络计算。内存和散热要求更高。本地跑7B模型需要至少16GB内存推理持续占用CPU和NPU散热跟不上会直接降频。使用方式不同。它可以离线完成文本生成、总结、分类、抽取不需要把所有数据传到云端。华硕弘道系列属于面向商用和行业用户的笔记本产品线加上AI能力后它的定位从“能跑办公软件”变成了“能跑本地模型”。这里不讨论具体型号和跑分因为不同批次配置会变化。更稳妥的判断是只要本机可以流畅运行7B级别的量化开源模型下面这套工作流就能跑通。2.2 AI工作流不是Flowable很多后端开发一听到“工作流”就会想到Flowable、Activiti这类重量级工作流引擎。这个理解没有错但“AI工作流”的侧重点不一样。Flowable解决的是流程状态机的管理节点、审批、连线、会签。而AI工作流解决的是“业务的重复动作怎么编排”它可以是基于脚本的也可以是基于可视化工具的核心是把大模型能力嵌入到可能原本靠人工完成的判断环节。在本文的场景里工作流更像是一条“业务流水线”读取名单、分群、生成策略、质检、出报表。它不需要事件驱动引擎也不需要复杂的审批流。先用Python脚本把最小路径跑通比一开始就上Flowable更务实。2.3 端侧模型和云端API怎么选这是搭工作流时绕不开的选择题。整理一下对比对比维度本地端侧模型云端大模型API数据安全数据不出设备合规风险低数据出域需严格脱敏和授权使用成本一次硬件投入电费可忽略按Token计费规模越大成本越高延迟首次加载慢运行后稳定受网络影响高峰期可能波动模型能力7B级别复杂推理有限可调用百B甚至千B级模型运维门槛需要自己管理模型和依赖无需运维开通即用结论很清楚模型能力强弱不是本地部署的第一考量数据边界才是。催收业务涉及敏感个人信息本地模型哪怕判断粗糙一点也比“数据出去”的风险小。实际操作中还可以做混合方案常规分群用规则质检和话术总结用本地模型只有脱敏后的汇总数据才允许进入云端。3. 环境准备在这台AI笔记本上需要装什么3.1 硬件与系统以华硕弘道AI笔记本这一类AI PC为参考建议硬件底线是内存16GB起步32GB更舒服。本地推理7B模型内存不够会直接OOM。硬盘建议512GB以上模型文件加依赖至少预留20GB。操作系统建议Windows 11 WSL2或者直接安装Ubuntu。Windows下跑Ollama也可以但WSL2环境下调试脚本更顺手。注意这里不写死具体CPU型号因为AI PC的CPU平台比较多Intel Core Ultra、AMD Ryzen AI、高通骁龙X都算。即便CPU型号不同只要内存和NPU够用流程逻辑完全一致。3.2 软件栈# 更新系统基础软件 sudo apt update sudo apt upgrade -y # Python 3.10WSL2 或 Linux 环境 python3 --version pip install --upgrade pip # 项目依赖 pip install pandas openai # Ollama 本地模型管理工具 curl -fsSL https://ollama.com/install.sh | sh如果你在Windows原生环境可以直接下载Ollama桌面版然后安装Python。后续所有命令建议统一在WSL2的终端里执行避免Windows和Linux路径混用导致问题。3.3 项目目录规划不要把所有脚本放在一个文件里一个清晰的项目结构对后续维护很重要。推荐的目录结构如下zhouzhi-workflow/ ├── data/ │ ├── raw/ │ │ └── customers.csv │ └── processed/ ├── workflow/ │ ├── customer_segment.py │ ├── quality_check.py │ ├── report.py │ └── main_pipeline.py ├── prompts/ │ ├── strategy_prompt.txt │ └── quality_prompt.txt └── output/data目录放原始数据和中间结果workflow目录放运行代码prompts目录放提示词模板output目录放最终报表。这样分层的意义在于业务规则变更时只改对应模块不会把整个脚本推倒重来。3.4 准备一份脱敏测试数据为了跑通流程先准备一份小样本数据。注意即使是测试数据也不要使用真实客户手机号。可以用固定格式生成假数据customer_id,phone,overdue_days,contact_status C001,13800001111,95,lost C002,13900002222,45,reachable C003,13700003333,15,reachable字段含义customer_id客户编号。phone手机号这里只是演示真实接入时必须先脱敏。overdue_days逾期天数。contact_status联系人状态reachable表示可联系lost表示失联。4. 工作流整体设计先拆业务再写代码4.1 典型催收工作流有哪些环节催收作业看起来是一通电话背后其实是多个环节的协作。整理成流程如下客户名单导入。从催收系统或Excel批量导入当天待处理客户。风险评估与分群。按逾期天数和失联状态把客户分成高风、中风、正常、失联四类。触达策略匹配。不同分群对应不同触达方式。执行触达。短信、自动语音、人工外呼。催记回传。外呼结束后催收员填写沟通结果。合规质检。检查催记和录音话术是否符合业务红线。报表生成。汇总分群统计、触达率、质检结果。前3步适合自动化第4、5步需要人参与第6、7步可以交给系统处理。本文的重点是把1、2、3、6、7跑通。4.2 规则与大模型的职责边界一个常见误区是既然都本地部署大模型了分群、策略、质检全交给大模型。这不是好设计。分群这类判断规则非常稳定逾期90天以上属于高风险这个结论不需要模型来“想”。即使让模型做它也可能因为提示词写得不清楚而输出不一致结果。正确的分工是能用Excel函数和Python规则解决的不调用模型。模型只做两件事策略话术的生成建议、催记文本的合规质检。模型输出之后必须有人工抽查机制兜底。这个设计背后的原因是大模型擅长的是语义理解和生成不擅长精确数值计算。把不擅长的事情交给模型是工作流不稳定的主要来源。4.3 数据流设计每个步骤的输入输出整个工作流的数据流可以拆成五段输入CSV文件每行一个客户。分群后在DataFrame里新增segment列和masked_phone列。策略后新增strategy列记录该客户采用的触达方式。质检后记录质检结果JSON包含是否通过、违规原因。输出汇总统计CSV以及质检日志。数据流清晰之后代码结构自然就清楚了。下面是完整实现。5. 完整实现从本地模型到自动化流水线5.1 启动本地大模型服务首先拉取一个适合中文业务场景的开源模型。这里以Qwen2.5 7B为例它在中文本体和结构化输出方面表现比较稳定。# 在 WSL2 或 Linux 环境下执行 # 启动 Ollama 服务 ollama serve # 新开一个终端拉取模型 ollama pull qwen2.5:7bOllama下载完成后默认监听本机11434端口。它提供了兼容OpenAI协议的接口所以后面Python代码可以直接用openai库访问。验证服务是否正常curl http://localhost:11434/v1/models如果返回了包含模型ID的JSON说明本地模型服务已经就绪。5.2 客户分群模块# 文件路径workflow/customer_segment.py import pandas as pd def mask_phone(phone: str) - str: 对手机号脱敏避免完整明文进入后续环节。 if not phone: return return phone[:3] **** phone[-4:] def apply_segment(df: pd.DataFrame) - pd.DataFrame: 按逾期天数和联系状态做客户分群。 def classify(row): if row[contact_status] lost: return lost_contact if row[overdue_days] 90: return high_risk if row[overdue_days] 30: return medium_risk return normal df[segment] df.apply(classify, axis1) df[masked_phone] df[phone].map(mask_phone) return df这里有两个细节值得说明。第一分群顺序很重要。先判断“失联”再判断“高风险”因为失联客户需要走失联修复流程风险等级反而是次要信息。第二mask_phone在任何环节都要执行。即使是在本地跑模型也要养成“最小暴露”的习惯防止中间日志里出现完整手机号。5.3 催收策略生成策略生成可以很简单用规则映射即可。现实中策略可能涉及还款率、历史联系频率等更多维度但核心逻辑是稳定的映射关系。# 文件路径workflow/strategy.py def gen_strategy(segment: str) - str: 根据分群结果生成触达策略。 mapping { normal: 短信提醒 自动语音, medium_risk: 人工外呼 还款方案沟通, high_risk: 资深催收员跟进 合规面谈, lost_contact: 失联修复先联系紧急联系人合规前提下, } return mapping.get(segment, 人工复核)这个模块虽然简单但它把业务规则收敛到了一个文件里。后续如果策略调整只需要改这一段映射不需要动主流程代码。5.4 催记合规质检这部分是整条工作流的重点。本地模型要做的是检查催记文本是否符合合规要求。# 文件路径workflow/quality_check.py import json from openai import OpenAI # 本地 Ollama 服务兼容 OpenAI 协议 client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, # 本地服务密钥不参与真实鉴权 ) def check_script(script: str) - dict: 检查催收话术是否合规返回结构化结果。 prompt f 你是一名贷后合规质检员。请检查以下催收通话脚本是否合规。 合规要求 1. 不得出现威胁、辱骂、恐吓性词语。 2. 不得向无关第三人透露债务信息。 3. 不得冒充公检法或伪造身份。 4. 沟通时必须说明机构名称和工号。 5. 不得采用骚扰、频繁呼叫等不当催收手段。 通话脚本 {script} 请返回 JSON格式如下 {{pass: true/false, reasons: [违规点1], suggestion: 修改建议}} resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: prompt}], temperature0.1, ) content resp.choices[0].message.content try: return json.loads(content) except json.JSONDecodeError: return { pass: False, reasons: [模型输出不是合法JSON请人工复核], suggestion: content, }这里有一个容易被忽略的点为什么temperature设成0.1因为质检是判断类任务需要输出稳定。如果temperature太高模型可能会把同样一段话术一次判通过、一次判不通过这是质检逻辑不能接受的。另外本地模型输出不一定稳定所以代码里加了JSON解析失败的兜底。实际项目中解析失败的任务应该进入“人工复核队列”而不是直接通过或直接拦截。5.5 报表生成# 文件路径workflow/report.py import pandas as pd def export_summary(result_df: pd.DataFrame, output_path: str) - pd.DataFrame: 按分群统计客户数量导出汇总报表。 summary result_df.groupby(segment).agg( count(customer_id, count) ).reset_index() summary.to_csv(output_path, indexFalse, encodingutf-8-sig) return summary导出CSV时使用utf-8-sig编码是为了避免Excel打开时中文乱码。如果你用的数据量比较大后续可以在这里加上触达率、质检通过率等聚合指标。5.6 主流程编排# 文件路径workflow/main_pipeline.py from pathlib import Path import pandas as pd from customer_segment import apply_segment from strategy import gen_strategy from quality_check import check_script from report import export_summary BASE_DIR Path(__file__).resolve().parents[1] def run(): # 1. 读取客户名单 df pd.read_csv(BASE_DIR / data / raw / customers.csv) # 2. 客户分群 df apply_segment(df) # 3. 生成策略 df[strategy] df[segment].map(gen_strategy) # 4. 对每条客户打印任务信息 for _, row in df.iterrows(): print( f{row[customer_id]} | {row[segment]} | f{row[masked_phone]} | {row[strategy]} ) # 5. 质检示例模拟一段催收脚本 sample_script ( 您好这里是XX消费金融贷后中心工号0826 请问是张先生吗您有一笔账单已逾期45天 今天可以安排还款方案说明。 ) quality check_script(sample_script) print(质检结果, quality) # 6. 生成报表 output_dir BASE_DIR / output output_dir.mkdir(exist_okTrue) summary export_summary(df, output_dir / summary.csv) print(summary) if __name__ __main__: run()主流程的核心思路是“线性编排”。因为步骤之间没有复杂的条件分支用脚本串起来比引入工作流引擎更轻量。真正需要引擎的时候是这个流程变成多人协作、审批、多级任务分配之后。5.7 跑通完整流程确保当前在workflow目录下cd zhouzhi-workflow/workflow python main_pipeline.py如果一切正常你会看到分群结果和质检结果依次输出。6. 运行结果与效果验证6.1 预期输出用前面三行测试数据运行预期输出类似C001 | lost_contact | 138****1111 | 失联修复先联系紧急联系人合规前提下 C002 | medium_risk | 139****2222 | 人工外呼 还款方案沟通 C003 | normal | 137****3333 | 短信提醒 自动语音 质检结果 {pass: True, reasons: [], suggestion: 保持当前沟通口径}同时output目录下会生成一个summary.csv内容类似segment,count lost_contact,1 medium_risk,1 normal,16.2 判断成功的标准工作流跑通不等于效果可用。建议按以下标准逐条验证分群结果是否符合业务预期。失联客户优先高风险客户进入资深催收员队列。手机号是否全程脱敏。如果日志里出现完整手机号说明脱敏没有执行到位。质检结果是否稳定。同一段话术多跑几次结论不应频繁翻转。报表字段是否满足使用方要求。不要等日报发出来才发现少了一列。6.3 性能观察与调优方向7B模型在AI笔记本上推理单次质检出结果可能需要几秒到十几秒具体取决于硬件和模型量化方式。如果觉得慢可以换更小参数的量化版模型例如qwen2.5:7b-q4_K_M。如果换小模型后准确率下降明显说明模型能力是瓶颈优先恢复原参数而不是盲目优化延迟。第一次运行如果失败不要急着改代码。先确认三件事Ollama服务有没有启动、模型有没有拉取成功、Python依赖有没有装齐。7. 常见问题与排查方法问题现象可能原因排查方式解决方案Ollama服务启动失败端口被占用运行curl http://localhost:11434/v1/models释放端口或修改Ollama默认端口调用本地模型超时模型未加载或内存不足查看Ollama运行日志等待模型加载完成或换更小的量化版本openai库报连接错误base_url写错或服务未启动先运行curl再检查base_url确认base_url为http://localhost:11434/v1Python导入模块失败当前目录不是workflow运行pwd查看当前目录进入workflow目录后重新运行CSV中文乱码编码未指定用文本编辑器打开CSV检查导出时使用encodingutf-8-sig质检结果多次不一致temperature设置过高检查模型调用参数把temperature降到0.1左右质量管理要求看到完整手机号脱敏策略过于严格与业务方确认展示范围采用前三后四脱敏或分级查看权限8. 最佳实践与工程建议8.1 数据合规是上限整个工作流的运行基础是数据合规。必须明确几件事数据来源是否有用户授权员工访问范围是否最小化日志是否完整可审计模型是否全程本地运行。如果这些回答不清楚不要急着上线。在代码层面所有手机号、身份证号等敏感字段在打印前必须脱敏。提示词模板中不要出现完整姓名和电话号码这是底线。8.2 规则优先模型兜底能用规则实现的需求不要为了“AI化”而引入模型。分群用规则策略映射用规则模型只负责它擅长的语义理解和生成。这样的好处是系统行为可预测、调试方便、故障影响面小。8.3 模型与依赖版本要固定本地部署的模型版本必须固定。今天用qwen2.5:7b明天拉一个更新版本可能质检标准就变了。Python依赖也一样建议使用requirements.txt锁定版本。pip freeze requirements.txt8.4 结果必须可审计每一次质检都应该记录输入话术、模型输出、处理时间、处理版本。不要把质检结果直接当成最终结论至少设置一个“人工复核待办”。这一点对催收业务尤其重要因为机器判断出错后需要能够追溯。8.5 何时从笔记本迁移到服务器华硕弘道AI笔记本适合以下场景单团队验证、小型业务闭环、出差演示、数据合规要求极高且需要物理隔离环境。它不适合日处理量极大的场景。当出现以下信号建议迁移到GPU服务器或容器化平台每天需要质检的催记超过几千条单机推理排队明显。需要多人同时访问工作流服务。需要模型服务高可用不能因为笔记本休眠而中断。迁移时代码结构基本不用变只要把模型服务端点从localhost换成服务器地址即可。这正体现了“先把最小路径跑通再考虑规模化”的价值。9. 总结与下一步实践建议这篇内容真正讲清楚了三件事第一AI笔记本的落地价值不在跑分而在于把数据、模型和业务流程放在同一个可信的本地环境里。对催收这类数据敏感业务这个特性比什么都重要。第二工作流不是越复杂越好。先用规则把稳定场景兜住再用本地大模型做语义判断最后用人工复核兜底这个顺序能避免大部分踩坑。第三一套完整的工作流需要业务拆解能力而不是代码能力。写分群、策略、质检脚本只需要半天但想清楚谁来做、谁来看、哪些数据必须脱敏、模型判断错了谁能发现才是真正花时间的地方。下一步建议很直接不要急着买更贵的硬件也不要急着接入云端大模型API。把手头最重复的一张Excel表拿出来按本文“分群 策略 质检 报表”的顺序先用脚本跑通一个最小闭环。跑通之后你自然会知道瓶颈在模型能力、 AI笔记本本地跑通催收工作流：端侧模型与数据合规实战
AI PC发布以来被问得最多的一个问题就是本地跑大模型到底是不是跑分好看、实用拉胯如果你只拿它开浏览器、写文档、看视频答案可能确实如此但如果换一个场景——把一台AI笔记本当作业务工作流的开发与运行平台结论就会完全不同。这篇文章要记录的是围绕一条“周志催收工作流”的搭建过程。催收这个词听起来传统但在持牌金融机构的贷后管理里它恰恰是数据敏感、流程复杂、人工密集的典型场景。客户分群、触达策略、催记质检、报表生成每一个环节都有大量重复劳动。而把这一整条链路搬上一台华硕弘道AI笔记本让它用本地大模型完成部分判断和质检是我认为AI PC目前最值得落地的方向之一。为什么强调“本地”因为催收业务涉及客户姓名、手机号、欠款金额和沟通记录这些数据对隐私合规的要求极高不能随便送到外部大模型API。用AI笔记本部署7B级别的开源模型配合工作流脚本既能用上模型能力又能守住数据边界。这篇文章会从业务拆分、环境准备、核心代码、运行验证到常见问题完整过一遍。如果你想把手边的AI笔记本从“影音本”变成“业务自动化平台”这篇可以作为起点。1. 为什么用AI笔记本搭“周志催收工作流”先说清楚一个判断AI笔记本适合做工作流不是因为它的算力能打而是因为它提供了一个“数据不出设备”的本地闭环。这一点在贷后管理场景里非常关键。传统催收作业流程一线催收员每天打开Excel表格根据逾期天数、联系人状态、历史还款表现人工决定今天先打哪个客户、用什么话术。稍微规范一点的团队会有一个催收系统来做任务分配但到了催记质检环节往往还是靠组长抽听录音抽检率低漏检概率高。报表就更不用说日报、周报、月度复盘大部分靠下班后手工汇总。这些痛点用一套工作流可以拆解成四步名单进入后先做客户分群。逾期90天以上的、30天以上的、失联的、正常可触达的走不同策略。根据分群结果生成触达策略。短信提醒、自动语音、人工外呼、失联修复分别对应不同人群。催记回传后做合规质检。这一步交给本地大模型按预设的合规清单逐条检查话术。每天结束后自动生成报表分群数量、触达率、质检通过率一目了然。这个工作流最核心的收益不是把模型“用起来”了而是把业务里最容易被忽略的红线变成了系统规则。催收合规问题一旦出在真实业务里轻则投诉重则处罚。让模型先做第一道质检再让人工抽查能把风险大幅降低。当然这套方案也有明确边界本地AI笔记本适合做验证、Demo、小型团队落地以及数据敏感度高的场景。如果是日处理百万级数据的核心生产系统还是需要服务器集群。这个后面会详细说。2. 先搞清楚三个概念AI笔记本、AI工作流、端侧模型2.1 AI笔记本到底“AI”在哪AI笔记本通常指带有独立NPU神经网络处理单元、可以本地运行大模型的PC产品。和普通轻薄本的区别可以从三个角度理解算力组成不同。普通笔记本只有CPU和GPUAI PC额外加了NPU专门处理神经网络计算。内存和散热要求更高。本地跑7B模型需要至少16GB内存推理持续占用CPU和NPU散热跟不上会直接降频。使用方式不同。它可以离线完成文本生成、总结、分类、抽取不需要把所有数据传到云端。华硕弘道系列属于面向商用和行业用户的笔记本产品线加上AI能力后它的定位从“能跑办公软件”变成了“能跑本地模型”。这里不讨论具体型号和跑分因为不同批次配置会变化。更稳妥的判断是只要本机可以流畅运行7B级别的量化开源模型下面这套工作流就能跑通。2.2 AI工作流不是Flowable很多后端开发一听到“工作流”就会想到Flowable、Activiti这类重量级工作流引擎。这个理解没有错但“AI工作流”的侧重点不一样。Flowable解决的是流程状态机的管理节点、审批、连线、会签。而AI工作流解决的是“业务的重复动作怎么编排”它可以是基于脚本的也可以是基于可视化工具的核心是把大模型能力嵌入到可能原本靠人工完成的判断环节。在本文的场景里工作流更像是一条“业务流水线”读取名单、分群、生成策略、质检、出报表。它不需要事件驱动引擎也不需要复杂的审批流。先用Python脚本把最小路径跑通比一开始就上Flowable更务实。2.3 端侧模型和云端API怎么选这是搭工作流时绕不开的选择题。整理一下对比对比维度本地端侧模型云端大模型API数据安全数据不出设备合规风险低数据出域需严格脱敏和授权使用成本一次硬件投入电费可忽略按Token计费规模越大成本越高延迟首次加载慢运行后稳定受网络影响高峰期可能波动模型能力7B级别复杂推理有限可调用百B甚至千B级模型运维门槛需要自己管理模型和依赖无需运维开通即用结论很清楚模型能力强弱不是本地部署的第一考量数据边界才是。催收业务涉及敏感个人信息本地模型哪怕判断粗糙一点也比“数据出去”的风险小。实际操作中还可以做混合方案常规分群用规则质检和话术总结用本地模型只有脱敏后的汇总数据才允许进入云端。3. 环境准备在这台AI笔记本上需要装什么3.1 硬件与系统以华硕弘道AI笔记本这一类AI PC为参考建议硬件底线是内存16GB起步32GB更舒服。本地推理7B模型内存不够会直接OOM。硬盘建议512GB以上模型文件加依赖至少预留20GB。操作系统建议Windows 11 WSL2或者直接安装Ubuntu。Windows下跑Ollama也可以但WSL2环境下调试脚本更顺手。注意这里不写死具体CPU型号因为AI PC的CPU平台比较多Intel Core Ultra、AMD Ryzen AI、高通骁龙X都算。即便CPU型号不同只要内存和NPU够用流程逻辑完全一致。3.2 软件栈# 更新系统基础软件 sudo apt update sudo apt upgrade -y # Python 3.10WSL2 或 Linux 环境 python3 --version pip install --upgrade pip # 项目依赖 pip install pandas openai # Ollama 本地模型管理工具 curl -fsSL https://ollama.com/install.sh | sh如果你在Windows原生环境可以直接下载Ollama桌面版然后安装Python。后续所有命令建议统一在WSL2的终端里执行避免Windows和Linux路径混用导致问题。3.3 项目目录规划不要把所有脚本放在一个文件里一个清晰的项目结构对后续维护很重要。推荐的目录结构如下zhouzhi-workflow/ ├── data/ │ ├── raw/ │ │ └── customers.csv │ └── processed/ ├── workflow/ │ ├── customer_segment.py │ ├── quality_check.py │ ├── report.py │ └── main_pipeline.py ├── prompts/ │ ├── strategy_prompt.txt │ └── quality_prompt.txt └── output/data目录放原始数据和中间结果workflow目录放运行代码prompts目录放提示词模板output目录放最终报表。这样分层的意义在于业务规则变更时只改对应模块不会把整个脚本推倒重来。3.4 准备一份脱敏测试数据为了跑通流程先准备一份小样本数据。注意即使是测试数据也不要使用真实客户手机号。可以用固定格式生成假数据customer_id,phone,overdue_days,contact_status C001,13800001111,95,lost C002,13900002222,45,reachable C003,13700003333,15,reachable字段含义customer_id客户编号。phone手机号这里只是演示真实接入时必须先脱敏。overdue_days逾期天数。contact_status联系人状态reachable表示可联系lost表示失联。4. 工作流整体设计先拆业务再写代码4.1 典型催收工作流有哪些环节催收作业看起来是一通电话背后其实是多个环节的协作。整理成流程如下客户名单导入。从催收系统或Excel批量导入当天待处理客户。风险评估与分群。按逾期天数和失联状态把客户分成高风、中风、正常、失联四类。触达策略匹配。不同分群对应不同触达方式。执行触达。短信、自动语音、人工外呼。催记回传。外呼结束后催收员填写沟通结果。合规质检。检查催记和录音话术是否符合业务红线。报表生成。汇总分群统计、触达率、质检结果。前3步适合自动化第4、5步需要人参与第6、7步可以交给系统处理。本文的重点是把1、2、3、6、7跑通。4.2 规则与大模型的职责边界一个常见误区是既然都本地部署大模型了分群、策略、质检全交给大模型。这不是好设计。分群这类判断规则非常稳定逾期90天以上属于高风险这个结论不需要模型来“想”。即使让模型做它也可能因为提示词写得不清楚而输出不一致结果。正确的分工是能用Excel函数和Python规则解决的不调用模型。模型只做两件事策略话术的生成建议、催记文本的合规质检。模型输出之后必须有人工抽查机制兜底。这个设计背后的原因是大模型擅长的是语义理解和生成不擅长精确数值计算。把不擅长的事情交给模型是工作流不稳定的主要来源。4.3 数据流设计每个步骤的输入输出整个工作流的数据流可以拆成五段输入CSV文件每行一个客户。分群后在DataFrame里新增segment列和masked_phone列。策略后新增strategy列记录该客户采用的触达方式。质检后记录质检结果JSON包含是否通过、违规原因。输出汇总统计CSV以及质检日志。数据流清晰之后代码结构自然就清楚了。下面是完整实现。5. 完整实现从本地模型到自动化流水线5.1 启动本地大模型服务首先拉取一个适合中文业务场景的开源模型。这里以Qwen2.5 7B为例它在中文本体和结构化输出方面表现比较稳定。# 在 WSL2 或 Linux 环境下执行 # 启动 Ollama 服务 ollama serve # 新开一个终端拉取模型 ollama pull qwen2.5:7bOllama下载完成后默认监听本机11434端口。它提供了兼容OpenAI协议的接口所以后面Python代码可以直接用openai库访问。验证服务是否正常curl http://localhost:11434/v1/models如果返回了包含模型ID的JSON说明本地模型服务已经就绪。5.2 客户分群模块# 文件路径workflow/customer_segment.py import pandas as pd def mask_phone(phone: str) - str: 对手机号脱敏避免完整明文进入后续环节。 if not phone: return return phone[:3] **** phone[-4:] def apply_segment(df: pd.DataFrame) - pd.DataFrame: 按逾期天数和联系状态做客户分群。 def classify(row): if row[contact_status] lost: return lost_contact if row[overdue_days] 90: return high_risk if row[overdue_days] 30: return medium_risk return normal df[segment] df.apply(classify, axis1) df[masked_phone] df[phone].map(mask_phone) return df这里有两个细节值得说明。第一分群顺序很重要。先判断“失联”再判断“高风险”因为失联客户需要走失联修复流程风险等级反而是次要信息。第二mask_phone在任何环节都要执行。即使是在本地跑模型也要养成“最小暴露”的习惯防止中间日志里出现完整手机号。5.3 催收策略生成策略生成可以很简单用规则映射即可。现实中策略可能涉及还款率、历史联系频率等更多维度但核心逻辑是稳定的映射关系。# 文件路径workflow/strategy.py def gen_strategy(segment: str) - str: 根据分群结果生成触达策略。 mapping { normal: 短信提醒 自动语音, medium_risk: 人工外呼 还款方案沟通, high_risk: 资深催收员跟进 合规面谈, lost_contact: 失联修复先联系紧急联系人合规前提下, } return mapping.get(segment, 人工复核)这个模块虽然简单但它把业务规则收敛到了一个文件里。后续如果策略调整只需要改这一段映射不需要动主流程代码。5.4 催记合规质检这部分是整条工作流的重点。本地模型要做的是检查催记文本是否符合合规要求。# 文件路径workflow/quality_check.py import json from openai import OpenAI # 本地 Ollama 服务兼容 OpenAI 协议 client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, # 本地服务密钥不参与真实鉴权 ) def check_script(script: str) - dict: 检查催收话术是否合规返回结构化结果。 prompt f 你是一名贷后合规质检员。请检查以下催收通话脚本是否合规。 合规要求 1. 不得出现威胁、辱骂、恐吓性词语。 2. 不得向无关第三人透露债务信息。 3. 不得冒充公检法或伪造身份。 4. 沟通时必须说明机构名称和工号。 5. 不得采用骚扰、频繁呼叫等不当催收手段。 通话脚本 {script} 请返回 JSON格式如下 {{pass: true/false, reasons: [违规点1], suggestion: 修改建议}} resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: prompt}], temperature0.1, ) content resp.choices[0].message.content try: return json.loads(content) except json.JSONDecodeError: return { pass: False, reasons: [模型输出不是合法JSON请人工复核], suggestion: content, }这里有一个容易被忽略的点为什么temperature设成0.1因为质检是判断类任务需要输出稳定。如果temperature太高模型可能会把同样一段话术一次判通过、一次判不通过这是质检逻辑不能接受的。另外本地模型输出不一定稳定所以代码里加了JSON解析失败的兜底。实际项目中解析失败的任务应该进入“人工复核队列”而不是直接通过或直接拦截。5.5 报表生成# 文件路径workflow/report.py import pandas as pd def export_summary(result_df: pd.DataFrame, output_path: str) - pd.DataFrame: 按分群统计客户数量导出汇总报表。 summary result_df.groupby(segment).agg( count(customer_id, count) ).reset_index() summary.to_csv(output_path, indexFalse, encodingutf-8-sig) return summary导出CSV时使用utf-8-sig编码是为了避免Excel打开时中文乱码。如果你用的数据量比较大后续可以在这里加上触达率、质检通过率等聚合指标。5.6 主流程编排# 文件路径workflow/main_pipeline.py from pathlib import Path import pandas as pd from customer_segment import apply_segment from strategy import gen_strategy from quality_check import check_script from report import export_summary BASE_DIR Path(__file__).resolve().parents[1] def run(): # 1. 读取客户名单 df pd.read_csv(BASE_DIR / data / raw / customers.csv) # 2. 客户分群 df apply_segment(df) # 3. 生成策略 df[strategy] df[segment].map(gen_strategy) # 4. 对每条客户打印任务信息 for _, row in df.iterrows(): print( f{row[customer_id]} | {row[segment]} | f{row[masked_phone]} | {row[strategy]} ) # 5. 质检示例模拟一段催收脚本 sample_script ( 您好这里是XX消费金融贷后中心工号0826 请问是张先生吗您有一笔账单已逾期45天 今天可以安排还款方案说明。 ) quality check_script(sample_script) print(质检结果, quality) # 6. 生成报表 output_dir BASE_DIR / output output_dir.mkdir(exist_okTrue) summary export_summary(df, output_dir / summary.csv) print(summary) if __name__ __main__: run()主流程的核心思路是“线性编排”。因为步骤之间没有复杂的条件分支用脚本串起来比引入工作流引擎更轻量。真正需要引擎的时候是这个流程变成多人协作、审批、多级任务分配之后。5.7 跑通完整流程确保当前在workflow目录下cd zhouzhi-workflow/workflow python main_pipeline.py如果一切正常你会看到分群结果和质检结果依次输出。6. 运行结果与效果验证6.1 预期输出用前面三行测试数据运行预期输出类似C001 | lost_contact | 138****1111 | 失联修复先联系紧急联系人合规前提下 C002 | medium_risk | 139****2222 | 人工外呼 还款方案沟通 C003 | normal | 137****3333 | 短信提醒 自动语音 质检结果 {pass: True, reasons: [], suggestion: 保持当前沟通口径}同时output目录下会生成一个summary.csv内容类似segment,count lost_contact,1 medium_risk,1 normal,16.2 判断成功的标准工作流跑通不等于效果可用。建议按以下标准逐条验证分群结果是否符合业务预期。失联客户优先高风险客户进入资深催收员队列。手机号是否全程脱敏。如果日志里出现完整手机号说明脱敏没有执行到位。质检结果是否稳定。同一段话术多跑几次结论不应频繁翻转。报表字段是否满足使用方要求。不要等日报发出来才发现少了一列。6.3 性能观察与调优方向7B模型在AI笔记本上推理单次质检出结果可能需要几秒到十几秒具体取决于硬件和模型量化方式。如果觉得慢可以换更小参数的量化版模型例如qwen2.5:7b-q4_K_M。如果换小模型后准确率下降明显说明模型能力是瓶颈优先恢复原参数而不是盲目优化延迟。第一次运行如果失败不要急着改代码。先确认三件事Ollama服务有没有启动、模型有没有拉取成功、Python依赖有没有装齐。7. 常见问题与排查方法问题现象可能原因排查方式解决方案Ollama服务启动失败端口被占用运行curl http://localhost:11434/v1/models释放端口或修改Ollama默认端口调用本地模型超时模型未加载或内存不足查看Ollama运行日志等待模型加载完成或换更小的量化版本openai库报连接错误base_url写错或服务未启动先运行curl再检查base_url确认base_url为http://localhost:11434/v1Python导入模块失败当前目录不是workflow运行pwd查看当前目录进入workflow目录后重新运行CSV中文乱码编码未指定用文本编辑器打开CSV检查导出时使用encodingutf-8-sig质检结果多次不一致temperature设置过高检查模型调用参数把temperature降到0.1左右质量管理要求看到完整手机号脱敏策略过于严格与业务方确认展示范围采用前三后四脱敏或分级查看权限8. 最佳实践与工程建议8.1 数据合规是上限整个工作流的运行基础是数据合规。必须明确几件事数据来源是否有用户授权员工访问范围是否最小化日志是否完整可审计模型是否全程本地运行。如果这些回答不清楚不要急着上线。在代码层面所有手机号、身份证号等敏感字段在打印前必须脱敏。提示词模板中不要出现完整姓名和电话号码这是底线。8.2 规则优先模型兜底能用规则实现的需求不要为了“AI化”而引入模型。分群用规则策略映射用规则模型只负责它擅长的语义理解和生成。这样的好处是系统行为可预测、调试方便、故障影响面小。8.3 模型与依赖版本要固定本地部署的模型版本必须固定。今天用qwen2.5:7b明天拉一个更新版本可能质检标准就变了。Python依赖也一样建议使用requirements.txt锁定版本。pip freeze requirements.txt8.4 结果必须可审计每一次质检都应该记录输入话术、模型输出、处理时间、处理版本。不要把质检结果直接当成最终结论至少设置一个“人工复核待办”。这一点对催收业务尤其重要因为机器判断出错后需要能够追溯。8.5 何时从笔记本迁移到服务器华硕弘道AI笔记本适合以下场景单团队验证、小型业务闭环、出差演示、数据合规要求极高且需要物理隔离环境。它不适合日处理量极大的场景。当出现以下信号建议迁移到GPU服务器或容器化平台每天需要质检的催记超过几千条单机推理排队明显。需要多人同时访问工作流服务。需要模型服务高可用不能因为笔记本休眠而中断。迁移时代码结构基本不用变只要把模型服务端点从localhost换成服务器地址即可。这正体现了“先把最小路径跑通再考虑规模化”的价值。9. 总结与下一步实践建议这篇内容真正讲清楚了三件事第一AI笔记本的落地价值不在跑分而在于把数据、模型和业务流程放在同一个可信的本地环境里。对催收这类数据敏感业务这个特性比什么都重要。第二工作流不是越复杂越好。先用规则把稳定场景兜住再用本地大模型做语义判断最后用人工复核兜底这个顺序能避免大部分踩坑。第三一套完整的工作流需要业务拆解能力而不是代码能力。写分群、策略、质检脚本只需要半天但想清楚谁来做、谁来看、哪些数据必须脱敏、模型判断错了谁能发现才是真正花时间的地方。下一步建议很直接不要急着买更贵的硬件也不要急着接入云端大模型API。把手头最重复的一张Excel表拿出来按本文“分群 策略 质检 报表”的顺序先用脚本跑通一个最小闭环。跑通之后你自然会知道瓶颈在模型能力、