Как создать контакт Android с ИИ и проверкой дублей
Практический гид FoneClaw: как превратить сообщение или заметку в структурированный Android-контакт, проверить дубли, выбрать аккаунт, подтвердить запись и убедиться, что контакт сохранен правильно.
- FoneClaw поддерживает прямое создание Android-контакта после проверки дублей и явного подтверждения пользователя.
- Хорошая карточка контакта начинается со структурированных полей: имя, телефон, email, организация, должность, заметка и целевой аккаунт.
- Точные совпадения по телефону или email важнее похожего имени, а возможные совпадения нужно показывать для решения, а не обрабатывать автоматически.
- После записи контакт нужно найти по нормализованному телефону или email, открыть сохраненную карточку и проверить аккаунт, поля и отсутствие лишнего дубля.
Создать один контакт без лишнего дубля
Чтобы создать контакт Android с ИИ и проверкой дублей, начинайте с маленького, проверяемого процесса: дайте FoneClaw источник, превратите его в карточку-кандидат, проверьте точные и возможные совпадения, выберите аккаунт хранения и подтвердите запись. Только после этого контакт должен появиться в адресной книге. Такой порядок экономит время и сохраняет контроль там, где ошибка быстро превращается в два похожих контакта или неверный номер у важного человека.
Пример запроса: «Создай контакт из этого SMS: Иван Петров, менеджер доставки, +7 999 123-45-67, ivan@example.com. Проверь дубли и покажи перед сохранением». В этом запросе есть источник, имя, роль, телефон, email и требование проверки. FoneClaw может разобрать данные, подготовить структурированную карточку, сравнить ее с текущими контактами и показать пользователю, что именно будет создано.
Мы добавили approved contact creation с duplicate checks именно для такого момента. Раньше создание контакта через помощника часто заканчивалось открытием другого приложения и ручным переносом полей. Сейчас FoneClaw может выполнить поддерживаемую запись напрямую, если у него есть нужное разрешение Android и пользователь утвердил конкретную карточку. Для нас это важный пример phone action agent: модель помогает понять данные, но последнее действие остается видимым и проверяемым.
Пять шагов стоит держать одинаковыми для голоса, текста, SMS, email-подписи или заметки: извлечь данные, нормализовать поля, найти совпадения, подтвердить аккаунт и сохранить. После записи обязательно выполните поиск по телефону или email. Сообщение об успехе полезно, но настоящий финал — открытая сохраненная карточка с правильными полями.
Превратить подпись или заметку в поля контакта
ИИ полезен при создании контакта не потому, что угадывает человека, а потому что быстро отделяет поля друг от друга. В Android контакты устроены как структурированные данные: есть агрегированный контакт, account-specific raw contacts и typed data rows для имени, телефона, email, организации и других деталей. Документация Android о Contacts Provider показывает, почему правильная структура важнее красивой строки в одном поле.
Когда источник — подпись в письме, сообщение в мессенджере или заметка после звонка, сначала ищите факты, которые действительно присутствуют. Имя может быть полным или кратким. Телефон может быть мобильным, рабочим, добавочным или частью адреса. Email может относиться к человеку или общей группе. Организация и должность помогают уточнить контекст, но редко являются надежным идентификатором сами по себе.
Хороший кандидат контакта должен явно разделять подтвержденные данные и предположения. Если в подписи написано «Анна, закупки, Север», FoneClaw может предложить имя «Анна», организационную заметку «закупки / Север» и попросить уточнить фамилию или компанию. Он не должен придумывать домен email, страну номера или юридическое название компании только для того, чтобы карточка выглядела полной.
Полезная структура выглядит так:
- Имя: как человек представлен в источнике.
- Телефон: с кодом страны, если он указан или очевиден из исходного формата.
- Email: без лишних пробелов, точек после подписи и случайных символов.
- Организация и должность: только из явного текста или подтвержденного контекста.
- Заметка: источник контакта, например «доставка шкафа» или «участник встречи по договору».
- Аккаунт хранения: телефон, Google Account, рабочий профиль или другой доступный адресный контейнер.
Если контакт приходит из SMS, полезен связанный процесс: сначала сделать сводку переписки, выделить отправителя и данные, а затем сохранить только проверенный набор. Для этого сценария подходит статья Сводка SMS на Android с ИИ: период, отправители, ответы и проверка, потому что она показывает, как из сообщения получить контекст без автоматической записи всего текста в адресную книгу.
Проверить точные и возможные совпадения
Проверка дублей перед сохранением должна начинаться с точных идентификаторов. Телефон и email обычно дают самый сильный сигнал: если уже есть контакт с тем же нормализованным номером или тем же адресом, FoneClaw должен показать найденную карточку и предложить решение. Имя, компания и заметка помогают понять контекст, но они не должны сами закрывать вопрос идентичности.
Android Contacts Provider может агрегировать matching raw contacts в один видимый контакт. При этом агрегирование не является доказательством, что две записи всегда описывают одного человека. В справке Android по RawContacts описано, что изменения имени, организации, телефона, email или nickname могут запускать повторную агрегацию. Для пользователя это означает: совпадение помогает принять решение, но не заменяет просмотр полей.
Мы делим совпадения на два уровня. Exact match — это совпадение нормализованного телефона или email. Possible match — это похожее имя, общая организация, похожая подпись, тот же короткий номер или связь через уже существующую заметку. Exact match обычно ведет к вопросу: обновить существующую карточку или отменить создание? Possible match ведет к другому вопросу: это тот же человек, общий номер компании или просто похожее имя?
Google Contacts тоже использует пользовательскую проверку для объединения дублей. В справке Google Contacts о слиянии дублей видно, что merge suggestions рассчитаны на решение пользователя, а контакты в разных Google Accounts имеют отдельные границы. Поэтому FoneClaw показывает duplicate check как поддержку решения: создать новый контакт, обновить существующий, выбрать другой аккаунт или отменить запись.
| Сигнал | Как трактовать | Что показать перед записью |
|---|---|---|
| Тот же email | Сильное точное совпадение | Существующий контакт, аккаунт, имя и новое поле |
| Тот же нормализованный телефон | Сильное точное совпадение, но общий номер возможен | Номер, текущая карточка, источник нового контакта |
| Похожее имя | Возможное совпадение | Список похожих контактов и различающиеся поля |
| Та же организация | Поддерживающий сигнал | Контакты из той же компании и новый контекст |
| Разные аккаунты | Граница хранения и синхронизации | Где лежит старая запись и куда пойдет новая |
Проверить аккаунт, поля и действие перед подтверждением
Перед записью контакта важны три решения: в какой аккаунт сохранить, какие поля попадут в карточку и какое действие выполняется сейчас. Аккаунт определяет, где контакт будет храниться и синхронизироваться: локально на телефоне, в личном Google Account, в рабочем профиле или в другом доступном контейнере. Ошибка в этом месте часто заметна только потом, когда контакт не появляется на другом устройстве или попадает в рабочую адресную книгу вместо личной.
В FoneClaw мы показываем карточку-кандидат до сохранения. Пользователь видит имя, телефон, email, организацию, заметку, целевой аккаунт и найденные совпадения. Если есть exact match, практичный выбор обычно звучит как «обновить существующую карточку» или «отменить создание». Если есть possible match, лучше показать оба варианта и дать пользователю решить, идет ли речь о том же человеке.
Duplicate check сам по себе не является разрешением на запись. Он только подготавливает решение. Подтверждение должно относиться к конкретному действию: создать новый контакт, добавить email к существующему контакту, обновить организацию, выбрать другой аккаунт или отменить. Такой подход особенно важен для рабочих номеров, семейных контактов, сервисных телефонов и контактов из временной переписки.
Мы подробно разбираем дизайн таких остановок в статье Интерфейс подтверждения действий ИИ-агента на телефоне: уверенность, причины и восстановление. Для контактов это не абстрактная UX-тема: пользователь должен понимать, почему FoneClaw предлагает запись, на каких полях основано совпадение и что изменится после нажатия кнопки подтверждения.
Создать контакт напрямую через FoneClaw
Текущий процесс FoneClaw позволяет создать approved contact без открытия другого приложения. Это удобно, когда данные уже находятся в разговоре, SMS, заметке, письме, скриншоте или текущем экране. Пользователь дает команду, FoneClaw извлекает поля, проверяет дубли, показывает карточку и после подтверждения выполняет поддерживаемую запись в контакты Android.
Практический сценарий выглядит так. Пользователь выделяет или пересказывает источник: «Сохрани контакт: Сергей Лебедев, ремонт кондиционера, +7 916 555-01-22, нашел через домовой чат». FoneClaw формирует candidate record: имя Сергей Лебедев, телефон в международном формате, заметка «ремонт кондиционера / домовой чат». Затем выполняется duplicate-contact check по номеру и похожим данным. Если совпадений нет, пользователь выбирает аккаунт и подтверждает создание.
Если найден существующий контакт «Сергей кондиционер» с тем же номером, FoneClaw показывает точное совпадение. В такой ситуации пользователь может отменить создание новой карточки и обновить существующую: привести имя к нормальному виду, добавить заметку или оставить все как есть. Если найден другой Сергей из той же организации, но с другим телефоном и email, FoneClaw показывает это как possible match и оставляет решение пользователю.
Разрешения Android остаются частью маршрута. Когда задаче нужен доступ к контактам, FoneClaw направляет пользователя через соответствующее разрешение. Мы развиваем этот слой как permission-aware execution: модель не обходит системные правила, а FoneClaw помогает увидеть, какой доступ нужен для текущего шага. Для более широкой картины полезна статья Песочница AI-агента и разрешения телефона: почему безопасным агентам нужны границы.
Полный набор актуальных возможностей лучше проверять через встроенные инструменты FoneClaw. В этой статье важен конкретный вывод: создание контакта стало не просто текстовой подсказкой, а поддерживаемым Android-действием с duplicate check, approval и post-write verification.
Общие номера, международный формат и разные аккаунты
Дубли в контактах редко бывают очевидными. Один и тот же номер может принадлежать семье, ресепшену, курьерской службе, школьному классу, рабочей группе или сервисному центру. Если номер повторяется, FoneClaw должен показать совпадение и контекст, а пользователь решает: это тот же контакт, общий номер для нескольких людей или новая карточка с общей линией связи.
Международный формат требует отдельной проверки. Номер может быть записан как 8 999 123-45-67, +7 999 123-45-67 или с пробелами, скобками и добавочным кодом. Нормализация нужна для сравнения, но она не должна менять смысл. Если источник не содержит код страны, FoneClaw может использовать контекст устройства или попросить уточнить страну. Для рабочих номеров важно сохранить extension отдельно или в заметке, чтобы основной номер не стал недозваниваемым.
Разные аккаунты создают еще один слой. В Android один видимый контакт может быть собран из raw contacts, а Google Contacts указывает, что записи в разных Google Accounts нельзя всегда объединить через один merge flow. Поэтому перед сохранением нужно видеть целевой аккаунт. Для личного контакта подходит личный аккаунт, для сотрудника — рабочий профиль, для временного сервисного номера — локальная запись или заметка, если синхронизация не нужна.
Иногда правильное решение — создать неполный контакт и вернуться к нему позже. Если есть только имя и роль, можно сохранить заметку без телефона. Если есть только номер из звонка, лучше дать понятное имя вроде «Сервис кондиционеров, уточнить» и добавить источник. FoneClaw помогает удержать этот контекст, но мы проектируем процесс так, чтобы пользователь видел неопределенность, а не получал уверенно заполненную карточку из догадок.
Когда контактный доступ не работает, сначала проверяйте состояние телефона и разрешения. Руководство Проверка состояния Android с ИИ: батарея, разрешения и уведомления помогает пройти базовую диагностику, если FoneClaw не видит контакты, не может открыть нужный доступ или задача останавливается на системном экране.
Проверить сохранение и восстановиться без ошибок
Создание контакта заканчивается не сообщением «готово», а проверкой сохраненной карточки. После записи найдите контакт по нормализованному телефону или email, откройте его и проверьте имя, аккаунт, номер, email, организацию и заметку. Если Android или приложение контактов агрегировало запись с существующей карточкой, посмотрите, какой результат стал видимым пользователю.
Post-write verification защищает от двух частых ошибок: повторного сохранения после неопределенного результата и создания контакта в неправильном аккаунте. Если FoneClaw сообщает, что запись была выполнена, но поиск не находит контакт, задача должна перейти в recovery: проверить разрешение, целевой аккаунт, состояние синхронизации и последние найденные совпадения. Слепой повтор может создать второй raw contact и усложнить адресную книгу.
При ошибке исправляйте только нужный слой. Неверный формат номера — обновить номер. Не тот аккаунт — создать запись в правильном месте и затем вручную решить судьбу лишней карточки. Неправильное совпадение — открыть существующий контакт и проверить raw fields перед объединением. FoneClaw помогает возвращаться к понятному шагу, потому что контактные задачи требуют аккуратности: одно поле может влиять на звонки, сообщения, синхронизацию и поиск.
Наше направление для FoneClaw — делать такие phone-side writes все более предсказуемыми: лучше показывать источник данных, яснее объяснять duplicate signals, держать approval рядом с конкретным действием и всегда возвращать пользователя к проверяемому результату. Именно так ИИ-агент для Android становится полезным в адресной книге: он ускоряет ввод, но оставляет владельцу телефона последнее решение.