EP01. "AI Fluency for Builders：给建造者的 4D 框架实战"

首页 › AI 工具 › Claude · AI Fluency Collections · EP01

约 18 分钟· #EP01#Claude#AI Fluency Collections

一句话就是这门课的核心立场：「Delegating implementation is usually safe. Delegating judgment is usually not.」——实现细节可以放心丢给 AI，但判断这件事不行
这是 Anthropic Academy「AI Fluency」系列面向 builder（产品人、工程师、独立开发者）的专属课程，9 节课 + 1 测验，约 3 小时，把通用课 AI Fluency: Framework & Foundations 里的 4D 框架（Delegation / Description / Discernment / Diligence）重新套进「做产品」这件事，不是简单复述 4 个定义
跟通用版最大的不同：通用课用抽象场景练 4D，这门课全程用同一个案例——诊所候诊时间查询工具（Clinic Wait Time Checker）——贯穿 9 节课，每节课都在同一个项目上叠加一层新技能，做完等于跑完一次「需求 → 设计 → 代码 → 上线」全流程
前置知识：适合已经有产品/工程背景、正在用 AI 辅助开发的人，不是零基础 AI 入门课

重点内容

课程主张：Builder 的责任不会因为用了 AI 而变小

课程开篇就定调：builder 对产品负的责任，是「从发现用户问题，到把方案交付出去」这一整条线，不是「把 prompt 写好」那一小段。课程反复强调一句话贯穿全程：大部分 AI 翻车，根源不是 AI 能力不够，而是前面 Description（描述不清楚）或 Discernment（没检查）环节先出了问题。

第一节课的实操不是写代码，是先写一份「Builder Brief」——一份以后每次开新 AI 对话都可以直接复用的背景文档，内容要覆盖：在做什么产品/给谁用、自己的角色和 ownership 范围、硬约束（团队规模、技术栈、时间线）、明确写出「这些领域我想用 AI」和「这些领域我刻意不用」。📌 这份 brief 不是一次性作业，后面 8 节课都会反复回来在它基础上叠加内容。

Inner Loop / Outer Loop：4D 不是一条直线，是两个循环

这门课对 4D 框架加了一层通用课没有的结构——把四个能力分成两个循环：

循环	包含	管的是什么
Inner loop（内圈）	Description + Discernment	日常每一次跟 AI 的来回对话——你怎么描述、AI 给了什么、你怎么评估
Outer loop（外圈）	Delegation + Diligence	更大尺度的决策——这件事该不该交给 AI、交出去之后谁最终负责

💡 卡住的时候先判断自己是在哪个循环里出问题——「AI 老是给不对的东西」多半是 inner loop（描述/评估）没做好；「不确定这块要不要用 AI」是 outer loop（该不该委托）的问题，两种问题解法不一样。

Delegation：先拆问题，再决定 AI 扮演什么角色

这门课把 Delegation 的落点从「该不该用 AI」改成一句更具体的问法：「我有一个客户问题，怎么拆解它，AI 在每一步该扮演什么角色？」——先分解问题，才轮到决定分工，不是反过来先纠结要不要用 AI。

三个原则：

靠拆解来委托：先把问题拆成步骤，再逐步决定每一步 AI 负责什么
先写验收标准，再动手：写代码前先定义「怎样算做完」，让你和 AI 对「完成」的理解一致
价值转移：AI 加速了实现部分，builder 的价值就集中到「怎么定义问题」和「把标准定得多高」上

同样延续 Automation / Augmentation / Agency 三种协作模式，但套进了 builder 的语境：

flowchart TD
    subgraph S1["🤖 Automation 自动化"]
        direction TB
        N1["AI 执行，你验收<br/>例：照规格写完一个函数，你 review"]
    end
    subgraph S2["🤝 Augmentation 增强"]
        direction TB
        N2["builder 跟 AI 一起打磨<br/>例：一起来回改一段技术方案"]
    end
    subgraph S3["🧭 Agency 代理"]
        direction TB
        N3["AI 在划好的边界内自主运作<br/>例：设好规则后让 AI agent 自己跑测试、修 lint"]
    end

实操：诊所候诊时间项目（Clinic Wait Time Checker），贯穿全课，写代码前先交三样东西：

Problem Brief（一页以内）：具体是哪些用户（不是笼统标签）、他们真正要的结果是什么、理想体验长什么样、真实约束（预算、技术能力、设备、隐私）
Delegation Plan：一张表，把项目拆出的能力逐条对应到 Automation/Augmentation/Agency 三种模式
Acceptance Tests（5-7 条）：具体到可验证。课程给了强弱对比范例——「拿着普通智能手机的病人，30 秒内不用注册就能查到当前候诊时间」是好标准，「这个系统很好用」不是

Description：Description Chain——翻译链条，不只是写 prompt

课程认为「prompt engineering」不够，真正决定成败的是一条完整的翻译链：

flowchart TD
    A["User voice<br/>用户原话，模糊、口语化"] --> B["Requirements<br/>可衡量的需求范围"]
    B --> C["Technical spec<br/>具体实现方案"]
    C --> D["AI instructions<br/>可执行的 AI 指令"]

📌 核心一句话：「The builder is the translator at every step. AI cannot hear what the user did not say.」——builder 是每一环的翻译官，用户没说出口的话 AI 听不到，得靠你补上。

诊断技巧：如果「代码能跑，但产品不对」，不要从代码开始查，倒回这条链条一环一环找是哪一环翻译错了。「测试全过但用户不满意」代表你描述对了错误的意图，不是测试本身的问题。写 spec 的关键是把「快」「简单」这类形容词全部换成可衡量、可辩护的具体说法（例如「快」对停车场里等待的病人到底是几秒）。

实操五步：写一段可衡量的产品需求（每个形容词都要定义）→ 半页技术规格（组件、交互、AI 在哪里帮忙）→ 把验收标准改写成代码可判断的形式（加边界情况：诊所关门、数据缺失、候诊时间为零）→ 把规格翻译成带约束/技术选型/测试用例的 AI 指令并开始搭建 → 找人 role-play 病人角色实测，不解释不协助，只观察。

Discernment：分两个透镜看——代码和用户体验

通用课的 Discernment 只讲 Product/Process/Performance 三层，这门课换成了 builder 更贴身的两套评估透镜：

Discernment for code（五个评估维度）：正确性（correctness）、代码质量（quality）、是否贴合项目（fit）、使用体验（experience）、责任归属（responsibility）。核心提醒：「Code that runs can still fail. 默认的 AI 输出在技术上是完整的，但常常没抓到重点。」AI 在并发、安全、可扩展性这几类问题上有可预测的盲区——这些问题往往只在生产环境才会暴露。📌「Taste is a builder skill. AI delivers functional. Making it worth using is on you.」

Discernment for user experience（四个检查点）：

检查点	在问什么
Clarity & Mental Model	界面用语和模式，用户（如诊所行政人员）熟不熟悉
Information Hierarchy	最重要的信息是不是排在最前面
Accessibility	色彩对比、屏幕阅读器、键盘导航达标了吗
Feedback & Error Handling	操作有没有确认、出错有没有引导

📌「AI does not get accessibility right by default.」——无障碍设计必须明确要求 + 事后审查，不会自动做对。另一个关键提醒：跟 AI 说「做得好看一点」没用，描述界面体验要跟描述一个函数一样精确；同事之间口头给的критique（评价）和能喂给 AI 执行的具体描述，是两种不同的东西，需要自己转译。

Diligence：You own the outcome, not the output

课程把 Diligence 浓缩成一句话：「You own the outcome, not the output.」——说「这是 AI 写的」不能替你解释任何东西，也不能免责。AI 不会主动提醒你迁移（migrations）、版本管理（versioning）、限流（rate limiting）、feature flags 这些上线必须考虑的东西，除非你明确问。测试是产品上线后的安全网，先写测试再改代码，才能有信心持续迭代。

上线前自查清单（用诊所候诊工具举例）：

Understanding：你能不能解释这段功能在「预期行为之外」还会怎么表现？
Testing：验收测试全过了吗？边界情况（诊所关门、数据缺失、候诊时间为零）覆盖了吗？
Access：这个产品会漏掉哪些用户？
Responsibility：输出有没有可能被误读？有没有透明说明 AI 参与的部分？
Feedback Loop：上线后怎么衡量它有没有成功？

💡 课程给的经验法则：可以随便做实验、快速做原型（prototype generously），但要谨慎决定什么进生产环境（deploy thoughtfully）——便宜快速做出来的代码，只有配上严格的评估才有价值。

学完你会

✅ 区分清楚「这件事该不该交给 AI」（outer loop）跟「这句话该怎么描述给 AI」（inner loop）是两类不同的判断
✅ 用 Description Chain 追查「代码能跑但产品不对」问题出在哪一环翻译
✅ 用五个透镜（正确性/质量/贴合度/体验/责任）审查 AI 写的代码，而不是「能跑就行」
✅ 上线前用 Diligence 自查清单过一遍，说得清「这是我负责的产品」而不是「这是 AI 写的」

常见错误

❌ 先纠结「这个功能该不该用 AI」，而不是先把问题拆解清楚——课程强调分工判断应该建立在问题已经拆开之后
❌ 验收标准写成「这个系统很好用」这种无法验证的话，而不是「30 秒内不用注册能查到候诊时间」这种可衡量的标准
❌ 跟 AI 说「做得好看一点/快一点」，没有把形容词换成具体数字或可判断的条件，AI 只能瞎猜
❌ 代码测试全过就直接上线，没有另外用 UX 的四个检查点（尤其是 accessibility）单独审查一遍
💡 出问题先别急着改代码——沿着 Description Chain（用户原话→需求→技术规格→AI 指令）倒着查，通常问题出在更早的翻译环节

Sources

官方文档：

AI Fluency for Builders（课程总览）— https://academy.claude.com/courses/ai-fluency-for-builders
Welcome to AI Fluency for builders — https://academy.claude.com/courses/ai-fluency-for-builders/ai-fluency-for-builders
The 4D Framework — https://academy.claude.com/courses/ai-fluency-for-builders/the-4d-framework
AI capabilities & limitations — https://academy.claude.com/courses/ai-fluency-for-builders/ai-capabilities-and-limitations
Delegation & the builder's toolkit — https://academy.claude.com/courses/ai-fluency-for-builders/delegation-the-builder-s-toolkit
Description & building great things — https://academy.claude.com/courses/ai-fluency-for-builders/description-building-great-things
Discernment for code — https://academy.claude.com/courses/ai-fluency-for-builders/discernment-for-code
Discernment for user experience — https://academy.claude.com/courses/ai-fluency-for-builders/discernment-for-user-experience
Stand behind what you build — https://academy.claude.com/courses/ai-fluency-for-builders/stand-behind-what-you-build
Closure & looking forward — https://academy.claude.com/courses/ai-fluency-for-builders/closure-looking-forward