夜雨聆风你不需要组一支团队，但要学会从这些角色的角度和 Codex 对话。
上一篇我们说，软件不是只有页面，也不是一团神秘代码。
一个小小的待办 App，背后也有四个部分：
• 界面：用户看见和操作的地方。 • 规则：软件怎么判断事情能不能做。 • 数据：软件要记住什么。 • 运行环境：软件在哪里活着。
理解了这四件事以后，下一个问题就来了：
如果只是做一个 App，为什么现实里会有产品经理、设计师、前端工程师、后端工程师、测试、运维这么多角色？
难道做软件不是“把代码写出来”就行了吗？
不是。
写代码只是其中一部分。
真正做软件，是把用户目标、操作体验、业务规则、数据保存、质量验证和持续运行连成一条可靠的链路。
岗位，就是这条链路上的责任分工。
岗位不是头衔，而是责任边界
小白第一次看到软件团队分工，很容易觉得复杂。
产品、设计、前端、后端、测试、运维。
每个词都像一个陌生部门。
但先别把它们想成公司里的头衔。你可以先把它们理解成几种问题视角：
• 谁来想清楚要解决什么问题？ • 谁来设计用户怎么操作？ • 谁来把页面做出来？ • 谁来处理数据和规则？ • 谁来证明它真的能用？ • 谁来保证它能稳定运行？
这些问题合在一起，才是软件开发。
在大公司里，它们可能由不同的人负责。
在个人项目里，可能只有你和 Codex。
但即使只有你和 Codex，这些视角也不会消失。
你不需要成为六个人。
但你要知道自己什么时候在问哪一类问题。
产品：决定要解决什么问题
产品负责把模糊想法变成清楚需求。
听起来有点正式。换成白话就是：
到底给谁用？解决什么事？第一版做什么？哪些先不做？
比如你想做一个待办 App。
如果只是说：
我想做一个好用的待办工具。
这还不够。
产品视角会继续追问：
• 谁主要使用它？上班族、学生，还是自由职业者？ • 第一版只给自己用，还是准备给朋友用？ • 必须有新增、完成、删除吗？ • 需不需要提醒？ • 要不要搜索？ • 要不要团队协作？ • 要不要账号登录？ • 哪些功能这次明确不做？
你会发现，产品不是“多提功能”。
产品更重要的工作，是做取舍。
第一版如果什么都想要，最后很容易什么都做不好。
对于小白来说，最应该先学的其实就是产品视角：
把想法说清楚，把边界说清楚。
Codex 可以帮你整理需求文档，也可以帮你拆任务。
但它不知道你真实生活里怎么用这个工具。
这个判断，要从你这里来。
设计：让用户知道怎么操作
设计不是只负责“好看”。
当然，好看重要。一个页面太乱，用户会烦。
但设计更重要的事情是：
让用户知道下一步该做什么。
还是待办 App。
设计会关心这些问题：
• 添加按钮放在哪里，用户一眼能不能找到？ • 输入框里要不要有提示文字？ • 完成任务以后，是划掉、变灰，还是移动到已完成列表？ • 删除按钮会不会太容易误点？ • 手机上单手操作方不方便？ • 任务很多时，列表会不会看起来乱？
这些问题都不是单纯的颜色问题。
它们关系到用户能不能顺利完成动作。
小白和 Codex 协作时，设计视角非常重要。
你不一定会画专业原型，但你可以像用户一样试：
我想新增任务时，按钮是不是好找？
我完成任务以后，页面有没有给我明确反馈？
我在手机上点起来会不会别扭？
这些反馈，比一句“页面再美化一下”更有价值。
前端：把界面和交互做出来
前端负责用户能看见、能点击、能输入的部分。
如果说设计画出了“应该长什么样”，前端就是把它变成真实可操作的页面。
在待办 App 里，前端可能负责：
• 输入框。 • 添加按钮。 • 任务列表。 • 完成勾选。 • 编辑弹窗。 • 筛选按钮。 • 手机和电脑不同屏幕的适配。
前端不只是把东西摆上去。
它还要处理用户操作后的反应。
比如你点了“添加”，按钮是不是有反馈？任务是不是马上出现在列表里？输入框是不是清空？出错时有没有提示？
这些都属于前端体验的一部分。
小白不需要一开始懂 React、Vue、Next.js 这些框架。
但你需要能描述：
我在页面上做了什么，期待看到什么反馈。
这句话，就是你和 Codex 讨论前端问题的起点。
后端：处理规则、数据和接口
后端通常是小白最看不见的部分。
你可以把它想成餐馆的后厨和仓库。
前台负责接待和点单，但真正处理食材、出餐、库存的地方在后厨。
在软件里，后端也类似。
用户不一定直接看见它，但它决定很多关键事情：
• 任务怎么保存。 • 哪些任务属于哪个用户。 • 标题为空时能不能创建。 • 修改任务时要不要检查权限。 • 手机和电脑怎么拿到同一份数据。 • 前端通过什么方式请求数据。
数据库经常和后端一起出现，但它们不是一回事。
数据库更像仓库，负责长期存放数据。
后端更像后厨，负责处理规则、检查权限、整理数据，再和仓库打交道。
如果没有后端思维，待办 App 可能会遇到很多问题：
• 数据只存在页面里，刷新就没了。 • 每个人看到同一份任务。 • 删除任务没有权限检查。 • 手机和电脑数据对不上。
所以，当你和 Codex 说“我要多端同步”“我要登录”“我的数据不能给别人看”时，其实已经进入后端问题了。
你不需要自己写后端代码。
但你要知道：这些不是页面美化能解决的事。
测试：证明它真的能用
测试不是挑刺。
测试是在保护软件不要靠感觉上线。
很多小白第一次看到 AI 生成页面，会很开心：
页面打开了。
按钮也有。
列表也像那么回事。
但真正的问题是：
它能不能稳定完成真实动作？
待办 App 至少要试这些动作：
• 新增一条任务。 • 刷新页面后任务还在。 • 标记完成后状态正确。 • 修改标题后保存成功。 • 删除前有确认。 • 搜索能搜到正确任务。 • 手机和电脑看到的数据一致。
这些检查并不高级。
但非常有效。
小白天然可以参与测试，因为你就是第一位用户。
你不需要说“系统异常”。
你可以说得很具体：
我添加了一条“周五前整理发票”，刷新页面后不见了。
我在手机上标记完成，电脑上没有变化。
我点删除时没有确认，容易误删。
这种反馈，Codex 更容易处理。
运维和发布：让软件稳定活在网上
本地能跑，不等于别人能用。
这句话对小白很重要。
你在自己电脑上打开一个地址，看到了待办 App。它确实运行起来了。
但这通常只是本地运行。
如果你想让朋友也访问，就要把它发布到网上。
发布以后，还会出现新的问题：
• 网址是什么？ • 数据保存在哪里？ • 出错时在哪里看日志？ • 如果服务挂了怎么办？ • 数据要不要备份？ • 哪些配置不能公开？
这些事情，就是运维和发布关心的范围。
对个人小项目来说，第一阶段不需要搞得很复杂。
但你要知道，上线不是“点一下完成”。
上线意味着软件进入一个别人也可能访问的环境。你要更认真地检查隐私、安全、数据和错误处理。
后面我们会专门用一篇文章讲测试、修 bug 和发布上线。
现在先记住：
软件不是写完就结束，它还要被稳定地运行和维护。
你和 Codex 如何临时组成一支小队
看到这里，你可能会有点紧张：
这么多角色，我一个小白怎么可能都会？
别急。
你不需要成为每个岗位的专家。
但你可以和 Codex 临时组成一支小队。你负责判断目标、体验、边界和结果，Codex 负责帮你整理、实现、解释和验证。
可以这样分工：
这张表不是让你一夜之间变成全栈工程师。
它只是提醒你：
当你和 Codex 对话时，不要只说“帮我做一下”。
你可以更具体地说：
• 从产品角度：第一版只做个人待办，不做团队协作。 • 从设计角度：手机上添加任务要容易点到。 • 从前端角度：添加成功后任务要立刻出现在列表里。 • 从后端角度：任务必须属于当前用户。 • 从测试角度：刷新页面后任务不能丢。 • 从运维角度：发布前检查有没有暴露测试数据。
这些话都不需要你会写代码。
但它们会显著提高 Codex 做对的概率。
结尾：你不是要变成六个人
做软件不是“写代码”一个动作。
它是一串责任视角围绕用户目标配合：
• 产品想清楚要解决什么。 • 设计让用户知道怎么操作。 • 前端把界面和交互做出来。 • 后端处理规则、数据和接口。 • 测试证明它真的能用。 • 运维让它稳定运行。
你用 Codex 做个人项目时，不需要真的组一支团队。
但你需要知道这些视角存在。
因为很多问题，看起来都是“AI 没写好”，其实是我们没有说清楚自己站在哪个角度提要求。
当你能分清：
• 这是需求问题。 • 这是体验问题。 • 这是数据问题。 • 这是验证问题。 • 这是上线问题。
你和 Codex 的合作就会稳定很多。
下一篇，我们继续往下走。
理解了这些角色之后，就可以看懂它们背后的技术分工：
页面、接口、数据库、服务端和多端同步，到底是怎么连起来的？
