Построение схем нейросеть помогает начать с текста. На возврате проектора разбираю в LibraChat обозначения узлов, точные замечания и сверку следующей редакции.
Евгений
Дизайнер-партнёр LibraChat
8 мин чтения
«Левую стрелку направь к нижнему блоку». Я понимаю это замечание, пока мы с коллегой смотрим на одну страницу. Стоит переставить блоки — и слово «нижний» уже указывает не туда. Поэтому я перестал использовать положение на листе как единственное имя элемента. Даже маленькой схеме нужны обозначения, которые переживут новую компоновку.
В задаче «построение схем нейросеть» я прошу их сразу. На возврате проектора покажу три приёма для обсуждения правок: как назвать переход, не подменить правило короткой подписью и принять следующую редакцию. Исходную текстовую спецификацию я действительно получил в LibraChat; дальнейшие команды ниже — заготовки для собственной работы.
Для «построение схем нейросеть» сначала нужны правила и имена
Процесс у меня небольшой. Принять устройство, проверить комплект. Если комплект полный, проверить работу. Если работает — закрыть заявку. При неполном комплекте или неисправности передать ответственному. Правила ремонта, хранения и компенсаций сюда не входят.
Я сначала выписываю ограничения, которые нельзя потерять при сокращении:
проверка работы следует после подтверждённого полного комплекта;
неполный комплект ведёт к передаче ответственному;
неисправность ведёт к тому же адресату, но после другой проверки;
закрытие заявки предусмотрено для полного исправного устройства.
Для получения спецификации я попросил LibraChat дать каждому узлу уникальное обозначение, тип, подпись и переходы. Получил пять узлов. Небольшую таблицу можно читать прямо как перечень мест, к которым дальше относятся замечания.
Обозначение · Подпись · Переходы в полученном ответе
N1 — Принять устройство — К N2
N2 — Комплект полный? — Да: к N3; нет: к N5
N3 — Устройство работает? — Да: к N4; нет: к N5
N4 — Закрыть заявку — Конечный узел
N5 — Передать ответственному — Конечный узел
Короткое N2 не заменяет понятную подпись. Оно позволяет сослаться на элемент однозначно. Я проверил исходную таблицу: все пять обозначений различались, у обоих вопросов были две ветки, а N4 и N5 названы конечными. Я сопоставил это с исходным правилом, прежде чем обсуждать оформление.
Открой LibraChat и попробуй превратить правила возврата оборудования в перечень узнаваемых узлов:
По правилам ниже составь текстовую спецификацию. Каждому узлу дай уникальное короткое обозначение, тип и подпись. Затем перечисли переходы с предусмотренными ответами на условия. Ничего не дорисовывай по привычке. Правила: […].
Приём 1. Называю переход тремя частями
Моё замечание состоит из места начала, ответа на вопрос и следующего узла. Например: `N2: Нет → N5`. По таблице понятно, что речь о неполном комплекте и передаче ответственному. Перестановка блоков на странице не меняет смысл этой записи.
Это особенно полезно в переписке. Коллега может открыть другую компоновку, но всё равно найдёт N2. Если написать только «к ответственному», останется вопрос, какой переход обсуждаем: их в нашем примере два. Назвать конечную точку недостаточно, когда к ней приходят по разным основаниям.
Для отдельной проверки я бы дал такое задание:
Проверь переход N2 при ответе «Нет». По принятому правилу он должен вести к N5. Назови текущую подпись обоих узлов и укажи, соответствует ли переход правилу. Остальные связи пока не меняй.
Здесь я не прошу заново строить весь процесс. Мне нужен ответ по одному замечанию. Если исходник уже согласован, большой повторный запрос может затруднить сверку: вместе с нужной правкой появятся другие изменения, которые тоже придётся принять.
Если обозначение в твоём тексте повторяется, сначала исправь эту неоднозначность. Два разных блока с именем N2 снова вернут нас к словам «тот, что слева». Короткие имена полезны только пока каждый элемент можно узнать по ним отдельно.
Приём 2. Фиксирую, что обозначение осталось у своего узла
Представим, что подпись «Устройство работает?» хочется сократить до «Включается?». Внешне задача маленькая. Но включение ещё не тождественно работоспособности в заданных правилах. С такой заменой я верну вопрос владельцу процесса: что именно должен проверять принимающий?
В нашей спецификации N3 означает проверку работы. При обсуждении новой подписи я сохраняю эту связь. Если N3 внезапно станет проверкой комплекта, наличие знакомого обозначения уже ничего не подтвердит. Мне нужна прежняя роль узла, а не только те же буквы в первой колонке.
Для редакторской попытки можно написать:
Предложи более короткую подпись к N3, сохранив смысл вопроса «Устройство работает?». Не меняй обозначения существующих узлов и не переназначай их другим действиям. Отдельно объясни, не стал ли новый вариант уже исходного. Если без уточнения критерия сократить нельзя, оставь принятую подпись.
Правило для следующей редакции
Уникальные обозначения в первом ответе не закрепляются навсегда сами собой. Поэтому в запрос на продолжение я добавляю отдельное условие: существующие узлы не перенумеровывать и не присваивать их имена другим действиям. Для новых элементов использовать новые обозначения, а удалённые перечислять отдельно.
Мне нужны три вида изменений:
прежний узел с уточнённой подписью или явно согласованным условием;
новый узел с новым обозначением;
удалённый узел с объяснением, куда делась его работа или проверка.
Это инструкция для подготовки редакции. После ответа её исполнение нужно проверить. Я не считаю знакомый набор N1–N5 доказательством, что схема осталась прежней: обозначения могут сохраниться, а смысл под ними поменяться.
Вот учебный антипример, составленный мной для сверки, а не полученный ответ продукта:
```text
Принятая запись:
N2 — Комплект полный?
N3 — Устройство работает?
Запись для отклонения:
N2 — Устройство работает?
N3 — Комплект полный?
```
В обоих списках имена уникальны. Но если переходы механически остались прежними, сначала будут проверять работу, а не комплект. Проверка «все обозначения на месте» этого не поймает. Нужно сопоставить каждое имя с его вопросом и ролью в принятой процедуре.
При настоящем изменении условия я сохраняю прежнюю и новую формулировки рядом. Тогда видно, что согласовали другое действие или критерий. Если добавили проверку, я хочу увидеть её новое имя и связи, а не узнать о ней из переименованного старого блока.
Приём 3. Сверяю редакции без «стрелки слева»
Когда рисунок станет плотнее, блоки придётся двигать. Комментарий, связанный с N2, переживёт такую перестановку; комментарий о левой стороне может устареть. Поэтому перед передачей я перевожу пространственные замечания в записи о содержании.
Расплывчатое замечание · Как я его уточняю
«Из верхней проверки не туда» — «Из N2 при ответе “Нет” нужен переход к N5»
«У нижнего блока плохое название» — «У N5 уточнить подпись передачи, не меняя его роль завершения»
«Здесь слишком длинно» — «У N3 предложить короткую подпись без сужения критерия»
После редакции я отдельно сверяю перечень узлов и сами связи. Все прежние обозначения на месте? Изменён именно названный переход? Остальные условия сохранились? Эти вопросы относятся к содержанию, даже когда поводом была компоновка страницы.
Следующий запрос может быть таким:
Сопоставь две текстовые редакции по обозначениям узлов и их ролям. Перечисли изменения подписей отдельно от изменений переходов, новые и удалённые узлы — отдельными списками. Проверь, не присвоено ли прежнее имя другой проверке. Не выбирай правило по своему усмотрению: назови места для подтверждения.
Такой список поможет увидеть разницу, но не заменит согласование. Я читаю его вместе с исходными правилами: изменение одной подписи может потребовать вопроса к владельцу процесса. Сначала принимаю содержание замечаний, затем новую компоновку страницы.
Роль N5 в моём примере — передача человеку. Если в новой редакции под тем же именем окажется «отремонтировать», я отмечу изменение роли, даже при прежних стрелках. Его нужно согласовать как новое правило, а не принять как другое оформление.
Перед передачей материалов я делаю короткий проход:
Сохраняю принятую текстовую редакцию вместе с обозначениями.
Записываю каждое замечание к конкретному узлу или переходу.
Отделяю правки оформления от новых условий.
Передаю вопросы о критериях владельцу процедуры.
Сверяю оформленную страницу с принятым текстом.
В сопроводительном сообщении я указываю принятую редакцию: иначе точное замечание может попасть к устаревшей таблице обозначений. Одного совпадения имени файла для такой сверки мне недостаточно.
Прежде чем добавлять к возврату проектора другие этапы, можно свериться с разбором схем. Для следующих задач соотнеси свой доступ с возможностями тарифов. Я бы сначала довёл до однозначности замечания к этим пяти узлам, а уже потом расширял процесс.
Проверь своё последнее замечание к схеме: мысленно переставь блоки на странице. Если после этого непонятно, что менять, допиши начало перехода, ответ на условие и конечный узел. Затем отдай запись другому человеку без указания пальцем на экран.
LibraChatнейросетиобсуждение редакций схемы возврата проектора через устойчивые обозначения узловпрактиказадачи с ИИ
