看懂 AI
从一个网站的诞生说起 · 写给非技术同学的四堂课
一个网页产品是怎么"从无到有再上线"的
Prompt / Harness / Loop:AI 工程的三级台阶
Skills:给 AI 的岗前培训手册
Git 与并行开发:让几个 AI 同时替你干活
一个 Web 产品的一生
你在浏览器里打开的每一个网站,背后都走过同一条路:有人写了代码,把它打成一个"包",搬到一台永远开机的电脑(服务器)上跑起来,再把网址交给用户。我们用公司真实的项目——「AI 电商作图台」——把这条路走一遍。
本章内容:产品三件套 → 打开网址的那一秒 → 上线六步 → 真实部署单 → 什么叫闭环 → 出事了怎么办
一个 Web 产品 = 三个部分
前前端
你看得见的一切:页面、按钮、输入框。它跑在你自己的浏览器里,负责"长得好看、点得动"。
后后端
你看不见的大脑:跑在服务器上,负责真正干活——调 AI 出图、处理批量任务、判断权限。
数数据
记得住的部分:数据库和文件仓库。你上传的素材、生成的图、任务记录都存在这里,关机也不丢。
一家餐厅:前端是前厅(菜单、桌椅、服务员,给客人看的);后端是后厨(客人看不见,但菜是那儿做的);数据是仓库和账本(食材、订单记录,哪怕今天打烊,明天还在)。
「电商作图台」就是这样:你在网页上传商品图(前厅点单)→ 后端调 AI 模型批量出图(后厨炒菜)→ 出图结果和台账存进数据库与文件夹(记账入库)。
你按下回车的那一秒,发生了什么?
盯着下面这条线看一轮: 红点是你的请求出发, 绿点是数据返回——一来一回,不到一秒。
按下回车
译成真实地址
敲对房间号
真正干活
把结果交回
点外卖:你报店名(域名)→ 平台translate成具体地址(DNS)→ 骑手找到那栋楼那个档口(服务器+端口)→ 店家接单、后厨开做(后端 API)→ 从冰柜取材出餐(数据库)→ 原路送回你手上(响应)。API 就是前厅和后厨之间递单子的小窗口。
从代码到上线:一次"搬家"
代码写在开发者自己的电脑上,但用户访问的是服务器——机房里一台永远不关机的电脑。中间隔着一次搬家:
打包成集装箱
体检验证
就能使用
以前搬家总担心"我家电器到了你家电压对不对";集装箱把货物连同它需要的环境一起封死,到任何港口打开都一模一样。这就是为什么"在我电脑上能跑,到服务器上也一定能跑"。顺带记两个词:自己电脑叫开发环境(随便折腾),服务器叫生产环境(动它要小心)。
真实案例:电商作图台的部署单
下面是这个项目真实的"搬家清单",看个眼熟就行,不用背:
| 事项 | 实际做法 | 人话翻译 |
|---|---|---|
| 打包 | docker build → smy-studio-api:latest | 把前端+后端封进一个约 316MB 的集装箱 |
| 门牌号(端口) | 8012 | 一台服务器像一栋楼,每个产品占一个房间号;8011 已被另一个项目占了,所以选 8012,不能撞号 |
| 钥匙(密钥) | .env 文件,不打进包里 | AI 服务的 API key 是敏感信息,单独放服务器上,像钥匙不缝在衣服里 |
| 数据不丢 | Docker volume 持久化 | 素材、出图、数据库放在集装箱外面的仓库里;以后换新集装箱,仓库原地不动 |
| 体检 | curl /health → {"status":"ok"} | 部署完先"号个脉",各关键页面都返回 200(正常)才算上线成功 |
| 预演 | 本地冒烟测试,用 8013 端口 | 正式搬家前,先在自己电脑上用另一个房间号试跑一遍整个流程,确认无误再上服务器 |
什么叫"闭环"?
上线不是终点,而是循环的起点。一个健康的产品,永远在转下面这个圈:
换新版本必须整个换掉集装箱(重建容器),不能只按"重启"。重启就像把微波炉关了再开——里面的饭还是昨天那碗。所以要 compose up -d 重建后,再核对新旧镜像编号:不要相信"我操作了",要验证"它确实变了"。这个思想第四章验收 AI 时还会用到。
网站打不开了,怎么排查?
程序出问题不靠猜,靠看记录。运维排查的三板斧,你哪怕不亲自敲,也要知道 AI 在替你干什么:
一店开着吗
docker ps
先看容器还活着没。相当于先确认"店是不是根本没开门",一半的问题到这步就有答案。
二回放监控
docker logs --tail 100
调出程序最近 100 行日志。程序做的每件事、每次报错都留了记录,像行车记录仪。
三进店查看
docker exec -it … bash
直接"走进"容器内部检查文件和配置。前两步解决不了才用。
报错信息不是电脑在骂你,是它在递线索。非技术同学最实用的一招:把整段报错原文复制给 AI——"这是什么意思?怎么修?"。不要截一半、不要自己转述,原文里往往就藏着答案。
从写好一句话,
到设计一个「自己干活的系统」
Prompt / Harness / Loop——AI 工程的三级台阶。核心逻辑:工程对象不断"上移",从一句指令,到运行环境,再到整个工作循环;而人,逐步退场。
01 提示工程 Prompt Engineering
把任务说清楚,让模型一次就答好。
改的是什么
一句指令——提示词文本本身。背景交代够不够、要求写没写全、格式说没说清。
人干嘛
全程亲自操作,一条一条写提示词、看结果、再改再发。AI 是个聪明但需要逐字吩咐的实习生。
像给员工写一封任务邮件——说清楚,才做得好。你不会给新同事发一句"搞一下那个事",却常常这样对 AI。
一条好提示词的四个要素
境背景
我是谁、在什么场景、给谁看。AI 不知道你脑子里的上下文。
务任务
动词开头,一件事一说。"写""改""对比""列出",别把五件事揉一句。
束约束
长度、语气、格式、禁忌。"200 字内""口语化""表格呈现""别用感叹号"。
例例子
给一个你满意的样例,胜过十句形容。"照这篇的风格来"。
AI 只能靠猜:什么活动?给谁?多长?什么语气?
四要素齐了,一次就能拿到八十分的稿。
两个进阶习惯:① 复杂任务先让 AI 复述一遍它的理解和计划,确认了再动工;② 结果不满意时在原对话里补充要求,别扔掉重开——它已经积累的上下文是资产。
02 驾驭工程 Harness Engineering
不改模型,改造环境,让 Agent 不重复犯错。Harness 原意就是"马具"。看下面两条跑道:
改的是什么
Agent 的运行环境:给它什么工具、圈多大的沙箱、立哪些规则。比如"部署必须先跑体检脚本""密钥禁止打进镜像"。
人干嘛 · 修路立规
每次 AI 犯错,不是骂一句完事,而是把教训写进规则和工具里,让这类错误在结构上不再重演。
自查一条:这次的改进,下次换个 AI、换个人来做,还自动生效吗?写在聊天里的叮嘱会消失,写进规则、脚本、skill 里的才留得下。第一章那些"端口不许撞号、数据放 volume、部署后必须验证",都是我们给 AI 配的马具。
03 循环工程 Loop Engineering
系统自己找活干、自己验收,人退出执行。一个能自转的循环,必须补齐三个零件:
像一支定时出车、自行回场检修的车队:调度表排好、检修标准立好之后,车队每天自己出车、自己报修;你只看月度报表,不再坐进驾驶室。注意——循环工程不是放养:人退出的是执行,"什么算做好"的标准和抽查的权力,始终在人手里。
三级台阶,一张表看懂
| 提示工程 | 驾驭工程 | 循环工程 | |
|---|---|---|---|
| 工程对象 | 一句指令 | 运行环境(工具·沙箱·规则) | 工作循环(任务·验证·记忆) |
| 人的角色 | 全程操作,逐条吩咐 | 修路立规,让错误不再重演 | 只做设计与验收,退出执行 |
| 成果留在哪 | 留在一次对话里 | 留在规则和工具里 | 留在会自转的系统里 |
| 类比 | 写任务邮件 | 给野马配马具 | 自动运转的车队 |
| 起点 | 2023 年起 | 2026.2 | 2026.6 |
写好指令→修好环境→让系统自己转
你现在在哪一层?
三个问题,对号入座:
问题一
你还在每件事都逐条现场吩咐 AI 吗?
→ 是,说明你在台阶一。先把四要素练熟,这是一切的地基。
问题二
同样的错误,AI 犯过两次以上吗?
→ 是,该上台阶二了:把纠正它的那段话写进规则或 skill,别再靠嘴。
问题三
有没有一件重复性工作,你还在亲手执行?
→ 有,想想能否上台阶三:定标准、设验收,把执行整段交出去。
三级台阶是逐级踩实的,不能跳级:话都说不清楚的人,规则也写不明白;规则立不住的团队,循环转两天就散架。但反过来,每上一层,你的时间就解放一大块——这是这套方法论的全部意义。
Skills:给 AI 的
「岗前培训手册」
上一章说到"修好环境"。Skill 就是环境建设里最容易上手的一种:把某类工作的最佳做法写成一份说明书文件,放在固定位置,AI 遇到匹配的任务会自动翻出来照着做。它是驾驭工程最平民化的形态。
本章内容:skill 是什么 → grill-me → superpowers → 官方与社区技能一览 → 全生命周期地图 → 自己写一个
Skill 到底是个什么东西?
拆开看,一个 skill "简陋"得惊人:就是一个文件夹,里面放一份叫 SKILL.md 的说明书(有时附几个小脚本)。说明书开头写清楚"什么时候该用我",AI 每次接到任务都会先扫一眼手册架,发现匹配就取下来照做。
为什么有用
AI 每次对话都是"新来的",没有上一次的记忆。Skill 把老员工踩坑攒下的经验固化下来,新来的 AI 一上岗就继承全部经验,不用每次从零教。
谁都能写
它不是编程,是写文档。你能把一件事的做法写清楚,你就能写 skill——这恰恰是文科同学的强项。
连锁店的 SOP 手册。店员流动再快,只要《开店流程》《客诉处理》手册在,任何新店员照着做都是老店水准。Skill 就是给 AI 的 SOP:人走了茶不凉,AI 换了活照干。
grill-me:先把你"盘问"清楚
出自开发者 Matt Pocock,核心只有几行字,却治好了 AI 最大的毛病——没听懂就急着动手。装上之后,AI 在写任何代码之前会先对你穷追猛打地提问:
- 一次只问一个问题,顺着决策树一根枝一根枝地捋,把选择之间的连带关系一个个理清;
- 每个问题都附上它推荐的答案,你可以直接采纳,也可以推翻;
- 能自己翻代码查到的,它就不来烦你,只问真正需要你拍板的事。
好的装修设计师在开工前会把你问到"烦":插座要几个?猫会不会抓沙发?爸妈来住几天?——问得越细,砸墙返工越少。grill-me 就是逼 AI 当这种设计师,把返工成本消灭在动工之前。
适用场景:新功能、新项目开工前;你自己也没完全想清楚需求的时候——被它问一轮,思路反而清楚了。有人被问 5 个问题,有人被问一个小时,问得越久,说明原来的想法漏洞越多,这是好事。
superpowers:不止一个技能,是一套方法论
出自开发者 Jesse Vincent(网名 obra),是社区最有名的技能合集:二十多个技能打包,外加一套"先想清楚、再列计划、再动手"的完整开发流程,装上后按需自动激活。最常用的三板斧:
谋brainstorm
开工前的头脑风暴:和你反复讨论,把模糊的想法打磨成清晰的设计,不满意不进入下一步。
案write-plan
把设计写成一份分步骤的施工计划:每步做什么、怎么验证做对了,白纸黑字。
行execute-plan
按计划分批执行,每完成一批就核对验收,而不是闷头写完一大坨再看。
此外还内置了"先写测试再写代码(TDD)""系统化找 bug 根因再修"等一批工程界公认的好习惯——相当于给 AI 请了一位严格的老工程师当师傅。
grill-me 是一位问得很细的设计师;superpowers 则是一整家正规装修公司——有量房、出图、报价、施工、监理验收的全套流程,而且每一步都按规范来。
值得知道的技能,不止这两个
| 技能 / 合集 | 来自 | 解决什么 |
|---|---|---|
| docx · pptx · xlsx · pdf | Anthropic 官方 | 让 AI 规范地制作和修改 Word、PPT、Excel、PDF——办公室同学最常用的一组 |
| grill-me | Matt Pocock | 动工前逼问需求,消灭"没听懂就开干" |
| superpowers 合集 | Jesse Vincent (obra) | 头脑风暴→写计划→按计划施工的全套方法论,附 TDD、调试等好习惯 |
| systematic debugging | 社区(superpowers 内含) | 强制"先找根因再动手修",禁止头痛医头式乱改 |
| elements-of-style | obra(基于《风格的要素》) | 给 AI 立写作规矩:删废话、用主动语态,产出简洁清晰的英文文本 |
| frontend-design | Anthropic 官方 | 界面审美规范:配色、字体、排版有章法,做出来的页面不"AI 味" |
| skill-creator | 社区/官方均有 | "写技能的技能":引导你把经验整理成一份合格的新 skill |
怎么装?两条路:① 在 Claude Code 里通过插件市场安装(如 /plugin install superpowers);② 更朴素的,把技能文件夹直接放进项目的 .claude/skills/ 目录——放进去就生效。
开发全生命周期的 Skill 地图
按一个项目从头到尾的顺序,每个阶段都有对应的"手册"可用:
| 阶段 | 代表 Skill | 它替你做什么 |
|---|---|---|
| ① 想清楚 | grill-me · brainstorm | 穷追猛打地提问,把需求和边界盘明白,避免开工即返工 |
| ② 列计划 | write-plan | 把共识变成分步施工图,每步自带验收标准 |
| ③ 写代码 | execute-plan · TDD 类技能 · frontend-design | 按计划分批施工;先定"怎么算做对"再动手;界面按设计规范走,不出丑 |
| ④ 抓 bug | systematic debugging | 强制先找根因再修,禁止"头痛医头"式乱改 |
| ⑤ 出交付物 | 官方 docx / pptx / xlsx / pdf | 产出规范的 Word、PPT、表格、PDF 文件 |
| ⑥ 沉淀经验 | skill-creator | 项目里踩的坑、总结的做法,反过来写成新 skill,团队越用越聪明 |
记住这个飞轮:用 skill 干活 → 干活攒经验 → 经验写成新 skill。这正是第二章说的"让错误在结构上不再重演"。
自己写一个 skill,五分钟的事
以"周报助手"为例,一份最小可用的 SKILL.md 长这样:
你平时怎么带新人，就怎么写 Skill先问哪些问题、按什么顺序做、哪些错误绝不能犯——把口头经验写下来，就是最小可用的 AI 岗前手册。
最关键的一行
是 description:AI 靠这句话决定"这个任务要不要翻这本手册"。把触发场景写全("周报、月报、工作汇报"),技能才会在该出现的时候出现。
写什么内容
把你带新人时会讲的话写进去:固定流程、质量红线、常见错误。你在岗位上的隐性经验,就是最值钱的 skill 素材。
Git 与并行开发:
让几个 AI 同时替你干活
一个人指挥一个 AI 已经很快了;但真正的效率飞跃,是同一个项目里开三个工位,三个 Claude Code 各干各的、互不打架、最后合并——这需要先认识 Git,以及它的一个妙招:worktree。
本章内容:Git 四个词 → 一次完整的协作流程 → worktree 多开工位 → 并行节奏 → 冲突怎么解 → 什么不能进仓库 → 让 AI 自己提交 → 当好监工
Git:代码世界的存档系统
Git 是全世界程序员都在用的"版本管理"工具。先看这张会自己画出来的图——四个词全在里面:
档commit · 存档
做完一小步就"存个档",附一句说明。搞砸了随时退回任意存档点。
云GitHub · 云端仓库
把整个存档库放到云上:多人共享、互相审阅、永不丢失。"代码界的共享网盘+审批流"。
像打游戏:commit 是存档点,打 Boss 前先存档;branch 是开新档试一条邪道路线,失败了读旧档,主线毫发无伤;merge 是把试出来的最优路线抄回主档。也像 Word 的"修订+历史版本",只是强大得多。
一次完整的协作,从头到尾
无论人还是 AI,在团队里改一段代码,标准动作都是这八步:
存档说明(commit message)有讲究:写"做了什么、为什么",如 "fix: 修复台账导出丢最后一行的问题"。三个月后翻历史,靠的全是这些一句话——写"改了点东西"等于没写。
worktree:同一个项目,开出多个工位
普通情况下一个项目只有一个文件夹,同一时间只能待在一条支线上——一个 AI 干活,另一个只能干等。git worktree 把同一个仓库"投影"成多个并排的文件夹:
一间厨房只有一个灶台,三个厨师只能排队;worktree 相当于照着同一本菜谱,支起三个独立灶台——各炒各的菜,互不抢锅,最后一起上桌。
并行开发的实际节奏
要点只有一个:拆任务时让各工位少碰同一批文件——比如一个做前端页面、一个做后端接口、一个写文档,冲突就会很少。
"冲突"没那么可怕
当两条支线改了同一个文件的同一段,合并时 Git 不会自作主张替你选,而是把两个版本并排摆出来,等人裁决——长这样:
上半段是你这边的版本,下半段是对方的版本。你(或你指挥的 AI)选一个、或手动融合成第三个版本,删掉标记,重新存档——冲突就解完了。
上策 · 预防
拆任务时错开文件,从源头让冲突少发生。
中策 · 勤合并
小步快跑,做完一块就并一块;囤一个月再合并,冲突会滚成雪球。
下策也不怕 · 让 AI 解
真冲突了,让 AI 分析两边各想干什么,给出融合建议,你来拍板。
有些东西,永远不能进仓库
仓库门口有一份"禁入名单",叫 .gitignore:写在里面的文件,Git 会当它们不存在,永远不会被提交。三类东西必须在名单上:
密钥匙类
.env、API key、密码。还记得第一章"钥匙不缝在衣服里"吗?同理,钥匙也不放进仓库。
重可再生的大件
node_modules、构建产物。几百 MB,而且随时能重新生成,进仓库只会拖垮所有人。
私用户数据
数据库文件、用户上传的素材。既是隐私,也不属于"代码"。
GitHub 上推送过的内容会留在历史里,删了文件也抹不干净。API key 一旦泄露,等于把公司账户的额度公开给全网——网上有人 24 小时扫描公开仓库里的密钥。所以规矩是铁的:密钥只放服务器的 .env,不进镜像、不进仓库;万一泄露,第一时间作废换新,而不是删文件。
让 AI 自己提交到 GitHub
存档、推送、发起合并申请——这些机械操作完全可以交给 AI。你只需要用人话下指令:
PR 是什么
Pull Request = "我做完了,请审阅后并入主线"的申请单。同事(或另一个 AI)在网页上逐行看改动、留意见,通过后一键合并。
只需一次性准备
在电脑上装好 GitHub 的命令行工具 gh 并登录授权一次(gh auth login,跟着提示点几下),之后 AI 就能全程代劳。
给几个 AI 当"监工"的四字诀
并行开发时,你的角色从"操作员"变成"包工头"。包工头不砌墙,但每天巡场。四个字:
拆拆
任务边界切清楚:各工位目标独立、少碰同一批文件、各自有明确的"完成标准"。
述述
动工前让每个 AI 复述计划:"你打算怎么做?"计划不对,五秒纠正;做完再纠正,半天白干。
查查
不全信"我做完了"。看改动对比(diff)、跑一遍测试、亲手点一点页面——呼应第一章:验证它确实变了。
收收
合并前在 PR 页面过最后一遍。PR 就是你的验收台,人守住这一关,其余都可放手。
发现没有?这正是循环工程里"人的位置":执行在 AI 手里,标准和验收在你手里。管一个 AI 和管三个 AI,区别只是把这套动作重复三份——而你的产出,是原来的三倍。
四堂课,四句话
术语速查表:开会听不懂时翻这页
| 术语 | 一句话解释 | 术语 | 一句话解释 |
|---|---|---|---|
| 🖥️前端 Frontend | 浏览器里看得见、点得动的部分 | 🧠后端 Backend | 服务器上看不见、真干活的部分 |
| 🪟API | 前后端之间递单子的小窗口 | 📒数据库 Database | 产品的账本,关机也不丢 |
| 🏢服务器 Server | 机房里永不关机的电脑 | 🚪端口 Port | 服务器这栋楼里的房间号 |
| 🚚部署 Deploy | 把产品搬上服务器让人能用 | 📦镜像/容器 | 集装箱的图纸/跑起来的集装箱 |
| 📹日志 Log | 程序的行车记录仪 | 🔑密钥 API Key | 调用付费服务的钥匙,严防泄露 |
| 🏠仓库 Repository | 项目全部代码和历史的家 | 💾提交 Commit | 存档一次,附一句说明 |
| 🌿分支 Branch | 不影响主线的平行世界 | 🔀合并 Merge | 把支线成果并回主线 |
| ⚡冲突 Conflict | 两边改了同一处,等人裁决 | 🧾PR | "请审阅后合并"的申请单 |
| 🖥️worktree | 同一仓库多开几个并行工位 | 📘Skill | 给 AI 的 SOP 说明书文件 |
| ✉️Prompt 提示词 | 你发给 AI 的任务邮件 | 🤖Agent 智能体 | 能自己用工具连续干活的 AI |
课后小练习:一周内各花十分钟
壹被盘问一次
下次让 AI 做事之前,先说"用 grill-me 的方式盘问我"。数一数它问了几个你没想到过的问题——那就是你省下的返工。
贰走一遍完整流程
让 Claude Code 在一条新支线上做个小改动,然后说"提交并开 PR"。打开 GitHub 网页,亲眼看一遍 diff 长什么样,点下合并。
叁写你的第一个 skill
挑一件你岗位上重复教过别人的事(周报格式、命名规范、审稿清单),照第三章的模板写成 SKILL.md,丢给 AI 试用一次。
它们分别对应三级台阶:练习壹让你把话说清楚(Prompt),练习叁让你开始修环境(Harness),练习贰让你体验"人只守验收关"(Loop 的雏形)。做完这三个,这门课才算真的上完。
写好指令→修好环境→让系统自己转
再开几个工位,让它们一起转
有任何一页想不起来,回来翻这份课件即可。
Q & A