Вводная презентация по продукту TextFoundry

собирать библиотеку переиспользуемых блоков;

комбинировать их в композиции;

версионировать изменения;

детерминированно рендерить итоговый prompt;

применять AI как явный инструмент редактирования, а не как скрытое ядро всей системы.

workbench для authoring;

future Prompt Server для published prompt registry and render API.

TextFoundry превращает prompt engineering из набора разрозненных текстов в управляемую систему артефактов.

в заметках;

в чатах;

в markdown-файлах без строгой структуры;

в коде как большие строковые литералы;

в копиях "финальной версии", которые быстро расходятся между собой.

трудно переиспользовать удачные части prompt;

сложно понять, какая версия сейчас рабочая;

изменения плохо сравниваются и почти не трассируются;

один и тот же prompt приходится вручную адаптировать под разные сценарии;

AI-правки легко смешиваются с ручными правками и теряется контроль.

он вводит явные сущности Block, Composition, Version, Render;

отделяет хранение, сборку, просмотр и AI-assisted изменения;

делает prompt assets управляемыми и обозримыми.

AI product engineer;

prompt engineer;

applied ML engineer;

technical writer для AI workflows;

исследователь или оператор, которому нужен визуальный authoring без постоянного перехода в код.

вести библиотеку reusable prompt blocks;

поддерживать несколько версий prompt assets;

собирать системные prompts из частей;

делать controlled AI-assisted editing;

показывать состояние prompt-логики в GUI, а не только в Python-коде.

prompt - это не один длинный текст, а композиция управляемых частей.

Block - переиспользуемый версионируемый кусок prompt-логики;

Composition - упорядоченная сборка из блоков и служебных фрагментов;

Renderer - детерминированный механизм получения итогового текста;

AI workflows - отдельные явные операции, которые помогают автору, но не подменяют core runtime.

сначала есть библиотека артефактов;

затем есть controlled assembly;

и только потом есть optional AI assistance.

AI в продукте работает как инструмент редактора;

deterministic path остаётся главным источником правды;

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

создание и редактирование блоков;

версионирование;

поиск и просмотр по библиотеке;

AI generation и AI revise как черновые предложения.

создание и редактирование композиции;

вставка ссылок на блоки и служебных фрагментов;

version history;

обновление ссылок на последние версии блоков;

compare с актуальной версией.

deterministic render;

preview raw, rendered и normalized;

runtime parameters;

copy/export результата.

Block Generation

Prompt Slicing

Normalization

Composition Rewrite

Qt/QML GUI для основного сценария;

FTXUI TUI для базовых операций.

Prompt Server как published prompt registry и сервер рендера.

Runtime Surfaces как стратегия для C local`, `Python local`, `C remote и Python remote.

блоки и композиции публикуются как версии;

новые изменения не затирают старые автоматически;

compare и update являются нормальными рабочими сценариями.

deterministic render живёт отдельно;

AI не вызывается "сам по себе" внутри обычного рендера;

AI влияет только на explicit user action.

блоки, композиции и версии можно осматривать как объекты интерфейса;

workflow виден пользователю напрямую;

продукт не требует постоянно мыслить только Python-runtime категориями.

framework для программной сборки LLM behavior;

слой для модулей, оптимизации и execution logic;

инструмент, который хорошо живёт в коде и исследовательском runtime.

как библиотека prompt assets;

как visual authoring workbench;

как система версий блоков и композиций;

как desktop-first инструмент с ручным review и controlled publishing.

в центре находятся блоки, композиции и версии, а не только runtime modules;

есть явный desktop UI и TUI;

встроен authoring workflow для non-trivial prompt libraries;

deterministic render отделён от AI assistance;

human-in-the-loop модель заложена в продукт;

compare, update, review и publish являются частью пользовательского процесса;

локальное storage и локальная библиотека артефактов встроены в систему;

целевая серверная траектория включает prompt registry/render server, а не только desktop authoring.

TextFoundry сильнее как prompt asset workbench;

DSPy сильнее как framework для программируемых LLM pipelines.

экосистема Python-first tooling;

framework mindset для программной оркестрации;

исследовательский цикл вокруг optimization and evaluation;

более естественная встраиваемость в кодовые LLM pipelines;

готовые ментальные модели для module-based experimentation.

это более узкий и специализированный продукт;

он лучше подходит для authoring and delivery workbench, чем для полной исследовательской платформы;

часть advanced evaluation и automation дисциплины ещё нужно развивать;

planned Prompt Server пока не реализован как runtime capability;

Python integration story пока не оформлена как готовый продуктовый слой.

для asset-centric prompt authoring TextFoundry часто лучше подходит;

для Python-centric prompt programming и research workflow DSPy может быть естественнее.

уменьшает хаос в prompt-базе;

делает reuse нормальной практикой;

упрощает сопровождение длинных system prompts;

даёт контролируемый способ использовать AI без скрытых мутаций;

позволяет обсуждать prompt changes как версии и артефакты;

помогает отделить "черновое AI-предложение" от "утверждённой версии".

один и тот же prompt asset можно будет использовать не только в workbench, но и в backend/runtime clients по API;

TextFoundry сможет выступать не только как editor, но и как prompt registry/render platform.

меньше copy-paste prompt engineering;

меньше неявных расхождений между версиями;

больше прозрачности при изменениях;

лучшее основание для дальнейшей автоматизации, quality review и prompt governance.

один и тот же policy fragment копируется в разные prompts;

локальные исправления расходятся между ветками;

сложно обновить общий блок сразу во всех местах;

AI-редактор предлагает удачный вариант, но потом теряется понимание, что именно было принято.

общие части выносятся в reusable blocks;

композиции собираются из этих blocks;

изменения выпускаются как новые версии;

Update Blocks To Latest помогает подтянуть composition;

Compare With Latest показывает, что изменилось;

Render Preview даёт проверить итоговый текст до публикации;

AI используется как помощник, а не как источник безусловной правки.

core engine должен оставаться детерминированным;

storage и versioning должны быть частью ядра;

AI должен подключаться через явные интерфейсы и по явному действию пользователя.

воспроизводимость render path;

понятные границы между ручным и AI-assisted workflow;

возможность деградации без потери базовой функциональности;

меньший риск скрытого изменения артефактов.

published assets должны стать доступными через отдельный Prompt Server;

server должен отдавать deterministic render и metadata published versions;

authoring и delivery должны остаться разными поверхностями.

сначала стабилизируется local semantic contract;

потом появляется multi-language local story;

затем появляется remote delivery boundary;

и только после этого продукт становится полноценной multi-surface platform.

Python не должен оставаться "вторичным thin client";

server не должен проектироваться просто под удобство bindings;

parity между языками должна измеряться по capability и semantics, а не по буквальному совпадению API.

доменная модель;

GUI/TUI surfaces;

локальное versioned storage;

deterministic rendering;

базовый набор AI-assisted authoring функций.

зрелость evaluation-практик;

расширение интеграционного контура;

prompt server как published prompt registry and render API;

Python client/bindings strategy;

более широкий operational story для командного использования.

продукт уже полезен как инструмент управления prompt assets;

при этом он ещё находится в стадии развития как более широкая платформа.

TextFoundry - это инструмент для хранения, сборки, версионирования, просмотра и controlled AI-assisted редактирования prompt-артефактов.

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

Он не заменяет все framework-сценарии вроде DSPy, но решает другой, очень практический класс задач: управление prompt assets как системой.

Почему TextFoundry сделан как самостоятельный продукт, а не как решение на базе DSPy

High-Level Design

UI/UX

Function Docs

Roadmap runtime surfaces и Prompt Server