smallnestHexohttps://colobu.com/All rights reserved 2026, smallnest大道至简 Simplicity is the ultimate form of sophistication鸟窝2026-07-04T08:14:49.784Zsmallnest
「A code smell is a surface indication that usually corresponds to a deeper problem in the system. The term was first coined by Kent Beck while helping me with my Refactoring book.」 （坏味道是系统表面的一个信号，往往对应着更深层的问题。这个词是 Kent Beck 帮我写《重构》时造的。）
有意思的是，据 c2 wiki 的记载，Beck 造这个词时的灵感，部分来自同事 Massimo Arnoldi 的"鼻子"——一种对烂代码的直觉嗅觉。
真正让这个词火遍全球的，是 1999 年出版的《Refactoring: Improving the Design of Existing Code》。Fowler 在书里专门用一章（和 Beck 合写）罗列了一份"坏味道目录"，并给每种味道配了对应的"重构手法"。从此，"我觉得这段代码有点臭"这种模糊的工程师直觉，第一次有了可以命名、可以分类、可以按方子治疗的框架。
自从 Karpathy的llm-wiki理念提出来之后，我收集资料的时候特意使用Obsidian web clipper进行收集，最近几个月也收集了700多篇资料，也在Hermes中建立了llm-wiki，这次我使用chao-rag-wiki 建立了RAG索引，让我们比较一下这两个skill搜索资料的效果。
查询一："loop engineering"
chao-rag-wiki（hybrid + rerank）召回了散在多篇原文里的片段：
1 2 3 4 5 6 7
[1] rerank=8.0 PART 2: WHAT LOOP ENGINEERING ACTUALLY IS articles/...Loops What Every AI Engineer Needs to Know in 2026.md [2] rerank=7.0 工程化的三个层次 articles/...深度拆解：AI 智能体 Harness 的构造.md [3] rerank=7.0 Most Developers Do Not Need Agent Loops Yet [4] rerank=7.0 Agent Harness 拆解：AI Agent 真正的工程底座 [5] rerank=6.0 > I don't talk to an agent anymore, I talk to a loop
"Clear is better than clever." 清晰胜于聪明。 —— Rob Pike, Go Proverbs
第 23 章把重构讲完了。嗅坏味道、套 Fowler 手法、小步施工、每步测试，这套东西对 Java、Python、Go 一视同仁。但真到 Go 上手你会发现，Fowler 的目录够不着 Go 的好几层脾气。一段能跑的 Go 代码，可能还停在 Go 1.10 的写法，不地道；可能并发原语用错了，race detector 一开就红，不安全；也可能分配没控住，cache line 在 false sharing，不快。这些坏味道扫不出来，是 Go 二十年攒下来、只有老手才摸得到的门道。
一是 Go 的地道写法绑版本。同一件事，Go 1.10 和 Go 1.22 的标准答案不一样。循环找切片里有没有某个元素，1.10 要手写 for 循环，1.21 一行 slices.Contains 搞定；求最小值，1.20 要 if-else，1.21 有内置 min。Agent 训练数据里两种写法都有，随手给你写哪种全看运气。代码是能跑，可能是个十年前的化石。
二是 Go 的并发坑深，而且静默。一个 map 并发读写不会马上崩，要等压力上来、等到生产环境的某个深夜才 panic。一个 sync.Mutex 被复制了，go vet 查得出，Agent 不会主动跑。goroutine 泄漏更无声无息，程序能跑，内存曲线却悄悄爬坡。这些坑 Fowler 的坏味道目录里一个都没有。
三是 Go 的性能是测出来的，不是猜出来的。Dave Cheney 那句「You can't optimize what you don't measure」是 Go 性能圈的宪法。可 Agent 的默认行为恰恰是猜，看一眼代码凭直觉说「这里用 sync.Pool 优化一下」，既没 benchmark 也没 pprof。猜对的概率比你想的低。
Skill 内置 35 条转换规则，每条带一个版本门控，只在项目的 Go 版本够格时才启用。规则从 Go 1.0 一路排到 1.26+，挑几个有代表性的：
Go 版本
老写法
新写法
1.0+
time.Now().Sub(start)
time.Since(start)
1.13+
err == io.EOF
errors.Is(err, io.EOF)
1.18+
interface{}
any
1.18+
strings.Index + 手动切片
strings.Cut
1.19+
atomic.StoreInt32(&v, 1)
var v atomic.Int32; v.Store(1)
1.20+
fmt.Errorf("...: %w: %w", e1, e2)
errors.Join(...)
1.21+
手写 for 循环找元素
slices.Contains
1.21+
if a<b {v=a} else {v=b}
v = min(a, b)
1.21+
var once sync.Once; once.Do(...)
sync.OnceFunc(...)
1.22+
for i := 0; i < n; i++
for i := range n
每条规则都配 before/after 代码对照，机械、可执行。这正是 Go 团队 modernize 分析能被 Agent 接住的地方。
24.3.2 安全保护：读 go.mod，绝不越级
真正关键的不是这 35 条规则，是它怎么决定该用哪条。流程很死板：
先读 go.mod 里的 go 指令，拿到项目声明的 Go 版本；
扫描目标范围内所有 .go 文件（排除 vendor/、.git/、testdata/）；
对每个文件，只应用版本 ≤ 项目版本的规则，从老到新依次套；
最后打印一份改了什么、跳过了什么的汇总。
铁律只有一条，但很硬：绝不应用需要比项目声明版本更高的规则。项目还停在 Go 1.20，就不会给你塞 1.21 的 min 和 slices，塞了编译不过。这条把「现代化」和「改坏」之间的边界钉死了。
这条保护和第 23 章 /refactor 的五阶段协议是同一种思路：把人最容易手滑的地方改成 Agent 必须遵守的护栏，这里是「图新」而越级升级。人升级 Go 时常犯的错，比如把目标版本改高了却忘了改 go.mod，或者用了新 API 却没加 import，/modern-go 用版本门控和 requires importing 的提示一条条堵上。
24.3.3 实演：一段老代码怎么被现代化
光看规则表没感觉，跑一段。假设 go.mod 写的是 go 1.21，项目里有这么个函数，写法停在 Go 1.13：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
funcparseHeader(buf []byte) (key, val string, ok bool) { if i := bytes.Index(buf, []byte("=")); i >= 0 { key = string(buf[:i]) val = string(buf[i+1:]) ok = true } return }
funcparseHeader(buf []byte) (key, val string, ok bool) { before, after, found := bytes.Cut(buf, []byte("=")) if found { key, val, ok = string(before), string(after), true } return }
Skill 还配 8 份参考资料，按需加载：benchmarking、memory-optimization、cpu-optimization、cache-optimization、concurrency-perf、pgo、tooling、version-changes。其中两块是 Go 圈的硬骨头：PGO（Profile-Guided Optimization）的完整工作流，和 Go 1.12 到 1.27 的关键性能变更（哪个版本改了 GC、哪个版本改了调度器，升级时要留意什么）。CPU 缓存那块也讲得细，cache line 对齐、false sharing 检测、AoS 对 SoA 的数据局部性取舍，这些资深 Go 工程师才碰得到，Agent 默认不会主动想。
问题分类：并发竞争（吞吐量不随 CPU 增加） 诊断步骤： 1. go test -bench=. -cpuprofile=cpu.out 2. go tool pprof -http=:8080 cpu.out → 看 mutex 热点 3. go test -race → 确认无数据竞争 4. 看锁竞争：临界区只有一个 n++，纯计数
它最显眼的标签是 README 里那句 "Opinionated by design"，刻意固执己见。它明确说，这不是通用、官方的 Go 风格指南，是个人偏好，要的是真实代码库里的一致性、可维护性和生产可用性。紧接着一句很关键：「如果你仓库已经有自己的约定，那些约定通常优先。」这一句把固执己见和尊重本地两边都顾上了，Skill 给默认值，但不覆盖既有规矩。
Bootstrapped with Claude Code by distilling my Go project commits. Edited, tested, reviewed and reworked by a human. No AI slop here. AI-made skills are useless.
先用 Claude Code 把自己 Go 项目的提交蒸馏成 Skill 草稿，再由人编辑、测试、审查、返工。最后那句「No AI slop here. AI-made skills are useless.」是整个项目的主张：AI 生成的 Skill 没人把关就是废纸，人审过的才是 Skill。这跟本书第 2 章 Matt Pocock 的「real engineering, not vibe coding」、第 12 章的 maker-checker 分离是一个调子。
24.7.1 28+ 原子 Skill，交叉引用
cc-skills-golang 把 Go 工程拆成 28+ 个原子、可交叉引用的 Skill，分四大类加一批框架/库 Skill：
"Clear is better than clever." 清晰胜于聪明。 —— Rob Pike, Go Proverbs
第 23 章把重构讲完了。嗅坏味道、套 Fowler 手法、小步施工、每步测试，这套东西对 Java、Python、Go 一视同仁。但真到 Go 上手你会发现，Fowler 的目录够不着 Go 的好几层脾气。一段能跑的 Go 代码，可能还停在 Go 1.10 的写法，不地道；可能并发原语用错了，race detector 一开就红，不安全；也可能分配没控住，cache line 在 false sharing，不快。这些坏味道扫不出来，是 Go 二十年攒下来、只有老手才摸得到的门道。
本章介绍五个 Go 专属的 Skill，正好覆盖 Go 工程的四个面：现代化（/modern-go）、性能（chao-go-perf）、并发（chao-go-sync）、风格（go-style-guide），外加一个把这几样打包、还顺带做了效果评估的全家桶（cc-skills-golang）。前三个是本书作者 smallnest 写的，对，写这本书的人和写这些 Skill 的人是同一个；后两个分别来自 madflojo（Benjamin Cane）和 samber。
]]>
Go 语言技能：AI 时代的 Go 开发工具链2026-06-28T06:46:22.016Zsmallnest
「Any fool can write code that a computer can understand. Good programmers write code that humans can understand.」 任何傻瓜都能写出计算机能看懂的代码。好程序员写的是人能看懂的代码。 —— Martin Fowler
第 22 章解决了「人怎么读懂 AI 写的代码」，用 UML 把代码画成图。
读懂之后呢？你打开 AI 生成的代码，能跑，但是一团乱麻：一个方法三百行，一个类管了八件事，同样的逻辑复制了五遍。这时候怎么办？
重构。
这件事本身不新鲜，Martin Fowler 1999 年就把它写成了一本书。变的是执行者。以前是人对着那本书一处一处手动改，现在是 AI 对着同一本书的目录自动改，人退到后面审查 diff。
手法分六大类：组合方法（Composing Methods）、在对象间搬移特性（Moving Features Between Objects）、组织数据（Organizing Data）、简化条件表达式（Simplifying Conditional Expressions）、简化方法调用（Simplifying Method Calls）、处理泛化关系（Dealing with Generalization）。
整个流程是「症状到处方」：你先嗅到味道，比如「过长方法」或者「Feature Envy」，目录再告诉你该用哪几种手法去治。这套映射关系明确、能机械执行，也正是 AI Agent 接得住的地方。
「Any fool can write code that a computer can understand. Good programmers write code that humans can understand.」 任何傻瓜都能写出计算机能看懂的代码。好程序员写的是人能看懂的代码。 —— Martin Fowler
第 22 章解决了「人怎么读懂 AI 写的代码」，用 UML 把代码画成图。
读懂之后呢？你打开 AI 生成的代码，能跑，但是一团乱麻：一个方法三百行，一个类管了八件事，同样的逻辑复制了五遍。这时候怎么办？
重构。
这件事本身不新鲜，Martin Fowler 1999 年就把它写成了一本书。变的是执行者。以前是人对着那本书一处一处手动改，现在是 AI 对着同一本书的目录自动改，人退到后面审查 diff。
这句话非常有哲理。Dex Horthy 在 2025 AI Engineer 大会上独立提出了："Don't outsource the thinking" / "AI cannot replace thinking, it can only amplify the thinking you have done."，但是今年你看， AI已经外包了我们的思考，你只需说出的你需求，智能体就能帮助你生生成你要的程序，但是 AI 没有办法帮我们理解啊。
这句话非常有哲理。Dex Horthy 在 2025 AI Engineer 大会上独立提出了："Don't outsource the thinking" / "AI cannot replace thinking, it can only amplify the thinking you have done."，但是今年你看， AI已经外包了我们的思考，你只需说出的你需求，智能体就能帮助你生生成你要的程序，但是 AI 没有办法帮我们理解啊。
]]>
UML 新用途：让 AI 理解你生成的代码2026-06-28T06:46:22.016Zsmallnest
"The goal isn't a graph that wows you with how complex your codebase is — it's a graph that quietly teaches you how every piece fits together." 目标不是一张让你惊叹「代码库真复杂」的图——是一张默默教你每个部分如何协作的图。
"The goal isn't a graph that wows you with how complex your codebase is — it's a graph that quietly teaches you how every piece fits together." 目标不是一张让你惊叹「代码库真复杂」的图——是一张默默教你每个部分如何协作的图。
如果你写过前端，大概率读过他的书。他在 Google Chrome 领导开发者体验工程团队近 14 年，主导了 Chrome DevTools、Lighthouse、PageSpeed Insights、Core Web Vitals 等工具和标准的建设。2026 年转任 Google Cloud AI 总监，负责 Gemini、Vertex AI 和 Agent Development Kit。著有《Learning JavaScript Design Patterns》《Leading Effective Engineering Teams》，博客名篇《The Cost of JavaScript》从 2017 年到 2023 年持续更新了七年，几乎定义了 web 性能优化的讨论框架。他在前端工程和 web 性能领域的影响力，塑造了一整代前端开发者的工程实践。
2026 年初，他的注意力从"人怎么写更好的代码"转向了"AI 怎么写更好的代码"。2 月 15 日，他开源了 agent-skills，定位一句话："Production-grade engineering skills for AI coding agents"——把资深工程师的工作流、质量门禁和最佳实践，编码为 Agent 不可绕过的结构化约束。 到 6 月，近 60K star。
如果你写过前端，大概率读过他的书。他在 Google Chrome 领导开发者体验工程团队近 14 年，主导了 Chrome DevTools、Lighthouse、PageSpeed Insights、Core Web Vitals 等工具和标准的建设。2026 年转任 Google Cloud AI 总监，负责 Gemini、Vertex AI 和 Agent Development Kit。著有《Learning JavaScript Design Patterns》《Leading Effective Engineering Teams》，博客名篇《The Cost of JavaScript》从 2017 年到 2023 年持续更新了七年，几乎定义了 web 性能优化的讨论框架。他在前端工程和 web 性能领域的影响力，塑造了一整代前端开发者的工程实践。
2026 年初，他的注意力从"人怎么写更好的代码"转向了"AI 怎么写更好的代码"。2 月 15 日，他开源了 agent-skills，定位一句话："Production-grade engineering skills for AI coding agents"——把资深工程师的工作流、质量门禁和最佳实践，编码为 Agent 不可绕过的结构化约束。 到 6 月，近 60K star。
Every 团队在 README 里有一句话值得注意：这个项目刻意固执己见（opinionated by design）。他们欢迎 issue 和 PR 讨论，但不会接受所有贡献。不是所有建议都是好建议，不是所有定制都应该变成配置选项。这个态度在开源社区不太常见，但放在方法论工具上很合理：一个没有主张的工具比没有用还糟，因为它让你觉得你在做事。
这个分工背后是一笔所有用 AI 写代码的人都在付、但很少认真算过的账。用 Opus 读代码库、找 bug、排优先级，值。用 Opus 敲每一行代码、跑每一个测试、写每一句 commit message，不值。但现在的 AI 编程工具不管这些——你给它们什么模型，它们就全程用什么模型。预算好的团队手动切模型——研究阶段用 Opus，实现了切 Sonnet，跑测试了再切 Haiku。切来切去，时间都花在模型下拉菜单上了。
Rejected (false positives): ✗ SEC-03: https_proxy in src/fetch.ts:10 flagged as SSRF → By-design: standard proxy convention. Added to veto log. ✗ TYPE-01: strict:false in tsconfig.json flagged as missing type safety → Monorepo root config. Sub-packages each enable strict independently.
shadcn 把这个项目开源不到一周 5000+ star。社区的热情不是因为新技术，并行子智能体、验证门禁、worktree 隔离这些前面都讲过了。热的是它的主张：AI 编程的成本不必是刚性的。你不用为了质量把 Opus 用在每一行代码上。让 Opus 做它最擅长的，理解、判断、规划，执行外包给便宜的。在 AI API 按 token 计费的现实里，这个主张比任何架构模式都更直接地改变了你的开发成本。
这个分工背后是一笔所有用 AI 写代码的人都在付、但很少认真算过的账。用 Opus 读代码库、找 bug、排优先级，值。用 Opus 敲每一行代码、跑每一个测试、写每一句 commit message，不值。但现在的 AI 编程工具不管这些——你给它们什么模型，它们就全程用什么模型。预算好的团队手动切模型——研究阶段用 Opus，实现了切 Sonnet，跑测试了再切 Haiku。切来切去，时间都花在模型下拉菜单上了。
先是 STATE.md，项目的活档案、中央导航层。它记录当前里程碑、活跃阶段、已完成和待办的计划、进度指标、累积的决策，还有会话连续性笔记。所有工作流启动时先读 STATE.md，做完重要动作后写回。它就是第 12 章说的那根脊柱：明天早上的运行从今天停下的地方接着走，不是从零开始。gsd-tools.cjs 甚至提供 state get <section> 让你按小节查它。
2026 年 6 月，两条推文把这个矛盾推到了台前。Peter Steinberger（OpenClaw 作者）的那句话在 48 小时内获得 220 万次浏览。几天后，Boris Cherny（Anthropic Claude Code 负责人）在 WorkOS 的 Acquired Unplugged 活动上说了几乎同样的话："I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
全网炸了。但没人说得清"loop"到底是什么。有人说是 Ralph Loop 的翻版，有人说是"戴了顶帽子的 cron job"，有人说"prompt engineering 已死"。一周之内，Reddit、Hacker News、X 上的讨论翻了几十页，最诚实的回答是 Matthew Berman 那句："Nobody knows but him and Boris."
Addy Osmani 随即发表了长文"Loop Engineering"，给了这个概念第一个完整的拆解。本章基于 Osmani 的框架，结合 Boris Cherny 的实践、Geoffrey Huntley 的 Ralph Loop 思想、以及 AlphaSignal 的四条件测试，回答三个问题：Loop Engineering 是什么？它和前十一章的方法论什么关系？你真的需要它吗？
12.1 从提示 Agent 到设计循环
先把 Boris Cherny 的三阶段演化说清楚。
一年前，Cherny 的写代码方式和所有工程师一样：IDE + 自动补全。然后他开始同时跑五到十个 Claude 会话，手动提示每一个——这个修 bug，那个做 feature，还有一个跑测试。每一条指令都是他亲手打的。他的时间不再是写代码，而是在五个终端窗口之间切来切去，给每个窗口里的 Claude 写 prompt。
然后他停了。不是不用 Claude——而是不再自己打 prompt。他写了一组小程序，每个程序做三件事：找到该做的事、把事交给 Claude、检查做完了没有。这些程序按时间表运行——有的每分钟一次，有的每天一次，有的跑到达成某个条件才停。Cherny 把它们叫 loops。他的原话是："My job is to write loops."
一个实战例子：让 Agent "go through my last 50 sessions and mine them for the corrections I keep making"。结果：49 个会话分析，86 个纠正挖掘，每个引用对照实际会话验证。产生的报告显示反复出现的纠正模式——AI slop、虚构词语、错误事实。
2026 年 6 月，两条推文把这个矛盾推到了台前。Peter Steinberger（OpenClaw 作者）的那句话在 48 小时内获得 220 万次浏览。几天后，Boris Cherny（Anthropic Claude Code 负责人）在 WorkOS 的 Acquired Unplugged 活动上说了几乎同样的话："I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
全网炸了。但没人说得清"loop"到底是什么。有人说是 Ralph Loop 的翻版，有人说是"戴了顶帽子的 cron job"，有人说"prompt engineering 已死"。一周之内，Reddit、Hacker News、X 上的讨论翻了几十页，最诚实的回答是 Matthew Berman 那句："Nobody knows but him and Boris."
Addy Osmani 随即发表了长文"Loop Engineering"，给了这个概念第一个完整的拆解。本章基于 Osmani 的框架，结合 Boris Cherny 的实践、Geoffrey Huntley 的 Ralph Loop 思想、以及 AlphaSignal 的四条件测试，回答三个问题：Loop Engineering 是什么？它和前十一章的方法论什么关系？你真的需要它吗？
Sunsetting。 Vibe Kanban 已宣布逐步关闭。官网上挂着公告："Vibe Kanban is sunsetting. The project will continue as open source and community maintained."，主要原因是开发者团队找不到合适的商业模式，主要用户都是免费用户。从产品角度看，做 Agent 协作工具的 SaaS 商业模式仍在摸索期——开发者倾向开源免费工具，企业市场仍在观望 Agent 成熟度。夹在中间的 SaaS 产品找不到舒适的定价锚点。
gstack 的代表作是二十三个虚拟角色。产品经理、架构师、安全专家、性能工程师、数据库管理员，各有各的审查维度。"你是一个有十五年经验的员工工程师，审查这份代码的安全问题"和"review this code for security"的区别，第 5 章实测过。前者能发现上下文相关的逻辑漏洞，后者只能看到 SQL 注入。角色不是噱头，是审查深度。
文档质量。英文 Skill 生成的 PRD 翻译后丢精度。"The system must validate user input"翻译成"系统必须验证用户输入"没问题。但带技术精确度的内容，"Handle race condition on concurrent refund callbacks using idempotency key"，翻译后语义会变形。superpowers-zh 和 spec-kit-zh 直接中文产出，不经过翻译层。
审查结论是建议，不是命令。"Treat review output as advisory. Never blindly apply it."Agent 对每条发现都要验证：读代码、读依赖、拒绝不合理的边界情况、拒绝过度工程化的修改。这和 gstack 的"角色审查 → 你有否决权"逻辑一致。自动化不是 AI 说了算，是 AI 找了问题，你判断该不该修。
2025 年 10 月发布，不到一年冲到 201K+ Stars。这个数字在所有 AI 编程方法论相关仓库里排第一——超过 gstack（约 5K），超过 OpenSpec（约 49K），超过 Ralph Loop 所有实现的总和。
从 README 第一段就能看出来：
"It starts from the moment you fire up your coding agent. As soon as it sees that you're building something, it doesn't just jump into trying to write code. Instead, it steps back and asks you what you're really trying to do."
<HARD-GATE> Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. </HARD-GATE>
Garry Tan 自己说过一句话，概括了 gstack 的设计理念：他本质上是一个工程经理，管理一支临时工模型大军。这句话在卷首语中也出现过——Claude Code 的创造者 Boris Cherny 说过类似的话。但 Garry Tan 比 Cherny 多走了一步：他给这支 AI 大军建立了一套组织架构——角色分工、流程阶段、质量门禁、交付流水线。一群零散的 Agent 变成了一个有结构的虚拟工程团队。
gstack 每个 Skill 既定义行为，也定义人格。/plan-ceo-review 的开头是"你是 CEO / 创始人。你的职责是重新思考这个问题，找到'十星级产品'的愿景。"人格设定改变了 Agent 的认知姿态——它不光知道要做什么，还知道用什么视角、什么标准、什么语气来做。
这是工程决策，不是包装。
当你对 AI 说"审查这个架构"，它给出的反馈取决于它认为自己是谁。如果它认为自己是一个代码审查者，会关注命名、结构、可读性。如果它认为自己是工程经理，会关注模块边界、扩展性、失败模式。如果它认为自己是 CEO，会关注这个架构在多大程度上服务于产品愿景、哪些复杂度是为未来假设买单、哪些简化会释放更多迭代速度。
/plan-eng-review——工程经理视角。 这个角色锁定架构：ASCII 架构图、数据流图、状态机、测试矩阵。核心任务是把隐藏的假设翻到台面上——组件 A 依赖组件 B 的什么接口？并发场景的竞态条件是什么？失败模式的降级策略是什么？这些问题不在这一步澄清，到 Build 阶段再发现，返工成本是十倍起。
/plan-devex-review——开发者体验视角。 这个角色做一件事：实际走一遍"新开发者上车"的流程。测量 TTHW（Time to Hello World）——clone 仓库到看到第一个成功运行的功能要多久——并与同类项目做基准对比。追踪摩擦点：哪些步骤需要手动配置、哪些文档缺失或过时、哪些错误信息让人困惑。开发者体验就是产品体验——你的 API 需要读三篇文档才能调用成功，用户不会怪文档，用户会怪你的产品。
审查逻辑分成两条通道。结构通道：检查代码结构、命名一致性、错误处理完备性、测试覆盖盲区——传统代码审查的自动化版，可以自动修复机械问题。对抗通道：假设自己是攻击者或极端场景——"如果这个 API 被每秒 1000 次调用会怎样？""中间件崩溃重启后状态能恢复吗？""用户同时开两个 tab 操作，数据会冲突吗？"这类问题传统 CI 永远抓不到，因为它们不是代码逻辑错误，是代码在真实世界的行为假设错误。
touchstart calls start(), then 300ms later synthetic click fires start() again. On desktop with touchscreen, this means: first touch during game-over resets AND starts in one tap (not two separate actions). Fix: track if touchstart already handled.
