3 · AI Native：代码是黑盒
AI Native 开发，首先要想清楚"我要什么"。
为什么叫"AI Native"
这门课反复出现的"AI Native"，其实是两个词拼在一起，各自都有讲究。
先说 AI：这次不一样的地方，是执行这件事本身，交给了 AI——不再是查资料、补代码那种辅助，落地的活儿它真能包办。这就是"AI"放在最前面的原因：它不是效率工具，而是真正动手做事的那个人。
再说 native：英文里指"与生俱来"——native speaker 不用先想语法再翻译，语言是本能；cloud native 也不是"搬去云上"，而是"从第一行起就按云的方式设计"。AI Native 同理：不是把 AI 接到旧流程里，而是从一开始就假设 AI 是那个动手写代码的人，你的角色因此被重新设计。
想清楚这一点，你就知道这门课要练的是什么——不是怎么使唤 AI，而是AI 负责实现之后，你这个人该干什么。
很多人第一次用 AI 开发，会觉得最重要的是告诉它怎么实现。但 AI Native 里最重要的第一步，是想清楚：我到底想要什么？
比如"我想要一个能记录待办事项的应用"——这句话已经能让 AI 动手，但还很基础。往下追一层：只存在这台设备上吗？换个设备还看得到吗？如果不只自己用、给团队用呢——谁能看、谁能改、任务怎么分配？
需求一路深挖下去你会发现，真正要想清楚的从来不是"我要一个 Todo 页面"，而是：
“我希望用户通过这个工具解决什么问题，并获得什么样的体验。”
这是 AI Native 和传统开发最大的区别：过去从"要做什么页面、写什么代码"想起；AI Native 从"要解决什么问题、什么结果才算成功"想起。AI 能包办大量实现，但替代不了你理解需求、判断方向。
所以 AI Native 的核心能力，不是让每个人都变成程序员，而是让每个人都能把自己的想法讲清楚。
从「问答题」到「选择题 + 判断题」
过去写代码像做问答题——面对空白，从零默写出答案，难。
AI 时代更像做选择题 + 判断题：
- 选择题：AI 给你的方案，通常比你实际需要的更多——你要做的不是"随便选一个"，而是做取舍。
- 例：你说要个 Todo，AI 可能顺手就把标签分类、优先级排序、提醒通知、多端同步都一起做上了。这时候你要判断：这些现在都需要吗？哪个留下、哪个砍掉、哪个往后放？
- 判断题：AI 交出结果，你负责判断对不对——不只是"符不符合我要的样子"，还要多问几层：
- 符合预期吗？这个页面是我想要的样子吗？这个任务列表刷新后还在吗？
- 有没有过度实现？我只要一个能用的列表，它是不是顺手做了一套复杂的权限系统？
- 有没有过度思考？为一个还没发生的场景提前绕了一堆弯路、加了用不上的复杂度？
- 稳不稳？刷新页面、断网重连、多点几次按钮，会不会就坏了？
- 这些不用你自己一条条去查——让 AI 自己给出判断依据、自己去验证，你负责追问，判断它给的答案站不站得住脚。
选择和判断，比默写容易得多，而且这才是「产品负责人」真正的工作。
💡 这个「选择题 + 判断题」的思路，会贯穿整门课的每一个功能。看到它反复出现，别嫌烦——这就是新时代开发的肌肉记忆。
人和 AI 怎么分工
一句话概括：在 AI Native 开发中，人负责明确目标、提出需求、验证结果；AI 负责完成实现、解决问题，并推动产品最终上线。 说白了就是导演和摄制组的关系——你决定拍什么、这条过不过，AI 扛机器、打光、剪辑。
这种分工贯穿整个研发过程，落到我们要做的 AI Todo 项目里，每个阶段都有具体的样子：
| 研发阶段 | 你负责 | AI 负责 | 落到 AI Todo 项目里 |
|---|---|---|---|
| 确定目标 | 说明想解决什么问题、做一个什么产品 | 分析目标，整理产品方案和实施步骤 | “我要一个能管理日常待办事项的小工具” |
| 明确需求 | 说明需要哪些功能、用户应该如何使用 | 将需求转化为具体功能、页面和交互 | 需要新增、完成、编辑、删除、筛选任务 |
| 开发产品 | 决定先做什么、后做什么 | 创建项目并逐项完成功能 | 先做核心功能，再接数据、加登录、加 AI 拆解，最后打磨上线 |
| 测试验收 | 实际操作产品，判断结果是否符合预期 | 根据测试结果检查和调整实现 | 添加任务后是否出现在列表里？刷新后数据还在不在？ |
| 发现问题 | 说明做了什么、出现了什么、期望什么 | 定位问题原因并完成修复 | “我删除第二条任务，页面却删掉了第一条” |
| 完善体验 | 提出页面、操作和使用体验上的改进 | 优化界面、交互和异常处理 | 任务列表空的时候要有提示文案，不能是一片空白 |
| 上线准备 | 确认功能是否完整，决定是否可以发布 | 完成配置检查和发布准备 | 把新增、编辑、删除、筛选再挨个跑一遍确认没漏 |
| 部署上线 | 验收线上版本是否能够正常访问和使用 | 完成部署，并处理上线过程中出现的问题 | 打开线上地址，看看别人能不能正常打开、正常用 |
| 持续迭代 | 根据实际使用提出新的需求和改进 | 在现有产品基础上继续完善功能 | 用一段时间后，提出"想加个截止日期提醒" |
整个过程中，你不需要理解产品内部是如何实现的，但必须能够判断每个阶段的结果是否正确。当结果不符合预期时，只需要向 AI 说清楚三件事：
💡 我进行了什么操作，实际出现了什么结果，我期望得到什么结果。
你不需要告诉 AI 应该怎样修改内部实现。你负责提出目标、需求和问题，AI 负责找到实现方式、完成修改，并最终把产品交付上线。
小结
AI 负责执行，native 意味着这从一开始就是你思考方式的一部分，而不是事后补丁。你要练的，是把「问答题」换成「选择题 + 判断题」——AI 给方案你做取舍，AI 交结果你做判断；从确定目标到部署上线，每个阶段都是这套分工的具体应用。这就是这门课要你养成的新肌肉记忆。
这一部分的收尾
到这里，你还没写一行代码，但已经完成了最重要的准备——换脑子，装上 AI Native 的思维方式：
- 做软件的本质是把需求变成能运行、能验证、能迭代的系统。
- 代码是黑盒：你不打开它，只在需求和结果两头工作。
- 用一个循环推进：说清预期 → 看结果 → 修正，转到满意为止。
- 你负责的两件事：选择题（替 AI 做决定）+ 判断题（验收结果符不符合预期）。
- 全程一个项目：AI Todo 助手；工具只需一个：Claude Code 或 Codex。
带着这套 AI Native 思路，下一部分我们就把工具真正装起来、跑起来。