В последняя время было много проблем с тем в каком стиле отвечают модели антропиков, в частности Opus 5 и Fable 5

Решил почитать их промт-гайд для новой Fable 5.1, так что вот главные советы как улучшить письмо:

1.
Да, у неё текст стал чище, меньше шаблонных фраз и тд, но из того что я и сам заметил, она теперь отвечает сплошным текстом из длинных предложений и кучи стилистических оборотов

Например, вместо "этот параметр стоит менять" модель может написать "это ручка, которую стоит покрутить"

Решается прямым запретом на манерный текст:

Mannered prose substitutes metaphor and flourish for direct statement. Instead of "a parameter worth varying," the mannered writer produces "a dial worth turning." Instead of "this point still matters," they write "this point earns its keep." The phrases exist to display the writer, not to convey the idea, and readers can tell. That is why mannered prose irritates: it makes the reader work harder so the writer can perform. It is also imprecise. Metaphors drag in connotations the writer did not choose and cannot control. The fix is to say what you mean. When a literal phrase is available, use it.

2.
Также 5.1 теперь меньше пишет саммари того что делает, что нашел, о чем думает и тд во время работы

Решение: включить функцию thinking.display, и выбрать "updates" или "summarized", или через /btw просить коротко объяснить что происходит

3.
И всё еще осталась проблема, когда модель (не только у антропиков) забывает что можно вызывать несколько тулов паралельно и тратит время вызывая их поочередно

Решается тоже простой просьбой батчить вызовы тулов:

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

4.
Еще 5.1 стоит ограничивать фокус задачи, чтобы он не отвлекался на фикс соседних багов, расширение функционала и тд

Решение (будет делать только то что просят, а то что найдет по пути просто перечислит в конце):

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Where the task is ambiguous, implement the reading its wording and the surrounding code most directly support, state that assumption in your summary, and don't build for the other readings as well. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files — roughly one focused test per stated behavior — and don't turn scratch checks into additional permanent test files. This is about extras only: implement every behavior the task asks for, completely.

Еще один фан факт: 5.1 реже использует веб-поиск/чтение файлов на low-effort и отвечает просто по памяти

По традиции вот вам универсальный промт, в духе "make no mistakes":

finish the task, stay within scope, search fresh/unknown entities, batch independent tool calls, prefer targeted edits.

👀

@tips_ai

🤖 Прилетело из @tips_ai