软件是怎么搭起来的
在学任何一个工程动作之前，先看一眼地形。你不用会做菜，但得知道前厅、后厨、货架各在哪儿——不然别人说"要动后端"，你连这句话大不大都判断不了。
START
你听懂了每个字，却做不了那个判断
你让 AI 帮你改个东西，它回你一句——
这个要动后端，还得加个接口，改完得重新部署一下。
每个字你都认识，合起来却不知道它在说哪儿。于是最要紧的那个判断你做不了：这事到底大不大？会不会把别的地方弄坏？改坏了还回得来吗？
结果只有两种。一种是不敢让它动，好好一个能干的帮手，只敢用来写文案。另一种是让它随便动，动完了出问题，你连问题在哪一环都说不出来，只能整段重来。
这两种都不是"AI 不好用"，是你手里没有地形图。
这一页就给你那张图。它不教你写代码，也不需要你记住任何命令——看完你要能做的事只有一件：别人（或 AI）说一句改动，你能说出它动的是哪一环、这一环有多贵。
MODEL
把软件看成一家餐厅
任何一个你在用的系统——网店后台、客户管理系统、公司内部工具——拆开看都是同一家餐厅。五个部件，各管一段。
前端（Frontend）
前厅和菜单
你看得到、点得到的一切都在这儿：页面、按钮、表格、那个下拉框。它不做菜，只负责把东西摆给你看，以及接住你的动作。你觉得"这个软件长这样"，说的其实就是前厅。
接口（API）
传菜口
前厅不进后厨，后厨也不出来跑堂——中间开一个固定的口子，单子从这儿递进去，菜从这儿端出来。口子的规矩是提前约好的：递什么样的单、回什么样的菜，双方都照着这个约定办。所以当你听到"接一下某个 AI 的接口"，意思就是：在你的餐厅侧墙上再开一个传菜口，通到人家的后厨去，让人家帮你做一道菜。
后端（Backend）
后厨
接到单子、按配方干活的地方。你点了"提交"之后转圈的那几秒，就是后厨在忙：核对这单能不能做、该扣多少钱、要不要通知谁。你永远看不见它，但决定"这个软件到底靠不靠谱"的规矩，全在这儿。
数据库（Database）
后厨背后的货架
每类东西一排架子，取放都登记在册。你在系统里看到的每一行记录——每个客户、每笔订单、每条备注——都是从某排架子上取出来的。前厅够不着货架，想拿什么都得让后厨去取。这不是麻烦，是安全：不然任何一个坐在前厅的人都能自己进仓库搬东西。
部署（Deploy）
正式上菜单
新菜在自己厨房里试成了，不等于门店在卖。得正式印进菜单、通知所有门店，客人才点得到。所以"功能做好了，今晚部署"的意思是：今晚起，所有人用到的都是新版本。没部署之前，改动只活在开发者自己的厨房里。
FLOW
一次点击，走过全部五环
把这五个部件串起来，看一次最普通的操作实际走了多远。你在一个客户列表里，改了某位客户的备注，点了保存。
- 1
前厅接住动作
页面把你输入的那行字收起来，写成一张单子。
- 2
单子递进传菜口
按事先约好的格式送进去——哪位客户、哪个字段、改成什么。
- 3
后厨干活
先核对你有没有权限改、这位客户还在不在、这行字合不合规矩，然后决定动手。
- 4
去货架取放
找到那位客户所在的那排架子，把旧备注换成新的，登记入册。
- 5
原路回前厅
后厨回一句"存好了"，前厅把转圈换成一个"保存成功"。
全程可能不到一秒，但它确实走过了五环。记住这条链路，比记住任何一个术语都值钱——因为接下来两件最实用的事，全靠它。
JUDGE
用它判断影响面：改哪一环，贵多少
现在回到开头那个问题：这事大不大？答案取决于改动落在哪一环。越靠前越轻，越靠后越重——因为越往后，被别人依赖得越多。
| 你想要的改动 | 动到哪几环 | 有多重 | 为什么 |
|---|---|---|---|
| 换个按钮文案、调个颜色、挪个位置 | 只动前厅 | 轻 | 改坏了也只是难看，数据一根汗毛没动。 |
| 列表加一个筛选条件 | 前厅 + 传菜口 + 后厨 | 中 | 要重新约定单子格式，后厨也得跟着改配方。 |
| 每位客户多存一项信息 | 全链，且要动货架结构 | 重 | 货架加一排是小事，改动已有那排的摆法就危险——旧记录怎么办、旧配方还认不认得。 |
| 接入一个 AI 能力 | 侧墙新开一个传菜口 | 中 | 主要是把"递什么单、回什么菜"约清楚，以及那道菜出不来时怎么办。 |
一条经验：动前厅可以随意试，动货架必须先想清楚。前厅改砸了刷新一下就回来了；货架的摆法改了，架子上原有的东西不会自己跟着变——这正是"数据不像代码那样能随便回滚"的原因。
所以当 AI 跟你说"这个要动数据库"，你该做的不是拦住它，而是多问一句：旧的那些记录怎么办？
TRIAGE
用它定位问题：先问断在哪一环
第二个用处，是出事的时候。大多数人看到报错的第一反应，是把整段错误信息丢给 AI，说"报错了，你看看"。这样也能修，但你会一直停在"我不知道刚才发生了什么"的位置上。
有了地形图，你可以先做一次十秒钟的分诊：顺着那五环，问"哪一环没走通"。
页面根本没反应，点了跟没点一样
多半断在前厅，单子压根没递出去。
页面转圈很久然后报错
单子递出去了，后厨或者传菜口出了事。
提示"没权限""不允许"
后厨的规矩把你挡了，这通常不是故障，是设计。
页面看着成功了，换个地方一看没变
十有八九货架那一步没落到，或者你看的是另一排架子。
你本地明明好好的，别人用还是老样子
大概率是没上菜单（没部署）。
分诊完再开口，你说的就不是"报错了"，而是"提交之后转圈然后失败，前厅显示正常"——这句话能让任何一个帮手（包括 AI）少走一半弯路。
这套习惯本身有个名字，叫报错定位法：先定位断在哪一环，再动手改。顺序反过来——一上来就改代码——才是把小问题拖成大问题的常见原因。
RULES
三条守则
守则一 · 先问"动哪一环"，再问"要多久"
时间估算不可靠，环数不会骗人。听到"只改个显示"就放心，听到"要改数据结构"就坐下来聊聊。
守则二 · 货架的事，永远多问一句旧数据
加一排新架子几乎没风险；改动已有那排的摆法，必须先说清楚已经摆在上面的东西怎么办。
守则三 · 出问题先分诊，再报修
描述现象走到哪一环断的，比复制一整段报错更有用——对人如此，对 AI 更是如此。
NEXT
下一步
地形图你有了。动手之前，先把桌上的三样家伙认清。
自己学的下一步
教程说"打开终端"，AI 说"我改了三个文件"——编辑器、终端、AI 编程助手各是什么、怎么配合，前置篇《AI 在哪儿替你干活》一页讲清。
读前置篇找我们做
看懂了地形，接下来是自己走一遍。这条路我们踩过，可以带着你的团队走完整一轮，走完地形图就在你们自己脑子里了。
查看服务伴读词条 · 概念词典（第三层 + 元词条）