刘红皓接到这个把AI部署进殡仪馆的项目邀请时，我第一反应不是兴奋，是想逃。作为常年做大模型落地的人，我早已习惯在干净的数据机房里调优推理参数、算吞吐、看显存曲线，但走进那条连着告别厅的长走廊时，我还是清楚意识到：平时那套“上线-观测-迭代”的玩法，在这里全部失灵。团队里的人劝我时说了一句话：伦理审查已经过了一轮，现在缺一个能把模型老老实实跑起来、又肯承认AI不该做什么的人。这句话改变了我。
项目实际地点不是遗体处理区，而是殡仪馆内部一个独立出来的生命关怀空间，隔壁就是告别厅和家属休息区。主要使用者也分两类：一部分是临终者本人，更多是正在处理丧葬事务、同时承受着巨大情绪压力的家属。他们要面对的东西太沉，以至于“能提供多强的AI”根本不该是第一个问题；第一个问题是——AI在这里能做什么，以及它绝不能做什么。这篇文章我尽量不写情怀，只讲那条从伦理约束倒推技术方案的完整路径，包括本地化部署的选型逻辑、对话护栏的分层实现、一次真实的越界事故复盘，以及我们最终定下的产品边界。
1. 这个场景先列伦理账，再谈技术账
1.1 使用场景里的“用户状态”和普通客服完全不同
很多AI项目在做需求分析时看的是用户行为，但在这里，我首先注意到的是用户状态：绝大多数人走进关怀空间时，已经连续很多天没有睡好，注意力涣散、情绪高度敏感，又因为传统文化影响，很多话不能对家里人说、不想对医生说，只能对着一个“不会评价自己”的机器讲。这种状态下，任何一句措辞不当都会被放大成巨大的心理冲击。
传统客服机器人追求的是“解决问题效率”，但这个场景不能追求效率。家属问“遗体接运流程有哪些”，系统确实应该快速给标准答案；可一旦同样的人问“我是不是不该把老人送进安宁病房”，这时候AI要做的不是检索，而是停下、共情、转介给真人。这决定了整个软件的架构不是“问答引擎”，而是一套“话术分诊系统”。
另外要考虑一个很笨拙的现实：使用者里老人多。不会打字，听不懂复杂的操作，视力也在下降。我们一开始设计了语音交互，但马上被伦理审查会问住：语音输入如果在设备上实时收音，旁边有人怎么办？家属的情绪话被其他亲戚听到怎么办？所以整个系统被设计成“主动按键启动，语音一次一句，在本机完成语音转文字，不留音频文件”。这个决定很大程度上保护了使用者的表达自由，也让家属放心让老人独自使用。
1.2 我列出的问题清单，比技术架构更长
开始写方案前，我把已经出现过和可能出现的伦理风险全部列出来，不是为了应付审查，而是为了让自己在后面写代码时有一条不能越过的线：
- 知情同意风险：使用者可能并不知道自己在和机器说话，或以为AI的回答来自某个真人工作人员。
- 医疗越界风险：模型一旦说出“没事，会好的”或“治疗方案不要停”，都可能影响真实医疗决策。
- 幻觉风险：模型可能凭空编造家属姓名、编造共同回忆、甚至编造逝者曾经说过的话。
- 人格复刻风险：家属要求“让AI学一下老伴的声音和语气”是最棘手的问题之一。
- 隐私风险：对话内容会涉及家族财产分配、私人恩怨、婚外关系、未和解的冲突，这些比普通病历还要敏感。
- 自主性风险：系统如果太主动，会干预使用者自己的情绪节奏；如果太刻板，又会让对方觉得被敷衍。
- 人工接管风险：AI识别到高风险信号后，能不能真的找到真人？万一值班社工不在，怎么办？
当时团队里一位做了二十年安宁疗护的老护士看着这张清单说了一句话：“你们要做的不是不让AI犯错，而是让AI就算犯了错，也有真人在后面兜得住。”这句话基本成了整个项目后续设计的核心原则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么必须本地化部署，而不是直接调云端大模型
2.1 对话内容的敏感程度，不允许原始文本离开这栋楼
项目刚开始，产品经理提出的最快方案是“接入成熟大模型的API，两天就能跑通Demo”。我直接否决了。原因不在技术，而在对话内容的信任关系。很多人愿意对着机器讲出不敢对子女讲的话，是因为他们默认“这台机器属于这个机构，不属于某个商业公司”。如果对话被传到外部模型服务，哪怕合同里写得再清楚，家属只要在伦理访谈里问一句“这些话会不会被人看见”，我们就无法回答。
所以从立项第一周起，本地化部署就不是可选项，而是硬约束。