系统判断力 · Evals + Code Taste + meta-skill(收官)

一段 production code 摆在你面前 · 你能问什么问题?

让我用一个具体场景开篇。你是一个 AI native team 的新人,入职第二周。同事提了一个 PR,做的事是给 research agent 加一个 web search 工具。代码很短,只有 5 行:

# Diff: app/tools/search.py
+ import requests
+
+ def search(q):
+     r = requests.get(f"https://api.search.com/?q={q}").json()
+     return r["results"][:10]

PR description 是 "Add web search tool to research agent"。CI 跑过了,test 也 pass。同事问你,你看下,有问题就 review 一下。

vibe coder 第一反应通常是这样:代码很简单,看起来 OK,approve 吧。原因是代码字面上没有 bug,函数能跑、逻辑清晰、语法正确,扫一眼没毛病。但 production engineer 第一反应是另一种,看到这 5 行代码,脑子里立刻跑一遍 5 到 7 个固定问题:失败怎么处理?状态在哪里?有 eval 吗?能 debug 吗?trade-off 选对了吗?抽象合理吗?有没有 security 风险?同一段代码,两种 reviewer 看见的是两个不同的对象。

10 秒钟内,production engineer 会发现这段代码有 至少 6 个 P1 问题。没有错误处理,网络断了直接抛 KeyError;URL 拼接没有 escape,有 injection 风险;top-10 这个数字怎么定的没说;这个 tool 没有 log,将来 debug 时不知道搜了什么;API key 在哪里没看到,同事说 hardcode 在另一个文件;这个 search.com 是什么 service,有 SLA 吗。6 个问题每一个都是 production 里可能引爆的雷,reviewer 在 10 秒钟内能 spot 完。

这 10 秒钟跑完 6 个问题的能力,是 4 大实验室 verbatim 列为 entry-level baseline 的 judgment 加 taste。它不是读完很多本书的产物,是学过的 mental model 反复应用的产物。这一章我们要建立的就是这种判断力的种子。种子完整长成需要看够多优秀作品、做真实项目、跟同事互相 review,foundations 给你种子,不给你成熟果实。成熟需要 6 个月到 2 年的 production 实战加 reflection。但种子必须先种下,这就是 Stage 4 的存在价值。

1. Eval · 4 层 framework

判断力的第一个具体表达,是能不能告诉一个系统好还是不好。这是 eval 解决的事。Eval 不是一种东西,是多个层次叠加起来的体系。最底层是 unit eval,测单个函数、工具或 prompt;再上一层是 behavior eval,测整体行为的语气、准确度、安全;再往上是 production A/B test,在真实用户里分组对比新旧;最高层是 human eval,人工 review 高风险或边界 case。每一层有自己的方法、工具、频率、适用场景,合起来才是 production-grade 的 eval 体系。本章只覆盖这 4 层 baseline,不教 RL eval data flywheel、Agent trajectory eval、Reward model 训练这些更深的话题,它们分别归 #3、#6、#8 路书。

1.1 为什么 vibe coder 通常没 eval

vibe coder 最常见的误区是把 eval 等同于单元测试 LLM 输出。所以很多人会写一个 assert,例如 assert llm("3 + 4 = ?").startswith("7"),跑通就觉得我有 eval 了。事实是这只是 unit eval 的最浅层,production LLM 系统的 eval 体系至少 4 层,少了任何一层都意味着某种 production 故障早晚找上你。

不做 eval 的 cost 不是少了点严谨,而是非常具体的盲操作风险。你不知道改 prompt 是变好了还是变差了;你不知道新模型上线是不是回归了;你不知道用户报的 bug 是不是其他用户也碰到了。盲操作系统几个月,质量就在不知不觉中漂走,等你发现的时候已经晚了几十个 release。所以 eval 的本质不是工程洁癖,是 production 系统的 sensor —— 没有 sensor 你不知道飞机在掉高度。

1.2 Unit Eval · 测单个 prompt / 工具的输出

Unit eval 给单一组件(一个 prompt、一个工具、一个 chain)固定输入,验证输出是否符合预期。频率上每次 commit 或 PR 都跑,工具用 pytest 或 vitest 套上 CI 就够。下面是最小起步的样子:

# tests/test_classifier.py
import pytest
from app.llm import classify_intent

@pytest.mark.parametrize("text, expected", [
    ("我想退款", "refund"),
    ("订单还没发货", "shipping"),
    ("你好", "greeting"),
    ("给我推荐几个产品", "recommendation"),
])
def test_intent_classifier(text, expected):
    result = classify_intent(text)
    assert result == expected

简单到不能再简单,但这就是 unit eval 的本质:用确定的输入跑 LLM,把 output 跟期望对比。你不需要 fancy 框架,pytest 加几个 parametrize case 就能跑起来,门槛极低。门槛低也意味着没理由不做,任何 LLM 应用都应该有这一层。

unit eval 有两个反直觉点要 internalize。第一,LLM unit eval 的输出通常是 fuzzy 的,同一 prompt 跑两次结果可能不同。解决办法要么降 temperature 到 0(更稳定但仍非完全 deterministic),要么跑多次取大多数结果(majority vote),要么写更松的 assert(用 contains、starts with、in expected set,而不是精确 equal)。第二,unit eval 不查全,它只能告诉你在这些固定测试 case 上 OK,不能保证所有 case 都 OK,这是 behavior eval 的工作。把 unit eval 当成 production eval 的全部,是最常见的 fallacy。

1.3 Behavior Eval · 测整体行为质量

Behavior eval 准备 30 到 300 个 金标 case(用户问加期望回答),让你的 LLM 系统跑过,用另一个 LLM 或人评估输出质量。频率上每个 release 之前跑一次,工具可以用 Anthropic Evals API、LangSmith,或者自家 harness。下面是最小起步:

# evals/run_behavior_eval.py
GOLDEN_SET = [
    {
        "input": "我的订单 12345 还没到",
        "expected_behavior": "应该: 1) 道歉 2) 查询订单状态 3) 给具体 ETA",
        "must_not_do": ["承诺退款", "猜测 ETA"],
    },
    # ... 30+ cases
]

def evaluate(model_response, expected_behavior, must_not_do):
    # 用 stronger model 做 judge
    judgment = judge_llm(f"""
    Response: {model_response}
    Expected: {expected_behavior}
    Must NOT: {must_not_do}

    Score 1-5 + brief justification.
    """)
    return judgment

# 跑所有 case
results = [evaluate(production_agent(case["input"]),
                    case["expected_behavior"],
                    case["must_not_do"])
           for case in GOLDEN_SET]

Behavior eval 设计上有几个关键点。Golden set 要持续扩展,每发现一个 bug 就加一个 case 防止回归,一年后它就是你 system 历史所有 bug 的合集,越大越值钱。Judge model 必须比 production model 强,Claude 3.5 Opus 评 Claude 3.5 Sonnet 输出、GPT-4 评 GPT-4-mini 输出,如果 judge 跟 production 同级,judge 倾向给自己人偏袒分。评分要多维度,不只对不对,还有语气合适、引用准确、没说不该说、格式合规等多维,单维度 binary 评分丢掉太多信息。每个 score 要带 why 让结果可解释,这样 fix 时知道往哪改,不会盲修。

1.4 Production A/B Test · 真实用户分组对比

A/B test 在 production 把用户分成两组,A 组走旧 prompt 或旧 model,B 组走新 prompt 或新 model,对比两组的核心 metric,例如完成率、满意度、cost、latency。频率上重要变更前必跑,以及持续跑,工具用 feature flag 平台(LaunchDarkly、Flagsmith、Statsig)加自家 metrics pipeline。最小起步代码如下:

# 用 feature flag 决定走哪个 prompt
def get_prompt(user_id):
    if feature_flag.is_enabled("new-prompt-v2", user_id):
        return NEW_PROMPT_V2
    return OLD_PROMPT_V1

def chat(user_id, message):
    prompt = get_prompt(user_id)
    response = llm.call(prompt, message)

    # 关键:记录 metric
    metrics.log({
        "user_id": user_id,
        "prompt_variant": "v2" if feature_flag.is_enabled("new-prompt-v2", user_id) else "v1",
        "input_tokens": response.input_tokens,
        "output_tokens": response.output_tokens,
        "latency_ms": response.latency_ms,
        "completion": response.text,
    })
    # 用户后续行为也要记录 — 是否 followed up / 是否 satisfied
    return response.text

A/B test 有几个常见陷阱必须避开。样本量要足,10 个用户对比毫无统计意义,通常需要至少几百到几千用户才能看出真实差异。分组要随机,不能前 100 用户走 A、后 100 走 B(时段有差异),要用 hash(user_id) 这种方式分。观察期要够长,某些 metric 例如 retention、满意度需要几天才能稳定,提前下结论容易误判。最后要看分位数不要只看均值,p99 latency 跟 mean latency 完全两件事(回到 Ch 6 学过的),均值掩盖长尾,长尾掩盖真实用户体感。

1.5 Human Eval · 高风险 case 必须人来 review

Human eval 选择高 stakes、边界或罕见的 case,让人工 reviewer 打分。频率上重大变更前跑一轮加持续抽样,工具用自家 review tool 就够。为什么自动 eval 替代不了人?有三类场景:某些质量维度模型 judge 自己都不靠谱(taste、文风、微妙 tone),高风险场景(医疗、法律、金融)出错代价大,以及边界 case(模型在两个 reasonable 答案之间摇摆,没有正确答案,需要人决定哪个更好)。这三类场景里没有人,你的 eval 就有盲区。

最小起步很简单:每周从 production 随机抽 20 到 50 个 case,3 个 reviewer 各自打分 1 到 5,取均值。低分 case 加入 golden set 防止回归。容易 internalize 的反直觉点是,human eval 不是等系统出问题再做,它是 production 系统的持续 input。Anthropic 和 OpenAI 内部都有专门的 eval team 做这事,production-grade LLM 系统里 human eval 是 day-1 计划的一部分,不是事后补的 patch。

4 层 eval 综合表

Eval design 5 条原则

最后,把 eval 思维 collapse 成 5 条 design 原则,这是你以后看任何 LLM 系统 eval setup 时的 mental checklist。eval 写在第一次实验之前,不是事后补,写完代码再去想 eval 你已经 bias 进了我已经做出来了心智,容易接受 ad-hoc 的、刚好让自己代码 pass 的 eval,先写 eval 再写代码,让 eval 驱动设计。Golden set 持续扩展,每发现一个 bug 加一个 case 到 golden set,一年后你的 golden set 是宝藏,里面记录了所有你的系统犯过的错,新版本必须跑过这套才能上。

Eval 本身要 maintainable,不要写 100 个 eval 每个都需要手动维护 prompt,这种系统很快没人愿意维护,结构化 golden set 加公共 evaluator 让加 case 跟加 row 一样简单。同时接受 eval 不能 100% 自动,总有 5 到 10% 的 case 需要人 review(taste、边界、风险),不要硬上 100% 自动,留出人的位置反而让系统更稳。最后多维度 score 不要只 binary,对错是 unit eval 的写法,behavior eval 必须多维,accuracy、tone、citation、format、safety 各打分,这样改 bug 时知道哪一维在退步,而不是只知道总分掉了。

2. Code review · 7 维度 + 4 种动作

判断力的第二个具体表达,是看一段代码、一个方案,能问出关键问题加看出常见 smell。这是 code review 解决的事。

2.1 7 个判断维度 · 看代码该问什么

回到开篇那个 5 行 search 工具的例子。production engineer 10 秒内能问 6 个问题,不是因为他更聪明,是因为他脑子里有固定的 7 维度 checklist,看任何代码都 systematically 跑一遍这 7 个问题。下面这张表把这 7 个维度按 foundations 前 5 章组织起来,看一段 production code 时心里依次过一遍,任何缺失都是 review comment 的种子。

这 7 维度不是按重要性排,是按看代码时该问问题的顺序。第一维(失败处理)总是 first concern,因为它直接影响用户体感,网络断了用户看到一个 stack trace 比看到 graceful 的错误信息糟糕得多。后面 6 维按因果依赖排:状态决定 retry 逻辑,eval 决定能不能验证,observability 决定能不能 debug,trade-off 决定选型对错,抽象决定可维护性。顺序记住了,review 时不用想下一步该问什么。

2.2 Code review 的 4 种"动作"

读完代码,你想说点什么。production review 通常有 4 种 comment 类型,各有不同的语气和目的,选对类型比挑出更多问题更重要。第一类是 Question(疑问),例如"这里我没看懂。max_iter=50 是怎么定的?"。这是最安全加最高产的 review action,不挑刺、问问题、逼设计者讲清,常常逼出"哦其实没好理由,就随手写了"的答案,这就是 review value。Junior 工程师应该 80% 时间用 Question 类。

第二类是 Suggestion(建议),例如"你考虑过用 enum 而不是 string literal 吗?"。中等 weight,给替代方案,被采纳与否在原作者手里,Suggestion 不是 demand,你给建议作者有权拒绝。第三类是 Praise(称赞),例如"这段 error fallback 写得很好,降级到 Haiku 这个 fallback 我以前没想过"。Praise 经常被忽略但极重要,review 不只是挑刺,看到好的明确说出来让团队知道好作品是什么样,Junior 工程师常忽略 Praise 以为 review 就是找 bug,这是错的,Praise 是团队 culture 的载体,它定义"好"是什么。第四类是 Blocking concern(阻塞),例如"这段把 API key log 出来了。这是 security incident,必须改"。这是最重的 weight,不改不能 merge,要慎用,真有 blocking concern 时才用。Junior 工程师不应该轻易用 Blocking,senior 工程师才有判断权,如果你用错把 nitpick 当 Blocking,团队效率掉一截。

review 礼仪有几条值得 internalize。对事不对人,例如"这里的 retry 没考虑 idempotency",而不是"你写的 retry 错了"。Specific 不要 vague,例如"这段重复了上面 line 23",而不是"这里有些重复"。挑战 default,例如"这个数字为什么是 50?有 eval 数据支持吗?",逼对方思考而不是默认接受。Praise 加 suggestion 是黄金组合,例如"整体方案很清楚,3-4 行加 type hint 会让 caller 更容易用",先肯定再建议比单纯挑刺好接受得多。

2.3 真实 PR review 演练 · 6 reviewer 不同 angle

回到开篇 search 工具的例子,让我们看 6 个 reviewer 的不同角度,每个对应本章某个维度。这是 production review 的真实形态,不是一个 reviewer 找所有问题,是团队多视角合力。

Reviewer A 看失败处理(维度 1):

这段失败处理没有。requests.get 超时会 hang;HTTP 500 会 JSON parse 失败抛 KeyError。production 不能这么写 —— 至少加 timeout + try/except 捕几个常见错。

Reviewer B 看状态加 security(维度 2 加 7):

q 直接拼到 URL 里 —— 如果 q 含 &special 等字符,这是 URL injection 风险。要 urllib.parse.quote。另外 API key 没有出现在代码里,是在配置里吗?能告诉我们 secret 怎么管理的吗?

Reviewer C 看 eval 加 tool quality(维度 3):

Top 10 怎么定的?如果搜出来 0 个 / 100 个怎么办?这层 tool 有 eval 吗 —— 给固定 query 看返回质量?如果没有,新人接手这个 tool 改它时怎么知道没退化?

Reviewer D 看 observability(维度 4):

这个 tool 调用没 log。Agent debug 时不知道搜了什么、得到什么、耗时多久。production 跑起来后用户报"agent 答错了" 你找不到现场 —— 因为没记录。

Reviewer E 看抽象(维度 6 加 7):

这个 tool 函数太薄了 —— 没类型,没 docstring。建议:

• 加 q: str -> list[SearchResult] 类型
• 加 docstring 说明它 query 哪家 search engine、何时该用、limits 是什么
• 抽 search provider(以后切到 Brave / Google 不用改这里)

Reviewer F 给 Praise(维度 8 综合):

整体方向是对的 —— search 作为 tool 是 standard 模式。上面 5 点都是 polish,核心 design OK。

这 6 个 reviewer 的 comment 覆盖了 review 的不同 angle。读完它们你设计 search tool 时立刻有 6 个以上的 specific concerns 要 address,这就是 review 文化的价值。Code review 不是找茬,是团队的 distributed cognition,集体智慧补足单人盲点。一个人无论多强,7 维度都跑遍也总会漏一两条;一个团队 6 个人,每人主看一两维,合起来覆盖度远远高于任何单兵。

3. Code taste · 10 个常见 smell

Code taste 是 review 之外的更高层能力。不需要刻意检查 7 个维度,看一眼就觉得对劲或不对劲。这层能力靠长期看好作品加写真实代码内化,不能速成,但 taste 的种子可以建立。下面是 10 个常见 code smell,每个都是 production review 看一眼就该 spot 的,先把名字和形状记住,再在真实代码里反复识别,你就开始养成 taste 了。

第一,Long function(超过 50 行)通常意味着职责混乱该拆。一个函数干一件事;干很多事等于单元测试难写加阅读难,review 时遇到 long function 第一反应应该是"这里其实是几件事在一起"。第二,Long parameter list(超过 5 个参数)通常该用 dataclass 或 config object 包起来。process(a, b, c, d, e, f, g) 调用方根本看不清每个参数是干嘛的,改成 process(config: ProcessConfig) 调用方读起来轻松,代码本身也强迫你想清楚这堆参数的内在结构。第三,Boolean parameters(process(data, True, False, True))调用方看不出每个 bool 是干嘛,通常该用 enum。process(data, mode=Mode.STRICT, debug=False, retry=True) 读起来清楚,而且 enum 给你 type system 帮你检查,bool 给不了。

第四,Magic numbers(if score > 0.7: ...)0.7 哪来的?要不要常量化加 comment。Magic number 是 production bug 的高频源,6 个月后改这个数,新人不知道为什么是 0.7,改成 0.8 业务行为变了不知道。一个简单规则:任何 hardcode 的非平凡数字都应该是常量或配置,并且有 comment 说明它的出处和影响。第五,Nested if-else 5 层以上 该用 early return、guard clause 或 state machine 拆开。深嵌套等于圈复杂度爆炸等于 test 覆盖几乎不可能,看到 5 层缩进的 if 你应该立刻想到这段必然有更清晰的写法。第六,Copy-pasted error handling 该抽 helper。同一段 try/except 加 log 加 retry 出现 8 次等于维护噩梦,改 retry 策略要在 8 个地方同步改,漏一处就是 production bug。

第七,Comments explaining what code does(# loop through users)通常意味着 code 不够 self-documenting,改名而不是加 comment。for user in active_users: 比 for u in users: # loop through users 好 10 倍,前者用变量名表达意图,后者把意图丢给 comment 而 comment 总是会跟代码 drift。第八,# TODO 没 owner 没 deadline 永远不会被做,纯垃圾。Production code 里所有 TODO 应该有 owner 加 deadline,否则就该删或转 issue,无主 TODO 在代码里堆几个月,后来人读到不知道是该跟进还是可以删,产生 ambient anxiety 但没人解决。第九,Print debug statements 留在代码里,看到这种 PR 别 merge,作者还在 debug 中。Production 用 structured logging(Ch 6 学的),不是 print,print 没有 level、没有 timestamp、没有 context,完全是开发期产物。第十,没 type annotation 的 production code 立刻给 reviewer 增加 30% 阅读负担(Ch 5 学的)。Production code 必须 typed,这是 entry-level baseline 之一,新人代码里看到无 type 函数,reviewer 第一反应就该是要求加上。

读够 100 段优秀代码加自己写 5 个 production project,这 10 个 smell 你看一眼就有反应,taste 的种子就长出来了。Taste 不是天赋,是大量优秀样本在视觉系统里建立的 pattern matcher,你看够多好的,自然能 spot 坏的。foundations 给你 10 个 smell 的清单,真正长成 taste 是你自己的事,谁也代替不了。

跨实验室 verbatim 信号(回到 Stage 1 开篇就提过的 4 lab JD):

这 4 条 verbatim 跨 entry 加 senior、跨美中全部 explicit。学完 foundations 想进前沿团队,taste 的种子必须有,没有这个种子简历过不了第一关。进 foundations 之后的 7 个路书会反复回到 taste 这个主题,尤其 #8 Agent 工程的 case study 章节(Claude Code 源码阅读、OpenAI Codex 设计分析、DeepSeek Agent harness 解构),那里你会看够多优秀作品。看够多优秀作品是 taste 真正成长的关键,没有任何捷径。

4. Trade-off lens 大表 · 把前 5 章合成判断框架

到这里我们已经学了 eval(怎么告诉系统好不好)、review(怎么 spot 代码问题)、taste(怎么一眼觉得对劲不对劲)。最后一个判断力维度是看一个方案能跑一遍 trade-off lens。下面这张大表汇总你在 production LLM 系统里最常见的决策,每行对应前面某一章学过的 trade-off,看一个 production 方案时在脑子里跑这张表,你立刻有判断方向。

这张表是这一章里少数 结构化为主 的内容(per teaching-tokens.md 1.10,structured 合法位置之一:跨章节 trade-off lens 或 decision table,给已学会的人 review 用)。下面的表是帮你 review 已掌握内容的工具,不是第一次接触概念的载体,如果某行你看着陌生,说明对应章节没消化好,回去补,不是在这张表上现学。

4.1 Stage 2 来的 trade-offs

4.2 Stage 3 来的 trade-offs

4.3 Stage 4 来的 trade-offs(本章引入)

4.4 把 trade-off lens 用起来

读这张表你可以针对任何 production 方案做 3 步判断。第一步,这个方案在哪几个轴上做了选择(扫表识别)?第二步,每个选择的理由是什么(问设计者)?第三步,如果其中 1 到 2 个选错,后果有多严重?这套问题流程化跑下来你就有了 production architecture review 的 base capability。这不是看一两个项目就有的能力,但有了这个 framework 加一年的 production 实践,你能从 vibe coder 长成能 review architecture 的 production engineer。

5. 跨工具 vibe coding 流利度 · meta-skill

最后一个判断力维度是跨工具能力。这不是技术 trade-off,是把 AI 工具用起来加速自己日常工作的 meta-skill。DeepSeek S7 verbatim 列了 8 个产品:

Claude Code · Cowork · Codex · Cursor · OpenCode · GitHub Copilot · Manus · OpenClaw · Hermes

学完 foundations 你应能跨工具 collaborate,看一个新工具能 5 分钟上手,跨工具切换无障碍。这层 meta-skill 决定了你 6 个月后能不能跟上 AI native team 的工作节奏,因为团队 default 假设你能在不同 tool 之间无缝迁移,不会因为换了 IDE 就卡半天。

5.1 Self-check · 你的跨工具流利度

5.2 各工具的差异化定位

读这表的目的:学完 foundations 后主动用 2 个以上你不熟的工具,各跑 5 到 10 小时真实项目。这是把 meta-skill 落地的最直接方法,没有跑过真实项目的工具不算用过,只是看过几个 demo。

5.3 "用 LLM 工具加速日常工作"的真实工作流

一个 production engineer 一天的"AI 加速"工作流(示例):

早晨:
  - Claude Code: "看一下昨天我的 commits,有什么没考虑到的吗"
  - 它列 3 个 concerns,我决定哪个 follow up
  - "把第 2 个 concern 修了",它 implement

中午:
  - 新 feature: vibe code 实现 prototype
  - 跑通后让 Cursor: "refactor 这段到 production quality(按 Ch 5 7 维度)"
  - 跑 pytest + ruff + mypy
  - Claude Code: "写 PR description,列 trade-off 和 alternatives"

下午:
  - Review 同事 PR: 让 Claude "scan this diff for 我学的 7 个维度问题"
  - 它列 5 个 concerns,我筛 2-3 个真问题写到 review

晚上:
  - 读一篇 Anthropic blog
  - Claude: "用 5 行总结这篇,关键洞察是什么"
  - 把关键洞察存进我自己的 notes 库

这套工作流的关键不是我用了多少 AI 工具,是 AI 工具放大了我已有的判断力。我审 Claude 写的代码,采纳好的拒绝坏的;我看 Cursor 提的建议,识别哪个是 over-engineered。前提是你有判断力。foundations 6 章给你的就是这个判断力的种子。没有判断力 AI 工具是放大噪音的扬声器;有判断力 AI 工具是放大能力的杠杆。两者的差别不在工具本身,而在使用者脑子里有没有那套判断框架,这就是为什么 foundations 把判断力 capstone 放在最后一章,而不是把工具 demo 放在最后。

6. 向未来外推 · 把判断力指向下一堵墙

到这里,foundations 教给你的判断力还差最后一块拼图。前面五节让你能评估一个系统(eval)、看穿一段代码(review)、一眼分辨好坏(taste)、跑一遍 trade-off(lens)、跨工具加速自己(meta-skill),这些都是面向当下的判断力。最后这一节把判断力指向未来:当一个你从没见过的新模型、新产品、新论文出现时,你怎么不慌、怎么快速判断它到底意味着什么。这不是要你预测未来,预测会立刻过期而且常常错;是要你掌握一套外推的方法,这套方法比任何具体预测都耐用。

方法你其实在 Ch 1 就见过。回到那条认知弧的核心节奏:这个领域每一次真正的进步,都遵循同一个 pattern——先撞到一堵墙,理解这堵墙的本质,再找到一条结构性的解法,而这条解法常常是一条和老路正交的新轴,不是把老路推得更远。RNN 不能并行那堵墙,被 Transformer 换成一条可并行的轴;模型能力够强但普通人用不上,被 ChatGPT 用 RLHF 加聊天界面换成可及性这条轴;知识锁死在权重里,被 RAG 和工具换成按需检索这条轴;预训练 scaling 放缓,被推理时算力换成一条全新的轴。同一个节奏,十年里重复了四次。

现在把这个 pattern 跟你刚学完的六章连起来,你会发现一件事:foundations 教的几乎每一个核心概念,都是某一堵墙的解法。你在 Ch 3 学的 RAG,是训练 cutoff 加幻觉那堵墙的产物;你在 Ch 4 学的 Agent 工程词汇,是 2023 玩具 agent 跑几步就飞那堵墙、被工具化和推理能力补上之后才长出来的;你在本章学的 evals,是可靠性和评测那两堵墙逼出来的入场券,没有好的 sensor 就没法系统改进。换句话说,你这一路学的不是一堆孤立的技术名词,是这个领域十年里撞过的墙和找到的轴的合集。这就是 Ch 1 那条时间脊柱一直在为你铺的底:让你学每个概念时,都知道它是哪次撞墙的答案。

学会了往回看,往前看就有了方法。站在 2026,前面还立着几堵清楚可见的墙,我在 Ch 1 第 3 节 列过,这里用你现在学到的判断力再过一遍。可靠性的墙:agent 在长任务上仍会跑飞,几十步后累积误差,这限制了它从助手变成可托付的同事。成本的墙:推理模型想得越久越贵,大规模部署的经济性还是真问题,你在 Ch 6 学的 token 监控就是在产品侧守这堵墙。评测的墙:我们其实还不太会衡量一个 agent 到底好不好,这正是 evals 成为入场 baseline 的原因。记忆与上下文的墙:agent 跨长时间、多任务保持连贯仍然很难,这是 context engineering 作为独立子学科存在的理由。对齐的墙:能力越强,确保它按人的意图行事越难。

你现在不需要解这些墙,foundations 也没教你怎么解,那是 #2 到 #8 各路书以及前沿研究本身的事。你需要的是养成一个习惯:遇到任何 AI 新闻、新产品、新论文,先别问它有多厉害,先问它在攻哪堵墙、用的是老轴还是新轴。一个只是把老轴推得更远的进展(更大的预训练、更多的参数),和一个开了新轴的进展(像 o1 那样换一种算力),意义完全不同,后者才真正改变方向。这个判断习惯,就是这条路书 mission 里"为前沿研究做准备"的种子。前沿研究的本质,说到底就是站在这条轨迹的最前端,辨认出下一堵还没被人清楚说出的墙,想象出下一条还没人走过的轴。foundations 给你的判断力,是你走到那个最前端的第一步。

写给完成 foundations 的你

恭喜读到这里。你最初进 foundations 的样子,是一个有 vibe coding 经验但缺系统知识的人,能用 LLM 工具但对"为什么"心里发虚。6 章读完(假设你真读了加真做了 self-check 加真在自己代码里试了),你不再是 prompt 玩家,是有 baseline judgment 的 LLM 系统 builder。这条线还很长,foundations 只是地基,Stage 2 到 4 学的 vocabulary、engineering、judgment 都是种子,在真实项目里长成大树需要时间和实践。

回头看你这 6 章走过的路径。Ch 2 你建立了 LLM 心智模型,LLM 是一个把文字映射到文字的概率函数,没有记忆、没有意图、有不确定性,这是后续 5 章一切讨论的锚。Ch 3 你拿到了 LLM API surface,Token 加 Context 经济学、三种 API 模式、production prompt 加 spec、Function calling 加 Tool use 加 MCP、Embedding 加 RAG。Ch 4 你拿到了 Agent vocabulary,13 个核心概念加 3 个子学科定位,你能读懂 Anthropic 和 OpenAI Agents SDK README 不陌生。Ch 5 你拿到了 production engineering 基底,7 个 quality 维度、Sync/Async/Stateless/Stateful、DB/Cache/Queue 三件套、HTTP status/Retry/Idempotency、Latency/Throughput/Cost trade-off lens。Ch 6 你拿到了部署加监控加 OS 视角,Cloud、Docker、CI/CD、Web stack、OS/网络/GPU minimum、Observability 三件套、LLM-specific 5 类信号。Ch 7 也就是本章,你拿到了系统判断力,4 层 eval、7 维度 code review、10 个 smell、trade-off lens 大表、跨工具 meta-skill。这是 foundations 的全部交付。

有教无类的边界提醒

回到 foundations 的核心使命:有教无类。路书侧把渐进式做到了最好,6 章加 200 多词的 glossary 加必看视频是大约 12 到 14 小时的诚实劳动;学生侧是真实努力,capacity 在你这边,实践和内化是你的事。如果你认真走完这 6 章你已经做对了你这一侧应该做的,剩下的是把 baseline 用起来,找真实项目、参与 code review、跟同事讨论 trade-off、不停看更多优秀作品。3 个月后你回头看 foundations,最有价值的不是某个具体概念,是"读完后我有底气讨论 LLM 系统"这层 confidence。

学完 foundations 后去哪

诚实标注你能做什么加不能做什么:

职位组合,你想做什么决定下一步学什么:

(2026-05-26 现状:你正在读 #1 的 v2。#2 到 #8 尚未发布,目前 foundations 把基础打牢,等后续路书逐步上线。)

反 pattern · 学完 foundations 不要做的事

学完后有几个常见的反 pattern,避开它们比再多学一个概念更值钱。不要假装 foundations 加一个 framework tutorial 等于高手,foundations 给你 baseline,各专业方向还需要至少 30 到 50 小时深入,任何路书上来就声称自己已经精通就是 Dunning-Kruger 的典型。不要读完不实践,foundations 的概念全是 application-driven,不在真实项目里用 3 个月忘 70%,学完每章建议在自己项目里用一次那些概念。

不要等 foundations 全英文版上线再开始 #2,中英版进度独立,中文版 6 章加 glossary 全套已经够你进下一步,等英文版会浪费几个月。不要自学不交流,production engineering 是 social skill,foundations 学完后找一个 team 或 OSS project 参与 code review,judgment 才能真正长出来,关起门来看书永远长不成 production engineer 的判断力。

反馈

Foundations 路书是 Akashic Learning 的 #1 horizontal roadmap,也是后续 7 路书的参考模板。如果你发现某章内容不清晰、某概念在错误的章节、某 trade-off 没说到或说反了、glossary 缺重要词条,直接在 GitHub repo issues 留言。学生侧的反馈是路书侧持续改进的唯一信号,没有反馈我们假设一切都好,实际可能有很多隐藏问题等着被指出。

本章术语速查

Evals:Eval 评估系统表现的标准化方法 · Unit Eval 测单个组件 · Behavior Eval 用 golden set 测整体 · A/B Test 真实用户分组 · Human Eval 人工 review · Golden Set 人工确认的测试集 · Judge Model 评分用的 LLM · Regression Test 防破坏已有功能 · Feature Flag 分组开关基础设施

Code review / taste:Code Review 同事互相 review · Smell 不对劲的信号 · Taste 区分好坏的判断力 · Judgment trade-off 时知道该选什么 · Question / Suggestion / Praise / Blocking concern 4 类 review comment · YAGNI / KISS / DRY 设计原则 · Magic number 没解释的常量 · Early return / Guard clause 避免深嵌套 · Self-documenting code 命名好到不需 comment

Meta-skill:Trade-off lens 三轴判断框架 · Cross-tool fluency 跨工具流利度 · Meta-skill 元能力,加速学习别的能力

完整词汇见 术语表 /glossary。

参考文献

Mode B · 必看视频

无。Stage 4 系统判断力主体靠跨章节合成加真实素材引,无单一合格视频 cover。

Mode B · 可选深 dive 视频(超出 baseline)

• John Ousterhout · A Philosophy of Software Design (Google Tech Talk) · ~1h17m · YouTube · 2018 Stanford 教授本人讲解他的《A Philosophy of Software Design》核心思想,抽象层次设计、complexity 管理、命名哲学。看完是 code taste 的 senior 视角加强。

Mode A · 引用出处

• OpenAI Applied Evals SWE · "judgment to create reusable systems that measure and improve our models" · evals team JD
• Anthropic Applied AI · "reusable evals" · 显式 baseline
• DeepMind PM Personalization · "experience with eval methods, A/B testing"
• DeepSeek · Agent Data Eval Expert + AGI research engineer 都列 eval pipeline 经验
• Anthropic Full-Stack RL JD · "the bottleneck isn't typing — it's judgment, taste" · code taste verbatim
• DeepSeek 核心系统 JD · "优秀的设计能力和代码品味" · code taste verbatim
• DeepSeek Agent Harness PM JD · 8 跨工具产品名 · 跨工具 vibe coding 流利度 baseline · 收录 teaching-system/research/foundations/synthesis.md
• industry-roadmap.md 9 节 · 职位组合 vs 路书组合 · 收录 teaching-system/frameworks/industry-roadmap.md

深 dive 资源(可选)

Evals 进阶:

• Hamel Husain · Your AI Product Needs Evals · 业界实战指南
• Eugene Yan · Patterns for Building LLM Systems & Products · 综合 review
• Anthropic · Evals docs · 官方 evals 指南
• Langfuse · LLM Evals 文档 · 工具向

Code review / taste:

• John Ousterhout · "A Philosophy of Software Design"(书 + Stanford lecture)· 软件设计哲学经典
• Robert Martin · "Clean Code"(争议较大,选读其中你认同的部分)
• Google Engineering Practices · "Code Review Developer Guide" · Google 内部 review 文化

Meta-skill / 跨工具:

• 跨工具实战:foundations 学完后,直接挑你不熟的工具跑一个 10 小时项目。任何工具的官方 doc 加一两个 demo 视频就够。
• Anthropic Cookbook · github.com/anthropics/anthropic-cookbook · 大量 Agent + Tool use pattern
• OpenAI Cookbook · cookbook.openai.com · 对照阅读

Foundations 路书完结

总学习时长:大约 12 到 14 小时(原创 prose 约 9 小时加必看视频约 3 到 3.5 小时),加 4 到 8 周内化(在真实项目里实践)。

下一步(等 #2 到 #8 路书逐步上线):

• 想做工程方向 → #2 系统设计 + #8 Agent 工程
• 想做研究方向 → #4 模型设计 + #6 后训练
• 想做 PM/Designer → #8 Agent 工程 + #3 数据工程(轻)

恭喜结业。