AI-assisted engineering field guide · 2026.08

从类比
走向系统化试错

用「档案馆」理解 Git，用「实验协议」理解 TDD，用「协作网络」理解 GitHub，让 AI 不只替你写代码，而是帮助你建立可回退、可验证、可复用的工程思维。

FOR创作者 · 独立开发者

READINGWhat / Why / Practice

EXPERIMENT / TOOLBAR-BOTTOM EXPERIMENT / AUTO-HIDE MAIN / ACCEPTED

创造不是沿一条路冲刺，而是把多个未来变成可比较的证据。

00 / 核心结论

MENTAL MODEL

这不是一份命令速查表，而是一张可以反复校正的认知地图。

AI 降低的是执行成本，
工程方法降低的是错误成本。

类比 → Git 留痕 → TDD 验证 → GitHub 协作

四者不是四个孤立工具，而是一条完整的学习与创造闭环：先用类比建立可工作的心智模型，再用 Git 保存探索路径，用测试把预期变成可执行证据，最后在 GitHub 上让变化可讨论、可审查、可复用。

KNOWN A熟悉经验

≈

UNKNOWN X新概念

≠

BOUNDARY主动找差异

01 / 一张总地图

四层系统：从想明白，到做扎实

COGNITION

类比 · 建模用熟悉结构搭桥，再通过差异校正，获得对未知领域的第一张可用地图。

EXPERIMENT

Git · 留痕记录项目状态，让每个重要选择都能回看、比较、分叉和整合。

VERIFICATION

TDD · 验证先把行为预期写成失败的测试，再用最小实现让它通过，随后整理结构。

COLLABORATION

GitHub · 协作托管仓库、讨论问题、审查差异、运行检查，并把个人成果变成公开或团队资产。

EXECUTION

AI · 扩展带宽阅读源码与测试、生成假设、补测试矩阵、执行命令；人负责目标、边界、证据与最终判断。

02 / Git 的第一性理解

Git 不是「保存按钮」，
而是一座本地的项目档案馆

WORKING TREE

门外的工作桌

你正在改的文件。Git 看得到变化，但不会替你决定哪些值得归档。

STAGING AREA · 归档清单

COMMIT
a18f…
工具栏下移

COMMIT
b730…
自动隐藏

COMMIT
c912…
通过测试

工作区 Working Tree你正在写作、设计或编码的桌面。文件可能未跟踪、已修改，但尚未进入下一个历史快照。

暂存区 Staging Area / Index档案馆门口的装袋清单：你选择「下一次提交究竟收哪些内容」。官方文档强调，git add 暂存的是当下那一版内容。

提交 Commit一个可追溯的项目快照，包含作者、说明以及父提交关系。它不是按分钟自动保存，而是一次有意图的历史声明。

仓库 Repository保存对象与历史关系的档案馆。Git 是分布式版本控制：一次完整克隆通常包含整个仓库历史，不只是一份最新文件。

最好的提交说明，不是「我改了什么文件」，而是「我为什么让项目历史多出这个节点」。

03 / 两个类比，一次校正

「平行世界时光机」负责点燃直觉，
「档案馆」负责校正结构

≈ 准确之处

像平行世界

可以从同一个历史节点分出多个实验方向。
可以在不同分支之间切换、比较，再决定是否整合。
每条路径都保留其上下文，适合真正有不确定性的创造。

≠ 不准确之处

不是真正改写过去

Git 通常不是把旧历史抹掉，而是从旧节点继续产生新历史。
分支不是一整套项目副本；在 Git 中，它本质上是指向某个提交的轻量可移动指针。
合并也不一定是「选一个、删两个」；它可以组合多个实验的有效部分，也可能产生冲突，需要人判断。

最小心智模型

04 / Git 最小词汇表

命令可以交给 AI，
但这些名词与动词必须认得

概念	类比	为什么重要	常见动作
repository	整座档案馆	项目文件、对象与历史的容器；本地仓库与远程仓库不是同一个东西。	init · clone
working tree	门外工作桌	你当前看见和修改的文件状态。	edit · status · diff
staging area	待入库清单	精确决定下一次提交包含什么，而不是「所有改动一起塞进去」。	add · restore --staged
commit	带索引的档案袋	一个可定位、可解释、可作为分叉起点的历史快照。	commit · show · log
branch	可移动书签	隔离实验方向；不是项目文件夹的昂贵复制。	branch · switch
HEAD	当前阅读指针	告诉 Git 你当前位于哪条分支、哪个提交。	switch · checkout
merge / rebase	整合 / 重排档案	两种不同的历史整理方式；不要让 AI 在你不理解影响时擅自改写共享历史。	merge · rebase
remote	另一座可联络的档案馆	常见是 GitHub，但也可以是别的服务器或位置。	fetch · pull · push

01 SEEstatus
看状态

02 READdiff
读变化

03 SELECTadd
选入库

04 RECORDcommit
写意图

05 TESTrun tests
做验证

06 SHAREpush
传远端

07 REVIEWPR
讨论合并

不必背完命令，但应能在 AI 执行前读懂「它准备改变哪一层、是否会改写历史、失败时如何回退」。

05 / Git ≠ GitHub

GitHub 是协作与公开资产层

Git 可以完全在本地工作；GitHub 把仓库带入网络、讨论、审查、自动检查与社区关系。

PUBLIC UI EVIDENCE · Git 的 GitHub 公开镜像页面，采集于 2026-08-14；不含个人数据。

LOCAL GIT

个人实验系统

REPOSITORY代码、文件与每个文件的修订历史；可公开或私有。

PULL REQUEST提议合并变化，并在合并前讨论、审查与运行检查。

ISSUE / DISCUSSION记录问题、反馈、任务、方案与社区知识。

CHECKS自动运行测试、构建、扫描，让判断拥有机器证据。

clone

把远程仓库与其历史复制到本地。它不是「下载 ZIP」的同义词。

fork

在 GitHub 上产生关联的仓库副本，常用于无直接写权限时独立贡献。

pull request

不是「拉代码」，而是向目标分支提议合并，并聚合会话、提交、检查与差异。

06 / TDD 的第一性理解

TDD 不是「写完再测」，
而是用测试驱动设计决策

把测试理解成实验协议：在实现之前先写清楚「什么现象才算成功」。代码只是为了让这份可执行的行为合同成立。

RRED · 先失败

写一个足够小的测试，描述下一项行为；运行它，确认它因为功能尚不存在而失败。

GGREEN · 最小通过

写最少、最简单的实现让测试通过。此时目标是建立证据，不是提前追求优雅。

RREFACTOR · 保持通过

在所有测试仍通过的前提下，整理命名、结构、重复与耦合，让设计更清楚。

测试真正提供什么

明确预期、迫使接口可测试、快速发现回归、积累行为文档，并给重构提供安全网。

测试不能保证什么

不能证明没有 bug，不能自动覆盖所有边缘情况，也不能替你判断「这个功能值不值得做」。坏测试同样会误导。

对录音的精确校正

「全面试错完毕，只剩正确道路」适合作为行动方向，但不是数学保证。更准确的说法是：把重要风险空间显性化，并用一组可重复实验不断压缩未知。

07 / 把边缘情况变成矩阵

别问 AI「这个功能怎么实现」，
先问「它在哪些维度会失败」

以录音中的阅读器「划词高亮」为例。功能表面只有一次拖拽，真实行为却横跨文本边界、方向、DOM 结构、语言与空选择等多个维度。

风险维度

正常路径

左边界

右边界

极端 / 异常

起止位置

词首 → 词尾

词中开始

词中结束

空选择 / 单字符

拖拽方向

从左到右

反向选择

越过句末

取消后重选

文本结构

同一文本节点

跨 span

跨段落

隐藏节点 / 注释

语言系统

英文单词

中文无空格

标点相邻

emoji / 组合字符

持久化

刷新后保留

内容微调

版本迁移

定位目标消失

SPEC

先写行为合同

把「应自动扩展到完整词」写成可观察、可断言的结果。

GAP

再找测试空洞

对照优秀开源项目的测试，问 AI：哪些风险维度尚未出现？

REGRESSION

最后守住历史

任何已修复 bug 都先变成测试，再修代码，避免同一问题回来。

08 / AI 辅助开发的完整闭环

让 AI 执行更多，
让自己判断得更清楚

锚定一手资料优先官方仓库、官方文档、成熟开源项目。先让 AI 基于真实材料回答，不让它只靠泛化记忆。

从测试反推行为不要先沉进实现细节。让 AI 找到相关测试，分类：正常路径、边界、失败、兼容、性能、可访问性。

制作风险矩阵让 AI 标出维度、取值、组合与未覆盖 gap；由你决定哪些风险值得付出测试成本。

先写失败测试要求测试确实因缺失行为而失败；否则可能测错对象、测试无效，或功能早已存在。

最小实现并反复运行AI 写代码直到新增测试与原有测试全部通过；若失败，读错误证据，不盲目重试。

重构与审查差异测试保持通过，再整理结构。人工阅读 diff，确认没有越权改动、没有偷改测试迎合实现。

提交意图与证据小而完整地 commit，说明问题、方法和验证；推送到 GitHub 后用 PR 聚合讨论、检查和最终决定。

# 一条可复用的 AI 提示词 基于这个仓库的真实代码与测试，先不要实现功能。 1. 找到与「[功能]」直接相关的全部测试，并按行为维度分类； 2. 解释每个测试保护的风险； 3. 建立「维度 × 场景 × 预期 × 当前覆盖」矩阵； 4. 指出 gap，并区分高风险 / 低风险； 5. 给出最小的新增测试顺序，确保每个测试先失败； 6. 等我确认矩阵后，再实现最小代码让测试通过； 7. 最后运行完整测试，并展示 status、diff 与验证结果。

你不是在「学会 Git」，
你是在升级自己的创作操作系统

1. 一个目标，一个实验分支

只有存在真实不确定性时才分支：不同布局、不同数据结构、不同交互策略。
分支名写假设，例如 experiment/toolbar-bottom，不要写 new-thing。
实验结束必须得出结论：合并、摘取部分成果，或记录为什么放弃。

2. 内容与代码都按意图提交

课程、书稿、HTML、Skill 都可以用 Git；commit 的单位是「一个可解释的变化」。
不要把一天所有工作塞成「update」；让历史本身成为未来 AI 可读的上下文。
二进制大文件另设资产策略，避免仓库被视频、PDF、图片历史拖重。

3. 先测试风险，不测试行数

优先测试会毁掉用户信任的行为：数据丢失、跨端不一致、权限错误、不可逆操作。
测试数量多不等于质量高；每个测试都要能回答「它防止哪种真实失败」。
对探索性 UI 可以先做小原型，再把确定的行为下沉为测试。

4. 把「变慢」当作质量信号

早期 AI 开发的快，常来自没看见复杂度；后来变慢，是边界、验证与回滚进入流程。
用交付吞吐而不是敲代码速度衡量：真正指标是「稳定完成并可继续迭代」。
但也防止宰牛刀杀鸡：根据风险分级，决定测试深度，不把每个临时实验都做成航天工程。

5. What / Why 领先，How 不消失

日常命令可以让 AI 执行，但你必须理解它要改变工作区、暂存区、历史还是远程。
高风险动作前，让 AI 先展示计划、git status、git diff 与回滚方法。
禁止 AI 未经明确授权执行 force push、硬重置、清理未跟踪文件或改写共享历史。

10 / 常见误区与护栏

工程思维的成熟，
首先体现在知道什么不能自动化

应该坚持

先看 status 与 diff，再决定提交。
一个 commit 只表达一个完整意图。
bug 先写可复现测试，再修复。
PR 让别人能看懂目标、风险与证据。
重要仓库设置远程备份与分支保护。
让 AI 报告验证命令与实际结果。

不要这样

把 Git 当成「Dropbox 自动存档」。
把 GitHub 当成 Git 本身。
为每次随手保存都制造无意义 commit。
通过删除失败测试让 CI 变绿。
测试全通过就宣称没有缺陷。
让 AI 在脏工作区里盲目 reset / clean。

常见说法	更准确的理解
commit = 保存	保存写入文件；commit 是把经过选择的项目状态写入可追溯历史。
branch = 复制项目	Git 分支是指向提交的轻量指针；切换分支会让工作区呈现对应快照。
pull = pull request	git pull 是取回并整合远程变化；Pull Request 是 GitHub 上的合并提议与协作页面。
TDD = 测试很多	TDD 是测试、编码、设计紧密交织的短循环；测试数量只是结果，不是定义。
AI 会命令就够了	执行可委托，责任不可委托。你仍需理解目标、影响、证据和回滚。

11 / 四周训练路径

从一条真实需求开始，
不要从背命令开始

WEEK 01

建立档案馆

选一个正在写的 HTML、课程或小工具。
用 AI 初始化仓库并解释每一步。
每天至少做 3 次有意图的 commit。
练习 status、diff、log 三种观察。

WEEK 02

制造平行世界

为一个真实设计选择开 2 个分支。
分别推进，保留清晰提交。
比较结果并记录取舍。
练习 merge 与冲突解释。

WEEK 03

把预期写成测试

挑一个具体功能或 bug。
先找成熟仓库的相关测试。
建立边界矩阵。
完成 3 个 Red–Green–Refactor 循环。

WEEK 04

进入协作网络

推送一个不含敏感信息的仓库。
开一次 Pull Request。
让自动检查运行测试。
把 README 写成「目标 + 用法 + 验证」。

每次交付前的 10 项检查

工作区里是否有不属于本任务的改动？

是否读过最终 diff，而不只看 AI 总结？

提交是否只有一个清晰意图？

新增行为是否有失败过的测试？

是否运行了相关测试与完整测试？

测试是否真的断言用户可观察行为？

是否检查空态、错态、边界与回归？

是否记录限制、风险与回滚方法？

公开仓库是否移除隐私和密钥？

PR 是否让陌生人也能理解为什么？

12 / 五条可直接复制的学习提问

真正改变质量的，
往往只是问题换了一种问法

类比建模

请给出 3 个日常类比解释 X。分别说明每个类比准确、不准确的部分，并给出匹配度与适用边界。

最小概念集

在准确的部分，我必须立刻掌握哪些名词、动词和关系？只给能让我开始阅读真实资料的最小集合。

源码考古

基于这个官方仓库的真实历史，解释它为何形成今天的结构。请给出对应文件、提交或文档证据。

测试先读

全面搜索与功能 X 相关的测试，按行为分类，并从测试反推该功能真正的契约。

找 gap

这些测试没有覆盖哪些维度？请建立风险矩阵，并标明哪些 gap 值得优先补、为什么。

反向验证

AI 的上限不只取决于模型，更取决于你是否拥有：逻辑框架、论证框架、验证框架。

13 / 来源与证据

Pro Git · About Version Control：版本控制记录文件变化并可召回特定版本；Git 属于分布式版本控制。
Pro Git · Recording Changes：工作区、跟踪状态、暂存区与提交的官方说明。
Pro Git · Branches in a Nutshell：Git 分支是指向提交的轻量可移动指针。
GitHub Docs · About repositories：仓库、可见性与协作能力。
GitHub Docs · About pull requests：PR 聚合会话、提交、检查与文件差异，用于提议、审查与合并变化。
Agile Alliance · What is TDD?：失败测试、最小实现、重构与重复循环；同时列出常见陷阱。

GETNOTE · 2026-08-13

GETNOTE · 2026-08-14

说明：录音中的具体仓库规模与「测试代码多一个量级」等瞬时数据未作为结论使用；本指南保留方法论，技术定义以可核查的一手资料为准。

从类比走向系统化试错

AI 降低的是执行成本，工程方法降低的是错误成本。

四层系统：从想明白，到做扎实

Git 不是「保存按钮」，而是一座本地的项目档案馆

门外的工作桌

「平行世界时光机」负责点燃直觉，「档案馆」负责校正结构

像平行世界

不是真正改写过去

命令可以交给 AI，但这些名词与动词必须认得

GitHub 是协作与公开资产层

个人实验系统

clone

fork

pull request

TDD 不是「写完再测」，而是用测试驱动设计决策

测试真正提供什么

测试不能保证什么

别问 AI「这个功能怎么实现」，先问「它在哪些维度会失败」

先写行为合同

再找测试空洞

最后守住历史

让 AI 执行更多，让自己判断得更清楚

你不是在「学会 Git」，你是在升级自己的创作操作系统

1. 一个目标，一个实验分支

2. 内容与代码都按意图提交

3. 先测试风险，不测试行数

4. 把「变慢」当作质量信号

5. What / Why 领先，How 不消失

工程思维的成熟，首先体现在知道什么不能自动化

应该坚持

不要这样

从一条真实需求开始，不要从背命令开始

建立档案馆

制造平行世界

把预期写成测试

进入协作网络

每次交付前的 10 项检查

真正改变质量的，往往只是问题换了一种问法

类比建模

最小概念集

源码考古

测试先读

找 gap

反向验证

从类比
走向系统化试错

AI 降低的是执行成本，
工程方法降低的是错误成本。

Git 不是「保存按钮」，
而是一座本地的项目档案馆

「平行世界时光机」负责点燃直觉，
「档案馆」负责校正结构

命令可以交给 AI，
但这些名词与动词必须认得

TDD 不是「写完再测」，
而是用测试驱动设计决策

别问 AI「这个功能怎么实现」，
先问「它在哪些维度会失败」

让 AI 执行更多，
让自己判断得更清楚

你不是在「学会 Git」，
你是在升级自己的创作操作系统

工程思维的成熟，
首先体现在知道什么不能自动化

从一条真实需求开始，
不要从背命令开始

真正改变质量的，
往往只是问题换了一种问法