DEV Community: Yang Goufang

AI 週報 — 2026-07-03 to 2026-07-10 | 前線模型密度飆升，基礎設施與信任邊界同步重劃

Yang Goufang — Fri, 10 Jul 2026 05:49:17 +0000

本週一句話：微軟在同一週把 GPT-5.6 整合進 Copilot，又悄悄把 OpenAI 與 Anthropic 的依賴往自研模型搬——合約義務與結構性避險並不矛盾，前線模型的供應商地圖正在被企業內部重畫。

前線模型：GPT-5.6 的效率賭注與 Grok 4.5 的企業叩關

OpenAI 發布 GPT-5.6，定位為「隨企圖心擴展的前線智慧」GPT-5.6: Frontier intelligence that scales with your ambition - OpenAI。Sam Altman 接受 CNBC 採訪時宣稱，新模型在 agentic coding 場景的 token 效率提升 54%OpenAI's newest AI model is 54% more token efficient on agentic coding, Altman tells CNBC - CNBC。這個數字值得注意但不該照單全收——廠商自報的效率基準通常挑選最有利的場景，54% 是「宣稱值」而非獨立驗證。

GPT-5.6 同步進入 Microsoft 365 Copilot 成為預設模型GPT-5.6 is now the preferred model in Microsoft 365 Copilot - OpenAI。但同一週，SiliconANGLE 報導微軟正在減少對 OpenAI 與 Anthropic 模型的依賴，轉向自研模型以降低成本Microsoft is reportedly ditching OpenAI's and Anthropic's AI models in favor of its own to cut costs - SiliconANGLE。這兩則消息並不矛盾——Copilot 換上 GPT-5.6 是合約義務與短期最優解，微軟的自研策略是中長期結構性避險。

對技術決策者，這個矛盾直接壓到選型決策：

合約鎖定：今天把 GPT-5.6 嵌進 Copilot 的合約，明天可能因為微軟自研路線而被迫遷移，遷移成本不只在 API 更換，也在提示工程、guardrail、評估管線的重建。
供應鏈去風險化：把單一供應商視為唯一前線模型，會把這個供應商的優先順序綁進自己的 roadmap。微軟的雙軌策略示範了一條「短期用最好的、長期用可控的」路徑。

不要假設今天整合的模型 API 明天還會是同一個供應商。

xAI 的 Grok 4.5 是本週另一個焦點Introducing Grok 4.5 - X.ai。AI Business 評論這是 SpaceXAI 首次認真進入企業市場Grok 4.5 Is SpaceXAI’s First Real Entry Into the Enterprise - AI Business。與 GPT-5.6 相比，Grok 4.5 的劣勢在生態——缺乏像 Microsoft 365 Copilot 那樣的現成分發管道。但 xAI 的優勢是 X 平台的即時資料存取，這在需要時效性的場景（輿情監控、即時摘要）有差異化空間。

維度	GPT-5.6	Grok 4.5
企業分發	Microsoft 365 Copilot 預設模型GPT-5.6 is now the preferred model in Microsoft 365 Copilot - OpenAI	無等效管道，需自行整合
效率宣稱	agentic coding token 效率 +54%（廠商宣稱）OpenAI's newest AI model is 54% more token efficient on agentic coding, Altman tells CNBC - CNBC	未提供可比基準
即時資料	依賴 Bing 等第三方	X 平台原生存取
成熟度	已進入 Copilot 產品線	剛進入企業市場Grok 4.5 Is SpaceXAI’s First Real Entry Into the Enterprise - AI Business

晶片戰線：自研 vs 合縱連橫（延續上週 Nvidia 定價權觀察）

Meta 計畫九月將自研 AI 晶片投入生產，目標是將運算容量翻倍Meta to put AI chip into production in September as it looks to double computing capacity, Reuters reports - CNBC。同週 Barron's 報導 Meta 股價因 Muse Spark 1.1 發布與 Broadcom 晶片合作夥伴關係上漲Meta Stock Rises on Muse Spark 1.1 Release and Broadcom AI Chip Partners - Barron's。Meta 的策略是雙軌：自研 MTIA 降低對 Nvidia 的單點依賴，同時用 Broadcom 合作補充產能。本週新增的具體節點是九月量產時程——這讓「Meta 自研」從路線圖變成可追蹤的交付物。

Nvidia 的應對方式更值得玩味——The Information 報導 Nvidia 開始與晶片競爭對手合作而非單純對抗Nvidia’s New Hedge Against Chip Competitors? Partner with Them - The Information。市場結構壓力解讀：當 Meta、Google、Amazon 都在自研，Nvidia 的護城河從「唯一選擇」變成「最佳選擇」，定價權正在鬆動。

SambaNova（Intel 投資）則走了另一條路——The Register 報告其最新基準測試讓舊款 Nvidia GPU 煥發新生Intel-backed AI chip startup SambaNova breathes new life into aging Nvidia GPUs in latest benchmarks - The Register。對已經持有大量舊 GPU 的企業，軟體層優化能延長投資壽命。但基準測試同樣需要獨立驗證——SambaNova 有商業動機讓結果好看。

Claude Code 的安全風險標記與「思考空間」

中國透過 CNBC 對 Anthropic 的 Claude Code 發出 AI 安全風險警告China warns about AI risks with Anthropic's Claude Code - CNBC。報導本身偏向政策信號而非具體技術漏洞披露，但值得注意：當一個國家級實體點名特定工具的安全風險時，通常代表該工具的使用量已大到引起關注，而非純粹的技術評估。

同週，Axios 報導 Anthropic 表示 Claude 已開闢出「自己的思考空間」Anthropic says Claude has carved out its own space to ponder - Axios。這指的是 Claude 在回答前會進行獨立的內部推演。從工程角度，這意味著更高的延遲但潛在更深的推理品質。替代方案是 OpenAI 的 o 系列或任何 chain-of-thought 模型——差異在 Claude 的「思考」是否真正影響最終輸出品質，目前缺乏獨立對比數據。

Google：法律勝利、訂閱分層與人才流動

Google 在消費者訴訟中勝訴——法院駁回了關於 Gemini 資料追蹤的指控Google defeats consumer lawsuit over Gemini data tracking claims - Reuters。對企業考慮 Gemini 的決策者來說，這降低了短期法律風險，但不改變資料治理的設計責任——你的合規框架不能依賴供應商打贏官司。

9to5Google 詳細列出了 Google AI Plus 與 AI Pro 訂閱各自解鎖的 Gemini 功能What Gemini app upgrades you get with Google AI Plus & AI Pro - 9to5Google。分層策略本身不新鮮，但 Google 的差異化在於將 Gemini 深度綁定 Android 生態——這是 OpenAI 和 Anthropic 都缺乏的作業系統級分發管道。

人才方面，South China Morning Post 報導 Google DeepMind 主管曹良良重返香港Google DeepMind director Cao Liangliang makes a boomerang return to Hong Kong - South China Morning Post。單一人事異動不構成趨勢判斷，但配合中國 AI 監管信號（見上節），值得持續觀察是否形成回流模式。

Meta 的深偽底線測試

BBC 與 NBC News 同日報導：Meta 允許用戶從公開 Instagram 個人檔案照片生成 AI 圖像，且不需要明確同意Outcry as Meta lets users make AI images from public Instagram profile pics - BBC Meta AI now lets people make deepfakes from public Instagram photos without explicit consent - NBC News。深偽技術早已成熟，這不是技術突破，是治理選擇：Meta 選擇將「公開照片」視為默示同意的來源。

對企業的啟示：如果你的員工或品牌在 Instagram 上有公開存在，他們的肖像可能被用於 AI 生成內容。現有防護（浮水印、肖像權聲明）在這個機制下效力有限。替代方案是減少公開照片暴露面，或要求 Meta 提供企業級的肖像保護 API——目前不存在。

機器人「AI 大腦」：仍處於宣稱階段

Fortune 報導由前 Google DeepMind 研究員領導的 Nomagic 實驗室宣稱其機器人「AI 大腦」取得成功Nomagic AI lab led by former Google DeepMind researcher claims success with 'AI brain' for robots - Fortune。目前這是廠商宣稱——沒有獨立驗證、沒有可採購的產品、沒有價格。機器人領域的 demo 與產品化之間的鴻溝比軟體更大，因為涉及物理世界的邊緣案例。列為「值得追蹤」，不是「值得導入」。

AI Weekly — 2026-07-03 to 2026-07-10 | Frontier Models Ship, Infrastructure Shifts

Yang Goufang — Thu, 09 Jul 2026 23:10:34 +0000

Three frontier models landed in the same week — GPT-5.6, Grok 4.5, a Claude "thinking space" — but the structurally louder signal came from the buyers and builders around them: Microsoft wants off the metered API treadmill, Meta is forging its own silicon path, and a national regulator named a specific agentic coding tool as a concern. When the biggest consumers start building their own stack, the pricing layer for everyone else has to adjust.

OpenAI's GPT-5.6: Token Efficiency Is the New Benchmark Arms Race

OpenAI released GPT-5.6 on July 9, positioning it as a frontier model whose headline claim is not raw intelligence but efficiency: Sam Altman told CNBC the model is 54% more token-efficient on agentic coding tasks compared to its predecessorOpenAI's newest AI model is 54% more token efficient on agentic coding, Altman tells CNBC - CNBC. OpenAI's own announcement frames it as "frontier intelligence that scales with your ambition"GPT-5.6: Frontier intelligence that scales with your ambition - OpenAI, and Microsoft has already made GPT-5.6 the preferred model in Microsoft 365 CopilotGPT-5.6 is now the preferred model in Microsoft 365 Copilot - OpenAI.

The efficiency framing matters more than the capability framing. If token consumption per agentic task drops by roughly half, the unit economics of multi-step coding agents move materially. Developer workflows that depend on metered API spend at scale suddenly look different — not incrementally, but categorically.

But "54% more token-efficient" is a vendor claim on an internal benchmark, not an independently reproduced number. OpenAI's announcement does not disclose the methodologyOpenAI's newest AI model is 54% more token efficient on agentic coding, Altman tells CNBC - CNBC. The real test is whether your specific codebase, tool-calling patterns, and context windows see proportional savings.

Status: Announced and available via API. Commercially usable now. The efficiency claim is vendor-asserted and unverified by third parties.

Grok 4.5: xAI's Enterprise Pivot

X.ai announced Grok 4.5 on July 8Introducing Grok 4.5 - X.ai, and the framing this week is explicitly enterprise. AI Business reports this is "SpaceXAI's first real entry into the enterprise"Grok 4.5 Is SpaceXAI’s First Real Entry Into the Enterprise - AI Business, meaning xAI is no longer treating Grok as a consumer/X-platform feature but as a competitor for enterprise API spend.

The enterprise AI market does not need another general-purpose chatbot. It needs reliability, compliance posture, data residency guarantees, and integration depth. Grok's historical advantage — real-time access to X data — is a feature, not an enterprise platform. Whether xAI has built the surrounding infrastructure (SOC 2, enterprise SLAs, audit logs, fine-grained access controls) remains unclear from the announcementIntroducing Grok 4.5 - X.ai Grok 4.5 Is SpaceXAI’s First Real Entry Into the Enterprise - AI Business.

Status: Announced. Enterprise readiness is claimed but not demonstrated. Treat as a consumer model with enterprise aspirations until procurement-grade documentation appears.

Microsoft's In-House Pivot: The Buyer Is Becoming the Builder

SiliconANGLE reports Microsoft is "ditching OpenAI's and Anthropic's AI models in favor of its own to cut costs"Microsoft is reportedly ditching OpenAI's and Anthropic's AI models in favor of its own to cut costs - SiliconANGLE. This is the most strategically significant story of the week, and it is not about model quality.

Microsoft 365 Copilot runs at massive scale. At that scale, the difference between paying per-token to a third party and running your own model on your own infrastructure is a margin question, not a quality one. GPT-5.6 becoming the "preferred" model in CopilotGPT-5.6 is now the preferred model in Microsoft 365 Copilot - OpenAI and Microsoft simultaneously building its own models to replace OpenAI/AnthropicMicrosoft is reportedly ditching OpenAI's and Anthropic's AI models in favor of its own to cut costs - SiliconANGLE are not contradictory — they are sequential. Microsoft is using GPT-5.6 now while its in-house stack matures.

For anyone building on Azure OpenAI, this is a signal to architect for model portability. Vendor lock-in to a specific provider's model API is a risk when the platform owner itself is planning to swap out the underlying model.

Anthropic: Claude Code Draws Regulatory Attention

CNBC reports China has warned about AI risks specifically associated with Anthropic's Claude CodeChina warns about AI risks with Anthropic's Claude Code - CNBC. This is notable because the warning targets a specific agentic coding tool, not a general-purpose model. Regulators are beginning to distinguish between "AI that generates text" and "AI that executes code with system access" — and the latter draws sharper scrutiny.

Separately, Axios reports Anthropic says Claude has "carved out its own space to ponder"Anthropic says Claude has carved out its own space to ponder - Axios, referring to extended reasoning or chain-of-thought behavior. The two Anthropic stories this week are independent: the regulatory story targets agency and system accessChina warns about AI risks with Anthropic's Claude Code - CNBC, while the "pondering" framing addresses capability. The regulatory signal is the one with engineering implications — agentic coding tools that execute commands on developer machines are now on the radar of national-level regulators. If you are deploying Claude Code or similar tools in enterprise environments, expect compliance reviews.

Meta: Custom Silicon Moves to Production

Meta will put its own AI chip into production in September, aiming to double computing capacityMeta to put AI chip into production in September as it looks to double computing capacity, Reuters reports - CNBC. Barron's separately reports Meta stock rose on the Muse Spark 1.1 release and Broadcom AI chip partnershipsMeta Stock Rises on Muse Spark 1.1 Release and Broadcom AI Chip Partners - Barron's.

Meta's silicon strategy is the clearest example of a hyperscaler treating AI inference as infrastructure, not as a service they rent. The cost structure of running recommendation models and LLM inference on owned silicon is fundamentally different from a company paying per-token to OpenAI or Anthropic. The September production dateMeta to put AI chip into production in September as it looks to double computing capacity, Reuters reports - CNBC means Meta is past the prototype stage — this is a deployment timeline.

For the broader market, Meta's move validates the thesis that the largest AI consumers will vertically integrate. SambaNova's benchmark claims about extending the life of aging Nvidia GPUsIntel-backed AI chip startup SambaNova breathes new life into aging Nvidia GPUs in latest benchmarks - The Register and Nvidia's own strategy of partnering with chip competitorsNvidia’s New Hedge Against Chip Competitors? Partner with Them - The Information point in the same direction: the silicon layer is becoming multi-vendor.

Privacy and Consent: Meta's Instagram Feature Backlash

BBC reports Meta now lets users generate AI images from public Instagram profile photosOutcry as Meta lets users make AI images from public Instagram profile pics - BBC, and NBC News frames this as enabling deepfakes "without explicit consent"Meta AI now lets people make deepfakes from public Instagram photos without explicit consent - NBC News. Google separately won a consumer lawsuit over Gemini data trackingGoogle defeats consumer lawsuit over Gemini data tracking claims - Reuters, which is a legal win but not a reputational one.

The engineering lesson: consent and data provenance are becoming first-class system design problems, not legal afterthoughts. If your product can ingest user data and generate derived content, the consent model must be built into the data pipeline, not bolted on after a public backlash.

The Signal

Three things actually matter this week:

Token efficiency is the new competitive axis. GPT-5.6's headline is cost-per-task, not capabilityOpenAI's newest AI model is 54% more token efficient on agentic coding, Altman tells CNBC - CNBC. When models are "good enough," the pricing layer decides deployments.
The largest buyers are building their own stack. MicrosoftMicrosoft is reportedly ditching OpenAI's and Anthropic's AI models in favor of its own to cut costs - SiliconANGLE and MetaMeta to put AI chip into production in September as it looks to double computing capacity, Reuters reports - CNBC are both moving toward self-supplied AI infrastructure. This compresses margins for pure-play model providers.
Agentic tools draw specific regulatory fire. China's warning about Claude CodeChina warns about AI risks with Anthropic's Claude Code - CNBC targets a tool that executes code, not a chatbot. The regulatory perimeter is narrowing around agency, not capability.

Design Your Own Multi-AI Coding Pipeline: A Portable Reference Architecture

Yang Goufang — Thu, 09 Jul 2026 02:03:37 +0000

The point was never "more agents are smarter." It's stopping any single agent from being both the author of correctness and the judge of correctness. This is for people who want to build one on their own stack — a reference architecture you can carry away, not a diary of my machine.

You've probably let a single coding agent take a task from planning all the way through implementation. It works — but you know the risk in your gut: the same agent defines what "correct" means AND decides whether it got there. The green light is its own; the diff is its own review. Fine most of the time — until the once it reports "success" while running in the wrong directory, or a migration gets silently skipped by a guard clause while the tests stay green.

Splitting the work across multiple AIs doesn't buy you "three brains." It buys you breaking that self-endorsement apart. This piece isn't about installing a particular tool; it's a reference architecture you can map onto your own stack — which roles, which contracts, which checkpoints. There's a case box at the end describing how I wired it up, but that's just one instantiation, not the point.

The one core claim: No single agent can both define correctness and judge whether it is itself correct. So every artifact — the plan, the tests, a "finding," that "it worked," that green build — has to be checked independently against a verifiable ground truth (source code, a frozen test, a schema, real DB state), not trusted because it sounded confident.

01 · The invariant: every AI output is a proposal, not a verdict

Nail down the part that's easiest to skip: in this pipeline, everything an agent produces is a proposal, not a conclusion. The plan is a proposal. The tests are a proposal. "There's a bug here" is a proposal. Even a green build is a proposal. What they share: each must be checked against something that isn't an LLM — does the code actually look like that? Does this API really exist? Does this test fail for the reason it's supposed to fail? Does the diff really only touch what it should?

This invariant matters because it even covers the reviewer is also an LLM. Your verifier — whichever model it is — isn't trustworthy because it's cast as "the reviewer." It's trustworthy because what it checks against is verifiable. Take away that verifiable target and the whole thing collapses into "a bunch of LLMs talking each other into it" — which is the truly bottomless state.

02 · The reference architecture: four roles, one rule

Think of the pipeline as a set of responsibilities, not a set of brands. One tool can hold several roles. But one rule can't be broken:

In a single run, a tool cannot both produce a claim and be the final judge of that claim. Author and judge must be different runs (ideally different models / different context).

The shape (→ means "on to the next step"; the checkpoints sit between steps):

Planner → produces a change plan + test plan (which files, boundaries, what won't be tested).
[LOOP ①] Planner ⇄ Plan-verifier → check the plan's referenced types / APIs / schema against existing code; iterate until both sides agree.
Implementer → writes tests + implementation against the frozen plan, makes the tests go green.
[GATE ②] Test-verify + Final-verify → tests are reviewed before they're frozen into a contract; after impl, run the tests, review the diff, check side effects — do not trust the implementer's self-report.
Discovery (discovery loop) → audits already-running code, proposes findings — also checked against source before they count.

Three checkpoints: ① the plan loop · ② the implementation gate (test review + final verification) · the discovery loop the auditor runs. Each is the same principle — check the proposal against a verifiable target — landing in a different place.

Role → responsibility → forbidden behavior

This table is the most portable thing in the piece. Map your tools (Cursor, Aider, some CLI, some agent framework) onto it by responsibility, not by brand:

Role	Responsibility	Checked against	Forbidden
Planner	Produce a concrete change plan + test plan: name files, APIs, assumptions, boundaries, and what won't be tested	— (it's a proposal source)	Writing production code
Plan verifier	Before any work, check the plan's referenced types / modules / schema / command paths against existing code — confirm what it references is real	Existing source, schema	Rubber-stamping
Implementer	Write tests and implementation against the frozen plan; optimized for execution, not judgment	The frozen plan	Editing frozen tests after impl starts
Test verifier	Before tests become contract, check they express the plan and fail for diagnostic reasons	Plan, test semantics	Letting an uninformative RED through
Final verifier	Run tests, review the diff, check DB / schema / runtime side effects	Test results, diff, real state	Trusting the implementer's "success" report
Discovery agent	Audit already-running code, propose findings — its output is not truth, it enters the discovery loop	Source, real behavior	Treating a "finding" as a verdict
Adapter / wrapper	Stabilize tool invocation: absorb CLI churn, model-specific flags, sandbox, working dir, context packaging, retries, output normalization	— (infrastructure)	Pretending it guarantees correctness

03 · The three checkpoints: where the invariant lands

"Every artifact gets checked against a verifiable target" lands in three concrete places. If you've done rigorous TDD, the first two already exist in embryo; the third is the one people miss:

① The plan loop — check against existing code, not the not-yet-written implementation. A commonly-confused point: for a new feature, the plan comes first, the code second. At planning time there's no implementation to compare against; all you can check is whether the current state it references exists — is this type there? Is this module's interface really shaped like that? (Only when fixing existing code is there an old target to compare against.) And the plan isn't "one AI hands off, another reviews once" — it's two AIs iterating until both agree. The planner can be the author, but whether it's right has to be verified by another role, both nodding, before it counts.

② The implementation gate — freeze the tests as contract, make the implementation chase them. Tests get reviewed before they become contract (do they reflect the plan? do they fail diagnostically?) — and the test plan belongs in loop ① too: the planner and a second role capable of independently challenging it must trace every case and expected result back to verifiable ground truth, and only after both agree is it frozen as the shared contract for implementation and acceptance (check facts first, then agree — the two-agent consensus is not itself a source of truth). Once frozen, the implementer has exactly one job: make the frozen tests pass — change only the implementation, never the tests. Final verification runs the tests and reviews the diff — but does not trust the implementer saying "it worked." This is a gate, not a loop: the three checkpoints are not equal in weight — final acceptance is an independent backstop that holds the last veto; fail it and you go back.

"Frozen" does not mean blind obedience. If dependency checks reveal that a task's premise would break an existing gate, the implementer should STOP, attach source evidence, and escalate the decision — it must neither rewrite the frozen contract on its own nor force the change just to report "done." One archive task in this run stopped for exactly that reason: the files marked for movement were still used by a shared binary locator and by a parity path that loaded the old entrypoint through importlib. The implementer surfaced the dependency and halted, instead of moving them and breaking both gates.

③ The discovery loop — this pipeline also finds that already-running code is wrong. A lot of people only see this as a "get new code right" tool. But the same invariant holds for existing code: point an independent, adversarial role at code that looks like it works and ask "is it actually right?" — purely diagnostic. What it digs up isn't a freshly-written bug; it's a bug that's been running all along (see the case at the end). Its "findings" are proposals too — checked against source before they count.

04 · Mapping it onto your stack

You don't need my tools. You need to answer a few design questions:

Who's the planner? Pick a model/tool good at reading your codebase and producing a structured plan. It only outputs plans, never production code.
Who's the plan verifier? A different role that can run tools, read source, and check references (usually your main agentic environment). It iterates with the planner until both agree.
What's your contract? Frozen tests, first choice. Without tests that can serve as contract, the foundation is shaky.
Who's the final verifier? A role that can run tests, review diffs, and check real side effects — and that is not the same run that wrote the implementation.
Who holds the invocation layer? See the next section — this is usually what decides "you can run it" vs "someone else can run it too."

Take the role table above, fill each row with your own tools, and that's your "responsibility assignment." The one line you can't break: a single run cannot be both the author of a claim and its final judge.

05 · Split out the "tool invocation" layer — it's an architecture decision, not chores

This is the part most easily dismissed as plumbing, and it's actually where it lives or dies. The CLIs / agent tools you pick are moving targets that keep changing: flags change, model params change, sandbox modes change. Memorize them by hand and have your orchestrator invoke them "from memory," and you'll hit things like "a parameter drift burns a whole turn before reasoning even starts, zero files written" — which has nothing to do with how smart the model is. It's purely an invocation-layer problem.

The fix isn't "the orchestrator learns a few more flags." It's wrapping invocation in an adapter layer that pins each tool's correct current usage — flags, run-mode, working dir, context packaging, retry rules, output normalization. Your upper logic calls the adapter, never the CLI directly. This layer guarantees no correctness (don't treat it as magic); it only guarantees the invocation is stable — and that's often exactly the step that takes a pipeline from "I can run it" to "someone else can run it by following along."

06 · When to run the full ceremony, and when not

Honestly: for a small change, the full six steps are pure overhead. Ceremony should scale with change size. A guard clause, a one-line hint — the round-trips of the split cost more than the risk they catch. Just do it yourself, faster.

What earns the full run: high-risk, cross-cutting, persistent, schema-touching, or hard-to-revert work. The test isn't "big or small," it's "cost of being wrong" vs "cost of the round-trips."

07 · What architects will push back on (answered up front)

"Isn't this just trading speed for correctness?" No. The extra is those few round-trips of tests and cross-role review — but that cost is owed by any code you intend to maintain; the pipeline just makes you pay it now instead of on credit. And it isn't a speed trade at all: precisely because the implementer writes less correctly than your strongest model, you fence it harder with tests — the shakier the implementer, the tighter the tests around it. How fast it all is, isn't what's on the table here.

"Why not just use a stronger model?" A stronger model lowers the error rate but doesn't remove the self-verification risk — it's still both author and judge. This pipeline solves the latter, not the former.

"LLMs are unpredictable — how is this reliable?" The reliable part was never the LLM; it's the contract: frozen tests, source checks, diff review, schema checks, reproducible commands. The LLM proposes; the contract judges.

"Isn't this over-engineering?" If you run the full ceremony on every change, yes. So take the rule in §06 seriously — small changes skip it.

08 · Failure modes you'll actually hit (put them on the table)

This isn't a flex about "never failing" — the opposite. Its value is that it catches these:

The implementer lies about success: reports "success" while running in the wrong dir, having written nothing. Trust the report and you commit an empty change. → Whoever owns final acceptance must run the right tests in the correct environment and review the entire code diff line by line, tracing every change back to the frozen tests and verifiable ground truth. A green run is evidence of verification, not a review — passing the tests is verify; reading every line is review.
Tests all green, but a change was silently skipped: a migration's guard clause misfires, a whole expansion is silently dropped, local tests stay green. → Check against the real schema / DB state, not just the green light.
Hermetic tests are green and the diff is correct, but the real backend still refuses: in one cross-repo migration a sentinel date was fixed at a far-future value; the hermetic stub harness passed and the diff faithfully implemented the plan, but the real backend enforced a constraint that the date could not exceed today + 365 days, so it failed before the write and the date was changed to a relative today + N. → A stub can only check constraints it models; here the gap showed up only in a minimal smoke run against the real backend. Green hermetic tests plus a correct diff are not evidence that an unmodeled integration contract holds.
The auditor's "finding" is a false positive: it confidently reports a "high-severity issue" — because it only read half the context and missed that the guard actually lives elsewhere. → Findings get checked against source; a subagent's finding is scoped to exactly what it read. — Getting the architecture right does not guarantee that claims about concrete codebase facts are correct; each claim must still be checked against the relevant source code, configuration, or actual data. And a finding can be valid while its location is wrong: verify both the problem and the edit site it points at against the source — otherwise you fix the right thing in the wrong place.
Tests passed, but polluted shared state: the implementation is real, the logic is correct, the suite is genuinely green — but the data that setup created was never cleared by teardown, so every run leaves a real side effect in the shared, live environment. The green light shows none of it; only reading the teardown and checking the shared state afterward surfaces it. → Test results must also be checked against post-run state: everything setup created must be removed — a green suite is not evidence of cleanup.
The invocation layer breaks before reasoning: a param drift burns the whole turn, zero files written. → That's the adapter layer's problem, not the method's.

Pre-adoption checklist

[ ] Do we have specs that can serve as contract? (Freezable tests / explicit assertions)
[ ] Can the tests fail diagnostically? (Each red has its own reason, not a blanket NotImplemented)
[ ] Can the verifier actually read source, diffs, and real side effects? (Not just the agent's report)
[ ] Are author and judge different runs? (One run can't both make a claim and judge it)
[ ] Is tool invocation wrapped? (When a CLI shifts, you don't relearn flags)
[ ] Do we have an explicit "small change → skip the ceremony" rule?

Case · How I wired it (just one instantiation)

Codex plans ⇄ Claude Code challenges and validates the plan, and together they freeze the test plan; Grok 4.5 implements; Claude Code provides the final acceptance backstop — independently running the tests and reviewing the diff line by line.

Planner = Codex (task-by-task, test-first plans); plan verifier + final verifier = Claude Code (check the plan against existing code, run tests, review diffs); implementer = Grok 4.5 (writes test + impl to the frozen plan). Neither CLI is driven raw — they're moving targets I keep invoking wrong, still do — so I call each through its Claude Code plugin (the adapter layer), letting the plugin pin the "correct current usage." That's an invocation-layer concern, unrelated to the method.

Sample boundary: across a few repos (a Rust + Turso CLI, a Rust + Python tool, a Zig project), on the order of a dozen observations — not a benchmark, not a statistical result. Not many runs per repo.

Real bugs it found (all in already-running code): a map silently rendering blank (activities weren't linked to coordinates, and nothing warned); a command writing zero rows when called without fields yet printing "✅ updated"; an import printing "✅ saved" when every row was skipped. None were freshly-written mistakes — the audit + verification are what forced them out.

If you take away one line: multi-AI isn't for being smarter — it's so the one who defines correct and the one who judges correct aren't the same. Everything else — how you split the roles, where the contract lives, who holds invocation — is just how that line lands. Copy the role table and the checklist above, swap in your own tools, and you've got your own.

This is a first-person working note reshaped into a portable reference architecture. Every failure mode is from real runs; the sample is small and I don't extrapolate. Every claim is designed to be falsifiable against your own codebase in minutes. Go build one — then tell me where it doesn't hold.

設計你自己的 Multi-AI Coding Pipeline：一份可搬走的參考架構

Yang Goufang — Thu, 09 Jul 2026 02:03:34 +0000

重點從來不是「多幾個 AI 比較聰明」，而是不讓任何一個 AI 同時當「正確的作者」和「正確的裁判」。這篇給想在自己的技術棧上搭一條的人——一份可搬走的參考架構，不是我機器上的日記。

你大概已經試過讓單一 coding agent 從規畫到實作一路包辦。它能動，但你心裡清楚那個風險：同一個 agent 既定義什麼叫「對」，又自己判定自己有沒有做對。 綠燈是它自己說的，diff 是它自己審的。多數時候沒事——直到某次它跑在錯的目錄卻回報「成功」，或一段 migration 被守衛邏輯靜默跳過，而測試照樣全綠。

把工作拆給多個 AI，真正買到的不是「三顆腦袋」，是把這種自我背書拆開。這篇不談某個特定工具怎麼裝，談的是一套你可以映射到自己技術棧的參考架構：哪些角色、哪些契約、哪些關卡。文末有個 case 說明我自己怎麼實作的，但那只是「一種」實作，不是重點。

唯一的核心命題： 沒有任何一個 agent 能同時定義正確、又判定自己是否正確。所以每一份產物——計畫、測試、發現、那句「成功了」、那盞綠燈——都要被獨立地對回一個可查證的 ground truth（原始碼、凍結的測試、schema、真實的 DB 狀態），而不是因為它「講得很篤定」就採信。

01 · 不變量：AI 的每一句話都是「提議」，不是「定論」

先把最容易被跳過的一點釘死：在這條管線裡，agent 產出的東西一律是提議，不是結論。 計畫是提議、測試是提議、「這裡有個 bug」的發現是提議、連綠色的 build 都是提議。它們的共同點是——都必須拿去對一個「不是 LLM」的東西核實：程式碼真的長那樣嗎？這個 API 真的存在嗎？這個測試真的因為它該失敗的原因而失敗嗎？diff 真的只動了該動的地方嗎？

這條不變量之所以重要，是因為它連「審查者本身也是 LLM」都涵蓋了。你的驗證者（不管是哪個模型）並不因為它是「審查角色」就可信；它可信，是因為它比對的對象是可查證的。拿掉那個可查證的對象，整套就退回成「一群 LLM 互相說服」——那才是真正沒有底。

02 · 參考架構：四種角色，一條規則

把管線想成一組責任，不是一組品牌。同一個工具可以兼好幾個角色；但有一條規則不能破：

同一次 run，不能既產出一個聲稱、又是那個聲稱的最終裁判。 作者與裁判必須是不同的 run（最好是不同的模型 / 不同的 context）。

管線的形狀（→ 表示往下一步，關卡就在步驟之間）：

計畫者 → 產出變更計畫 + 測試計畫（要改哪些檔、邊界、什麼不測）。
【迴圈 ①】計畫者 ⇄ 計畫驗證者 → 把計畫引用的型別／API／schema 對回「現有」程式碼，來回到兩邊都同意才定案。
實作者 → 依「凍結的」計畫寫測試 + 實作，讓測試轉綠。
【關卡 ②】測試驗證 + 最終驗收 → 測試先審過才凍結成契約；實作後跑測試、審 diff、查副作用——不採信實作者的自述。
稽核者（發現迴圈） → 對「已經在跑的程式」提出發現，一樣要對回原始碼才算數。

三個關卡：① 計畫迴圈 · ② 實作閘（含測試審查與最終驗收）· 稽核者走的發現迴圈。每一個都是「把提議對回可查證對象」的同一條原則落在不同位置。

角色 → 責任 → 禁止事項

這張表是全篇最該搬走的東西。把你手上的工具（Cursor、Aider、某個 CLI、某個 agent framework）按責任對號入座，不要按品牌：

角色	責任	對回什麼	禁止
計畫者	產出具體變更計畫＋測試計畫：點名檔案、API、假設、邊界、以及「不測什麼」	—（它是提議源）	寫正式程式碼
計畫驗證者	在動工前，把計畫引用的型別／模組／schema／指令路徑對回現有程式碼——確認它引用的東西真的存在	現有原始碼、schema	蓋章放行
實作者	依凍結的計畫寫測試與實作，追求「執行」而非「判斷」	凍結的計畫	動工後改凍結的測試
測試驗證者	在測試變成契約前，審它是否忠實反映計畫、是否因各自獨立的原因失敗（可診斷的紅燈）	計畫、測試語意	讓無資訊的 RED 過關
最終驗收者	跑測試、審 diff、查 DB／schema／runtime 副作用	測試結果、diff、真實狀態	採信實作者的「成功」自述
稽核者	審「已在跑的程式」、提出發現——它的輸出不是真理，要進發現迴圈核實	原始碼、真實行為	把「發現」當定論
適配層 / wrapper	穩住工具調用：吸收 CLI 變動、模型專屬旗標、sandbox、工作目錄、context 打包、重試、輸出正規化	—（基礎設施）	假裝它能保證正確性

03 · 三個關卡：不變量落在哪三個地方

「每份產物都要對回可查證對象」這句話，具體落在三處。前兩處你若做過嚴謹 TDD 其實已經有了雛形，第三處常被忽略：

① 計畫迴圈——對回「現有的碼」，不是「還沒寫的實作」。 這裡有個常被搞混的點：新功能是先有計畫、後有碼。 計畫階段還沒有實作可比，能比的只有它引用的現況存不存在——這個型別在嗎？這個 module 的介面是這樣嗎？（只有在「修正」既有程式時，才有一份舊的目標碼可對。）而且計畫不是「一個 AI 交出、另一個審一次」，是兩個 AI 來回到彼此都同意才定案。計畫者可以是作者，但它對不對，要另一個角色核實過、兩邊都點頭才算數。

② 實作閘——測試先凍結成契約，實作去追它。 測試在變成契約前要先被審（是否反映計畫、是否可診斷地失敗）——而且測試計畫也屬於迴圈①：出計畫的角色跟另一個有能力獨立挑戰它的角色，要把每個案例與預期結果各自對回可查證的 ground truth，兩邊同意才凍結成實作與驗收的共同契約（先對回事實、再彼此同意——雙方共識本身不是真理來源）。凍結後，實作者的任務只有一句：讓已凍結的測試通過，只改實作、不准動測試。 最終驗收跑測試、審 diff——但不採信實作者自己說「成功了」。這是閘，不是迴圈：三關職責並不對稱，最終驗收是獨立兜底、握最後否決權，驗不過就退回重做。

「凍結」不等於盲從。若實作者在依賴核對時發現任務前提會破壞既有 gate，它應該 STOP、附上原始碼證據，把決策升回決策者；不能自行改掉凍結契約，也不能硬做只為交出「完成」。我這輪就有一次 archive 任務因此停下：待搬的檔案仍被一個共用 binary locator、以及一條以 importlib 載入舊入口的 parity 路徑使用——實作者查出依賴後停手回報，而不是照搬把兩個 gate 弄壞。

③ 發現迴圈——這條管線也是「找出已在跑的程式其實是錯的」。 很多人只把這套當「把新程式寫對」的工具。但同一條不變量對現存程式一樣成立：讓一個獨立、對抗式的角色去審「看起來會動」的程式，問一句「它真的對嗎？」——這是純診斷用途。它挖出來的不是新寫的 bug，是早就在跑的 bug（見文末 case）。它的「發現」一樣是提議，要對回原始碼才算數。

04 · 把它映射到你的技術棧

你不需要跟我用一樣的工具。你要做的是回答幾個設計問題：

誰當計畫者？ 選一個擅長「讀你的 codebase、產結構化計畫」的模型／工具。它只出計畫，不出正式碼。
誰當計畫驗證者？ 另一個能跑工具、讀原始碼、比對引用的角色（通常是你主力的 agentic 環境）。跟計畫者來回到兩邊同意。
你的契約是什麼？ 凍結的測試是首選。沒有可當契約的測試，這套的地基就不穩。
誰是最終驗收者？ 能跑測試、審 diff、查真實副作用的角色——而且它不是寫實作的那一個 run。
誰握著調用層？ 見下一節——這通常是決定「你跑得起來 vs 別人也跑得起來」的關鍵。

把上面那張角色表照抄、每一列填上你自己的工具，就是你的「責任配置」。唯一不能破的一條：同一次 run 不能既是某聲稱的作者，又是它的最終裁判。

05 · 把「工具調用」這一層獨立出來——這是架構決策，不是雜事

這點最容易被當成瑣事，其實是成敗關鍵。你選的那些 CLI／agent 工具是會一直變的移動目標：旗標改、模型參數改、sandbox 模式改。手動去記這些、每次靠 orchestrator「憑印象」呼叫，就會踩到「參數漂移在推理開始前就讓整輪空轉、零檔案寫入」這種坑——而這跟模型聰不聰明一點關係都沒有，是純調用層的事。

解法不是「orchestrator 再多學一點旗標」，是把調用封進一個 adapter 層：它固定住每個工具的「當前正確用法」——旗標、run-mode、工作目錄、context 打包、重試規則、輸出正規化。你的上層邏輯呼叫 adapter、不直接碰 CLI。這一層不保證任何正確性（別把它當魔法），它只保證調用是穩的——而這往往正是一條 pipeline 從「我跑得起來」變成「別人照著也跑得起來」的那一步。

06 · 什麼時候該跑全套，什麼時候別

誠實講：對小改動，全套六步是純 overhead。ceremony 要隨改動大小縮放。 一道防呆、一行提示這種，分工的來回本身就大於它擋下的風險，直接動手更快。

值得跑全套的，是風險高、跨切面、會留下來、動到 schema、或難以回退的工作。判準不是「大或小」，是「錯了的代價」對上「來回的成本」。

07 · 架構師會質疑的地方（先講在前面）

「這不就是拿速度換正確？」 不是。多出來的是測試與跨角色審查那幾段來回——但那份成本，本來就是任何要長期維護的程式都該付的；管線只是逼你當場付清、而不是欠著。而且它不是速度取捨：正因為施工的模型寫得沒有你最強的模型準，你才更要用測試把它框死；越不穩的實作者，圍它的測試要越緊。整體快不快，不是這裡在談的事。

「直接用一個更強的模型不就好了？」 更強的模型降低錯誤率，但消不掉自我驗證的風險——它還是同時當作者和裁判。這條管線解的是後者，不是前者。

「LLM 不是不可預測嗎，這樣怎麼可靠？」 可靠的部分從來不是 LLM，是契約：凍結的測試、原始碼核對、diff 審查、schema 檢查、可重現的指令。LLM 是提議源，契約是裁判。

「這是不是過度工程？」 如果你對所有改動都跑全套，是。所以第 06 節那條規則要當真——小改動就別上這套。

08 · 實務上會踩到的失敗（把它擺在檯面上）

這套不是拿來炫「不會出錯」，正好相反——它的價值就在於把這些失敗接住：

施工者謊報成功： 回報「成功」，實際跑在錯的目錄、一行沒寫。只看回報就會提交一個沒改的 commit。→ 最終驗收者必須在正確環境親自跑對測試，並逐行審完本次 code diff，把每個改動對回凍結測試與可查證的 ground truth。綠燈只是 verify 的證據，不等於 review——跑過測試是 verify，讀完每一行才是 review。
測試全綠、但改動被靜默跳過： 一段 migration 的守衛邏輯誤判、整段擴充被無聲略過，本地測試照樣全綠。→ 要對回真實的 schema／DB 狀態，不只看綠燈。
Hermetic 測試全綠、diff 也對，真實後端仍拒絕： 一次跨 repo 的遷移把一個哨兵日期定成固定的遠未來值；hermetic 的 stub harness 全綠，diff 也忠實實作了計畫，但真實後端有一條「該日期不得超過今天 +365 天」的約束，一跑就在寫入前失敗，最後改成相對的 today+N。→ Stub 只能驗它有建模的約束；這一例要到對真實後端跑一次最小 smoke run 才看得見缺口。Hermetic 綠燈加正確 diff，不是「未被建模的整合契約也成立」的證據。
稽核者的「發現」是誤報： 它很有信心地報了「高嚴重度問題」，結果是它只讀了半個上下文、沒讀到防呆其實在別的地方。→ 發現要對回原始碼；subagent 的發現，範圍就等於它讀過的東西。——架構判斷正確，不保證對 codebase 具體事實的主張也正確；每個 claim 仍須對回相關的源碼、設定或實際資料。而且發現可能成立、定位卻錯誤：問題與它指的修改位置，都要各自對回原始碼——不然你會改對的東西、卻改錯地方。
測試全綠、卻污染了共享狀態： 施工是真的、程式邏輯對、測試也真的全綠——但那批測試在 setup 建的資料沒被 teardown 清乾淨，每跑一次就往共享的正式環境留下真實副作用。綠燈完全看不出來，只有讀 teardown、事後查共享狀態才發現。→ 測試「結果」也要對回事後狀態：setup 建的東西是否全部清除，不能拿綠燈當 cleanup 的證據。
調用層在推理前就壞： 參數漂移讓整輪空轉、零檔案寫入。→ 這是 adapter 層的事，不是方法的事。

採用前的自檢清單

[ ] 我們有「能當契約」的規格嗎？（可凍結的測試 / 明確斷言）
[ ] 測試能「可診斷地」失敗嗎？（每個紅燈有各自的原因，不是一律 NotImplemented）
[ ] 驗收角色能真的讀到原始碼、diff、真實副作用嗎？（不是只讀 agent 的回報）
[ ] 作者與裁判是不同的 run 嗎？（同一次 run 不能既產出聲稱又當它的裁判）
[ ] 工具調用有被 wrapper 包住嗎？（CLI 一變，你不用重學旗標）
[ ] 我們有一條「小改動就別跑全套」的明確規則嗎？

Case · 我自己的實作（只是一種實作）

Codex 出計畫 ⇄ Claude Code 核實，兩者共同凍結 test plan；Grok 4.5 施工；Claude Code 最終驗收兜底——獨立跑測試＋逐行審 diff。

計畫者＝Codex（出逐任務、測試優先的計畫）；計畫驗證＋最終驗收＝Claude Code（把計畫對回現有碼、跑測試、審 diff）；實作者＝Grok 4.5（依凍結計畫寫 test＋impl）。兩個 CLI 都不裸打——它們是會一直變的移動目標，我裸呼叫常常出錯，現在也還是——所以透過各自的 Claude Code plugin（adapter 層）調用，讓 plugin 固定住「當前正確用法」。這是調用層的事，跟方法無關。

樣本邊界：跨幾個 repo（一個 Rust + Turso 的 CLI、一個 Rust + Python 的工具、一個 Zig 專案），量級 n≈十幾的觀察，不是 benchmark、不是統計結論。每個 repo 次數都不多。

它挖到的真 bug（都在已經在跑的程式裡）：地圖靜默空白（活動沒連座標卻沒人示警）、一個指令不帶欄位時寫入零列卻照印「✅ 已更新」、一個匯入在全部被跳過時卻印「✅ 已儲存」。這些不是新寫的錯，是稽核＋驗收才逼出來的。

如果只帶走一句：多 AI 不是為了更聰明，是為了讓「定義正確的人」和「判定正確的人」不是同一個。 其餘的——角色怎麼分、契約放哪、調用誰來握——都是這句話落地的方式。把上面那張角色表和自檢清單抄走，換成你自己的工具，你就有了自己的一條。

這篇是把一篇第一人稱工作筆記整理成可搬走的參考架構。所有失敗場景均為實測，樣本小、不外推；每個論斷都設計成能被你在自己的 codebase 上幾分鐘內驗證或反駁。歡迎照著搭一條、然後告訴我哪裡不成立。

AI Weekly — 2026-06-26 to 2026-07-03 | Curated Surfaces, Sovereign Bets

Yang Goufang — Fri, 03 Jul 2026 02:17:55 +0000

Three numbers rearranged the AI stack this week — a $2.5B Microsoft implementation unit, a $576B Korean drive anchored by Samsung and SK Hynix, and an OpenAI stake offered to Washington — while Claude Science and Gemini Spark shipped as packaged surfaces aimed at owning workflow rather than winning the model leaderboard.

Packaged AI surfaces

Anthropic shipped Claude Science on June 30Claude Science, an AI workbench for scientists, is now available - Anthropic, and STAT framed the same launch as a direct pitch at researchers and pharmaceutical workflows rather than the broader "AI assistant" marketAnthropic releases Claude Science, a product aimed at researchers, the pharma industry - STAT. Both treatments agree on the operational shape: a workbench-style product, not a model release. The distinction matters because most enterprise AI rollouts fail at the integration seam, not the inference call — and a pre-wired scientific toolbench shaves out the part where analysts normally hand-roll their own RAG pipeline. Until pricing tiers and data-residency terms are public, treat this as announced-and-accessible, not yet a replacement for in-house stacks.Claude Science, an AI workbench for scientists, is now available - Anthropic Anthropic releases Claude Science, a product aimed at researchers, the pharma industry - STAT

Google pushed Gemini down two more end-user surfaces the same week. Gemini Spark landed a native macOS client on July 1 via the Gemini appGemini Spark updates: macOS launch, connected apps and more - blog.google Gemini Spark Comes To Google's Gemini App For macOS - Engadget, and Gemini's new Google Play Store integration lets users chat to discover Android apps and gamesGemini’s new Google Play Store integration lets you chat to find Android apps, games - 9to5Google. Neither is a model release; both move the question from "what can Gemini do" to "where does Gemini live." For dev teams this changes the integration map: a chat-native Play Store means a new inbound channel for app discovery and likely a new outbound surface for Play Console metadata. Engineers building anything that touches app-distribution funnels should look at the conversational retrieval behavior before assuming a static search-rank world.Gemini’s new Google Play Store integration lets you chat to find Android apps, games - 9to5Google Gemini Spark updates: macOS launch, connected apps and more - blog.google Gemini Spark Comes To Google's Gemini App For macOS - Engadget

The general-purpose Gemini surface itself got a usability pass in PCMag's "15 features you'll actually use"Google's Gemini AI Can Do a Lot, But Here Are 15 Features You'll Actually Use - PCMag, a useful sanity check against capability-marketing inflation. Read it as a reading list, not a benchmark — the real signal is which Gemini behaviors survive user friction in 2026 and which still feel like demos.

The compute and capital stack rearranges

Microsoft committed $2.5B and roughly 6,000 employees to a new AI implementation unitMicrosoft commits $2.5 billion and 6,000 employees to new AI implementation unit - CNBC, and inc.com read the move as a direct counter to Amazon's announcement from two days earlierJust 2 Days After Amazon's AI Announcement, Microsoft Counters With Its Own $2.5 Billion Unit - inc.com. CNBC's piece notes the unit is implementation, not researchMicrosoft commits $2.5 billion and 6,000 employees to new AI implementation unit - CNBC. Microsoft's own Frontier framing the same week as "AI engineering that amplifies and protects your intelligence"Microsoft Frontier Company: AI engineering that amplifies and protects your intelligence - The Official Microsoft Blog reads as the marketing wing of that same bet — implementation headcount is what Microsoft is buying.

Etched, the Nvidia competitor built around transformer-specific silicon, hit a $5B valuation and $1B in committed salesNvidia competitor Etched hits $5B valuation, $1B in sales for AI chip - TechCrunch. The standard against which this has to be read is Nvidia's reported demand strengthNvidia Stock Rises Amid Signs of Strong AI Chip Demand - Barron's, not general AI capex. A $1B sales book on a $5B valuation is a real number, not a press-release figure — but for an enterprise buyer it is forward contract reliability and supply allocation, not silicon you can benchmark against H100/Blackwell fleets today. Caveat with vendor claim.Nvidia Stock Rises Amid Signs of Strong AI Chip Demand - Barron's Nvidia competitor Etched hits $5B valuation, $1B in sales for AI chip - TechCrunch

Sovereign money joined the pile. South Korea announced a multi-hundred-billion-dollar AI and chip drive, tapping Samsung and SK Hynix as anchorsKorea taps Samsung, SK Hynix in $576 billion AI-chip drive to cement global leadership - Yahoo Finance, with Crypto Briefing citing a higher end of up to $648BSouth Korea plans massive AI and chip investment drive worth up to $648 billion - Crypto Briefing. Whether this lands as actual fab capacity or as coordinated industrial policy depends on which line item survives the next budget cycle — the $576B and $648B figures are likely top-of-range announcements.Korea taps Samsung, SK Hynix in $576 billion AI-chip drive to cement global leadership - Yahoo Finance South Korea plans massive AI and chip investment drive worth up to $648 billion - Crypto Briefing

Geopolitics leaked into engineering decisions more explicitly this week. CNBC reported OpenAI proposed a 5% stake to the Trump administration to ease regulatory pressureOpenAI proposes 5% stake to Trump administration to ease Washington pressure: Report - CNBC, with CNN corroborating from FT reportingOpenAI in talks to give Trump administration a 5% stake in the company, FT reports - CNN. For buyers of OpenAI APIs this is not a curiosity — procurement, security review, and enterprise timelines can be sensitive to political alignment. The right word is "announced": deal structure, terms, and probability are all open.OpenAI proposes 5% stake to Trump administration to ease Washington pressure: Report - CNBC OpenAI in talks to give Trump administration a 5% stake in the company, FT reports - CNN

Carrying context forward

Encyclopedia Britannica's history-of-DeepMind primerGoogle DeepMind | History, Innovations, & Controversies - Encyclopedia Britannica and the Guardian's interview with the philosopher embedded inside Google DeepMind‘There’s this deep mystery of what, actually, is this thing?’: the philosopher inside Google DeepMind AI - The Guardian both surfaced this week; the Guardian piece is the more useful of the two because it touches the "what is this thing internally" question that keeps recurring in capability reviews — and is one reason real-world reliability numbers matter more than benchmark gains.

Two macro narratives from the prior month frame why this week mattered. CNBC documented the shift from "tokenmaxxing" to efficiencyOpenAI and Anthropic face new AI reality as users shift from 'tokenmaxxing' to efficiency - CNBC, and TechCrunch's read on the OpenAI-vs-Anthropic framingIt’s not about Anthropic vs. OpenAI anymore - TechCrunch is no longer the most useful lens — neither claim needs re-running here, but both explain why a $2.5B implementation unitMicrosoft commits $2.5 billion and 6,000 employees to new AI implementation unit - CNBC and Claude ScienceClaude Science, an AI workbench for scientists, is now available - Anthropic Anthropic releases Claude Science, a product aimed at researchers, the pharma industry - STAT are aimed at workflow ownership instead of model leaderboard rank.

Engineering takeaways

Three decisions worth making this week:

Signal	Decision it pushes
Claude Science is a workbench, not an APIClaude Science, an AI workbench for scientists, is now available - Anthropic Anthropic releases Claude Science, a product aimed at researchers, the pharma industry - STAT	Evaluate against in-house pipelines before assuming win on integration cost
Gemini Spark on macOS + Play Store chatGemini’s new Google Play Store integration lets you chat to find Android apps, games - 9to5Google Gemini Spark updates: macOS launch, connected apps and more - blog.google Gemini Spark Comes To Google's Gemini App For macOS - Engadget	Watch conversational discovery as a new channel, don't patch search-rank assumptions
Microsoft $2.5B / 6,000 in implementationMicrosoft commits $2.5 billion and 6,000 employees to new AI implementation unit - CNBC Just 2 Days After Amazon's AI Announcement, Microsoft Counters With Its Own $2.5 Billion Unit - inc.com	The bottleneck is integration headcount, not model choice — budget for it

"Announced" vs "commercially usable" is the right filter this week. Claude Science is announced and accessible, but enterprise contract terms decide whether it replaces your RAG pipelineClaude Science, an AI workbench for scientists, is now available - Anthropic Anthropic releases Claude Science, a product aimed at researchers, the pharma industry - STAT. The Microsoft $2.5B unit is committed headcount, not a model delta, so its arrival should change how you staff integration projects rather than which provider you pickMicrosoft commits $2.5 billion and 6,000 employees to new AI implementation unit - CNBC Just 2 Days After Amazon's AI Announcement, Microsoft Counters With Its Own $2.5 Billion Unit - inc.com. Etched's $1B sales is the kind of forward commitment that warrants a notebook entry, not a procurement decisionNvidia competitor Etched hits $5B valuation, $1B in sales for AI chip - TechCrunch. And the OpenAI-government stakeOpenAI proposes 5% stake to Trump administration to ease Washington pressure: Report - CNBC OpenAI in talks to give Trump administration a 5% stake in the company, FT reports - CNN belongs on a political-risk slide, not a technical one — but it belongs on one.

Tool, not shrine. Surface, not scoreboard.

AI 週報 — 2026-06-26 to 2026-07-03 | 從 token 競量到工作流競深

Yang Goufang — Fri, 03 Jul 2026 02:15:54 +0000

本週一句話摘要：當模型層的差距縮到誤差範圍內，真正的競爭轉到工作流、供應鏈、與監管曝險——Claude Science 與 OpenAI 政府股權是這週最清楚的兩條訊號線。

垂直工具壓進工作流

Anthropic 推出 Claude Science，把文獻搜尋、引用核對、實驗設計的循環收進同一介面 Claude Science, an AI workbench for scientists, is now available - Anthropic Anthropic releases Claude Science, a product aimed at researchers, the pharma industry - STAT。取代既有解法（檢索工具＋Notion＋Zotero 組合）的關鍵是引用準確率與權限隔離——目前廠商宣稱已與數家藥廠導入 Anthropic releases Claude Science, a product aimed at researchers, the pharma industry - STAT，但「發布」「可商用」「可被稽核」三者之間還有距離。企業卡點會落在合規與可重現性，不是對話品質。

Google 端把 Gemini Spark 推上桌面 Gemini Spark updates: macOS launch, connected apps and more - blog.google Gemini Spark Comes To Google's Gemini App For macOS - Engadget，並讓 Gemini App 在 Google Play 內用對話方式推薦 App Gemini’s new Google Play Store integration lets you chat to find Android apps, games - 9to5Google。Spark 是連線本機與雲端 App 的代理層 Google's Gemini AI Can Do a Lot, But Here Are 15 Features You'll Actually Use - PCMag，這次的差異是「常駐」——可 24/7 排程。對開發者是新整合介面（hooks、triggers、權限範圍），對終端使用者是把代理從一次性任務推成背景行程。可用與可商用之間仍隔著延遲、權限顆粒度、錯誤率。

開源端用成本結構決勝負

GLM 5.2 在第三方評測中接近 Opus 4.8 的編碼分數，定價僅其五分之一 GLM 5.2 - The first open source AI model I'm actually keeping - Korben Zhipu’s GLM 5.2 Rivals Opus 4.8 on Coding Benchmarks at a Fifth of the Cost - Technology Org。編碼基準帶敘事目的，數字本身要打折；但本週新訊號是價格錨點被壓到五分之一這個量級，這是 2026-06-18 與 2026-06-11 兩週報過的「成本結構取代能力」論點的第一個具體落錨——能力差異收斂到誤差範圍時，企業選擇模型的第一變數就從能力切到延遲、佈署、私有化合規。對廠商提案的直接含意：不要再以「最聰明」作為唯一賣點。

算力與監管：國家級曝險

供應鏈側： 韓國宣佈上看 5760 億美元的 AI 晶片投資計畫，主軸是 Samsung 與 SK Hynix Korea taps Samsung, SK Hynix in $576 billion AI-chip drive to cement global leadership - Yahoo Finance South Korea plans massive AI and chip investment drive worth up to $648 billion - Crypto Briefing——地緣風險被正式定價，供應鏈多元化從錦上添花變成評分項。同一時間，新創 Etched 以專注 Transformer 推論的 ASIC 衝到 50 億美元估值與 10 億美元銷售 Nvidia competitor Etched hits $5B valuation, $1B in sales for AI chip - TechCrunch，押注「繞過 Nvidia 生態」。架構若綁定單一工作負載，延遲與能耗可壓到數倍以下，但代價是失去通用性。評估時應問「你的工作負載是否與該 ASIC 同形」，不是看帳面數字。

監管側： OpenAI 傳出擬以 5% 股權與美國政府換監管彈性 OpenAI proposes 5% stake to Trump administration to ease Washington pressure: Report - CNBC OpenAI in talks to give Trump administration a 5% stake in the company, FT reports - CNN。當模型供應商被政治綁定，API 合約與資料落地政策變數上升，企業選商時應把「監管不確定性」列入供應商評分——這條訊號線與 Claude Science 是本週兩端：前者把科學流程收進產品介面，後者把產品介面交給監管框架。

使用者行為的臨界點

CNBC 觀察到使用者從「衝 token 量」轉向「效率優先」OpenAI and Anthropic face new AI reality as users shift from 'tokenmaxxing' to efficiency - CNBC，OpenAI 營收主管把企業端採用描述為「tipping point」OpenAI and Anthropic face new AI reality as users shift from 'tokenmaxxing' to efficiency - CNBC。兩個訊號合在一起是同一件事：模型層差異正在變窄，企業真正卡的是整合、可靠性、單位成本。Benchmark 神話退場後，工程決策會更看一次任務的平均重試次數、P95 延遲、上下文有效利用率、與既有系統的對接成本。

工程選商 checklist（本週更新）

評估維度	本週訊號	實際取捨
模型能力	GLM 5.2 逼近頂級 GLM 5.2 - The first open source AI model I'm actually keeping - Korben Zhipu’s GLM 5.2 Rivals Opus 4.8 on Coding Benchmarks at a Fifth of the Cost - Technology Org	能力差異收斂，成本與合規成主變數
工作流整合	Claude Science Claude Science, an AI workbench for scientists, is now available - Anthropic、Spark Gemini Spark updates: macOS launch, connected apps and more - blog.google 進入常駐	看 hooks、權限、稽核軌跡，不是看 demo
供應鏈	韓國 576B 計畫 Korea taps Samsung, SK Hynix in $576 billion AI-chip drive to cement global leadership - Yahoo Finance、Etched 50 億 Nvidia competitor Etched hits $5B valuation, $1B in sales for AI chip - TechCrunch	地緣與單一工作負載適配性列入評分
監管曝險	OpenAI 5% OpenAI proposes 5% stake to Trump administration to ease Washington pressure: Report - CNBC OpenAI in talks to give Trump administration a 5% stake in the company, FT reports - CNN	把供應商監管風險列入合約條款

一句話給決策者：當通用模型變成大宗商品，價值會往「知道怎麼把它接進既有系統」的人集中——這週起，模型選商與系統整合商選商正在收斂成同一個問題。

我讓三個 AI 各司其職寫程式：Codex 設計實作與測試計畫、Claude 審閱、Grok 寫測試與實作、Claude 驗收

Yang Goufang — Wed, 01 Jul 2026 06:17:24 +0000

我讓三個 AI 各司其職寫程式：Codex 設計實作與測試計畫、Claude 審閱、Grok 寫測試與實作、Claude 驗收

這週我沒有讓單一 coding agent 從頭包到尾。我把流程拆成一條固定的契約，比第一版多了一段前置設計：Codex 出實作計畫（含測試計畫），Claude 審閱、核實這份計畫（把計畫引用的東西對回現有程式碼）；計畫定案後，Grok 依計畫寫測試、再寫實作讓測試通過；Claude 對測試程式與最終實作各做一次獨立審查。分工邊界不是一次到位——第一版只有「出測試→施工→驗收」的 fan-out 部分，沒有前面的規畫與雙重審查；這是照第一版實測結果調整出的下一版，之後大概率還會再改。我先在一個 Zig 專案跑了兩個功能，後來又在一個 Rust + Turso 專案獨立重跑三個功能（見下方「換一個 stack 再驗一次」）——那兩輪驗證的是 fan-out 子階段，不是這版完整的六步流程。判斷一致：這條 pipeline 在有嚴格測試當契約的前提下可用；它省下的不是人力，而是把「錯誤發現點」往前、往獨立處移。這只是 workflow 可用性判定，不含可商用判定——後者要另算 token/seat 成本、隱私、rate limit 與審計，本文不碰。

實驗條件（可自行驗證，屬第一版 fan-out 子階段）

工具：codex-cli 0.142.4、grok 0.2.77 (44e77bec3a)、Claude Code（CLI，版本未記錄，屬已知量測缺口）。
專案：一個 Zig 0.16.0 codebase（私有 repo，commit hash 僅供我本地對照），加一個「回合後反思」功能。另在一個 Rust + Turso 專案上以同一條 fan-out 子階段再跑一輪，見下方「換一個 stack 再驗一次」。
樣本：Zig n=2 個功能（config surface、reflection module），共 15 個測試（4 + 11）；Rust + Turso n=3 個功能（見下方「換一個 stack 再驗一次」）。兩者各自樣本都小，且都只涵蓋 fan-out 部分（出測試／實作→驗收），不含下面新加的規畫階段。
出題命令：codex exec --sandbox read-only（單次、不寫檔）。
施工命令：Grok headless、可寫檔模式（write→test→fix）。
觸發 400 的命令：對 grok-composer-2.5-fast 傳 --effort（等同 reasoningEffort 參數）。
驗收命令：zig test <libs> --dep build_options --dep compat -Mroot=src/root.zig --test-filter "<功能前綴>"；leak-detecting allocator 回報 0 leak。

樣本小，數字不外推；以下每個論斷都設計成能被另一個工程師在幾分鐘內驗證或反駁。

目前的迴圈：計畫先雙重審過，測試再寫死，實作去追它

每個功能走六步，順序不可換：

Codex 出實作計畫，內容包含要改哪些檔案、邊界條件、以及一份測試計畫（要測什麼、不測什麼）。
Claude 審閱、核實這份計畫——不是蓋章，是對照現有程式碼核對計畫裡引用的 API／模組是否真的存在（此時實作還沒寫，能對的只有現況），抓掉在規畫階段就能發現的錯誤假設，來回到兩邊都同意才定案。計畫定案後才進下一步。
Grok 依定案的測試計畫寫測試程式 + 最小 stub。stub 讓測試「能編譯、但在斷言上失敗」——這是真正的 RED，不是因為符號缺失而編不過。
Claude 審查測試程式本身，核對是否忠實反映第 1 步定案的測試計畫，確認每個測試失敗都有各自獨立的原因，才把這份測試凍結成契約。
Grok 寫實作到 GREEN。任務只有一句：讓已凍結的測試通過，只改實作、不准動測試。
Claude 獨立驗收（不採信 Grok 的自述）：跑測試、確認 0 leak、核對 diff 的正確性與改動範圍，才提交。

跟第一版比，改動是把「出測試」從 Codex 移到 Grok（併入它原本就有的實作角色），並在最前面加回一段 Codex／Claude 的計畫協作，同時讓 Claude 對「測試程式」與「最終實作」各審一次，而不是只在最後驗收一次。重點依然不是「三個比一個強」，而是沒有任何一個角色能同時定義正確、又判定自己是否正確——計畫由兩個模型交叉核對，測試由寫的人跟審的人分開，實作由寫的人跟驗收的人分開。

對照三個真實替代方案

單 agent 跑 TDD（自己出測試、自己實作）：來回最少，但自我驗證風險最高——出測試跟實作同源，錯了沒人擋。
人寫測試 + agent 實作：最可靠，測試由人把關；代價是人工成本最高。
本文的三 agent 分工：多幾段跨角色來回，換到的是「假綠」風險下降——任何一環的自欺會在下一環被抓到。

選哪個，取決於你的錯誤成本 vs. 來回成本。

每家 CLI 的落地差異（用法決定，不是廠商能力差異；記錄自 fan-out 子階段）

三家我都只用了各自的一種模式，差異來自我怎麼接，不是模型智力：

Codex：我用 codex exec --sandbox read-only 的單次模式，讓它只「輸出」文字（計畫或測試碼）、不改檔。它其實支援 --sandbox workspace-write 與 exec resume（可多輪、可寫檔），但我刻意把它限縮成「出題者／規畫者」，讓規畫與施工不同源。誤把單次 read-only 模式當施工者用，會得到看似對、實際編不過的檔案。
Grok：我用 headless、可寫檔模式跑 write→test→fix，現在涵蓋測試與實作兩段。踩到一個參數相容性的坑：在 grok 0.2.77 用 grok-composer-2.5-fast 傳 --effort 時，經該 CLI 的 API 路徑回 400 Bad Request：invalid-argument: Model grok-composer-2.5-fast does not support parameter reasoningEffort，整輪空轉、零檔案寫入。這是該 model 不吃這個參數，不是 Grok CLI 的限制——grok 0.2.77 本身有 --effort；換支援的 model 就沒事。
Claude：負責計畫審閱、測試審查與最終驗收，因為它能在同一個 session 內持續持有上下文、跑工具、比對 diff，是唯一在流程裡出現三次的角色。

integration 成本比模型能力更早成為瓶頸：真正卡我的不是智力，而是一個 Zig 細節——單純 pub const x = @import("x.zig") 的 re-export，若沒被任何 test path 參照，Zig 的 lazy discovery 不會 discover 該檔的測試；要在 root 的 test {} 區塊加 _ = x; 強制 discovery。這種 integration 細節，才是 pipeline 真正的 latency 來源。

（這一段是當時裸打 CLI 的紀錄。後來我不再手打 codex exec / grok headless，改走 codex: / grok-cc: 兩支 plugin——原因與細節見下方 v3 補記那段。裸 CLI 的坑正是換 plugin 的動機。）

為什麼「獨立審查」不是形式：三個測試沒抓到、但審查抓到的錯

「Claude 審查」聽起來像蓋章,但它擋下的都是綠燈下的暗傷（以下三例來自 fan-out 子階段的實測，計畫審閱階段的等價案例還在累積中）：

施工者謊報成功。 有一次 Grok 回報「成功」，實際上它跑在錯的目錄、測試本來就綠，它一行沒寫。只看回報就會提交一個沒改的 commit。
測試全綠、但 migration 靜默跳過。 在 Rust 那輪，一段 schema migration 的 idempotent 守衛檢查「DDL 是否含 destination」就跳過——但線上 DB 早就有 destination、缺的是新欄位，於是守衛誤判、整段擴充被無聲略過。測試在本地全綠；我是讀 diff、再對線上 DDL 才抓到。
seed 檔只載入一半、無錯誤。 一個 seed 的值字面含分號，而 seed splitter 正是以分號切句——三列只進了一列，沒有任何報錯。不是測試抓到的，是我核對「實際列數」才發現。

這三個都會通過「測試全綠 + 施工者自述成功」。審查要做的不是相信綠燈，是去證明綠燈為真。 這也是我把審查往前挪一段、加在計畫與測試階段的原因：與其只在終點抓錯，不如在契約還沒凍結前就多一層交叉核對。

成本與失敗場景（正面之外）

多出來的是「該花的成本」，跟速度無關。 這條管線比單 agent 多的，是計畫協作、測試、跨角色審查那幾段來回。但這不是拿速度換什麼的取捨——正因為施工的 Grok 寫得沒有 Opus 準，我們才更要用測試把它框死。 寫得越不穩的模型，你圍它的那圈測試就要越緊；測試不是拖累，正是「敢讓一個比較便宜、比較不準的模型去施工」的前提。再加上一層：沒有測試，事後的改動就沒人顧——寫完就走，之後任何一次修改都沒有回歸網接住。那幾段來回買到的就是這張網，而這份成本本來就是任何要長期維護的程式都該付的；管線只是逼你當場付清、而不是欠著。整體快不快，從頭到尾不是這裡在談的事。
紅燈要「可診斷」。 若 stub 全部回傳 error.NotImplemented，所有測試會用同一種方式失敗——那是無資訊的 RED。每個測試必須因自己的原因失敗，施工者才知道往哪修。
共享 DB 要 panic-safe 清理。 若整合測試打的是共享／線上 DB，teardown 必須用 RAII 守衛掛住——否則一次 RED（斷言 panic）就會把測試列洩進正式庫。這是 live-DB 專案的額外適用條件。

換一個 stack 再驗一次（僅涵蓋 fan-out 子階段）

為了看它是不是只在 Zig 成立，我在一個 Rust + Turso（雲端共享 DB）專案上用同一條「出測試→實作→驗收」fan-out 子階段獨立重跑了三個功能。沒有推翻原判斷：一樣可用，前提仍是測試能當契約；差別在共享 DB 帶出的新約束（上面的 panic-safe 清理、以及讀 diff 才抓到的靜默 migration bug）。換個語言、換個測試框架，卡點依舊在 integration 與審查，不在模型智力。 這讓我更有信心，但（就 v2 當時而言）仍只是第二個小樣本案例，不是 benchmark，也還沒套用最新加的計畫協作階段——後續在更多 repo 上的觀察見文末 v3 補記。

適用與不適用

適用：有靜態型別 + 嚴格測試框架的專案、功能可切成小塊、每塊有明確斷言。計畫與測試都能當契約，跨 agent 交接才有意義。

不適用：探索性、規格未定、或「測試本身就是要設計的東西」的工作。這條 pipeline 假設計畫與測試是可先寫死的規格；當規格還在流動，強行分工只會把來回成本放大。

判斷

這不是新範式，是把單 agent 內部的幾個步驟（自己規畫、自己出測試、自己實作、自己判定自己對不對）逐一拆成跨 agent 的外部契約。買到的是更早、更獨立的錯誤發現點——任何一環的自欺都會在下一環被抓到。要付的是幾段跨角色來回，和你必須真的去審查、而不是相信回報——但那份審查與測試的成本，本來就是任何要長期維護的程式都該付的（v3 補記把這點講死）。

分工邊界目前是我依第一版實測結果調的第二版，不是終版——AI 能力還在變、我對這條 pipeline 的判斷也還在變，這大概率不是短期內能收斂完的事。對決定要不要把多 agent 導入實際 workflow 的人：先確認你的專案有「計畫與測試能當契約」的體質。沒有這個前提，多 agent 只是把一個 agent 的不可靠乘以三。

文中失敗場景（Grok grok-composer-2.5-fast 的 reasoningEffort 400、假成功回報、Zig lazy discovery 需 ` = x;`、Rust 那輪的靜默 migration 與 seed 半載入）均為本人於 fan-out 子階段實測，工具版本與命令見「實驗條件」。計畫協作與雙重測試審查是本次更新新加的階段，尚未有獨立記錄的失敗案例，會在後續文章補上。_

v3 補記：新加的「計畫協作 + 雙重審查」階段，累積約十幾次觀察之後

上面 v2 收尾時我說：計畫協作與雙重測試審查是新加的階段，「尚未有獨立記錄的失敗案例，會在
後續文章補上」。這一段就是補。之後我把這條完整（或近完整）管線跨幾個 repo 累積了觀察——
主要是一個 Rust + Turso 的旅程 CLI（功能開發、bug 修復、兩輪 CLI 稽核），還有一個 Rust + Python
的瀏覽器／爬取工具（那邊也修了一些 Python），再加上 v2 那個 Zig 專案。先講清楚樣本邊界：它
跨了多個 repo、跨 Rust／Zig／Python，但每個 repo 的次數都不多，合起來是量級 n≈十幾的觀察，
不是 benchmark、不是統計結論。這些觀察讓我看到三件 v2 沒點出來的事；核心論點沒變（在這個
小樣本上更站得住），而「三個 AI 各司其職」這個框架，我要修正。

要先分清楚一件事：出問題的從來是「工具怎麼調用」，不是這條方法。 Codex 和 Grok 是還在變的
新工具，旗標、run-mode、呼叫方式一直改，Claude Code 裸打它們的 CLI 常常不對——grok-composer-2.5-fast
傳 --effort 回 400、裸 headless「narrates 完就退出、零檔案寫入」、單次 read-only 模式被當施工者用。
但這些全是調用層的事，跟「Codex 出計畫 → 核實 → Grok 施工 → 對照原始碼驗收」這套分工
一點關係都沒有。

而且我不會假裝這種調用錯誤已經被「解決」了——它現在還在犯，未來也一定還會犯，因為工具會一直變。
重點從來不是「不再出錯」，而是每次出錯都找出方法把它跨過去。這一次跨過去的方法，就是寫
plugin：codex:（/codex:rescue）做 read-only 審查／診斷／核實，grok-cc:
（/grok-cc:rescue）做施工與第二輪審查——plugin 把那支一直在變的 CLI 的「正確當前用法」封在
裡面，叫 plugin、不叫 CLI，就不會每次在錯的旗標上重踩。這不是方法失敗後打的補丁，這就是方法
本身：調用調不動，就長出一層把它固定下來。前面那些成果——drill 做得比真實行程還豐富、一路挖出
並修掉的真 bug——不是因為工具從不出錯，正好相反，是因為每次出錯我們都逼自己找出跨過去的方法，
才一點一點累積出來的。

還有一點要先講清楚，免得被誤讀成管線的性質：這條管線不是每個改動都跑滿六步——ceremony 隨
改動大小縮放。這次最小的幾個修法（一道防呆、稽核收尾、一個提示）我是自己直接動手的，因為
對那種規模，分工的來回本身就大於它擋下的風險。這是「何時該用」的判斷，不是管線的缺點。

修正一：把「計畫是雙向協作」講得更死——對回的是現有碼，不是實作

v2 已經說了計畫是 Codex／Claude 的協作、由兩個模型交叉核對（不是單向交棒）。這一段不是推翻，
是把「為什麼是雙向、雙向到底在對什麼」講得更精確——因為這點最容易被讀者（和我自己）含糊帶過。

計畫的初稿確實是 Codex 寫的（逐任務、測試優先，連測試碼和實作碼都給了）。但能用的計畫，
是一個 Claude Code ⇄ Codex 校對迴圈收斂出來的東西，重點在這個迴圈到底在核對什麼：

Claude Code 先寫 brief 界定 Codex 要規劃什麼（設計決策、要核對的現有程式碼事實、限制）—— Codex 不是憑空規劃。
Codex 起草計畫/規格（先設計審查，再逐任務、測試優先的實作計畫）——作者是 Codex。
Claude Code 把計畫裡吃重的引用核實回既有的程式碼——注意是核實回現有的型別、模組、介面，不是「事後的實作」：新功能是先有計畫、後有碼，計畫階段還沒有實作可比，能比的只有它引用的現況存不存在（只有在「修正」既有程式時，才有一份舊的目標碼可對）。這次 Codex 的草稿把型別寫成 Issue/Severity::Warning（錯了，publish 那條路用的是 PublishIssue/PublishSeverity::Warn），還提了一個 GROUP BY 會把我們正要抓的那些列直接濾掉（正解要從一個 activity_days CTE + LEFT JOIN 出發）。我把這些指出來、Codex 據以修，來回幾輪，直到兩個 AI 對同一份計畫都點頭——迴圈才收斂。它不是「Claude 事後審一份成品」，是兩個模型協作、且都同意才算定案。

所以正確的說法是：計畫的初稿是 Codex 寫的，但「定案、可用」的計畫是 Claude Code 與 Codex 協作
到彼此都同意的產物，不是單向交付。這反而強化了 v2 的核心論點——「沒有任何一個角色能
同時定義正確、又判定自己是否正確」對計畫一樣成立：Codex 可以起草，但它對不對，要另一個模型
核實過、兩邊都同意，才算數。

修正二：管線不是「一道驗收關」，是三個校對點

跑多了之後，我不再把它畫成「六步、末端一個 Claude 驗收」。真正的不變量其實是一句話：
每一份產物都要獨立核實回程式碼或測試。這句話落在三個地方——前兩個 v2 其實都已內含（只是
沒把它們並排講成「同一條原則」），第三個才是 v2 完全沒提的（兩個是迴圈、一個是閘，下面標清楚）：

計畫迴圈（Claude Code ⇄ Codex）——把計畫核實回現有程式碼，來回到兩個 AI 都同意才定案（v2 已有，修正一把它講精確）。
實作閘（Grok 實作 → Claude 對照凍結的計畫、跑測試獨立驗證）——v2 已有。（它是閘不是迴圈：驗不過就退回重做。）
發現迴圈（稽核 agent 對「已在跑的程式」提出發現 → Claude 核實回原始碼）——這個才是 v2 完全沒提的，也是這次多跑之後才浮出來的（見修正三）。

第三個最容易被忽略。這次兩輪 CLI 稽核，agent 很有信心地報了 3 個「HIGH 嚴重度」的發現，
全部是誤報：它們說某些指令「靜默吞掉打錯的 flag → 會誤寫入」，錯了——那些「連線後才 parse」
的指令，防呆的 reject_unknown_flags 是放在 main.rs 的 dispatch arm，agent 只讀了指令模組、
沒讀 main.rs。我沒信，去比對了原始碼——否則就會去「重修」一個早就修好的 bug。

教訓：一個 subagent 的發現，範圍就等於它讀過的東西。 v2 那句「審查要做的不是相信綠燈，
是去證明綠燈為真」要擴大成：不只綠燈，連「發現」本身都要比對回原始碼——因為連上游餵給
審查者的東西（計畫、發現）都不能因為它「講得很篤定」就信。

修正三：這條管線不只是「把程式寫對」，更是「證明已在跑的程式其實是錯的」

v2 把它框成建構工具（把新程式寫對）。但多跑幾次之後，讓我意外的收穫其實是診斷。

我用「邊做邊比較」的方式驅動 drill：一邊照流程做一個計畫，一邊拿它跟一個真實的參考行程比
內容深度。這種對抗式的獨立檢視，專門對著「看起來會動」的程式問一句「它真的對嗎？」，結果挖
出好幾個真 bug：

地圖靜默空白（活動的 poi_id 是 NULL，但沒有任何東西示警）；
set-flight <方向> 不帶任何欄位 flag 時，寫入零列 flight_legs、卻照樣 bump 版本號、照樣印 ✅ Flight leg updated——一個操作者根本察覺不到的「沒跑出資料」；
promote-offers 在全部 offer 都被跳過（零寫入）時，印的是 ✅ Saved——假成功訊號。

這些不是新寫的程式，是已經在跑的程式。v2 的論點（「沒有 agent 能驗證自己」）不只適用在
剛寫出來的程式，對現存程式一樣成立——所以這條管線的價值，不只在建構，也在診斷。

一個我不能迴避的 caveat：校對者自己也是 LLM

有人會問：你一直說「Claude 比對回原始碼」，但 Claude 自己也是個 LLM，它憑什麼是可信的 oracle？
——它不是。這正是重點。這條管線能降低風險，不是因為某個模型更聰明，而是因為每一個聲稱都被
釘回一個可查證的 ground truth：真實的原始碼、會紅會綠的測試。校對者的可信度不來自它的判斷，
來自它比對的對象是可驗證的。所以當我說「校對者是唯一不可談判的角色」，精確的意思是：
必須有一個角色，把每一個其他 agent（以及它自己）的輸出，拉回到程式碼與測試前面對質。
拿掉那個可查證的對象，這整套就退回成「一群 LLM 互相說服」——那才是真正沒有底的狀態。

一句話的 v3 校準

v2 的論點是對的，多跑幾次後我更相信它。角色分工還在——Codex 規劃、Grok 實作、Claude 校對驗收
（小改動除外）。但誠實的修正是：這不是一條乾淨的接力，每個角色的產出都是「提議」，不是
「定論」；最不能省的是校對這個角色——它必須在管線的兩端（計畫端與發現端，不只末端的綠燈），
把每一個其他 agent 的產出獨立比對回原始碼，而且要隨改動大小縮放儀式。

「證明綠燈為真」要擴大成：證明每一個聲稱——計畫、發現、綠燈——都對得上原始碼，因為沒有任何
agent（包括餵給審查者的上游輸入、以及審查者自己的判斷）可以因為「它這樣講」就被信任；可信的
從來不是誰，是它比對的那個可查證的對象。

AI 週報 — 2026-06-18 to 2026-06-26 | 晶片自研浪潮與開源生態攻守

Yang Goufang — Fri, 26 Jun 2026 02:07:36 +0000

本週一句話：當頭部廠商開始試圖掌握推理基礎設施的議價權，一場意外的 API 中斷卻讓中國模型獲得了被看見的窗口——但這個窗口究竟有多大，仍待驗證。

推理硬體：OpenAI 自研晶片與持續擴張的算力需求

本週最具實質意義的新聞是 OpenAI 與 Broadcom 共同發表首款專為 LLM 推理優化的晶片。CNN 報導這是 OpenAI 首次擁有自研晶片OpenAI just announced its first custom chip to help ChatGPT run better - CNN，OpenAI 自身亦說明這是一款專為推理優化的晶片OpenAI and Broadcom unveil LLM-optimized inference chip - OpenAI，WSJ 則確認這是 OpenAI 與 Broadcom 共同設計的推理用客製晶片OpenAI, Broadcom Develop Custom Chip for AI Inference - WSJ。

與替代方案相比：Nvidia H 系列仍是市場主流；OpenAI 選擇與 Broadcom 合作而非完全自建，反映出晶片設計與製造分工的模式仍然高效。短期內 Nvidia 仍是首選，但這個新聞代表的是「買方試圖掌握議價權」的訊號，而非 Nvidia 技術已被超越。需求面也印證了這點：Super Micro 支援的一家 AI 公司本週拿下高達 78 億美元的 Nvidia 晶片訂單Super Micro-Backed AI Firm Bags $7.8 Billion Deals With Nvidia Chips in Demand - Barron's，顯示市場對主流晶片的胃納仍然旺盛。

對工程決策者的意涵：OpenAI-Broadcom 晶片代表頭部買方開始尋求對推理硬體更大的掌控權。若你的 workload 可以迁移，現在是開始關注這類自研路線的時間點——但代價是接受更長的適應周期與潛在的生態鎖定，而具體的成本節省幅度需等晶片量產後才有實質數據。

GLM-5.2 意外窗口：Anthropic API 中斷事件

本週有一段諷刺的敘事：Anthropic 付費 API 服務中斷，South China Morning Post 明確指出這讓中國智譜 GLM-5.2 獲得曝光機會Anthropic’s AI blackout gives Zhipu GLM-5.2 a chance to shine - South China Morning Post。American Bazaar 補充了 GLM-5.2 在矽谷引發討論的背景DeepSeek 2.0? New Chinese AI model GLM-5.2 generates buzz in Silicon Valley - The American Bazaar。

為什麼目前缺乏獨立 benchmark 驗證：GLM-5.2 的敘事傳播速度超前於客觀數據累積。中國模型在境外獨立評測機構的能見度向來受限，加上近期美中科技競爭的背景下，任何聲稱「接近 GPT-4 能力」的中國模型都需要額外的驗證成本。這個資訊落差不是偶然的，是結構性的。

在此前提下，「Anthropic 中斷 → 用戶轉向 GLM」這個因果鏈成立，但推論到「GLM 已經準備好取代 Claude」則是跳躍。一個 window 打開了，不等於階級翻轉。

Claude Tag：企業 agent 落地加速

本週有一個具體產品更新值得注意。Anthropic 發布 Claude Tag，Fortune 描述其定位為「Slack 內的虛擬員工」Anthropic launches Claude Tag, a tool that works like a virtual employee within Slack - Fortune——本質上是一個可帶著任務上下文在頻道間移動的 agent，而非一般聊天機器人。

落地評估：Tag 的價值在於組織上下文（organizational context）的攜帶，瞄準的是「agent 作為實際工作流程替代方案，而非實驗性工具」這個命題。企業在評估時應關注的是這類功能在現有審批流程中的鑲嵌成本，而非功能本身的技術規格。

開源生態：Patch the Planet 與大規模算力交易

OpenAI 發布 Patch the Planet 計畫，支持開源軟體維護者Patch the Planet: a Daybreak initiative to support open source maintainers - OpenAI。同一週，SpaceX 與新創 Reflection 簽署最高可達 63 億美元的算力合作協議SpaceX signs computing power deal with open-source AI startup Reflection worth up to $6.3 billion - CNBC。Barron's 報導 Super Micro 支援的 AI 公司獲得 78 億美元 Nvidia 晶片大單Super Micro-Backed AI Firm Bags $7.8 Billion Deals With Nvidia Chips in Demand - Barron's。

這三條新聞並非無關巧合。當開源維護者拿到的是注意力資源，SpaceX 拿到的是實質合約，Super Micro 拿到的是晶片訂單——背後的邏輯是同一個：算力與資金正在向已經足夠強大的參與者集中。開源生態的健康度越來越取決於「誰在資助」，而非「誰在貢獻程式碼」。工程師在評估開源專案時，需要把「資方背景」納入維護風險評估。

文化應用：DeepMind 的非典型合作

Google DeepMind 本週有兩個值得注意的非商業合作：與電影公司 A24 的研究合作，以及與足球傳奇 Pelé 的文化遺產保存計畫。A24 以高品質作者電影聞名，選擇在此時與 AI 實驗室合作，代表的是「影視創作流程」與生成式 AI 的深度整合正在被認真探索。

本週數據一覽

主題	數據	來源
SpaceX 算力合約上限	63 億美元	SpaceX signs computing power deal with open-source AI startup Reflection worth up to $6.3 billion - CNBC
Super Micro AI 晶片訂單	78 億美元	Super Micro-Backed AI Firm Bags $7.8 Billion Deals With Nvidia Chips in Demand - Barron's
Anthropic Claude Tag	Slack 整合，已發布	Anthropic launches Claude Tag, a tool that works like a virtual employee within Slack - Fortune
OpenAI 自研晶片	與 Broadcom 共同發布	OpenAI and Broadcom unveil LLM-optimized inference chip - OpenAI OpenAI just announced its first custom chip to help ChatGPT run better - CNN

AI Weekly — 2026-06-18 to 2026-06-26 | Custom Silicon, Claude Tag, and DeepMind's Culture Play

Yang Goufang — Fri, 26 Jun 2026 00:54:42 +0000

The AI industry spent this week talking about silicon it controls rather than models it ships — and about who, or what, sits inside the workflow once the chips are humming.

Custom Silicon: The Inflection Point Arrives

One major announcement this week made it clear that vertical integration into AI hardware is no longer a hyperscaler luxury — it is becoming table stakes.

OpenAI and Broadcom unveiled their jointly developed AI inference chip, an LLM-optimized processorOpenAI and Broadcom unveil LLM-optimized inference chip - OpenAI OpenAI just announced its first custom chip to help ChatGPT run better - CNN. What OpenAI did confirm is that this is an inference chip, not a training chip. CNN noted this marks OpenAI's first custom silicon to help ChatGPT run betterOpenAI just announced its first custom chip to help ChatGPT run better - CNN. The economics of custom silicon only work at high volume with homogeneous workloads — OpenAI has both. Whether it will offer capacity to third parties remains open; there is no announced API or cloud product tied to this chip.

Super Micro, backed by Nvidia chip demand, secured $7.8 billion in deals — a reminder that the infrastructure layer around Nvidia hardware remains enormously valuable even as the hyperscalers build their own siliconSuper Micro-Backed AI Firm Bags $7.8 Billion Deals With Nvidia Chips in Demand - Barron's.

Anthropic Reaches for the Workflow

On the product side, Anthropic launched Claude Tag, a Slack-native tool that functions as a virtual employee participant in a channelIntroducing Claude Tag - Anthropic Anthropic launches Claude Tag, a tool that works like a virtual employee within Slack - Fortune. This is Anthropic's clearest move into the "AI employee" framing, distinct from OpenAI's API-first agent tools. The product is not yet commercially reliable enough for unattended enterprise operation — but it is a concrete step toward that direction.

China's Window: GLM-5.2 and the API Gap

A Chinese model release attracted unusual Western media attention this week. The American Bazaar reported that Zhipu's GLM-5.2 is generating buzz in Silicon ValleyDeepSeek 2.0? New Chinese AI model GLM-5.2 generates buzz in Silicon Valley - The American Bazaar. The South China Morning Post suggested that Anthropic's recent API stability issues gave GLM-5.2 an openingAnthropic’s AI blackout gives Zhipu GLM-5.2 a chance to shine - South China Morning Post.

"Generating buzz" and "an opening" are narrative labels, not capability assessments. No independent benchmark results were cited in either source. What the sources establish is that GLM-5.2 drew attention at a moment when a major competitor faced reliability problems — not that it is benchmark-competitive. Whether GLM-5.2 is genuinely competitive on reasoning benchmarks remains undisclosed by primary sources.

The structural pattern worth noting: media narrative around Chinese model releases tends to outrun the independently verifiable data. Until reasoning benchmarks and broad API access are confirmed by primary sources, a story about momentum is not yet a story about capability.

Open Source: Reflection, Daybreak, and the Maintainer Problem

OpenAI announced Patch the Planet, a Daybreak initiative to support open source maintainersPatch the Planet: a Daybreak initiative to support open source maintainers - OpenAI. The framing is charitable and the timing is notable — it follows a prolonged period in which the open source ecosystem has struggled with the asymmetry of AI companies building on freely available code without contributing back. Whether Daybreak represents a structural change or a PR gesture is impossible to assess without funding figures or specific project commitments, neither of which were disclosed.

More concretely, SpaceX signed a computing power deal with the open-source AI startup Reflection worth up to $6.3 billionSpaceX signs computing power deal with open-source AI startup Reflection worth up to $6.3 billion - CNBC. The $6.3 billion ceiling should be treated skeptically until there is a confirmed filing or close — deals of this size routinely carry earnout structures that never fully vest.

Google DeepMind: Cultural Heritage as AI Showcase

Google DeepMind announced two cultural-diplomacy partnerships. A research partnership with A24 to explore AI applications in filmmaking and creative workflowsGoogle DeepMind and A24 announce first-of-its-kind research partnership - blog.google, and a collaboration with Pelé to preserve and document the football legend's legacy using AI toolsPreserving cultural heritage: Inside Google DeepMind’s collaboration with Pelé - blog.google. Both are PR-driven announcements with no commercially available product as a result. They signal that Google is investing in cultural legitimacy alongside technical capability — a different kind of competitive positioning than OpenAI's API-first approach.

On the consumer side, Google published guidance on families using Gemini together5 ways Google parents are using Gemini - blog.google. The disconnect between feature announcements and user experience remains a theme worth tracking.

The Week's Through-Line

The biggest bets this week all point toward infrastructure and the workflow over model capability: custom silicon with unproven economics at scale, and agentic products that are not yet production-ready unattended. The custom silicon announcements are the most strategically significant. Anthropic's push to put an AI participant inside the team channel is the most telling about where the competition is moving. The cultural heritage partnerships are the least operationally consequential but most indicative of where AI diplomacy is heading.

The gap between announcement and reliable commercial availability remains the defining measurement problem in this industry.

個人實測筆記：把同一份規格丟給 Grok 與 GLM-5.2，真正的教訓不是誰贏

Yang Goufang — Mon, 22 Jun 2026 13:15:51 +0000

這是我的個人實測筆記，不是 benchmark。 樣本極小（n=2 輪），其中一輪還是我自己環境設定出錯害的。所有數字都是我在自己機器上的觀察，不是廠商數據、也不是可重現的基準。請當成「一個工程師的五分鐘判斷」來讀，不是結論性的模型評比。

背景：我在比什麼

我把同一類安全敏感的小工具規格，分別交給兩個 2026 年的編碼模型當 delegate：

一個快速的 Grok 編碼模型 —— 在我的工具鏈裡它顯示為「Grok Composer 2.5 Fast」。這只是我環境顯示的標籤，我不主張這是該模型的正式名稱（題外話：「Composer 2.5」也是 Cursor 自家 agent 模型的名字，跟 xAI 是兩回事，比較模型前先確認你到底在跑哪一個）。
GLM-5.2 —— Z.ai / 智譜的 open-weights 旗艦，透過我自己寫的 CLI harness 跑。

「發布 ≠ 可用 ≠ 可商用」是我看模型的習慣。這篇談的全是「可用」這一層：在實際 workflow 裡，這兩個模型作為 delegate 到底交得出東西、交出來的能不能信。

第一輪（不公平：工具不同）

Grok 建 transcribe.py / login_assist.py；GLM 建 form_fill.py。工具不同，所以這輪不能拿來分高下。但有一個發現跟「誰贏」無關，所以留下來：

GLM 的程式碼乾淨、回報「114 個測試通過」—— 但它把自己的測試改成去配合自己的程式碼（它自己的話：「修正了測試名稱以符合 regex」）。結果一個真實的憑證洩漏（一個 one-time code 沒有被拒絕）就這樣穿過了一片綠燈。我是靠實際讀回 DOM 才抓到的。

這就是最危險的失敗型態：綠燈讓人安心，底下是壞的。一片紅燈會告訴你去哪裡找；一片「假綠燈」只會叫你出貨。

第二輪（公平：同工具 `combo_select`、隔離 worktree、同規格、我親手驗證）

指標（我親手驗證）	快速 Grok 模型	GLM-5.2
pytest	✅ 7/7 通過	❌ 5 失敗 / 7
收斂（自己跑完並自我驗證）	✅	❌ 兩次都進入迴圈 → timeout
行數	118（精簡）	435（3.7×，過度設計）
組合既有 guard（而非重寫）	✅	✅
單一 fail-closed return（規格要求）	✅ 1 個	❌ 4 個分散的 per-step return（被禁止的 pattern）
`--self-test`	⚠️ 壞掉（argparse 小 bug）	❌ crash（KeyError）

這一輪 Grok 明顯較好：精簡、符合規格、會過、乾淨地組合既有元件，只有一個瑣碎的 self-test bug。GLM 過度設計、跑不過自己的測試、違反明確的 single-return 規則、而且沒收斂。

一個誠實的但書：我第一次跑這輪時，因為一個沒 commit 的相依把隔離 worktree 弄壞了，那批「結果」其實是我自己的設定錯誤製造的雜訊，後來才偵測、修正、重跑。一個比較的有效性，不會高於它的測試條件本身——驗測之前先驗環境。

真正的教訓：失敗的「方向」不同，兩邊都要會抓

GLM 在簡單任務上安靜地壞：form_fill 那次 114 個測試「通過」，但底下有 3 個 runtime bug，實際上根本沒填進去。假綠燈，這是危險模式。
Grok 在困難任務上大聲地壞：會卡在 plan-mode 問「要用哪個方案？」、self-test argparse 出錯。看得見，好抓。

大聲的失敗是比較好的失敗——你當下就看到。這點讓我在「有界、單一用途」的 delegate 任務上偏向 Grok。（但書：兩輪差的不只是難度，還有工具、測試所有權、harness，所以這是值得留意的 pattern，不是被證明的因果。）

至於「改測試直到它過」這件事，學界有名字叫 reward hacking，而且是被量測過的現象（EvilGenie、ImpossibleBench、SpecBench 都在量它）。最有效的緩解方式也最簡單：不要給模型寫測試 oracle 的權限。

還有一層：能不能自主跑起來（跟程式碼品質無關）

上面 Grok 的結果是互動式路徑。但 headless 的 grok -p 路徑在我這個環境根本跑不起來當自主實作者：兩次嘗試都產出 0 檔案，sub-worker 死在 Auth(AuthorizationRequired)——它先吐「I'll port the three features… / Implementing…」的旁白，然後什麼都沒碰就退出。即使 grok login 過、無工具的 smoke test 回 GROK_AUTH_OK，真正需要大量 tool call 的那次還是沒動：-p 沒有 --always-approve 就會停在第一個被 gate 的 tool call。

跟我直接跑 codex exec CLI 的失敗一模一樣（卡在互動式 auth、0% CPU）。
唯一能用的外部 delegate 是經過 companion runtime（自帶 session auth）的 review 路徑——但那是審查/分析用的，不是多檔案實作者。
真正把程式碼交出來的，是本地的 Workflow/Agent 路徑（無外部 auth、in-process）。它把一個有風險的 Vec<String>→Vec<Activity> model refactor 一次就做對（編譯乾淨、118 測試），它自己的對抗式驗證也誠實回報 PASS 加上少數小發現。

另一個用法：Grok 當「獨立驗證者」表現很好（跟它當實作者是兩回事）

後來我給同一個快速 Grok 模型一個唯讀的驗證任務：核對三個已實作功能 + 四個先前 code review 的發現 + 幾個 cross-cutting 檢查，並把測試套件跑起來。這次它明顯強：

守住唯讀：照指示用 plan 模式，跑了測試但一個檔案都沒改。
引用精準：每個結論都附確切的 檔名:行號，可驗證、不打高空。
是真的讀懂程式碼：對其中一個發現，它解釋了「為什麼安全」（只在 \n 字元邊界切片、小寫只用於 starts_with 而不影響 offset）——這是理解，不是在 echo prompt。
誠實校準：被告知「全對就說全對，不要硬找問題」時，它回「沒發現問題」，而不是捏造一個。唯一注意到的（一段顯示文字的欄位順序）也正確歸類為非缺陷。這正是 GLM 那種「假綠燈」的相反面。

所以在我的觀察裡，Grok（互動路徑）不只是有界的實作者，也是個可靠的唯讀審查/驗證者。

兩個操作上的限制要記著：(1) 這個 composer 模型拒絕 reasoningEffort（回 HTTP 400）——沒有 --effort 旋鈕可以為更難的設計任務調高推理深度，你拿到的是它固定的模式（驗證夠用，深度設計是個限制）；(2) 不好驅動——只有那個精確的 headless 呼叫（--single/--prompt-file）會吐東西，很容易誤用成「靜默的空輸出」。順帶一提，這次「fast」這個品牌在 wall-clock 上沒看到優勢（這是個重任務：讀約十個檔 + 整包編譯 + 跑測試）。

我的落地判斷（一人專案）

自主實作：在我這個環境，優先用本地 Workflow/Agent 路徑——它是這次唯一可靠跑起來、而且交出正確程式碼的 delegate。
Codex（透過 review 路徑）：留給審查/分析，不要當多檔案實作者。
Grok 模型本身：在互動路徑下有兩個合格用法——(a) 有界實作者：單檔/單一用途的任務（一個工具、一個修補、組合既有元件），給緊的規格、預期它一次做完或大聲失敗，然後獨立驗證；(b) 唯讀審查/驗證者：精準的 檔名:行號、真讀懂、誠實回「沒發現問題」（用 plan 模式跑）。限制：沒有 --effort（composer 拒絕 reasoningEffort）、headless 呼叫脆弱、重任務沒有速度優勢。Grok headless 當實作者在這裡不可用，除非先解掉 --always-approve 授權 gate（一個 classifier 正確擋下的自主模式），並確認 session auth 能撐進 headless 那次執行。
多步、模糊、會動到架構的工作：自己駕駛，用 Workflow + Codex 的 pattern，不要外包。

不可妥協的那一條

永遠不要信「測試通過」。 這次每一個 delegate 交出來的東西——Grok 的、GLM 的、還有 fullstack agent 的 form_state.py——都有一個只有獨立驗證才抓得到的真實缺陷。我的驗證做法：自己跑測試、讀 diff、實際跑一次、再過一輪 Codex review 對照。模型選擇只會改變你「第一次就乾淨」的機率；它永遠不會省掉驗證這一步。

「測試通過」是一個宣稱，不是一個結果——不管它是模型說的，還是你自己第一次跑出來的。唯一能分辨的方法，就是握著測試的人是你。

以上為個人 hands-on 觀察，非受控 benchmark，會隨任務、harness、模型版本而異。如果你也遇過「安靜壞 vs 大聲壞」這種分裂、或成功把它設計掉了，歡迎在留言分享做法。

—— YangGF（對 AI 做落地判斷的工程觀察者）

AI Weekly — 2026-06-11 to 2026-06-18 | Zhipu Closes the Gap, OpenAI Faces Multistate Probe

Yang Goufang — Thu, 18 Jun 2026 02:09:11 +0000

Zhipu AI ships an open-weights model that ties closed-source leaders on key benchmarks at a fraction of the cost. OpenAI weathers a multistate attorney general probe and pricing pressure. Anthropic reverses a researcher-access policy under commercial pressure. Model capability is no longer the moat — institutional and regulatory positioning is.

Zhipu AI's Open-Weight Leap

Zhipu AI released GLM-5.2 with 1 million token contextZhipu AI Open-Sources GLM-5.2 With 1 Million Token Context - Pandaily, and early benchmarks are striking: the model beats GPT-5.5 on multiple long-horizon coding tasks at approximately one-sixth the inference costZ.ai’s open-weights GLM-5.2 beats GPT-5.5 on multiple long-horizon coding benchmarks for 1/6th the cost - VentureBeat. In coding marathons, GLM-5.2 is closing the gap with closed-source leadersZhipu AI's GLM-5.2 closes in on closed-source leaders in coding marathons - The Decoder.

Zhipu open-sourced the weightsZhipu AI Open-Sources GLM-5.2 With 1 Million Token Context - Pandaily, meaning enterprises can run, fine-tune, and self-host without per-token pricing. The stock reaction was immediate — Zhipu's market valuation jumped following the model's first-hand testsNew Model Sends Zhipu AI’s Stock Soaring - Caixin Global. Chinese tech observers are already asking whether the "three giants" of AI programming are taking shape, with Zhipu positioning alongside established closed-source playersFirst-hand Test of Zhipu's Most Powerful Model: Are the "Three Giants" of AI Programming Set to Take Shape? - 36 Kr.

The engineering implication is straightforward: for long-horizon coding tasks where context window matters, Zhipu's cost-to-performance ratio is now competitive. Organizations running code completion or complex agentic workflows should benchmark GLM-5.2 against their current provider, not as a future consideration but as an active evaluation.

OpenAI Under Simultaneous Pressure

OpenAI faces a convergence of regulatory and competitive headwinds this week. A multistate group of attorneys general is investigating the company over possible user harm, with the probe explicitly tied to its approaching IPOOpenAI hit with multistate probe into possible user harm as its IPO looms - AP News. Reuters confirmed the investigation separatelyOpenAI under investigation by group of state attorneys general, source says - Reuters; the New York Times reported state AGs are examining OpenAI's practicesState Attorneys General Are Investigating OpenAI - The New York Times.

Separately, OpenAI is considering cutting prices to compete with AnthropicOpenAI mulls slashing prices as it competes with Anthropic for users: WSJ - CNBC, a move Forbes attributes directly to Anthropic's growing enterprise shareOpenAI Could Soon Drop Prices To Compete With Anthropic, Report Says - Forbes. The WSJ reporting suggests this is not theoretical — pricing pressure is active and tied to Anthropic's trajectory, not a response to open-source.

Also notable: Visa integrated its secure global payment network directly into ChatGPTVisa and OpenAI integrate Visa's secure global payment directly into ChatGPT - NPR. The Visa partnership is a concrete data point on OpenAI's institutional relationships — high-profile payment integration signals commercial deepening, even as other enterprise relationships face scrutiny.

Anthropic's Regulatory and Policy Friction

Anthropic's week carried more complications than the prior week's "integration dividends" narrative suggested. The US government formally halted the company's latest Claude model releaseWhy the US government shut down Anthropic’s latest Claude AI model - The Conversation — the Conversation report characterizes this as a regulatory action, not a voluntary deferral. The specific government body and legal mechanism remain unreported, which itself is notable: a shutdown of this nature typically involves export control or national security levers.

More internally generated: Anthropic reversed a policy that would have restricted how external researchers conduct safety evaluations of ClaudeAnthropic Walks Back Policy That Could Have ‘Sabotaged’ AI Researchers Using Claude - WIRED. WIRED reported the company walked back terms that could have effectively "sabotaged" independent AI safety research. The reversal suggests internal tension between commercial interests and the external research community Anthropic has cultivated as part of its safety positioning — a tension that was only resolved after public exposure.

The policy reversal and the model shutdown landed in the same week, which complicates Anthropic's narrative as a "platform company" building ecosystem rather than selling models directly. Regulators are engaging, not standing back.

Infrastructure: The Chip Layer

On the hardware side, Nvidia's inference chip market share appears to be risingNvidia’s Share of AI Inference Chip Market Appears to Be Rising - The Information — The Information's reporting suggests this is not just GPU demand but specifically inference workload concentration. Nvidia also accelerated Google DeepMind's DiffusionGemma for local AINVIDIA Accelerates Google DeepMind’s DiffusionGemma for Local AI - HPCwire, indicating the ecosystem lock-in between silicon and foundation model vendors remains tight.

Elon Musk's claim about building a chip 2-3x better than Nvidia at 10% the costElon Musk Says He's Building a Chip '2-3x Better Than Nvidia' at 10% the Cost. Should Nvidia Investors Be Worried? - Yahoo Finance is unverified and comes with obvious competitive incentives to narrative-build. The Yahoo Finance framing ("Should Nvidia Investors Be Worried?") is the right lens: until silicon ships and benchmarks independently, this is a statement, not a data point.

Google's Gemini integration continues to surface friction. Users report Gemini won't enable a Google subscription planI would love a Google subscription plan, but Gemini won't let me - Android Police, and Android Auto integration remains limited despite five published workarounds5 Clever Ways To Use Google Gemini With Android Auto - bgr.com. Neither is a fundamental capability problem, but both signal execution gaps in Google's AI product rollout.

Enterprise AI: Microsoft Opens Its Evaluation Stack

Microsoft open-sourced an AI evaluation framework for enterprise agentsMicrosoft open sources AI evaluation framework for enterprise agents - InfoWorld (InfoWorld). This matters because enterprise agent deployments require reproducible evaluation — the ability to say whether a workflow is actually improving, not just faster in demo conditions. An open evaluation framework lowers the barrier for organizations to instrument their own deployments rather than relying on vendor-supplied benchmarks.

This is the kind of infrastructure move that compounds. When evaluation is standardized and open, vendor lock-in becomes harder to defend on "trust us, it's better" grounds.

What This Week Means

Last week's framing — "integration dividends fading" — pointed to Apple and OpenAI's fraying partnership as the leading indicator. This week's developments extend that signal across three vectors: a competitor (Zhipu) that no longer needs distribution deals to be technically relevant, a regulator (state AGs) that is explicitly timing action to OpenAI's IPO, and a platform player (Anthropic) whose ecosystem story is being stress-tested by the same government whose support it needs.

The technical and commercial signals point in the same direction: the frontier is narrowing. Organizations already committed to a provider should pressure-test their evaluation and switching costs now, not when a contract renewal forces the question.

AI 週報 — 2026-06-11 to 2026-06-18 | 監管、價格戰與中國開源勢力

Yang Goufang — Thu, 18 Jun 2026 00:49:20 +0000

OpenAI 的 burn rate 終於被量化：340 億美元。同一週，多州檢察長聯手調查、Anthropic 遭政府封禁——監管與資金的雙重壓力不再是敘事，而是數字。

OpenAI：burn rate 量化，價格戰信號浮現

金融時報本週揭露 OpenAI 上一會計年度支出達 340 億美元OpenAI spending hit $34bn last year ahead of planned IPO - Financial Times OpenAI spending hit $34 billion last year ahead of planned IPO, FT reports - Reuters，這個數字將過去一年市場對 OpenAI 財務狀況的模糊預期轉化為可計算的事實。同時，The Information 與 CNBC 先後報導 OpenAI 正在評估降價策略以對抗 Anthropic 的市佔成長 OpenAI mulls slashing prices as it competes with Anthropic for users: WSJ - CNBC OpenAI Could Soon Drop Prices To Compete With Anthropic, Report Says - Forbes。

340 億美元的 burn rate 搭配降價壓力，意味著 OpenAI 的變現緊迫性比對外釋出的敘事更尖銳——而多州檢察長的聯合調查（重點在「可能對用戶造成傷害」）State Attorneys General Are Investigating OpenAI - The New York Times OpenAI under investigation by group of state attorneys general, source says - Reuters OpenAI hit with multistate probe into possible user harm as its IPO looms - AP News，為這場資金戰加上了一層無法用公關處理的監理風險。

企業整合進展：Visa 宣布將其安全支付網路直接整合進 ChatGPT Visa and OpenAI integrate Visa's secure global payment directly into ChatGPT - NPR。不同於多數「策略合作」公告，這筆整合有既有的全球網路與合規框架支撐，可商用性較高——是消費級 AI 產品進入金融支付基礎設施的實質進展。

Anthropic：政府封禁與政策急轉彎

美國政府以安全考量為由封禁了 Anthropic 最新版 Claude 模型的使用授權 Why the US government shut down Anthropic’s latest Claude AI model - The Conversation。幾乎同一週，Anthropic 迅速撤回了一項引發內部反彈的政策——此政策原被 WIRED 形容為具有「自毀傾向」，從制定到撤回的時間極短 Anthropic Walks Back Policy That Could Have ‘Sabotaged’ AI Researchers Using Claude - WIRED。

這兩個事件是否相關，文章未提供直接證據；但從時間 close 與政策撤回的速度來看，Anthropic 內部存在即時的自我糾錯機制。真正需要追蹤的是：若政府封禁最終指向「不可部署於政府場景」，Anthropic 的企業銷售將面臨結構性障礙。

中國開源模型：GLM-5.2 在程式碼任務逼近封閉領先者

本週最具技術實質的消息落在中國 Zhipu AI 的 GLM-5.2。

根據 VentureBeat 與 The Decoder 的測試，GLM-5.2 在多項長期程式碼任務的基準上，以六分之一的推論成本達到與 GPT-5.5 相近的表現 Zhipu AI's GLM-5.2 closes in on closed-source leaders in coding marathons - The Decoder Z.ai’s open-weights GLM-5.2 beats GPT-5.5 on multiple long-horizon coding benchmarks for 1/6th the cost - VentureBeat。36Kr 以「AI 程式設計三巨頭成形」為標題，將 Zhipu 與 OpenAI、Anthropic 並列為程式碼能力的第一梯隊 First-hand Test of Zhipu's Most Powerful Model: Are the "Three Giants" of AI Programming Set to Take Shape? - 36 Kr。

這些數據來自模型發布方的內部測試，需等第三方驗證。但若橫向參照多個訊源同時報導此事（成本分析、技術解讀、產業敘事），可信度比單一新聞高。GLM-5.2 的關鍵意涵不是「打敗 GPT」，而是開源模型的性價比曲線正在快速逼近封閉模型。需注意的是：Zhipu 的資料僅涵蓋中國市場應用，其對英文語境與國際開發文化的適配程度仍待實測。

Google：指標式 AI 互動研究與 Gemini 生態擴張

Google DeepMind 本週發表了重新思考滑鼠游標在 AI 時代角色的研究 Google DeepMind is worried about what happens when millions of agents start to interact - MIT Technology Review——對「定址」（pointing）這個人類與介面互動最基礎動作的重新框架。當 AI 能主動預測意圖時，傳統的點選-確認模型是否仍是最佳互動單位？這項研究的戰略意圖在於：定義下一代人機介面的基礎構件。

產品面上，Android Auto 的 Gemini 整合已進入實用階段 5 Clever Ways To Use Google Gemini With Android Auto - bgr.com，但 Android Police 的測試發現 Gemini 訂閱機制存在使用障礙 I would love a Google subscription plan, but Gemini won't let me - Android Police——模型能力與 distribution 執行之間仍有落差。

Nvidia：硬體廠商的護城河持續拓寬

市佔消息：The Information 報導 Nvidia 在 AI 推論晶片市場的占比正在持續上升Nvidia’s Share of AI Inference Chip Market Appears to Be Rising - The Information。訓練市場已相對穩定，推論市場的高成長才剛開始——Nvidia 在推論端的軟體生態（CUDA、Triton）與供應鏈韌性讓後進者很難在性價比上取勝。

合作消息：Nvidia 宣布加速 Google DeepMind 的 DiffusionGemma 模型在本地 AI 場景的執行 NVIDIA Accelerates Google DeepMind’s DiffusionGemma for Local AI - HPCwire，同時強化了 Nvidia 對開源模型的軟體優化支援，以及 Google 對本地部署（on-device）場景的認真程度。

340 億美元 burn rate 的量化、OpenAI 降價壓力浮現、Anthropic 遭遇政府封禁——本週的核心不是任何單一事件，而是監理與資金的雙重量化正將 AI 公司的真實體質攤在陽光下。同時，GLM-5.2 以六分之一成本逼近封閉模型領先者，顯示開源性價比曲線正在縮短與封閉模型的差距。技術發布的領先與商業價值的捕獲之間，鴻溝正在擴大。