规范驱动开发（Spec-Driven Development）：一个批判性审视

摘要：规范驱动开发（SDD）是2025年AI辅助编码领域涌现的方法论，主张"先写规范，规范驱动AI生成代码"。本文基于对12个一手来源的交叉验证分析，系统考察SDD的定义边界、历史渊源、工具生态、实证证据与核心争议。研究发现：SDD的核心理念（spec-first）具有理论合理性，但术语存在严重的语义扩散；当前工具在实际使用中面临可用性瓶颈；且尚无对照实验证明SDD优于"普通AI辅助编码"。本文采取审慎乐观的立场，区分"已验证的事实"与"合理但未经证实的推论"，为研究者和实践者提供一份基于证据的参考框架。

关键词：规范驱动开发、Spec-Driven Development、AI辅助编码、Vibe Coding、模型驱动工程、软件工程方法论

目录

  1. 引言：问题的提出
  2. 定义与概念边界
  3. 历史脉络：从MDD到SDD
  4. 对照物：Vibe Coding与无约束AI生成的实证问题
  5. 方法论定位：SDD与TDD/BDD/DDD的关系
  6. 规范格式与代码生成基础设施
  7. 三大SDD工具的设计哲学与独立评测
  8. 实证证据与证据缺口分析
  9. 系统性批评与反驳
  10. 开放问题与未来研究方向
  11. 结论与审慎建议
  12. 参考文献

1. 引言：问题的提出

2025年，AI编码工具（Cursor、GitHub Copilot、Claude Code等）的能力突破了一个临界点：从"行级补全"跃升为"全功能实现"。这一跃升带来了两种截然相反的实践倾向：

倾向一：Vibe Coding——“完全交给AI，不审查代码”（Karpathy, 20251）

倾向二：Spec-Driven Development——“先写结构化规范，让AI在约束内工作”（GitHub, 20252；Amazon Kiro, 20253）

本文的核心研究问题是：

SDD作为一种新兴方法论，其理论基础是否坚实？实证证据是否支持其宣称的价值？其适用边界在哪里？

本文不预设立场，而是通过多源交叉验证、反方意见的系统整合、以及对证据质量的严格审查，力求提供一份可被质疑、可被反驳、但论证过程透明的分析报告。

1.1 研究方法与来源说明

本文分析基于以下主要来源：

类别来源可信度评级
独立学术/准学术METR RCT研究4、arXiv论文5⭐⭐⭐⭐⭐
独立专家评测Birgitta Böckeler (Thoughtworks)6⭐⭐⭐⭐⭐
行业雷达Thoughtworks Technology Radar Vol.347⭐⭐⭐⭐⭐
一手技术文档（有利益相关）GitHub Blog2、Spec Kit文档8、Kiro3⭐⭐⭐⭐
商业推广Specmatic9、TypeSpec10⭐⭐⭐

关键方法论原则：

  • 每个核心断言至少2个独立来源交叉验证
  • 区分"事实陈述"与"观点表达"
  • 工具官方的宣传数据标注为"官方宣称，缺乏独立验证"
  • 对推理性结论明确标注"推论"

2. 定义与概念边界

2.1 多源定义对比

目前对SDD的定义尚未形成共识。以下是来自不同权威来源的原始定义：

定义A（Birgitta Böckeler, Thoughtworks, 2025年10月6）：

“Spec-driven development means writing a ‘spec’ before writing code with AI (‘documentation first’). The spec becomes the source of truth for the human and the AI.”

定义B（GitHub Spec Kit 哲学文档8）：

“SDD inverts this power structure. Specifications don’t serve code—code serves specifications. The Product Requirements Document (PRD) isn’t a guide for implementation; it’s the source that generates implementation.”

定义C（Tessl Framework，引自Böckeler6）：

“A development approach where specs — not code — are the primary artifact. Specs describe intent in structured, testable language, and agents generate code to match them.”

定义D（Thoughtworks Technology Radar, 2025年11月7）：

“An emerging approach to AI-assisted coding workflows… workflows that begin with a structured functional specification, then proceed through multiple steps to break it down into smaller pieces, solutions and tasks.”

2.2 定义的共同核心与分歧点

共同核心（所有定义一致）：

  1. 先写规范，后写代码
  2. 规范成为某种形式的"事实源"（source of truth）
  3. AI参与从规范到代码的转化

关键分歧：

分歧维度保守立场（Böckeler/技术雷达）激进立场（Spec Kit/Tessl）
规范的生命周期可以是一次性的（spec-first）必须长期维护（spec-anchored/spec-as-source）
代码的地位代码仍然重要，需要审查代码是"最后一公里"，可以不再直接编辑
AI的角色辅助工具执行引擎（规范→代码完全自动化）

2.3 "语义扩散"警告

Böckeler明确警告6：

“The term ‘spec-driven development’ isn’t very well defined yet, and it’s already semantically diffused. I’ve even recently heard people use ‘spec’ basically as a synonym for ‘detailed prompt’.”

Thoughtworks技术雷达独立确认7：

“While the term’s definition is still evolving…”

读者应警惕的常见混淆：

  • “Spec-driven” ≠ “Contract-first”（后者专指机器可读的API规范，如OpenAPI）
  • “Spec” ≠ “Detailed prompt”（前者是结构化的持久工件，后者是即时输入）
  • “Spec-driven” ≠ “Documentation-first”（前者的规范面向AI消费，后者面向人类阅读）

2.4 SDD的三个层级模型

Böckeler提出的三层模型6是当前最清晰的概念框架：

层级名称特征代表工具风险递增
Level 1Spec-first为任务编写规范，任务完成后规范可被弃用Kiro低
Level 2Spec-anchored规范在功能完成后保留，随功能演进更新Spec Kit（探索中）中
Level 3Spec-as-source人只编辑规范，代码标注"GENERATED - DO NOT EDIT"Tessl高

2.5 "什么是Spec？"的操作性定义

“A spec is a structured, behavior-oriented artifact — or a set of related artifacts — written in natural language that expresses software functionality and serves as guidance to AI coding agents.”
— Böckeler6

与相关概念的区分：

  • vs. Memory Bank（如AGENTS.md、architecture.md）：Memory Bank跨所有会话有效；Spec只与特定功能任务相关
  • vs. PRD：Spec最接近PRD，但更面向AI Agent消费
  • vs. Prompt：Spec是持久的结构化工件；Prompt是即时输入

3. 历史脉络：从MDD到SDD

3.1 模型驱动工程（MDE/MDD）的兴衰

SDD最重要的历史先驱是模型驱动开发（Model-Driven Development, MDD）：

“Model-driven engineering (MDE) is a software development methodology that focuses on creating and exploiting domain models… technical artifacts such as source code, documentation, tests, and more are generated algorithmically from a domain model.”
— Wikipedia, Model-driven engineering11

MDD的核心理念（“从抽象模型自动生成代码”）与SDD高度相似。两者都试图将开发者的工作重心从"编写代码"上移到"编写规范/模型"。

3.2 MDD失败的教训

MDD在2000-2010年代未能广泛成功，主要原因包括11：

  1. 形式化语言的学习壁垒：UML/DSL需要专门学习
  2. 代码生成器能力有限：无法处理复杂业务逻辑
  3. Round-trip engineering困难：模型与代码难以双向同步
  4. 调试困难：生成的代码与原始模型的对应关系不透明
  5. 抽象层错位：在错误的粒度上建模

3.3 LLM如何改变了游戏规则

Böckeler对MDD-SDD类比进行了深度分析6：

“LLMs take some of the overhead and constraints of MDD away, so there is a new hope that we can now finally focus on writing specs and just generate code from them. With LLMs, we are not constrained by a predefined and parseable spec language anymore, and we don’t have to build elaborate code generators.”

但她也指出了新的风险：

“The price for that is LLMs’ non-determinism of course. And the parseable structure [of MDD] also had upsides that we’re losing now: We could provide the spec author with a lot of tool support to write valid, complete and consistent specs.”

总结对比：

MDD的问题LLM是否解决？SDD的新情况
形式化语言壁垒✅ 解决自然语言规范
生成器能力有限✅ 大幅改善LLM通用代码生成
Round-trip困难❌ 未解决规范⇌代码同步仍是核心挑战
调试困难⚠️ 部分改善LLM代码更"人类化"但仍有理解困难
非确定性❌ 新增问题同一规范每次可能生成不同代码

本文判断：SDD有可能避开MDD的部分失败原因（特别是形式化语言壁垒），但也面临MDD时代不存在的新问题（非确定性）。Level 3 (Spec-as-source)面临的风险最高，最可能重蹈MDD覆辙。

3.4 其他历史先驱

先驱方法年代核心思想与SDD的关系
Contract-First API Design2011至今先写OpenAPI规范再实现SDD在API层面的前身
Design-by-Contract (Eiffel)1986接口前置条件/后置条件"契约"思想的起源
BDD/Executable Specs2006至今Given-When-Then场景可直接运行规范可执行性的先驱
Literate Programming (Knuth)1984文档与代码交织"文档优先"理念

4. 对照物：Vibe Coding与无约束AI生成的实证问题

4.1 Vibe Coding的定义

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. […] I ‘Accept All’ always, I don’t read the diffs anymore.”
— Andrej Karpathy, 2025年2月2日1

Vibe Coding的边界界定（Simon Willison，引自Wikipedia12）：

“If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book — that’s using an LLM as a typing assistant.”

4.2 Vibe Coding问题的实证证据

以下证据来自多个独立来源的交叉验证1241314：

安全性
来源方法发现时间
Semafor扫描1645个Lovable应用170个(~10.3%)存在信息泄露2025.05
Veracode多年纵向研究LLM功能性↑但安全性未改善；大模型不比小模型更安全2025.10
BBC/Orchids安全研究员发现vibe coding平台代码含安全漏洞2026.02
代码质量
来源方法发现时间
CodeRabbit13470个GitHub PR分析AI共创代码"重大问题"率1.7x、安全漏洞率2.74x2025.12
GitClear14211M行代码纵向分析重构率25%→<10%，代码重复4x增长2025.02
生产力（最高证据级别——随机对照实验）

METR研究4是该领域迄今最严谨的研究之一：

研究设计：16名经验丰富的开源开发者，246个真实issue，来自平均22k+ stars的仓库，随机对照分组。

核心发现：

“When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts.”4

认知偏差发现：

“Developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.”4

（即约39-43个百分点的感知-现实差距）

METR自己的声明限制4：

  • 仅测量经验丰富的开源开发者
  • 仅使用2025年初AI工具（Cursor Pro + Claude 3.5/3.7 Sonnet）
  • 不排除存在更有效的使用方式
  • 不排除后续模型进步可能逆转结果

4.3 对SDD论证的意义——诚实声明

逻辑链：

  1. 无约束AI辅助存在已被实证证明的质量和生产力问题 ✅（4.2节证据）
  2. SDD通过结构化规范提供约束，理论上可缓解这些问题 ✅（逻辑推导）
  3. 但：目前没有同等级别的实证研究证明SDD确实比无约束AI辅助更好 ⚠️

这是本文最重要的诚实声明：SDD相对于"普通AI辅助编码"的效果优势，目前主要是理论推导和轶事证据，不是对照实验。

5. 方法论定位：SDD与TDD/BDD/DDD的关系

5.1 综合对比

维度SDDTDDBDDDDD
核心工件功能规范(Markdown)测试套件.feature文件领域模型
工作层面需求/设计层代码实现层行为描述层架构设计层
驱动什么AI代码生成手动编码开发+验收系统分解
AI时代新价值为AI明确执行指令为AI提供验证标准为AI提供行为期望为AI提供领域知识
证据基础弱（无RCT）强（数十年）中中

5.2 关键判断：互补而非替代

Spec Kit文档内嵌了TDD8：

“Create test files in order: contract → integration → e2e → unit. Create source files to make tests pass.”

即SDD不是TDD的替代品——SDD负责"做什么"的宏观规范，TDD负责"做对了"的微观验证。两者在不同抽象层工作，天然互补。

6. 规范格式与代码生成基础设施

6.1 机器可读规范格式

格式成熟度代码生成支持适用场景
OpenAPI 3.x生产级50+客户端, 40+服务端15REST API
AsyncAPI成长期多语言模板事件驱动
Protocol Buffers生产级所有主流语言高性能RPC
GraphQL Schema生产级TypeScript为主灵活查询
TypeSpec10成长期通过emitters多协议API设计

6.2 TypeSpec示例

import "@typespec/http";
using Http;

model Todo {
  id: int32;
  title: string;
  completed?: boolean;
}

@route("/todos")
interface Todos {
  list(): Todo[];
  create(@body todo: Todo): Todo;
}

此代码编译生成数百行OpenAPI YAML——体现了SDD的"高层规范→低层实现"理念。

6.3 契约测试：规范即测试

Specmatic9展示了"规范→可执行测试"的零代码路径：API规范自动转化为契约测试，无需手写测试代码。

官方宣称效果（注意：缺乏独立第三方验证）：

  • API开发周期减少75%
  • 流效率提升40%

7. 三大SDD工具的设计哲学与独立评测

7.1 设计哲学对比

维度Kiro (Amazon)3Spec Kit (GitHub)28Tessl6
口号“Vibe coding → viable code”“Intent is the source of truth”“Specs, not code, are primary”
SDD层级Level 1Level 1-2Level 2-3
激进程度保守中等激进
工作流Requirements→Design→TasksConstitution→Specify→Plan→TasksSpec↔Code双向
分发独立IDECLI+workspace(MIT开源)CLI+MCP(私有Beta)

7.2 Spec Kit的"宪法"（Constitution）机制

Spec Kit最独特的设计是Constitution8——不可变的架构原则集合：

“At the heart of SDD lies a constitution—a set of immutable principles that govern how specifications become code.”8

通过模板中的"Phase -1 Gates"（如Simplicity Gate、Anti-Abstraction Gate）强制AI在生成前通过检查。这是一种创新的LLM行为约束框架。

7.3 独立评测：Böckeler的深度体验

Birgitta Böckeler（Thoughtworks Distinguished Engineer，20+年经验）是目前唯一公开发表三工具独立评测的人6。核心发现：

发现一：尺寸不适配（Sledgehammer-to-crack-a-nut）

“When I asked Kiro to fix a small bug, it quickly became clear that the workflow was like using a sledgehammer to crack a nut. The requirements document turned this small bug into 4 ‘user stories’ with a total of 16 acceptance criteria.”6

发现二：审查负担

“To be honest, I’d rather review code than all these markdown files. An effective SDD tool would have to provide a very good spec review experience.”6

发现三：虚假控制感

“Even with all of these files and templates and prompts and workflows and checklists, I frequently saw the agent ultimately not follow all the instructions.”6

具体案例：Spec Kit的research步骤正确识别了现有代码结构，但AI agent随后将其当作新规范，生成了重复代码。

发现四：评价困难

“It turns out to be quite time-consuming to evaluate SDD tools in a way that gets close to real usage.”6

7.4 总结性判断

Böckeler的最终结论6：

“The general principle of spec-first is definitely valuable in many situations… But the term ‘spec-driven development’ isn’t very well defined yet.”

她用了一个德语合成词：

“Verschlimmbesserung”: Are we making something worse in the attempt of making it better?

Thoughtworks技术雷达独立确认7：

“These tools behave very differently depending on task size and type; some generate lengthy spec files that are hard to review.”

8. 实证证据与证据缺口分析

8.1 证据质量矩阵

断言证据质量证据类型来源数量
“无约束AI辅助有安全/质量风险”高多源独立实证4+
“AI辅助不一定提升生产力”高RCT41（高质量）
“当前SDD工具有可用性问题”中-高专家评测6 + 技术雷达确认72
“SDD比无约束AI辅助更好”低理论推导 + 轶事0个对照实验
“规范优先能加速API开发”中商业案例9（缺独立验证）1

8.2 最大的证据缺口

缺口一（最关键）：没有"SDD+AI" vs “裸AI” vs "纯手工"的对照实验。

缺口二：没有长期追踪数据（SDD工具存在不到1年）。

缺口三：没有规模化团队使用的公开报告。

8.3 对"SDD有效"的最强间接证据

  1. Contract-First的15年实践：规范优先在API层面已被验证有效
  2. METR研究揭示的机制：AI让人变慢的因素（“代码不符合项目风格”）可能被SDD缓解
  3. 逻辑论证2：更明确的输入→更少的猜测→更少的错误（但"清晰逻辑"≠"已验证效果"）

9. 系统性批评与反驳

9.1 批评一：“Bitter Lesson”——规则不如学习

Thoughtworks技术雷达7：

“We may be relearning a bitter lesson — that handcrafting detailed rules for AI ultimately doesn’t scale.”

反驳：Bitter Lesson假设计算力无限增长；即使模型变强，"明确表达意图"的沟通价值仍在。

本文判断：这是最深刻的批评——它质疑SDD的长期生命力。短期有价值；长期取决于AI能力阶梯式跃升是否发生。

9.2 批评二：SDD是瀑布模型的回归

反驳：SDD可以按Story粒度迭代应用；AI将"规范→代码"时间压缩到分钟级；Spec Kit明确支持迭代模式8。

本文判断：批评部分有效。关键在于粒度控制——如果被滥用为"写完所有规范才编码"，确实是瀑布回归。

9.3 批评三：虚假控制感

“Just because the context windows are larger, doesn’t mean that AI will properly pick up on everything that’s in there.”6

本文判断：当前有效的批评。SDD面临的根本挑战：如果AI不可靠地遵守规范，规范的约束价值就打折扣。这依赖基础模型进步。

9.4 批评四：审查负担转移而非消除

Böckeler：“I’d rather review code than all these markdown files”6

本文判断：因人而异。对技术熟练者，审查代码可能更高效；对非技术利益相关者，审查规范更现实。

9.5 批评五：MDD幽灵

“I wonder if spec-as-source might end up with the downsides of both MDD and LLMs: Inflexibility and non-determinism.”6

本文判断：Level 3 (Spec-as-source)面临此风险最高；Level 1 (Spec-first)风险最低。

10. 开放问题与未来研究方向

10.1 亟需回答的实证问题

  1. SDD对照实验：在相同任务上比较"SDD+AI" vs “裸AI” vs “纯手工”
  2. 规范维护的长期成本：6个月后规范与代码是否漂移？
  3. 任务大小的盈亏平衡点：多大的任务SDD收益超过开销？
  4. 团队vs个人：SDD在协作中的价值是否显著高于个人使用？

10.2 可观察的技术趋势

  1. 规范的自动化生成：从代码反向生成规范（Tessl的tessl document）
  2. "意图工程"融合：规范与Prompt工程边界模糊化
  3. IDE原生集成：SDD可能从"显式Markdown文件"演变为"IDE内置智能约束层"
  4. METR 2026年2月更新4：追踪late-2025 AI工具的生产力影响——可能改变结论

11. 结论与审慎建议

11.1 核心结论

结论一：SDD的核心理念——“在让AI编码前先明确意图”——具有理论合理性。这是"先想清楚再动手"的永恒原则在AI时代的表达。

结论二：当前SDD术语存在严重语义扩散，三个工具对SDD的理解大相径庭（spec-first到spec-as-source），且都处于早期。

结论三：SDD相对于"普通AI辅助"的优越性尚缺乏对照实验验证。我们有充分理由相信它有价值（理论推导+Vibe Coding负面证据），但这与"已被证明"之间存在重要区别。

结论四：当前工具面临真实可用性问题（尺寸不适配、审查疲劳、AI无视规范6），限制了实用价值。

结论五：SDD最可能的适用范围是中等规模绿地项目功能开发——太小则开销过大，太大则规范难以完备，棕地引入困难。

11.2 分层建议

对象建议风险级别
个人开发者用AI前花5-10分钟写结构化需求（零成本spec-first）无风险
团队试点新API尝试OpenAPI-first + 代码生成低风险
SDD工具采用除非愿意承担早期采用者不稳定性，否则等待成熟中风险
组织级推行不建议现在强制推行，鼓励试点收集数据需谨慎

11.3 最终反思

“The past has shown that the best way for us to stay in control of what we’re building are small, iterative steps.”
— Böckeler6

“We’re moving from ‘code is the source of truth’ to ‘intent is the source of truth.’”
— GitHub Blog2

这两句话代表了讨论的两极。

SDD之所以在2025年重新成为可能，不是因为"规范"变了，而是因为"从规范到代码"的成本趋近于零了。 这一变化是真实的、不可逆的。但它不自动意味着一切都应变成规范——正如打字机降低了写作成本，并不意味着每个想法都值得写成书。

最审慎的立场是：保持spec-first的习惯（这永远不会错），但对SDD工具和流程保持批判性评估——直到有更充分的对照实验证据。

12. 参考文献

本文完成于2026年5月30日。鉴于SDD领域的快速演变，文中结论的有效期可能有限。

  1. Karpathy, A. (2025, February 2). “There’s a new kind of coding I call ‘vibe coding’…” X (Twitter). https://x.com/karpathy/status/1886192184808149383 ↩︎ ↩︎

  2. Delimarsky, D. (2025, September 2). “Spec-driven development with AI: Get started with a new open source toolkit.” GitHub Blog. https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. Amazon. (2025-2026). Kiro Official Website. https://kiro.dev/ ↩︎ ↩︎ ↩︎

  4. Becker, J., Rush, N., Barnes, E., & Rein, D. (2025, July 10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” METR. arXiv:2507.09089. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. Koren, M., Békés, G., Hinz, J., & Lohmann, A. (2026, January 21). “Vibe Coding Kills Open Source.” arXiv:2601.15494v1. ↩︎

  6. Böckeler, B. (2025, October 15). “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl.” martinfowler.com. https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  7. Thoughtworks. (2025, November). “Spec-driven development.” Technology Radar Vol. 34, Assess. https://www.thoughtworks.com/radar/techniques/spec-driven-development ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  8. GitHub. (2025-2026). “Specification-Driven Development (SDD).” spec-kit repository, spec-driven.md. https://github.com/github/spec-kit/blob/main/spec-driven.md ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  9. Specmatic. (2025-2026). Official Website. https://specmatic.io/ ↩︎ ↩︎ ↩︎

  10. Microsoft. (2025-2026). TypeSpec. https://typespec.io/ ↩︎ ↩︎

  11. Wikipedia contributors. (2025). “Model-driven engineering.” Wikipedia. https://en.wikipedia.org/wiki/Model-driven_engineering ↩︎ ↩︎

  12. Wikipedia contributors. (2026). “Vibe coding.” Wikipedia. https://en.wikipedia.org/wiki/Vibe_coding ↩︎ ↩︎

  13. Loker, D. (2025, December 17). “Our new report: AI code creates 1.7x more problems.” CodeRabbit Blog. ↩︎ ↩︎

  14. Doerrfeld, B. (2025, February 19). “How AI generated code compounds technical debt.” LeadDev. ↩︎ ↩︎

  15. OpenAPI Tools. (2025-2026). OpenAPI Generator. https://openapi-generator.tech/ ↩︎

# 驱动开发 # 人工智能
Logo
天工造物局

北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台

更多推荐

deck.gl TripsLayer 出租车轨迹动画示例实战：从示例运行到着色器原理

TripsLayer 是 deck.gl 中用于渲染**随时间流动的轨迹动画**（如出租车行程、物流路径、迁徙路线）的核心图层。本文以仓库中的最小独立示例 [examples/website/trips](https://link.gitcode.com/i/1442af8f442f4cff39ff546e050fceb5) 为骨架，带你完成从安装依赖、启动应用、理解曼哈顿出租车数据格式，到深入

avatar 天工造物局

Foundry Anvil 中 eth_simulateV1 的 Blob 交易与 Blob Gas 字段规范化：原理、实现与测试验证

本篇技术指南以 [anvil-simulate-blob-transactions.md](https://link.gitcode.com/i/3d2ebe227262de169335eb290af80da8) 这条 changelog 条目为起点，深入剖析 Foundry Anvil 对 `eth_simulateV1` RPC 返回结果中 blob（EIP-4844）交易与 blob gas

avatar 天工造物局

LMCache CLI 实战：用 `lmcache kvcache clear` 管理运行中服务的 KV Cache 状态

本文是一份针对 LMCache 官方 CLI 命令 `lmcache kvcache` 的完整技术指南。该命令用于在**运行中的 LMCache 服务（MP HTTP server）**上管理 KV cache 状态，当前提供 `clear` 子命令，用于清空 L1（CPU 内存）层中缓存的全部 KV 数据。读完本文，你将掌握该命令的完整参数体系、退出码语义、终端/JSON/静默三种输出模式，并能

avatar 天工造物局