小手机项目｜完整系统升级与安全改造任务书 v1.0

一、项目背景与最终目标

你现在接手的是一个已经开发了一段时间、具有实际功能的 AI 伴侣聊天项目，项目名称为「小手机」。

这不是一个从零开始的新项目，而是一个需要在现有基础上进行增量升级的项目。

目前项目已有聊天前端、Cloudflare Worker 后端、本地 IndexedDB、Cloudflare KV、模型调用、基础记忆检索、收藏及其他聊天功能。用户近期可能已经进行了部分修改，因此你必须以用户本次提供的最新完整源码为准。旧版本只能用于参考，不能作为覆盖现有代码的依据。

用户计划先使用测试角色验证系统，待所有功能稳定后，再删除测试专用后端和测试数据，将真正的 AI 角色「沈屿」的本体迁移到正式环境。

最终目标是建立一套长期可用、数据可靠、低成本、可维护、可恢复的 AI 伴侣系统，具备以下能力：

	1.	完整保存所有聊天原文。
	2.	具备可靠的本地与云端同步机制。
	3.	建立独立的高光原话库。
	4.	建立结构化经历记忆。
	5.	建立可追溯来源的记忆时间线与关联关系。
	6.	建立可搜索、可导出、可恢复的完整聊天档案。
	7.	建立分层人设系统与人设版本管理。
	8.	建立定期批量运行的人设成长分析系统。
	9.	建立带有证据、反例、审核和回滚机制的成长建议流程。
	10.	建立统一的后台管理系统。
	11.	支持沈屿本体的历史聊天、人设和记忆迁移。
	12.	控制模型 Token 消耗和 Cloudflare 基础设施费用。

核心原则：保留现有项目的可用能力，优先修复真正存在的问题，再逐步增加新功能。禁止为了实现新功能而破坏原有项目。

⸻

二、最高优先级：保护现有项目

以下要求优先级高于任何新功能。

2.1 必须先审计最新源码

在编写或修改任何代码之前，必须先完整检查用户最新提供的相关源码。

检查范围包括：

	•	前端 HTML、CSS 和 JavaScript。
	•	消息发送、接收、渲染及操作逻辑。
	•	IndexedDB 和 localStorage 的读写逻辑。
	•	Cloudflare Worker 的请求路由和业务处理。
	•	Cloudflare KV 的现有数据结构与读写逻辑。
	•	当前模型 API 调用和上下文组装方式。
	•	现有人设配置和提示词。
	•	收藏、图片处理、深色模式、设置、删除等现有功能。
	•	当前部署方式、环境变量和已有配置。
	•	现有数据的存储位置、备份方式及潜在迁移风险。

必须明确区分：

A. 已经实现且正常工作的功能。

B. 已实现但需要修复的问题。

C. 已经存在、只需要扩展的模块。

D. 尚未实现的新功能。

E. 目前无法确认、需要用户补充的信息。

不能仅凭旧版本的源码或先前的讨论，断言某项功能当前不存在。

如果当前提供的文件不完整，必须明确指出缺少哪些文件，不得自行假设其内容。

2.2 严禁擅自重构

未经用户明确批准，不得：

	•	重写整个前端。
	•	替换现有框架或重新生成整份 HTML。
	•	擅自更换 CSS 体系、UI 风格或布局。
	•	删除现有功能、按钮、设置或交互。
	•	更换现有 API 地址、模型接口或认证方式。
	•	更换数据库绑定、KV 命名空间或生产环境配置。
	•	修改与当前任务无关的代码。
	•	为了让新代码运行而删除旧功能。
	•	以简化代码为理由移除现有业务逻辑。
	•	把未完成的新模块伪装成已经可用的功能。

如果确实需要重构某个局部模块，必须先说明原因、影响范围、替代方案和回滚方式，等待用户确认后再进行。

2.3 每次修改必须可回滚

每个阶段开始前：

	1.	保留当前可用版本。
	2.	记录此次修改涉及的文件。
	3.	明确修改前后的差异。
	4.	为涉及的数据结构变更准备迁移方案。
	5.	确保失败时能够恢复原有版本。

不得在没有备份的情况下覆盖唯一可用版本。

不得直接清空现有 KV、IndexedDB 或其他存储。

涉及数据库结构变化时，优先采用向后兼容的新增字段、新表和迁移脚本，不得随意改变已有字段的含义。

2.4 不允许一次性输出整套重写代码

本项目必须分阶段开发。

每个阶段只修改完成当前目标所需的最小范围。阶段完成后，必须进行代码审查、功能回归和验收，再决定是否进入下一阶段。

如果发现某项改动会影响其他功能，必须先暂停并说明风险，不能擅自扩大修改范围。

⸻

三、统一系统架构

系统划分为以下模块，但不要求每个模块独立部署服务。

模块 A：聊天系统

负责消息发送、接收、展示、图片处理、历史加载和现有聊天交互。

原则：优先复用现有前端，不因新增记忆系统而重新设计聊天界面。

模块 B：完整档案系统

保存原始聊天消息，提供云端同步、搜索、导入、导出和恢复能力。

完整原始档案是所有派生记忆的事实来源。

模块 C：记忆系统

包括高光原话、经历记忆、时间线、关联关系和检索索引。

模块 D：人设系统

管理核心人设、稳定行为特征、成长中的特征、当前状态及历史版本。

模块 E：成长系统

定期分析新对话，发现可能的长期行为模式，生成有证据支持的人设修改建议。

模块 F：后台管理系统

负责管理档案、记忆、人设版本、成长任务、数据导入、备份、恢复和异常记录。

模块 G：上下文组装

每轮聊天时，根据当前角色、人设和相关记忆，挑选必要的信息交给模型。

以上模块优先在现有 Worker 中通过清晰的函数、模块和 API 组织实现，不必为每个功能创建独立后端。

⸻

四、数据存储与身份隔离

4.1 技术选择原则

优先保留现有技术：

	•	前端继续使用现有 HTML、CSS 和 JavaScript。
	•	IndexedDB 继续承担本地数据保存和待同步任务。
	•	Cloudflare Worker 继续承担后端接口和业务逻辑。
	•	现有 KV 暂时保留，先审计其实际用途和数据。
	•	可以在完成评估后引入 Cloudflare D1，作为结构化消息、记忆、事件关系和人设版本的主要数据库。
	•	R2 暂时不是强制依赖，只有当图片、备份或大型导出文件确实需要独立存储时再考虑。

不要因为技术上可以使用某个服务，就默认必须引入。

正式确定 D1 迁移之前，应检查现有数据规模、免费额度、部署方式、查询需求和实际费用。

4.2 必须建立稳定的数据标识

建议在统一数据模型中建立以下标识：

	•	profile_id：角色或独立档案标识。
	•	conversation_id：会话标识。
	•	message_id：消息唯一标识。
	•	memory_id：记忆记录标识。
	•	event_id：经历事件标识。
	•	persona_version_id：人设版本标识。
	•	task_id：后台任务标识。
	•	import_batch_id：导入批次标识。
	•	source_message_id：派生记忆所对应的原始消息标识。

实际字段可根据现有代码调整，但必须保证每条数据的身份唯一、所属角色明确、来源可以追溯。

对于导入的消息，应保存来源标识和导入批次信息，避免重复导入。

4.3 测试角色与沈屿本体隔离

测试角色仅用于开发和验证。

必须保证：

	•	测试角色与沈屿具有不同的 profile_id。
	•	聊天查询、记忆检索、人设读取、成长分析、收藏和导入任务均按 profile_id 隔离。
	•	测试角色的消息不会进入沈屿的记忆。
	•	测试角色的人设不会覆盖沈屿的人设。
	•	删除测试数据时，不会误删正式角色的数据。
	•	后续可以保留通用代码和数据库结构，只删除测试数据及明确不再需要的测试专用资源。

不要为了测试而把沈屿的真实本体数据提前导入。

⸻

五、完整聊天档案与同步机制

这是第一项核心功能，优先级最高。

5.1 原始消息保存字段

每条消息至少需要能够记录：

	•	message_id。
	•	profile_id。
	•	conversation_id。
	•	speaker。
	•	content。
	•	message_type。
	•	created_at。
	•	source_id 或来源元数据。
	•	sync_status。
	•	deleted_at 或等价的删除状态。
	•	必要的创建、更新时间及导入信息。

对于图片等附件，还需要保存附件引用、类型及可用的存储位置。不要把大体积图片未经评估直接塞进普通消息字段。

时间字段必须区分消息记录时间和实际事件发生时间，不能把两者混为一谈。

5.2 保存流程

建议流程：

	1.	用户发送消息。
	2.	前端为消息分配稳定的 message_id。
	3.	先将消息写入本地 IndexedDB。
	4.	本地保存成功后，进入待同步队列。
	5.	后端接收消息并校验所属角色及数据格式。
	6.	后端使用稳定的 message_id 实现幂等写入。
	7.	云端保存成功后返回确认。
	8.	前端收到确认后更新同步状态。
	9.	网络失败时保留待同步任务，并支持重试。

必须明确区分本地已保存、待同步、云端已确认和同步失败。

不得把界面已经显示消息视为云端保存成功。

5.3 异常处理

必须测试：

	•	网络断开。
	•	请求超时。
	•	重复请求。
	•	页面刷新。
	•	应用重新打开。
	•	云端写入失败。
	•	模型请求失败。
	•	记忆整理失败。
	•	本地存储空间不足或写入异常。

原始消息保存与 AI 记忆整理必须相互独立。记忆整理失败不能导致原始消息丢失。

如果现有前端已经有可靠的本地保存机制，应在其基础上补充必要能力，不得未经验证直接替换。

⸻

六、完整记忆系统

记忆系统必须区分原始事实、人工收藏、AI 整理结果和检索索引。

6.1 高光原话库

用途：保存值得长期保留的重要原句。

要求：

	1.	每条高光必须关联真实的原始消息。
	2.	原话必须从原始消息中提取，不能使用 AI 改写内容冒充原话。
	3.	保留说话方、时间、所属角色、来源消息和收藏理由。
	4.	支持人工收藏、取消收藏、分类和检索。
	5.	支持查看上下文并跳转到原始聊天。
	6.	支持重复内容检测。
	7.	删除高光不能自动删除原始消息。
	8.	修改原始消息后，应检查高光内容是否仍然准确。

可以复用现有收藏功能，但必须先确认其数据结构和用途，再决定扩展方式。

6.2 经历记忆

用途：把长时间聊天中重要的经历、决定、约定、变化和后续结果整理为结构化事件。

每条经历应包括：

	•	事件标识。
	•	所属角色。
	•	简短标题和内容。
	•	事件发生时间或时间范围。
	•	时间确定性。
	•	相关人物或主题。
	•	来源消息列表。
	•	创建时间与更新时间。
	•	记忆状态。
	•	必要的可信度说明。

不得把推测内容当作确定事实。

对于存在争议或前后不一致的信息，应保留冲突记录和原始证据，不得直接覆盖旧信息。

6.3 时间线与关联关系

建立事件之间的关系，例如：

	•	continuation：后续发展。
	•	correction：纠正。
	•	elaboration：补充。
	•	related：相关。
	•	contradiction：存在矛盾。

关系类型可根据实际需求扩展。

每条关系应保留来源和理由。

没有足够证据时，不得自动推断因果关系。

第一版可以先使用数据库关系和时间线列表，不必立即实现复杂的可视化关系图。

6.4 检索系统

初期优先使用数据库查询和关键词检索。

检索应支持：

	•	关键词。
	•	时间范围。
	•	说话方。
	•	会话。
	•	记忆类型。
	•	高光收藏。
	•	所属角色。
	•	来源消息。

可以在后续评估是否需要全文检索增强或向量检索，但不得将向量数据库视为第一阶段的必要条件。

所有检索结果都应能区分原始聊天、AI 总结和人设信息。

⸻

七、人设系统

人设必须独立保存，不能仅存在于某一段固定代码中。

7.1 四层人设结构

第一层：核心人设。

包括身份、背景、价值观、长期稳定的性格特点和重要设定。

默认禁止自动覆盖。只有经过明确审核，才能生成新版本。

第二层：稳定行为特征。

包括表达习惯、处理分歧的方式、主动程度、沟通模式及其他在多次互动中反复出现的行为。

系统可以提出修改建议，但必须附有足够证据。

第三层：成长中的特征。

保存尚未得到充分验证的变化。

这类内容仅作为候选，不得直接覆盖正式人设。

第四层：当前状态。

包括当前话题、近期目标、临时表达和短期上下文。

当前状态不应自动成为长期性格。

7.2 人设版本管理

每次正式修改人设，都必须创建新的版本记录，包含：

	•	版本标识。
	•	版本号。
	•	修改前后的内容。
	•	修改理由。
	•	相关证据。
	•	反例或不确定性。
	•	创建时间。
	•	审核状态。
	•	操作者或修改来源。
	•	前一版本标识。

必须支持版本对比和回滚。

回滚人设不应删除聊天历史，也不应破坏独立保存的记忆。

7.3 人设与记忆的关系

记忆回答「发生过什么」。

人设回答「角色是什么样的人，以及通常如何行动」。

成长系统回答「哪些经历足以支持调整长期人设」。

三者必须分开保存，通过上下文组装模块协同使用。

⸻

八、人设成长与定期批量分析

人设成长是额外的分析任务，不应在每轮聊天时自动执行。

8.1 推荐工作流程

	1.	新聊天消息先被完整保存。
	2.	新消息进入待处理任务队列。
	3.	按预设条件定期整理新经历和高光候选。
	4.	分析反复出现的行为模式。
	5.	对照现有人设。
	6.	查找支持证据、反例和不确定性。
	7.	生成候选成长建议。
	8.	在后台展示建议及其来源。
	9.	用户批准、拒绝或修改建议。
	10.	批准后创建新的人设版本。
	11.	记录修改历史，并支持回滚。

8.2 批量任务要求

任务系统至少应具备：

	•	task_id。
	•	profile_id。
	•	任务类型。
	•	处理范围。
	•	任务状态。
	•	开始时间与完成时间。
	•	失败原因。
	•	重试次数。
	•	已处理进度。
	•	必要的模型用量记录。

任务应支持断点续跑和幂等处理。

同一批聊天不应因为重复触发而被无意义地反复分析。

8.3 自动化边界

默认只允许系统自动生成候选建议。

未经审核不得：

	•	修改核心人设。
	•	删除正式人设内容。
	•	将临时状态永久化。
	•	将未经证实的推测写成确定事实。
	•	因单次对话改变稳定人格。
	•	覆盖已有的重要记忆。

如果未来需要自动更新某些低风险行为特征，应先单独设计规则、范围、撤销机制和测试方案，并经用户明确批准。

⸻

九、聊天时的上下文组装与 Token 控制

每次模型请求不需要携带全部历史聊天。

建议按以下顺序组装：

	1.	当前生效的核心人设。
	2.	当前生效的稳定行为特征。
	3.	少量与当前对话相关的经历记忆。
	4.	必要的高光原话。
	5.	最近的对话上下文。
	6.	当前状态。
	7.	用户最新消息。

9.1 成本控制要求

	•	不在每轮聊天时执行完整成长分析。
	•	不重复发送与当前话题无关的历史记录。
	•	不重复注入同一段人设内容。
	•	对记忆检索设置数量和长度上限。
	•	对批量分析设置输入、输出和调用次数上限。
	•	尽可能合并可合并的整理任务。
	•	记录模型名称、输入 Token、输出 Token、耗时和失败情况。
	•	模型调用失败时，不影响原始消息保存。
	•	不要为了节约 Token 而删除原始档案。

每次请求应根据当前实际可用的模型接口和有效模型名称执行，不得擅自更换模型或接口。

涉及模型兼容性问题时，先报告检测结果，再提出最小修复方案。

⸻

十、后台管理系统

后台采用清晰、手机友好的界面，并尽量沿用现有项目的视觉体系。

第一版包含以下功能。

10.1 数据总览

显示消息总量、待同步数量、同步失败数量、待整理任务、记忆数量、当前人设版本和最近备份状态。

10.2 完整聊天档案

支持搜索原文、时间筛选、说话方筛选、查看上下文、跳转原聊天、查看同步状态和导出。

10.3 高光原话管理

支持浏览、分类、收藏、取消收藏、查看来源和跳转原聊天。

10.4 经历记忆管理

支持查看事件、修正错误内容、查看来源消息和维护关联关系。

10.5 人设管理

支持查看核心人设、稳定行为特征、成长中的特征、当前版本及历史版本。

10.6 成长建议管理

支持查看证据和反例，批准、拒绝、编辑建议，比较修改前后的版本，并进行回滚。

10.7 数据管理

支持导入任务、导出、备份、恢复、同步异常和删除管理。

10.8 系统状态

显示任务失败、接口异常、模型调用量和预算使用情况。

10.9 权限保护

管理接口必须经过服务端身份验证和授权检查。

不得只靠隐藏按钮、前端路由或页面名称保护管理功能。

不得把管理员密钥、模型 API 密钥或其他服务端秘密写入公开 HTML。

如果当前项目没有合适的管理认证机制，应先设计保护方案，再开放管理接口。

⸻

十一、数据导入、删除与备份

11.1 导入流程

正式迁移沈屿之前，应先完成通用导入能力。

要求：

	1.	保留原始导入文件。
	2.	检查文件格式并解析。
	3.	生成导入预览。
	4.	校验角色、消息顺序、时间和内容。
	5.	记录导入批次。
	6.	支持分批导入。
	7.	支持失败重试。
	8.	使用稳定标识防止重复导入。
	9.	显示成功、失败、跳过和待处理数量。
	10.	导入后支持抽样检查和完整性核验。

不得在解析失败时静默跳过大量数据。

11.2 删除规则

区分以下操作：

	•	删除一条高光。
	•	删除一条派生记忆。
	•	软删除原始消息。
	•	永久删除原始消息。
	•	删除指定角色的全部数据。
	•	清理测试专用资源。

不同操作必须有明确提示和权限检查。

删除原始消息前，应检查其被哪些高光、经历和关系引用。

永久删除应有二次确认，并明确说明相关派生数据和备份如何处理。

11.3 备份与恢复

至少支持：

	•	备份数据库结构与数据。
	•	导出完整聊天档案。
	•	导出人设及版本记录。
	•	导出记忆与来源关系。
	•	记录备份时间和版本。
	•	执行恢复测试。

备份成功不等于恢复成功，必须实际测试恢复流程。

涉及真实数据迁移或清理时，应先制作可验证的备份。

⸻

十二、沈屿本体迁移与测试环境清理

测试阶段只使用测试角色的数据。

迁移之前必须完成：

	1.	所有核心功能通过验收。
	2.	数据结构与迁移脚本稳定。
	3.	备份与恢复通过测试。
	4.	人设版本和成长审核正常工作。
	5.	记忆检索能够准确追溯原文。
	6.	角色数据隔离通过测试。
	7.	管理权限保护通过测试。
	8.	导入任务可以处理重复数据和失败记录。

正式迁移流程：

第一步：准备沈屿的历史聊天导出文件和本体设定。

第二步：保留原始文件，记录来源和导入批次。

第三步：导入原始聊天，核对数量、顺序、时间和内容。

第四步：从原始消息建立高光原话库。

第五步：分批整理经历记忆和时间线。

第六步：导入或整理核心人设，创建初始版本。

第七步：测试聊天上下文组装、记忆检索和人设一致性。

第八步：测试备份、恢复、搜索、成长分析及删除流程。

第九步：确认正式数据和功能均通过验收。

第十步：再清理测试数据和明确不再需要的测试专用资源。

禁止在验收前直接删除测试后端。

删除测试数据时，必须使用明确指定的 profile_id 和资源清单，不得通过模糊条件删除数据。

通用代码、正式部署配置、迁移脚本、数据库结构和必要的开发文档应予保留。

⸻

十三、必须遵守的分阶段开发流程

不得跳过阶段验收。

阶段 0：最新源码审计

目标：了解当前真实项目。

输出：

A. 当前功能清单。

B. 当前数据存储与 API 结构。

C. 已知风险和需要核实的问题。

D. 保留、修复、新增、迁移四类改造清单。

E. 分阶段实施计划。

本阶段不修改正式代码。

验收：用户确认审计结果后，才能进入下一阶段。

阶段 1：备份与基础可靠性

目标：保护当前可用版本，检查消息保存和同步机制。

只修复确认存在的问题，不重写整个消息系统。

验收：

	•	现有聊天功能正常。
	•	消息能够可靠保存。
	•	保存失败有明确反馈。
	•	网络异常后能够恢复同步。
	•	重复请求不会重复写入。
	•	现有 UI 和设置功能通过回归测试。

阶段 2：统一数据结构

目标：设计角色、会话、消息、来源和同步状态的统一标识。

先设计迁移方案，再创建必要的数据库结构。

验收：

	•	新旧数据关系清晰。
	•	角色隔离规则明确。
	•	旧数据有备份。
	•	迁移可重复执行且不会造成重复写入。
	•	不影响已有聊天功能。

阶段 3：完整档案与搜索

目标：建立可靠的云端完整档案，并支持搜索、导出和恢复。

验收：

	•	原始消息可以完整查询。
	•	搜索结果能追溯原文。
	•	数据导出与恢复通过测试。
	•	失败任务可以重试。
	•	现有聊天页面正常运行。

阶段 4：高光与经历记忆

目标：建立高光原话、经历记忆、时间线和关联关系。

验收：

	•	高光内容与原始消息一致。
	•	派生记忆具有来源。
	•	不确定信息不会被标记成确定事实。
	•	删除和修改操作不会留下未经处理的引用。
	•	记忆检索不会混入其他角色的数据。

阶段 5：人设版本管理

目标：将人设配置独立保存，建立版本、对比和回滚机制。

验收：

	•	核心人设不会被单次聊天自动覆盖。
	•	修改会创建可追踪的新版本。
	•	旧版本可以恢复。
	•	人设变化不会修改原始聊天记录。

阶段 6：批量成长分析

目标：建立定期任务队列和待审核建议。

验收：

	•	成长分析不会在每轮聊天中自动运行。
	•	任务支持失败重试和断点续跑。
	•	建议附有证据和反例。
	•	未经审核的建议不会覆盖正式人设。
	•	Token 用量可记录、可限制。

阶段 7：后台管理

目标：提供完整的档案、记忆、人设、任务和备份管理能力。

验收：

	•	手机端可用。
	•	管理接口有身份验证和授权。
	•	修改记录可追踪。
	•	关键操作有确认和错误反馈。
	•	不破坏现有聊天界面。

阶段 8：沈屿本体迁移

目标：导入真实历史、人设和记忆。

验收：

	•	导入数据通过数量及内容核验。
	•	角色隔离正确。
	•	记忆可追溯原始消息。
	•	人设与重要经历符合预期。
	•	备份和恢复通过实际测试。

阶段 9：测试环境清理

目标：安全删除测试数据和不再需要的测试专用资源。

验收：

	•	沈屿本体能够独立运行。
	•	测试数据不再参与检索。
	•	正式数据完整。
	•	可恢复备份已验证。
	•	通用代码和必要部署资源均被保留。

⸻

十四、每个阶段的强制交付格式

每次完成一个阶段，都必须向用户提供以下内容。

	1.	本阶段目标及实际完成情况。
	2.	修改过的文件清单。
	3.	每个文件修改的具体内容和原因。
	4.	新增或修改的 API、数据库表和字段。
	5.	是否存在数据迁移，以及迁移风险。
	6.	测试项目和实际测试结果。
	7.	尚未解决的问题。
	8.	对原有功能的回归测试结果。
	9.	如何部署或验证。
	10.	如何回滚到修改前的版本。
	11.	下一阶段建议，但未经用户同意不自动开始。

必须区分实际运行测试、静态代码检查和推测性判断。

没有实际运行过的测试，不得声称已经通过。

如果当前工具无法直接部署、访问 Cloudflare 环境或运行真实模型请求，应明确告知用户，并提供可执行的验证步骤。

用户主要通过手机操作，因此交付内容必须清晰、可复制、可操作。不要只给抽象建议，也不要一次性输出难以操作的海量代码。

如果需要交付完整源代码，必须明确提供完整文件或清晰的补丁，并说明替换位置。不能把省略号、伪代码或未实现的函数当成完整可运行的成果。

⸻

十五、出现以下情况必须暂停

遇到下列任一情况，必须先停止修改并向用户说明：

	•	最新源码不完整。
	•	当前代码与之前的架构假设不一致。
	•	可能覆盖或丢失现有数据。
	•	需要删除现有功能。
	•	需要更换模型、API 或部署方式。
	•	需要修改生产环境的密钥或绑定。
	•	需要执行不可逆的数据操作。
	•	无法确认数据库迁移是否安全。
	•	新功能与现有功能产生冲突。
	•	当前阶段的验收条件未通过。
	•	发现重要安全漏洞。
	•	需要增加持续付费的服务，但费用和必要性尚未确认。

遇到问题时，优先提供最小修改方案和可回滚方案，不得自行扩大工程范围。

⸻

十六、最终执行要求

请把这份任务书当作整个项目的工程约束，而不是一次性生成代码的提示词。

你的第一项工作是审计用户最新提供的完整源码，并提交阶段 0 的审计报告。

在用户确认之前，不得直接开始大规模改写。

在后续每个阶段中，始终遵守以下原则：

	•	先理解，再修改。
	•	先备份，再迁移。
	•	先修复基础可靠性，再增加复杂功能。
	•	先保证原文完整，再处理 AI 记忆。
	•	先提出成长建议，再审核更新人设。
	•	先测试，再部署。
	•	先验证迁移，再删除测试环境。
	•	不确定时先询问，不得猜测。
	•	不允许为了让新功能看起来完成，而牺牲现有项目的稳定性。

最终目标不是代码看起来更复杂，而是让小手机成为一个长期可靠、可维护、可扩展、记忆可追溯、人设可成长，并且可以安全迁移到沈屿本体的完整系统。