Dikaya Pro 2 для рев’ю коду: від умови до перевірних тестів

Мінімальний API-приклад

Ілюстративний Python-код, не виконана відповідь моделі. Ключ береться з оточення, автоматичні повтори вимкнені. Втрата зв’язку може залишити результат і витрати невідомими: не повторюйте запит наосліп.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro-2",
    max_tokens=512,
    messages=[{"role": "user", "content": "Склади перевірний список для мого завдання. Відокрем факти від припущень."}],
)
print(response.choices[0].message.content)

Описуйте дефект через порушений контракт

Розгляньмо функцію, що рахує кількість робочих днів між двома датами для внутрішнього календаря команди. Симптом «інколи отримуємо зайвий день» не визначає, яка межа включна, який часовий пояс застосовується і що робити зі святами. Перш ніж просити виправлення, запишіть ці правила людською мовою. Модель повинна бачити договір поведінки, інакше вона може запропонувати послідовну, але не вашу семантику.

Додайте вхідні значення, фактичний результат і очікуваний результат лише для відомого випадку. Окремо перелічіть питання, на які команда ще не відповіла. Версія мови, бібліотеки дат і спосіб запуску тестів мають значення не менше за саму функцію. Виріжте мінімальний фрагмент із потрібними імпортами, замінивши секрети та приватні дані нейтральними значеннями, які не змінюють сутність помилки.

Спочатку отримайте тест, який справді виявляє проблему

Попросіть Pro 2 запропонувати один тест для підтвердженого випадку та пояснити, яка зміна поведінки зробить його червоним. Перевірка не повинна просто порівнювати два значення, обчислені тим самим помилковим алгоритмом. Для календаря корисно зафіксувати конкретний день тижня, часовий пояс і включність меж. Очікуваний результат обґрунтовується правилами задачі, а не авторитетним тоном відповіді.

Запустіть цей тест локально до правки й прочитайте причину падіння. Помилка імпорту або неправильна команда не є доказом відтворення дефекту. Поверніть моделі лише потрібну діагностику без змінних середовища й ключів. Якщо тест уже зелений, з’ясуйте, чи справді він перевіряє той самий сценарій. Не просіть переписати всю реалізацію, поки не встановлено, що саме поточний тест має захищати.

Обмежте виправлення та збережіть невідоме

У запиті на правку визначте дозволені файли й забороніть супутній рефакторинг. Для функції календаря це може бути зміна обчислення межі без заміни бібліотеки дат і без нового формату збереження. Просіть diff або повну невелику функцію разом із поясненням залежностей. Кожне припущення про навколишній код повинно бути явним, а відсутня функція — приводом попросити фрагмент, не вигадувати її сигнатуру.

Після основного тесту додайте граничні випадки: однакова дата, зворотний інтервал, вихідний на межі, перехід часової зони. Це не вимірювання якості Pro 2, а спосіб перевірити запропонований патч. Якщо поведінка для зворотного інтервалу не визначена контрактом, спочатку прийміть командне рішення. Тест, який мовчки закріплює випадкову відповідь моделі, лише робить невідому вимогу складнішою для подальшої зміни.

Розділяйте пораду, інструмент і реальне виконання

Відповідь у браузерному чаті є текстом. Блок команди не запускає тестовий процес на вашому комп’ютері, а наведений журнал не слід вважати справжнім виконанням без відповідного інструмента й доказу. Попросіть модель назвати команду, очікуваний тип результату та умови успіху. Сам запуск і перегляд фактичного виводу залишаються окремою дією у вашому середовищі розробки.

У клієнті IDE можуть бути власні інструменти роботи з файлами та командами; їхні дозволи не є нативною можливістю кожного запиту API. Так само явний пошук у платному браузері може допомогти знайти документацію бібліотеки, але не підтверджує запуск тестів і не перетворює публічний API на інтернет-інструмент. Джерело документації, пропозиція патча та результат виконання мають залишатися трьома різними видами свідчень.

Плануйте рев’ю з урахуванням демо та виходу

Поточне нове демо використовує Pro 2 і має окремі межі запитів та контексту; старі акаунти зберігають власні знімки умов. Сумісність старого демо Flash не означає відкриття інших моделей. Ліміт демо Pro 2 включає вихід разом із міркуванням, тому велике прохання про рев’ю може залишити замало місця на остаточний текст. Менший явний ліміт у клієнті не скасовується автоматично.

У платному режимі також розрізняйте контекст моделі, обсяг браузерної історії та запас на відповідь. Для першого проходу достатньо контракту, функції та тесту; наступним окремим запитом можна переглянути ширші наслідки. Pro 2 не має нативного зору: зображення коду проходить через окремий оплачуваний опис. Замість скриншота передайте перевірений текст, щоб не втратити відступи, лапки й точні назви символів.

Завершіть рев’ю перевірюваним записом

Підсумок для колеги має містити причину дефекту, межі зміни, назви доданих тестів і фактичні команди, які ви виконали. Незапущені перевірки позначайте окремо. Не зливайте запропонований патч лише тому, що він супроводжується переконливою історією. Перегляньте імпорти, залежності та відсутність сторонніх змін, а потім зіставте результат із початковим контрактом функції й реальними вимогами вашого календаря.

Перед надсиланням підготовленої чернетки перевірте seller-pro-2 у селекторі, дозволи акаунта та можливий пріоритет збереженого тексту. В API використовуйте max_retries=0 і явну межу виходу. Якщо зв’язок обірвався, результат і витрати можуть залишатися невідомими; це не рівнозначно підтвердженому HTTP-відхиленню. Не дублюйте автоматично запит на рев’ю й не вигадуйте для публічного API гарантію ідемпотентності, якої не встановлює приклад SDK.

Запитання й відповіді

Чи є Pro 2 тим самим, що seller-glm-5-3?

Ні. Для Dikaya Pro 2 схвалено опис доопрацьованої версії на основі GLM-5.3, але його API-ID залишається seller-pro-2. seller-glm-5-3 — окрема ідентичність із власними задекларованими параметрами й умовами доступу. Не підмінюйте одну іншою в прикладах, демо або налаштуваннях збереженого діалогу.

Чому модель не підтверджує, що тести пройшли?

Без реального виконання у вашому середовищі вона може лише запропонувати код і команду перевірки. Навіть правдоподібний журнал у відповіді не є доказом запуску. Збережіть фактичний локальний вивід, переконайтеся, що тест падав до правки й проходить після неї, та окремо перелічіть перевірки, які не виконувалися.

Чи вистачить демо для повного рев’ю репозиторію?

Демо призначене для обмеженого знайомства й має власні ліміти запитів, байтів та виходу. Воно не є обіцянкою аналізу всього репозиторію. Почніть з невеликої функції та одного відтворюваного дефекту. Умови раніше створеного акаунта можуть відрізнятися, тому орієнтуйтеся на його фактичний збережений стан.

Як передати код так, щоб рев’ю було корисним?

Додайте текст коду, сигнатури потрібних залежностей, версії середовища та точний очікуваний результат. Видаліть секрети, але не обрізайте частину, яка визначає поведінку. Для помилки потрібен мінімальний приклад відтворення. Скриншот гірше зберігає символи й для Pro 2 означає окремий оплачуваний міст опису зображення.

Джерела

Матеріал підготовлено за допомогою AI. Приклади ілюстративні, а не записи справжніх відповідей чи порівняльних тестів. Зовнішні джерела не замінюють умов сервісу.

• Документація Dikaya: демо, API та обмеження
  dikaya.cc
• Каталог Dikaya: окремі ідентичності Pro 2 та GLM
  dikaya.cc
• OpenAI Python: вимкнення автоматичних повторів
  github.com
• MDN: помилки мережі та читання відповіді Fetch
  developer.mozilla.org