本页目录

📘 第 5 课:Describing what users need(描述用户需求)

所属课程:AI Fluency for Builders(the AI Architect path 第 1 门) 官方课时定位:Section 3「The 4D framework for builders」— Lesson「Description & building great things」 课时长度:预计 45 分钟(视频 5 分钟 + 大练习) 针对认证:CCAR-P(架构师 Professional) 整理日期:2026-10-13 ⚠️ 语料来源:官方 Skilljar 课程正文(用户提供,非公开抓取)。CC BY-NC-SA 4.0,仅供个人学习。 ⭐ 本课权重提示:引入全课最核心的模型 —— Description Chain(描述链),是领域 2 的直接考点,也是解释"AI 项目为何失败"的主干框架。


🎯 本课学习目标(What you'll learn)

Estimated time: 45 minutes

学完本课后,你应当能够:

  • 使用描述链(Description Chain)把用户需求转化为精确的 AI 指令
  • 识别描述失败何时会级联扩散(cascades),并追溯到断掉的那一环
  • 通过测试表达意图,让 AI 确切知道"成功"长什么样

📖 一、课程导读:提示工程只是其中一环

官方原句: Most AI training teaches you to write better prompts. That's necessary but not sufficient for building great products. This lesson maps the full Description Chain: the path from a messy human need to a precise instruction AI can act on, with the builder as the translator at every step.

架构师级精译:

大多数 AI 培训教你写更好的提示词。这对构建出色的产品而言必要但不充分(necessary but not sufficient)。 本课将描绘完整的描述链:从一个混乱的人类需求,到一条 AI 可以据以行动的精确指令的路径 —— 而在每一步,构建者都是那个翻译者。

💡 三个关键词

概念 说明 考点价值
necessary but not sufficient 必要但不充分 ⭐ 官方明确贬低了"只学提示工程"的做法。题干问"提示工程在构建产品中的地位"→ 答必要但不充分
messy human need 混乱的人类需求 需求天生是模糊的(呼应 032 framing、第 4 课诊所场景)
the builder as the translator 构建者是翻译者 ⭐ 定义了构建者的角色,不是"提示词工程师"

记忆锚:提示工程是描述链的一环,不是全部。构建者是翻译者,不是提示词写手。


🔗 二、⭐ 描述链(The Description Chain)· 本课核心模型

官方 Key takeaway 原句: The Description Chain connects user voice → requirement → technical spec → AI instruction. Prompt engineering is only one link.**

四环结构图

环 英文 是什么 谁负责 典型产物
① user voice 用户的原话(混乱、模糊、带情绪) 用户说出,构建者采集 访谈记录、原话引述
② requirement 需求(可测量、有范围) 构建者翻译 产品需求(PRD 式段落)
③ technical spec 技术规格(结构、组件、接口) 构建者翻译 技术方案(半页)
④ AI instruction AI 指令(提示词、约束、测试) 构建者翻译 提示词 + 约束 + 测试
user voice  →  requirement  →  technical spec  →  AI instruction
(用户原话)     (需求)        (技术规格)        (AI 指令)
      ↑              ↑               ↑                  ↑
      └──────── 构建者是每一步的翻译者 ────────┘
                                    └─ 提示工程只是第 ④ 环

⭐ 最关键的一句:**Prompt engineering is only one link.** 提示工程只是其中一环。 这彻底定位了提示工程的位置 —— 它是最后一环,前面还有三环。大多数团队只在第 ④ 环上用力,而失败发生在 ①②③。

五条 Key takeaways 逐条拆解

1. 构建者是每一步的翻译者;AI 听不到用户没说的东西

The builder is the translator at every step. AI cannot hear what the user did not say.**

精译:构建者在每一步都是翻译者。AI 听不到用户没有说出口的东西。

⭐ **AI cannot hear what the user did not say** —— 这是本课最精炼的一句。 含义:AI 只能基于被显式传达的内容工作。用户没说的(言外之意、场景假设、情绪)不会自动出现在指令里,必须由构建者翻译补上。 呼应第 4 课 Empathy = AI weak, it can't feel the gap —— AI 既感受不到缺口,也听不到没说出口的话。两条同源。 考点:题干问"为什么 AI 输出看似符合需求却不解决用户问题"→ 根因是缺失的上下文没有被翻译进指令,而不是"AI 能力不足"。

2. ⭐ 代码能跑但产品不行 = 描述失败

Code that works but the product doesn't is a description failure. Find which link broke upstream.**

精译:代码能运行、但产品不行,这就是一次描述失败。去找出是上游哪一环断掉了。

概念 说明
Code that works but the product doesn't 代码能跑,产品不行 —— 这是描述失败的典型症状
description failure 描述失败(不是技术失败!)
Find which link broke 找出哪一环断了
upstream 上游(关键!)

⭐ 这是本课第二重要的论断,也是第 1 课"多数失败追溯到 description/discernment/diligence"的具体化。 核心洞察:问题表现在代码(第 ④ 环下游),根因在需求或规格(上游)。 考点: * 题干描述"功能正常实现但用户不满意"→ 答案选需求/描述环节的问题,不是"代码有 bug"或"模型能力不足"。 * upstream 这个词是解题钥匙 —— 往上游找,不要在第 ④ 环反复改提示词。 * 呼应考纲领域 4「诊断系统问题」:诊断要定位根因,不是修表象。

3. ⭐ 测试是最精确的描述形式

Tests are the most precise form of description. A passing test with an unhappy user means you described the wrong intent.

精译:测试是最精确的描述形式。一个测试通过但用户不满意,说明你描述的是错误的意图。

概念 说明
Tests are the most precise form of description ⭐ 测试 = 最精确的描述(把测试重新定义成"描述工具")
a passing test with an unhappy user 测试通过 + 用户不满 —— 矛盾信号
you described the wrong intent 你描述错了意图(不是"测试写错了")

⭐ 这是本课对我最有价值的一条: * 把测试从"验证手段"升格为"描述手段" —— 它与第 4 课的 acceptance tests / shared definition of done 完全咬合。 * "测试通过但用户不满"的诊断结论是"意图描述错了",而不是"测试不够严" —— 这是反直觉的,也是出题点。 * 考点:题干给"所有测试通过,用户仍然投诉"→ 正确答案指向意图/需求描述错误(第 ② 环),不是"再补充更多测试"。

4. 每一步都涉及前一阶段无法替你做的判断

Every step involves judgment calls the previous phase did not make for you.

精译:每一步都涉及前一阶段没有替你做出的判断取舍(judgment calls)。

含义:翻译不是机械转换 —— 每一环都有信息损失与需要人做的取舍。你不能指望用户原话自动变成需求、需求自动变成规格。 呼应第 1 课:Delegating judgment is usually not(判断不能委派)。 呼应第 4 课:Every adjective should be a decision you can defend(每个形容词都该是你能辩护的决定)—— 见下文练习 Step 1。


✍️ 三、实战项目:Clinic Wait Time Project, Part 2(诊所等待时间项目·第 2 部分)

You're picking up exactly where the last lesson left off. —— 严格承接第 4 课。 取出:问题简报(Problem Brief)+ 委派计划(Delegation Plan)+ 验收测试(Acceptance Tests)。

Step 1:写产品需求(Write the product requirement)

一段话。 把简报里的用户需求收束成可测量的东西。

⭐ 官方判定标准: Every adjective should be a decision you can defend. If you write "fast," write how fast. If you write "simple," describe what simple means for a patient checking from a phone in a parking lot.

精译:每一个形容词都应该是你能为之辩护的决定。 你写"快",就要写出多快;你写"简单",就要描述清楚 —— 对一个在停车场用手机查询的患者来说,"简单"意味着什么。

💡 这条标准可以直接当评分表用: | 模糊形容词 | 必须转化为 | |---|---| | fast(快) | 多快(秒数 / 毫秒数) | | simple(简单) | 对谁、在什么场景下简单(停车场 + 手机 + 抱着生病的孩子) | | reliable(可靠) | 可用性百分比 / 失败时的兜底行为 | | secure(安全) | 具体的控制项与合规要求 |

呼应:第 4 课交付物 3 的 Good/Bad 验收测试例;第 4 课 shared definition of done。

Step 2:写技术规格(Write the technical spec)

半页。 描述构建什么以及它如何组织。说出各个部件的名字。说出它们之间如何通信。

⭐ 官方指定的协作模式: Use AI in augmentation mode here: share your product requirement, ask it to propose a technical approach, then push back on anything that doesn't fit your constraints.

精译:此处以增强模式(augmentation)使用 AI:分享你的产品需求,请它提出技术方案,然后对任何不符合你约束的地方提出反驳(push back)。

💡 这是第 4 课三种协作模式的实战应用: * 明确指定 Augmentation(人机协同),不是 Automation(放手让 AI 做)。 * push back = 反驳、顶回去 —— 这是 Discernment 的动作:AI 提议,人质疑。 * 呼应考纲领域 1:架构方案必须符合约束(预算、技术栈、合规)。

Step 3:收紧你的测试(Tighten your tests)

回顾上一课的验收测试。重写它们,使每一条都是代码可以通过或失败的判定。

⭐ 至少添加两个边界情况(edge cases): * 诊所关门时会发生什么?(when the clinic is closed) * 没有数据时会发生什么?(when there's no data) * 等待时间为零时会发生什么?(when the wait time is zero)

💡 边界情况正是 Discernment 的用武之地 —— 正常路径容易想到,边界路径才是缺陷藏身处。 呼应考纲领域 4:design evaluation datasets(评估数据集要覆盖边界)。

Step 4:写 AI 提示词并构建(Write your AI prompts and build)

写出把规格变成可运行代码的指令。包含:你的约束、你的技术栈选择、以及你的测试。构建第一个版本。

💡 注意这一步要求把三类东西一起给 AI:约束(constraints)+ 技术栈(stack choices)+ 测试(tests)。 这三件套正是第 4 课交付物 1(约束)与交付物 3(测试)的延续,加上 Step 2 的架构决策。

Step 5:演示它(Demo it)

找一个搭档。 他们扮演诊所患者 —— 他们带着生病的孩子,只有十分钟。

⭐ 官方的严苛规则: Hand them your build and watch them use it. Don't explain anything. Don't help. Did the tests pass? Is the patient satisfied? If those answers don't match, which link in the chain would you go back to?**

精译:把你的构建交给他们,观察他们使用。不要解释任何东西。不要帮忙。 测试通过了吗?患者满意吗?如果这两个答案不一致,你会回到链条中的哪一环?

💡 这是本课设计的点睛之笔: * Don't explain anything. Don't help. —— 排除构建者的口头补救,暴露真实的描述质量。呼应 AI cannot hear what the user did not say 的镜像:用户也不会听你没做出的解释。 * "测试通过"与"患者满意"两个信号不一致 → 正是 Key takeaway 3 的 a passing test with an unhappy user 的现场版。 * 结论方向:回到上游(requirement 环,即意图描述错了),而不是改代码或加测试。


🤔 四、课后反思(Lesson reflection)

  1. 描述链中的哪一次"翻译"让你感觉最自然?你倾向于草率跳过哪一个?
  2. 在诊所演示中,你的意图与搭档的实际体验之间,最大的落差在哪里?

➡️ 五、下一课(What's next)

下一课我们从描述转向判断力(discernment)。你已经构建了东西,代码也能跑 —— 现在的问题是:它到底好不好。


📌 六、版权与致谢(Acknowledgments and license)

Copyright 2026 the AI provider. 本课程由 the AI 与 CodePath 联合开发,构建于 Prof. Rick Dakan(Ringling College of Art and Design)与 Prof. Joseph Feller(University College Cork)开发的 AI Fluency Framework 之上。采用 CC BY-NC-SA 4.0 许可。


🧠 本课 → CCAR-P 考点映射

本课知识点 命中考纲条目
描述链四环:user voice → requirement → spec → AI instruction 领域 2(提示工程只是最后一环)
提示工程 necessary but not sufficient 领域 2(定位提示工程)
AI cannot hear what the user did not say 领域 2 / 领域 5(上下文缺失导致失效)
代码能跑但产品不行 = 描述失败,往上��找 领域 4(诊断系统问题、定位根因)
测试是最精确的描述形式 领域 4(定义评估指标、设计评估数据集)
测试通过但用户不满 = 描述了错误意图 领域 4 / 领域 1(意图与需求)
每个形容词都是可辩护的决定 领域 1(把模糊问题转为有范围方案)
Augmentation 模式 + push back 领域 1(人机协同)
边界情况(关门 / 无数据 / 零等待) 领域 4(评估数据集覆盖边界)
每一步都是 judgment calls 领域 5(判断不委派)

🔤 本课新生词(待回灌生词本 02)

词汇 释义 备注
Description Chain 描述链 ⭐ 本课核心模型
user voice 用户原话 第 ① 环
requirement 需求 第 ② 环
technical spec 技术规格 第 ③ 环
AI instruction AI 指令 第 ④ 环
necessary but not sufficient 必要但不充分 ⭐ 官方对提示工程的定位
messy 混乱的 修饰 human need
translator 翻译者 ⭐ 构建者角色
cascade(v.) 级联扩散 描述失败会 cascade
upstream 上游 ⭐ 找根因的方向
downstream 下游 与 upstream 相对
judgment call 判断取舍 呼应 014 judgment
push back 反驳、顶回去 ⭐ Discernment 的动作
defend(a decision) (为决定)辩护 a decision you can defend
edge case 边界情况 领域 4
tighten 收紧 收紧测试
demo(v./n.) 演示 Step 5
the link that broke 断掉的那一环 诊断用语

✅ 本课进度

  • [x] 全文精译与架构师级拆解(2026-10-13)
  • [x] 建立描述链四环结构图
  • [ ] Step 1 产品需求(一段话,形容词可辩护)
  • [ ] Step 2 技术规格(半页,augmentation 模式 + push back)
  • [ ] Step 3 收紧测试(含三个边界情况)
  • [ ] Step 4 写 AI 提示词并构建 v1
  • [ ] Step 5 找人演示(不解释不帮忙)
  • [ ] 课后反思两问
  • [ ] 生词回灌 30-单词表/02-考试核心生词与术语表.md

输入至少 2 个字符,检索全部课程与单词表