程式碼、模型、Demo 與開發紀錄證據

公開儲存庫能證明什麼？

能證明某些檔案與歷史公開存在，不自動證明它們完整、可執行或已部署。

檢查 license、依賴鎖定、測試、release tag 和建置說明，再比較公開介面的版本標記。鏡像、範例或過時 branch 應標明，commit 頻率也不能代替產品能力。

如何留下證據： 保存 repo URL、commit SHA、license、build 結果與部署連結。

宣稱使用的模型要如何核對？

要界定模型名稱、提供者、版本、微調或路由角色，以及執行時真正被呼叫的端點。

「自有模型」可能指 prompt、微調權重、封裝 API 或完整訓練。要求產品把所有權範圍說清楚；若有多模型路由，還要記錄每個任務實際落到哪個模型。

如何留下證據： 保存 model card、API 回應欄位、設定版本和可公開的執行 metadata。

什麼條件讓 Demo 成為有效證據？

使用者能控制輸入、保存輸出、知道版本，並能重跑正常與失敗案例時，Demo 才有較高權重。

錄影可保存聲明，但無法排除剪輯或後台操作。互動 Demo 還需揭露資料是否預先準備、人工是否介入、工具結果是否真實，以及測試資產是否受限。

如何留下證據： 保存輸入、輸出、時間、版本、網路請求或 trace 與重跑差異。

如何閱讀開發活動？

看變更是否持續連到產品問題、測試與 release，而不是只計數量。

大量自動 commit、文件格式化或依賴更新不等於核心能力進展。較有用的是 issue→pull request→測試→release→部署的鏈條，以及安全回報和回歸修復速度。

如何留下證據： 抽樣保存變更類型、作者分布、review、測試和 release notes。

最終證據表要怎麼建立？

每列只放一項聲明，並分開記錄來源、版本、直接性、重做結果和限制。

同一來源可支持多列，但不能因此提高獨立性。對矛盾來源保留雙方的日期與適用版本；最後狀態由最接近產品行為且範圍匹配的證據決定。

如何留下證據： 欄位包含 claim、artefact、version、test、result、limit、status、review date。

驗證工作簿

以下檢查卡把研究變成可重做紀錄。它們不產生投資建議，而是要求保存證據、反例、版本、限制與會改變結論的條件。

常見問題