AI-Native开发范式：从Spec-Driven Agent Loop到最小项目实践

如果你在 Hacker News 上刷到一条Show HN: YC Startup School, but AI-Native第一反应大概率是把 YC 创业课用 AI 重讲一遍给每个学员配一个 AI 导师还是用 AI 自动生成商业计划书这三种猜测都停留在“AI 增强”层面没有触到真正的变化。AI-Native 的意思不是“在旧流程上加几个 AI 按钮”而是把整条链路从第一性原理重新想一遍当 AI 能写代码、做调研、跑实验、生成报告时创业教育应该教什么创业者的时间应该花在哪里以及软件开发这件事本身应该如何组织。这篇文章不打算复述某个具体项目的功能清单而是以这个项目标题为切入点把它放到更大的技术背景里拆解。我们会先讲清楚 AI-Native 和 AI-Enabled 的本质区别再落到一个有代表性的开发范式——Spec-Driven Agent Loop然后给你一套可以直接复制运行的最小示例。读完以后你可以拿着一份产品规格、一个 Agent 角色定义、一个编排脚本亲手跑通一个“AI 原生小项目”并知道怎么验证它、怎么排查它、怎么避免最常见的坑。1. AI-Native 到底在说什么从工具层到生产范式先澄清一个近几年被说烂的词。很多人把 AI-Native 当成“用了 AI 就是 AI-Native”这是最容易踩的认知误区。用 AI 给搜索结果加摘要是 AI-Enabled把产品设计成“用户输入意图、AI 生成候选结果、系统自动验证、人来决策”才是 AI-Native。区别不在 AI 用得多不多而在“人的角色”和“流程的结构”是否发生了根本改变。传统软件开发的流程结构是“人写代码、人写测试、人部署、人运维”AI 最多是副驾驶帮你补全函数、解释报错。AI-Native 开发的结构变成了“人写规格、AI 生成实现与测试、工具链自动验证、人负责判断和回滚”。这里人的职责从“亲手实现”前移到了“定义意图、评估产物、控制风险”而 AI 的职责从“辅助者”变成了“生产力流水线中的主要执行单元”。这个变化看起来只是分工调整实际上会重构团队的技能要求、代码仓库的组织方式、测试策略甚至成本模型。维度AI-EnabledAI 增强AI-NativeAI 原生出发点已有产品或流程追加 AI 功能从第一性原理重新设计整条链路执行主体人负责主要执行AI 做辅助Agent 负责生成候选产物人负责决策核心瓶颈人手不够、时间不够判断质量、验证成本、风险控制典型产物搜索摘要、智能客服、代码补全规格驱动的自动生成、自动验证、持续评估体系失败方式功能不实用、没人用跑得很快但验证缺失错误被规模放大用这个框架去看YC Startup School, but AI-Native你就能明白为什么它大概率不是一个课程视频摘要工具。真正 AI-Native 的形态是把创业教育中“动手执行”的部分交给 Agent把“判断与决策”的训练放到核心位置。一个学员不用再花两周手写一个粗糙的 MVP而是用一下午写清楚规格让 Agent 生成原型再用工具链验证它是否满足验收标准。省下来的时间恰好是过去最稀缺、也最难训练的能力在信息不足时判断什么值得做。2. 传统创业课教什么AI-Native 改什么Y Combinator 的 Startup School 之所以出名是因为它把创业这件事拆成了一套相对固定的动作验证想法、做用户访谈、搭 MVP、看指标、找人、融资。这些动作背后的假设是创业者必须亲手完成大部分执行才能在过程中建立对业务的真实体感。这个假设在 AI 出现之前是对的因为执行本身就是最大的学习成本也是筛选创业者的主要手段。AI-Native 的创业教育假设完全不同。当一套 MVP 可以在几小时内生成当用户访谈记录可以自动聚类和总结当一个团队可以用 Agent 并行跑十个想法验证时执行不再是稀缺资源判断才是。于是课程内容必须跟着变怎么把一个模糊想法写成可验收的规格怎么设计一组能区分真需求与伪需求的实验怎么评估 Agent 生成的产物怎么在快速迭代中守住质量、成本和安全边界。这不是说创业者可以完全不懂执行。恰恰相反AI-Native 对“懂”的定义变了你不必会写每一行代码但你必须能读懂生成代码的关键逻辑、能判断测试覆盖是否充足、能看出 Agent 的报告里哪些结论是编造的。所以更准确的说法是AI-Native 创业教育并不是抛弃动手能力而是把“动手”从“写代码”重新定义为“构造可验证的实验”。这也解释了为什么最近业界开始流行所谓 AI-Native SDLC Playbook——它不是某个公司的独家秘籍而是整个行业在摸索一套与 AI 生产力匹配的软件生命周期方法论包括规格怎么写、Agent 怎么分工、CI 怎么验证、回归怎么跑。3. 一个 AI-Native 项目的原子单元Spec-Driven Agent Loop如果你看足够多的 AI 原生项目会发现它们都共享一个相似的循环我把它称为 Spec-Driven Agent Loop。这个循环是 AI-Native 开发的原子单元理解它就能理解绝大部分 AI 原生工具的架构思路。循环的第一步是“写规格”。这里的规格不只是一段需求描述而是一组可验收的断言输入是什么、输出是什么、边界条件是什么、成功标准是什么。规格由人类负责因为它是产品意图的最终载体。第二步是“加载上下文”把规格、相关代码库、历史决策记录一起打包给 Agent确保生成结果不会偏离已知事实。第三步是“生成候选产物”由一个或多个 Agent 根据规格产出代码、测试、文档或报告。第四步是“验证”用自动化测试、静态检查、评估集等工具链去检查产物是否满足规格中的断言这一步必须由机器执行因为人类无法在快速迭代中保持一致的判断标准。最后一步是“人工决策”由人决定接受、修改还是丢弃并把决策结果写回规格或上下文形成下一次循环的输入。这个循环和传统敏捷开发最大的区别在哪里传统团队的迭代单位是“任务卡片”每个任务由人实现、人测试、人评审AI-Native 团队的迭代单位是“规格变更”每次变更自动触发 Agent 生成、自动验证人的评审对象从“实现细节”变成了“规格是否准确、验证是否充分”。换句话讲质量守门员从“写代码的人”变成了“规格与验证体系”。这也是为什么很多 AI-Native 项目把 spec 目录放进代码仓库、把验收条件写成机器可读的清单——因为规格已经不只是给人看的文档它同时是 Agent 的输入、测试的基准和回滚的依据。4. 核心流程拆解把 Spec-Driven Agent Loop 落地到自己的项目理论讲完下面是落地。我们用一个小项目来演示整个流程假设你想做一个“AI 客服工单摘要工具”它能接收一份 CSV 格式的工单文件自动按问题类型聚类并输出当日 TOP 3 问题和建议动作。这个项目足够小可以在文章中完整展示又足够真实能覆盖规格、Agent、编排、验证四个环节。4.1 写规格把想法翻译成可验收的句子很多初学者拿到需求就开始写提示词这是 AI-Native 开发里最常见的错误。提示词解决的是“这次生成得对不对”的问题规格解决的是“整个项目什么是正确”的问题。顺序错了后面的每一步都会跑偏。规格里最重要的不是功能描述而是验收标准尽量写成可测试、可量化的句子比如“输入 100 行 CSV 后 10 秒内输出摘要”而不是“系统要快”。可测试的规格才是后面验证脚本能发挥作用的前提。4.2 定义 Agent把任务分给角色Agent 定义文件的本质是给 AI 配置一份“岗位说明书”。它要包含角色职责、技术约束、输出格式和工作边界。比如后端 Agent 的说明里要明确它使用什么框架、生成的文件放哪里、必须提供什么测试。边界尤其重要否则 Agent 会把任务理解成“随便写一段代码”而不是“交付一个可验证的模块”。一份好的 Agent 定义应该让你在三个月后重新运行时仍然能生成结构相似的产物而不是每次都是完全不同的实现。4.3 编排执行让 Agent 按规格干活编排脚本的价值在于让整个流程可重复。你不可能每次都把规格手动复制粘贴到聊天窗口然后人工把输出拷进项目目录。至少要做到读规格、读 Agent 定义、调用模型、把结果写入输出目录。这样每次运行都会留下产物可以 diff可以回滚可以审计。对团队来说可重复的编排脚本还有一个额外好处新人不需要理解整套 prompt 技巧也能通过同一个入口触发生成流程的稳定性不依赖某个人的个人经验。4.4 验证与决策不信任输出只看证据AI 生成的代码里相当高比例能编译通过但逻辑是错的。所以在循环里验证不是可选项而是强制关卡。验证脚本要检查两件事产物是否生成、产物是否满足规格中的关键约束。更完整的项目还会跑单元测试、接口测试和回归评估。记住一个原则AI 输出是候选不是结论只有通过验证并经过人确认的产物才允许进入主线。否则你省下的开发时间会成倍赔在排查生成的逻辑错误上。5. 完整示例一个 AI-Native 最小项目从 0 到 1下面是一个可直接复制的示例。先看目录结构ticket-summarizer/ ├── spec/ │ └── product.md ├── agents/ │ └── backend.md ├── orchestrate.py ├──