Модель DeepSeek v4 flash
Задача :
-переместить 2 файла из входящих,
-применить шаблон
Как сделано:
Исправляем как надо.
При этом надо понимать что 2 недели назад все делалось нормально.
Потрачено 16 рублей на 2 небольшие заметки.
Что-то явно надо менять.
ответ выше. дорогая модель пишет mcp или скрипт. дипсик за копейки выполняет
Понял. Тогда я бы предложил ему не “чинить промптом”, а вынести операции с заметками из модели в детерминированный инструмент.
Текст, который можно отправить:
———
Проблема не в том, что DeepSeek “плохой”, а в том, что модель делает файловые операции и правки заметок как свободный текст. Для такого сценария нужен жёсткий исполнитель: скрипт или MCP.
Решение:
{
"moves": [{"from": "Inbox/a.md", "to": "Notes/a.md"}],
"apply_templates": [{"file": "Notes/a.md", "template": "Templates/default.md"}],
"patches": [{"file": "Notes/existing.md", "mode": "append_under_heading", "heading": "...", "text": "..."}]
}
Скрипт/MCP выполняет план:
• проверяет, что файлы реально есть;
• двигает только из Inbox;
• применяет шаблон строго из файла шаблона;
• редактирует заметку только через точечный patch, не переписывает всю заметку;
• перед записью показывает diff;
• делает backup.
Правила безопасности:
• запрещён full rewrite заметки без явной команды;
• запрещены изменения вне указанного блока/заголовка;
• если шаблон не найден, не продолжать;
• если diff содержит лишние изменения, остановиться и спросить.
Модель:
• DeepSeek v4 flash можно оставить только как дешёвый parser/планировщик;
• сами операции должны делать скрипты/MCP;
• для двух заметок контекст должен быть маленький: только имена файлов, шаблон и целевой блок, без чтения всего vault.
Чтобы понять регрессию:
• сравнить, какая модель/промпт/инструменты были 2 недели назад;
• проверить, не стал ли агент читать весь vault или историю;
• проверить, не исчез ли tool/skill, который раньше применял шаблон автоматически.
Итог: агент не должен “сам редактировать заметки”. Он должен предложить проверяемый план, а скрипт применяет его атомарно. Тогда 2 файла и одна заметка будут стоить копейки и не будут ломаться от поведения модели.
Если у вас просто скрипт все делает то в принципе зачем там ллм? Дали шаблонное сообщеие и скрипт отработал. Никаких дополнительных стоимостей на модель
Если шаблонная задача с шаблонными заметками то просто ручками.
Но задача привести заметку к шаблону
в моем случае llm или пишет продающий ответ, или рерайтит пост для вконтакте,
Короткий ответ: LLM там не делает работу — он принимает решения между шагами, которые делают скрипты. Скрипты детерминированы и тупы по краям; LLM закрывает «мягкие» места, где нужно понять намерение, сматчить неточные данные и среагировать на ошибку.
Конкретно в цепочке fbo-logistics LLM делает 5 вещей, которых скрипт сам не может:
1. Перевод «человеческого» в параметры.
Ринат пишет «оформи поставку 20 пневмовинтовёртов на Москву». Скрипту нужны cluster_id=4039, warehouseCode, materialCode, количества, таймслот. LLM достаёт намерение из фразы и раскладывает по аргументам тулзы. Скрипт начинается только с готового JSON.
2. Резолв неточных совпадений.
Товар назвали «винтовёрт», а в номенклатуре он «Гайковёрт аккум. 20В». Артикул дали частично. LLM матчит название→SKU/materialCode (для этого и resolve_cache.db). Скрипт по точному коду — да, по «винтовёрту» — нет.
3. Реакция на ошибки API.
API вернул START_DATE_CANNOT_BE_TODAY или ROBJECT_INCORRECT — LLM понимает, что это значит, и решает: поправить дату на завтра, спросить склад, или сообщить тебе. Скрипт просто упал бы с кодом ошибки.
4. Оркестрация многошаговых сценариев.
Создать черновик → проверить таймслоты → выбрать → подтвердить → дождаться статуса задачи → забрать этикетки. Между шагами есть ветвления («таймслотов нет → что делаем»). LLM ведёт этот граф; каждый отдельный шаг — детерминированный скрипт/API-вызов.
5. Объяснение результата.
API отдаёт сырой JSON с кодами. LLM превращает в «поставка создана, слот завтра 14:00, этикетки вот».
Где LLM НЕ нужен — и правильно, что эта работа в скриптах: сами API-вызовы, пагинация, ретраи, парсинг PDF, кэш. Это детерминированно, и гонять через LLM — дорого, медленно и ненадёжно (он бы галлюцинировал коды складов).
То есть деление осознанное: скрипты = руки (точные, повторяемые операции), LLM = диспетчер (намерение, матчинг, ветвление, ошибки, речь). Если убрать LLM — получишь жёсткий CLI, где ты сам подставляешь все коды и сам читаешь ошибки. Если убрать скрипты и дать LLM дёргать API напрямую — получишь дорого и с галлюцинациями в параметрах.
Хочешь, покажу на конкретной тулзе fbo, какая часть в скрипте, а какая отдана модели?
Проще говоря. В таком сценарии вообще ИИ не нужен. Тут простейший алгоритм, взять, вставить, запустить скрипт. добавить в базу. Для чего здесь ИИ да еще и дорогие? Тут достаточно даже локальной 1В модели на компе. Если уж так охота все усложнить и добавить ненужный контроль и бестолковую оркестрацию. Пример как из мухи сделать слона. Подписку тогда за 200 возьмите у ЧатГПТ, а то вдруг не справится вставить в конфиг две переменные данных из запроса.
Совсем не туда и не о том все это. ИИ вообще не про это и в таких сценариях нах не нужен.
Если тут жестко не прописать все то через месяц работы по любому ИИ что-то перепутает забудет или выдумает, добавит не то в базу и сломает напрочь все данные. И скажет что ему такнравится и так надо
ИИ - это не робот по алгоритмам, он живет своей китайской жизнью, и что там у него в голове не известно. Ответственные задачи по-любому нужно через человеческий контроль или лучше вообще не допускать ИИ. Остальное на потоке, да, все можно и все будет отрабатывать. Но ИИ тут никакого нет, обычная автоматизация
Но это имхо и не оспариваю. Просто мой опыт говорит о необходимости упрощения. Слишком много точек отказа. А когда все посыпется то встанет и база и заявки и все остальное
А не лучше будет всю эту автоматику в обычного бота на питоне вписать, и все будет работать надежно и безотказно, а собирать данные и обрабатывать инфу для тебя уже может ИИ
Дать тому же чатгпт или гуглу и он за минуту нужного бота с нужной автоматизацией напишет. У меня так боты работают с базой уже года три даже не проверял что там , все как часики. но другой алгоритм только
да, мысль здравая. можно попробовать. правда как только озон опять поменяет api опять надо чинить ((
дану. все переменные в отдельный файл и если меняется то прописывай и перезапускай бота
клод с тобой согласился и уже все переписывает)) хотя и на mcp тоже норм работало))
если будешь писать бота, то не пиши на китайских, запусти гугл или чатгпт, они более умные и грамотней напишут, сразу спланируй промт как принимать заявки, какие данные отправлять в переменные что заносить в базу и какой выдавать результат и в боте и тебе для работы в ИИ а модель уже пусть читает базу и файлы и уже там по обстоятельствам.