# 用旧手机做 AI 陪伴终端：拆解一份 TRAE 帮我梳理的方案 几个月前，我用 TRAE 梳理过一个项目方案，名字叫“小伴”：把闲置的旧 Android 手机变成老人专属的 AI 陪伴终端。 最近重新翻出来，我还是觉得这份方案做得不错。需求整理得清楚，功能范围比较克制，技术设计也有值得展开的地方。尤其是本地记忆、按需加载上下文，以及“子女买密钥、配置好给老人用”这几个设计，放在一起，确实构成了一个值得尝试的应用方向。 这次就拿它做个案例，拆开看看：我为什么认可这份方案，它的技术思路好在哪里，如果继续开发，又应该先验证什么。 这里讨论的是方案设计，实际运行效果还需要原型和测试来验证。文中的对话都是帮助说明设计的假设示例。 文末附上了“小伴”设计方案的公开整理版，保留功能定义、记忆结构和技术流程，方便结合正文查看。 ## 一、先把旧手机的角色想清楚 “小伴”的出发点很直接：旧手机已经有屏幕、麦克风、扬声器，也有联网和运行 App 的能力，可以尝试把它作为一个专门的 AI 交互终端。 原方案给出的分工是：手机负责语音交互、本地记忆和设备操作，云端大模型负责对话生成。 沿着这个设计，老人说一句话，App 将语音转成文字，选择本轮需要的记忆，组装上下文后请求模型，再把回答通过语音播报出来。需要记住的新信息，则在对话后进入记忆更新流程。 这个分工让我觉得比较合理。目标设备既然是旧手机，就应该先控制它需要承担的计算量，把主要精力放在收音、播放、界面和连续使用体验上。 当然，代价也很明确：网络状况和云端响应会直接影响体验。原型阶段需要测的，是老人说完一句话以后，要等多久才能听到回答；遇到请求失败，界面又能不能给出清楚的反馈。 这样看，旧手机再利用就有了具体的技术内容：我们要给这台设备安排什么工作，哪些能力可以借助云端，又为此接受了哪些约束。 ## 二、我最喜欢的部分，是它把“记忆”拆开了 陪伴类应用要能接着聊，记忆是一个很重要的环节。老人昨天提过家人的近况，今天再说起时，系统最好能知道前情。 “小伴”方案里让我印象比较深的，就是它没有把所有信息混在一个文件里，而是设计了分层记忆。简化以后，大致是这样： ```text memory/ ├── Agent.md # 身份与交流方式 ├── memory.md # 核心档案 ├── rules.md # 规则与禁忌 ├── memory-family.md # 家庭关系 ├── memory-food.md # 饮食偏好 ├── memory-hobby.md # 兴趣爱好 ├── memory-life.md # 生活经历 ├── contacts.md # 联系人 └── logs/ # 近期对话记录 ``` 这里有两个值得讲的设计。 第一个是区分长期信息与对话记录。一次聊天的原文可以进入日志，但其中哪些内容值得长期保留，需要另外判断。今天随口说了一句“想吃面”，和明确告诉系统“我一直不吃辣”，对以后对话的作用并不一样。 第二个是区分固定加载与按需加载。身份、核心档案和规则作为每轮对话的基础；聊到家人，再加载家庭记忆；聊到饮食，再取用相关偏好。遇到跨话题的内容，也应该允许同时选择多个文件。 **这个设计的价值，在于开始考虑：每次调用模型，到底需要给它哪些信息。** 如果把所有日志和记忆都塞进去，随着使用时间增长，上下文会越来越长。分层和按需加载提供了一种控制输入范围的思路。不过，文件分好类只是第一步，如何选对记忆、避免漏掉重要信息，仍然需要实现和测试。 Markdown 在这里也有一个很实际的优点：原型阶段便于查看和检查。记错了什么、写到了哪里，开发者可以直接看文件。至于后续是否需要结构化存储，可以等数据规模和查询需求清楚以后再决定。 ## 三、记忆要形成从写入到取用的完整流程 原方案还进一步考虑了记忆如何更新：每轮对话结束后，判断有没有值得记住的信息，再决定新增、修改，或者只保留日志。 我觉得这一步很关键。只有文件目录，还不足以让应用拥有可靠的长期记忆。 举个例子，老人说： > 我女儿丽华上个月搬到苏州了。 系统需要先判断，丽华是否已经在家庭档案里。如果能够确认是同一个人，就把居住地更新为苏州，保留必要的时间信息。以后老人再提到去看女儿时，系统才有机会取用这条记忆。 这里马上会遇到更细的问题：如果旧记录写的是上海，应该如何处理？如果老人是在转述别人的话，是否应该写入自己的家庭档案？如果语音把名字识别错了，又怎样纠正？ 这些问题说明，记忆更新需要比“让模型写文件”更具体的约束。 如果由我继续做原型，我会在原方案上补一层：让模型先提交待新增或修改的信息，由应用检查后再写入。涉及身份、关系、号码等容易产生后续影响的内容，必要时通过一句自然的追问确认。 老人说“刚才记错了”，也应该能触发修正。这样，记忆才有机会成为一套可以持续维护的数据，而不是越积越多、无法纠错的记录。 从技术角度看，这也是我认为“小伴”值得展开的地方：它让上下文选择和记忆维护，都有了一个具体的应用场景。 ## 四、“一大一小”的功能安排，范围控制得不错 原文把核心功能概括为“一大一小”：大功能是带记忆的陪伴聊天，小功能是语音通讯录。 我认可这个安排。项目的主线很明确，通讯录又能复用聊天时建立的家庭关系信息，两个功能之间有联系。 比如老人说： > 帮我打给丽华。 这句话交给应用以后，需要完成的事情包括：识别拨号意图、查找联系人、判断名字和号码是否明确，然后确认对象并交给手机执行。如果有两个同名联系人，或者一个人有多个号码，就需要继续询问。 这里要划清模型与应用的职责。模型可以帮助理解表达、识别意图，但执行拨号时，应由应用从已经确认的联系人数据中取得号码，并完成必要的校验。 这就把自然语言理解接到了一个具体操作上。技术读者能看到，做一个语音功能，除了回答得通顺，还要处理数据查询、歧义和执行条件。 语音体验本身也需要认真设计。按住说话还是点击开始，用户怎样知道应用正在听，识别失败后怎么重试，播报时能不能打断，这些都值得通过原型观察。 对于这个项目，我会优先把一次完整交互做顺：老人能够开口，系统能够理解，失败时能够恢复，最后得到可预期的结果。 ## 五、“买密钥给老人用”，也是一个值得保留的亮点 我最初看这份文档时，就很喜欢这个想法：子女负责购买和配置 AI 服务，老人直接使用。 从技术交付的角度看，它明确了两类不同的使用需求。 子女需要配置模型、填写服务信息、管理费用；老人需要的是一个可以直接开口的界面。应用可以分别设计这两部分，把复杂设置集中到配置环节。 这也意味着，给老人用的 AI 应用，设计工作不能停在把字体和按钮放大。首次配置、后续维护、服务失效时如何处理，都要有人承担，界面也要相应安排好。 原方案还设想用一个口令完成配置。这个方向可以继续研究，但具体如何生成、导入和保护配置，需要另外设计。原文提到的 TRAE 套餐和额度联动，在这篇文章里也只作为当时的方案设想，不能据此认为平台已经提供了这些能力。 我更看重其中可以保留下来的思路：**把付费、配置与日常使用分别安排给合适的人，让老人获得一个尽量简单的入口。** ## 六、这份方案为什么让我觉得 TRAE 做得不错 把前面几个部分连起来，就能看出我认可这份输出的原因。 它从旧手机这一设备约束出发，提出端侧交互与云端模型的分工；围绕长期聊天的需求，设计分层记忆、按需加载和对话后更新；又把联系人信息与语音操作连在一起，最后考虑由谁配置、由谁使用。 需求、功能和架构之间，已经建立起了联系。 这让后续工作有了比较具体的起点。我们可以开始讨论：话题路由怎么做，记忆更新如何校验，语音流程先验证哪一段，而不用一直停留在“做个老人陪伴 App”的概念上。 与此同时，重新审视也能发现需要修正的地方。比如原文一边写“个人数据不上传云端”，一边又把相关记忆和对话组装后发送给云端模型，这两种说法存在冲突。 准确的表述应该是：记忆文件保存在本地，调用云端模型时，仍然会发送本轮所需的对话和相关记忆。语音处理是否涉及联网，也需要根据具体采用的服务确认。 费用同样需要测量。对话生成之外，记忆判断、上下文长度和语音方案都可能影响成本，不能直接把方案里的“每月几十块”当成已经验证过的结论。 这些修订也正是从方案走向开发的过程。TRAE 帮我梳理出的这份文档，已经提供了值得进一步推敲的结构和细节；接下来需要做的，是用实际结果检验其中的判断。 如果继续推进“小伴”，我会先做一个最小原型：在一台具体的旧手机上，跑通语音输入、带记忆的对话和语音播报，再验证一条信息能否被正确记住、更新，并在下一次聊天中取用。 等这条流程能够稳定运行，再接上语音通讯录，观察老人能不能独立完成一次通话操作。 这也是我重新翻出这份方案后，仍然觉得它不错的原因：它给出了一个我愿意继续做下去、也知道该从哪里开始验证的方向。 --- ## 附录：小伴项目设计方案（公开整理版） > 以下根据当时使用 TRAE 梳理的 Markdown 方案整理，保留主要设计与文档结构，删去比赛排期、平台商业联动设想及宣传性表述，修正数据流与隐私说明，并补充必要的执行确认要求。它是一份待验证的项目方案，文中的功能均为设计目标。 ### 1. 产品概述 **产品名称：** 小伴。 **一句话定位：** 将闲置的旧 Android 手机改造成老人专属的 AI 陪伴终端，以语音交互和长期记忆提供个性化聊天，并支持语音查找联系人、发起通话。 **产品形态：** Android 原生 App，优先考虑旧设备上的轻量运行与简单操作。 **目标用户：** 老人为日常使用者；子女为服务购买者、设备配置者和维护者。 **典型场景：** 子女在旧手机上安装 App 并完成配置，老人通过语音聊天逐步建立个人档案；后续聊天按需取用相关记忆，需要联系家人时可以直接说出称呼或名字。 ### 2. 核心功能：一大一小 #### 2.1 大功能：带长期记忆的陪伴聊天 **自然对话建档。** 通过聊天逐步了解基本信息、家庭关系、兴趣爱好与生活习惯，允许跳过不愿回答的问题，不要求首次使用就填写完整档案。 **个性化对话。** 根据当前话题读取相关记忆，使前后对话能够衔接。 **记忆自动维护。** 每轮对话后判断是否存在需要新增或修改的信息，避免把所有聊天内容直接当作长期事实。 **交流节奏。** 默认由老人发起交流；主动提醒作为可选能力，具体触发方式另行设计。 #### 2.2 小功能：语音通讯录 - 通过对话记录联系人姓名、称呼、关系与号码。 - 支持“帮我打给女儿”等表达，将称呼映射到已确认的联系人。 - 遇到重名或多个号码时，先询问，再确定通话对象。 - 修改号码时确认新信息，避免继续使用旧号码。 - 由应用查询、校验联系人并执行拨号，执行前确认对象；不使用模型临时生成的号码。 ### 3. 本地记忆系统 #### 3.1 文件组织 记忆采用 Markdown 文件保存。以下为逻辑目录示意，实际存储位置在开发时确定。 ```text memory/ ├── Agent.md # 身份设定与交流方式 ├── memory.md # 核心档案 ├── rules.md # 行为规则与用户禁忌 ├── memory-health.md # 用户愿意保留的健康相关信息 ├── memory-food.md # 饮食偏好 ├── memory-family.md # 家庭关系 ├── memory-hobby.md # 兴趣爱好 ├── memory-life.md # 生活经历 ├── contacts.md # 联系人及关系 └── logs/ └── YYYY-MM-DD.md # 当日对话记录 ``` 健康信息和联系人等敏感内容仅在用户愿意保留时记录；公开文档不包含任何真实个人档案。 #### 3.2 加载策略 - **固定加载：** `Agent.md`、`memory.md`、`rules.md`，组成对话基础。 - **按需加载：** 根据当前话题选择相关主题记忆；一次对话可以涉及多个主题。 - **联系人加载：** 涉及联系人查找或拨号时，由应用读取必要信息。 - **近期上下文：** 根据本轮需要选择近期对话，不默认加载全部历史日志。 目标是控制输入规模，使模型获得与当前问题相关的信息。主题识别、漏检处理及输入长度上限需要在原型阶段验证。 #### 3.3 更新策略 每轮对话后进行记忆判断： ```text 本轮对话 → 识别是否有值得长期保留的信息 → 与已有记忆核对 → 判断新增、修改，或仅保留日志 → 必要时向用户确认 → 更新对应主题文件 ``` 对话日志与长期记忆分开管理。原方案设想日志保留最近七天，长期档案独立维护；实际保留范围与清理方式需要进一步确定。 ### 4. 技术架构与处理流程 **总体方案：** 手机端 App + 本地记忆 + 云端大模型服务。 **手机端职责：** 界面、语音输入输出、记忆存取、话题选择、上下文组装、联系人查询与设备操作。 **云端模型职责：** 对话生成与记忆信息识别；模型输出经应用处理后用于播报或记忆更新。 一次对话的主要流程： ```text 语音输入 → 语音识别 → 话题判断与记忆选择 → 组装上下文 → 请求云端模型 → 接收回答 → 语音播报 本轮对话 → 记忆判断与确认 → 本地记忆更新 ``` **上下文组成：** 身份设定 + 核心档案 + 行为规则 + 相关主题记忆 + 必要的近期对话 + 当前输入。 语音识别与合成优先评估设备可用能力，是否联网、语言支持和实际质量以选定设备与服务的测试结果为准。目标 Android 版本与具体设备范围也应通过测试确定。 ### 5. 服务配置与数据边界 **配置方式：** 子女在设置中填写模型服务地址、模型名称和个人服务凭据，完成连接验证后交给老人使用。 **简化配置：** 可以研究配置导入或口令方式，但凭据保护、传递与失效机制需要单独设计，不能把“粘贴字符串”直接等同于安全、零门槛。 **付费与维护：** 子女负责开通个人使用的模型服务、管理费用及处理配置失效；老人侧尽量保留简单的日常操作入口。 **本地与云端的边界：** 记忆文件保存在设备上；调用云端模型时，会发送本轮所需的对话与相关记忆。因此，本地保存不意味着个人信息完全不离开设备。 公开文档只说明配置字段与处理流程，不提供可用的服务凭据、配置口令、真实联系人或私人对话。实际应用还需设计凭据保护、记忆查看、纠错、删除及日志清理等能力。 ### 6. 面向老人的交互设计 - 大字体、大按钮、语音优先，减少日常操作步骤。 - 清楚呈现正在听、正在处理、正在播报和失败等状态。 - 对识别不清、联系人歧义等情况提供简短追问。 - 网络或服务不可用时给出明确反馈和重试入口。 - 将配置维护与日常使用界面分开，避免老人反复处理技术设置。 ### 7. 原型开发与验证顺序 **第一阶段：** 在一台旧手机上打通语音输入、模型调用与语音播报，记录响应时间并检查异常恢复。 **第二阶段：** 实现核心档案、主题记忆、按需加载和对话后更新，检查跨次对话能否正确取用信息。 **第三阶段：** 接入语音通讯录，验证联系人匹配、歧义澄清、号码修改与拨号确认。 **第四阶段：** 邀请目标用户试用，评估能否独立操作，再决定配置导入、提醒等后续功能的优先级。 原型重点回答四个问题：交互是否顺畅，记忆是否准确，操作是否可预期，持续使用的费用是否可接受。 --- > 作者: [RoverTang](https://rovertang.com) > URL: https://rovertang.com/ai/old-phone-ai-companion-trae-plan/