五分鐘面試展示

AI Coding Agent:從任務到可驗證決策

所有內容來自真實 Task、Agent Run、測試、Evidence 與 Replay;不是預先寫死的成功畫面。

01

人工審核後才交給 Agent

Notion 是內部任務來源;外部 GitHub Issue 先進 Inbox。未經人工接受或連結,不會污染 Notion,也不能啟動 Agent。

真實 E2E Task

修正同步失敗後缺少重試提示

同步工作失敗時,使用者需要清楚知道原因與下一步操作。

bugNotion已完成
02

Context 不是整個 Repository

Agent 先做 Hybrid Retrieval,索引綁定 commit。Embedding 失敗會降級 Keyword;Evaluation fixture 不允許進正式 Context。

檢索方式Hybrid
Context Files10
Context Chars39659
檢索耗時8.2s
apps/web/app/api/agent-runs/[id]/replay/route.tsapps/web/app/api/internal/sync-jobs/process/route.tsapps/web/app/api/sync-jobs/[id]/retry/route.tsapps/web/app/api/tasks/[id]/prepare-patch/route.tsapps/web/app/evaluations/cases/[id]/page.tsxapps/web/app/evaluations/page.tsxapps/web/app/page.tsxapps/web/app/runs/[id]/page.tsxapps/web/app/sync/page.tsxapps/web/lib/data.ts
03

Agent 是可檢查的工作流程

這不是單次 LLM 呼叫。Baseline 先通過,模型才可修改;Patch 後重新執行 lint、typecheck、test,最多修正三次。

1
Context Retrieval完成 · 2 次
→
2
Baseline完成 · 3 次
→
3
Plan完成
→
4
Patch尚未執行
→
5
Check尚未執行
→
6
Evidence Gate尚未執行
7
Human Approval尚未進入
結果failed
嘗試1
風險medium
成本$0.0301

目前沒有產生程式碼 Diff。

04

沒有可驗證證據就不能核准

模型必須引用檔案、行號與原始片段。Worker 對照實際 Context 驗證,不相信模型自行宣稱『已確認』。

分析摘要

同步失敗提示目前只提供前往同步紀錄的入口;Webhook 失敗事件沒有重試操作,且現有重試 API 僅支援 sync_jobs。需要補上事件重試流程,才能完整符合「失敗摘要與重試入口」的驗收條件。

中型修改中風險禁止修正
預計修改
  • 確認 sync_events 失敗後的正確重試語意:新增事件重試端點,或將失敗事件重新排入對應的 sync_jobs。
  • 在同步紀錄頁為 failed 的 Webhook 事件顯示重試按鈕,並保留錯誤摘要。
  • 確認重試成功後事件或工作狀態更新,首頁的「同步需要處理」警報會自動消失。
  • 若產品只要求 sync_jobs 重試,則將首頁入口文案由「查看同步記錄」改為更明確的「查看並重試」,並補充失敗工作的直接重試入口。
驗收方式
  • ✓sync_jobs 與 sync_events 的失敗狀態都能顯示錯誤摘要及可操作的重試入口。
  • ✓重試請求成功排隊後,失敗項目不再被首頁的待處理警報計入。
  • ✓重試執行成功後,頁面不再顯示待處理警報。
  • ✓重試請求失敗時仍保留原錯誤資訊,且不會誤顯示成功狀態。
風險原因
  • 需要新增 sync_events 的重試 API 或明確重用既有 sync_jobs 流程,但目前 repository_context 沒有提供事件重試端點或 sync_events 的處理契約。
  • 錯誤重試若未正確重置事件狀態,可能造成重複處理或狀態長期停留在 failed。
程式碼證據
apps/web/app/page.tsx:9-10已由 Worker 驗證
  const failedJobs = syncJobs.filter(job => job.status === "failed");
  const failedEvents = syncEvents.filter(event => event.status === "failed");

首頁會統計同步工作與 Webhook 事件的失敗數量,表示兩種失敗都會觸發待處理提示。

apps/web/app/page.tsx:31-31已由 Worker 驗證
    {failedJobs.length + failedEvents.length > 0 && <section className="section card alert-card"><div><h2>同步需要處理</h2><p className="muted">有 {failedJobs.length} 筆回寫工作與 {failedEvents.length} 筆 Webhook 事件失敗。</p></div><Link className="button secondary" href="/sync">查看同步紀錄</Link></section>}

首頁只提供查看同步紀錄的連結,沒有直接或明確的重試入口。

apps/web/app/sync/page.tsx:21-27引用無法驗證
        <tbody>{jobs.map(job => <tr key={job.id}>
          <td>{job.work_items?.title ?? "未知任務"}</td>
          <td>{actionLabels[job.action] ?? job.action}</td>
          <td><StatusBadge value={job.status} /></td>
          <td>{job.attempt_count} / 3</td>
          <td className="muted">{job.last_error ?? "—"}</td>
          <td>{job.status === "failed" && <ActionButton endpoint={`/api/sync-jobs/${job.id}/retry`} label="重新同步" tone="secondary" />}</td>
        </tr>)}</tbody>

sync_jobs 已有錯誤摘要與重試按鈕,但目前只涵蓋 jobs。

apps/web/app/api/sync-jobs/[id]/retry/route.ts:6-17已由 Worker 驗證
  const { data, error } = await adminDb()
    .from("sync_jobs")
    .update({ status: "queued", attempt_count: 0, last_error: null, available_at: new Date().toISOString() })
    .eq("id", id)
    .eq("status", "failed")
    .select("id")
    .maybeSingle();
  if (error) return failure(error.message, 500);
  if (!data) return failure("只有失敗的同步工作可以重新執行", 409);
  scheduleSyncJobs();
  return ok({ queued: true });

現有重試端點只更新 sync_jobs,無法處理首頁同樣統計的 failed sync_events。

相關檔案
apps/web/app/page.tsxapps/web/app/sync/page.tsxapps/web/app/api/sync-jobs/[id]/retry/route.tsapps/web/lib/data.ts
05

相同條件下比較 Prompt

Exact Replay 固定 Task snapshot、base commit、Context paths 與 SHA-256。這次 Prompt v2 並沒有更好,而是因錯誤行號被 Evidence Gate 阻擋。

Original
2e900482失敗
Prompt
v1
Commit
e78f02f2
Tokens
19231
結果
PATCH_NOT_SAFE
→
Exact Replay
72b6105f失敗
Prompt
v1
Commit
e78f02f2
Tokens
—
結果
WORKER_INTERRUPTED
1
Context Retrieval完成 · 2 次
→
2
Baseline完成 · 3 次
→
3
Plan尚未執行
→
4
Patch尚未執行
→
5
Check尚未執行
→
6
Evidence Gate尚未執行
7
Human Approval尚未進入
06

用 Evaluation 決定技術,不替技術找理由

困難 Retrieval corpus 中,Keyword 與 Hybrid 品質持平,但 Hybrid 明顯更慢。因此目前沒有證據支持全面取代 Keyword。

品質持平,Hybrid 增加延遲目前小型 fixture 中 Keyword 已達到 100% Recall,沒有證據支持全面改用 embedding。

Keyword

Recall@3100%
MRR0.90
延遲<1 ms
vs

Hybrid

Recall@3100%
MRR0.90
延遲1358 ms