最近我把主力开发环境切到了Kiro IDE起初只是好奇它把AI智能体塞进编辑器之后到底能做到什么程度结果用下来最大的感受不是生成代码多了而是自己的开发方式被改变了。它正在把一种叫规范驱动开发SDD的方法变成IDE里的日常操作简单点说就是先写一份人能读、机器能验证的行为规范围再让AI照着这份规范围去写实现。这篇文章会把Kiro IDE里这套SDD工作流的原理、完整实操过程和踩过的坑都整理出来适合正在用或准备用AI编程工具做真实项目的开发者参考不管你是被AI生成的半成品代码折磨过的老手还是刚接触智能编程的新人都能从中得到一些能直接落地的经验。1. 从让AI猜需求到让AI照着做为什么SDD是必然方向1.1 没有规范时AI编程卡在哪先从一个特别常见的场景说起。过去很长一段时间AI编程工具给大多数人的体感就是高级自动补全你写了一个函数名、一段注释模型把你后面可能写的那几行推出来。遇到样板代码确实快但一碰到真正的业务逻辑立刻就露馅了。因为模型根本不知道你这个模块要满足什么业务规则不知道哪些分支必须存在不知道异常情况要怎么兜底。它只能根据训练数据里大多数人会怎么写来猜而猜出来的东西往往表面上能跑实际上边界条件一团糟。我在自己维护的一个模拟库存管理平台里试过最典型的翻车场景让某个AI助手直接写一个订单状态流转接口。它写出了非常标准的增删改查代码数据库表结构也搭好了但完全没有处理已取消订单不能再流转到已发货这种业务约束。代码在语法上是完美的在业务上是错的。这种错是最危险的因为它不会直接崩溃而是等到某一天一个用户触发了非法状态流转数据乱掉之后你才开始追查到底是哪个过滤条件漏了。传统IDE里你还能通过断点慢慢查可AI生成的一两百行代码你根本不熟悉它的思路排查成本比手写还高。这个问题的根子在于人和AI之间没有一份合同。人脑里有一种模糊的需求预期AI的训练数据里有一套通用的代码模式两者相遇之后AI只能靠猜。你不给它明确的事实输入它当然只能给你最可能出现的普适答案而不是最符合你业务的那个答案。所以后来我越来越认同一个判断AI编程真正要解决的瓶颈不是生成能力而是怎样让生成的东西有据可依。1.2 规范驱动开发SDD想解决的核心矛盾规范驱动开发也就是Spec-Driven Development简称SDD。它的思路不算新鲜简单来说就是先把需求固化成一份结构化的行为规范Spec里面写清楚功能场景、输入输出、验收标准、边界约束然后让AI基于这份规范去生成或者修改代码。用装修来打比方的话以前你请施工队AI干活你只给了一句我想要个好看点的客厅施工队自由发挥完你觉得不是你要的SDD则是先画出施工图——墙体怎么砌、插座在哪里、电线怎么走全标清楚施工队照图施工最后你用图纸验收。AI不再用猜规范就是人和机器之间的共享合同。那为什么SDD这两年又重新被重视关键是大模型对结构化文本的理解能力上来了。以前所谓的规则驱动开发更像模板填充你给一份特殊格式的文档程序按正则把字段抠出来套代码模板这既不能理解语义边界也不能生成复杂逻辑。但当大模型能真正读懂一段自然语言写的行为约定之后规范才具备了成为开发输入的资格。AI不再是执行模板的机器而是能根据规范要求主动设计函数结构、数据关系、异常处理路径的工程师助理。SDD真正想解决的核心矛盾是需求描述的模糊性和AI生成能力的无限性之间的错配。AI生成能力越强模糊需求被固化成错误代码的风险就越大。以前人写代码脑子里模糊一点写的过程会逼自己理清逻辑现在AI写代码它不会觉得模糊是个问题它会把模糊当作自由发挥的空间于是错误被大规模、高效率地制造出来。SDD就是在生成能力前面加一道闸门先让你把话说清楚再让你享受生成效率。1.3 为什么偏偏是IDE来承载这套闭环这就要提到Kiro IDE的设计取舍了。它不是把AI当作一个聊天窗口挂在侧边栏而是把AI接入到代码编辑、测试运行、文件变更追踪这些核心链路里。SDD真正落地起来是一整套写规范—生成代码—跑测试—改规范—再生成的循环这个循环只有在IDE里才能形成最短路径。如果你把它拆成命令行工具或者一个在线网站每走一步都要切换上下文人根本坚持不下去。我也试过在某个聊天式AI工具里让模型先写规范再写代码模型确实会输出一份规范文档但那只是一个远程对话窗口里的文本和当前项目没有任何绑定关系。规范写完就躺在聊天记录里不会触发文件变更、不会关联测试、不会在项目树里形成一个可被检索的实体。Kiro IDE把规范文件当作一等公民之后整个体验就完全不同了。项目里有一个独立于代码目录的 spec/ 空间每一份规范都能和实现文件建立关联修改规范时IDE会列出受影响文件生成代码时IDE会在规范条目和函数定义之间建立索引。这听起来像是小事但在真实项目中这种绑定关系决定了你愿意不愿意持续用SDD。如果每次都要手动去找这个规范对应哪个模块用不了两天你就会放弃。只有当IDE把追溯成本降到零SDD才从小众方法论变成了日常操作。2. 核心机制拆解Kiro IDE里一份Spec是怎么驱动整个开发的2.1 一份可执行的Spec应该包含哪几个部分先给一份我自己在用的最小模板。要写出一份能真正驱动AI的规范至少包含五个部分功能场景、输入与状态、行为规则、边界与异常、验收标准。不是说要写成长篇大论的需求文档而是要把握一个尺度——把条件和结果说清楚把具体实现留给AI。拿用户登录功能举例规范大致可以这样写# 用户登录行为规范 ## 功能场景 - 用户使用邮箱和密码进行登录 - 登录成功后系统返回带用户身份的访问令牌 ## 输入与校验 - email 必须符合邮箱格式 - password 长度不得低于 8 位 ## 行为规则 - 密码错误时返回统一错误码 AUTH_001 - 连续失败 5 次后账号进入 10 分钟锁定状态 ## 边界与异常 - 不存在的邮箱与错误密码走同一个错误响应防止用户枚举 - 锁定期间即使密码正确也拒绝登录 ## 验收标准 - 上述规则全部有自动化测试覆盖 - 并发登录同一账号不产生竞态这份规范的核心作用是把产品经理脑子里的假设全部摆到台面上。很多人写代码时其实没想清楚这些前提结果AI只是在代码生成层面代劳需求假设错误照样会被实现进代码里。比如并发登录不产生竞态这句话如果不写AI大概率不会主动去想并发问题一旦写了它就会去考虑数据库锁、原子更新、幂等表这些机制。规范先立住后面所有生成和修改都有了锚点AI不会在你以为它懂但实际它不懂的地方翻车。2.2 从Spec到代码AI的映射逻辑接下来是Kiro IDE里最关键的一步AI拿到规范之后怎么把它变成实现。我实测下来它并不是直接把整份Markdown翻译成代码而是先做结构映射。比如看到用户登录行为规范它就会尝试定位项目里已有的认证模块如果项目还是空的它就根据规范新建对应的路由、服务、存储层文件。然后它把行为规则里的每一条对应到具体函数或守卫逻辑上比如连续失败5次锁定这种规则会被翻译成一次登录失败的计数和状态记录逻辑而锁定期间即使密码正确也拒绝登录则会被实现成一个前置条件判断在验证密码之前就拦住请求。这一步的实际价值在于可追溯。Kiro IDE会在规范里每个小节和生成的代码之间建立关联索引你点规范里的某一条IDE能高亮对应实现代码的位置。真正产生增量价值的不是它帮你写出了500行代码而是这500行代码里每一条规则都有对应的校验点。之后做重构或者加需求你不需要重新通读整个模块点开规范就能知道改动半径在哪里。这种把高密度业务知识结构化并且追踪起来的能力是普通AI编程工具不具备的。2.3 规范追踪与变更联动这套闭环的护城河代码是业务规则的影子需求和实现一旦不同步影子迟早会变形。Kiro IDE对规范与代码之间的关联不是一次性生成完就结束的。后续修改代码时它会提醒你这个函数的实现偏离了规范中的条款A当你修改规范中某句话时它会在变更面板中列出受影响的文件清单并自动生成一轮按新规范调整代码的建议。这就像把传统IDE里的引用查找升级成了业务规则追踪。举个具体例子。我在一个模拟的电商项目里把未支付订单在15分钟后自动关闭改成24小时后才关闭。如果没有规范我需要手动搜索所有跟订单超时相关的代码搜索15分钟、搜索定时任务、搜索订单状态常量很容易漏掉隐藏在某个查询语句里的时间判断。而在Kiro IDE里我只要在Spec里把这个时间阈值改掉再补上新的验收用例AI会自己定位到定时任务、数据库状态字段、查询接口等所有关联位置挨个把逻辑与注释同步更新。这个过程不是简单的全局替换它会根据上下文判断哪些地方需要改哪些地方可以保持不变这种判断只有结合了全项目索引和语义理解的IDE模式才做得到。3. 从零走一遍在Kiro IDE里用SDD做一个真实功能3.1 初始化一个SDD工作区下面进入实操。我自己做的是一个小型REST API服务技术栈选Python。Kiro IDE初始化的方式和普通IDE差别不大但区别在于它会询问你是否启用规范驱动开发工作区。启用后项目结构会多出一个 spec/ 目录里面默认有一个 _template.md 作为规范模板。我建议第一次尝试时不要急着让AI做复杂功能先把目录结构跑通。初始化完之后建议顺手配置一下测试框架和代码格式化工具。Kiro IDE对主流测试框架的集成是现成的在初始化向导里选好pytest、eslint、prettier或者对应的工具链后续的生成—测试循环才不会在环境问题上卡壳。这一步很基础但很多人在上手AI IDE时容易忽略环境一致性结果AI生成的测试在自己机器上跑不过第一反应就是抱怨工具不行实际上是你没把执行环境交代清楚。3.2 手写第一份行为规范然后我在 spec/ 里新建 auth.md把上一节那份登录规范的内容填进去。写规范的时候要注意措辞要精确到可测试比如写返回统一错误码AUTH_001而不是提示用户出错写密码错误连续5次后锁定10分钟而不是限制登录次数。Kiro IDE会在右侧实时渲染规范预览每个小节前面会有对应的复选框表示这条规则是否已被实现代码覆盖这是一个很直观的进度感。我第一次写的时候还是忍不住用了一些模糊词比如登录失败过多应该锁定账号。结果AI生成的代码确实做了锁定但过多被它理解成3次锁定时间是它自己定的5分钟。不是AI不聪明是规范给了它太大的解释空间。从那之后我养成一个习惯凡是涉及数量、时间、状态、错误码、权限角色这些要素必须写一个确定的值。数值是模糊需求的重灾区AI不是业务方它没有义务替你把过多翻译成5次。3.3 让AI按规范生成实现并跑测试写完规范我直接调用IDE里的根据规范实现命令。Kiro会先弹出一个变更预览面板列出它即将创建和修改的文件清单我确认之后才开始写入。这一步很重要它允许你在AI动手之前拦截明显跑偏的方案。比如我第一次用Kiro做登录功能时它规划了一个独立的认证微服务目录但我的项目只是单体服务多出来的抽象层次完全没有必要。我直接在预览面板里把目标目录改掉它后续生成就全部落在合理位置。生成完代码它会自动补一组 pytest 用例。Kiro自动生成的测试开头大致是这种风格import pytest from auth import authenticate def test_login_success_returns_token(): result authenticate(emailuserexample.com, passwordpassword123) assert result.token is not None def test_login_wrong_password_returns_auth_001(): with pytest.raises(AuthError) as exc: authenticate(emailuserexample.com, passwordwrongpass) assert exc.value.code AUTH_001然后它会在内置终端里执行测试。第一次跑通常不会全绿此时Kiro会自己读失败的断言回溯实现代码进行修复直到测试通过。人不需要介入完整的一次生成-修复循环但如果AI反复修不过它会停下来向你提问。遇到这种情况建议先检查规范本身是不是有歧义或者方案选型是不是和项目现状冲突而不是单纯让AI换个写法硬试。3.4 需求变化先改Spec再改代码的标准动作接下来是最关键的标准动作。后来我在这个项目里又加了需求登录成功后要一并返回用户角色信息。我没有直接去找代码实现而是先回到 auth.md在功能场景里补上登录成功返回用户角色在验收标准里增加登录接口响应体中包含 role 字段然后让Kiro执行同步更新实现。它生成的变更首先体现在测试用例上——旧测试会因为缺少role字段而失败新测试会断言role字段存在。AI为了通过新测试去服务层补充用户角色的查询逻辑顺带更新接口文档注释。整个过程需求、代码、测试三者始终保持同步。这种节奏一旦养成你会发现改需求不再是一件焦虑的事。以前改一个字段要全局搜索实体的使用点现在只要规范改一个字AI和测试一起帮你兜住影响面你要做的只是在变更预览里审视一遍AI的方案是否合理。4. 踩坑实录SDD模式用得不好的几个高频问题4.1 规范写太细反而拖慢节奏我最初入坑SDD时最大的问题就是把它写成了详细设计文档。我用自然语言把每个函数的内部流程都描述得清清楚楚AI生成代码时几乎没有发挥空间遇到复杂逻辑改动时规范本身的维护成本变得比代码维护还高。这个问题很隐蔽因为你写的时候会觉得越详细AI越不容易出错但实际体验下来规范一旦详细到调用链路级它就已经不是规范了而是伪代码。你的AI编程效率不仅没有提升反而因为规范里的描述和实际技术实现不匹配陷入反复调整措辞的泥潭。后来我摸清了一条规律规范着重行为约定和验收条件而不是具体实现步骤。你不需要在规范里写先查数据库再查缓存最后拼接返回结果你只需要写接口必须在500毫秒内返回缓存命中时不得访问数据库。AI是工程师它需要的是目标和约束不是逐行指令。给AI留出实现空间它才能真正发挥出比你更熟悉框架细节的优势把实现细节全定死你就等于退回到了用自然语言写业务代码的原始时代。4.2 规范和测试冲突先信谁这是一个很实际的问题。Kiro在某些场景下会先根据自己对规范的理解生成测试而不是严格把规范里的验收标准转成测试。如果它理解偏了就会出现规范和测试打架的局面。我遇到过一种情况规范里明明写了不存在的邮箱和错误密码返回同一个错误码但AI生成的测试里却在断言不存在的邮箱返回提示账号不存在这明显是AI从训练数据里带出来的习惯而不是我的需求。这种冲突出现时我自己的原则是优先信规范。因为测试是AI生成的可能在生成过程中被项目里其他上下文污染而规范是你亲手写的需求承诺。正确做法是先把测试行为向规范对齐可以直接手动修改测试断言也可以让AI按规范重写测试,然后再让AI重新实现代码。注意不要反过来为了迁就一个AI生成的测试去改规范那样属于本末倒置会把需求带偏时间一长规范和真实业务就会越漂越远。4.3 AI理解偏差规范不够细还是模型能力不够另一个高频问题是AI生成的代码看起来正确但漏掉了某个小众边界条件。这时候先别急着骂模型。多数情况下是规范里没有把那一个条件写出来。大模型本质上是模式补全器不是逻辑推导引擎它不会主动把你没写但隐含的条件补全。你说连续失败5次锁定它可能会实现锁定计数的逻辑但不一定想到锁定期间即使密码正确也要拒绝登录你说登录接口要防枚举它可能只做了验证码而不会想到错误信息统一。每一个边界规则都需要你明确写进规范大模型的能力上限其实取决于你描述需求的下限。为了减少这种情况我在写完规范后会做一个反向检查把自己当作一个极端的测试人员逐条问规范里有没有覆盖空值、重复值、越界值、并发、时间边界、权限边界这几类情况。跑一遍这个问题清单往往能救回来一大批隐藏 bug。AI确实能帮你写代码但需求完整性这件事目前没有任何工具能替你兜底。4.4 与Git/CI协作时的一些坑最后说下版本管理。SDD模式会带来两类文件变更规范文件和代码文件。在多个分支并行开发时很容易出现代码是新规则、规范还是旧规则或者反过来规范更新了、代码忘了让AI同步的状态。我现在的做法是把 spec/ 目录和测试目录一起纳入Code Review范围并且在CI流程里加一步规范格式校验以及规范和测试映射完整性的检查。Kiro IDE自己会提供一个规范差异对比视图我建议不要跳过它直接看Git diff因为规范变更影响的是一整片代码生成逻辑只靠肉眼在代码层面找diff很容易漏掉隐性的关联改动。另一个版本管理的细节是在合并分支之前最好先让Kiro执行一次全量同步动作让所有规范重放一遍生成逻辑看有没有因为某个分支改动导致其他模块的测试挂掉。这个动作听起来费时但在依赖关系比较深的项目上非常值得它相当于用一次AI智能体的全项目扫描替代了传统开发中最耗时的人工回归测试。5. 我实际用了SDD之后的变化以及几个扩展建议5.1 个人开发者的收益从写得快到改得稳如果只谈体验变化我认为SDD模式让我从追求AI生成速度快转向了追求需求变更稳。过去一个AI辅助项目最怕的是代码量很大但没人说得清楚某块逻辑到底为什么存在。现在取而代之的是每个功能模块都有一份可以被自动追踪的规范文件。做重构时AI搜索到的不是字符串常量而是业务规则本身。Kiro IDE这种把规范和代码持久绑定的思路本质上是在降低系统的认知负载它不解决所有bug但让你把精力集中在决策而不是记忆上。我在实际使用中还有一个明显的感觉写规范这个动作本身就在逼我理清需求。以前接到需求后我经常是打开代码边写边想写到一半发现某个分支逻辑有问题再回头问产品反复折腾。现在我会先在规范里把场景、边界、验收标准过一遍写的过程就已经把需求问清了。大多数需求混乱问题在高保真的规范面前会自己暴露出来甚至不需要AI出场你就能发现产品方描述里的矛盾。5.2 团队协作层面的设想与一个收尾心得团队如果能把规范当作评审的核心对象新成员就不需要读几千行代码来理解业务逻辑直接读规范就能快速建立系统认知。另外先改规范还是先改代码这个问题在团队协作中也会自然消失因为标准动作是先改规范。结合Kiro IDE的规范追踪PR描述都可以自动携带本次规范更新—受影响文件的摘要评审效率能提升不少。最后再分享一个我在Kiro IDE里摸索出来的扩展玩法把规范文件当成提示词库。因为规范写得足够结构化它实际上就是给大模型的最优上下文。将来不管出来新AI工具还是新模型只要你手里有一份贴合业务的规范集它立刻就能接上你的业务而不是重新去理解一堆零散文件。对我来说这是SDD最被低估的长期价值。这一路用下来最大的体会就是AI编程的天花板不在模型而在你把需求描述清楚的能力。先写规范再写代码短期看是多了一道工序长期看是让工具真正听懂了你的业务。 
长河君 · 2026/10/13 7:10:26 · 阅读 1.2k Kiro IDE深度实践：规范驱动开发如何重塑AI编程工作流
最近我把主力开发环境切到了Kiro IDE起初只是好奇它把AI智能体塞进编辑器之后到底能做到什么程度结果用下来最大的感受不是生成代码多了而是自己的开发方式被改变了。它正在把一种叫规范驱动开发SDD的方法变成IDE里的日常操作简单点说就是先写一份人能读、机器能验证的行为规范围再让AI照着这份规范围去写实现。这篇文章会把Kiro IDE里这套SDD工作流的原理、完整实操过程和踩过的坑都整理出来适合正在用或准备用AI编程工具做真实项目的开发者参考不管你是被AI生成的半成品代码折磨过的老手还是刚接触智能编程的新人都能从中得到一些能直接落地的经验。1. 从让AI猜需求到让AI照着做为什么SDD是必然方向1.1 没有规范时AI编程卡在哪先从一个特别常见的场景说起。过去很长一段时间AI编程工具给大多数人的体感就是高级自动补全你写了一个函数名、一段注释模型把你后面可能写的那几行推出来。遇到样板代码确实快但一碰到真正的业务逻辑立刻就露馅了。因为模型根本不知道你这个模块要满足什么业务规则不知道哪些分支必须存在不知道异常情况要怎么兜底。它只能根据训练数据里大多数人会怎么写来猜而猜出来的东西往往表面上能跑实际上边界条件一团糟。我在自己维护的一个模拟库存管理平台里试过最典型的翻车场景让某个AI助手直接写一个订单状态流转接口。它写出了非常标准的增删改查代码数据库表结构也搭好了但完全没有处理已取消订单不能再流转到已发货这种业务约束。代码在语法上是完美的在业务上是错的。这种错是最危险的因为它不会直接崩溃而是等到某一天一个用户触发了非法状态流转数据乱掉之后你才开始追查到底是哪个过滤条件漏了。传统IDE里你还能通过断点慢慢查可AI生成的一两百行代码你根本不熟悉它的思路排查成本比手写还高。这个问题的根子在于人和AI之间没有一份合同。人脑里有一种模糊的需求预期AI的训练数据里有一套通用的代码模式两者相遇之后AI只能靠猜。你不给它明确的事实输入它当然只能给你最可能出现的普适答案而不是最符合你业务的那个答案。所以后来我越来越认同一个判断AI编程真正要解决的瓶颈不是生成能力而是怎样让生成的东西有据可依。1.2 规范驱动开发SDD想解决的核心矛盾规范驱动开发也就是Spec-Driven Development简称SDD。它的思路不算新鲜简单来说就是先把需求固化成一份结构化的行为规范Spec里面写清楚功能场景、输入输出、验收标准、边界约束然后让AI基于这份规范去生成或者修改代码。用装修来打比方的话以前你请施工队AI干活你只给了一句我想要个好看点的客厅施工队自由发挥完你觉得不是你要的SDD则是先画出施工图——墙体怎么砌、插座在哪里、电线怎么走全标清楚施工队照图施工最后你用图纸验收。AI不再用猜规范就是人和机器之间的共享合同。那为什么SDD这两年又重新被重视关键是大模型对结构化文本的理解能力上来了。以前所谓的规则驱动开发更像模板填充你给一份特殊格式的文档程序按正则把字段抠出来套代码模板这既不能理解语义边界也不能生成复杂逻辑。但当大模型能真正读懂一段自然语言写的行为约定之后规范才具备了成为开发输入的资格。AI不再是执行模板的机器而是能根据规范要求主动设计函数结构、数据关系、异常处理路径的工程师助理。SDD真正想解决的核心矛盾是需求描述的模糊性和AI生成能力的无限性之间的错配。AI生成能力越强模糊需求被固化成错误代码的风险就越大。以前人写代码脑子里模糊一点写的过程会逼自己理清逻辑现在AI写代码它不会觉得模糊是个问题它会把模糊当作自由发挥的空间于是错误被大规模、高效率地制造出来。SDD就是在生成能力前面加一道闸门先让你把话说清楚再让你享受生成效率。1.3 为什么偏偏是IDE来承载这套闭环这就要提到Kiro IDE的设计取舍了。它不是把AI当作一个聊天窗口挂在侧边栏而是把AI接入到代码编辑、测试运行、文件变更追踪这些核心链路里。SDD真正落地起来是一整套写规范—生成代码—跑测试—改规范—再生成的循环这个循环只有在IDE里才能形成最短路径。如果你把它拆成命令行工具或者一个在线网站每走一步都要切换上下文人根本坚持不下去。我也试过在某个聊天式AI工具里让模型先写规范再写代码模型确实会输出一份规范文档但那只是一个远程对话窗口里的文本和当前项目没有任何绑定关系。规范写完就躺在聊天记录里不会触发文件变更、不会关联测试、不会在项目树里形成一个可被检索的实体。Kiro IDE把规范文件当作一等公民之后整个体验就完全不同了。项目里有一个独立于代码目录的 spec/ 空间每一份规范都能和实现文件建立关联修改规范时IDE会列出受影响文件生成代码时IDE会在规范条目和函数定义之间建立索引。这听起来像是小事但在真实项目中这种绑定关系决定了你愿意不愿意持续用SDD。如果每次都要手动去找这个规范对应哪个模块用不了两天你就会放弃。只有当IDE把追溯成本降到零SDD才从小众方法论变成了日常操作。2. 核心机制拆解Kiro IDE里一份Spec是怎么驱动整个开发的2.1 一份可执行的Spec应该包含哪几个部分先给一份我自己在用的最小模板。要写出一份能真正驱动AI的规范至少包含五个部分功能场景、输入与状态、行为规则、边界与异常、验收标准。不是说要写成长篇大论的需求文档而是要把握一个尺度——把条件和结果说清楚把具体实现留给AI。拿用户登录功能举例规范大致可以这样写# 用户登录行为规范 ## 功能场景 - 用户使用邮箱和密码进行登录 - 登录成功后系统返回带用户身份的访问令牌 ## 输入与校验 - email 必须符合邮箱格式 - password 长度不得低于 8 位 ## 行为规则 - 密码错误时返回统一错误码 AUTH_001 - 连续失败 5 次后账号进入 10 分钟锁定状态 ## 边界与异常 - 不存在的邮箱与错误密码走同一个错误响应防止用户枚举 - 锁定期间即使密码正确也拒绝登录 ## 验收标准 - 上述规则全部有自动化测试覆盖 - 并发登录同一账号不产生竞态这份规范的核心作用是把产品经理脑子里的假设全部摆到台面上。很多人写代码时其实没想清楚这些前提结果AI只是在代码生成层面代劳需求假设错误照样会被实现进代码里。比如并发登录不产生竞态这句话如果不写AI大概率不会主动去想并发问题一旦写了它就会去考虑数据库锁、原子更新、幂等表这些机制。规范先立住后面所有生成和修改都有了锚点AI不会在你以为它懂但实际它不懂的地方翻车。2.2 从Spec到代码AI的映射逻辑接下来是Kiro IDE里最关键的一步AI拿到规范之后怎么把它变成实现。我实测下来它并不是直接把整份Markdown翻译成代码而是先做结构映射。比如看到用户登录行为规范它就会尝试定位项目里已有的认证模块如果项目还是空的它就根据规范新建对应的路由、服务、存储层文件。然后它把行为规则里的每一条对应到具体函数或守卫逻辑上比如连续失败5次锁定这种规则会被翻译成一次登录失败的计数和状态记录逻辑而锁定期间即使密码正确也拒绝登录则会被实现成一个前置条件判断在验证密码之前就拦住请求。这一步的实际价值在于可追溯。Kiro IDE会在规范里每个小节和生成的代码之间建立关联索引你点规范里的某一条IDE能高亮对应实现代码的位置。真正产生增量价值的不是它帮你写出了500行代码而是这500行代码里每一条规则都有对应的校验点。之后做重构或者加需求你不需要重新通读整个模块点开规范就能知道改动半径在哪里。这种把高密度业务知识结构化并且追踪起来的能力是普通AI编程工具不具备的。2.3 规范追踪与变更联动这套闭环的护城河代码是业务规则的影子需求和实现一旦不同步影子迟早会变形。Kiro IDE对规范与代码之间的关联不是一次性生成完就结束的。后续修改代码时它会提醒你这个函数的实现偏离了规范中的条款A当你修改规范中某句话时它会在变更面板中列出受影响的文件清单并自动生成一轮按新规范调整代码的建议。这就像把传统IDE里的引用查找升级成了业务规则追踪。举个具体例子。我在一个模拟的电商项目里把未支付订单在15分钟后自动关闭改成24小时后才关闭。如果没有规范我需要手动搜索所有跟订单超时相关的代码搜索15分钟、搜索定时任务、搜索订单状态常量很容易漏掉隐藏在某个查询语句里的时间判断。而在Kiro IDE里我只要在Spec里把这个时间阈值改掉再补上新的验收用例AI会自己定位到定时任务、数据库状态字段、查询接口等所有关联位置挨个把逻辑与注释同步更新。这个过程不是简单的全局替换它会根据上下文判断哪些地方需要改哪些地方可以保持不变这种判断只有结合了全项目索引和语义理解的IDE模式才做得到。3. 从零走一遍在Kiro IDE里用SDD做一个真实功能3.1 初始化一个SDD工作区下面进入实操。我自己做的是一个小型REST API服务技术栈选Python。Kiro IDE初始化的方式和普通IDE差别不大但区别在于它会询问你是否启用规范驱动开发工作区。启用后项目结构会多出一个 spec/ 目录里面默认有一个 _template.md 作为规范模板。我建议第一次尝试时不要急着让AI做复杂功能先把目录结构跑通。初始化完之后建议顺手配置一下测试框架和代码格式化工具。Kiro IDE对主流测试框架的集成是现成的在初始化向导里选好pytest、eslint、prettier或者对应的工具链后续的生成—测试循环才不会在环境问题上卡壳。这一步很基础但很多人在上手AI IDE时容易忽略环境一致性结果AI生成的测试在自己机器上跑不过第一反应就是抱怨工具不行实际上是你没把执行环境交代清楚。3.2 手写第一份行为规范然后我在 spec/ 里新建 auth.md把上一节那份登录规范的内容填进去。写规范的时候要注意措辞要精确到可测试比如写返回统一错误码AUTH_001而不是提示用户出错写密码错误连续5次后锁定10分钟而不是限制登录次数。Kiro IDE会在右侧实时渲染规范预览每个小节前面会有对应的复选框表示这条规则是否已被实现代码覆盖这是一个很直观的进度感。我第一次写的时候还是忍不住用了一些模糊词比如登录失败过多应该锁定账号。结果AI生成的代码确实做了锁定但过多被它理解成3次锁定时间是它自己定的5分钟。不是AI不聪明是规范给了它太大的解释空间。从那之后我养成一个习惯凡是涉及数量、时间、状态、错误码、权限角色这些要素必须写一个确定的值。数值是模糊需求的重灾区AI不是业务方它没有义务替你把过多翻译成5次。3.3 让AI按规范生成实现并跑测试写完规范我直接调用IDE里的根据规范实现命令。Kiro会先弹出一个变更预览面板列出它即将创建和修改的文件清单我确认之后才开始写入。这一步很重要它允许你在AI动手之前拦截明显跑偏的方案。比如我第一次用Kiro做登录功能时它规划了一个独立的认证微服务目录但我的项目只是单体服务多出来的抽象层次完全没有必要。我直接在预览面板里把目标目录改掉它后续生成就全部落在合理位置。生成完代码它会自动补一组 pytest 用例。Kiro自动生成的测试开头大致是这种风格import pytest from auth import authenticate def test_login_success_returns_token(): result authenticate(emailuserexample.com, passwordpassword123) assert result.token is not None def test_login_wrong_password_returns_auth_001(): with pytest.raises(AuthError) as exc: authenticate(emailuserexample.com, passwordwrongpass) assert exc.value.code AUTH_001然后它会在内置终端里执行测试。第一次跑通常不会全绿此时Kiro会自己读失败的断言回溯实现代码进行修复直到测试通过。人不需要介入完整的一次生成-修复循环但如果AI反复修不过它会停下来向你提问。遇到这种情况建议先检查规范本身是不是有歧义或者方案选型是不是和项目现状冲突而不是单纯让AI换个写法硬试。3.4 需求变化先改Spec再改代码的标准动作接下来是最关键的标准动作。后来我在这个项目里又加了需求登录成功后要一并返回用户角色信息。我没有直接去找代码实现而是先回到 auth.md在功能场景里补上登录成功返回用户角色在验收标准里增加登录接口响应体中包含 role 字段然后让Kiro执行同步更新实现。它生成的变更首先体现在测试用例上——旧测试会因为缺少role字段而失败新测试会断言role字段存在。AI为了通过新测试去服务层补充用户角色的查询逻辑顺带更新接口文档注释。整个过程需求、代码、测试三者始终保持同步。这种节奏一旦养成你会发现改需求不再是一件焦虑的事。以前改一个字段要全局搜索实体的使用点现在只要规范改一个字AI和测试一起帮你兜住影响面你要做的只是在变更预览里审视一遍AI的方案是否合理。4. 踩坑实录SDD模式用得不好的几个高频问题4.1 规范写太细反而拖慢节奏我最初入坑SDD时最大的问题就是把它写成了详细设计文档。我用自然语言把每个函数的内部流程都描述得清清楚楚AI生成代码时几乎没有发挥空间遇到复杂逻辑改动时规范本身的维护成本变得比代码维护还高。这个问题很隐蔽因为你写的时候会觉得越详细AI越不容易出错但实际体验下来规范一旦详细到调用链路级它就已经不是规范了而是伪代码。你的AI编程效率不仅没有提升反而因为规范里的描述和实际技术实现不匹配陷入反复调整措辞的泥潭。后来我摸清了一条规律规范着重行为约定和验收条件而不是具体实现步骤。你不需要在规范里写先查数据库再查缓存最后拼接返回结果你只需要写接口必须在500毫秒内返回缓存命中时不得访问数据库。AI是工程师它需要的是目标和约束不是逐行指令。给AI留出实现空间它才能真正发挥出比你更熟悉框架细节的优势把实现细节全定死你就等于退回到了用自然语言写业务代码的原始时代。4.2 规范和测试冲突先信谁这是一个很实际的问题。Kiro在某些场景下会先根据自己对规范的理解生成测试而不是严格把规范里的验收标准转成测试。如果它理解偏了就会出现规范和测试打架的局面。我遇到过一种情况规范里明明写了不存在的邮箱和错误密码返回同一个错误码但AI生成的测试里却在断言不存在的邮箱返回提示账号不存在这明显是AI从训练数据里带出来的习惯而不是我的需求。这种冲突出现时我自己的原则是优先信规范。因为测试是AI生成的可能在生成过程中被项目里其他上下文污染而规范是你亲手写的需求承诺。正确做法是先把测试行为向规范对齐可以直接手动修改测试断言也可以让AI按规范重写测试,然后再让AI重新实现代码。注意不要反过来为了迁就一个AI生成的测试去改规范那样属于本末倒置会把需求带偏时间一长规范和真实业务就会越漂越远。4.3 AI理解偏差规范不够细还是模型能力不够另一个高频问题是AI生成的代码看起来正确但漏掉了某个小众边界条件。这时候先别急着骂模型。多数情况下是规范里没有把那一个条件写出来。大模型本质上是模式补全器不是逻辑推导引擎它不会主动把你没写但隐含的条件补全。你说连续失败5次锁定它可能会实现锁定计数的逻辑但不一定想到锁定期间即使密码正确也要拒绝登录你说登录接口要防枚举它可能只做了验证码而不会想到错误信息统一。每一个边界规则都需要你明确写进规范大模型的能力上限其实取决于你描述需求的下限。为了减少这种情况我在写完规范后会做一个反向检查把自己当作一个极端的测试人员逐条问规范里有没有覆盖空值、重复值、越界值、并发、时间边界、权限边界这几类情况。跑一遍这个问题清单往往能救回来一大批隐藏 bug。AI确实能帮你写代码但需求完整性这件事目前没有任何工具能替你兜底。4.4 与Git/CI协作时的一些坑最后说下版本管理。SDD模式会带来两类文件变更规范文件和代码文件。在多个分支并行开发时很容易出现代码是新规则、规范还是旧规则或者反过来规范更新了、代码忘了让AI同步的状态。我现在的做法是把 spec/ 目录和测试目录一起纳入Code Review范围并且在CI流程里加一步规范格式校验以及规范和测试映射完整性的检查。Kiro IDE自己会提供一个规范差异对比视图我建议不要跳过它直接看Git diff因为规范变更影响的是一整片代码生成逻辑只靠肉眼在代码层面找diff很容易漏掉隐性的关联改动。另一个版本管理的细节是在合并分支之前最好先让Kiro执行一次全量同步动作让所有规范重放一遍生成逻辑看有没有因为某个分支改动导致其他模块的测试挂掉。这个动作听起来费时但在依赖关系比较深的项目上非常值得它相当于用一次AI智能体的全项目扫描替代了传统开发中最耗时的人工回归测试。5. 我实际用了SDD之后的变化以及几个扩展建议5.1 个人开发者的收益从写得快到改得稳如果只谈体验变化我认为SDD模式让我从追求AI生成速度快转向了追求需求变更稳。过去一个AI辅助项目最怕的是代码量很大但没人说得清楚某块逻辑到底为什么存在。现在取而代之的是每个功能模块都有一份可以被自动追踪的规范文件。做重构时AI搜索到的不是字符串常量而是业务规则本身。Kiro IDE这种把规范和代码持久绑定的思路本质上是在降低系统的认知负载它不解决所有bug但让你把精力集中在决策而不是记忆上。我在实际使用中还有一个明显的感觉写规范这个动作本身就在逼我理清需求。以前接到需求后我经常是打开代码边写边想写到一半发现某个分支逻辑有问题再回头问产品反复折腾。现在我会先在规范里把场景、边界、验收标准过一遍写的过程就已经把需求问清了。大多数需求混乱问题在高保真的规范面前会自己暴露出来甚至不需要AI出场你就能发现产品方描述里的矛盾。5.2 团队协作层面的设想与一个收尾心得团队如果能把规范当作评审的核心对象新成员就不需要读几千行代码来理解业务逻辑直接读规范就能快速建立系统认知。另外先改规范还是先改代码这个问题在团队协作中也会自然消失因为标准动作是先改规范。结合Kiro IDE的规范追踪PR描述都可以自动携带本次规范更新—受影响文件的摘要评审效率能提升不少。最后再分享一个我在Kiro IDE里摸索出来的扩展玩法把规范文件当成提示词库。因为规范写得足够结构化它实际上就是给大模型的最优上下文。将来不管出来新AI工具还是新模型只要你手里有一份贴合业务的规范集它立刻就能接上你的业务而不是重新去理解一堆零散文件。对我来说这是SDD最被低估的长期价值。这一路用下来最大的体会就是AI编程的天花板不在模型而在你把需求描述清楚的能力。先写规范再写代码短期看是多了一道工序长期看是让工具真正听懂了你的业务。