Comments 11
Что-то никак нет ухода от крайностей - текстовый редактор уровня "консоль" и чистый WYSIWYG, нужно что-то среднее между LaTeX и окончательной вёрсткой. То есть должна быть полная взаимосвязь между элементами того что в графике и сам текст хотя-бы имел минимальный скетч из атрибутов - положение, размер шрифта даже если это моноспейс, верхний-нижний индекс. Тогда в окончательную вёрстку попадает полный стиль набор а в промежуточную только прибитое к некоторому условному форматированию. Тоже самое про программирование разделов, нумерации, глав итд. В ворде это сделано как линейный список, годный только для книг. Для более сложной документации содержащей перекрёстные ссылки этот подход не годен, в этом случае там нумерация будет почти как вручную текстом просто сгенерированная автоматически.
В любом случае пришли, что некая парадигма IDE оптимальна. Здесь еще надол учитывать порог входа для работы с такими инстурментами, особенно если задача перевести на них хардкорных гост-техписателей. Поэтому вопрос GUI тоже очень важным, чтобы была интуитивность в работе. В принципе то, к чему мы пришли не заключена в рамки только ГОСТ-документации. Можно задать любой типовой набор стилей Word и в бой!)
Интересная штука. Хотел потыкать, но у вас регистрация только по приглашениям. Судя по описанию и скринам интерфейса (здесь и у вас на сайте), я бы сказал, вашей системе недостаёт векторного поиска. Полезная штука, когда документации много и коррелирует с вашими планами - я имею в виду ИИ помощника (RAG)
Я наверно очевидность скажу - но не проще сюда ИИшку прикрутить, она все и поменяет.
В случае массивной документации если просто " в лоб" просить ИИ решить задачу, то упирались в 2 ограничения: лимит контекстного окна и большой расход токенов (несколько сотен тысяч). Поэтому в принципе видим сервис как инструмент качественного структурирования промпта и способ экономии токенов, так большой расход токенов на "выходе" еще терпим, но то что нужно давать много контекста, это сильно "засоряет" общение с LLM. Даже векторная база через RAG с ходу все эти вопросы не решает. Отдельным материалом еще расскажу про это)
Молодцы, конечно, но есть же такие развитые технологии как Docbook и DITA и есть XML-редакторы их поддерживающие, например, oXygen XML Editor. Поддерживается:
1. Принцип единого источника. Документ в Oxygen можно собирать из "кирпичиков" – из разных текстов, хранящихся в других файлах.
2. Профилирование. Блоки данных можно помечать специальными атрибутами, которые отвечают за публикацию документа в той или иной интерпретации. Перед публикацией отмечается нужная интерпретация и какие-то блоки печатаются, а какие-то, не относящиеся к этой интерпретации, игнорируются.
3. Отделение оформления от содержания. Писатель работает только с содержанием и разметкой. Стили форматирования элементов разметки прописаны в других файлах и после настройки не меняются.
4. Многоформатность. Публикация возможно в различные форматы (PDF, Word, HTML...).
Самое сложное будет, особенно с необходимостью писать по ГОСТу настроить стили в п.3. А потом все идет как по маслу.
Именно в случае ГОСТа самым тяжелым оказалось решить вопрос правильного рендеринга DOCX и из него впоследствии PDF. Вся ГОСТ с документация с "рамками" это прям оформительская боль, так как это оформляется в логике Word как колонтитул, далее используются разные форматы колотитулов для титульного листа, оглавления и основной части + элементы переменных внутри колонтитулов. То есть все что мы пробовали приводила к получению полуфабрикатных документов, которые все равно приходилось дополнительно форматировать руками. Надеюс в отдельной статье чуть больше технической деталей опишу, как мы в итог это решили + еще заложили вариативность, что можно свободно менять форматирование при генерации (например в ГОСТе 2 шрифта допустимы: Times New Roman и GOST).
И еще нам стало очень удобно подключать ИИ-ассистента, когда это свое решение, то больше есть поле для экспериментов с этим. В перспектие дойдем до своего MCP.
Как мы избавились от копипаста в технической документации