Примечание автора: генеральный директор животноводческой компании с примерно 120 сотрудниками самостоятельно создал систему управления хозяйством с помощью инструмента для программирования с ИИ. В этой статье мы не будем повторять тезис «теперь разрабатывать может каждый», а разберём, при каких условиях это получилось и с какими ограничениями по-прежнему сталкиваются бизнес-специалисты, создавая системы с помощью ИИ.
В ноябре 2026 года на Всемирной интернет-конференции в Учжэне объявили лауреатов премии в области передовых технологий. Платформа ИИ-агентов Qoder от Alibaba стала единственным китайским универсальным агентным продуктом, получившим награду. В публикациях об этом событии есть пример, который легко пересказать как историю о том, что «бизнес-специалисты тоже могут сами создавать системы»: Чжан Лифэй, генеральный директор животноводческой компании 西鲜记 из Нинся, за три с лишним месяца с помощью инструмента для программирования с ИИ создал несколько бизнес-систем, в том числе систему управления животноводством.
Это не история о том, как человек «с нуля за одну ночь стал программистом». Ранее Чжан Лифэй занимался разработкой в Huawei и Ericsson, а ещё отлично знал бизнес своей компании: животноводство, убой и переработку. Эти два условия определяют как то, о чём говорит данный пример, так и то, каких выводов из него делать нельзя.
Что вы узнаете: прочитав статью, вы сможете оценить, подходит ли ваша бизнес-задача для самостоятельной разработки с помощью ИИ, и поймёте, какие сложности возникают на трёх этапах: при описании требований, проверке результата и дальнейшем сопровождении.

Как сотрудники бизнеса сами создают системы с помощью AI: главное о кейсе
Сначала разберёмся с фактами, которые можно подтвердить по публикации, а затем обсудим, что они означают. Все данные в таблице взяты из материала GeekPark от 5 ноября 2026 года.
| Пункт | Подробности |
|---|---|
| Компания | Сисяньцзи: занимается продажами, разведением, забоем и переработкой; около 120 сотрудников |
| Главный герой | Генеральный директор Чжан Лифэй. Ранее занимался разработкой в Huawei и Ericsson, в 2015 году вернулся на родину и открыл бизнес. Он единственный технический специалист компании |
| Бизнес-проблема | Три фермы и более 10 тысяч овец породы тан содержались на учёте в сложных таблицах Excel. Прибыль от партии можно было точно посчитать только после отправки животных на забой |
| Прежние варианты | Готовое универсальное ПО было трудно адаптировать под бизнес, а разработка на заказ могла обойтись в миллионы юаней и требовала постоянного общения с подрядчиком и внесения правок |
| Подход к разработке | С 2026 года использует Qoder: после работы и в перерывах между командировками открывает несколько сессий на двух компьютерах, описывает требования на естественном языке. AI изучает проект, меняет код и запускает задачи, а он проверяет результаты |
| Результат | За три с небольшим месяца создал несколько систем, в том числе для управления разведением. Их используют для ежедневного кормления, отслеживания роста и принятия решений об отправке животных на забой. Часть проблем, которые раньше обнаруживались только при забое, теперь выявляют ещё на этапе кормления |
| Эффект по оценке компании | Ожидается сокращение скрытых потерь на несколько миллионов юаней в год; методика расчёта не раскрыта |
Как на практике выглядит самостоятельная разработка систем с помощью AI
В публикации есть деталь, которую легко упустить: Чжан Лифэй не просто «произнёс одну фразу и получил готовую систему от AI». Он одновременно открывает несколько сессий разработки и, пока одна задача выполняется, переключается на другую. После того как AI вносит изменения, Чжан сам проверяет результат и добавляет новые сведения о бизнесе.
По сути, это модель сотрудничества «эксперт по бизнесу + AI-исполнитель». Человек разбивает задачу на части, принимает результат и определяет направление доработок, а AI пишет и меняет код, а также запускает задачи. Если посмотреть на кейс с этой стороны, вывод становится яснее.

Как AI помогает специалистам создавать системы: какие барьеры он снижает
Разработка внутренних инструментов с помощью AI по сути перераспределяет работу, которую раньше выполняла небольшая команда. В таблице показано, кто отвечает за каждый этап традиционной заказной разработки в этом случае.
| Этап разработки | Традиционная заказная разработка | Как это устроено в данном случае | Насколько AI снижает барьер |
|---|---|---|---|
| Проработка требований | Продакт-менеджер изучает потребности и пишет документацию | Руководитель бизнес-направления сам описывает требования | Не снижает: по-прежнему нужно понимать бизнес |
| Написание кода | Frontend- и backend-разработчики работают каждый над своей частью | AI изучает проект и меняет код | Да, это главное снижение барьера |
| Запуск и отладка | Разработчики отлаживают проект локально | AI запускает задачи, человек проверяет результаты | Частично снижает |
| Приёмка результата | Бизнес и разработчики обсуждают результат в несколько этапов | Руководитель бизнес-направления сам проверяет результат | Снижает затраты на коммуникацию, но умение оценивать результат по-прежнему необходимо |
| Дальнейшее развитие | Постановка требований, планирование сроков, обновление продукта | Новые потребности бизнеса добавляются по мере появления | Да, цикл доработок заметно сокращается |
Как видно из таблицы, AI сильнее всего снижает барьер на этапе превращения понятных требований в работающий код, а также сокращает потери на коммуникацию между заказчиком и разработчиками. Раньше главной трудностью для Чжан Лифэя было отсутствие команды, которая могла бы воплотить его идеи в системе. И как раз этот пробел инструменты AI-программирования помогают закрыть лучше всего.
При этом проработка требований и приёмка результата никуда не исчезли — теперь они в большей степени ложатся на руководителя бизнес-направления. В самой публикации отмечается, что новая версия Qoder рассчитана на людей, «которые чётко понимают свою цель и могут оценить качество результата». Это важная оговорка.
3 условия для самостоятельного создания системы с помощью AI
Из этого случая можно выделить три условия, необходимые для успеха:
- Понимать, в чём проблема: Чжан Лифэй чётко видел главную боль — прибыль от партии овец можно было узнать только после забоя. У задачи была конкретная бизнес-цель.
- Уметь ясно сформулировать требования: описать поля, процессы и правила расчёта, а также задать проверяемые критерии приёмки, а не просто попросить «сделать систему управления».
- Уметь оценить результат: опыт в разработке помогал ему разбираться в структуре, находить логические ошибки и вовремя поправлять AI, когда тот уходил не туда.
Первым качеством обладают большинство руководителей бизнес-направлений, а вот второе и третье становятся решающими. Люди без опыта разработки тоже могут справиться, но им придётся потратить дополнительное время на обучение. При этом один случай не позволяет судить о том, как часто они добиваются успеха.
🚀 Быстрый старт: если вы хотите без больших затрат проверить, удаётся ли вам чётко сформулировать требования, попробуйте использовать большую языковую модель, чтобы превратить описание бизнес-задачи в структурированный документ с требованиями. Через APIYI apiyi.com можно вызывать разные популярные модели с одним API-ключом. Это подойдёт для небольшого эксперимента, прежде чем вкладываться в полноценную разработку.
Прежде чем создавать систему с помощью ИИ, оформите требования в виде спецификации
Многие проекты по самостоятельной разработке проваливаются не потому, что ИИ не умеет писать код, а потому, что сами требования сформулированы расплывчато. Прежде чем приступать к работе, попросите модель превратить описание бизнес-задачи, данное своими словами, в список полей, правил и критериев приёмки. Затем проверьте каждый пункт.
Вот простой пример: он вызывает модель через OpenAI-совместимый интерфейс и преобразует описание задачи в спецификацию требований:
import openai
client = openai.OpenAI(
api_key="YOUR_API_KEY",
base_url="https://api.apiyi.com/v1"
)
desc = "三个养殖场,按批次记录每天饲料消耗和羊的体重,想在出栏前就知道每批羊大概赚多少钱。"
resp = client.chat.completions.create(
model="gpt-4o-mini", # Можно заменить другой моделью, доступной на платформе
messages=[{"role": "user", "content": f"把以下业务需求整理成数据字段、计算规则和验收条件:{desc}"}]
)
print(resp.choices[0].message.content)
Посмотреть полный код реализации с уточняющими вопросами
import openai
from typing import Optional
SYSTEM_PROMPT = (
"你是资深业务分析师。请把用户的业务描述整理为:\n"
"1. 核心数据实体与字段(含单位)\n"
"2. 计算规则(写出公式)\n"
"3. 验收条件(每条都必须可被人工检查)\n"
"4. 需要用户补充确认的问题清单\n"
"不要假设用户没说过的规则,不确定的地方放进问题清单。"
)
def build_spec(
business_desc: str,
model: str = "gpt-4o-mini",
extra_context: Optional[str] = None,
max_tokens: int = 1500
) -> str:
"""Преобразовать разговорное описание бизнес-задачи в спецификацию, которую можно проверить"""
client = openai.OpenAI(
api_key="YOUR_API_KEY",
base_url="https://api.apiyi.com/v1"
)
content = business_desc
if extra_context:
content += f"\n补充背景:{extra_context}"
try:
resp = client.chat.completions.create(
model=model,
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": content},
],
max_tokens=max_tokens,
)
return resp.choices[0].message.content
except Exception as e:
return f"调用失败:{e}"
if __name__ == "__main__":
spec = build_spec(
business_desc="按批次管理在栏羊,记录每日饲料消耗、体重和生长阶段,"
"希望出栏前估算每批羊的成本和利润。",
extra_context="目前用 Excel 台账,有三个养殖场。"
)
print(spec)
Этот код не разработает систему за вас. Его польза в том, что он помогает обнаружить моменты, которые казались понятными, но на деле остались неясными. Чем длиннее список вопросов от модели, тем важнее сначала доработать требования и только потом передавать их инструменту для программирования с помощью ИИ.
Могут ли сотрудники бизнеса создавать системы с помощью ИИ: как оценить применимость
Этот пример показывает: при подходящих условиях сотрудники бизнеса могут самостоятельно создать внутреннюю систему с помощью ИИ. Но это не значит, что такой подход подходит для любой системы. Следующая таблица поможет определить, что можно попробовать сделать самостоятельно, а где лучше привлечь профессиональную команду.
| Критерий | Можно начать с самостоятельной разработки с помощью ИИ | Лучше привлечь профессиональную команду |
|---|---|---|
| Масштаб использования | Внутри отдела, небольшое число пользователей | Для клиентов или нескольких организаций |
| Чувствительность данных | Операционные журналы, внутренняя статистика | Персональные данные, платежи, бухгалтерские документы |
| Сложность прав доступа | Мало ролей, простые права доступа | Многоуровневое согласование, детальное разграничение прав |
| Цена ошибки | Ошибку можно обнаружить и исправить вручную | Ошибка напрямую приводит к финансовым потерям, нарушениям требований или инцидентам безопасности |
| Интеграция с системами | Относительно независимая система, достаточно импорта и экспорта | Нужна интеграция с ERP, платёжными системами или государственными надзорными платформами |
| Долгосрочное сопровождение | Заказчик может самостоятельно поддерживать систему | Нужна совместная работа нескольких специалистов и доступность 24/7 |
Система управления животноводством компании 西鲜记 в целом соответствует левой колонке: она используется внутри компании для принятия решений о кормлении и отправке животных на продажу, а проблемы можно вовремя заметить. Если ваша задача относится к той же категории, стоит попробовать создать систему с помощью ИИ. Если же несколько пунктов попадают в правую колонку, надёжнее сначала сделать прототип с помощью ИИ и уточнить требования, а затем передать разработку профессиональной команде или купить готовый продукт.

Сравнение трёх подходов: самостоятельная разработка с помощью ИИ, покупка и заказная разработка
Если сравнить три подхода, различия станут нагляднее:
| Подход | Основные особенности | Когда подходит | Основные риски | Доступные ресурсы |
|---|---|---|---|---|
| Покупка готового ПО | Готово к использованию, стандартные функции | Процессы соответствуют общепринятым в отрасли | Сложно адаптировать под индивидуальные процессы | Отраслевые SaaS-поставщики |
| Заказная разработка | Профессиональная команда, стандартизированный процесс создания и передачи продукта | Сложные системы с чувствительными данными и интеграцией нескольких систем | Высокая стоимость, длительное согласование | Аутсорсинговые и софтверные компании |
| Самостоятельная разработка с помощью ИИ | Быстрые итерации, максимальное соответствие бизнес-процессам | Внутренние инструменты; заказчик понимает бизнес и может принять результат | Безопасность, права доступа и сопровождение зависят от одного человека | Инструменты для программирования с ИИ; для вызова моделей можно использовать APIYI apiyi.com |
Эти подходы не исключают друг друга. Распространённый вариант — сначала самостоятельно создать систему с помощью ИИ, отладить процесс и проверить, действительно ли она нужна. А когда пользователей станет больше и данные станут чувствительнее, решить, стоит ли поручить профессиональной команде переработку системы.
Как создание систем с помощью ИИ силами бизнес-сотрудников влияет на компанию
Влияние на руководителей малого и среднего бизнеса
- Задачи больше не приходится откладывать из-за нехватки команды: у компаний вроде 西鲜记, где технической разработкой занимается всего один человек, раньше был выбор между «неподходящим универсальным ПО» и «дорогой заказной разработкой». Теперь появился ещё один вариант, который можно попробовать.
- Знание бизнеса становится ещё ценнее: тот, кто лучше всех понимает рабочие процессы, может напрямую заложить свой опыт в систему и постепенно дорабатывать её по мере использования. Так меньше информации теряется при «переводе» требований для разработчиков.
- Руководителю приходится тратить больше времени: по данным публикации, Чжан Лифэй занимался разработкой после работы и в перерывах между командировками. Потраченное время — тоже затраты, поэтому называть такое решение «бесплатным» было бы упрощением.
Влияние на профессиональные команды разработки и ИТ-отделы
- Роль смещается от «написания кода» к «подстраховке»: по мере роста числа инструментов, созданных бизнес-сотрудниками, профессионалы будут всё чаще нужны для проверки безопасности, настройки прав доступа, резервного копирования и интеграции систем.
- Растут риски теневых систем: если каждый бизнес-отдел будет самостоятельно создавать инструменты с помощью ИИ, данные окажутся разрозненными, методы расчёта показателей могут различаться, а после ухода сотрудников системы могут остаться без поддержки. Поэтому правила стоит установить заранее.
5 вопросов, на которые этот кейс пока не отвечает
В публикации описан успешный результат, но для принятия решений не менее важны и следующие сведения. В открытых материалах их пока нет:
| Что нужно проверить | Почему это важно |
|---|---|
| Как оценивались «скрытые потери в несколько миллионов юаней» | Без этого нельзя понять, можно ли получить аналогичную выгоду в своём бизнесе |
| Как обеспечиваются безопасность, разграничение доступа и резервное копирование данных | От этого зависит, можно ли в долгосрочной перспективе доверить системе ключевые бизнес-данные |
| Как организованы дальнейшая поддержка и устранение сбоев | Главные скрытые затраты на собственную систему возникают на этапе поддержки |
| Стоимость инструментов и вызовов моделей | Упомянутые в публикации «нулевые затраты» не учитывают расходы на инструменты и потраченное время |
| Успешные и неудачные примеры бизнес-сотрудников без опыта разработки | Один случай не позволяет судить о том, насколько типичен такой результат |
Пока на эти вопросы нет ответов, разумнее считать этот кейс доказательством того, что подход осуществим при подходящих условиях, а не того, что «это под силу каждому».
Часто задаваемые вопросы FAQ
Q1: Может ли сотрудник без опыта разработки самостоятельно создать систему с помощью ИИ?
Да, но это заметно сложнее. У героя этого кейса был опыт разработки в Huawei и Ericsson: он мог разобраться в структуре кода и оценить результаты работы ИИ. Без такой подготовки нужно хотя бы научиться чётко формулировать критерии приёмки и быть готовым потратить время на поиск и устранение проблем. В открытых публикациях пока мало подробных примеров создания систем людьми без опыта разработки, поэтому лучше начать с небольшого инструмента.
Q2: Как выбрать между самостоятельной разработкой системы с ИИ и заказной разработкой у подрядчика?
Учитывайте три фактора: последствия ошибок, конфиденциальность данных и то, кто будет поддерживать систему в дальнейшем. Для внутреннего использования, когда ошибки можно исправить вручную, а сам заказчик способен поддерживать систему, стоит сначала попробовать самостоятельную разработку. Если же система работает с персональными данными, платежами или интегрируется с другими системами, лучше обратиться к профессионалам. Ещё один вариант — сначала создать прототип с помощью ИИ, уточнить требования и затем обсудить их с подрядчиком. Это часто помогает избежать переделок.
Q3: Действительно ли сотрудник может создать систему с помощью ИИ «бесплатно»?
Нет. Даже если у инструмента есть бесплатный лимит, остаются расходы на подписку и вызовы модели, а также время, которое потрачено на разработку. О последнем легко забыть. Герой кейса разрабатывал систему больше трёх месяцев после работы и в перерывах во время командировок. Эти затраты тоже нужно учитывать при принятии решения.
Q4: Как недорого проверить идею до начала полноценной разработки?
Сначала можно с помощью большой языковой модели превратить описание бизнес-задачи в спецификацию требований и список критериев приёмки, а затем создать минимально жизнеспособную версию. Как это сделать:
1. Зарегистрируйтесь на APIYI apiyi.com и получите API-ключ и бесплатный лимит для тестирования
2. Используйте пример кода из этой статьи, указав для base_url значение `https://api.apiyi.com/v1`
3. Сгенерируйте спецификации с помощью разных моделей и сравните, какая из них лучше учитывает особенности вашей задачи
Этот этап обойдётся недорого и поможет заранее обнаружить неясности в требованиях.
Q5: На что в первую очередь обратить внимание после запуска собственной внутренней системы?
Позаботьтесь о трёх вещах: регулярном резервном копировании данных, разделении учётных записей и прав доступа, а также документации по ключевой логике вычислений. Самостоятельно созданная система обычно сильно зависит от своего разработчика. Если он уйдёт или в системе произойдёт сбой, без резервных копий и документации восстановить её будет сложно. Когда пользователей станет больше, рекомендуется пригласить специалистов для проверки безопасности и архитектуры.
Q6: Как контролировать стоимость вызовов большой языковой модели во внутреннем инструменте?
Если внутренний инструмент сам вызывает модель — например, для автоматического составления пояснений к отчётам или распознавания документов, — распределяйте задачи по сложности: для простых используйте лёгкую модель, а для сложного анализа — более мощную. Через совместимый с OpenAI интерфейс APIYI apiyi.com можно переключаться между моделями с помощью одного и того же кода и платить по фактическому использованию. Так удобно сравнить результаты и расходы, прежде чем выбрать постоянное решение.
Как бизнес-специалисту самостоятельно создать систему с помощью ИИ: главное
- У истории успеха есть предпосылки: герой кейса разбирается и в разработке, и в бизнесе. Это не значит, что теперь каждый может создавать системы.
- ИИ снижает порог входа в разработку: писать код и вносить изменения становится быстрее, но формулировать требования и проверять результат по-прежнему должен человек.
- Что стоит попробовать создать самостоятельно: внутренние инструменты, которые не работают с чувствительными данными и в которых ошибки можно исправить вручную.
- Когда нужны специалисты: если система работает с персональными данными, платежами, сложными правами доступа или интеграциями с другими системами.
- Не забывайте о скрытых затратах: учитывайте потраченное время, стоимость инструментов и долгосрочную поддержку.
- Сначала проверка, потом вложения: с помощью APIYI apiyi.com можно недорого вызвать модель для подготовки спецификации требований, а затем решить, создавать систему самостоятельно, покупать готовую или заказывать разработку.
Итоги
Кейс 西鲜记 показывает: когда руководитель бизнеса понимает проблему, умеет сформулировать требования и оценить результат, инструменты ИИ-программирования помогают воплотить в жизнь системные проекты, которые раньше откладывали. Здесь есть три главных вывода:
- Порог входа действительно снижается: ИИ уже способен взять на себя большую часть работы по превращению требований в работающий код.
- Без человеческой оценки не обойтись: описание требований, проверка результатов и постоянная поддержка остаются за человеком, который разбирается в бизнесе.
- Границы нужно определить заранее: безопасность данных, права доступа и долгосрочная поддержка определяют, какие системы можно создать самостоятельно, а для каких нужна команда специалистов.
Если вы планируете создать внутренний инструмент с помощью ИИ, начните с небольшого процесса, где цена ошибки невысока. С помощью ИИ оформите требования в спецификацию, создайте прототип и по результатам решите, что делать дальше. Для быстрой проверки можно воспользоваться APIYI apiyi.com: одного API-ключа достаточно, чтобы сравнить несколько популярных моделей.
📚 Источники
- GeekPark — Что помогло Qoder занять первое место на китайском рынке ИИ-инструментов для программирования и получить награду World Internet Conference за передовые технологии: источник фактов для примеров в статье
- Ссылка:
geekpark.net/news/373542 - Описание: кейс системы управления животноводством Xixianji, а также опыт использования ИИ для программирования в компаниях Geely, Shanda Huatian и других
Автор: техническая команда APIYI
Технические вопросы: если у вас есть вопросы о вызове моделей и подключении внутренних инструментов, свяжитесь с нами через главную страницу сайта APIYI apiyi.com
