夜雨聆风一个任务从写下到保存，背后其实经过了界面、规则、数据和运行环境。
上一篇我们说，vibe coding 不是许愿。
你可以不从代码开始，但不能不理解逻辑和架构。你可以让 Codex 多写一点代码，但不能把“这个软件到底怎么工作”完全交出去。
那第一步要理解什么？
不是编程语言。
不是框架。
也不是命令行。
第一步是先弄明白：软件到底是什么。
我们从一个最普通的动作开始。
你打开一个待办 App，在输入框里写下：
周五前整理发票
然后点一下“添加”。
你看到页面上多了一条任务。看起来，这件事很简单。
但在软件内部，已经发生了好几件事：
• 页面接收了你输入的文字。 • 软件判断这条任务能不能保存。 • 任务被整理成一条数据。 • 数据被保存到某个地方。 • 页面刷新，让你看到新任务。 • 下次打开时，软件还要把它再读出来。
所以，软件不是一团神秘代码。
它更像一个能接收操作、执行规则、保存数据、持续运行的小系统。
对纯小白来说，可以先记住一个简单模型：
软件 = 界面 + 规则 + 数据 + 运行环境
这四个词，就是我们理解软件的第一张地图。
软件不是一个页面
很多人第一次用 AI 做软件，会先盯着页面。
页面好不好看？
按钮圆不圆？
颜色顺不顺眼？
列表排得整不整齐？
这些当然重要。用户最先看到的就是页面。如果页面乱，用户很快就不想用了。
但页面不是软件的全部。
一个页面可以很漂亮，却完全不保存数据。你点了“添加”，看起来多了一条任务，但刷新页面以后就没了。
一个页面可以能打开，却没有正确规则。你什么都不输入，也能添加一条空白任务。
一个页面可以在你电脑上能跑，却不能让别人访问。你发给朋友一个地址，朋友打开只看到错误。
这就是为什么小白做 vibe coding 时，不能只说：
帮我做一个漂亮的待办页面。
更好的说法是：
帮我做一个能新增、保存、显示、完成待办事项的小应用。任务标题不能为空，添加后刷新页面仍然存在。
这两句话的差别很大。
前一句只在说页面。
后一句开始描述软件。
界面：你和软件打交道的地方
界面，是用户看见和操作的地方。
在待办 App 里，界面可能包括：
• 输入任务的文本框。 • 点击添加的按钮。 • 展示任务的列表。 • 标记完成的勾选框。 • 查看全部、未完成、已完成的筛选按钮。 • 编辑任务的弹窗或页面。
你可以把界面理解成一家店的门面和柜台。
用户从这里进来，在这里点单，在这里看到结果。
所以界面不是可有可无的装饰。它决定用户能不能顺利完成动作。
但是，评价界面时，不要只说“好看”或“不好看”。
对一个待办 App 来说，更重要的问题是：
• 我从哪里输入任务？ • 我怎么知道任务添加成功了？ • 我怎么标记完成？ • 我怎么找到已完成任务？ • 我误删以后有没有机会确认？ • 手机上手指点起来会不会太小？
这些问题都不需要你会写代码。
你只要像真实用户一样试用，就能发现很多问题。
这也是小白和 Codex 协作时最容易上手的部分：先从界面和操作反馈开始。
但别停在这里。
界面只是第一层。
规则：软件怎么判断事情能不能做
规则，是软件做事的逻辑。
你可以把它理解成：
当用户做了某个动作，软件应该怎么判断、怎么处理。
待办 App 看起来简单，但规则一点都不少。
比如：
• 标题为空时，能不能添加？ • 标题太长时，要不要限制？ • 一条任务完成以后，还能不能编辑？ • 删除任务时，要不要二次确认？ • 截止日期已经过去，要不要变红？ • 已完成任务默认显示还是隐藏？ • 搜索时，要不要同时搜备注？
这些不是代码细节。
这些是软件的使用规则。
如果规则没有说清楚，Codex 也能继续写。它会根据自己的判断做默认选择。
但默认选择不一定符合你的习惯。
比如你说“删除任务”，Codex 可能直接删除。可你真正想要的是先弹出一个确认，避免手滑。
再比如你说“完成任务”，Codex 可能让任务从列表里消失。可你真正想要的是它留在列表里，只是变成灰色，方便你回顾今天做了什么。
这就是为什么第 0 篇反复强调：vibe coding 可以少看代码，但不能不看逻辑。
你不需要知道代码里用了哪个函数。
但你要知道软件应该按什么规则处理事情。
数据：软件要记住什么
数据，是软件需要记住的内容。
对待办 App 来说，一条任务看起来只是一行字：
周五前整理发票
但软件真正要保存的，通常不止这一行字。
它可能还要保存：
• 任务标题。 • 备注。 • 截止日期。 • 优先级。 • 是否完成。 • 创建时间。 • 更新时间。 • 属于哪个用户。
这些东西合在一起，才是一条完整的任务记录。
如果没有数据保存，页面再好看，也只是临时纸片。
你打开页面，写了几条任务，看着很开心。结果刷新一下，全没了。
这就不是一个真正可用的待办应用。
小白怎么判断数据有没有真的保存？
可以用几个很朴素的问题：
• 我添加任务后，刷新页面还在吗？ • 我关掉浏览器再打开，还在吗？ • 我修改标题后，旧标题会不会又冒出来？ • 我标记完成后，下次打开还是完成状态吗？ • 如果换到手机上，能不能看到同一条任务？
这些问题很简单，但非常重要。
很多 AI 生成的演示页面，第一眼看起来像应用，实际只是“看起来有数据”。只要刷新页面，刚才的内容就没了。
所以你以后和 Codex 说需求时，不要只说：
页面上有一个任务列表。
要补一句：
任务需要被保存，刷新页面后仍然存在。
这一句，会把“页面展示”推进到“软件记住”。
运行环境：软件在哪里活着
运行环境，是软件真正被打开、执行和访问的地方。
这个词听起来有点技术，但可以先用一句话理解：
软件不是写出来就会自动活着，它必须运行在某个地方。
一个待办应用可能运行在你的电脑浏览器里。
也可能运行在手机浏览器里。
它的数据可能存在浏览器本地。
也可能存在一台服务器的数据库里。
如果只是你自己电脑上能打开，那叫本地运行。
如果别人也能通过网址访问，那就需要发布到网上。
如果电脑和手机都要看到同一份数据，那就需要它们连接到同一个数据来源。
这就是为什么很多小白会遇到一个困惑：
明明 Codex 已经帮我做出来了，为什么只有我电脑上能看？
因为“能在本地运行”和“能让别人访问”不是一回事。
前者说明软件在你的电脑上活着。
后者说明它被放到了一个别人也能访问的环境里。
后面讲发布上线时，我们会再展开这件事。现在先记住一点：
软件要能用，不只要有代码，还要有运行的地方。
一条待办从输入到保存，经历了什么
现在，我们把四个部分合起来看。
还是那条任务：
周五前整理发票
完整旅程大概是这样：
第一步，你在界面输入任务。
输入框接收了文字，按钮等待你点击。
第二步，你点击“添加”。
界面把这个动作交给程序处理。
第三步，规则开始检查。
标题是不是空的？有没有超过长度？截止日期格式对不对？
第四步，程序把它整理成数据。
这条任务可能会变成一条记录：标题是什么，是否完成，什么时候创建，属于谁。
第五步，数据被保存。
可能保存在浏览器本地，也可能发送到服务端，再写进数据库。
第六步，界面更新。
你在列表里看到刚刚添加的任务。
第七步，下次打开时再读取。
软件从保存位置把任务取出来，重新显示到页面上。
这就是一个很小的软件闭环。
你不需要看懂每一行代码，也可以用这条旅程检查一个软件是不是靠谱：
• 界面有没有接住操作？ • 规则有没有正确判断？ • 数据有没有真的保存？ • 环境能不能稳定运行？
如果这四件事都通了，一个小应用才算开始“活起来”。
为什么这对 vibe coding 很重要
因为 Codex 很擅长写代码，也很擅长快速生成页面。
但你给它的问题越模糊，它越容易做出一个“看起来像”的东西。
你说：
做一个待办页面。
它可能给你一个漂亮列表。
你说：
做一个待办应用。用户可以新增任务，标题不能为空；任务要保存，刷新后仍然存在；已完成任务可以筛选；第一版先在本地浏览器运行。
这时，Codex 得到的就不只是页面要求，而是一个软件要求。
所以，以后你描述需求时，可以先问自己四个问题：
第一，用户要看到什么？
这是界面。
第二，软件要按什么规则处理？
这是逻辑。
第三，哪些数据要保存？
这是数据。
第四，它要在哪里运行，给谁访问？
这是运行环境。
你会发现，这四个问题一问出来，你和 Codex 的对话会立刻变得更清楚。
你不再只是说“帮我做个东西”。
你开始像一个小产品负责人一样，说清楚这个软件要怎么工作。
结尾：先看懂软件，再谈写代码
软件不是一团神秘代码。
也不是一张漂亮页面。
它更像一个小系统：
• 界面负责让你操作。 • 规则负责让它做出判断。 • 数据负责让它记住。 • 环境负责让它运行。
代码很重要，但代码不是理解软件的唯一入口。
对小白来说，更好的起点是先看懂这四件事。
以后当你让 Codex 帮你做一个功能时，不妨先用这四句话描述：
• 用户要看到什么？ • 软件要按什么规则处理？ • 哪些数据要保存？ • 它要在哪里运行、给谁访问？
这就是你进入软件开发世界的第一张地图。
当界面、规则、数据和环境变多、变复杂，就会自然出现更多分工：有人负责想清楚需求，有人负责设计界面，有人负责处理数据，有人负责测试，有人负责发布和维护。
下一篇，我们就聊聊：
做软件的人到底都在做什么？