Привязывайте документы по устранению неполадок к реальным строкам ошибок до их составления в модели

Таблицы устранения неполадок — единственная документация, которую большинство пользователей читают, когда что-то уже сломано, что делает их худшим местом для выдуманной причины. Самый дешевый шлюз, который я знаю, одновременно и самый скучный: требовать, чтобы каждая строка заключала в кавычки строку ошибки, которая существует на сегодняшний день в репозитории, и отклонять любую строку, цитата которой не может быть найдена. Все, что написано ниже, посвящено построению этих ворот, а не тому, чтобы подсказать вам путь к улучшению прозы. Режим отказа носит структурный, а не стилистический характер. Модель, которую просят «документировать распространенные ошибки», будет генерировать симптомы и пары, которые хорошо читаются, потому что правдоподобие — это именно то, что вознаграждает обучающий сигнал. Затем рецензент должен решить, строка за строкой, описывает ли абзац что-то, что на самом деле может сделать код, и это решение обходится дорого. Сопоставление строк вообще не является оценкой, поэтому оно должно выполняться первым и компенсировать самые простые ошибки. Почему строка ошибки — самый дешевый доступный якорь Сообщения об ошибках представляют собой литералы в исходном коде, поэтому их можно извлекать и сравнивать без какого-либо семантического понимания. Это свойство делает их лучшим якорем, чем заголовки, названия продуктов или ссылки на билеты, которые бесшумно дрейфуют. Строка, которая цитирует реальные