AI Skills
printing-press-output-review

printing-press-output-review

熱門

內部子技能：以代理方式審查已列印 CLI 的取樣命令輸出，找出基於規則的檢查無法編碼的合理性問題（子字串比對相關性、格式錯誤、無聲來源遺漏、排序失敗）。由主要 printing-press SKILL.md（第 4.85 階段）和 printing-press-polish SKILL.md 在診斷循環中透過 Skill 工具呼叫。不供使用者直接呼叫——其可操作的包裝為 /printing-press 和 /printing-press-polish。

4028星標
441分支
更新於 2026/7/16
獲取技能源代碼

相關技能

webapp-testing6.9萬dogfood22萬agent-tester7.1萬
SKILL.md
唯讀
名稱
printing-press-output-review
描述

內部子技能：以代理方式審查已列印 CLI 的取樣命令輸出，找出基於規則的檢查無法編碼的合理性問題（子字串比對相關性、格式錯誤、無聲來源遺漏、排序失敗）。由主要 printing-press SKILL.md（第 4.85 階段）和 printing-press-polish SKILL.md 在診斷循環中透過 Skill 工具呼叫。不供使用者直接呼叫——其可操作的包裝為 /printing-press 和 /printing-press-polish。

printing-press-output-review（內部）

審查已列印 CLI 的取樣輸出，找出 dogfood、verify 以及基於規則的 scorecard --live-check 規則無法捕捉的合理性錯誤。Wave B 政策：所有發現以警告形式呈現，絕不為錯誤。

此技能為僅供內部使用（user-invocable: false）。由父技能呼叫——主要 printing-press 技能在 shipcheck 第 4.85 階段，polish 技能在其診斷循環中。獨立執行會產生浮動的發現文字，沒有出貨判定、不套用修正、不提供發布選項；可操作的包裝為 /printing-press 和 /printing-press-polish。技能帶有 context: fork，使審查代理的診斷對話與呼叫技能的上下文隔離。

輸入

呼叫者傳遞 $CLI_DIR 作為引數：已列印 CLI 工作目錄的絕對路徑。

此技能捕捉的問題

基於規則的檢查遺漏的錯誤，通常透過 5 分鐘的手動測試發現，但逃過 dogfood、verify 和 scorecard --live-check 規則：

  • 子字串比對結果偶然包含查詢字詞但語義上不匹配（例如，查詢匹配到較大不相關術語的子字串）
  • 聚合命令在僅回傳部分要求的 N 個來源時無聲地遺漏來源
  • 排名或排序命令回傳的前 N 個結果在查詢下並非合理最佳（權重錯誤、提取器備援）
  • 輸出中的 URL 指向類別索引頁面、饋送端點或隨機選擇器路由，而非標準內容永久連結
  • 基於規則的層級未捕捉的格式錯誤（亂碼、不一致的複數形式、截斷/換行的儲存格內容）

程序

步驟 1：收集取樣資料

# 定位 research.json。與二進位檔相鄰涵蓋 promotion 後的佈局（獨立 polish、針對函式庫副本的 shipcheck）。
# 祖父目錄備援涵蓋管線中期呼叫，其中 $CLI_DIR 為
# $PRESS_RUNSTATE/runs/<id>/working/<cli>，而 research.json 位於
# $PRESS_RUNSTATE/runs/<id>/research.json。沒有備援時，scorecard 在管線中期回報
# `unable: true`，我們會跳過最資訊豐富的審查。
# 使用 bash 陣列讓旗標能處理含空格的路徑。
RESEARCH_ARGS=()
if [ ! -f "$CLI_DIR/research.json" ]; then
  _grandparent="$(dirname "$(dirname "$CLI_DIR")")"
  if [ -f "$_grandparent/research.json" ]; then
    RESEARCH_ARGS=(--research-dir "$_grandparent")
  fi
fi

cli-printing-press scorecard --dir "$CLI_DIR" "${RESEARCH_ARGS[@]}" --live-check --json > /tmp/output-review-livecheck.json 2>&1 || true

如果 scorecard 呼叫失敗或 /tmp/output-review-livecheck.json 為空，則回傳 SKIP 結果（步驟 3），不派遣審查代理。

步驟 2：派遣審查代理

使用 Agent 工具（通用型），並遵循以下提示合約：

審查位於 $CLI_DIR 的已出貨 CLI 的取樣輸出。你有以下真實來源：

  • 取樣命令輸出：讀取 /tmp/output-review-livecheck.json 並檢查 live_check.features[] 陣列。每個條目包含命令、範例呼叫、經過處理的 stdout 證據（在 output_sample 中，限制約 4 KiB）、經過處理的通過/失敗原因，以及 warnings 陣列（由基於規則的檢查如原始 HTML 實體偵測器填入）。將 <redacted> 標記視為隱私處理過的值，而非格式錯誤。
  • 僅審查 status: pass 的條目。 status: fail 的條目可能崩潰、超時或具有佔位符引數（<id>、<url>），從未產生真實輸出——其樣本為空，沒有可供判斷的內容。第 5 階段的 dogfood 會處理測試覆蓋率和退出碼問題。
  • $CLI_DIR/research.json 中的 novel_features（每個功能的預期行為）和 novel_features_built（已驗證的已建置命令）。
  • 位於 $CLI_DIR/<cli-name>-pp-cli 的 CLI 二進位檔——當發現需要驗證時，你可以呼叫其他命令以收集更多輸出。

針對以下每項檢查，回報發現，每項不超過 50 字。僅回報人類使用者在 5 分鐘手動測試中會注意到的問題——而非詳盡 QA 可能發現的每個邊緣案例：

  1. 輸出在語義上符合查詢意圖。 對於具有查詢引數的取樣新功能，判斷相關性，超越 live-check 已強制的機械式查詢權杖檢查。通過 live-check 的 outputMentionsQuery 測試的功能仍然在某處包含某些查詢權杖——但「buttermilk」作為「butter」結果的子字串出現，或「brownies」因提取器備援到相鄰內容而回傳辣椒食譜，兩者都逃過機械式檢查。僅在人類使用者查看頂部結果並說「這不是我想要的」時才標記。當範例沒有查詢引數時跳過此檢查。
  2. 沒有明顯的格式錯誤。 輸出是否包含原始 HTML 實體、亂碼（標題中的問號或替代字元）或格式錯誤的 URL（指向類別索引頁面、饋送端點或隨機選擇器路由，而非標準內容永久連結）？基於規則的 live-check 會捕捉數字實體；此層級捕捉更廣泛的類別。
  3. 聚合命令顯示所有請求的來源。 對於帶有 --source/--site/--region CSV 旗標的命令：如果使用者請求 N 個來源，輸出是否顯示 N 個，或者 stderr 是否解釋遺漏的來源？失敗來源的無聲遺漏是扇出命令的主要失敗模式。
  4. 結果排序/排名合理。 對於聲稱排名或排序的命令，頂部結果在給定查詢下是否看起來合理最佳？注意權重錯誤、差一排序錯誤，以及相關性計算失敗時無聲備援到最新。

學習循環命令樣本（recall、learnings、playbook）的校準：在新列印中，本地學習儲存初始為空，因此空的候選清單、零計數的 learnings stats 和「未記錄學習」的輸出是合理正確的。不要將其標記為無聲失敗或遺失資料。

回傳發現清單。每項包含：檢查名稱、嚴重性（Wave B 為 warning；error 保留給 Wave C）、一行描述、一句修正建議。如果 CLI 通過所有四項檢查，回傳「PASS — no findings.」

步驟 3：輸出結構化結果區塊

以父技能解析的 ---OUTPUT-REVIEW-RESULT--- 區塊結束技能回應：

乾淨通過時：

---OUTPUT-REVIEW-RESULT---
status: PASS
findings: []
---END-OUTPUT-REVIEW-RESULT---

有警告時：

---OUTPUT-REVIEW-RESULT---
status: WARN
findings:
- check: <check-name>
  severity: warning
  description: <one-line>
  suggestion: <one-sentence>
- ...
---END-OUTPUT-REVIEW-RESULT---

審查失敗時（超時、代理預算耗盡、缺少 live-check 資料）：

---OUTPUT-REVIEW-RESULT---
status: SKIP
reason: <one-line description>
findings: []
---END-OUTPUT-REVIEW-RESULT---

Wave B 政策（目前）

  • 所有發現以 warning 呈現——絕不為 error。Shipcheck 無論如何都會繼續。
  • 呼叫者將發現記錄到執行的工件目錄（例如 manuscripts/<api>/<run>/proofs/phase-4.85-findings.md）並呈現給使用者。發現不會持久化到 scorecard.json——該路徑保留給 Wave C。
  • 使用者根據個案決定是否在出貨前修正。

非互動合約（CI、cron、批次重新產生）：

  • 如果 stdout 不是 TTY，呼叫者遵循 fail-open-with-log：記錄發現，shipcheck 繼續而不提示。
  • status: SKIP（審查崩潰、超時、資料遺失）僅供參考——shipcheck 不會因此阻塞。
  • 尚無 --auto-approve-warnings 旗標。在 Wave B 中，政策已經是「警告不阻塞」，因此該旗標沒有閘控效果。

Wave C（單獨的未來 PR）將在函式庫中校準資料顯示誤報率低於 10% 後，將 error 嚴重性的發現轉為阻塞。

為何使用代理而非僅範本

輸出合理性問題無法透過原始碼進行模式比對。基於規則的 live-check 規則涵蓋正規表示式能處理的內容（數字 HTML 實體、查詢權杖缺失）。其他所有問題——「這些替換結果對查詢而言是否合理正確？」、「頂部搜尋結果看起來相關嗎？」——都是 LLM 適合的問題。權杖成本有限（每次執行一次，而非每個命令），且針對促使此階段的錯誤類別的捕捉率證明了派遣的合理性。

已知盲點

  • 無法驗證數值準確性（價格、評分、排名與真實值比較）。如果 CLI 說食譜有 4.8 顆星但實際只有 4.2，此技能無法捕捉。
  • 無法偵測資料新鮮度問題（食譜發布於 2019 年 vs 2024 年）。這些需要與權威來源進行即時比較。
  • 無法判斷主觀偏好（「這是否是巧克力餅乾的最佳食譜？」）。
  • 僅取樣輸出——涵蓋 live_check.features[] 中的命令。完整的命令樹覆蓋屬於第 5 階段的 dogfood。
  • 非英文輸出：審查者的查詢意圖檢查假設英文查詢/輸出。對於非英文 CLI，請單獨校準提示。