# Knowledge Discovery — 2026-04-16

> RSS Scout: 151/151 源 → 2515 条新条目 → GPT-5.4 粗筛 1243 条（≥8 分）→ 去重 1165 → Top-60 → Claude 精筛 15 篇深度抓取

## 本日主题

**Context Engineering 的范式固化**：七位顶级作者（Anthropic 工程团队、Martin Fowler、Addy Osmani、Sebastian Raschka、Simon Willison、Kief Morris、TWIML Filip Kozera）在同一周内从不同角度给出同一结论——coding agent 的瓶颈已经从"模型能力"迁移到"上下文工程 + 验证工程 + harness 工程"三件套。这是一个 **范式收敛信号**，值得系统性对齐 VibeGuard 体系。

---

## 产出清单

| 类型 | 项 | 位置 |
|------|-----|------|
| 新增规则 | W-16 验证命令时效性 | `workflow.md`（补入 W-15 后） |
| 新增规则 | U-32 规则过载阈值 | `coding-style.md` |
| 新增规则 | SEC-12 MCP 工具描述静默变更 | `security.md` |
| 知识摘要 | 15 篇深度分析 | 本文件 |

说明：按「简单优先」原则，今日识别的 3 条新规则都有至少 2 篇独立来源支持（非单点发现），其他发现保持为知识摘要。

---

## 15 篇深度分析（按 VibeGuard 契合度排序）

### 1. Anthropic: Claude Code Best Practices（20 分）
- **来源**: https://code.claude.com/docs/en/best-practices
- **核心**: 官方正式发布的 Claude Code 最佳实践指南。
- **关键洞察（Insight Card）**:
  > **[旧共识]** 验证是交付后的清理步骤 vs **[新发现]** "Give Claude a way to verify its work — This is the **single highest-leverage** thing you can do"（给 Claude 验证能力是你能做的**最高杠杆**的一件事）
- **可操作建议**: 每个任务的 prompt 必须包含验证路径（tests/screenshots/expected outputs），否则 agent 没有反馈回路，"every mistake requires your attention"
- **VG 关联**: 验证 W-03（验证后才能声称完成）。官方措辞"single highest-leverage"可以作为 W-03 在 CLAUDE.md 中的权威引用来源。

### 2. Anthropic: Effective Context Engineering for AI Agents（20 分）
- **来源**: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- **核心**: Anthropic 官方给出四大 context engineering 配方。
- **关键洞察**:
  > **[旧共识]** 大上下文窗口 = 更好性能 vs **[新发现]** "Context rot under scale: model precision degrades with longer sequences despite architectural mitigations"（精度随序列长度退化）
- **可操作建议**:
  - Compaction：压缩会话历史，保留架构决策 + 最近 5 个访问文件
  - Just-In-Time Retrieval：保留 file path 等轻量标识符，按需动态加载而非预载
  - Sub-Agent：专门子代理用独立 context 返回 1k-2k token 摘要
  - 调参顺序：先优化召回（recall），再优化精度（precision）
- **VG 关联**: Compaction 必保留清单（L1-L7 中的 `/clear` 约束）与官方"5 most recently accessed files"一致，可互相引用。

### 3. Anthropic: Code Execution with MCP（20 分）
- **来源**: https://www.anthropic.com/engineering/code-execution-with-mcp
- **核心**: 将 MCP servers 作为 code API 而非直接工具调用。
- **关键洞察**:
  > **[旧共识]** MCP 工具越多越方便 vs **[新发现]** 150,000 → 2,000 token（98.7% 降低）。代码执行层过滤中间结果（10,000 行 → 5 行），只把必要数据回传模型。
- **可操作建议**:
  - MCP 工具按需从 `./servers/` 文件系统发现，而非启动时全部加载到 context
  - 隐私优势：PII 可在执行环境自动 tokenize，不进入模型上下文
  - 代价：需要 sandbox + 资源限制
- **VG 关联**: 这是 VibeGuard MCP 相关规则的**架构级新方向**。当前体系无此角度，值得长期跟进。

### 4. Martin Fowler: Harness Engineering（20 分）
- **来源**: https://martinfowler.com/articles/harness-engineering.html
- **核心**: "Agent = Model + Harness"。Harness = Guides（feedforward）+ Sensors（feedback）。
- **关键洞察**:
  > **[旧共识]** 质量靠 code review（反馈型） vs **[新发现]** Feedback-only 重复相同错误，feedforward-only 规则从未验证。**两个方向都必须**。
- **可操作建议**:
  - Guides = 文档、规则、LSP 集成（行动前引导）
  - Sensors = linter、test、review agent（行动后自检）
  - 检查应分两类：Computational（确定、快，test/linter/type-check）vs Inferential（语义、非确定，LLM review）
- **VG 关联**: VibeGuard 本身就是典型 harness。当前规则偏 feedforward 强（L1-L7 规则），sensor 维度较弱（仅 guards 脚本）。可对齐 Fowler 框架审视 VibeGuard 的 sensor 覆盖度。

### 5. Martin Fowler: Context Engineering for Coding Agents（20 分）
- **来源**: https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html
- **核心**: Context engineering = 策划模型看到什么。
- **关键洞察**:
  > **[旧共识]** 用"确保 X"、"永远不能 Y"的绝对化语言写规则 vs **[新发现]** **"Illusion of Control" 反模式** — LLM 本质概率性，绝对化语言制造虚假保证
- **可操作建议**:
  - Path-based scoping：`*.ts` 规则只在 TS 文件生效，避免全局膨胀
  - Instructions（任务性）vs Guidance（约定性）分开管理
  - 反对 copy-paste 规则集（风险：无意的冲突、低意识的内容、责怪 agent）
- **VG 关联**: 直接指出 VibeGuard 规则应审视是否有过量绝对化语言。→ 规则 U-32（规则过载阈值）的论据之一。

### 6. Addy Osmani: Context Engineering: Bringing Engineering Discipline to Prompts（20 分）
- **来源**: https://addyo.substack.com/p/context-engineering-bringing-engineering
- **核心**: 从"写好 prompt"到"构建完整信息环境"的范式迁移。
- **关键洞察**:
  > **[旧共识]** "What prompt will get the AI to do this?" vs **[新发现]** "What complete information environment must I construct so the AI can reliably succeed?"
- **可操作建议**: 组装 context 工作流：retrieve → label（"Relevant documentation:"）→ 分层合并（instructional / knowledge / tools）→ 长会话用压缩摘要替换完整历史
- **VG 关联**: 与 Anthropic 官方配方一致，三源独立印证 context rot 的存在。

### 7. Addy Osmani: The 80% Problem in Agentic Coding（19 分）
- **来源**: https://addyo.substack.com/p/the-80-problem-in-agentic-coding
- **核心**: Agent 能快速做到 80%，但最后 20% 需要不成比例的人工投入。
- **关键洞察**:
  > **[旧共识]** AI 加速编码 vs **[新发现]** **Comprehension Debt（理解债）**：生成速度 > 理解速度，导致"rubber stamping"（走过场审查）— "trivially easy to review code you can no longer write from scratch"
- **可操作建议**: 70% 精力花在定义 success criteria + test + 需求上，让 agent 导航实现细节；拒绝 "one more prompt" 循环
- **VG 关联**: 与 W-02（连续失败 3 次必须后退）互补——"one more prompt"就是循环反模式。

### 8. Addy Osmani: Trust, But Verify Pattern（19 分）
- **来源**: https://addyo.substack.com/p/the-trust-but-verify-pattern-for
- **核心**: "Blind trust in AI-generated code is a vulnerability."
- **关键洞察**:
  > **[旧共识]** AI 幻觉 = 写错代码 vs **[新发现]** **Slopsquatting**：AI 幻觉出不存在的包名 → 恶意方抢注 → 安装即感染（供应链攻击新向量）
- **可操作建议**: Verification budget 作为一等公民，SAST/fuzz/peer-review 分层
- **VG 关联**: 直接强化 SEC-11 的必要性；slopsquatting 可能值得新增 SEC 规则（待验证真实事件数据）。

### 9. Addy Osmani: How to Write a Good Spec for AI Agents（20 分）
- **来源**: https://addyo.substack.com/p/how-to-write-a-good-spec-for-ai-agents
- **核心**: Spec 六大要素 + 三层边界系统。
- **关键洞察**:
  > **[旧共识]** 规则越详细越好 vs **[新发现]** **Curse of Instructions**：10 条规则比 5 条规则遵守度更低（研究数据）
- **可操作建议**:
  - Spec 六要素：Commands / Testing / Structure / Code Style / Git Workflow / Boundaries
  - 三层边界：`✅ Always do` / `⚠️ Ask first` / `🚫 Never do`
- **VG 关联**: 与 /vibeguard:interview 产出的 SPEC 对齐；三层边界可直接用于 VibeGuard 规则分类。**→ 新规则 U-32 的最强支撑**。

### 10. Sebastian Raschka: Components of A Coding Agent（20 分）
- **来源**: https://magazine.sebastianraschka.com/p/components-of-a-coding-agent
- **核心**: Coding agent 六大组件。
- **关键洞察**:
  > **[旧共识]** 幻觉是模型质量问题 vs **[新发现]** "A lot of apparent **'model quality' is really context quality**"
- **可操作建议**: 六大组件 = Live Repo Context / Prompt Caching / Structured Tool Interface / Context Reduction / Dual-Layer Memory / Bounded Subagents
- **VG 关联**: Prompt prefix cache rigidity（缓存僵化）是一个新风险，VibeGuard 暂无对应规则。

### 11. Simon Willison: MCP Prompt Injection Security（20 分）
- **来源**: https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/
- **核心**: MCP 的五类注入攻击面。
- **关键洞察**:
  > **[旧共识]** MCP 工具认证 = 安全 vs **[新发现]** **Rug Pulls / Silent Redefinition**：MCP 工具可在安装后静默改写自己的描述（=LLM 看到的指令），重定向 API key 或行为
- **可操作建议**:
  - 客户端：初装时固定 tool 描述的 hash，后续变更触发用户确认
  - 跨 server 屏蔽：防止恶意 server 拦截对可信 server 的调用
- **VG 关联**: **→ 新规则 SEC-12（MCP 工具描述静默变更）的直接依据**。

### 12. Martin Fowler: Context Anchoring（19 分）
- **来源**: https://martinfowler.com/articles/reduce-friction-ai/context-anchoring.html
- **核心**: 将决策/约束/原因外化为 <50 行 living document，而非寄存在对话。
- **关键洞察**:
  > **[旧共识]** 会话是记录 vs **[新发现]** "**The reasoning behind decisions degrades faster than the decisions themselves**"——AI 会技术上遵守决策，但违反决策原意
- **可操作建议**:
  - 单会话 <1h：跳过
  - 跨日/多开发者：全量文档（decisions / constraints / open questions / state）
  - 判断标准："Can I close this session and start fresh without anxiety?"
- **VG 关联**: 与 VibeGuard 的 exec-plan 设计同构；可作为 context-anchoring skill 的候选。

### 13. Martin Fowler: Humans and Agents in Software Engineering Loops（19 分）
- **来源**: https://martinfowler.com/articles/exploring-gen-ai/humans-and-agents.html
- **核心**: 三位置框架：Outside / In / **On** the Loop。
- **关键洞察**:
  > **[旧共识]** 人在环中逐行审查代码 vs **[新发现]** 人应"**On the Loop**"设计 harness，不是"In the Loop"检查每行代码——"agents generate faster than humans can manually inspect"
- **可操作建议**: 人角色迁移为 **loop architect**，不是 code inspector。监控 agent 自改进建议的质量和安全性。
- **VG 关联**: VibeGuard = on-the-loop 工具的典型例子。harness 成为 agent 的可调上限。

### 14. TWIML Podcast: Context Engineering with Filip Kozera（20 分）
- **来源**: https://twimlai.com/podcast/twimlai/context-engineering-for-productive-ai-agents/
- **核心**: （播客形式，未深度抓取内容）podcast 与前述主题一致。
- **VG 关联**: 第四源印证 context engineering 正在成为独立学科。

### 15. Addy Osmani: My LLM Coding Workflow Going into 2026（20 分）
- **来源**: https://addyo.substack.com/p/my-llm-coding-workflow-going-into
- **核心**: 2026 年 4 阶段工作流 — Spec / 迭代小块 / Context 供给 / 模型切换。
- **关键洞察**:
  > **[旧共识]** AI 替代工程技能 vs **[新发现]** **AI 放大既有专业性**——"LLMs reward classic engineering practices (clear specs, solid tests, code reviews)"
- **可操作建议**:
  - Context7 / gitingest / repo2txt 打包代码库进 context
  - Granular commits = "save points in a game"（回滚无痛）
  - Conductor 并行 3-4 agent 但心理负担大；1 主 + 1 reviewer 是常态
- **VG 关联**: 验证 spec-first 方向；与 /vibeguard:exec-plan 对齐。

---

## Bridge Notes（跨条目关联）

### Bridge 1 (强关联): Context Rot 四源印证 ≡ VibeGuard 可加"context 噪声监测"
- **连接**: Raschka"context bloat as silent killer" + Addy"context rot" + Anthropic"context rot under scale" + Fowler"context bloat risk" **都指向同一原理**
- **If then**: 如果 context 噪声随时间指数积累 → VibeGuard 可以加量化监测 guard（同文件读 ≥N 次触发告警，建议 `/clear`）
- **置信度**: 强关联

### Bridge 2 (强关联): Verification 是瓶颈 ≡ W-03 需要补强为"引用命令必须新鲜"
- **连接**: Anthropic"verification = highest leverage" + Addy"80% problem" + Addy"Trust-Verify" + Fowler"sensor-only/feedforward-only 均失败" **四源一致**
- **If then**: 如果 verification 是交付瓶颈 → 每次"已修复/已完成"声称必须引用**本次会话的**命令输出（不能引用记忆、不能引用"之前跑过了"）
- **置信度**: 强关联 → **产出为 W-16**

### Bridge 3 (强关联): 规则过载反比遵守度 ≡ VibeGuard 需要审视规则条数
- **连接**: Addy"curse of instructions（10 条 < 5 条遵守度）" + Anthropic"bloated CLAUDE.md = ignored rules" + Fowler"illusion of control + context bloat" **三源一致**
- **If then**: 如果规则过量 → 违反 Addy 数据（5-10 条临界）。VibeGuard 当前 105 条需路径作用域化（per-file-type scoping），避免全局膨胀
- **置信度**: 强关联 → **产出为 U-32**

### Bridge 4 (强关联): MCP 工具描述 = 攻击面 ≡ 新增 SEC-12
- **连接**: Willison"Rug Pulls / Silent Redefinition" + Anthropic"code execution with MCP 提供隐私优势，但未解决信任问题" **两源独立**
- **If then**: 如果 MCP 工具描述可静默变更 → 客户端必须 hash 校验 + 用户确认
- **置信度**: 强关联 → **产出为 SEC-12**

### Bridge 5 (强关联): Harness = On-the-Loop ≡ VibeGuard 自我定位
- **连接**: Fowler humans-and-agents "On the Loop" + Fowler harness engineering（Guides + Sensors 双通道）
- **If then**: 如果 VibeGuard 是 harness → 应补全 sensor 维度，当前过度倾向 feedforward 规则。审视 `guards/` 覆盖度
- **置信度**: 强关联（项目级改进方向，非单条规则）

### Bridge 6 (可能关联): Spec-first + Context Anchoring + Explore→Plan→Code = 同一模式
- **连接**: Addy spec 六要素 + Fowler Context Anchoring + Anthropic explore→plan→code→commit + Raschka Live Repo Context
- **If then**: 如果都指向"前置 context 固化"→ 可抽象 skill: **context-anchor-doc**（会话开始时固化 <50 行决策文档）
- **置信度**: 可能关联（建议后续 skill 化，今日不产出）

### Bridge 7 (待验证): Prompt Prefix Cache 与动态 context 的冲突
- **连接**: Raschka"prompt prefix cache rigidity" + Fowler"determinism gaps — 不确定 context 是否按预期加载"
- **If then**: 如果前缀缓存 vs 动态工作区状态冲突 → 缓存失效策略需与 git branch / 工作区变更绑定
- **置信度**: 待验证（Raschka 单源，需要实测 Claude Code 的缓存行为）

---

## 未直接产出但值得跟踪的方向

1. **Slopsquatting 供应链攻击**：幻觉包名 → 攻击者抢注恶意包（Addy, 仅 1 源，需实证数据补充）
2. **MCP 作为 code API 而非 tool API**：Anthropic 提出的新架构，会影响 VibeGuard MCP 相关规则未来走向
3. **Agentic Flywheel**：Fowler 提出 agent 可自评并推荐 harness 改进，高置信度自动采纳。VibeGuard 的 `vibeguard:learn` 已有雏形，可参考 Fowler 框架系统化
4. **Bounded Subagent 泄漏**：Raschka 提到"权限过宽的 subprocess access 会重新引入风险"，对 VibeGuard W-14（并行 Agent 文件所有权）互补
5. **Prompt Prefix Cache 失效**：新维度，值得后续专题研究

---

## 下一步

- 本次新增 3 条规则（W-16 / U-32 / SEC-12）需要在使用中观察误报率
- Bridge 5（VibeGuard sensor 维度）需要独立会话审视 `guards/` 覆盖度
- Bridge 7 需要实测验证后才能产出规则

---

# 附录：≥20 分深度补抓 16 篇（数据驱动加深）

> 用户要求"分数高就全要"。在 ≥20 分 52 条中，对剩余 41 条筛掉 13 条低密度后（GH version notes / dup URL / AINews 综合），尝试抓 28 条，5 篇被反爬（OpenAI/VentureBeat/TheNewStack 域名 403/429），实际成功 16 篇，加上首轮 15 篇，本日深度分析共 **31 篇**。

## 16 篇补抓概要

### 16. Swyx: Cognition / The Devin is in the Details（20 分）
- **来源**: https://www.swyx.io/cognition
- **关键洞察**:
  > **[新发现]** "Code AGI in 20% of full AGI time, capture 80% of value" — 代码 AGI 帕累托原理。代码可验证 + 可递归 dogfood，比通用 AGI 走得快
- **数据点**: Devin ARR 从 $1M → $73M, 正利润运营, 单银行客户 $1.5M → $10M+
- **三角模式**: Sync (Windsurf IDE) + Async (Devin Slack) + 定价
- **VG 关联**: "remaining 10% details" 与 W-16（验证新鲜度）+ Addy 80% problem 同构

### 17. Addy Osmani: The Reality of AI-Assisted Software Engineering Productivity（20 分）
- **来源**: https://addyo.substack.com/p/the-reality-of-ai-assisted-software
- **关键洞察（数据驱动反直觉）**:
  > **[旧共识]** AI 加速所有人 vs **[新发现]** **经验工程师在复杂遗留代码上反而慢 19%**（METR study）
- **重要数据**:
  - 84% 用 AI，但仅 60% 看好（2023 还是 70%）
  - 46% 不信任 AI 准确性，66% 说"差不多正确"是最大时间杀手
  - Google RCT: ~21% 任务加速；初级 35-39% vs 高级 8-16%
  - 75% 用 AI，大多数组织无 measurable 性能提升
  - **PR 体积 +98%，但 review 时间 +91%**（Amdahl's Law）
  - bug 率 +9%
  - 开发者高估 AI 帮助 20%（过度自信偏差）
- **VG 关联**: 强支持 W-16 + U-32；与 Addy Trust-Verify 互补

### 18. Addy Osmani: Coding for the Future Agentic World（20 分）
- **来源**: https://addyo.substack.com/p/coding-for-the-future-agentic-world
- **关键洞察**:
  > **[新发现]** Agent 的代码喜恶清单：模块化/清晰边界/TDD/git worktree → 奖励；单体/紧耦合/直 push main/隐式约定 → 惩罚
- **可操作建议**: TDD 风格用作 agent guardrail；git worktree per task；instructions.md 文档化所有架构决策
- **VG 关联**: 与 U-26（声明-执行完整性）互补——agent 时代代码组织本身就是 affordance

### 19. Latent Space: Claude Code Source Leak Insights（20 分）
- **来源**: https://www.latent.space/p/ainews-the-claude-code-source-leak
- **关键洞察**:
  > **[新发现]** Claude Code 三层记忆架构：MEMORY.md 索引 + 按需主题文件 + 完整会话；**"autoDream"** 模式在睡眠时合并记忆/去重/解决矛盾
- **架构细节**:
  - 默认 ~20 工具，可扩展到 60+
  - KV 缓存 + prompt 缓存让 subagent fork-merge"基本免费"——共享完整上下文无需重复工作
  - 5 层权限 + 2 种 plan 模式
  - 5 种压缩类型，含语义去重 + 矛盾修复
- **VG 关联**: VibeGuard MEMORY.md 设计直接对齐三层模式；可参考 autoDream 设计 `/vibeguard:gc` 增强版

### 20. Eugene Yan: News Agents with MCP+Q+tmux（20 分）
- **来源**: https://eugeneyan.com/writing/news-agents/
- **关键洞察**:
  > **[新发现]** **远程 MCP 部署"isn't trivial"** — Eugene 原想部署到 web，最终放弃只支持本地 CLI
- **架构细节**:
  - 主-副 agent 模式：主 agent 分 feeds.txt 为 3 chunk，tmux 3 子 agent 并行
  - 所有 MCP 工具默认 "not trusted"，需用户授权
  - 暗示未来用 LLM 替代硬编码 RSS parser（"reliably and cheaply"）
- **VG 关联**: 与 SEC-12（MCP 工具描述静默变更）互补——"not trusted by default" 是好的安全默认

### 21. Addy Osmani: Is the IDE Dead?（20 分）
- **来源**: https://addyo.substack.com/p/death-of-the-ide
- **关键洞察**:
  > **[新发现]** IDE 不是死，是 **被 de-centered**：从 "open → edit → build → debug" 转到 "specify intent → delegate → observe → review diffs → merge"
- **新瓶颈**: 12 个并行 agent = 12 个 diff 等 review → review fatigue 成首要 bottleneck
- **建议**: 工具构建者优化 control plane 和 review surface，不是 text editor
- **VG 关联**: 直接强化 W-16（验证瓶颈）+ U-32（review fatigue 数据驱动）

### 22. Addy Osmani: Conductors to Orchestrators（20 分）
- **来源**: https://addyo.substack.com/p/conductors-to-orchestrators-the-future
- **核心**: Conductor（同步、单 agent、像 GPS 验证每步）→ Orchestrator（异步、多 agent、像管理团队）
- **关键差异**: Orchestrator 产物是 git artifacts（branches/commits/PRs），可追溯；Conductor 是 IDE 内 ephemeral 对话
- **职业建议**: 高级工程师应早期采纳 orchestrator 工作流。"engineering roles shift from implementer to manager"
- **VG 关联**: 与 Fowler "humans on the loop" 同构

### 23. Martin Fowler: Harness Engineering（Birgitta Böckeler）（20 分）
- **来源**: https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html
- **关键洞察**:
  > **[新发现]** 三类 harness 分层：**Maintainability harness**（linter/test/review）、**Architecture fitness harness**（fitness function）、**Behaviour harness（最弱）**——后者依赖功能 spec + 测试，效果有限
- **重要悖论**: "**Misdiagnosis 与 overengineering 谁都抓不到**"——computational + inferential sensor 都失败，必须靠更好的初始 spec 上游解决
- **概念**: **Harnessability** — 强类型语言 + 清晰边界提供 "ambient affordances"，遗留系统是"最需要 harness 但最难做 harness"的悖论
- **VG 关联**: 解释为什么 VibeGuard 的 sensor 维度需要补强——current 偏 feedforward

### 24. Zvi Mowshowitz: Claude Code Auto Mode #7（20 分）
- **来源**: https://thezvi.substack.com/p/claude-code-codex-and-agentic-coding
- **关键洞察**:
  > **[新发现]** **Permission fatigue 是真实威胁**——93% approval rate 暴露用户在 rubber stamp。Auto Mode 7% 拒绝率 + 17% false negative 比 100% click-yes 用户更安全
- **对比数据**: Codex 3M 周用户、免费层、50% 图像压缩；Claude Code lazy-cheater 模型、parallel sessions
- **insight**: Anthropic 终止覆盖 OpenClaw 第三方工具 = compute scarcity 战胜 subscription economics
- **VG 关联**: rubber stamping 与 Addy 80% problem 同源——少而智能的 gate > 多而机械的 gate

### 25. Martin Fowler: Spec-Driven Development 三工具评测（20 分）
- **来源**: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
- **关键洞察**:
  > **[新发现]** **Spec-as-source 像失败的 Model-Driven Development**——"组合了 inflexibility 与 non-determinism"
- **三工具评级**:
  - Kiro: 简单但笨重，小 bug 变 4 user story + 16 验收标准（"sledgehammer to crack a nut"）
  - Spec-Kit (GitHub): 评审负担重，agent 忽略 research notes、重复已有代码
  - Tessl: 唯一探索 spec-anchored 和 spec-as-source，但 non-deterministic
- **核心警告**: 详尽 spec 也会被 agent 忽略或过度热情遵循（**false control illusion**）
- **VG 关联**: VibeGuard `/vibeguard:exec-plan` 设计需要审视，是否在重蹈 MDD 覆辙

### 26. Zvi Mowshowitz: Cowork & Codex #6（20 分）
- **来源**: https://thezvi.substack.com/p/claude-code-cowork-and-codex-6-claude
- **关键洞察**: Claude Cowork 全 computer use（鼠标/键盘/屏幕），可 use any app；Dispatch 支持手机远程操作
- **安全警告**: 用户可能忽略安全警告——避免在 default Chrome / 邮件客户端运行
- **VG 关联**: 强化 SEC-11/SEC-12 的 agent 安全审视范围

### 27. Pragmatic Engineer: DHH's New Way of Writing Code（20 分）
- **来源**: https://newsletter.pragmaticengineer.com/p/dhhs-new-way-of-writing-code
- **关键洞察**:
  > **[新发现]** DHH（6 个月前还反对 AI）现在 tmux 同跑：Gemini 2.5（快）+ Opus（强）+ NeoVim/Lazygit（review diff）。"几乎不再手写代码""wearing a mech suit"
- **生态信号**: Rails 因 AI 复兴——token 高效、内置 testing 框架
- **政策**: Amazon 已禁止初级开发者未审 ship agent 代码
- **VG 关联**: 高级工程师 + AI = mech suit；初级仍需 guardrail（与 Addy 数据矛盾解决：测速 vs 测业务价值）

### 28. Pragmatic Engineer: Building Claude Code with Boris Cherny（20 分）
- **来源**: https://newsletter.pragmaticengineer.com/p/building-claude-code-with-boris-cherny
- **关键洞察**:
  > **[新发现]** Boris 个人每天 **20-30 PR**——靠"5 个终端 5 个平行 Claude 实例"。工作流：plan mode → iterate → 实现"几乎一次成功"
- **设计哲学**:
  - 无 PRD，"建立数十个 prototype 才推出功能"
  - **search = glob + grep**（model-driven），超越 vector DB（启发：Instagram 工程师"点击 def 失败时怎么搜"的实际行为）
  - "Fix infrastructure first"——破损 typechecker 时不该 ship feature，应停下修工具
- **数据**: Boris 在 Meta 因果分析"clean codebase → 双位数生产力提升"
- **VG 关联**: VibeGuard "fix build first" (U-25) 来自类似洞察

### 29. Google: Colab MCP Server（20 分）
- **来源**: https://developers.googleblog.com/announcing-the-colab-mcp-server-...
- **核心**: AI agent 通过 MCP 直接控制 Colab notebook：cell 管理、代码执行、依赖管理。"Colab as a service"
- **VG 关联**: MCP 生态扩张，SEC-12 适用范围进一步扩大

### 30. ByteByteGo: 12 Claude Code Features（20 分）
- **来源**: https://blog.bytebytego.com/p/ep209-12-claude-code-features-every
- **核心**: CLAUDE.md / Permissions / Plan Mode / Checkpoints / Skills / Hooks / MCP / Plugins / Context / Slash Commands / Compaction / Subagents
- **Power-user pattern**: CLAUDE.md + Skills 持久知识；Plan Mode + Checkpoints 安全执行
- **VG 关联**: 已知特性集合，无新洞察

### 31. Cursor: Shadow Workspace（20 分）
- **来源**: https://cursor.com/blog/shadow-workspace
- **关键洞察**:
  > **[新发现]** **Rust 失败模式**——rust-analyzer 必须写盘才能 lint，shadow workspace 的虚拟文件系统层无效
- **架构**:
  - 隐藏 Electron 窗口 + gRPC IPC
  - 15 分钟超时 + 跨请求复用（"利用 AI 可无限 pause 不感知延迟"）
  - 内存翻倍代价
- **未来限制**: macOS/Windows 无 kernel-level 文件代理（FUSE Linux only），"runnability + isolation" 在桌面平台仍未解
- **VG 关联**: agent 工具的平台特异性 → VibeGuard rules per-language scope（U-32）的硬证据

## 反爬失败的 5 篇（数据可观测但不可访问）
- OpenAI 域名 ×2（Harness Engineering / Agents SDK 演进）：403
- VentureBeat 域名 ×2（Goose vs Claude Code / 创建者 workflow）：429
- TheNewStack 域名 ×3（Personal software / Overnight Routines / Cursor 融合）：403

这些条目仍按 GPT 摘要进入 Notion 日报，但深度分析缺失。下次可改用 archive.org 或 reader 类代理重试。

## 新增 Bridge Notes（基于补抓 16 篇）

### Bridge 8 (强关联): Permission/Review Fatigue 跨三源印证
- **连接**: Zvi Auto Mode "93% approval rate = rubber stamp" + Addy 80% problem "review of code you can't write" + Addy IDE Death "review fatigue 是新 bottleneck"
- **If then**: 多 gate 不是更安全，**少而智能的 gate** 更安全（人类不会真审查每条命令）
- **置信度**: 强关联（与 W-16 互补——验证强制要求与 fatigue 之间的张力）

### Bridge 9 (强关联): Codebase 质量是 Agent 化前提投资（4 源）
- **连接**: Boris Cherny "clean codebase → 双位数生产力" + Fowler "harnessability" + Addy reality "经验工程师在 legacy 反慢 19%" + Addy agentic "模块化/紧耦合"奖惩清单
- **If then**: 想用 agent 加速 → 必须先重构遗留代码到 agent-friendly。**"先修工具再 ship feature"**（U-25 同源）
- **置信度**: 强关联

### Bridge 10 (强关联): Senior vs Junior 收益悖论
- **连接**: Addy reality "初级 35-39% vs 高级 8-16%" + DHH/Boris/Amazon "高级工程师收益更大、初级需 guardrail"
- **解决**: Addy 测的是**任务速度**（surface），DHH/Amazon 测的是**业务价值**（substantive）。同一现象的两个测度
- **VG 关联**: 解释为什么 VibeGuard 对初级用户应更严（multi-gate），对高级用户应更松（auto mode）

### Bridge 11 (强关联): Code Volume × Review Time = Amdahl's Law 新瓶颈
- **连接**: Addy reality "PR +98% / review +91%" + Addy IDE Death "review fatigue" + Boris "20-30 PR/day"
- **If then**: 个人产出 → 团队 review 不一定能 scale。VibeGuard 的 review skill (`/vibeguard:review`) 应优先支持快速三角化（pinpoint 关键 risk 点），而非全量审查
- **置信度**: 强关联

### Bridge 12 (待验证): Spec-as-Source 是失败的 MDD 重演
- **连接**: Fowler SDD-3-tools "spec-as-source 像失败的 MDD" + Addy spec "curse of instructions"
- **风险**: VibeGuard `/vibeguard:exec-plan` 是否在重蹈 MDD 覆辙？需要审视：是否在让 spec 替代代码而非引导代码
- **置信度**: 待验证（Fowler 单源警告，但权威人，需要内部审视）
