Skip to content

🚀 从「我不会」到「我的代码上线了」——一条完整的心智链

这一篇把七件事串成一条线,一次讲清楚: Agent 到底是什么 → GitLab 和 GitHub 有啥区别 → 代码怎么交上去 → 代码怎么认 → Web 开发与代码工程为什么重要 → 开发到底在干嘛 → 命令是什么。 (其中「怎么把需求说清楚」单独开了一篇 👉 怎么把需求讲清楚,那是全看板最重要的一课。)

你不用会写代码,也不用会敲命令。你只要会、会看结果。命令和代码是 Agent 的事,这篇是帮你「看得懂 Agent 在干嘛、知道什么时候该点头」。


一、先真的搞懂「Agent 是什么」

看这个看板的人,很多其实没真懂 Agent 是什么——只知道「能帮我写代码」。这里补一课,把底子打牢。

Agent 不是「聊天机器人」,是「能动手的同事」

普通 AI(豆包/聊天机器人)Agent
能干什么:回答、写文案、给建议:改文件、装工具、跑命令、发代码
你给它的一个问题一个任务(有目标、有范围、有验收)
它给你一段回答一个结果(做好了的东西)

一句话:聊天机器人给你答案,Agent 替你干活。 这个看板从头到尾教的,就是「怎么把 Agent 当一个能动手的同事用」。

Agent 干活的固定套路:想 → 做 → 给你看

Agent 收到你的需求,永远是这四步循环:

理解你要什么 → 自己拆步骤 → 动手干 → 把结果拿给你看 → 听你说「行 / 再改改」

你只要卡住两头:开头说清要什么,结尾看结果点头或摇头。 中间它怎么拆、怎么写、敲了什么命令,你都可以不用管(但你可以随时问「你现在在干嘛,说人话」)。

你真正要练的三件事

能力为什么重要去哪学
说清需求需求不清 = 做错,这是头号问题怎么把需求讲清楚
看懂结果做得好不好,你要能判断代码怎么认
会说不满意说「再改改」也要说清改哪里怎么跟 Agent 说话

别的(命令、代码、Git、部署)都可以甩给 Agent。唯独「说需求」和「看结果」这两件,永远是你自己的活。


二、GitLab 和 GitHub,到底是什么

先记住一句话:

它们俩是「放代码的网站」,差别只有「房子是谁的」。

一句话版

GitLabGitHub
是什么放代码的网站放代码的网站
像什么公司的内部网盘全世界最大的公共网盘
谁的常被公司自己搭、自己管微软的,谁都能注册
网址长这样gitlab.com/…github.com/…

那它们到底一样在哪、不一样在哪?

一样的部分(占 90%):你看到的「仓库」「提交」「分支」「合并请求」这些词,两个网站全都有,长得也几乎一样。你在 GitLab 学会的东西,到 GitHub 上照样会用。

不一样的部分(就三条,记住就够):

  1. 入口网址不一样 → 代码存的地方不一样。gitlab.com 存一份,github.com 是另一份,两边互不相通。
  2. 给谁用不一样 → GitLab 更常被公司内部用来放不能公开的代码;GitHub 更常放给全世界看的开源代码。
  3. 「请求合并」叫法不一样 → 同一个动作,GitLab 叫 MR(Merge Request),GitHub 叫 PR(Pull Request)。名字不同,意思一模一样:「我改好了,请帮我合进去」。

你已经懂了大半了 👉 术语词典 里也写了「仓库」「克隆」「推送」「分支」,忘了去查。

这个看板用哪个?

这个看板的主仓库在 GitLabgitlab.com/webkubor/xiaobai-kanban)。但你不需要记——你只要对 Agent 说「帮我提交到 GitLab」或「帮我提交到 GitHub」,Agent 自己知道去哪个网址。


三、代码是怎么「交上去」的

先忘掉命令。你只要理解一个送快递的过程:

你的电脑(本地)                    放代码的网站(GitLab/GitHub)
┌──────────────┐                    ┌──────────────────┐
│ 你改了代码    │  ── push 推送 ──▶  │ 代码住进网上的仓库 │
│ 先「保存+备注」│                    │ 别人也能看到       │
└──────────────┘                    └──────────────────┘

三步,对应三个词

你在心里想的事对应的词大白话
我先存一下现在的改动,写句话记着我改了什么Commit(提交)像 Word 里 Ctrl+S,还顺手写了「把按钮改成蓝色」
我改完了,但先别直接动主版本,放在一个副本上Branch(分支)先复印一份改,改好了再合回原件
我这份副本改好了,传到网上去Push(推送)把电脑上的文件上传到网站
请团队看看我的副本,OK 就合进主版本MR / PR(合并请求)「我改好了,麻烦审一下,没问题就合进去」

完整的一次「交代码」长这样(你只需说话)

  1. 你说:「帮我把这个项目改好之后提交上去。」
  2. Agent 会:拉最新 → 开个分支 → 改 → 提交(写备注)→ 推送 → 开一个 MR 等你确认。
  3. 你看一眼 MR 页面(其实 Agent 会翻译给你听),说「合」或「再改改」。

命令细节 👉 README 第三步:GitFlow 工作流。这篇不背命令,只要懂上面这张图。

最容易被卡住的两件事(提前知道,不慌)

  • 「main 分支被保护了,推不上去」 → 这是网站的保护锁,不是你的错。照 README 常见踩坑 解一下就好。
  • 「我没有权限」 → 你的账号还没被加进群组/仓库。找 Owner(这个看板里是 webkubor)加一下。

四、代码怎么「认」——给你一副能看懂的眼镜

你不需要会写代码,但你可以学会「认出它是干嘛的」。就像你不懂法文,但能认出「这是一本菜谱,那页是目录」。

一个项目 = 一个文件夹,里面一堆文件

my-project/
├── README.md          ← 说明书:这个项目是干嘛的、怎么用
├── index.html         ← 网页的「门面」(大门,进门先看它)
├── src/               ← 源代码都堆在这个柜子里
│   ├── app.js         ← 负责「动起来」的文件
│   └── style.css      ← 负责「长什么样」的文件
├── package.json       ← 清单:用了哪些别人写好的零件
└── .git/              ← 隐藏的账本:记录所有改动历史(别碰)

三类文件,认名字就知道干啥

文件名里带大概是干嘛的类比
README / docs说明书、文档产品说明书
.html .css .js网页门面(html)、化妆(css)、会动(js)
package.json / 依赖用了哪些现成零件采购清单

怎么「读」一段代码(不是看懂每个字)

不用逐行看懂。问三个问题就行:

  1. 它叫什么名字? 文件名、函数名通常就是它干的事(login 就是登录,saveImage 就是存图片)。
  2. 它从哪进来的? 先找 README 或入口文件,别一上来就钻最深处的文件。
  3. 它把结果送到哪? 看最后是「显示给用户」还是「存进数据库」。

你可以直接对 Agent 说:「帮我把这个项目讲一遍:它分几个部分、每个文件是干嘛的,用大白话。」——这就是你「认识代码」最快的方式,不用自己啃。



五、Web 开发与代码工程——为什么它重要

你可能听过「写代码」,但不知道它为什么是件「重要的事」。这里补上这个盲区,不然你会把 Agent 当成「写字的机器」,而看不到它背后真正的价值。

「Web 开发」是什么

就是做网站、做网页。你每天刷的淘宝、公众号网页、公司官网、后台系统,全都是「Web 开发」做出来的。

Web 开发特别适合当你的第一站,因为:

原因大白话
结果看得见改完刷新浏览器就变了,不用猜
Agent 特别擅长网页开发是最成熟的领域,它熟
容易说清「标题改成红色」这种需求,谁都听得懂

所以这个看板的第一个实战就是「做一个网页」,不是偶然。网页是「你说话、Agent 干活」这套玩法最顺手的试炼场。

「代码工程」是什么——为什么不能只是「写对」还要「写得好」

「写代码」和「代码工程」是两回事:

写代码代码工程
关心什么这一行写对没整个项目以后还好不好改、会不会塌
像什么把菜炒熟把厨房设计好:食材放哪、流程怎么走、谁来洗碗
决定什么现在能不能跑半年后你再加功能,是 10 分钟还是 10 天

为什么小白也要懂这个? 因为 Agent 帮你写的代码,如果结构一团乱,你现在看不出问题——但下一次你让它「加个新功能」,它会很难下手、很容易改坏别的地方。

好的代码工程,具体长这样:

  1. 结构清楚:文件按功能分好,不是所有东西堆在一个文件里。
  2. 命名能看懂:文件名、函数名一看就知道干嘛的(login 就是登录)。
  3. 有说明书README 告诉你项目怎么跑、怎么改。
  4. 改完能验证:有测试或构建,改坏了能立刻发现。
  5. 有历史记录:用 Git 存每一次改动,改错了能回退。

你不用自己搞这些——但你要会要求 Agent 搞。 比如对它说:「帮我把这个项目整理得结构清楚一点,每个文件加上注释说明它是干嘛的,README 写清楚怎么跑。」这就是你在「管工程」,只是动手的是 Agent。

你从这个看板能带走的一句话

写代码的是 Agent,但「这个东西以后好不好维护、会不会越改越烂」,是你该在意、也是你能通过提需求把控的事。


六、「开发」到底在干嘛——一个循环,转起来就行

开发不是「坐在那里一直写代码」,它是一个转圈

提需求 → Agent 做 → 你看 → 不满意 → 说哪里不对 → Agent 改 → 满意 → 提交 → 上线
   ▲                                                            │
   └──────────────────── 有新想法,再转一圈 ◀──────────────────────┘

每一步,你只负责两件

环节你负责Agent 负责
提需求说清楚要什么(见下一节)
写代码、搭结构
看效果:好看吗、能用吗
说「哪里不对、要改成什么样」
提交说「行了」提交、推送、开 MR
上线说「上吧」部署,给你网址

看出来了吗?你从头到尾就是「说」和「看」。 中间所有技术活都是 Agent 的。这就是这个看板说的「你只说话,Agent 搞定一切」。

卡住时的万能句型

  • 不知道从哪开始 → 「帮我用大白话说说,这个项目现在做到哪一步了?」
  • 看不懂 Agent 在干嘛 → 「你现在在做什么?为什么要做这个?说人话。」
  • 结果不对 → 「我要的是 X,你给的是 Y,改成 X。」

七、怎么把「需求」说清楚——全看板最重要的一课

这一课太重要,单独开了一篇讲透 👉 怎么把需求讲清楚

一句话预告:

需求说不清,是把成本从「开头多花 3 分钟说清楚」,转移成「后面来回改 30 分钟」。

核心就一个万能框架,先记着:

背景 + 目标 + 范围 + 验收标准
部分回答什么例子
背景为什么做这个、给谁用「公司要官网,客户想看产品」
目标做完长什么样「三个页面:首页、产品、联系」
范围做多少、不做什么「不做登录、不做购物车」
验收标准怎么算完成「电脑手机都能开、能放 6 张图」

去看完整版(含填空模板、三种场景套法、自检清单、完整范例)👉 怎么把需求讲清楚


八、「命令」是什么——以及怎么「说命令」

命令,就是「给电脑的一句话指令」

你平时点鼠标让电脑干活;命令是用文字让电脑干活。Agent 就是替你把这些文字敲进去的人。

你心里想的你说的话Agent 实际敲的命令
我想看看现在有哪些改动「帮我看看改了什么」git status
把改动存一下「帮我提交」git commit -m "..."
传到网上去「帮我推上去」git push
装一个工具「帮我装 Git」brew install git

说命令的万能公式(跟「说需求」互补)

动作 + 目标 + 位置 + 要求

这个公式 怎么跟 Agent 说话 讲得更细,这里再贴一次:动作(帮我改/查/装)、目标(哪个东西)、位置(在哪)、要求(改成什么样)。

你不需要背命令,但要学会「说清楚命令的结果」

说命令时,把你想要的最终结果说出来,比说对命令本身更重要:

  • ❌ 「帮我跑个 git 什么来着」——Agent 不知道你要啥。
  • ✅ 「帮我把刚才的改动保存并传到网上去」——Agent 自己知道用哪几个命令。

结论一句话:你负责说「要什么结果」,Agent 负责把结果翻译成命令。 命令是它的母语,你只要会提需求。


一张总表收尾

你想懂的一句话答案
Agent 是什么聊天机器人只「说」,Agent 能「做」;你只练「说需求」和「看结果」两件事
GitLab vs GitHub都是放代码的网站,GitLab 像公司内网盘、GitHub 像全球大网盘,用法几乎一样
代码怎么交改 → 提交(存+备注)→ 推送(上传)→ MR/PR(请人合并)
代码怎么认看文件名就知道干嘛;先读 README 和入口,别一头扎进最深处
Web 开发 / 代码工程网页最适合作第一站;「写对」和「写得好」是两回事,工程好才改得动
开发在干嘛一个循环:提需求 → Agent 做 → 你看 → 改 → 提交 → 上线
需求怎么说背景 + 目标 + 范围 + 验收标准,四句说全(完整版见 怎么把需求讲清楚
命令是什么给电脑的文字指令;你只管说「要什么结果」,Agent 翻译成命令

下一步

以 MIT 协议开源 · 内容会随反馈持续更新