如果把一个社会人的一天的生活按照时间顺序解构，那基本流程是起床，吃饭，通勤，上班，下班，吃饭，睡觉。
数据堰塞湖
在这个过程中，可能会涉及到电脑，家用电器，汽车，手机，外卖软件等生活用品/互联网服务。
以智能家居场景为例，由于各大厂商之间的相互竞争，个人数据实际是处于各自独立的“信息孤岛状态”。比如我买了一个米家的温度传感器，但空调是海尔品牌的。因为两个品牌的数据不互通，导致无法实现“温度传感器高于36°时打开空调”这种需求；又比如我用了小米的大模型音箱，询问它当前的室温，它只能通过网络搜索，告诉我区县级别的天气温度/湿度。而这部分数据，实际上一直存在海尔空调的温度传感器中。
我把这种数据不互联互通的情况称为“数据堰塞湖”。
上下文丢失
以上午上班通勤的活动为例，“在家吃饭”和“开车去上班”发生在两个不同的场景。但从家到地下停车场的这个过程，实际上“车”是不知道的。 为了缩小问题复杂度，我们假设使用了全套的小米智能家居，以及小米汽车。理论上，通过小米手机/小米智能手环上的蓝牙信号的衰减/增强可以判断车到人的距离，进而判断是人离车，还是人开车。 然而蓝牙设备能记住的设备数量毕竟有限，只有在小范围场景才能适用这种解决方案。
上下文丢失，更多的是一种跨设备，跨系统的问题。如果说“数据堰塞湖”是一种人为的上下文丢失，那么场景的切换也会带来上下文的丢失。
举个例子，当我们走进博物馆，本质上博物馆是可以通过票证凭据和摄像头识别“知道”游客已经入馆的。但由于这套系统的运作成本过于巨大，实际操作是丢弃“数据上下文”，让游客自行游玩。
//prompt: 画一个图片，内容是人进入博物馆之后，博物馆机器人打招呼，而且游客的手机屏幕切换为一个人形的导航。使用动漫风格。
意念编程（Spec Coding）与主动陪伴（Active Companionship）
以上问题并非没有解决方案。
在当前的意念编程设计中，AI作为新的流量入口，用户告诉智能音箱“打开客厅的灯”，本质是表达一种期望（spec）。AI作为一种“控制器”会做好该期望的实际交付工作（找到客厅中的灯，并打开）。
但意念编程的问题在于“人主动”，而不是“物主动”。在当前版本的智能家居中，需要人为设计很多自动化场景去智能地控制电子设备（比如感应到人，并且时间在日落之后，触发自动开灯），但在我看来，AGI的第一性原理是数据保存在用户自己的消费电子终端，平台基于写时复制（copy on write），最小化地使用用户的数据。
如果基础传感器数据存在用户本地，那么自始至终就不存在“信息孤岛”的问题。而携带个人数据的消费电子终端，可以通过传感器和其他设备（车）互联。
而基于AGI之上的主动陪伴（Active Companionship）,则是智能家居自动化控制流/家居机器人的关键。以午睡这个场景为例，实际上，通过累计足够的数据（用户在工作日12点之后通常会拉窗帘，并关灯），建立相关的关联关系，智能家居应该是可以直接给用户提出一个建议（工作日中午时段当感知到你之后，我会关灯并拉窗帘），并在获取用户授权后，工作日自动化执行。
If we deconstruct a social person’s daily life in chronological order, the basic flow is: wake up, eat, commute, work, get off work, eat, sleep.
Data Barrier Lake
In this process, various consumer goods and internet services may be involved—computers, home appliances, cars, phones, food delivery apps, and so on.
Take the smart home scenario as an example. Due to competition among major manufacturers, personal data is effectively trapped in isolated “information silos.” For instance, I bought a Mijia temperature sensor, but the air conditioner is a Haier brand. Because the two brands’ data don’t interoperate, I can’t implement a rule like “turn on the AC when the temperature sensor reads above 36°.” Or consider Xiaomi’s LLM-powered speaker: when I ask it about the current room temperature, it can only answer via web search, giving me district-level weather temperature/humidity—even though that data actually exists in the Haier AC’s temperature sensor all along.
I call this situation where data fails to interconnect “data barrier lake.”
Context Loss
Take the morning commute as an example. “Eating at home” and “driving to work” happen in two different contexts. But the car has no knowledge of the transition from home to the underground parking lot. To reduce complexity, assume we use a full Xiaomi smart home setup plus a Xiaomi car. Theoretically, Bluetooth signal attenuation/strengthening from a Xiaomi phone or smart band could indicate the distance between car and person, and thus whether the person is leaving or approaching the car. However, Bluetooth devices have a limited number of devices they can remember, so this approach only works in small-scale scenarios.
Context loss is largely a cross-device, cross-system issue. If “data barrier lake” is a man-made form of context loss, then context switching also causes context loss.
For example, when we enter a museum, the museum could in principle “know” that a visitor has entered via ticket credentials and cameras. But because the cost of running such a system is prohibitively high, the practical approach is to discard “data context” and let visitors explore on their own.
//prompt: Draw an image of a person entering a museum, a museum robot greeting them, and the visitor’s phone screen switching to a humanoid navigation interface. Use anime style.
Spec Coding and Active Companionship
These problems are not without solutions.
In current Spec Coding design, AI acts as a new traffic entry point. When a user tells a smart speaker “turn on the living room light,” they are expressing an expectation (spec). The AI, as a “controller,” handles the actual delivery of that expectation (finding the living room light and turning it on).
But the issue with Spec Coding is that it is “human-initiated” rather than “thing-initiated.” In current smart home setups, many automation scenarios must be manually designed to control devices (e.g., sense a person and, if it’s after sunset, trigger automatic lighting). In my view, the first principle of AGI is that data is stored on the user’s own consumer electronics, with platforms using copy-on-write to minimize use of user data.
If base sensor data resides locally on the user’s device, there is no “information silo” problem from the start. Consumer electronics carrying personal data can interconnect with other devices (e.g., the car) via sensors.
Active Companionship built on AGI is key to smart home automation flows and home robots. Take the afternoon nap scenario: with enough accumulated data (e.g., the user usually draws the curtains and turns off the lights after 12:00 on weekdays), correlations can be established. The smart home should be able to propose a suggestion (“On weekday afternoons, when I sense you, I’ll turn off the lights and draw the curtains”) and, after user authorization, automate it on weekdays.
社会人の一日の生活を時間順に分解すると、基本的な流れは起床、食事、通勤、出勤、退勤、食事、就寝となる。
データ堰塞湖（Data Barrier Lake）
この過程で、パソコン、家電、車、スマートフォン、フードデリバリーアプリなどの生活用品やインターネットサービスが関わってくる。
スマートホームのシーンを例にとると、各メーカー間の競争により、個人データは事実上それぞれ独立した「情報孤島」状態にある。例えば、米家の温度センサーを買ったが、エアコンはハイアール製だとする。両ブランドのデータが相互接続されていないため、「温度センサーが36°を超えたらエアコンをオンにする」といったニーズを実現できない。また、小米の大モデルスピーカーを使い、現在の室温を尋ねても、ネット検索でしか答えられず、区県レベルの天気の温度・湿度を教えてくれる。そのデータは実際にはハイアールエアコンの温度センサーにずっと存在しているのに。
私はこのデータが相互接続されない状況を「データ堰塞湖」と呼んでいる。
コンテキストの喪失
午前の通勤を例にとる。「自宅で食事」と「車で出勤」は二つの異なるシーンで発生する。しかし、家から地下駐車場までの過程は、「車」には知られていない。 問題の複雑さを抑えるため、小米のスマートホーム一式と小米自動車を使っていると仮定する。理論上、小米スマートフォンやスマートバンドのBluetooth信号の減衰・増強から、車と人の距離を判断し、人が車を離れているのか、車に乗っているのかを判断できる。 しかし、Bluetoothデバイスが記憶できるデバイス数には限りがあり、この解決策は小規模なシーンでのみ適用可能だ。
コンテキストの喪失は、より多くの場合、デバイス間・システム間の問題である。「データ堰塞湖」が人為的なコンテキスト喪失だとすれば、シーンの切り替えもコンテキストの喪失をもたらす。
例えば、博物館に入る時、本質的には博物館はチケットとカメラで「知る」ことができる——来館者が入館したことを。しかし、このシステムの運用コストが非常に高いため、実際には「データコンテキスト」を捨て、来館者に自由に見学させている。
//prompt: 博物館に入った人、博物館ロボットが挨拶し、来館者のスマートフォン画面が人型ナビに切り替わる画像を描く。アニメスタイルで。
Spec Coding（意念プログラミング）とActive Companionship（能動的同伴）
以上の問題に解決策がないわけではない。
現在のSpec Coding設計では、AIは新しいトラフィックの入口として機能する。ユーザーがスマートスピーカーに「リビングの照明をつけて」と伝えるのは、本質的には期待（spec）を表明している。AIは「コントローラー」として、その期待の実際の実行（リビングの照明を見つけて点灯する）を行う。
しかしSpec Codingの問題は「人が能動的」であり「物が能動的」ではないことだ。現在のスマートホームでは、電子機器をスマートに制御するために多くの自動化シーンを人為的に設計する必要がある（例えば、人を感知し、日没後の時間であれば自動点灯をトリガーする）。私の見解では、AGIの第一原理は、データがユーザー自身の消費電子端末に保存され、プラットフォームはcopy on writeに基づいてユーザーデータを最小限に使用することである。
基礎センサーデータがユーザーのローカルに存在すれば、最初から「情報孤島」の問題は存在しない。個人データを携帯する消費電子端末は、センサーと他のデバイス（車）を相互接続できる。
AGIの上に構築されたActive Companionshipは、スマートホームの自動化制御フローやホームロボットの鍵である。昼寝のシーンを例にとると、十分なデータ（ユーザーが平日12時以降に通常カーテンを閉め、照明を消す）を蓄積し、関連する相関関係を確立すれば、スマートホームはユーザーに直接提案できる（「平日の昼間、あなたを感知したら、照明を消してカーテンを閉めます」）。ユーザーの承認を得た後、平日に自動実行する。
Если деконструировать день социального человека в хронологическом порядке, базовая последовательность такова: пробуждение, еда, поездка на работу, работа, возвращение, еда, сон.
Озеро данных (Data Barrier Lake)
В этом процессе могут участвовать компьютеры, бытовая техника, автомобили, телефоны, приложения доставки еды и другие потребительские товары и интернет-сервисы.
Возьмём сценарий умного дома. Из-за конкуренции между крупными производителями персональные данные фактически оказываются в изолированных «информационных островах». Например, я купил температурный датчик Mijia, а кондиционер — Haier. Поскольку данные двух брендов не обмениваются, невозможно реализовать правило «включить кондиционер, когда датчик показывает выше 36°». Или: я использую колонку Xiaomi с большой языковой моделью и спрашиваю текущую температуру в комнате — она может ответить только через веб-поиск, сообщая температуру/влажность на уровне района. Хотя эти данные всё время есть в температурном датчике кондиционера Haier.
Я называю такую ситуацию, когда данные не связаны между собой, «озером данных» (data barrier lake).
Потеря контекста
Возьмём утреннюю поездку на работу. «Еда дома» и «поездка на работу» происходят в двух разных контекстах. Но машина не знает о переходе от дома до подземной парковки. Чтобы упростить задачу, допустим, используется полный комплект умного дома Xiaomi и автомобиль Xiaomi. Теоретически по затуханию/усилению Bluetooth-сигнала с телефона или умного браслета Xiaomi можно определить расстояние между машиной и человеком и понять, человек уходит от машины или подходит к ней. Однако Bluetooth-устройства могут запомнить ограниченное число устройств, поэтому такой подход применим только в малых масштабах.
Потеря контекста — это в основном проблема между устройствами и системами. Если «озеро данных» — это искусственная потеря контекста, то смена сценария тоже приводит к потере контекста.
Например, когда мы входим в музей, музей в принципе может «знать» о приходе посетителя по билету и камерам. Но из-за чрезмерно высоких затрат на такую систему на практике от «контекста данных» отказываются и дают посетителям свободно осматривать экспозицию.
//prompt: Нарисуй изображение: человек входит в музей, робот музея приветствует его, экран телефона посетителя переключается на человекоподобную навигацию. В стиле аниме.
Spec Coding и Active Companionship
У этих проблем есть решения.
В текущей концепции Spec Coding ИИ выступает новой точкой входа. Когда пользователь говорит умной колонке «включи свет в гостиной», он выражает ожидание (spec). ИИ как «контроллер» выполняет это ожидание (находит свет в гостиной и включает его).
Но проблема Spec Coding в том, что инициатива исходит от «человека», а не от «вещи». В нынешних умных домах приходится вручную проектировать множество сценариев автоматизации (например, обнаружить человека и, если уже после заката, включить свет). По моему мнению, первый принцип AGI — данные хранятся на собственных устройствах пользователя, а платформы используют copy-on-write, минимизируя использование пользовательских данных.
Если базовые данные сенсоров хранятся локально у пользователя, проблемы «информационных островов» изначально не возникает. Устройства с персональными данными могут связываться с другими устройствами (например, машиной) через сенсоры.
Active Companionship, построенный на AGI, — ключ к потокам автоматизации умного дома и домашним роботам. Возьмём сценарий дневного сна: накопив достаточно данных (пользователь обычно закрывает шторы и выключает свет после 12:00 в будни), можно выявить корреляции. Умный дом должен уметь предложить: «В будние дни в обеденное время, когда я почувствую тебя, выключу свет и закрою шторы» — и после одобрения пользователя автоматически выполнять это по будням.
💬 讨论 / Discussion
对这篇文章有想法？欢迎在 GitHub 上发起讨论。
Have thoughts on this post? Start a discussion on GitHub.