それはどのような問題を解決しますか
エージェントによって与えられる解決策型の出力は通常、結論を前面に出し、結論が依存する事実の仮定は物語の中に隠されています。読者はまず結論を受け入れてから、実際には当てはまらない結論に遭遇する必要があります。
たとえば、「オーダー リスト インターフェイスの最適化計画」には「ジョイント インデックスの追加、Redis キャッシュの追加、ページング戦略の変更」が含まれており、読み取られた時点で構造は完了します。ただし、デフォルトでは、速度の低下はネットワークではなくデータベースにあり、テーブルの行数は 5,000 万未満、読み取りリクエストが 90% を占め、テーブル ロックは許可されており、テーブル ロックは許可されていません。 tenant_id。これらの前提はどれも書き留められていません。
既存のツールは「問題」、「修正」、「信頼性」を報告しますが、「どの事実がこの結論を裏付けるか」は報告しません。このスキルは次の位置を占めます。前提を物語から取り出して、それを 1 つずつチェックできるリストに変換し、各バインディングの範囲を無効にする必要があります。
提案の内容は変更されません。提案を信頼する前に読者が確認できる内容のみが変更されます。
出力はどのようになりますか?
入力は「注文リストのインターフェースが少し遅いので、最適化計画を教えてください。」です。このスキルをインストールすると、プランの先頭に前提条件チケットが表示されます。
前提小票
1. 慢在数据库而非网络 ｜ 若不成立：§1 §2 全部作废
2. orders 表 < 5000 万行 ｜ 若不成立：§2 的建索引方式作废，需改分区表
3. 读请求占 90% 以上 ｜ 若不成立：§3 缓存收益归零，整节作废
4. 允许 5 分钟以内锁表 ｜ 若不成立：§2 需改为在线 DDL
5. ⚠ 未确认：orders 是否有 tenant_id ｜ 若有：§2 联合索引列顺序反转 ｜ 确认方式：\d orders
