Colay / ガイド
指示を失わずに 1 つのナレッジベース記事を書き直す
ナレッジベースを書き直すと、読者の次のアクションがより明確になります。 Colay では、いくつかの AI ドラフトにより、記事が短い手順として機能するか、トラブルシューティング ツリーとして機能するか、例を使った説明として機能するかが明らかになります。まずは 1 つの記事と検証済みのファクトシートから始めます。成果物は、追跡可能な手順を含む改訂された記事であり、魅力的な言い換えを集めたものではありません。
記事の読者と、達成する作業を一つに絞る
現在、通知設定の変更に関する記事には、アカウントの設定、権限、トラブルシューティングが混在している場合があります。書き直す前に、読者の出発点と達成すべき結果を述べてください。それ以外のすべては、前提条件、関連リンク、または別の記事に記載してください。この編集上の選択は、多くの場合、論調を変えることよりも重要です。
タスク カードを作成します: 記事 ID、対象読者、サポートされている製品バージョン、必要な役割、正確なインターフェイス ラベル、期待される結果、既知の例外、所有者。承認された材料のみを使用してください。ステップが不確かな場合は、モデルに記憶とのギャップを埋めるように依頼するのではなく、検証のためにステップにラベルを付けます。 Google の手順ガイダンスは、アクションに焦点を当てた手順と、アクションを見つけるための十分なコンテキストをサポートしています。
製品の事実を固定した架空のリライト例
架空のワークスペース ツールを考えてみましょう。メンバーは、[設定] → [通知] で個人の電子メール通知をミュートできます。組織全体のデフォルトを変更できるのは所有者だけです。保存された設定は、今後のメールに影響します。すでにキューに入れられているメッセージは削除されません。これらはサンプル用に考案された入力であり、Colay の機能ではありません。
同じ事実を使用して異なる構造を要求します。手順は、誰かがタスクをすぐに完了するのに役立ちます。トラブルシューティング バージョンは、コントロールが見つからない人に役立ちます。キューに入れられた電子メールの例外については、FAQ で説明されています。要求された 8 つのアプローチが可能ですが、同じ文章を増やすのではなく、8 つの読書状況に対応する必要があります。
| 読者の状況 | 便利な形式 | 必ず保持する事実 |
|---|---|---|
| 何を変えたいのかはわかっています | 番号付きの手順 | 設定 → 通知が指定された場所です |
| 組織のデフォルトを変更できません | ロールベースのトラブルシューティング | 指定された権限を持つのは所有者のみです |
| メールをミュートしましたが、別のメッセージを受信しました | 例外を含む簡単な説明 | キューに入れられたメッセージは影響を受けません |
文言と製品の真実を区別するプロンプト
Colay で Ask separately を使用して、選択したエージェントがタスクをどのように解釈するかを確認します。記事全体を修正する前に、概要を比較してください。ある回答ではアクセス許可要件が削除され、他の回答では許可要件が維持されている場合は、承認されたソースを調べてください。合意は、文書化されたワークフローのテストに代わるものではありません。
この承認済みナレッジベース記事を書き直します: [テキスト]。タスク カード: [対象ユーザー、製品バージョン、役割、正確な UI ラベル、期待される結果、例外]。番号付きのハウツー バージョン、トラブルシューティング バージョン、および短い FAQ バージョンを作成します。すべての条件、許可、例外を維持します。制御や動作を発明しないでください。バージョンごとに、各命令をサポートするソース文をリストします。不明瞭または矛盾する出典資料は別の質問リストに記入してください。 [読者の状況] に合わせて 1 つの構造を推奨し、その選択について説明します。異なる製品バージョンのファクトを黙って組み合わせないでください。
最高のドラフトを公開可能なリビジョンに変換する
最終的な成果物は、承認されたタイトル、前提条件、手順、期待される結果、例外、および 1 つの関連する次のリンクなど、小規模なものにすることができます。ソースと命令のマッピングを編集メモとともに保管してください。 Colay は草稿と比較を支援します。このワークフローは、ナレッジ ベースに接続したり、変更を自動的に公開したりできることを意味するものではありません。
- タスク カードに一致する構造を選択してください。他の下書きからの有用な文は、意味を確認してから保存してください。
- 指定された権限のユーザーとして、対応する製品バージョンで各手順を実行します。表示名、順序、結果、記載された例外を確認します。
- 新規ユーザーとして記事を読んでください。前提条件が必要になる前に表示され、失敗したステップには次のアクションが利用可能である必要があります。
- 査読者、記事のバージョン、変更されたセクションを記録します。既存のナレッジ ベース ワークフローを通じて公開し、比較のために以前のバージョンを保持します。
読者が何ができるかによってリライトを判断する
ドラフトに詳しくない同僚に出発点を見つけてもらい、許可要件を特定し、最後のステップの後に何が起こるかを説明してもらいます。誤解を編集上の問題として記録します。その記事に対するフィードバックや検索データがある場合は、すべての変更を AI のせいにすることなく、公開後に同じシグナルを比較してください。残りの作業が、文言の選択ではなく、製品に関する事実が欠落している場合は、生成を停止します。
質問と回答
8 つのバージョンすべてを公開する必要がありますか?
通常は不要です。これらは一つの読者の作業に対する候補です。最も明確で適切な版を公開し、異なるニーズに応える場合だけ記事を分けます。
モデルは古い説明書を修復できますか?
検証済みの新しい事実を与えた場合に限ります。もっともらしい新しいボタン名が出ても、製品がそのように動く証拠にはなりません。
記事に個人顧客の例が含まれている場合はどうなりますか?
共有を許可された例だけを使います。不要な識別情報を取り除き、本人を特定する情報が説明に役立たない場合は架空の例に置き換えます。
出典と方法
- Google: writing procedures
明確なアクションステップとコンテキストに関する主要なガイダンス。架空のワークフローとレビュー方法は、この記事の例です。
次の質問を Colay に送ってください。
モデルを選択するか、Autoを使用するか、Consensusを使用して複数の視点を組み合わせます。