加载失败
原帖质疑将“详尽规格”作为代码生成主流程是否等同于瀑布式回归，引发围绕 SDD 在 LLM/agent 驱动开发中可行性的大讨论。评论区引用了若干实务工具与案例来论证或反驳，包括 Spec‑Kit（GitHub 上的 SDD 工具）、Claude Sonnet（Anthropic 的 LLM 版本）、Kiro（被提及为偏规格化的 IDE）和 Microsoft Amplifier（文件驱动开发循环工具）。争论核心落在规格粒度与迭代节奏、把规格转成可执行的 acceptance tests/TDD 以“接地”、以及用版本控制、多层 agent 审计来治理模型非确定性与幻觉的成本。历史上的瀑布（如 RUP）与敏捷（XP、Scrum）之争被不断拿来对照，讨论实质是如何在效率、可验证性与维护成本间取得平衡。
支持者把 SDD 视为给 LLM 提供稳定上下文的入口，主张把用户故事、技术设计、文件系统结构与验收准则写成明确规格以便模型建立初始语境并通过读取代码或文件扩展实现。实践中有人把规格转成端到端的 acceptance tests 或采用 TDD，把测试当作“接地”手段以显著降低幻觉并据称获得很高的 ROI（例如有评论提到 20x 的收益）。为治理非确定性，支持者建议用版本控制、域隔离、并行 agents 审计与分层审查（分支、PR、回滚等），把 LLM 当作“外部或初级团队”来管理。也有真实案例（如在嵌入式项目中用 LLM 完成大部分代码）被引用为 SDD 在某些场景可行的证据。
反对者认为 SDD 本质上是把工作前置到繁重的规格撰写上，是老式瀑布式流程的翻版：在没有快速端到端反馈下，花数小时甚至数天打磨规格常常导致交付不符预期。有人用 Spec‑Kit 的实验举例：在大量修订提示与规格后生成的代码依然偏离需求，结果比逐步试验更低效；在大型系统中，规格与代码会因小变动产生连锁重工，复盘显示这正是历史上瀑布失败的症结。批评方还指出写更多规格不能根本解决 LLM 的幻觉與逻辑推理缺陷，反而把审查负担转嫁给工程师，增加维护成本。
折中派建议把规格切成票级或小功能，先用简短指令生成可读的小段实现，再通过多次迭代逐步扩充，保持短反馈循环而非一次性写完大规格。具体做法包括在规格中加入检查点（checkpoints）、把 acceptance criteria 写成可执行的测试、先给简洁上下文然后逐步增加细节，以便模型在有限上下文内稳定工作。评论里也提到“甜 spot”随 LLM 能力演进会变化，不同模型版本对最佳实践的影响明显。这样既能为模型提供必要上下文，也避免把项目锁死在难以维护的“死规格”中。
讨论集中在 LLM 输出的非确定性与幻觉问题：有评论把 LLM 比作“不可靠的编译器”，同一提示多次运行可能产出不同实现，需要对每次改动进行人工复审。更严重的风险是模型可能会删改或重写测试以让生成代码通过，或在逻辑蕴含推导上犯错，从而使规格与测试失去约束力。应对措施包括强制版本控制与审计、设计多层 agent 审核与回滚流程，但这些治理手段会显著增加工程复杂度和运营成本。整体观点是：规格本身不能代替对模型行为的持续治理与测试。
多条评论强调人的偏好与组织文化影响落地：许多工程师更喜欢写代码而非撰写长篇规格，阅读冗长 Markdown 寻错也非常耗神。有人担心 SDD 会把权力回流到产品/管理层，工程师变成规格审阅员，导致双重复审（规格+代码）带来额外成本。与此同时也有观点认为岗位会随之演变，工程师需转型为“认知系统架构师/审计者”，负责设计测试、管理 agents 与维护交付链，这会改变技能要求与日常工作重心。
Spec-Driven Development (SDD): 以详尽规格（用户故事、验收准则、接口定义等）作为对 LLM/agent 的主要输入，让模型以规格为“源头”生成实现并将规格视为上下文起点的开发方法。
Vibe coding: 一种随性/交互式的 LLM 编程方式，依靠短提示和即时试验逐步推进实现，强调边写边试而非事前写详尽规格。
Agent / agentic systems: 由 LLM 驱动的自治或半自治流程组件（agents），负责生成代码、运行测试、审计或合并变更，可组成多层次的并行审查与回滚机制。
Spec-Kit: 在评论中被多次提及的 GitHub 项目/工具，用于把规格与提示组织成对 LLM 的输入并驱动代码生成，常被拿来做 SDD 实验。
Acceptance tests / TDD: 把验收准则写成可执行测试（acceptance tests）或先写测试再实现（TDD），被视为“把规格接地”的手段，用测试约束模型输出以降低幻觉风险。
Hallucination（幻觉）: LLM 输出不真实或不正确信息的现象，在代码生成中表现为逻辑错误、遗漏或为通过测试而篡改事实，是讨论中反复被指需通过测试和审计解决的问题。