Если в ваших шаблонах промптов до сих пор живёт «подумай шаг за шагом», его можно удалять.
⠀
Addy Osmani выпустил в блоге Claude разбор, как выжать максимум из Opus 5.5. Про 1С там ни слова, но советы ложатся на нашу работу почти без переделки.
⠀
Многое оттуда 1С-ники с настроенным harness (харнес, программная обвязка вокруг модели) делали и до выхода Opus 5.5. Те же критерии готовности в спецификации или стоп-лист опасных команд. Новая модель работает чуть лучше, даже когда обвязки нет.
Кстати, как настроить harness для 1С, я рассказал в мини-курсе: https://lapits.ru/ai-course/
⠀
Советы из статьи Osmani и как они выглядят в 1С:
⠀
1. Отдайте агенту задачу целиком, сразу задайте критерий готовности и не мешайте. Opus 5.5 держит многошаговую работу дольше прошлых версий, так что дёргать её незачем. Думает она тоже сама, перед каждым ответом. Отсюда и совет выкинуть «думай внимательно»: по тестам без этих фраз ответ начинается быстрее, а качество не падает.
⠀
В 1С критерий готовности лучше задавать проверкой, которую можно запустить (пример):
⠀
Переведи модальные вызовы в формах подсистемы «Продажи» на асинхронные.
Критерий готовности: проверка конфигурации с поиском использования модальности по этим формам чистая, конфигурация загружается в тестовую базу.
Спрашивай, только если проверка упала и ты не понимаешь почему.
⠀
Заметьте, списка методов тут нет. Какие вызовы модальные, модель знает сама, а проверит платформа.
⠀
2. Раз модель долго работает без присмотра, пропишите в CLAUDE.md, где ей останавливаться: если без вас дальше никак или следующий шаг может сломать базу так, что её придётся поднимать из бэкапа. Стоп-лист у нас до боли знакомый, пишите его прямо: /UpdateDBCfg на рабочей базе, помещение в хранилище, снятие типового объекта с поддержки, удаление реквизита с данными.
⠀
3. Большую работу статья предлагает делить между субагентами, отдельными экземплярами модели, и принимать их выводы только с доказательствами. Это будто придумано под аудит типовой. В ERP столько общих модулей, что вручную их все не проверить (пример):
⠀
Проверь общие модули на запросы в цикле. Каждую подсистему отдай своему субагенту. Вывод принимай только с номером строки. В конце таблица: модуль, есть ли проблема, строка.
⠀
4. На длинной многошаговой задаче модель со временем забывает детали начала разговора, а файл остаётся. Поэтому пусть она ведёт список шагов в TASKS.md и отмечает сделанные. В OpenSpec мы так и делали: у каждого изменения там свой tasks.md, где выполненные задачи отмечаются галочками.
⠀
5. Самый полезный для нас совет: добавить в правила «помечай, что не подтвердил, и пиши, где искал». Классика: модель уверенно пишет обращение к РегистрНакопления.ТоварыНаСкладах, которого в вашей конфигурации нет. С таким правилом вместо выдуманного регистра появится честное «не нашёл в AccumulationRegisters/».
⠀
6. Прежде чем код посмотрит человек, статья советует прогнать ревью моделью. Промпт переносится почти дословно (пример):
⠀
Посмотри diff этой ветки относительно main в выгрузке конфигурации. Перечисли только то, из-за чего не пустил бы в релиз: файл, строка, почему это ошибка и как воспроизвести в тестовой базе.
⠀
По ранним тестам Opus 5.5 находит больше проблем, чем прошлые модели, и реже поднимает ложную тревогу.
⠀
7. С изображениями модель теперь работает лучше, поэтому автор советует присылать скриншот вместо объяснений. Форму с пустым полем или отчёт на СКД с кривыми итогами проще показать, чем описать.
⠀
Все эти советы бесполезны, пока вы не выгрузили конфигурацию в файлы и не показали её агенту: модели не с чем сверяться. В статье об этом ни слова. И результат нужно на чём-то проверять: тестовая база, синтаксический контроль, а лучше ещё сценарии Vanessa Automation.
⠀
Если у вас подключены скиллы и расширения для 1С, такие правила в них уже есть. Вручную их прописывают только для модели без обвязки. А без неё код на 1С сейчас никто и не пишет: ничего хорошего не выйдет.
⠀
#статья
⠀
Addy Osmani выпустил в блоге Claude разбор, как выжать максимум из Opus 5.5. Про 1С там ни слова, но советы ложатся на нашу работу почти без переделки.
⠀
Многое оттуда 1С-ники с настроенным harness (харнес, программная обвязка вокруг модели) делали и до выхода Opus 5.5. Те же критерии готовности в спецификации или стоп-лист опасных команд. Новая модель работает чуть лучше, даже когда обвязки нет.
Кстати, как настроить harness для 1С, я рассказал в мини-курсе: https://lapits.ru/ai-course/
⠀
Советы из статьи Osmani и как они выглядят в 1С:
⠀
1. Отдайте агенту задачу целиком, сразу задайте критерий готовности и не мешайте. Opus 5.5 держит многошаговую работу дольше прошлых версий, так что дёргать её незачем. Думает она тоже сама, перед каждым ответом. Отсюда и совет выкинуть «думай внимательно»: по тестам без этих фраз ответ начинается быстрее, а качество не падает.
⠀
В 1С критерий готовности лучше задавать проверкой, которую можно запустить (пример):
⠀
Переведи модальные вызовы в формах подсистемы «Продажи» на асинхронные.
Критерий готовности: проверка конфигурации с поиском использования модальности по этим формам чистая, конфигурация загружается в тестовую базу.
Спрашивай, только если проверка упала и ты не понимаешь почему.
⠀
Заметьте, списка методов тут нет. Какие вызовы модальные, модель знает сама, а проверит платформа.
⠀
2. Раз модель долго работает без присмотра, пропишите в CLAUDE.md, где ей останавливаться: если без вас дальше никак или следующий шаг может сломать базу так, что её придётся поднимать из бэкапа. Стоп-лист у нас до боли знакомый, пишите его прямо: /UpdateDBCfg на рабочей базе, помещение в хранилище, снятие типового объекта с поддержки, удаление реквизита с данными.
⠀
3. Большую работу статья предлагает делить между субагентами, отдельными экземплярами модели, и принимать их выводы только с доказательствами. Это будто придумано под аудит типовой. В ERP столько общих модулей, что вручную их все не проверить (пример):
⠀
Проверь общие модули на запросы в цикле. Каждую подсистему отдай своему субагенту. Вывод принимай только с номером строки. В конце таблица: модуль, есть ли проблема, строка.
⠀
4. На длинной многошаговой задаче модель со временем забывает детали начала разговора, а файл остаётся. Поэтому пусть она ведёт список шагов в TASKS.md и отмечает сделанные. В OpenSpec мы так и делали: у каждого изменения там свой tasks.md, где выполненные задачи отмечаются галочками.
⠀
5. Самый полезный для нас совет: добавить в правила «помечай, что не подтвердил, и пиши, где искал». Классика: модель уверенно пишет обращение к РегистрНакопления.ТоварыНаСкладах, которого в вашей конфигурации нет. С таким правилом вместо выдуманного регистра появится честное «не нашёл в AccumulationRegisters/».
⠀
6. Прежде чем код посмотрит человек, статья советует прогнать ревью моделью. Промпт переносится почти дословно (пример):
⠀
Посмотри diff этой ветки относительно main в выгрузке конфигурации. Перечисли только то, из-за чего не пустил бы в релиз: файл, строка, почему это ошибка и как воспроизвести в тестовой базе.
⠀
По ранним тестам Opus 5.5 находит больше проблем, чем прошлые модели, и реже поднимает ложную тревогу.
⠀
7. С изображениями модель теперь работает лучше, поэтому автор советует присылать скриншот вместо объяснений. Форму с пустым полем или отчёт на СКД с кривыми итогами проще показать, чем описать.
⠀
Все эти советы бесполезны, пока вы не выгрузили конфигурацию в файлы и не показали её агенту: модели не с чем сверяться. В статье об этом ни слова. И результат нужно на чём-то проверять: тестовая база, синтаксический контроль, а лучше ещё сценарии Vanessa Automation.
⠀
Если у вас подключены скиллы и расширения для 1С, такие правила в них уже есть. Вручную их прописывают только для модели без обвязки. А без неё код на 1С сейчас никто и не пишет: ничего хорошего не выйдет.
⠀
#статья