如果你在 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-Enabled（AI 增强） | AI-Native（AI 原生） |
|---|---|---|
| 出发点 | 已有产品或流程，追加 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 ├──
