Несколько идей: 1. Общаться по работе можно только в чате по определенной задаче, чтобы всё, что относится к этой задаче, было в одном месте, а не размазано по нескольким чатам. С другой стороны, всё, что отсутствует в чате, не является частью задачи, то есть, должны быть средства легкого импорта из всех каналов связи (электронная почта и др.) и со страниц интернета/интранета (включая Confluence), прикрепления файлов и т.п. 2. Перед отправкой сообщения в чат нужно пройти капчу, чтобы чат не засорялся небрежными обрывками фраз тех, кто через каждые три слова нажимают Enter (это те же самые люди, которые не используют заглавные буквы, знаки препинания, абзацы, склонения и спряжения) 3. Чат должен иметь некоторую "учетную часть" - содержать сведения, которые обычно имеются по задаче в таск-трекере (название, кому поручено, статус и т.д.) 4. Должна быть сущность, динамически объединяющая несколько задач в ТЗ 5. Эмодзи, голосовые сообщения и т.п. должны быть недоступны
Использование Snowflake для генерации уникальных ID требует координации и, следовательно, слишком сложной логики. Вместо этого предлагаю UUIDv7 с кодированием в Base62. При этом вообще не нужна координация. Будет 22 URL-безопасных символа против ~11 у Snowflake. Для сокращения ссылок это не критично, зато проще.
Эта статья не является полным и окончательным описанием нужной системы формирования ТЗ. Чтобы такая система хорошо работала, многое нужно додумать. Написание ТЗ - это всегда итерационный процесс, и это не меняется от того, что у нас теперь набор связанных документов, а не единое монолитное ТЗ. Да, можно привлечь ИИ к формированию нужного набора связанных документов, но потом придется посмотреть на результат и внести правки. Про "автособирание" ТЗ в статье не говорится. Один человек, исходя из своих обстоятельств соберет так, другой - иначе.
Но вся прелесть этого подхода в том, что сборное ТЗ легко актуализируется и поэтому отражает актуальное состояние системы. А внесение правок в монолитное 200-страничное ТЗ требует огромных редакторских усилий, и поэтому откладывается на потом (навсегда). Нужно сделать какую-то задачу проекта - написали одностраничный документ - связали ссылками с другими. Всё. Нужно внести правки в определенный документ - внесли правки только в этот документ, не думая об оглавлении, нумерации страниц и рисунков и т.п. Всегда понятно, когда именно внесена правка в одностраничный документ, чего не скажешь о 200-страничном ТЗ, где по 10 правок в день в разных местах. Если нужно получить общее представление о проектируемой системе, прошли по ссылкам, сделали обзор, оглавление, индекс. Если нужно поручить разработку исполнителю, сформировали перечень связанных документов, отослали исполнителю.
А как же единство и целостность разрабатываемой системы? А для этого есть архитектурные документы (разнообразные диаграммы и т.п.), и не нужно смешивать это с техническим заданием.
А разве монолитное ТЗ избавлено от внезапных правок? Правки должны согласовываться заказчиком с исполнителем и реализовываться в дополнительное время за отдельную плату, и тогда не будет проблем. А форма ТЗ не имеет к этому отношения. В статье нет ничего про то, что "не нужны какие-то аналитики, постановщики, архитекторы, которые будут читать весь документ, являться его автором и отвечать за его целостность и непротиворечивость". Это Вы от себя добавили.
Видимо, Вы работали без системного аналитика, который должен отвечать за целостность и непротиворечивость ТЗ. Безусловно, версионность ТЗ - это обязательное требованние. Ну и согласование изменений, а также уведомления об изменениях.
С чего Вы взяли, что Хабр - сайт для публикации статей, написанных людьми? Из глупого поспешно принятого пункта 4 каких-то там правил? Да этот пункт не проживет и нескольких лет, и его отменят. Для меня Хабр - сайт в основном не для публикации, а для чтения. Хотя деньги Хабру приносят корпоративные блоги, которые никто не читает, но без читателей некорпоративных статей не будет и выгодных корпоративных блогов. А читателей привлекают привлекательные статьи, а не статьи, на 100% "ручной работы". Поэтому пункт 4 бьет по экономике Хабра и будет рано или поздно отменен.
Я предпочитаю хорошие статьи, написанные с использованием ИИ, плохим статьям, написанным на 100% людьми. Мне, например, интереснее прочитать сгенерированную или отредактированную с помощью ИИ статью, если автор промпта или исходного текста смог сформулировать уникальную и полезную идею или добыть интересные сведения. Поэтому для меня борьба с ИИ - это "охота на ведьм".
С другой стороны, ленивые авторы выкладывают творения ИИ как есть, не утруждая себя редактированием текста. Ну так не читайте такие статьи. Если кто-то сильно боится потратить время на отсев таких статей, можно для него рассчитывать индикатор нейрослопности и дать соответствующий фильтр. Но реальная проблема не в сгенерированных статьях, а в отсутствии удобного механизма фильтрации статей по интересам читателей.
Мне не понравились принципы, которыми руководствовался автор. Зачем исторически сложившиеся трудности и проблемы кириллицы (legacy code) и орфографические ребусы перетаскивать в латиницу? Зачем тащить в нее транслитерацию и прежние неудачные варианты латиницы? Зачем ориентироваться на существующую раскладку клавиатуры? В результате эту латиницу невозможно прочитать не запинаясь. Хороший проект нужно начинать "с чистого листа", а не заниматься археологическими раскопками и воспроизведением прежних ошибок. Но вполне можно и нужно заимствовать удачные решения из других языков. Предлагаю свой вариант, основанный на фонетическом принципе, насколько это возможно. Ниже образцы.
Kak peredayot naš korrespondent, včera nad centraĺnîmi rayonami Penzenskoy oblasti prošla nebîvaloy silî groza. V räde mest bîli povalenî telegrafnîye stolbî, porvanî provoda, s kornem vîrvanî stoletniye derev́ya. V dvuh derevnäh voznikli požarî v rezuĺtate udara molnii. K etomu pribaviloś yeşo odno stihiynoye bedstviye: livnevîy dožd́ mestami vîzval siĺnoye navodneniye. Nanesön nekotorîy uşerb seĺskomu hozäystvu. Vremenno bîlo prervano železnodorožnoye i avtomobiĺnoye soobşeniye meždu sosednimi rayonami.
V Starom gorode, na veršine gorî Mtacminda, nahoditsa glavnaya dostoprimečateĺnost́ Tbilisi – krepost́ Narikala, postroyennaya persami yeşo v 4 veke i razrušennaya zemleträseniyem 1827 g. V 1990 g. zdeś bîla vosstanovlena cerkov́ Sv. Nikolaya s freskami, izobražayuşimi bibleyskiye scenî i istoričeskiye sobîtiya Gruzii. S veršinî Mtacmindî otkrîvayetsa velikolepnîy vid na gorod, a u yeyo podnožiya otkrît botaničeskiy sad – iskusstvennîy zapovednik ploşad́yu 128 ga. Spustivšiś po unikaĺnoy Vifleyemskoy ulice-lestnice, možno popast́ k Sionskomu soboru. On bîl sooružon v 6 veke, razrušen arabami i vozvedön zanovo 6 stoletiy spustä. Imenno zdeś hranitsa glavnaya hristianskaya relikviya Gruzii – drevniy krest Sv. Ninî.
Вставьте эти образцы текста в Google Переводчик, и Вы получите почти безошибочный перевод с несуществующего языка. Google Переводчик понимает его без обучения, в том числе диакритику.
Спасибо, про RMS и Doorstop не знал, посмотрю. Формально это тот же класс, и Doorstop ближе всего по духу, потому что требования в нем живут рядом с работой, а не в отдельном хранилище.
Но RMS, включая Doorstop, управляют требованиями, которые уже сформулированы и помещены в систему. Моя идея в другом. Я предлагаю не создавать еще одно дублирующее хранилище документации, а собирать ТЗ из того, что и так происходит в задачах, переписке и согласованиях. Не нужно писать требование в RMS, оно уже есть в процессе, нужно только связать и показать.
Doorstop хранит требования в репозитории, а значит предполагает, что аналитик работает с гитом. Аналитики, в отличие от разработчиков, с гитом, как правило, не работают, и это не их зона ответственности. Иначе им пришлось бы освоить ветки, конфликты, merge, pull request, а это серьезные навыки, которые от аналитиков не требуются. Кроме того, в документации много нетекстовой информации (таблицы, диаграммы). Аналитик – не разработчик, и это нормально. Поэтому идея “документация как код (в git)” и не получила широкого распространения.
Моя идея несколько отличается от RMS. Плоская модель вместо дерева, а также извлечение из каналов вместо ручного ввода. Но главное даже не это. Не нужно дублировать задачи Jira в Confluence или Word. Требование живет в задаче, со связями, историей и согласованием. ТЗ становится выборкой таких задач, а не отдельным документом, который надо писать и поддерживать.
У робота есть сенсоры - какие угодно (радар, лидар, видеокамера, тактильный, магнитометр, камера ночного видения, гироскоп, акселерометр, GPS). У него есть цифровая карта местности. Впереди летят квадрокоптеры и доразведывают маршрут с точностью до сантиметра. Робот всегда может положиться на радиоуправление из базового лагеря. Роботу нипочем ураганный ветер и холод. Роботы уже ездят по городским улицам и по Марсу, делают сальто. Так что я не вижу никаких непреодолимых препятствий к тому, чтобы роботы могли проходить те же горные маршруты, что и альпинисты. Единственное исключение - когда большие размеры робота не позволяют ему протиснуться через какую-то узость, но это больше относится к пещерам ("шкуродеры"), чем к горным вершинам. И такой участок можно и обойти.
Я думаю на этим. Но задача почти неразрешимая из-за низкой плотности воздуха и ураганных ветров. Вертолет высоко не поднимается, коптер способен поднять на большую высоту (и спустить вниз) пару килограммов максимум, аэростат сносит ураганным ветром. Есть одна идея, но маловероятно, что она реализуема.
Государство прямо разорилось! 12 спасателей на "точку притяжения" всей страны. Да налоги на бизнес, который крутится вокруг Эльбруса, в тысячи раз больше! Или, может быть, окружить Эльбрус кордонами, чтобы вообще не тратиться? Правда, на охранников больше денег уйдет.
Уж лучше бордюры и тротуары каждый год перекладывать, чем людей спасать. А вот Вы как влияете на то, куда идут налоги с Вас? Все остальные расходы Вас устраивают?
И сколько Вы уже заплатили? Вы правительству Непала платили или Китая (Эверест как раз там)? Судя по тому, что на спасательные мероприятия денег почти нет, и альпинистов оставляют умирать, Вы заплатили очень немного. И кто тонет, тот пусть предварительно оплатит работу спасателей на год вперед (спасение утопающих ... сами знаете). А уж автолюбителям, попавшим в ДТП, точно не нужно предоставлять услуги государственной медицины - пусть покупают частную медстраховку или продают квартиру.
Вы очень хорошо знаете, что именно другие должны делать или не делать и как они должны жить и энергично трудиться исключительно для пользы общества и решения мировых проблем. А сами ведете образ жизни, приятный всем окружающим, и ничего после себя не оставляете. А люди, которым нравятся горы, - ну пусть себе умирают, так как не вписываются в Вашу картину мира и сами виноваты в своих увлечениях. И вообще, меньше людей - меньше мусора.
Кодируйте UUIDv7 в выгузках в компактный текстовый формат. А вообще сравнивать идентификаторы глазами - это плохая идея. Пользователи вообще не должны видеть идентификаторы, ведь им нужны бизнес-данные. А для внешних потребителей нужно использовать стандартизованные классификаторы и преобразовывать суррогатные ключи в натуральные, действительные в отчетную дату.
Надо сказать, что ИИ в основном агрегируют те меры, которые уже предлагаются или описываются в интернете. Но хотелось бы видеть более творческий подход, основанный на глубоком анализе, а также на исследовании эффективности и побочных эффектов сложившейся практики в разных странах.
Например, формально поддерживаемый законодательством бессрочный наём фактически не работает. Заемный труд и принуждение к увольнению широко распространены. Нужно не закрывать на это глаза, а искать продуманные альтернативные решения, отвечающие интересам и работников/соискателей, и бизнеса. Трудовые отношения нужно вернуть в правовое поле и адаптировать к современным вызовам (удаленная работа, проектная работа, ротация и "горизонтальный рост", искусственный интеллект, гибкие организационные структуры и т.д.).
Несколько идей:
1. Общаться по работе можно только в чате по определенной задаче, чтобы всё, что относится к этой задаче, было в одном месте, а не размазано по нескольким чатам. С другой стороны, всё, что отсутствует в чате, не является частью задачи, то есть, должны быть средства легкого импорта из всех каналов связи (электронная почта и др.) и со страниц интернета/интранета (включая Confluence), прикрепления файлов и т.п.
2. Перед отправкой сообщения в чат нужно пройти капчу, чтобы чат не засорялся небрежными обрывками фраз тех, кто через каждые три слова нажимают Enter (это те же самые люди, которые не используют заглавные буквы, знаки препинания, абзацы, склонения и спряжения)
3. Чат должен иметь некоторую "учетную часть" - содержать сведения, которые обычно имеются по задаче в таск-трекере (название, кому поручено, статус и т.д.)
4. Должна быть сущность, динамически объединяющая несколько задач в ТЗ
5. Эмодзи, голосовые сообщения и т.п. должны быть недоступны
Использование Snowflake для генерации уникальных ID требует координации и, следовательно, слишком сложной логики. Вместо этого предлагаю UUIDv7 с кодированием в Base62. При этом вообще не нужна координация. Будет 22 URL-безопасных символа против ~11 у Snowflake. Для сокращения ссылок это не критично, зато проще.
Эта статья не является полным и окончательным описанием нужной системы формирования ТЗ. Чтобы такая система хорошо работала, многое нужно додумать. Написание ТЗ - это всегда итерационный процесс, и это не меняется от того, что у нас теперь набор связанных документов, а не единое монолитное ТЗ. Да, можно привлечь ИИ к формированию нужного набора связанных документов, но потом придется посмотреть на результат и внести правки. Про "автособирание" ТЗ в статье не говорится. Один человек, исходя из своих обстоятельств соберет так, другой - иначе.
Но вся прелесть этого подхода в том, что сборное ТЗ легко актуализируется и поэтому отражает актуальное состояние системы. А внесение правок в монолитное 200-страничное ТЗ требует огромных редакторских усилий, и поэтому откладывается на потом (навсегда). Нужно сделать какую-то задачу проекта - написали одностраничный документ - связали ссылками с другими. Всё. Нужно внести правки в определенный документ - внесли правки только в этот документ, не думая об оглавлении, нумерации страниц и рисунков и т.п. Всегда понятно, когда именно внесена правка в одностраничный документ, чего не скажешь о 200-страничном ТЗ, где по 10 правок в день в разных местах. Если нужно получить общее представление о проектируемой системе, прошли по ссылкам, сделали обзор, оглавление, индекс. Если нужно поручить разработку исполнителю, сформировали перечень связанных документов, отослали исполнителю.
А как же единство и целостность разрабатываемой системы? А для этого есть архитектурные документы (разнообразные диаграммы и т.п.), и не нужно смешивать это с техническим заданием.
Версионироваь можно не только "классическое ТЗ", но и каждую задачу или их набор.
А разве монолитное ТЗ избавлено от внезапных правок? Правки должны согласовываться заказчиком с исполнителем и реализовываться в дополнительное время за отдельную плату, и тогда не будет проблем. А форма ТЗ не имеет к этому отношения. В статье нет ничего про то, что "не нужны какие-то аналитики, постановщики, архитекторы, которые будут читать весь документ, являться его автором и отвечать за его целостность и непротиворечивость". Это Вы от себя добавили.
Видимо, Вы работали без системного аналитика, который должен отвечать за целостность и непротиворечивость ТЗ. Безусловно, версионность ТЗ - это обязательное требованние. Ну и согласование изменений, а также уведомления об изменениях.
С чего Вы взяли, что Хабр - сайт для публикации статей, написанных людьми? Из глупого поспешно принятого пункта 4 каких-то там правил? Да этот пункт не проживет и нескольких лет, и его отменят. Для меня Хабр - сайт в основном не
для публикации, адля чтения. Хотя деньги Хабру приносят корпоративные блоги, которые никто не читает, но без читателей некорпоративных статей не будет и выгодных корпоративных блогов. А читателей привлекаютпривлекательныестатьи, а не статьи, на 100% "ручной работы". Поэтому пункт 4 бьет по экономике Хабра и будет рано или поздно отменен.Я предпочитаю хорошие статьи, написанные с использованием ИИ, плохим статьям, написанным на 100% людьми. Мне, например, интереснее прочитать сгенерированную или отредактированную с помощью ИИ статью, если автор промпта или исходного текста смог сформулировать уникальную и полезную идею или добыть интересные сведения. Поэтому для меня борьба с ИИ - это "охота на ведьм".
С другой стороны, ленивые авторы выкладывают творения ИИ как есть, не утруждая себя редактированием текста. Ну так не читайте такие статьи. Если кто-то сильно боится потратить время на отсев таких статей, можно для него рассчитывать индикатор нейрослопности и дать соответствующий фильтр. Но реальная проблема не в сгенерированных статьях, а в отсутствии удобного механизма фильтрации статей по интересам читателей.
Мне не понравились принципы, которыми руководствовался автор. Зачем исторически сложившиеся трудности и проблемы кириллицы (legacy code) и орфографические ребусы перетаскивать в латиницу? Зачем тащить в нее транслитерацию и прежние неудачные варианты латиницы? Зачем ориентироваться на существующую раскладку клавиатуры? В результате эту латиницу невозможно прочитать не запинаясь. Хороший проект нужно начинать "с чистого листа", а не заниматься археологическими раскопками и воспроизведением прежних ошибок. Но вполне можно и нужно заимствовать удачные решения из других языков. Предлагаю свой вариант, основанный на фонетическом принципе, насколько это возможно. Ниже образцы.
Kak peredayot naš korrespondent, včera nad centraĺnîmi rayonami Penzenskoy oblasti prošla nebîvaloy silî groza. V räde mest bîli povalenî telegrafnîye stolbî, porvanî provoda, s kornem vîrvanî stoletniye derev́ya. V dvuh derevnäh voznikli požarî v rezuĺtate udara molnii. K etomu pribaviloś yeşo odno stihiynoye bedstviye: livnevîy dožd́ mestami vîzval siĺnoye navodneniye. Nanesön nekotorîy uşerb seĺskomu hozäystvu. Vremenno bîlo prervano železnodorožnoye i avtomobiĺnoye soobşeniye meždu sosednimi rayonami.
V Starom gorode, na veršine gorî Mtacminda, nahoditsa glavnaya dostoprimečateĺnost́ Tbilisi – krepost́ Narikala, postroyennaya persami yeşo v 4 veke i razrušennaya zemleträseniyem 1827 g. V 1990 g. zdeś bîla vosstanovlena cerkov́ Sv. Nikolaya s freskami, izobražayuşimi bibleyskiye scenî i istoričeskiye sobîtiya Gruzii. S veršinî Mtacmindî otkrîvayetsa velikolepnîy vid na gorod, a u yeyo podnožiya otkrît botaničeskiy sad – iskusstvennîy zapovednik ploşad́yu 128 ga. Spustivšiś po unikaĺnoy Vifleyemskoy ulice-lestnice, možno popast́ k Sionskomu soboru. On bîl sooružon v 6 veke, razrušen arabami i vozvedön zanovo 6 stoletiy spustä. Imenno zdeś hranitsa glavnaya hristianskaya relikviya Gruzii – drevniy krest Sv. Ninî.
Avtomir, Azbuka Vkusa, Alönka, Aĺfa-bank, AMEDIA, AST Izdateĺskaya gruppa, ATON, Aeroflot, Babayevskiy, Bazovîy Element, Baltika, Bank Moskvî, Bank Sankt-Peterburg, Bilayn, Vedomosti, Vimm-Bilĺ-Dann, Gazeĺ, Gazprom, Domik v derevne, DON-Stroy, Dîmov, Yevraz, YEVROCEMENT Grup, Ingosstrah, INMARKO, Intêko, Intêrros, Kasperskiy, Kalašnikov, Kamaz, Kafê Puškin, Kommersant, Korkunov, Kotofey, Krasnaya Liniya, Lukoyl, Magnit, Makfa, Maša i Medved́, Megafon, Metalloinvest, Mečel, Noriĺskiy nikeĺ, Odnoklassniki.ru, Pervîy kanal, Renova, RŽD, Rosneft́, Rosoboronêksport, Rostelekom, Rusagro, Rusal, Sberbank Rossii, Sväznoy, Snežnaya Koroleva, Surgutneftegaz, Suhoy, Tatneft́, Teremok, Tehnosila, Tonus, Uralkaliy, Čerkizovskiy, Čistaya Liniya, Štolle, Ekspediciya, Ekspert
U horoših lüdey zažigayutsa yarkiye yolki,
U horoših lüdey za stolami teplo i svetlo.
Nehoroših lüdey syeli strašnîye serîye volki,
I sledî teh volkov novogodney purgoy zamelo.
Вставьте эти образцы текста в Google Переводчик, и Вы получите почти безошибочный перевод с несуществующего языка. Google Переводчик понимает его без обучения, в том числе диакритику.
Спасибо, про RMS и Doorstop не знал, посмотрю. Формально это тот же класс, и Doorstop ближе всего по духу, потому что требования в нем живут рядом с работой, а не в отдельном хранилище.
Но RMS, включая Doorstop, управляют требованиями, которые уже сформулированы и помещены в систему. Моя идея в другом. Я предлагаю не создавать еще одно дублирующее хранилище документации, а собирать ТЗ из того, что и так происходит в задачах, переписке и согласованиях. Не нужно писать требование в RMS, оно уже есть в процессе, нужно только связать и показать.
Doorstop хранит требования в репозитории, а значит предполагает, что аналитик работает с гитом. Аналитики, в отличие от разработчиков, с гитом, как правило, не работают, и это не их зона ответственности. Иначе им пришлось бы освоить ветки, конфликты, merge, pull request, а это серьезные навыки, которые от аналитиков не требуются. Кроме того, в документации много нетекстовой информации (таблицы, диаграммы). Аналитик – не разработчик, и это нормально. Поэтому идея “документация как код (в git)” и не получила широкого распространения.
Моя идея несколько отличается от RMS. Плоская модель вместо дерева, а также извлечение из каналов вместо ручного ввода. Но главное даже не это. Не нужно дублировать задачи Jira в Confluence или Word. Требование живет в задаче, со связями, историей и согласованием. ТЗ становится выборкой таких задач, а не отдельным документом, который надо писать и поддерживать.
У робота есть сенсоры - какие угодно (радар, лидар, видеокамера, тактильный, магнитометр, камера ночного видения, гироскоп, акселерометр, GPS). У него есть цифровая карта местности. Впереди летят квадрокоптеры и доразведывают маршрут с точностью до сантиметра. Робот всегда может положиться на радиоуправление из базового лагеря. Роботу нипочем ураганный ветер и холод. Роботы уже ездят по городским улицам и по Марсу, делают сальто. Так что я не вижу никаких непреодолимых препятствий к тому, чтобы роботы могли проходить те же горные маршруты, что и альпинисты. Единственное исключение - когда большие размеры робота не позволяют ему протиснуться через какую-то узость, но это больше относится к пещерам ("шкуродеры"), чем к горным вершинам. И такой участок можно и обойти.
Я думаю на этим. Но задача почти неразрешимая из-за низкой плотности воздуха и ураганных ветров. Вертолет высоко не поднимается, коптер способен поднять на большую высоту (и спустить вниз) пару килограммов максимум, аэростат сносит ураганным ветром. Есть одна идея, но маловероятно, что она реализуема.
Знаете, сколько стоит лицензия на восхождение на Эверест?
В стоимость стандартного пакета «всё включено» входят:
Официальный пермит (разрешение) Непала - 15 000 $ (около 1 150 000 рублей)
Экологический сбор (мусорный депозит) - 4 000 $ (около 310 000 рублей)
А потом этих людей за такие деньги оставляют умирать на горе.
Я в принципе не против обязательного страхования, но дьявол как всегда в деталях.
Горным туризмом, много лет, до 3 к.с. включительно. А если не переходить на личности, то что Вас смущает в концепции?
Государство прямо разорилось! 12 спасателей на "точку притяжения" всей страны. Да налоги на бизнес, который крутится вокруг Эльбруса, в тысячи раз больше! Или, может быть, окружить Эльбрус кордонами, чтобы вообще не тратиться? Правда, на охранников больше денег уйдет.
Уж лучше бордюры и тротуары каждый год перекладывать, чем людей спасать. А вот Вы как влияете на то, куда идут налоги с Вас? Все остальные расходы Вас устраивают?
И сколько Вы уже заплатили? Вы правительству Непала платили или Китая (Эверест как раз там)? Судя по тому, что на спасательные мероприятия денег почти нет, и альпинистов оставляют умирать, Вы заплатили очень немного. И кто тонет, тот пусть предварительно оплатит работу спасателей на год вперед (спасение утопающих ... сами знаете). А уж автолюбителям, попавшим в ДТП, точно не нужно предоставлять услуги государственной медицины - пусть покупают частную медстраховку или продают квартиру.
Вы очень хорошо знаете, что именно другие должны делать или не делать и как они должны жить и энергично трудиться исключительно для пользы общества и решения мировых проблем. А сами ведете образ жизни, приятный всем окружающим, и ничего после себя не оставляете. А люди, которым нравятся горы, - ну пусть себе умирают, так как не вписываются в Вашу картину мира и сами виноваты в своих увлечениях. И вообще, меньше людей - меньше мусора.
Кодируйте UUIDv7 в выгузках в компактный текстовый формат. А вообще сравнивать идентификаторы глазами - это плохая идея. Пользователи вообще не должны видеть идентификаторы, ведь им нужны бизнес-данные. А для внешних потребителей нужно использовать стандартизованные классификаторы и преобразовывать суррогатные ключи в натуральные, действительные в отчетную дату.
А можно ли сделать так, чтобы LLM-ка сама последовательно задавала все необходимые уточняющие вопросы промпта с учетом того, что ей уже известно?
А вот какие решения проблемы предложил искусственный интеллект DeepSeek: https://chat.deepseek.com/share/ptfw1ihgzjp9iorbpw
Я с большим интересом это прочитал. Надо сказать, что ответ DeepSeek превзошел мои ожидания. Это вовсе не AI slop, а весьма продуманная система мер.
А вот, что предложил Perplexity без использования мощных платных моделей (LLM): https://www.perplexity.ai/search/2136f90b-8760-44d0-afd2-b01d94fe478e
Не так блестяще, но тоже интересно.
Надо сказать, что ИИ в основном агрегируют те меры, которые уже предлагаются или описываются в интернете. Но хотелось бы видеть более творческий подход, основанный на глубоком анализе, а также на исследовании эффективности и побочных эффектов сложившейся практики в разных странах.
Например, формально поддерживаемый законодательством бессрочный наём фактически не работает. Заемный труд и принуждение к увольнению широко распространены. Нужно не закрывать на это глаза, а искать продуманные альтернативные решения, отвечающие интересам и работников/соискателей, и бизнеса. Трудовые отношения нужно вернуть в правовое поле и адаптировать к современным вызовам (удаленная работа, проектная работа, ротация и "горизонтальный рост", искусственный интеллект, гибкие организационные структуры и т.д.).