Claude Efficiency Playbook: Наръчник за ефективна работа

Това е мярката с най-голям ефект тук. Всяко извикване на инструмент от асистента (търсене в уеба, отваряне на файл, заявка към приложение) е отделна стъпка и на всяка стъпка се прочита отново целият разговор до момента. Ако добавите нова, несвързана задача в стар и дълъг чат, тя повлича всичко казано по-рано, макар вече да няма отношение към нея. Щом задачата се промени, започнете нов чат, вместо да продължавате стария. Същата логика важи и в рамките на една задача: разделете я на евтина, механична стъпка за събиране на информация и отделна, по-скъпа стъпка за разсъждение; предайте резултата с кратък файл или бележка, вместо с цялата предходна размяна на съобщения.

Пример

Лек модел извлича ключовите факти от стенограма на среща в кратка бележка (стъпката за събиране). В отделен чат по-мощен модел прочита само тази бележка, за да прецени какво означава тя за дадено решение (стъпката за разсъждение) — вместо един дълъг чат, който влачи цялата стенограма и целия разговор по извличането в анализа.

Всяко изпратено от вас съобщение, особено това, което задейства инструмент, е отделна стъпка, при която се прочита отново всичко дотук. Пет малки заявки, изпратени една по една, струват повече от същите пет заявки, изпратени заедно, защото предишните се прочитат отново няколко допълнителни пъти, докато се чакат останалите.

Пример

Вместо да попитате „намери документ A“, после „сега намери документ B“ и накрая „сега ги сравни“, попитайте веднъж: „намери документи A и B и ги сравни“.

Отстъпката за повторно прочитане на кеширания контекст важи само за кратък прозорец, обикновено около пет минути. Ако замълчите по-дълго насред разговора, следващата стъпка ще зареди отново целия контекст на значително по-висока тарифа, вместо на ниската тарифа за кеширано четене.

Пример

Ако диктувате инструкции с паузи, опитайте се да изкажете цялата си мисъл наведнъж, вместо да изпратите едно изречение, да мислите няколко минути и после да изпратите следващото.

Използвайте Claude Haiku за четене и справки — например да вземете статус от тракер или да проверите какво вече пише в бележка от уики. Той е бърз и евтин, а работата е механично извличане на информация, което не изисква преценка, така че по-голям модел не носи полза. Използвайте Claude Sonnet за анализ — прочитане на стенограма или документ и осмислянето му; това е подходящият баланс между дълбочина и цена за повечето ежедневни задачи по писане и анализ. Използвайте Claude Opus за изготвяне на цялостен резултат — свързване на факти от много бележки в един цялостен материал, при който правилната преценка е по-важна от цената.

Пример

Haiku: проверка на статуса на задача или на вече записаното в бележка от уики. Sonnet: превръщане на стенограма от среща в ясен анализ. Opus: събиране на бележки от няколко инициативи в една пътна карта, която свързва фактите помежду им.

Независимо от избрания модел, Claude ви позволява да зададете колко да „мисли“ преди да отговори. Използвайте ниското ниво за рутинни, механични заявки, средното — за повечето ежедневни задачи по анализ и писане, а високото — само за наистина двусмислени, многоетапни решения, при които грешката струва скъпо. Claude Fable е създаден за тежки многоагентни автоматизации (оркестрация в стила на Claude Code) — не го използвайте за обичайната ежедневна работа, която не включва такава оркестрация: струва повече, без да носи полза при стандартна задача.

Пример

Проверка дали бележка следва фиксиран шаблон: ниско. Превръщане на стенограма в анализ: средно. Решение кой от три конкуриращи се риска по проекта да се ескалира първи: високо. Автоматизиран многоетапен поток през множество системи: Fable, и то само тогава.

Смяната на модела или нивото на разсъждение по средата на разговор обезсилва кешираната версия на всичко казано дотук. Следващата стъпка трябва да зареди цялата история отново на скъпата тарифа, вместо на по-евтината тарифа за кеширано четене. Ако задачата наистина изисква друг модел или друго ниво на усилие, това е знак да започнете нов чат, а не да сменяте настройката по средата на вече започнатия.

Пример

Започнахте чат с бързия клас за кратка справка, а задачата се превърна в сериозен анализ? Вземете наученото, отворете нов чат с по-мощен модел и продължете там, вместо да надграждате същата нишка.

Една MCP връзка (към календар, тракер на задачи, инструмент за диаграми или файлово хранилище) добавя целия списък с възможни действия към информацията, която асистентът трябва да следи; краткото ѝ описание стои във фоновия контекст още преди да бъде използвана. Щом се използва едно действие, пълното му техническо описание се зарежда и остава до края на чата. Проект с десет свързани MCP интеграции плаща за целия този обем дори при задача, която засяга само една от тях.

Пример

Ако проектът наистина използва само три MCP интеграции — например тракер на задачи, инструмент за диаграми и файлово хранилище — оставете свързани точно тях и нищо друго „за всеки случай“.

Инсталирано, но неизползвано умение или интеграция почти не струва само по себе си. Щом обаче бъде извикано, пълните му инструкции или техническото му меню — лесно няколко хиляди токена — се зареждат в чата и остават там до края му, независимо дали ще го използвате отново. Оставете включени само онези, които са нужни за конкретната задача, и изключете останалите.

Пример

Работите по преглед на документ? За тази сесия изключете интеграцията за диаграми и всички умения, които не са свързани с документи, вместо всичко да е включено по подразбиране.

LLM Wiki — постоянно допълвана, свързана база от знания, изграждана с помощта на асистента — има смисъл, когато дадена инициатива продължава няколко месеца или повече и включва повтарящи се срещи и решения, които ще искате да намирате отново по-късно. За еднократен въпрос, към който нищо друго няма да препраща, това е излишно; отговорете директно, вместо да го записвате в бележка с етикети и връзки. Идеята идва от gist-а на Andrej Karpathy за LLM Wiki — заслужава си да го прочетете изцяло, ако искате да изградите такава система както трябва.

Пример

Проект, който продължава два-три тримесечия и има седмични срещи, си струва да има уики. Бърза еднократна сметка — не; за нея не е нужна датирана бележка с етикети.

Превръщането на необработена стенограма от среща в чиста бележка е една задача. Преценката какво означава тази бележка за план или решение е друга задача. Изпълнете първата, затворете този чат и отворете нов, който чете само готовата бележка, а не цялата стенограма, за да се заемете с втората.

Пример

В един чат днешната среща се записва в бележка. По-късно отделен чат прочита бележката, за да прецени какво трябва да се промени заради нея.

Проект с трайно прикрепени файлове и папки има смисъл, когато разполагате с шаблони, постоянно поддържана база от знания или повтарящи се резултати, към които ще се връщате. За единичен въпрос или кратък еднократен анализ обикновеният чат без цял проект е по-прост и по-евтин, защото не вкарва файловете и структурата на цял проект във въпрос, който не се нуждае от тях.

Пример

Текуща инициатива със споделен набор от шаблони и поддържана база от знания заслужава постоянен проект. „Каква е разликата между тези два счетоводни термина“ — не.

Един проект, в който едновременно са свързани всички приложения и теми, означава, че всяка сесия в него — дори с тясно зададен обхват — носи тежестта на всичко останало, което е свързано. Разделянето на несвързани работни потоци в отделни проекти поддържа малък базов обем за всеки от тях.

Пример

Отделен проект за преглед на правни договори и друг за маркетингов анализ, вместо един проект с двата набора интеграции постоянно включени.