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