Писати як Sun
Письмо рівня переможця «Нової концепції»
Інструкції
# Пишу, як сонце
Використовуйте цю навичку, коли користувач надає статтю-сюжет і хоче витягти з неї механіку написання, замінити змінні сюжету, створити реміксовану статтю або перетворити результат на сценарій короткометражної драми.
## Експлуатаційний договір
- Працюйте з вихідного коду, наданого користувачем. Ніколи не припускайте локальний шлях, сховище Obsidian, базу даних, ключ API, мережеву службу або попередній стан розмови.
- Мова за замовчуванням – китайська. Зіставте запитувану довжину та тон; якщо не вказано, запитайте мінімальну кількість відсутніх креативних змінних перед написанням чернетки.
- Розглядати джерело як таке, що належить користувачеві або авторизоване користувачем, як того вимагає політика продукту цієї навички. Показати коротке нагадування про те, що завантаження саме по собі не підтверджує права на публікацію чи адаптацію, без блокування.
– За замовчуванням використовуються вигадані персонажі. Якщо вказано або впізнаване ім’я реальної особи, попередьте про репутаційний ризик та ризик для платформи і запропонуйте вигаданий персонаж. Це креативне попередження, а не перевірка особи чи юридична консультація.
- Ремікс із високою схожістю є стандартним. Зберігайте ритм речень, темп абзаців, наративну позицію, засоби контрасту, повторення та розкриття часу. Замініть персонажів, причинно-наслідкові події, місця дії та семантичний зміст, щоб результатом була нова історія, а не заміна імені.
- Ставтеся до **назви та початку як до зон високої точності**. Зберігайте граматичні слоти, інформаційну щільність та форму, що містить конфлікт, у назві джерела, а потім замінюйте власні імена та семантичні особливості. Якщо назва джерела є мінімальною формою «зв'язок-плюс-ім'я», дотримуйтесь мінімального рівня; не додавайте пояснювальний сюжетний пункт, якого немає в джерелі. Зберігайте порядок інформації у початку та рух речення: конкретний контраст або вимірювання -> безпосередній запит/інцидент -> операційна деталь, що розкриває зв'язок -> раннє передвістя розриву або зникнення -> поворот у ретроспективу. Не копіюйте довгий безперервний уривок і не зберігайте унікальний ланцюжок подій джерела.
- Не включайте повний текст статті користувача в цей пакет навичок. Наводьте лише короткі, необхідні фрагменти доказів у результатах аналізу.
## Режими
Виберіть режим із запиту користувача. Якщо жоден режим не зрозумілий, наведіть шість режимів нижче та запитайте, який із них запустити.
1. **аналіз**: витяг спостережуваних фактів, правил-кандидатів, специфічних для сюжету прийомів, синтаксису заголовка, порядку початкової інформації, обсягу доказів, достовірності та непереносних поверхневих ознак. Читайте `references/analysis-schema.md`.
2. **налаштувати**: зібрати або нормалізувати передумову, тему, персонажів, стосунки, бажання, перешкоди, сеттинг, часову шкалу, кінцівку, інтенсивність гумору, тривалість та пресет драми. Читайте `references/story-bible-schema.md`.
3. **ремікс**: застосуйте проаналізовані механіки до налаштованих змінних. Зберігайте поведінку поверхні високого рівня, змінюючи при цьому семантичні події та логіку персонажів. Напишіть чернетку заголовка та початкового плану перед основною частиною. Якщо аналіз відсутній, спочатку проаналізуйте вихідний код.
4. **напишіть**: створіть повну статтю про китайську казку з Біблії оповідань та вибраних механік. Напишіть та перевірте заголовок і вступ, перш ніж розгортати основну частину. Зберігайте причинно-наслідковий зв'язок та мотиви; не пояснюйте мораль, а драматизуйте її.
5. **сценарій**: перетворіть історію як на літературний сценарій, так і на виробничий аркуш штучного інтелекту. Читайте `references/drama-script-schema.md`.
6. **перегляд**: запускати автоматичні перевірки та повідомляти про блокування, попередження, оцінки та конкретні виправлення. Читайте `references/quality-rubric.md`.
## Робочий процес
Слідкуйте за найменшим повним шляхом:
`аналізувати -> налаштувати -> ремікс/записати -> переглянути -> скрипт -> переглянути`
Ознайомтеся з `references/workflow.md` для вхідних та вихідних даних етапу, правил продовження та нотаток щодо бенчмарків GitHub. Користувач може пропустити етап лише тоді, коли необхідний для нього артефакт вже присутній у запиті або робочій області.
На кожному етапі:
1. Вкажіть, який артефакт використовується, а які припущення відсутні.
2. Створіть результат Markdown, зрозумілий для людини.
3. Коли користувач запитує машинозчитуваний вивід, надайте відповідну JSON-форму з відповідної схеми.
4. Замість того, щоб мовчки вигадувати обмеження, чітко формулюйте невирішені рішення.
## Вихідні та якісні вентилі
- Вихідні дані статті повинні містити запитувану назву, точку зору наративу, структурні моменти та кінцівку. Зберігайте корисну механіку джерела, а не його власні назви чи фактичні твердження.
– Назва статті повинна відображати граматику назв, кількість слотів та щільність інформації джерела. Замініть власні іменники та факти джерела, але не робіть мінімальну назву джерела більш пояснювальною або довшим, якщо користувач не просить про зміну назви. Перші абзаци повинні відповідати послідовності аналізу інформації джерела та встановлювати зачіпку перед передісторією. Якщо користувач явно просить про інший початок, дотримуйтесь цього запиту та запишіть відхилення.
- Вивід реміксу повинен містити короткий «опис змін» зі списком змінених персонажів, подій, місця дії, кінцівки, семантики назви та вступних фактів, щоб семантичне перетворення можна було перевірити.
- Вивід сценарію повинен містити обидва результати, зазначені в `references/drama-script-schema.md`. Попередньо встановлена тривалість епізоду за замовчуванням становить 60–90 секунд та 12–24 епізоди; приймаються попередні налаштування, надані користувачем.
- У рецензії необхідно перевірити передумову, цілі персонажів, часову шкалу, причинно-наслідковий зв'язок, зворотні посилання на мотиви, бюджет тривалості/часу, діалоги, гумор, оригінальність семантичних подій, прапорці реальних осіб та повноту формату.
– Ніколи не стверджуйте, що автоматичне оцінювання доводить художню якість або юридичну придатність. Перевірка людиною залишається остаточним рішенням.
Опис
Розмір одного Skill.md — 5,54 KiB. Вага надрукованого рукопису на п’ятдесят мільйонів ієрогліфів — приблизно 250 кілограмів. Writing Like Sun натхненний відомою статтею на X. Він об’єднує заголовок, початок, ритм, структуру, бажання персонажів, повернення до деталей і механіку фіналу в єдиний метод письма, щоб нові вигадані персонажі, тло й події набували однакової оповідної температури. За допомогою цього Skill ви можете створювати історії в абсолютно нових сетингах із таким самим відчуттям, як у «того тексту», а також підвищити структурну, мовну й наративну довершеність до рівня, який уособлює перше місце премії «Нова концепція твору»: спокійно й точно, абсурдно, але правдоподібно, на поверхні цілком серйозно, із деталями, що постійно створюють контраст. Наче описувати сонце — Writing Like the Sun. Цей Skill не стосується жодних реальних людей чи подій.
Схожі навички
Переглянути всі
Коротка байка-пояснення
Ця навичка призначена для перетворення абстрактних понять на захопливі байки, що допомагають користувачам непрямим, конкретним способом зрозуміти складні ідеї. Вона створена для освітян, авторів контенту та всіх, хто потребує глибокого розуміння понять за допомогою інноваційного оповідання. Основна здатність цієї навички полягає в тому, щоб створити стислу коротку байку на основі будь-якого поняття, наданого користувачем. Історія не згадує прямо назву поняття або термінологію, але тонко натякає на глибше значення через сюжет, взаємодію персонажів та розвиток подій. Користувачі побачать, як історія поступово веде читача до розуміння абстрактного поняття за допомогою конкретних сцен і персонажів, а не прямого повчання. Весь процес включає створення байки, детальний аналіз поняття та генерацію двох контрольних запитань. Спочатку навичка генерує байку, яка відповідає суворим оповідним стандартам, забезпечуючи її незалежність та художність. Потім вона точно аналізує відповідність між кожним елементом історії та вихідним поняттям, пояснюючи, як історія відображає структуру та механізм поняття. Нарешті, навичка ставить два конкретних запитання: одне для перевірки розуміння суті поняття, а інше для заохочення застосування поняття в інших сферах, що поглиблює та закріплює навчальний ефект.
Сьогоднішній життєвий сценарій
Використовуючи цей Skill, просто введіть фразу: «Сьогоднішній життєвий сценарій: життя XXX.» щоб отримати повний творчий план, подібний до популярних відео «життєвий сценарій» у Douyin. Skill автоматично створить довгий імерсивний текст із віковим прогресом, життєвими поворотами, стосунками персонажів, конкретними подіями та фінальним результатом на основі вашої професії, ролі, звичок, соціального становища, історичної ролі або фантастичного сценарію. Типовий результат включає: · довгий текст життєвого сценарію на 5–8 хвилин · дикторський текст китайською мовою на 1600–2600 символів · 8–14 життєвих етапів · чистий та емоційний сценарій озвучення · фіксований образ персонажа та єдиний стиль · 30–50 повних розкадровок відео · AI-підказки для зображень та відео для кожного кадру · субтитри SRT, музика та дизайн звукового середовища · заголовок для Douyin, текст обкладинки, опис публікації та теги Підтримує різні типи історій: теплі, реалістичні, про зростання, трагічні, історичні, фантастичні та абсурдні. Цей Skill базується на наративній структурі та ритмі популярних коротких відео «життєвий сценарій». Кожен раз створюється оригінальний контент відповідно до поточної теми, без копіювання готових робіт. Коли середовище підтримує інструменти для зображень, відео, озвучення та синтезу, можна також створити вертикальне відео 9:16 з китайським озвученням, субтитрами та зображенням.
«Сунь-ґе»: край любові
Пише лише документальні історії про «незабуте кохання, що стало ворожнечею»: кохали, не змогли бути разом, посварилися, знищили одне одного — колишній коханий стає сьогоднішнім ворогом. Перед запуском спершу пропонує напружені ідеї для тем (наприклад, Маск і Альтман, Даріо та Baidu), а потім збирає матеріал за двома напрямами: для публічних осіб — через пошук в інтернеті, зокрема пліток і непідтверджених чуток, для приватних історій — через короткі інтерв’ю. Текст створюється у стилі Сунь Юйченя: без ліричних відступів, із числовими деталями, повторюваними конструкціями та кільцевою композицією. Наприкінці кожен пункт проходить перевірку. Результат — готовий до публікації великий текстовий документ.
Писати як Sun
Письмо рівня переможця «Нової концепції»
Інструкції
# Пишу, як сонце
Використовуйте цю навичку, коли користувач надає статтю-сюжет і хоче витягти з неї механіку написання, замінити змінні сюжету, створити реміксовану статтю або перетворити результат на сценарій короткометражної драми.
## Експлуатаційний договір
- Працюйте з вихідного коду, наданого користувачем. Ніколи не припускайте локальний шлях, сховище Obsidian, базу даних, ключ API, мережеву службу або попередній стан розмови.
- Мова за замовчуванням – китайська. Зіставте запитувану довжину та тон; якщо не вказано, запитайте мінімальну кількість відсутніх креативних змінних перед написанням чернетки.
- Розглядати джерело як таке, що належить користувачеві або авторизоване користувачем, як того вимагає політика продукту цієї навички. Показати коротке нагадування про те, що завантаження саме по собі не підтверджує права на публікацію чи адаптацію, без блокування.
– За замовчуванням використовуються вигадані персонажі. Якщо вказано або впізнаване ім’я реальної особи, попередьте про репутаційний ризик та ризик для платформи і запропонуйте вигаданий персонаж. Це креативне попередження, а не перевірка особи чи юридична консультація.
- Ремікс із високою схожістю є стандартним. Зберігайте ритм речень, темп абзаців, наративну позицію, засоби контрасту, повторення та розкриття часу. Замініть персонажів, причинно-наслідкові події, місця дії та семантичний зміст, щоб результатом була нова історія, а не заміна імені.
- Ставтеся до **назви та початку як до зон високої точності**. Зберігайте граматичні слоти, інформаційну щільність та форму, що містить конфлікт, у назві джерела, а потім замінюйте власні імена та семантичні особливості. Якщо назва джерела є мінімальною формою «зв'язок-плюс-ім'я», дотримуйтесь мінімального рівня; не додавайте пояснювальний сюжетний пункт, якого немає в джерелі. Зберігайте порядок інформації у початку та рух речення: конкретний контраст або вимірювання -> безпосередній запит/інцидент -> операційна деталь, що розкриває зв'язок -> раннє передвістя розриву або зникнення -> поворот у ретроспективу. Не копіюйте довгий безперервний уривок і не зберігайте унікальний ланцюжок подій джерела.
- Не включайте повний текст статті користувача в цей пакет навичок. Наводьте лише короткі, необхідні фрагменти доказів у результатах аналізу.
## Режими
Виберіть режим із запиту користувача. Якщо жоден режим не зрозумілий, наведіть шість режимів нижче та запитайте, який із них запустити.
1. **аналіз**: витяг спостережуваних фактів, правил-кандидатів, специфічних для сюжету прийомів, синтаксису заголовка, порядку початкової інформації, обсягу доказів, достовірності та непереносних поверхневих ознак. Читайте `references/analysis-schema.md`.
2. **налаштувати**: зібрати або нормалізувати передумову, тему, персонажів, стосунки, бажання, перешкоди, сеттинг, часову шкалу, кінцівку, інтенсивність гумору, тривалість та пресет драми. Читайте `references/story-bible-schema.md`.
3. **ремікс**: застосуйте проаналізовані механіки до налаштованих змінних. Зберігайте поведінку поверхні високого рівня, змінюючи при цьому семантичні події та логіку персонажів. Напишіть чернетку заголовка та початкового плану перед основною частиною. Якщо аналіз відсутній, спочатку проаналізуйте вихідний код.
4. **напишіть**: створіть повну статтю про китайську казку з Біблії оповідань та вибраних механік. Напишіть та перевірте заголовок і вступ, перш ніж розгортати основну частину. Зберігайте причинно-наслідковий зв'язок та мотиви; не пояснюйте мораль, а драматизуйте її.
5. **сценарій**: перетворіть історію як на літературний сценарій, так і на виробничий аркуш штучного інтелекту. Читайте `references/drama-script-schema.md`.
6. **перегляд**: запускати автоматичні перевірки та повідомляти про блокування, попередження, оцінки та конкретні виправлення. Читайте `references/quality-rubric.md`.
## Робочий процес
Слідкуйте за найменшим повним шляхом:
`аналізувати -> налаштувати -> ремікс/записати -> переглянути -> скрипт -> переглянути`
Ознайомтеся з `references/workflow.md` для вхідних та вихідних даних етапу, правил продовження та нотаток щодо бенчмарків GitHub. Користувач може пропустити етап лише тоді, коли необхідний для нього артефакт вже присутній у запиті або робочій області.
На кожному етапі:
1. Вкажіть, який артефакт використовується, а які припущення відсутні.
2. Створіть результат Markdown, зрозумілий для людини.
3. Коли користувач запитує машинозчитуваний вивід, надайте відповідну JSON-форму з відповідної схеми.
4. Замість того, щоб мовчки вигадувати обмеження, чітко формулюйте невирішені рішення.
## Вихідні та якісні вентилі
- Вихідні дані статті повинні містити запитувану назву, точку зору наративу, структурні моменти та кінцівку. Зберігайте корисну механіку джерела, а не його власні назви чи фактичні твердження.
– Назва статті повинна відображати граматику назв, кількість слотів та щільність інформації джерела. Замініть власні іменники та факти джерела, але не робіть мінімальну назву джерела більш пояснювальною або довшим, якщо користувач не просить про зміну назви. Перші абзаци повинні відповідати послідовності аналізу інформації джерела та встановлювати зачіпку перед передісторією. Якщо користувач явно просить про інший початок, дотримуйтесь цього запиту та запишіть відхилення.
- Вивід реміксу повинен містити короткий «опис змін» зі списком змінених персонажів, подій, місця дії, кінцівки, семантики назви та вступних фактів, щоб семантичне перетворення можна було перевірити.
- Вивід сценарію повинен містити обидва результати, зазначені в `references/drama-script-schema.md`. Попередньо встановлена тривалість епізоду за замовчуванням становить 60–90 секунд та 12–24 епізоди; приймаються попередні налаштування, надані користувачем.
- У рецензії необхідно перевірити передумову, цілі персонажів, часову шкалу, причинно-наслідковий зв'язок, зворотні посилання на мотиви, бюджет тривалості/часу, діалоги, гумор, оригінальність семантичних подій, прапорці реальних осіб та повноту формату.
– Ніколи не стверджуйте, що автоматичне оцінювання доводить художню якість або юридичну придатність. Перевірка людиною залишається остаточним рішенням.
Опис
Розмір одного Skill.md — 5,54 KiB. Вага надрукованого рукопису на п’ятдесят мільйонів ієрогліфів — приблизно 250 кілограмів. Writing Like Sun натхненний відомою статтею на X. Він об’єднує заголовок, початок, ритм, структуру, бажання персонажів, повернення до деталей і механіку фіналу в єдиний метод письма, щоб нові вигадані персонажі, тло й події набували однакової оповідної температури. За допомогою цього Skill ви можете створювати історії в абсолютно нових сетингах із таким самим відчуттям, як у «того тексту», а також підвищити структурну, мовну й наративну довершеність до рівня, який уособлює перше місце премії «Нова концепція твору»: спокійно й точно, абсурдно, але правдоподібно, на поверхні цілком серйозно, із деталями, що постійно створюють контраст. Наче описувати сонце — Writing Like the Sun. Цей Skill не стосується жодних реальних людей чи подій.
Схожі навички
Переглянути всіКоротка байка-пояснення
Ця навичка призначена для перетворення абстрактних понять на захопливі байки, що допомагають користувачам непрямим, конкретним способом зрозуміти складні ідеї. Вона створена для освітян, авторів контенту та всіх, хто потребує глибокого розуміння понять за допомогою інноваційного оповідання. Основна здатність цієї навички полягає в тому, щоб створити стислу коротку байку на основі будь-якого поняття, наданого користувачем. Історія не згадує прямо назву поняття або термінологію, але тонко натякає на глибше значення через сюжет, взаємодію персонажів та розвиток подій. Користувачі побачать, як історія поступово веде читача до розуміння абстрактного поняття за допомогою конкретних сцен і персонажів, а не прямого повчання. Весь процес включає створення байки, детальний аналіз поняття та генерацію двох контрольних запитань. Спочатку навичка генерує байку, яка відповідає суворим оповідним стандартам, забезпечуючи її незалежність та художність. Потім вона точно аналізує відповідність між кожним елементом історії та вихідним поняттям, пояснюючи, як історія відображає структуру та механізм поняття. Нарешті, навичка ставить два конкретних запитання: одне для перевірки розуміння суті поняття, а інше для заохочення застосування поняття в інших сферах, що поглиблює та закріплює навчальний ефект.
Сьогоднішній життєвий сценарій
Використовуючи цей Skill, просто введіть фразу: «Сьогоднішній життєвий сценарій: життя XXX.» щоб отримати повний творчий план, подібний до популярних відео «життєвий сценарій» у Douyin. Skill автоматично створить довгий імерсивний текст із віковим прогресом, життєвими поворотами, стосунками персонажів, конкретними подіями та фінальним результатом на основі вашої професії, ролі, звичок, соціального становища, історичної ролі або фантастичного сценарію. Типовий результат включає: · довгий текст життєвого сценарію на 5–8 хвилин · дикторський текст китайською мовою на 1600–2600 символів · 8–14 життєвих етапів · чистий та емоційний сценарій озвучення · фіксований образ персонажа та єдиний стиль · 30–50 повних розкадровок відео · AI-підказки для зображень та відео для кожного кадру · субтитри SRT, музика та дизайн звукового середовища · заголовок для Douyin, текст обкладинки, опис публікації та теги Підтримує різні типи історій: теплі, реалістичні, про зростання, трагічні, історичні, фантастичні та абсурдні. Цей Skill базується на наративній структурі та ритмі популярних коротких відео «життєвий сценарій». Кожен раз створюється оригінальний контент відповідно до поточної теми, без копіювання готових робіт. Коли середовище підтримує інструменти для зображень, відео, озвучення та синтезу, можна також створити вертикальне відео 9:16 з китайським озвученням, субтитрами та зображенням.
«Сунь-ґе»: край любові
Пише лише документальні історії про «незабуте кохання, що стало ворожнечею»: кохали, не змогли бути разом, посварилися, знищили одне одного — колишній коханий стає сьогоднішнім ворогом. Перед запуском спершу пропонує напружені ідеї для тем (наприклад, Маск і Альтман, Даріо та Baidu), а потім збирає матеріал за двома напрямами: для публічних осіб — через пошук в інтернеті, зокрема пліток і непідтверджених чуток, для приватних історій — через короткі інтерв’ю. Текст створюється у стилі Сунь Юйченя: без ліричних відступів, із числовими деталями, повторюваними конструкціями та кільцевою композицією. Наприкінці кожен пункт проходить перевірку. Результат — готовий до публікації великий текстовий документ.
Знайдіть свою наступну улюблену навичку
Досліджуйте більше підібраних AI-навичок для досліджень, творчості та повсякденної роботи.