夜雨聆风先学会说清需求、理顺逻辑、看懂架构、判断能不能用，再让 AI 帮你写代码。
我想做一个自己的待办 App。
不用太复杂。能在电脑上记录事情，也能在手机上查看。可以新增任务，可以打勾完成，最好还能同步，不要今天写在电脑上的东西，明天拿手机一看又没了。
问题是，我不会编程。
我只会描述自己想要什么。现在有 Codex 这样的 AI 编码工具，它不只是聊天，还可以在项目里读文件、改文件、运行命令、解释错误。那我是不是也能试一试？是不是只要把想法告诉它，它就能帮我做出一个真正能用的小软件？
我的答案是：可以，而且值得试。
但先把话说清楚。
这不是一句话让 AI 变魔术。也不是你把一句“帮我做个 App”扔出去，然后坐等一个漂亮、稳定、能上线、还能赚钱的产品自动长出来。
更现实的画面是：你和一个很会写代码、很会查资料、很会跑命令的搭档一起工作。它负责把很多技术活往前推，你负责告诉它目标是什么、哪里不对、怎样才算能用，哪些边界不能碰。
更关键的是，你还要和它一起把逻辑和架构想清楚。
这句话听起来有点技术，但可以先简单理解：
逻辑，是这个应用做事的规则。
架构，是这个应用怎么分工、怎么保存数据、怎么让不同端连在一起。
Vibe coding 不要求你一开始盯着每一行代码，但它要求你参与判断：规则是不是合理，数据要怎么流动，前端、服务端和数据库各自负责什么，最后这个东西到底能不能继续改下去。
这就是这个系列想讲的事。
为什么现在要给小白讲 vibe coding
过去，一个普通人想做软件，第一步经常就被劝退了。
你可能只是想做一个小工具，结果别人告诉你：先学一门编程语言，装开发环境，理解前端和后端，学数据库，学接口，学部署，还要会看报错。
每一个词都不算错。
但对小白来说，这些词堆在一起，就像只是想学做一顿饭，却先被塞了一本厚厚的厨房工程手册。
AI 编码工具出现以后，入口变了。
它不能让软件开发的所有复杂性消失，但它确实把第一段路变短了。以前你可能卡在“我连第一行代码都不会写”。现在你可以从“我到底想做什么”开始，把想法说出来，让 Codex 帮你拆需求、建项目、写代码、解释报错、运行检查。
这是一件挺大的变化。
不是因为程序员不重要了，也不是因为逻辑和架构不重要了。恰恰相反，正因为 AI 可以承担更多代码执行工作，普通人更需要学会看懂软件背后的规则、结构和取舍。
你第一次有机会站到软件开发的门口，看见里面到底发生了什么。
你不必先背完所有语法，才有资格讨论自己的想法。
你可以先从一个小需求开始。
比如：我想做一个个人待办事项应用。
Vibe coding 不是许愿
先说一个容易踩的坑。
很多人第一次用 AI 做软件，会这样提需求：
帮我做一个像某某一样好用的待办 App，要漂亮、稳定、能上线，电脑和手机都能用。
这句话听起来很清楚，其实非常模糊。
谁来用？
第一版必须有什么功能？
哪些功能可以以后再说？
数据放在哪里？
手机和电脑怎么同步？
要不要登录？
哪些数据不能给别人看？
怎样才算“稳定”？
什么时候算“做完”？
这些问题如果不回答，Codex 当然也能开始写。它可能会很快生成一堆页面、按钮和代码，看起来很热闹。
但你很快会发现：能打开页面，不等于软件已经能用；界面看起来漂亮，不等于数据真的保存了；本地电脑能跑，不等于别人也能访问；AI 说“完成了”，不等于你真的可以放心使用。
所以这个系列不会把 vibe coding 讲成许愿。
更准确地说，vibe coding 是一种新的协作入口：
你可以不从代码开始，但不能不从需求开始。
你可以少看代码细节，但不能不看业务逻辑。
你可以让 Codex 选择一些实现方式，但不能完全不管架构边界。
你可以暂时看不懂每一行代码，但不能不亲自试用结果。
你可以让 Codex 帮你修 bug，但要能说清楚哪里出错、怎么复现、你期待它怎样表现。
小白不是不能做软件。
小白只是不能把所有判断都交出去，尤其不能把隐私、安全和上线风险也一并交出去。
少看代码，不等于不看逻辑和架构
这里还要补一句很重要的话：
vibe coding 可以让你少关注代码细节，但不能让你不关注逻辑和架构。
很多小白会以为，既然 AI 会写代码，那自己就只要描述“我要一个什么页面”就够了。这个想法很自然，但很危险。
因为软件真正容易出问题的地方，往往不是某一行代码写得漂不漂亮，而是逻辑有没有想清楚。
比如一个待办 App，看起来只是新增、打勾、删除。
但稍微往深一点，就会冒出很多问题：
• 一个任务到底有哪些状态？ • 已完成的任务还能不能修改？ • 删除是彻底删除，还是先进回收站？ • 没登录时创建的任务，登录后要不要同步到账号里？ • 手机和电脑同时修改同一个任务，听谁的？ • 截止时间过了以后，只是变红，还是要提醒？ • 数据保存失败时，页面要不要告诉用户？
这些不是“代码问题”，而是“逻辑问题”。
如果逻辑没想清楚，Codex 仍然可以写出很多代码，但这些代码会把模糊的地方固定下来，变成后面更难改的问题。
架构也是一样。
架构听起来像很高级的词，其实小白可以先把它理解成一句话：
这个应用分成哪些部分，每个部分负责什么，它们怎么互相说话，数据最后放在哪里。
待办应用为什么要有前端、服务端、数据库？电脑和手机为什么要共享同一份数据？哪些事情放在浏览器里做，哪些事情交给服务端做？如果以后要加登录、同步、提醒，第一版要不要提前留一点空间？
这些问题不要求你一开始给出专业答案。
但你要知道它们存在，并且愿意和 Codex 一起把它们问出来。
所以这个系列开头会专门用 3 篇文章讲软件、岗位、技术和架构。
不是为了把你培养成架构师，也不是为了让你画很复杂的技术图，而是为了让你在 vibe coding 时，不只盯着“页面有没有生成”，还能看见页面背后的规则、数据、边界和连接方式。
换句话说：
代码可以交给 Codex 多写一点，但逻辑和架构不能完全交出去。
这个系列真正要教什么
这个系列不是程序员速成课。
读完以后，你大概率不会突然变成一个能独立开发复杂商业系统的工程师。我们也不会一上来讲一堆框架、命令和高级架构。
这个系列更像一张地图。
它想帮你把几件事情连起来：
第一，软件到底是什么。
一个应用不是一团神秘代码。你可以先把它理解成几个部分：界面、规则、数据和运行环境。代码只是把这些部分组织起来的材料。
第二，做软件的人都在做什么。
为什么一个 App 背后有产品、设计、前端、后端、测试、运维？这些岗位不只是公司里的头衔，它们代表了一套分工：有人想清楚用户要什么，有人设计怎么操作，有人做页面，有人处理数据，有人证明它真的能用，有人让它稳定运行。
第三，服务端、前端、数据库、接口、多端同步这些词到底是什么意思。
你不需要一开始掌握所有细节，但至少要知道它们在整个应用里分别负责什么。否则你和 Codex 对话时，很容易只盯着页面，却忘了数据、权限、同步和发布。
更重要的是，你要开始建立一种判断：哪些是界面问题，哪些是业务逻辑问题，哪些是数据问题，哪些是架构边界问题。只有能把问题分清楚，Codex 才更容易帮你把事情做对。
第四，怎样用逻辑和架构约束 Codex。
我们不会要求你读懂所有代码，但会反复练习几件事：先说清业务规则，再说清数据怎么流动，再说清哪些能力放在服务端，哪些体验放在前端，最后再让 Codex 去实现。这样 AI 写出来的东西才不是一堆临时拼起来的页面，而是一个能继续迭代的小应用。
第五，如何准备和使用 Codex。
Codex 和普通聊天不一样。它不是只在对话框里给建议，而是可以进入一个项目，读取文件，修改代码，运行命令，再根据结果继续调整。等到了第 4 篇，我们会单独讲安装、注册、付费和基本使用。因为这些信息会变化，到时候会以写作时的官方资料为准。
这一篇先不写具体入口和价格，因为工具形态、平台支持和付费方式都会变化。真正写到安装和注册时，我们再按当时官方资料逐项确认。
第六，用一个真实案例走完流程。
我们会从“我想做一个待办 App”开始，一步步走过需求分析、原型设计、技术方案、第一版开发、多端体验、登录同步、测试发布和使用复盘。
不是只看一个演示页面。
而是尽量让你看见一个小软件从想法到运行、从能用到更好用的完整过程。
为什么选个人待办事项应用
因为它足够简单。
每个人都知道待办事项是什么：写下一件事，设置一个时间，完成以后打个勾。
但它又足够完整。
哪怕只是一个小小的待办应用，也会碰到软件开发里的很多基本问题：
• 页面怎么设计？ • 任务数据怎么保存？ • 新增、修改、删除怎么处理？ • 电脑和手机怎么看到同一份数据？ • 要不要登录？ • 别人的待办为什么不能看到我的？ • 本地能运行以后，怎么发布到网上？ • 发布前怎么确认没有把不该公开的数据放出去？ • 上线以后发现不好用，怎么继续改？
这就是它适合作为入门案例的原因。
它不会一上来就把你拖进复杂业务，但又不会简单到只剩一个玩具按钮。
第一版我们也会刻意控制边界。
不做团队协作。
不做付费会员。
不追求应用商店上架。
不急着加入 AI 自动规划任务。
第一版只追求一件事：做出一个自己能用、能理解大致结构、以后还能继续改的小应用。
这比“做一个看起来很厉害但你完全不知道怎么维护的东西”更重要。
你和 Codex 怎么分工
很多人使用 AI 工具时，会不自觉站到两个极端。
一种是把 AI 当万能员工：我说一句，你全部搞定。
另一种是把 AI 当普通搜索框：我问一句，你答一句，剩下还是我自己痛苦摸索。
这两个都不太适合 vibe coding。
更好的分工是这样的：
注意这里最重要的一点：
你不是 Codex 的老板，也不是它的观众。
你更像这个小应用的产品负责人和第一位用户。
产品负责人不一定亲自写代码，但要知道自己要什么。第一位用户不一定懂技术细节，但要亲自试用，知道哪里顺手、哪里别扭、哪里根本不能用。
Codex 可以帮你把很多事情做出来，但它不能替你生活。
它不知道你每天什么时候记待办，喜欢在电脑上整理还是在手机上打勾，能不能接受登录，需不需要提醒，什么颜色看着舒服，什么操作让你烦。
这些判断，仍然要从你这里来。
读这个系列之前，需要准备什么
你不需要先学完一门编程语言。
但最好准备几样东西。
第一，一台你可以折腾的电脑。
因为后面会涉及安装工具、打开项目、运行本地应用。只用手机读文章当然可以，但真正跟做，还是需要电脑。
第二，一个可以注册相关服务的账号。
Codex 的具体安装、注册、付费、平台支持，后面会专门讲。这里先提醒一句：这类信息变化很快，不要只看过期截图，要以当时官方页面为准。
第三，一个真实的小需求。
可以先跟着这个系列做待办应用。等你理解流程以后，也可以换成自己的小工具：记账本、课程计划、客户记录、健身打卡、读书清单，都可以。
第四，一点耐心。
软件开发不是“生成一次就结束”。你会遇到报错，会发现界面不好用，会发现刚才以为说清楚的需求其实没说清楚。没关系，这些不是失败，而是做软件的正常过程。
第五，基本的安全意识。
练习时不要把真实密码、银行卡信息、公司生产账号、客户隐私数据随便交给 AI。刚开始做个人工具，尽量用模拟数据和练习账号；准备发布前，也要检查页面、接口、配置和示例数据里有没有不该公开的内容。
这不是吓唬你。
只是从第一天开始，就把边界感养起来。
读完这个系列，你应该得到什么
如果你一路读下来，并且愿意跟着做，最后得到的不应该只是一堆文章。
你应该至少得到七样东西。
第一，能听懂软件开发里的常见词。
别人再说前端、后端、接口、数据库、部署、多端同步，你不会马上觉得那是一堵墙。
第二，能把一个模糊想法拆成需求。
你会知道怎样描述用户、场景、功能、边界和验收，而不是只说“帮我做个好用的 App”。
第三，能和 Codex 开始一个项目。
不是只把它当聊天机器人，而是让它帮你读文件、改项目、跑命令、解释结果。
第四，能看懂一个小应用的大致结构。
你不一定看懂每一行代码，但你会知道页面在哪里、数据大概怎么保存、服务端和前端怎么配合。
第五，能开始判断逻辑和架构是否合理。
比如任务状态有没有漏，数据同步会不会乱，哪些规则应该放在服务端，哪些体验应该放在前端。你不需要一开始答得很专业，但至少不会只盯着页面颜色和按钮位置。
第六，能把一个待办应用从本地运行推进到可访问版本。
它可能还不完美，但至少不是停留在想象里。
第七，能根据真实使用继续迭代。
你会知道 bug、体验问题、新需求不是一回事，也会知道下一版应该怎么排优先级。
这些能力放在一起，比“AI 一次帮我生成了多少代码”更有价值。
因为真正长期有用的，不是某一次生成结果，而是你开始拥有一套把想法变成软件的工作方式。
三句话，作为我们的读者契约
在进入正式内容之前，我们先约定三句话。
第一，你不需要一开始会编程，但需要愿意把想法说清楚。
第二，你不需要看懂每一行代码，但需要认真参与逻辑和架构判断。
第三，你不需要一次做出完美产品，但需要亲自试用、验收，并接受从小版本开始迭代。
如果你认同这三句话，这个系列就适合你。
我们会慢慢来。
先认识软件，再认识软件开发分工，再认识前端、服务端、数据库和多端同步。然后准备 Codex，写需求，做原型，定技术方案，开发第一版，做多端体验，加登录和同步，测试并上线，最后根据真实使用继续改。
听起来步骤不少。
但它们不是为了把事情弄复杂。
恰恰相反，它们是为了让你知道每一步在解决什么问题。你知道自己走到哪里，就不容易被工具、术语和报错带着乱跑。
先别急着安装，先弄懂软件是什么
很多教程喜欢第一步就让你安装工具。
这个系列不急。
Codex 很重要，工具也很重要，但如果你完全不知道软件由哪些部分组成，一上来安装工具，很容易变成“我按照步骤点完了，但不知道自己在干什么”。
所以我们先从更基础的问题开始。
软件到底是什么？
一个待办事项，从你在页面里输入文字，到它被保存下来，再到你第二天在手机上看到它，中间到底发生了什么？
如果你愿意把“做软件”先理解成一次持续对话、持续试用、持续修正的过程，那么 Codex 就不是一个许愿池，而是一位可以陪你把想法慢慢落地的工程搭档。
下一篇，我们先不装工具，也不写代码。
先从一个最朴素的问题开始：软件到底是什么？
