企业官网建设流程全解析

那晚我合上电脑，准备睡觉，脑子里却还在反复调度白天没处理完的琐事，像一台关不掉电源的机器，所有后台进程都在抢占最后一丝注意力。我当时想了一个问题：我们天天谈论操作系统，说它管理 CPU、内存、进程，可我们自己脑子里那一堆想法、情绪、念头，谁来管？市面上有那么多日历软件、待办清单、冥想 App，但没有一个东西，真正站在“系统层”去管理一个人的内心运行状态。就是那一刻，我萌生了“山水观心操作系统（Shanshui-guanxin）”这个概念——一套面向心智状态的运行环境，用东方美学里的山水意象做界面，用操作系统的思路来做心境管理。

这篇文章是完整的设计与工程实践记录。我会把这套系统的定义、架构、核心模块、技术选型，以及我在原型迭代中踩过的坑全部摊开来讲。如果你正打算做一款冥想类、心境记录类、或者偏东方美学的数字产品，这篇文章应该能帮你少走不少弯路。

1. 山水观心操作系统到底是什么？先把这个概念说清楚

1.1 名字拆解：山水是界面语言，观心是核心逻辑

“山水观心”这四个字，不是随便起的。它拆开来看，一半落在东方美学的视觉与意境上，另一半落在内省觉察的功能逻辑上。

先说“山水”。中国山水画里的核心不是“像”，而是“境”。同样是山，可以画得高耸压抑，也可以画得温和绵长；同样是水，可以是急流，也可以是静潭。这种“随心境而变”的表现力，恰好适合做内部状态的映射载体。在设计上，我决定让整个系统的主界面就是一幅动态山水画，但它的明暗、雨雪、水流速度都不是随机生成的，而是由用户当前的心境状态驱动。

再说“观心”。这个词源自传统的观心法门，简单说就是对内心活动的持续觉察——看到情绪起来，看到念头飘过，但不跟随、不评判。现代心理学的“元认知”“情绪标注”（affect labeling）其实和观心是相通的：给情绪命名，本身就能降低情绪强度。把所有“记录情绪”的动作都建立在“观”的框架内，是本系统与普通心情打卡类软件最本质的区别。

1.2 这里的“操作系统”不是比喻，而是一套设计模型

传统计算机操作系统负责管理硬件资源、调度进程、记录日志、处理崩溃与恢复。山水观心操作系统把这套模型搬到人的内在体验层面，它不是比喻，而是一套可执行的设计模型。

我做了下面这个对照表，基本就是整套系统的逻辑底座：

这个模型的价值在于，它把“调节心情”这种模糊的表达，变成了有结构、有接口、可度量的系统设计问题。比如“死机”对应的是情绪过载，那系统要做的恢复机制必须有明确的触发条件和动作序列；“多任务并发”对应的是杂念纷飞，那系统在设计上就应该有“进程列表”一样清晰的念头清单。用操作系统的语言重新框定心境管理，很多原本无从下手的设计决策就有了落脚点。

1.3 它解决的是“状态管理”问题，不只是“情绪记录”问题

市面上已经有很多情绪记录 App 和冥想 App。前者侧重记录，后者侧重练习。但山水观心操作系统想解决的，是一个更上游的问题：状态的持续管理。

什么叫状态管理？举个直白的例子。你打开电脑，真正关心的不是某个 App 好不好用，而是整个系统的进程调度是否顺畅、有没有过热、有没有内存泄漏。同理，一个人一天的状态，也不是由某一个情绪事件决定的，而是由全天注意力的分配、情绪的起伏节律、疲惫积累的水平共同作用的结果。山水观心系统做的是：把过去只停留在“记录情绪”层面的产品，向上提升到“操作系统”层面——关注整体运行状态是否健康，是否有多余的“后台进程”在空转消耗，系统有没有进入过热状态，需不需要清理缓存。

所以它适合的人也很清晰：高强度脑力工作者、长期面对屏幕的开发者与设计师、对自我觉察有兴趣但缺乏持续方法的人，以及想做冥想类、身心健康类产品的产品经理和工程师。你可以不认同它的全部设计，但它提供的问题框架，值得参考。

2. 默认的“人生运行环境”有问题：高负载、多进程、缺恢复机制

2.1 现代人的数字生活是一场持续的系统过载

上桌吃饭，先拍照；通勤路上，刷短视频；工作时，开着十几个标签页，微信消息弹出来就看一眼，看完再切回代码，刚刚想到的思路已经没了。这些场景每个人都经历过，但很少有人把它们放在一起看：它们在客观上构成了一种持续的“系统高负载”状态。

我自己的观察是，现代人的注意力已经不只是被碎片化，而是被系统性地抢占。微信、邮件、钉钉、企业 IM、新闻推送，哪一个都像高优先级进程，随时可以抢占当前任务。真正想专心写一段东西，就得把通知权限全部关掉，可关掉之后又怕错过重要消息。这种矛盾不是靠“自律”能解决的，因为自律本身也在消耗有限的意志力资源。

更麻烦的是，这种高负载状态下，人缺少对自身运行状态的实时感知。电脑发热时风扇会狂转，弹温度警告；人情绪过载时却往往没有清晰的信号，直到晚上失眠、头痛、莫名烦躁才反应过来。山水观心操作系统想做的第一件事，就是把这种“隐形的高负载”变成可见、可读、可回放的信息。

2.2 为什么普通的“心情记录”解决不了问题

现在市面上很多情绪记录 App，设计逻辑是：你不开心了，打开 App，选一个表情，写下原因，打卡完成。这种方式不是没用，但它有几个结构性问题。

第一，它是回溯式的。情绪都已经过载了你才记录，而系统要做的是在情绪发酵过程中就提供觉察入口。第二，它是点状的。记录一个情绪事件，并不等于把全天的状态串起来，时间和触发情境这些关键维度被丢弃了，你无法看到“我每天下午三点之后状态就开始下滑”这种规律。第三，它没有恢复机制。记录完难受的情绪，App 就结束了，不会引导你去做任何调节。相当于一台电脑崩溃了，它只是弹了个错误日志给你看，不给恢复选项。

山水观心操作系统把“记录”放进更大的闭环里：觉察（观）→ 记录（日志）→ 映射（状态可视化）→ 引导（恢复机制）→ 复盘（趋势分析）。记录只是入口，后面的恢复和复盘才是系统真正要做的事。

2.3 用“快照”思维替代“打卡”思维

在系统设计上，我刻意用了“状态快照（snapshot）”来替代“打卡”这个动作。计算机系统的快照记录的是某一时刻的完整状态，而不是单一维度的数值。所以山水观心的观心日志，在设计上不是让用户选一个开心或难过的表情，而是提供一组多维度的记录字段：

• 当前情绪：从觉察到的情绪中选择，可多选
• 情绪强度：三档（微风、中浪、激流），不用十档这种过细的粒度
• 身体感受：哪个部位有紧张/松弛感，给一个简短的文字或语音记录
• 念头类型：回忆过去、担忧未来、自我评判、外界刺激，等等
• 当前情境：在做什么、和谁在一起、身处何种环境

这个设计有一个非常重要的心理学依据：把情绪从“模糊的不适”拆解成“可命名的具体条目”本身，就是一种有效的认知调节。脑科学研究发现，给情绪贴标签（affect labeling）能降低杏仁核的激活水平。也就是说，“观”这个动作本身就是恢复机制的一部分，不是额外负担。

3. 系统架构从零搭建：我做的技术选型和模块划分

3.1 三个设计目标：本地优先、离线可用、跨平台低打扰

很多人一听“操作系统”就想到了 Linux、内核、虚拟化，但山水观心不是那种意义上的系统。它是一套应用层的“状态管理环境”，所以技术选型的核心约束其实来自产品定位。

我的第一个设计目标是本地优先。用户的心境数据极度敏感，情绪日志、念头记录这些内容，如果上传到云端，用户心理上会有天然的不安全感。本地优先（local-first）架构意味着所有数据默认存储在设备本地，用户明确选择之后才考虑同步。这不仅是隐私问题，也是产品定位问题——一个做内观觉察的工具，不该让用户因为担心数据泄露而无法放松地记录。

第二个目标是离线可用。冥想引导和情绪记录经常发生在没有网络的地方，比如公园长椅上、深夜卧室里。如果 App 断网就转圈，那体验会非常糟糕。离线可用同时也意味着更快的启动速度和更稳定的体验。

第三个目标是跨平台低打扰。这个系统的核心理念之一就是降低数字生活的噪音，它自身绝对不能变成一个新的噪音源。所以需要在手机、平板、桌面之间保持体验一致，同时不做推送轰炸。

3.2 技术栈选择：为什么我先走 PWA 原型，再考虑框架落地

技术选型上，我前后对比过几个方案：

我的最终建议是：先用 PWA 把完整闭环跑通，再根据实际使用频率决定要不要落地原生框架。这不是偷懒，而是很现实的考量。山水动态渲染、语音输入、传感器数据接入，这些都有不止一种实现方案，在没想清楚用户真实使用路径之前，投入大量时间做原生应用，很可能做出一堆用户根本不用的功能。

原型阶段我用的技术组合是：React + Vite 做前端，IndexedDB 做本地存储，Service Worker 做离线缓存，Tone.js 做呼吸引导的音频节律。整套东西部署成静态站点后，手机桌面可以“添加到主屏幕”，体验接近原生 App。

3.3 四个核心层级：感知、认知、调度、表达

系统整体分四层设计，每一层只负责一个关注点。

感知层负责获取输入。包括被动感知（从智能手表读取心率、HRV）和主动感知（用户主动记录状态快照、语音输入心情）。被动感知的价值在于“零成本采集”，心率变异性（HRV）是衡量自主神经系统状态的重要指标，连续 HRV 数据能大致反映压力水平的变化趋势。主动感知则是用户有意识、有觉察的记录，它本身就有调节作用。

认知层负责把原始数据加工成有意义的信息。比如把心率数据和用户手动标注的情绪做关联分析，来识别“每当开会后心率会持续偏高”这类模式。这一层也承担语义理解，比如把用户语音记录中的关键词抽取出来，归入念头类型标签。

调度层是整个系统最核心的部分，相当于操作系统的“进程调度器”。它根据感知层和认知层的输出，决定系统当前应该处于什么模式：是保持安静、提示用户做一次呼吸引导，还是建议用户暂停工作、出门散步。调度层真正体现“操作系统”的含义——它管理的是介入时机和介入强度，避免在用户高度专注时强行打断，也避免在用户已经崩溃时才后知后觉。

表达层负责把系统状态呈现给用户。我的设计里，这个表达层就是动态山水画。不同的状态对应不同的山水意象，不是简单的颜色替换，而是整体氛围的迁移。这部分我后面单独展开。

3.4 数据模型：直接决定了这套系统能走多远

数据模型是整套系统里最不能将就的部分，我踩过换模型的坑，所以先把最终沉淀出来的核心结构放在这里。

第一个是 state_snapshot（状态快照），对应一次观心记录。核心字段有：时间戳、地点、当前活动、情绪标签列表、情绪强度、身体感受文本、念头类型、补充备注。它的特点是包含情境信息，这样才能做触发因素分析。

第二个是 guided_session（引导会话），记录一次系统引导的完整过程。核心字段有：引导类型（呼吸、身体扫描、三步呼吸空间）、开始时间、结束时间、完成度、引导前状态快照 ID、引导后状态快照 ID。引导前后各抓一次快照，才能量化引导的效果。

第三个是 ambient_metric（环境指标），存被动数据。核心字段有：时间戳、心率、HRV、步数、屏幕使用时长、设备类型、数据来源。

第四个是 insight（洞察/规律），由系统在复盘时自动生成或用户手动创建。核心字段有：类型、关联的快照ID集合、置信度、描述文本、建议动作。

这套模型最大的特点是把“主观感受数据”和“客观生理/环境数据”分开存储，但通过时间戳对齐可以随时联表分析。这样既保证了记录的自由度，也保留了后期做数据挖掘的可能性。

4. 核心功能模块逐个拆解：哪些必须做，哪些属于加分项

4.1 山水状态面板：如何把内在状态变成可见的风景

山水状态面板是整个系统的门面，也是压力最大的一个模块。它不能只是一个静态好看的 UI，它得让用户一秒钟就看懂自己当前的状态，并产生“想坐下来歇一会儿”的本能反应。

在设计映射规则之前，我先定义了几个维度：整体亮度（对应能量水平）、天气类型（对应情绪基调）、水流速度（对应思绪速度）、山体轮廓的锐利度（对应压力程度）。具体映射值如下表：

这个映射方案不是一步到位的。最早我用的映射是“情绪直接对应颜色”，开心就橙黄色，难过就灰蓝色，但实测效果很糟糕——太像劣质心情打卡 App。后来改成“整体氛围迁移”，让景观像真实的自然界一样缓慢变化，而不是按钮一按就脸色骤变。山水画的核心是“气韵”，而气韵的本质是连续性。所以面板的数据更新策略不是实时跳变，而是用缓动动画做 3-5 分钟的渐变过渡，模拟真实天光变化的感觉。

从工程角度，这部分最适合用 WebGL 或 Flutter 的 CustomPainter 做。我在原型里用 Canvas 2D 手绘了一套简化的山水生成算法：山体的起伏用了多层噪声叠加，水流用粒子系统模拟，雨雪雾则通过半透明图层的混合来实现。这个做法的好处是完全程序化生成，不需要预渲染素材，任何状态组合都能平滑过渡。

4.2 观心日志：降低表达门槛，让人真的愿意写

观心日志这个模块，最容易做成“让人有压力”的产品。如果每次记录都要输入大量文字，用户记录两三次就放弃了。所以我对记录入口做了很严格的设计约束。

主路径提供三种记录方式：语音记录、点选标签加简短备注、拍照或选择一张当前环境照片。语音记录是最推荐的，因为人在情绪波动时，语音比文字更容易表达；而且说话本身就有情绪宣泄效果。语音通过系统自带的端侧语音转文字能力做处理，而不是直接存录音文件，因为录音文件体积大、隐私风险高、也不好做后续的文本分析。

对不想输入任何内容的用户，系统提供一个“快速标记”按钮，按一下就是记录一个此刻的完整快照——情绪未知，强度未知，但至少留下了一个时间点位，后续可以回溯补充。这个设计参考了“门把手式交互”的思路：先降低进入门槛，再引导深度记录。

日志列表的展示按“天”分组，每一天是一段连续的轨迹，而不是一条条零散的小卡片。轨迹视图让用户能直观地看到自己一天的状态起伏：上午稳定，午后突然波动，晚间缓慢恢复。这种全局视角本身就是觉察的一部分。

4.3 引导引擎：不是播放音频的播放器，而是可调参的恢复系统

引导引擎的价值在于：当系统检测到状态异常时，能立刻提供一个可执行的恢复方案。它不是播客或音频课，而是像操作系统的“恢复模式”——有明确的诊断、有可选的恢复手段、有恢复后的效果验证。

我在原型里实现了三种引导类型：

• 呼吸引导：根据用户基线呼吸频率生成 4-6-8 节律（吸气 4 秒、屏息 6 秒、呼气 8 秒），通过音频节拍器和轻微的视觉呼吸球同步。这个对紧张状态效果最快。
• 身体扫描：引导语音带领用户从脚底到头顶逐一觉察身体感受，适合睡前、压力大时，时长可以选 5 分钟和 15 分钟两档。
• 三步呼吸空间：一种 3 分钟的极简练习，适合在会议间隔、工作间隙快速重启状态。它交互成本低，是最容易被用户每天使用的功能。

引导会话开始前和结束后，系统都会要求用户做一次快速状态快照（可以只选情绪强度和能量感）。两个快照之间的差异，就是这次引导的量化效果。这个数据会进入复盘体系，让用户看到一个长期趋势：哪些类型的引导在什么状态下最有效。

4.4 通知闸门：把“系统级权限”交给用户

作为一套要长期活在用户手机里的系统，它必须比用户更懂“勿扰”的意义。所以我在原型里做了一个通知闸门模块，它不直接调用系统 API 去强制拦截通知，而是成为一个“转发层”——用户把常用 App 的通知集中到闸门里，系统按规则统一放行。

规则的默认设定是：工作时段内，除电话和指定联系人消息外，所有非即时通知延迟到下一个休息点统一推送；检测到用户处于“激流”状态（情绪强度高、HRV 偏低）时，闸门自动进入高过滤模式，只保留紧急联系人的通信。这套机制的本质是把“要不要被打断”的决策从用户手里接过来，因为人在情绪波动时根本没有余力做这种决策。

通知闸门设计上最大的启发来自操作系统里的中断处理：一个稳定的系统会为不同优先级的中断预留不同的处理路径。人类做不到像电脑那样严格分级，但系统可以帮我们建立一条保护注意力的防火墙。

4.5 周度复盘报告：从数据中看见模式，而不是看单一数据点

周度复盘报告是让我自己最感慨的一个模块，因为它真正体现出了数据沉淀的价值。报告不是什么大数据炫技，而是回答三个问题：这周的状态整体如何？容易波动的时间段和场景是什么？哪种引导方式最有效？

自动生成方式：系统从本周的状态快照里取出情绪强度和能量感的数据点，做成一条七天叠加的曲线，标注出每周大概率低落的时段；把带着地点的快照按地点聚合，统计出哪种场景下情绪强度中位数最高；把引导会话的前后快照做配对比较，列出平均改善幅度最大的引导类型和建议时长。

最终的报告页只有四五个模块，每句话都是用人话写的，比如“你这周三下午的状态波动，和周二晚上 23:00 后的一条高强度记录存在时间关联”。不做成密密麻麻的数据大屏。报告存在的意义是让用户获得自我洞察，一旦信息过载，洞察就消失了。

5. 原型实测中的问题与调整：真实使用才能暴露的设计缺口

5.1 引导节奏“千人千面”，必须参数化

第一个原型我来回测试时发现，固定的呼吸节律对部分用户很不友好。我自己测试时觉得 4-6-8 的节奏很舒服，但有朋友反馈说“吸气还没吸完就开始憋气了”，还有人觉得屏息 6 秒太漫长。做冥想引导最忌讳的就是让用户觉得“是我做错了”，节律不合适会让用户丧失信心。

所以我把呼吸参数做成了可配置项，并在引导开始前增加了一个“一分钟基线感知”环节——用户跟着一个简单动画自然呼吸一分钟，系统估算近似的基线呼吸周期，再基于基线生成引导节律。对于不习惯反馈式设计的用户，直接给三个清晰档位：舒缓（吸气 4，屏息 2，呼气 6）、均衡（吸气 4，屏息 4，呼气 6）、深度（吸气 4，屏息 6，呼气 8）。实测下来，让用户先自己选一次档位，之后系统记住偏好，就没有再出现节奏不合适的问题。

5.2 闭眼场景被忽略，界面不能只靠“看”

引导过程里，用户大概率是闭着眼睛的。我一开始在界面上花了很大力气做动画，但测试时发现用户根本看不到，引导效果完全取决于音频的质量和节奏提示是否清晰。

这是个很痛的教训：所有面向冥想引导场景的视觉设计，都必须假设用户闭眼时依然能获得完整的体验。我的调整方案是：所有引导都要求配套高质量的引导语音和节拍提示音；视觉动画退化为次要元素，只在开始和结束的两个瞬间出现；呼吸引导的提示音用了“流水声渐强代表吸气、渐弱代表呼气”的方式，比光靠语音喊“吸气”“呼气”要自然得多。

5.3 情绪标注粒度太细，反而成了负担

早期版本的情绪标签有二十多个：平静、愉悦、满足、焦虑、烦躁、愤怒、悲伤、疲惫、孤独……测试下来发现，用户在情绪波动时根本没耐心去精准匹配词汇，翻两页标签就想关掉 App。情绪标注的本质是帮助觉察，不是做心理学研究，这份精确度的执念得放下。

最终我把情绪标注砍到三档强度加六个高频标签（平静、愉悦、焦虑、烦躁、疲惫、悲伤），剩下的全部交给自由文本和语音。这一改动，单次记录耗时从平均 50 秒降到了不到 15 秒，记录频率反而翻了一倍。产品的克制在这里体现出了价值。

5.4 语音转文字必须端侧处理，老设备性能是道坎

语音记录功能上线没多久，我就发现手机端的性能是最大瓶颈。在部分老旧 Android 设备上，端侧语音识别模型加载需要三四秒，识别过程中机身明显发热。如果加载类模型太重，干脆先购买一个极简策略：用户语音先记录为本地音频文件，异步转文字，用户可以在回看时补充标签。这样主流程完全不等待模型加载，识别质量也让用户自己决定是否采纳。

如果你打算复刻这个功能，我的建议是：优先用小体积的端侧模型（比如 Whisper tiny 或 mobile 版本），而且务必在项目规划阶段就定好降级路径，别让语音输入卡住整个记录流程。

5.5 “数字排毒”的悖论：产品自身别成为新的噪音源

这是最根本的一个反思。山水观心系统倡导降低数字干扰，但它本身也是一个数字产品，稍不留神就会变成新的焦虑来源。如果用户一天不记录，系统就弹通知提醒“连续打卡即将中断”，那它和那些让人上瘾的社交 App 在机制上没有任何区别。

所以我的设计原则变成了“不催促、不惩罚、不奖励”。用户今天不想打开系统，那系统就安静地待着，只保留后台的被动传感器采集。所有引导入口都只是静静地存在于首页，不弹提示，不做红点。这套“零打扰”理念不是一句空话，它在产品机制上做了很多减法，做减法比做加法难得多，但这是值得的，因为它决定了用户愿不愿意十年如一日地使用这套系统。

6. 如果你想复刻这套系统：建议、顺序与避坑参考

6.1 先定义“系统边界”，不要上来就做全套

坦率地说，山水观心操作系统到目前为止的全量功能如果一次性做完，需要投入的资源和时间非常可观。对个人开发者或小团队来说，“先做边界内的最小系统”是更现实的路线。

我推荐的最小可用闭环是：状态快照记录（可以只是点选） → 山水面板映射（把快照转成动态场景） → 一个引导功能（呼吸引导，只需节拍器加语音） → 周度报告（简单趋势图）。这个闭环已经把“觉察-记录-映射-引导-复盘”的核心逻辑全部跑通了。在此基础上再根据实际反馈，逐步加入语音记录、通知闸门、可穿戴设备接入等外围能力。

6.2 数据模型先行，界面可以砍，模型砍了要动筋骨

我在交付原型的过程中最深的体会是，界面可以快速重做，但数据模型一旦定错，后期改造成本是指数级上升的。比如早期版本里，引导会话没有关联前后的状态快照 ID，导致后来想计算引导效果时，不得不写一堆兼容逻辑去从时间戳里反推。

建议在写第一行界面代码之前，先把四个核心数据模型（状态快照、引导会话、环境指标、洞察）画清楚，尤其是它们之间的关联关系。这不是浪费时间，这是给未来三十个版本铺路。

6.3 动态山水效果别一上来就追极致

动态山水视觉效果是这套系统最容易让人沉溺打磨的部分，也是最容易让人拖期的地方。你研究着色器、粒子系统、噪声算法，两周就过去了，但用户可能一个月后才真正关注这个界面的细节。作为产品开发者，你是在为“一个好用的工具”做设计，不是在做数字艺术展。

我的建议是第一步只做“静态山水图加整体滤镜渐变”：根据状态参数切换场景的色调、亮度和天气覆盖层，在下一次迭代再加云层流动和水流动画，最后再考虑粒子级的细节。视觉氛围在及格线以上就够了，核心体验的打磨优先级永远高于视觉炫技。

6.4 心境数据安全要在一开始就设计进去

心境数据比健康数据更私密。领夹式体重秤的数据泄露已经让人难受了，情绪记录一旦泄露，用户在心理上会感到被赤裸裸地窥视。所以从设计第一天起就要明确：本地存储是默认形态，云端同步是用户主动开启的选项，所有导出文件必须提供加密选项。你还应该预埋一个一次性导出所有数据的功能，这也是用户信任的基础——数据是我的，我随时可以带走。

6.5 预留可穿戴设备接口，但别被硬件绑架

心率、HRV、睡眠数据这些被动采集的信息，对状态判断确实能提供很大帮助。但可穿戴设备的接入是一个巨大的工程，硬件品牌、协议、权限申请、电量消耗，每一件事都会耗掉大把精力。原型阶段没必要接硬件，但数据模型里要把“环境指标”这一类数据的位置留出来，将来接入时不用改结构。

如果你的用户群体手表渗透率高，后续可以优先支持健康平台的聚合接口。如果渗透率低，就先用用户手动选择的“此刻身体感受”作为替代，效果也不会差太多，毕竟主观感受本身就是最核心的数据源。

6.6 为什么说这个方向值得继续做下去

这个项目做下来，我最大的收获不是把它发布上线，而是重新理解了“操作系统”这个概念。过去我们嘴里的操作系统，管理的是硬件、文件、进程，服务的对象是计算机。山水观心系统做的，是把管理系统的那套成熟方法论，应用到人自身的认知与情绪资源上。我们的注意力、情绪、念头，本质上就是一个人一天里最稀缺的计算资源。系统不用高大上，认出自己处于什么状态、在恰当的时间做一次恰当的调节，这就够了。

如果你也在考虑做一个类似的项目，希望这篇文章能帮你跳过我踩过的那些坑。从一个人的自我实验开始，定义清楚边界，做出最小闭环，剩下的交给真实使用的打磨。这套系统的代码、数据模型和山水渲染逻辑，后续我还会继续迭代，但我最想先看到的，不是它有多炫的技术表现，而是它真的能在人状态最差的时候，安静地递过来一个“恢复”的选项。