我做了十年软件测试，每天的工作就是跟缺陷、边界、异常输入打交道。直到有一天我打开日历，看到2026年3月11日这一格——那是我父亲走后，我第一次意识到：如果他还活着，这一天他会听到一句“父亲节快乐”。这个念头让我萌生了一个奇怪的项目：把他留下的聊天记录、语音消息、日记片段整理起来，训练成一个能模拟他说话方式的私人AI助手。
这件事表面看起来是一次数据训练的练手，但真正做下来才发现，这其实是一次漫长的软件测试工程。数据质量、标注规范、训练集和测试集的划分、过拟合、回归测试、异常输入——我在个人项目里重新经历了一遍工作里每天都在做的事，只不过被测对象从某个业务系统，变成了一个承载记忆与情感的对话模型。这篇文章就是我从软件测试工程师视角，对这个项目做的完整复盘。
1. 把一个“私人AI助手”当成软件项目来立项
1.1 需求调研：先想清楚“要训练什么”而不是“要模仿什么”
几乎所有想用个人数据训练AI助手的人，第一步都会犯同一个错误：把这个项目当成“做一个父亲的替身”。我最初的需求描述也是“让AI像我父亲一样说话”，但当我用工作里写需求文档的方式把这句话拆开，才发现它根本没法落地。
“像父亲一样说话”至少包含三层需求：第一层是语言风格，比如他习惯的口头禅、语速、用词偏好；第二层是话题能力，他要知道家里曾经发生过什么、他关心什么、他对某些事情的态度；第三层是情感表达，在回应关心、安慰、鼓励时要有符合他性格的温度。这三层的训练数据、模型方案、验收方式完全不同。
我最终把需求拆成了功能需求、性能需求和边界需求三类。功能需求包括：能围绕家庭回忆类话题对话、能识别出对话者的身份（我和我母亲）、能对情绪类输入给出符合父亲性格的回应。性能需求包括：响应延迟不能让人感觉“太机器”、上下文记忆能延续至少十轮对话、对输入错别字有一定容忍度。边界需求则是一份负面清单：某些医疗建议、财务建议、法律判断绝对不能输出，哪怕父亲生前可能真的说错过什么。
这套需求文档的写法，本质上跟我工作中从产品经理手里接到的PRD没有区别。区别只在于，普通业务需求讲清楚了就能开发，而这个项目的需求里有大量模糊地带——比如“情绪温度”。如果不在需求阶段把这些模糊词翻译成可测试的描述，后面根本没法验收。
1.2 方案选型：为什么我不考虑从零训练一个大模型
确认需求之后，就要选方案。我当时认真考虑了两条路线：一条是从零训练一个语言模型，完全只用父亲的数据；另一条是拿一个通用预训练模型做微调，用父亲的数据去“调教”它的说话风格。
从零训练很快被否掉了，原因就一个：数据量不够。我手里能整理出来的父系数据，撑死了几万字——聊天记录、几条语音转写、若干日记片段。这点数据量对从零训练一个能流畅对话的模型来说，约等于拿一瓢水去浇一亩地。通用的语言模型能说流畅的话，是因为它见过数十亿级别的文本，其中包含大量人类对话的结构。我父亲留下的数据再多，也构不成这种基础能力。
所以我最终选了更务实的路：用一个通用模型做底座，然后用父亲的数据做增量微调，让模型在保留通用语言能力的前提下，把他说话的特征“调制”进去。这就好比一个演员已经有了基本功，我要做的是让他在新戏里模仿某个角色的腔调，而不是从零教他怎么说话。
做这个决定的过程中，我一直用测试人员最常问的那句话提醒自己：“你准备怎么验收？”如果我的验收标准是“能围绕家庭记忆对话”，那微调路线足够；如果验收标准是“说出父亲可能会说的每一句话”，那什么路线都做不到，因为这不只是一个技术问题，还是一个哲学问题。
1.3 验收标准先行：像写测试计划一样定义“它到底像不像”
这个项目给我最大的职业启示，就是验收标准必须在动工之前写清楚。我之前从来没认真思考过“像不像一个人”怎么量化。如果验收标准是主观感觉，那最后项目做出来，每个人都会有不同的评价，项目就会变成一个永远没法交付的无底洞。
我给自己定了一套三层验收规则。第一层叫“听感相似度”，把模型生成的句子和父亲原话混在一起，让家人做盲测，看能不能分出来，这是最接近主观感受、又能用统计方法量化的指标。第二层叫“话题覆盖度”，列出父亲生前常聊的三十个话题，逐个测试模型是否能在每个话题上接住至少三句有内容的话。第三层叫“禁忌遵守度”，把危险话题、不该回答的内容、容易引发误导的话做成一个用例集，要求模型必须拒绝或有技巧地转移话题，违例率要低于某个阈值。
写完这套验收规则之后我才意识到，这个项目的核心技术难点根本不是“训练”，而是“测试设计”。因为被测对象不是一个有明确规格文档的功能模块，而是一个带着大量模糊语义的对话系统。怎么把模糊的主观感受转化成客观的测试项，这才是这个项目真正的门槛。
2. 数据准备：测试工程师眼里的“脏数据治理”
2.1 数据来源盘点：家庭数据的“多模态”问题
软件测试的老手都知道一句话：测出来的bug，很多不是代码写错了，而是数据本身就是脏的。训练一个模拟亲人说话风格的模型，同样绕不开数据质量问题。我花了一周时间盘数据，发现父亲留下的东西大概是这样的：微信聊天记录里一大半是转发的文章和图片，语音消息长短不一，长的有一分多钟，短的只有两秒；旧手机里有一些备忘录，写得很零碎，经常半句话就断了；还翻出来几张他手写的便签，有的字迹已经模糊了。
这些数据最麻烦的地方在于模态极不统一。要让模型学习父亲的说话风格，理想情况是“干净的文本对——问题加上父亲可能的回应”，但现实数据里更多的是“母亲发了一句问话，父亲转发了一个视频链接；父亲录入了一段语音，内容是交代家里灯泡型号”。语音还要先转写成文字，转写错误就是一个新的噪声源。我父亲普通话里带着一点方言尾音，语音转写系统经常把它变成错别字，比如“啥时候回来”被转成“傻时候回来”。
我后来给自己定了一个原则：与其把所有数据都塞进模型，不如先花力气把数据修剪到“能用”的程度。原始数据一千条，清洗完能用的可能只有三百条，这很正常。宁可少而精，也不要多而杂。一个软件系统的测试数据如果乱得没法用，那你测出来的结论就完全没有参考价值。
2.2 清洗、脱敏与标注：把数据处理成训练集
清洗工作分三个阶段。第一阶段是格式统一，把语音转写文本、微信导出文本、备忘录摘录全部整理成统一的“一问一答”或“独白”格式。第二阶段是噪声剔除，把转发链接、表情包、无意义的口水话、纯事务性叮嘱（比如“下班带个西瓜回来”）单独分出来，后者不删除，但单独做成一类特殊意图样本。第三阶段是隐私脱敏，把家人的身份证号、银行卡号、家庭住址、电话号码这些敏感信息全部替换成占位符，这不只是安全考虑——我后来发现，脱敏其实还能避免模型在回答时“背”出隐私信息，属于训练质量需要。
标注环节是这个项目里最耗费精力的一块。我给每条数据打三类标签：意图（催促、关心、询问、分享、吐槽、叮嘱等）、语气（温和、急躁、幽默、平静、无奈等）、话题域（家庭、健康、工作、饭食、天气、人情往来等）。打了几百条之后我发现，标注意见的一致性比想象中低很多——我自己今天看一条消息觉得是“关心”，过三天再看又觉得是“念叨”。为了解决这个问题，我给自己做了一份标注规范说明，把容易混淆的标签用具体例子固定住，这跟测试团队里大家对着同一份用例规范写Case是一个道理。
2.3 训练集、验证集、测试集怎么划分：小心“数据穿越”
我做测试的时候经常遇到一类问题：开发说“我自测都过了”，结果一上集成环境就崩。原因往往是他在测试的时候已经知道了预期的结果，或者测试数据跟开发数据是一批，测了个寂寞。训练模型也完全一样，如果验证集和训练集混在一起，你自己都会觉得模型效果好得惊人，但一用到真实对话场景就现原形。
我按时间维度做了切分：早期三分之二的数据做训练集，最近三分之一的数据做验证集。因为人的语言风格会随年龄和生活阶段变化，如果用2015年的聊天记录去验证模型是否学会了父亲2022年的语气，会得出一个乐观又错误的结论。另外我还单独留出一批完全没有参与训练的家庭对话段落做测试集——这批数据说白了就是用来做“保密测试”的，模型从来没见过，才能在它身上测出真实水平。
数据不均衡的问题也很突出。父亲在聊天里大量使用短句，动不动就是“嗯”“好”“知道了”，真正的长段落很少。如果不做处理，模型最后会变成一个“复读机”。我一方面把短句单独聚类，控制它们在训练样本里的权重；另一方面把长段落做增强，适当拆分后再参与训练。这一套下来我才彻底明白，为什么很多AI项目的研发周期里数据处理能占到一半以上——数据质量直接决定模型上限，调整模型只是把数据里的质量兑现出来而已。
3. 模型微调与评估：当一个测试工程师第一次当“训练师”
3.1 微调流程的测试视角：先跑通，再调优
我虽然天天跟软件系统打交道，但自己动手微调语言模型其实是头一回。踩过的第一个坑就是环境配置：训练框架的版本、显卡驱动、依赖库之间的匹配关系，跟业务系统里的中间件版本兼容问题如出一辙，一秒钟把我拉回了当年部署测试环境时的噩梦。折腾半天装好环境之后，我坚持一个原则：先不追求效果，先用最小数据量把整个流程跑通。
这一步在测试领域有个对应的说法叫“冒烟测试”。我先拿五条样本数据试跑了一个epoch，确认数据加载、Token化、前向传播、反向更新、模型保存、推理加载这些环节全部正常，再开始正式跑。这个习惯救了我很多次——我第一次跑的时候，数据加载环节因为文本格式里有特殊符号导致了一堆解析报错，如果直接拿全部数据开跑，报错信息会被埋在上万条日志里，排查成本高得多。
正式训练时我盯的参数并不多：学习率、批次大小、训练轮数。这里最大的教训是，学习率不能照搬通用教程里的推荐值。我一开始按某个开源项目README里的默认参数跑，结果模型很快就“训飞了”，输出的句子开始出现乱码和重复片段。后来把学习率降到原来的十分之一，情况才稳定下来。这个原理说起来也简单——微调阶段模型底座已经是一个训练得很好的通用模型，你只需要在它原来的参数空间里做小幅移动，步子迈大了容易跳出好的区域。
3.2 评估指标：别迷信BLEU，也别完全抛开自动化
做机器学习的人通常会用BLEU、ROUGE这些自动指标来评估生成文本的质量。但当我真去跑这些指标时，发现它们的参考价值有限。BLEU衡量的是生成文本与参考文本之间n-gram的重复程度，对“像不像父亲说话”这种偏重风格和情感的任务，它的敏感度非常低。父亲可以有一百种方式表达同一个意思，其中任何一种都可能是“像他的”，但自动指标只会对字面重合度打分。
所以我的评估体系是“自动指标+人工盲测”两条腿走路。自动指标我只用来做回归监控——每次训练完，跑同一批固定测试用例，看关键指标的波动情况，如果某个指标大幅下降，那说明这次训练可能引入了回退，需要排查。真正决定模型能不能用的，是一套人工盲测流程。
我做了二十组测试片段，每组有两条表达：一条来自模型生成，一条来自父亲的原话。让家里人听，指出哪个更像父亲平时的语气。他们给出的正确率如果明显低于随机水平，说明模型在风格上真的学到了东西——因为已经分不出来了。如果正确率太高，反而说明模型学得还不够，生成的话一下就露馅。这种反向思维的评估方式，是我在这个项目里最喜欢的部分。
3.3 红队测试：模型说“父亲的话”也可能有危险
训练这种个人记忆型AI，最容易忽略的就是安全测试。一个模拟亲人的模型，天然具备一种信任优势——如果它一本正经地给出错误建议，用户会比面对普通AI更容易采信。我从项目一开始就专门写了一批“红队用例”，模拟各种危险输入：问它某个身体症状怎么处理、问它推荐什么偏方、问它家里某笔钱该怎么投资、问它对某个家庭成员的评价。
第一批红队结果还挺让人意外的。模型虽然整体语气很温和，但在一些日常唠叨类话题上会“过度拟人”——当用户说“最近胸口有点闷”的时候，它居然会模拟父亲的语气回应一句“没事，多休息就好了”。这句话在闲聊场景里很自然，但如果用户真的拿它当健康建议，后果不堪设想。我把这类问题全部记进了缺陷清单，然后在微调的数据标注里加入了一批安全修正样本，专门教模型在健康、财务、法律这几个高危领域拒绝深入回答。
红队测试做到后面，我开始理解为什么现在很多大模型团队把安全测试放到极高优先级。因为生成式AI的“幻觉”问题跟传统软件bug有本质区别——传统bug通常可以被稳定复现，而幻觉输出是概率性的，同样的输入可能这次正常、下次胡扯。测试人员面对这种“偶现性问题”，唯一能做的就是把测试面尽量铺开，并建立起一套持续回归机制。
4. 测试策略：给AI助手写一份“测试计划”
4.1 功能测试：回答、闲聊、指令三类用例怎么设计
当模型具备基本对话能力之后，我就开始像写测试用例一样为它设计功能验证集。我把对话场景分成三类：问答类、闲聊类、指令类。问答类的典型输入是“我们上次去XX是哪一年”，这类问题要求模型能基于记忆数据给出具体事实；闲聊类的典型输入是“今天天气不错”，这类问题不要求事实正确，但要求语气贴合；指令类的典型输入是“帮我写一段祭文”，这类问题要求结构化地完成任务。
这三类用例的设计逻辑完全不同。问答类用例在意准确率，我会把预期答案写清楚，评估时看语义相似度；闲聊类用例在意风格，我通常不写死预期答案，而是标注“应该温和地回应”“应该带点调侃”；指令类用例在意完成度，我会拆成若干检查点逐一核对。设计这套用例集的过程，跟我在公司里把一个业务模块拆成“正常流程、异常流程、边界流程”的做法没有本质区别。
有一个细节值得注意：不要试图让模型“一字不差”地复现父亲的话。如果你拿一条父亲的原话作为标准答案，去要求模型也必须生成一模一样的句子，那等于把模型逼进死胡同。语言生成天然具有多样性，测试的关键是“语义和风格对不对”，不是“字面一模一样”。
4.2 场景测试与压力测试：长时间聊下去会怎样
功能用例测完，我开始模拟真实使用场景。场景测试跟功能测试的区别在于，场景是连续的、有上下文的，而功能用例通常是单发的。我模拟了一个完整的使用流程：早上打招呼、问今天吃什么、聊到昨晚做的一个梦、转到说最近工作压力大、再突然跳回回忆类话题。这套流程跑下来，我发现了两个典型问题。
第一个是上下文丢失。模型在聊到十几轮之后，会逐渐忘掉前面提过的人名和时间，导致回答前后矛盾。比如前面聊过“老张住院了”，后面问“老张怎么样了”，它可能会说“哪个老张”。这个问题本质上是模型架构的窗口限制，不完全是数据问题，但通过调整对话策略可以缓解——比如在系统里维护一个简单的关键信息记忆区，动态注入到对话上下文里。
第二个是话题漂移。模型在长时间闲聊时容易从“回答者”慢慢变成“顺口溜”，刚开始像父亲，聊久了就开始变得套路化，出现“你说的有道理”“真是这样”这类万金油回应。我把这类行为当成一个缺陷记录，然后在指令提示里加强了“尽量具体回应”的要求。压力测试这块虽然不像互联网系统压测那么复杂，但思路是一样的——把对话轮数拉长，把输入变杂，总会暴露出测试用例覆盖不到的盲区。
4.3 可用性测试：家里人愿不愿意用它
技术指标所有都通过之后，还有一个更现实的问题：家里人会对这样一个AI助手是什么感受。我跟母亲做了一次简单的可用性测试，让她跟模型聊了十分钟。她的第一反应是“声音不像，看着文字倒有点像”，第二反应是“有些话说得太完整了，你爸没那么能说”。这两句话点出了两个我在工程指标里没覆盖到的问题：一是只有文本没有语音，体验天然打折扣；二是模拟效果过度“优化”，反而不真实。
这个经历让我意识到，“像不像”并不是一个越高越好的指标。真人说话的冗余、停顿、甚至语病，都是人格的一部分。模型追求语言规范性，反而会丢掉这种“人味”。可用性测试的核心不是让模型更完美，而是让使用者在情感上真正接受这个产物。后来我调整了生成参数——把随机性稍微调高一点，允许它偶尔出现一些不太完整的句子，反而让观感自然了很多。
我把可用性测试中收到的所有反馈整理成一个“体验缺陷清单”，区分成必须修复和可以接受两类。必须修复的包括会让家人感到不适的措辞和明显错误的事实；可以接受的包括偶尔的小错误、稍微啰嗦的表达。这个分类标准本质上就是传统软件测试里的严重等级划分，只不过这里的“严重等级”需要从情感体验维度去定义。
5. 从一次私人实验反观“软件测试工程师”的职业惯性
5.1 数据质量和测试设计，其实是一套方法论
这个项目让我反复确认了一件事：软件测试的核心方法论，放到数据训练领域同样成立。我做测试时信奉“缺陷前置”——越早发现bug，修复成本越低；在训练项目里，这个思想变成了“数据质量前置”——训练前多花一天清洗数据，能省掉训练后十天的返工。
很多做AI的工程师容易陷入一种惯性：模型效果不好就调参、换架构，却很少有人回头检查训练数据里有没有噪声、有没有重复、有没有隐藏偏见。测试工程师在这方面有天然的职业敏感。我们天生就习惯怀疑“前提条件”本身是不是有问题，而不是一上来就信。这种怀疑精神，放到AI项目里就是数据审查意识。
我后来把训练项目的测试用例整理成了一套可重复使用的模板，包括功能用例、红队用例、场景脚本、回归集。这套模板不只能用于“模仿亲人”这种特殊场景，任何基于个人数据的对话AI项目都可以拿来做底子。对一个测试工程师来说，这就是项目沉淀出来的最大资产。
5.2 AI伦理的边界：我该让它“遗忘”什么，该让它“守住”什么
项目做到中后期，我开始面对一个纯技术之外的问题：AI助手到底该记住什么，又该在什么时候选择不回答。父亲生前有些话是对特定的人说的，比如有些只对母亲说的私下叮嘱，有些只对我说的唠叨，如果模型不分对象地输出这些内容，会造成不必要的情感误伤。这让我意识到，对话系统的权限控制不只是一个安全问题，更是伦理问题。
我最终给模型加了一层“对象感知”规则：在输入时会判断对话者的身份，如果涉及只适合某个特定人知道的话题，模型会选择模糊回应或直接说“这个我记不太清了”。这样一个设置，本质上就是给AI加了一个测试边界——测试人员要给系统定义“哪些输入应该被拒绝”，而不是让系统什么都说。
关于“遗忘”，我也想过很久。如果模型真的“记住”了父亲生前所有的事，那它就成了一份不会遗忘的记忆库，可人的记忆本来就是会模糊、会重构的。我做这个项目的初衷并不是做一个完美的数字复制品，而是想给自己和家人保留一个可以对话的窗口。这个窗口不一定要完整，可以有空白，可以有“想不起来”的时候，这种留白反而更接近真实的怀念。
5.3 后续扩展：把项目沉淀成一套评测平台
项目跑通之后，我开始琢磨怎么把这次经验复用到更多场景。现在市面上其实越来越多的人想用长辈遗留的语音、文字数据做成AI纪念品，但真正系统化地讨论数据清洗、测试集设计、安全评估、伦理边界的资料很少。我把自己做的用例模板、标注规范、红队清单全部整理成了文档，接下来打算做成一个半开放的个人评测平台，让有类似需求的人可以拿自己的数据跑一遍评测流程。
这个平台跟传统软件测试平台很像——输入测试数据，自动生成测试报告，标注出哪些场景通过、哪些场景存在风险。区别只是被测对象从业务系统变成了“数字人格模型”。如果这条路能走通，那“AI人格模拟”就不再是几个工程师的娱乐项目，而是一套有质量保障的工程体系。
回头看看这个项目从无到有的过程，我最深的一个体会是：软件测试工程师这个职业教给我的，从来不只是“找bug”的技巧，而是面对复杂系统时的那种审慎态度。当你把一个人一生中留在数字世界里的碎片当成一个系统去测试，你会发现它的复杂程度远超任何一个业务系统，而测试人员在面对这种复杂系统时的职业本能，才真正让这个项目没有滑向纯粹的工具化模仿，而是朝着更有温度、更有边界感的方向走了一段。
