Colay / Посібники
Перепишіть статтю бази знань, зберігши точність інструкцій
Оновлена стаття бази знань має чіткіше пояснювати наступну дію читача. У Colay кілька чернеток ШІ допоможуть порівняти коротку процедуру, дерево усунення несправностей і пояснення з прикладами. Почніть з однієї статті та перевіреного набору фактів. Результат — відредагована стаття з інструкціями, які можна зіставити з джерелом, а не набір привабливих перефразувань.
Визначте одного читача й одне завдання
Стаття про зміну налаштувань сповіщень наразі може поєднувати налаштування облікового запису, дозволи та усунення несправностей. Перш ніж переписувати, сформулюйте вихідну точку читача та результат, який він має досягти. Все інше помістіть у попередні умови, пов’язані посилання або окрему статтю. Цей редакційний вибір часто має більше значення, ніж зміна тону.
Створіть картку завдання: ID статті, аудиторія, підтримувана версія продукту, потрібна роль, точні назви елементів інтерфейсу, очікуваний результат, відомі винятки й відповідальний. Використовуйте лише дозволені матеріали. Непевний крок позначте для перевірки, а не просіть модель заповнити прогалину з пам’яті. Рекомендації Google щодо процедур радять зосереджувати кроки на діях і давати достатньо контексту, щоб знайти потрібну дію.
Вигаданий приклад із незмінними фактами про продукт
Розгляньмо вигаданий інструмент для спільної роботи. Учасники можуть вимкнути особисті сповіщення електронною поштою в Налаштуваннях → Сповіщення. Лише власник може змінювати типові налаштування для всієї організації. Збережена зміна впливає на майбутні листи, але не видаляє повідомлення, які вже стоять у черзі. Це вигадані дані прикладу, а не функції Colay.
Запитайте про різні структури, використовуючи однакові факти. Процедура допомагає комусь негайно виконати завдання; версія для усунення несправностей допомагає тим, хто не може знайти елемент керування. Поширені запитання можуть пояснити виняток електронної пошти в черзі. Можливі вісім запропонованих підходів, але вони мають стосуватися восьми ситуацій читання, а не множити однакові речення.
| Ситуація читача | Корисний формат | Факт, який слід зберегти |
|---|---|---|
| Я знаю, що хочу змінити | Пронумерована процедура | Налаштування → Сповіщення є наданим розташуванням |
| Я не можу змінити налаштування організації за умовчанням | Усунення несправностей на основі ролей | Заявлений дозвіл має лише власник |
| Я вимкнув сповіщення, але отримав ще один лист | Коротке пояснення з винятком | Це не впливає на повідомлення в черзі |
Запит, який відокремлює формулювання від фактів про продукт
Використайте Ask separately у Colay, щоб побачити, як обрані агенти розуміють завдання. Порівняйте плани, перш ніж допрацьовувати повні статті. Якщо одна відповідь прибирає вимогу до прав доступу, а інші її зберігають, зверніться до затвердженого джерела. Згода моделей не замінює перевірки описаного процесу в продукті.
Перепиши цю затверджену статтю бази знань: [текст]. Картка завдання: [аудиторія, версія продукту, роль, точні назви елементів інтерфейсу, очікуваний результат, винятки]. Створи покрокову інструкцію, версію для усунення несправностей і коротку версію у форматі запитань та відповідей. Збережи всі умови, дозволи й винятки. Не вигадуй елементів керування або поведінки продукту. Для кожної версії вкажи вихідне речення, на якому ґрунтується кожна інструкція. Неясні чи суперечливі фрагменти винеси до окремого списку питань. Порекомендуй структуру для [ситуація читача] й поясни вибір. Не поєднуй мовчки факти з різних версій продукту.
Перетворіть найкращу чернетку на версію для публікації
Підсумковий матеріал може бути коротким: затверджений заголовок, передумови, кроки, очікуваний результат, винятки й одне доречне наступне посилання. Збережіть відповідність між джерелами та інструкціями в редакторських нотатках. Colay допомагає писати й порівнювати; цей процес не передбачає підключення до вашої бази знань або автоматичної публікації змін.
- Виберіть структуру, яка відповідає картці із завданням. Зберігайте корисні речення з інших чернеток лише після перевірки їх значення.
- Пройдіть кожен крок у підтримуваній версії продукту із зазначеною роллю. Перевірте мітки, порядок, результат і задокументований виняток.
- Прочитайте статтю як новий користувач: передумови мають з’явитися, перш ніж вони знадобляться, а невдалий крок має мати доступну наступну дію.
- Запишіть рецензента, версію статті та змінені розділи. Опублікуйте за допомогою існуючої робочої процедури бази знань, зберігаючи попередню версію для порівняння.
Оцінюйте нову версію за тим, що може зробити читач
Попросіть колегу, який не знайомий із чернеткою, знайти відправну точку, визначити вимоги щодо дозволу та пояснити, що відбувається після останнього кроку. Записуйте непорозуміння як проблеми редагування. Якщо у вас є відгуки або дані пошуку для цієї статті, порівняйте ті самі сигнали після публікації, не приписуючи кожну зміну ШІ. Припиніть генерацію, коли залишилася робота, пов’язана з відсутнім фактом продукту, а не вибором формулювання.
Відповіді на запитання
Чи слід опублікувати всі вісім версій?
Зазвичай ні. Це варіанти для одного завдання читача. Опублікуйте найзрозуміліший придатний варіант; окремі статті потрібні лише для справді різних потреб.
Чи може модель відновити застарілі інструкції?
Лише якщо ви надасте перевірені нові факти. Правдоподібна назва нової кнопки не доводить, що продукт працює саме так.
Що робити, якщо стаття містить приклади приватних клієнтів?
Використовуйте лише приклади, якими вам дозволено ділитися. Видаліть непотрібні ідентифікатори та замініть їх вигаданим прикладом, де ідентичність не додає повчального значення.
Джерела та методологія
- Google: writing procedures
Основні вказівки щодо чітких дій і контексту; вигаданий робочий процес і метод перегляду є прикладами цієї статті.
Задайте своє наступне запитання Colay
Виберіть модель, скористайтеся Auto або об'єднайте кілька точок зору за допомогою Consensus.