Автоматизация еженедельного чек-листа в Excel с помощью PowerShell, TypeScript и WSL

PowerShell окупается тем, что превращает кучу кликов по Windows в несколько строк. Сведения о машине, службы, запланированные задачи: до всего этого через него добраться быстрее всего. Добавьте к этому желание понять, как ИИ-агент вписывается в настоящую разработку, не как генератор приложений по одному промпту, а как напарник, с которым разбираешься в незнакомых API, разгребаешь ошибки, ставишь под сомнение подход и повторяешь заново, и получится эксперимент, которому не хватает только задачи. Задача нашлась сама.

Чек-лист, который просился в автоматизацию

Многие хоть раз думали: "Надо бы вести чек-лист в Excel". Это простой способ не сбиваться с курса, например во время поиска работы. А потом приходит вторая мысль. Вы правда будете обновлять его каждую неделю? Это значит переносить незакрытые пункты на следующую неделю, складывать выполненные куда-то в сторону, менять даты, сохранять старую неделю и повторять всё это бесконечно.

Такое однообразие запускает знакомый рефлекс программиста: это же наверняка можно автоматизировать. Насколько это вообще сложно?

Выбор стека

Первым делом вспомнился PowerShell. На машине стояла Windows, Excel был установлен локально, Планировщик заданий входит в систему, и PowerShell умеет работать со всеми тремя.

Но один огромный скрипт на PowerShell не вдохновлял. Хотелось получить то, что другие разработчики смогут прочитать и расширить и на чём легко строить дальше. Большая часть повседневной работы шла на JavaScript и TypeScript, поэтому каркасом проекта стал TypeScript, а PowerShell достались только части, завязанные на Windows. Слои выглядят так:

TypeScript
    ↓
PowerShell
    ↓
Windows / Excel

TypeScript отвечает за конфигурацию и оркестрацию. PowerShell делает то, что у него получается лучше всего.

Проблемы с путями в WSL

Разработка шла в WSL, поэтому проект запускается из Ubuntu, а файл Excel лежит в Windows. Отсюда свои странности. Путь в WSL выглядит так:

/mnt/c/Users/username/Documents/AutoTask/Weekly_Checklist.xlsx

а Excel нужен путь в формате Windows:

C:\Users\username\Documents\AutoTask\Weekly_Checklist.xlsx

Как раз для такого преобразования в WSL есть wslpath. Из TypeScript можно перевести путь, прежде чем передать его в PowerShell:

const windowsChecklist = execFileSync(
  'wslpath',
  ['-w', checklist],
  { encoding: 'utf8' },
).trim();

Коротко, и теперь приложение на стороне Linux отдаёт PowerShell нормальный путь Windows.

Пусть Excel остаётся Excel

В первой попытке файл .xlsx правился напрямую через JavaScript-библиотеку. Формально всё работало: данные переносились, книга открывалась. Но форматирование разваливалось. Выпадающие списки, стили и поведение книги, всё, что делало таблицу удобной, превратилось в проблему крупнее той, которую решали.

Это привело к ключевому архитектурному решению. Зачем воссоздавать поведение Excel, если Excel уже установлен? Лучше упростить. PowerShell умеет создавать COM-объект Excel:

$excel = New-Object -ComObject Excel.Application

а затем открывать книгу в настоящем настольном приложении:

$workbook = $excel.Workbooks.Open($checklist)

При таком подходе всё существующее форматирование остаётся ровно таким, каким было.

Еженедельный перенос

Главный скрипт называется rollover.ts. Он берёт текущий чек-лист и готовит его к следующей неделе. В книге три листа:

• This Week хранит активные задачи.
• Task History хранит выполненные.
• Settings определяет, например, переносятся ли незакрытые задачи и сохраняются ли заметки.

При запуске скрипт читает реальную системную дату и вычисляет текущий отрезок с понедельника по воскресенье. Это оказалось важнее, чем казалось. Ранняя версия просто сдвигала книгу на неделю вперёд при каждом запуске. Звучит нормально, пока не протестируешь пятнадцать раз и не обнаружишь, что автоматически докатился до ноября.

Решение было в том, чтобы считать системную дату источником истины. Логика перестала спрашивать, какая неделя в книге плюс семь дней, и начала спрашивать, какая неделя на самом деле.

Заодно решилась проблема со столбцом Weeks Carried. Незакрытая задача не должна получать лишнюю перенесённую неделю только потому, что скрипт запустился. Поэтому вместо увеличения счётчика код считает недели между исходной датой переноса задачи и реальной текущей неделей. Операция стала идемпотентной: сколько ни запускай её за одну неделю, результат каждый раз одинаковый. Гораздо лучше.

Архивирование прошлой недели

Прежде чем что-то менять, книга копируется в папку Previous Weeks под именем, в котором указан диапазон недели:

2026-09-07_to_2026-09-13.xlsx

Этот архив — полная копия файла до переноса, с выполненными и незакрытыми задачами ровно в том виде, в каком они были. Затем обновляется рабочая книга. Выполненные задачи попадают в Task History, самые новые сверху. Незакрытые остаются в активном списке, если включён перенос. Проставляются даты новой недели, и Excel сохраняет файл.

Планируем планировщик

Скрипт переноса всё равно надо помнить и запускать, а это убивает весь смысл. Тут в дело вступает configure.ts. На листе Settings хранится день переноса, по умолчанию понедельник. Скрипт конфигурации открывает книгу, читает это значение и через PowerShell регистрирует запланированную задачу Windows.

Задача также использует опцию StartWhenAvailable. Если перенос назначен на понедельник в 8:00, а компьютер выключен, Windows запустит его, как только машина станет доступна. Теперь таблица обслуживает себя сама.

Где помог ИИ-агент

ИИ-агента не просили собрать автоматизированный чек-лист Excel по одному запросу, чтобы потом принять результат как есть. Он участвовал во всём процессе. Ритм был примерно такой:

I define behavior
      ↓
AI suggests implementation
      ↓
I run it
      ↓
Something explodes
      ↓
We inspect the actual error
      ↓
Check documentation
      ↓
Fix it
      ↓
Run it again

Если подумать, это очень похоже на обычную разработку. Больше всего агент пригодился за пределами повседневных технологий. PowerShell и TypeScript были знакомы, но у COM-автоматизации Excel свои странности. Копирование значений между ячейками ведёт себя по-разному в зависимости от того, присваиваете ли вы .Value2 напрямую или используете собственные Copy() и PasteSpecial() из Excel. Даты добавляют ещё один слой: Excel хранит их как порядковые числа, а у PowerShell свои типы .NET. И всё пересекает границы: от Node в WSL к PowerShell в Windows и наконец в Excel через COM. Временами стек выглядел примерно так:

TypeScript
→ Node
→ WSL
→ PowerShell
→ COM
→ Excel
→ Why is this a System.Double?

Хорошо работала такая схема: вставить точный текст ошибки, объяснить свою версию причины, а затем с помощью агента найти нужную документацию Microsoft. Важнее всего по-прежнему было проверять каждый ответ. Не раз совет, разумный на бумаге, вёл себя иначе, стоило подключиться Excel.

В этом и главный урок про ИИ в разработке: он сокращает путь от «я этого пока не знаю» до «я знаю, что проверить». Он ускоряет обучение и оборот, когда у вас уже есть ясная архитектурная картина. Это совсем не то же самое, что слепо доверять сгенерированному коду.

Рулит всё равно ваш опыт

Имеющиеся технические знания раз за разом окупались:

• Знание PowerShell помогло легко понять, где ему место в архитектуре.
• Знание TypeScript дало понять, что автоматизация Windows не должна управлять всем приложением.
• Понимание запланированных задач показало, что постоянно работающий процесс Node не нужен.
• Умение заметить, что решение становится абсурдно сложным, было, пожалуй, самым ценным навыком.

Несколько раз реализация начинала обрастать проблемами вместо того, чтобы их решать. В такие моменты способность направлять агента, отклонять идеи и возвращать его к разумному подходу работала лучше, чем позволить ему диктовать ход проекта.

Что видят пользователи

Со стороны пользователя всё просто. Работаете с чек-листом в Excel как обычно: добавляете задачи, расставляете приоритеты, ставите сроки, отмечаете выполненное. Когда наступает новая неделя, копия старой книги отправляется в папку Previous Weeks, выполненные задачи переезжают на вкладку Task History, а незакрытые перетекают в книгу новой недели.

Всё остаётся локальным. Ни базы данных, ни сервера, ни подписки, ничего не работает в фоне. Движущиеся части — Excel, TypeScript, PowerShell, WSL и Планировщик заданий Windows. Признаться, многовато технологий для еженедельного чек-листа, но дело было не в размере. Смысл был в том, чтобы взять рутинную обязанность, применить уже понятные инструменты и воспринимать незнакомые куски как возможность научиться. PowerShell дал отправную точку, ИИ-агент открыл новый путь к незнакомым частям, и скучный маленький чек-лист превратился в неожиданно интересный проект по автоматизации. Неплохо для того, что началось с мысли, что это, наверное, можно автоматизировать.