Проверка предложений и отчётов с Gemini перед согласованием

Бывает, что важной информации в документе не хватает, а выясняется это уже на обсуждении. Вы отправили предложение, отчёт или план, но руководитель или клиент задаёт вопросы, на которые стоило ответить заранее. Каков бюджет? Кто отвечает? Что будет, если сроки сдвинутся? Как измерить успех? Почему этим стоит заняться сейчас? Gemini может помочь найти часть таких пробелов до отправки документа.

Общий запрос даёт мало контекста:

Для полезной проверки нужно объяснить, кто прочитает документ и что ему важно:

Проверку можно организовать так:

Метод из учебных материалов Google

В основе статьи — практическое задание из официального курса Google «AI for Writing and Communicating» на Coursera. В нём Gemini помогает проверить документ с учётом интересов его адресата. Вы описываете читателя и его приоритеты, а модель ищет недостающие сведения. Затем можно обсудить с ней предполагаемые исправления. Такую проверку проводят до реального согласования. Она помогает подготовить вопросы и правки, но не предсказывает реакцию конкретного человека. Первые три шага взяты из задания. Затем мы добавляем правила, которые помогут последовательно проверить рабочий документ.

Шаг 1. Опишите адресата и его приоритеты

Начните с документа, который нужно проверить.

Это может быть:

• предложение;
• отчёт;
• план проекта;
• бизнес-обоснование;
• одностраничный документ;
• стратегический документ;
• внутренняя рекомендация.

Прикрепите документ к Gemini. Затем опишите, кто должен его проверить и что важно этому человеку.

I’m working on a [type of document] for [brief description of your project].

Act as the [stakeholder you want feedback from and list their priorities], and review the document attached.

From your perspective, is there any information missing?

Например:

I’m working on a proposal for replacing our manual customer onboarding process with an automated workflow.

Act as our COO, whose priorities are implementation risk, operating cost, team capacity, and measurable efficiency improvements.

Review the attached proposal.

From your perspective, is there any information missing?

Указав должность и приоритеты, вы объясняете модели, на что обратить внимание при проверке. Финансовому директору могут быть важны затраты, ожидаемый доход и риски. Руководителю текущих работ — кто отвечает за внедрение и что нужно подготовить. Руководителю продаж — влияние на выручку и удобство для клиентов. Поэтому один и тот же документ вызывает у разных читателей разные вопросы.

Как роль влияет на проверку

В рекомендациях Google по промптам роль предлагается задавать вместе с задачей, контекстом и форматом ответа. Роль задаёт точку зрения для проверки. Конкретные приоритеты объясняют, по каким критериям оценивать документ.

При этом важно помнить: Модель не может точно предсказать реакцию генерального директора, клиента или руководителя. Зато она помогает ответить на вопрос:

Шаг 2. Проверьте предлагаемое исправление

Допустим, Gemini указал, что в документе не хватает сведений. Прежде чем дописывать текст, проверьте, что выбранное исправление отвечает на замечание. Опишите, что собираетесь изменить, и попросите оценить, решает ли это исходную проблему.

You provided the following feedback about [feedback topic].

I plan to resolve your feedback by [proposed resolution].

Does that resolve the concerns, or are you looking for more?

Например:

You said the proposal does not provide enough detail about implementation risk.

I plan to address this by adding:

- a phased implementation timeline;
- responsible owners for each stage;
- major dependencies;
- rollback procedures;
- success criteria for the pilot.

Does that resolve the concern, or is additional information still needed?

Так замечание проходит ещё одну проверку:

Так вы сначала проверите содержание правки и только потом будете работать над формулировкой.

Шаг 3. Подготовьте краткое резюме

После проверки и доработки плана попросите Gemini изложить его в нужном формате.

How would you write a [desired length] summary of this plan for the [document]?

Например:

How would you write a 2-sentence summary of this plan for the executive one-pager?

Краткую версию лучше готовить после проверки содержания. Иначе есть риск хорошо сформулировать план, в котором всё ещё не хватает данных для решения. Для этого последовательно:

1. проверьте содержание;
2. найдите недостающие сведения;
3. доработайте план;
4. подготовьте краткую версию.

Тогда краткий текст будет опираться на уже проверенный план.

Понятный текст и убедительное обоснование — разные задачи

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

Простой редакторский промпт может звучать так:

Этот запрос помогает изменить формулировки.

При проверке с позиции адресата вопрос другой:

Ответ покажет, какой информации не хватает для решения.

Даже в хорошо написанном предложении могут отсутствовать:

• затраты;
• график;
• ответственные;
• подтверждающие данные;
• критерии успеха;
• риски;
• альтернативы;
• подробности выполнения работ.

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

Дополнение M2B2: уточните приоритеты адресата

Для проверки рабочего документа недостаточно назвать должность адресата. В таком запросе непонятно, что человеку важно:

Уточните, за что отвечает операционный директор и что важно ему при выборе решения.

Например:

Review the attached proposal from the perspective of our COO.

For this review, assume the COO is primarily responsible for:

- operating efficiency;
- implementation risk;
- staffing capacity;
- cross-team dependencies;
- measurable business outcomes.

The purpose of the proposal is to obtain approval for a 90-day pilot.

Review only the information contained in the attached document.

Identify:

1. Questions this stakeholder is likely to ask.
2. Information that is missing or insufficiently supported.
3. Assumptions that are presented without evidence.
4. Risks that are not addressed.
5. Decisions the stakeholder would still be unable to make based on the current document.

For every issue, explain why it matters from this stakeholder perspective.

Do not invent company information.

If the document does not contain something, mark it as missing rather than assuming an answer.

Теперь понятно, какие сведения модель должна искать и чего не хватает для решения.

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

Укажите формат, который поможет последовательно обработать замечания.

Например:

Return the review as a table with these columns:

- issue
- stakeholder concern
- why it matters
- evidence currently provided
- information missing
- priority: High / Medium / Low
- recommended revision

Base the review only on the attached document and the stakeholder priorities I provided.

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

Указывайте известные приоритеты адресата

Роль сама по себе не даёт модели знаний о конкретном человеке.

Допустим, вы пишете:

Gemini не знает, что думает ваш генеральный директор. Без дополнительного контекста модель будет опираться на общие представления об этой должности. Поэтому лучше явно указать приоритеты:

Act as a CEO reviewing this investment.

Focus on:

- strategic fit;
- expected business impact;
- opportunity cost;
- implementation risk;
- time to measurable value.

Так будет понятно, по каким критериям модель проверяет документ и на каких предположениях строится её ответ.

Дополнение M2B2: проверьте документ с разных позиций

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

Одно предложение могут проверять:

• генеральный директор;
• финансовый директор;
• операционная команда;
• ИТ;
• юристы;
• отдел продаж;
• конечные пользователи.

Проведите отдельную проверку для каждой роли.

Например:

Review the attached proposal independently from three perspectives.

Perspective 1 — CFO
Priorities:
- total cost
- financial assumptions
- downside risk
- measurable return

Perspective 2 — Head of Operations
Priorities:
- implementation
- ownership
- workload
- dependencies
- operational failure modes

Perspective 3 — Head of IT
Priorities:
- integration
- security
- data access
- maintainability
- technical dependencies

For each perspective:

1. List the five most important questions.
2. Identify missing information.
3. Identify assumptions requiring validation.
4. Identify anything that could block approval.

Keep the three perspectives separate.

Do not manufacture company facts.

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

Различайте пропущенные данные и слабую аргументацию

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

Например, ИИ может попросить уточнить ROI — показатель окупаемости вложений:

Есть как минимум две возможности.

Недостающий факт

В предложении вообще нет финансового анализа.

Слабый аргумент

Расчёт ROI есть, но непонятно, какие исходные значения и условия в нём использованы.

В первом случае нужен сам расчёт, во втором — его пояснение и проверка исходных условий.

Можно попросить Gemini различать их:

For every concern, classify it as one of:

- Missing information
- Unsupported assumption
- Unclear explanation
- Weak evidence
- Unaddressed risk
- Decision dependency

Do not combine categories unless necessary.

Так для каждого замечания будет понятнее следующий шаг.

Проверьте, устраняет ли правка замечание

Запрос для повторной проверки тоже можно уточнить.

На вопрос с ответом «да» или «нет» можно получить согласие без объяснения:

Попросите модель оценить правку по конкретным условиям:

You previously raised this concern:

[paste concern]

I propose addressing it this way:

[paste proposed change]

Evaluate the proposed fix from the same stakeholder perspective.

Tell me:

1. Which part of the original concern it resolves.
2. Which part remains unresolved.
3. What new questions the proposed solution creates.
4. What evidence would make the response stronger.
5. Whether the document now contains enough information for a decision.

Do not rewrite the section yet.

Сначала проверьте, появилась ли нужная информация и решает ли она проблему. После этого подберите формулировку и внесите правку в документ.

Ведите журнал замечаний

Для важных документов соберите замечания и их статусы в одну таблицу.

Например:

Таблица поможет отслеживать правки до согласования документа.

Шаблон промпта для проверки с позиции адресата

Этот запрос подойдёт для предложений, планов, отчётов и кратких справок:

I am preparing a [document type] about [project or decision].

The document will be reviewed by:

[stakeholder]

Their responsibilities and priorities in this decision are:

- [priority]
- [priority]
- [priority]
- [priority]

The decision I need them to make is:

[decision]

Review the attached document from that perspective.

Do not rewrite it yet.

First create a feedback report containing:

1. The five most important questions this stakeholder is likely to ask.
2. Missing information.
3. Unsupported assumptions.
4. Claims that need stronger evidence.
5. Risks or trade-offs that are not addressed.
6. Information that is present but difficult to understand.
7. Decisions the stakeholder cannot yet make from the document.

For every issue include:

- priority: High / Medium / Low;
- why it matters;
- what information would resolve it.

Use only the attached document and the context I provided.

Do not invent missing facts.

Clearly distinguish between:
- information that exists in the document;
- your interpretation;
- information that is missing.

Повторно проверьте документ после правок

После доработки сравните результат с исходными замечаниями. Попросите модель проверить, какие проблемы устранены, а какие остались:

I revised the document based on the previous feedback.

Compare the new version against the issues you identified earlier.

For each original issue, mark it:

- Resolved
- Partially resolved
- Not resolved
- New issue introduced

Explain the classification briefly.

Then list only the remaining High-priority issues that could prevent the stakeholder from making the requested decision.

Так можно проверить, учтено ли каждое исходное замечание.

Как использовать проверку перед обсуждением

Используйте проверку с ИИ как подготовку к разговору с руководителем или клиентом. Репетиция презентации с коллегой позволяет заметить слабые места, но не предсказать все вопросы аудитории. Gemini тоже может подсказать вопросы и упущения, но не знает всех обстоятельств будущего обсуждения. Она может выявить:

• очевидные пробелы;
• требования разных участников, которые противоречат друг другу;
• предположения, которые не подтверждены данными;
• вероятные вопросы;
• неясные объяснения.

Но реального адресата может волновать то, чего модель не предвидела. Результат этой работы — более полный документ и подготовленные ответы. Само обсуждение с адресатом всё равно потребуется.

Последовательность проверки

Работа строится в несколько этапов:

При работе с ИИ легко сразу перейти к переписыванию:

Сначала проверьте, что в документе есть основания для предлагаемого решения. Затем добавьте недостающие сведения и улучшите формулировки. ИИ помогает найти вопросы, которые стоит разобрать до отправки документа. Ограничьте проверку известными приоритетами адресата:

Источник

На основе официального курса Google «AI for Writing and Communicating» на Coursera.