13万Star的Spec Kit把规格当唯一真相、Kiro强制先写spec：当AI不再听提示词，Java团队该怎么下指令

GitHub Spec Kit拿到13万Star、接入38款编程Agent，用constitution→specify→plan→tasks→implement四步把意图固化成版本化的规格文件；AWS Kiro更激进，不写requirements.md、design.md、tasks.md就不生成代码。它们背后的判断是一致的：对话式提示词给Agent的是移动靶，结构化规格给的是固定靶，输出的可靠性跟着brief的精度走。10月21日，飞算JavaAI最新版本给智能会话加了「/目标模式」指令，把同一条思路搬进了Java工程。本文拆解这场从提示词驱动到目标驱动的迁移，以及它为什么这次不会重蹈二十年前模型驱动开发的覆辙。

一、提示词驱动的天花板在哪

模型能力已经不太像瓶颈了。DeepSWE跑到77.0%，单任务成本从3.3元降到1.3元；上一轮旗舰模型在ARC-AGI-3这类推理基准上拿到99.9%。但「提示词写得越好、结果越好」这条经验，在长任务上开始失效。原因不复杂：你没法在一句话里说清三十条从没写在文档里的约定——事务边界加在哪一层、分页用IPage还是PageHelper、统一响应体继承哪个基类、异常码走GlobalExceptionHandler的哪一段。

Shiplight那篇2026年指南把这件事讲得很直白：对话式提示词给Agent的是一个移动靶（moving target），结构化规格给的是一个固定靶（fixed one），输出的可靠性跟着brief的精度走——所以规格驱动团队把写spec当成真正的活儿，而不是走流程。Agentic Patterns网站在10月14日收录的「Specification-Driven Agent Development」模式，把问题定义得更技术化：手工提示词或松散的user story留下大量歧义空间，Agent会漂移、过度解读，产出与相关方意图冲突的代码。

换句话说：模型越强，人的描述能力越成为短板。而提示词工程这条路线，把补齐短板的责任压在了每一个开发者身上——你得自己学会把话说全，且每次都说全。

二、规格驱动：从理念到工具链

GitHub Spec Kit是这波浪潮里最显眼的那个。它不是一个Agent，更是一层可插拔的流程壳：13万Star、270多名贡献者、接入38款编码Agent（Copilot、Gemini、Codex、Claude、Kiro等）、157个社区扩展。核心流程是specify→plan→tasks→implement，每个阶段产出一个Markdown产物喂给下一个阶段，用结构化上下文替代随意的提示词。它可以在内网、离线、Windows上跑。

AWS Kiro做了相反的架构赌注：不寄生在别的Agent上，更是从零建成一个围绕spec的agentic IDE。它在生成代码前必须有结构化规格，把需求拆解、技术设计、任务实现拆成独立阶段，并保持从高层需求到实现代码的traceability；autonomous、spec、default三种模式并存，Kiro Web的会话跑在隔离的云沙箱里，合上电脑也不中断。

2.1 配套的方法论也在成形

Agentic Patterns给出的框架是SPEC/EXPOSURE/TASK DELTA：SPEC是版本化的意图与价值记录，EXPOSure强调「spec是永久的、代码是临时的」，TASK DELTA则是一个持续评估SPEC与PRODUCT之间差距的循环。落到文件层，一套被反复验证的结构是：requirements.md写用户可见行为、验收标准和明确的非目标；design.md写架构、数据模型和ADR；tasks.md写可勾选的有序任务；契约层用OpenAPI 3.1、JSON Schema、Protobuf、Gherkin。

2.2 仓库级约定：把「每次都说一遍」变成「写一次」

AGENTS.md、CLAUDE.md、Cursor rules这一层约定文件的普及，本质上是同一件事的另一半：让Agent从仓库里读到长期约束，而不是靠你每轮补一段提示词。Anthropic的工程博客《Effective harnesses for long-running agents》被多个方法论站点列为核心参考，讲的就是怎么给长跑Agent搭好缰绳。

三、为什么这次不会重蹈MDD的覆辙

规格驱动不是新想法，诚实地讲，它有一个失败的近亲。2000年代的模型驱动开发（MDD）同样承诺从高层模型生成代码，最后基本失败——模型比代码还难写，生成器又脆弱又死板。Spec Kit和Kiro凭什么不一样？Shiplight给出的三条判断我认为站得住。

第一，生成器换了。编码Agent是灵活的生成器，不是模板引擎，它读得懂半结构化的自然语言规格，也能容忍不完美。第二，执行环境换了。CI/CD的成熟度让自动化强制变得可行：校验OpenAPI、跑契约测试、spec与代码不一致就直接fail build——规格不再是摆设，更是进了流水线的闸门。第三，消费者换了。规格的读者现在是AI，写好spec的收益立刻兑现，而不是等到遥远的维护周期。

这三条合起来是那句总结：The practice is old. The economics are new.（做法是旧的，账变了。）

四、目标驱动也会翻车：三个已知失败模式

4.1 Verification gap

Agent可以声称满足了spec，但实际上并没有。只有可执行的测试能让合规变成真的——所以规格层必须配一套CI里跑得起来的验收测试，否则「spec通过了」只是一句自述。

4.2 Spec rot

没有CI强制spec与代码对齐，spec会像过期注释一样，变成仓库里的另一个谎言。规格和目标一旦腐烂，后面所有基于它的自动化都在错误地基上加速。

4.3 过度规格化

四行改动不需要design document。更关键的是那句警告：a spec that faithfully encodes a bad design still ships a bad design——规格驱动提升的是保真度，不是判断力。探索性工作、意图本身就模糊的时候先写spec，是负收益。这也解释了为什么Kiro保留了default和autonomous两种非spec模式。

五、Java场景：/目标模式落地的三件事

5.1 目标要可验收，不是许愿

飞算JavaAI新增的「/目标模式」指令，把对话从「帮我写个导出接口」换成「目标是：分页导出、单次上限10万行、超限转异步并邮件通知、错误码复用现有GlobalExceptionHandler」。差别不在措辞，在于目标里带了验收条件。之前讨论过的DeepSeek自反馈RL把「许愿式编程」做成了现实，但愿望要能被验证，才有资格交给智能体去自主迭代——目标模式就是给愿望装上验收标准这一步。

5.2 目标要靠工程上下文落地

同一句目标，在A团队和B团队落出来的代码不一样。分页用IPage还是PageHelper，事务注解加在Service还是Controller，统一响应体继承哪个BaseController，日志走哪套MDC字段——这些从没写进需求文档，但写错了就要返工。全量代码语义索引让智能体直接从现有工程里读出这些约定，企业规范导入则把团队标准固化成默认行为。Java专有模型对Spring、MyBatis、Maven依赖树的针对性理解，在这里的价值就是：你不说，它也懂。

5.3 目标要能算账

目标驱动意味着智能体自主跑得更久，所以成本必须可见、可刹车。3.9.19起，智能引导Java Web工程与通用场景的生成源码步骤会显示总tokens消耗、并支持设置中断条件；配合智能路由与专家模式的双档设计，实测日均Token消耗从850万降到260万、节省69.4%。再加上本地化处理让代码不出域——目标可以定得很大，边界依然清楚。

提示词驱动的时代，比的是谁会把话说清楚；目标驱动的时代，比的是谁的工具能把工程里那些没说出来的话自己读懂。做最会接提示词的AI不难，做最懂你目标的AI——这才是Java团队真正缺的那一块。