# 第 19 章 剥夺执行权：强制 AI 像资深工程师一样"慢思考"

## 本章目标

- **O1** 能够定义“只读分析”进入“实施授权”所需的判断条件（产物：执行权门禁单）
  - 证据: 执行权门禁单写明从“只读分析”到“实施授权”的进入条件
- **O2** 能够构造执行权门禁单，写明分支、否决项和责任人（产物：执行权门禁单）
  - 证据: 执行权门禁单至少包含一个继续分支、一个停止分支和各自责任人
- **O3** 能够区分只读分析与获准实施并在行动前检查授权（产物：执行权门禁单）
  - 证据: 产物记录一个请求的当前权限、允许动作、禁止动作和升级对象

## 学习路径

- **初学者**: 本章迁移任务是：能够区分只读分析与获准实施并在行动前检查授权。先按图中的“条件门禁”关系完成执行权门禁单的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够区分只读分析与获准实施并在行动前检查授权。提交执行权门禁单后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 执行权门禁单
- **图解类型**: plan-before-action
- **关系语义**: 输入经过条件分支汇入明确门禁；停止与继续是互斥结果，红线不能被其他得分补偿。
- **核心概念**: 只读分析 · 实施授权 · 验收再行动

![第 19 章执行权门禁单教学图](/learning/diagrams/zh/chapter-19.svg)

沿条件分支阅读执行权门禁单，在门禁处作出可追溯的停止或继续决定。

图以“只读分析”为输入，经“实施授权”的条件分支到达“验收再行动”所控制的门禁。两条路径最终必须落在停止或继续之一；缺证据和红线失败不能被其他表现抵消。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 19.1 先降低不确定性，再实施

我们天生对速度有着无法抗拒的迷恋。当 AI 能在三秒内为一个复杂问题瞬间生成三百行代码时，那种"即时满足感"是极其强烈的——一种类似多巴胺驱动的奖赏反应，我们会惊叹于它的神速，我们会觉得自己拥有了全世界最强大的生产力工具。

这种对速度的沉迷，正是 AI 编程中最危险、也最具欺骗性的陷阱。

一个初级工程师，拿到需求后的第一反应是"马上动手写代码"。而一个资深的工程师或架构师，拿到同一个需求后，他的第一反应是"等一下，让我先想一想"。他会花上数小时甚至数天，去调研、画图、比较方案、评估风险。他知道，在键盘上敲下第一个字符之前，战争的胜负多半已经在他脑中的沙盘推演里决定了。

AI 不是承担责任的工程师，也天然没有业务或生产决策权。根据指令和工具配置，它可能在关键需求尚未解决时就给出代码。流程约束的作用，是把分析、决定和获授权执行分开：先补证据，再行动，而不是给模型套上人类职级标签。

让我们先解剖"直接写代码"这种做法，到底错在哪里：

错误一：你得到的是未经澄清的候选方案，而非已验证的问题解决。

当你不加引导地直接抛出一个问题（如"如何实现一个支持插件化的系统？"），模型只能依据给定上下文生成候选答案，不能自行访问你尚未提供的业务含义。它可能复用常见代码形态、教程或设计模式，但具体生成机制和所选方案不能从输出表面反推出。

这个过程可能缺少问题澄清与需求分析。你所谓的"插件"是动态加载的 DLL/SO，还是几个可配置的 JavaScript 对象？安全要求多高？插件如何通信？若这些问题没有在提示、工具流程或人工对话中得到回答，候选方案就没有足够证据说明适合当前业务。

错误二：过早陷入"实现细节"的泥潭。

一旦 AI 生成了第一版代码，你的注意力就会立刻被代码本身所吸引——这个变量名起得好不好？这个循环能不能优化？这种对"实现细节"的过早关注是架构设计的大忌：在你还没想清楚整个系统的"骨架"应该是什么样子的时候，你就已经开始纠结于某一块"砖头"的花纹了。

这在心理学上与"锚定效应"（Anchoring Effect）相关：AI 给出的第一版代码，无论好坏，都会成为你后续思考的"锚点"。你会不自觉地在"锚"的基础上修修补补（即确认偏误），而很难跳出来思考是否存在一个完全不同但更好的顶层设计。直接写代码，相当于 AI 主动为你抛下了一个"思想之锚"，将你和它一起困在了某一条狭隘的实现路径上。

错误三：放弃了你作为"决策者"的最高权力。

我们在第二部分确立了：人类在 AI 协作中的核心角色是"决策者"。而决策的价值，体现在对不同方案的权衡与取舍上。软件工程中几乎不存在"唯一的正确答案"——方案 A 性能最好但开发成本最高，方案 B 开发最快但有安全隐患，方案 C 是平衡。选择哪一个，是一个结合了项目周期、团队能力、业务风险、未来规划的商业决策。

当你直接让 AI 写代码时，你实际上把这个至关重要的"决策权"不负责任地让渡给了 AI。而 AI 作为一个没有商业意识、不懂你公司战略的概率模型，只会选择训练数据中最"平庸"、最"常见"的方案。这是一种极其危险的权力真空：你放弃了自己最有价值的工作，却让一个最不适合做决策的"实习生"替你决定了整个项目的命运。

结论："快"，是 AI 编程中最廉价的副产品，也是最昂贵的诱惑。我们的第一原则是：

> 对高风险、陌生领域或需要新架构的任务，在问题没有被充分理解、方案没有被充分评估、决策没有被明确做出之前，严禁 AI 生成任何一行实质性的业务代码。

在高风险、未知或需要新架构的任务里，我们要剥夺它的"执行权"，直到我们——作为总指挥官——对整个战役的地图、目标和行军路线都了然于胸。

### 19.2 "三步走"标准流：调研 → 谋局 → 落地

为了强制 AI（以及我们自己）进行"慢思考"，我们设计了一套用于高风险任务的"三步走"标准工作流。对于中等复杂度以上、陌生领域或需要新架构的需求，都应先按下表判定；一旦风险或未知因素不能被既有门禁覆盖，就必须严格遵循这个流程。

这个流程本质上是对一个资深工程师大脑中隐性的"问题解决模型"的显性化和流程化。

<!-- code-example:chapter-19-E1 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
第一步：调研（Research）    我们面对的是什么？
    ↓
第二步：谋局（Strategizing） 我们该怎么走？
    ↓
第三步：落地（Implementation）开始动手吧！
```

第一步：调研（Research）——我们面对的是什么？

目标：收集信息、澄清需求、识别约束。禁止讨论任何具体的实现方案。我们要像一个侦探一样勘察案发现场，而不是过早断定凶手是谁。

核心活动：
- 需求分解：将一个模糊的"大需求"拆解成一系列更小的、更具体的功能点；
- 边界定义：明确这个需求的"成功标准"是什么？范围边界在哪里？哪些是"必须做的"（Must-have），哪些是"可以做的"（Nice-to-have）？
- 技术预研：是否存在相关的第三方库或现有技术可以利用？各自的优缺点是什么？是否存在已知的"坑"或最佳实践？
- 风险识别：实现这个需求可能会对现有系统的哪些部分产生影响？存在哪些已知的技术风险、性能风险或安全风险？

产出物：一份简短的、结构化的"需求分析与风险评估"文档。

AI 的角色：在这个阶段，AI 不是"程序员"，而是你的"超级研究助理"——它极其擅长快速检索信息、总结文档、对比技术。

第二步：谋局（Strategizing）——我们该怎么走？

目标：基于第一阶段收集的信息，开始设计和比较多种可能的解决方案。注意，是"多种"，而不是"一种"。我们的目标是产出选项，并进行权衡。

核心活动：
- 方案设计：针对核心的技术挑战，提出至少两种（最好是三种）不同的架构或设计方案；
- 方案对比：从多个维度（开发成本、性能、可维护性、安全性、扩展性）对这些方案进行客观比较；
- 决策制定：基于方案对比的结果，由人类做出最终的、明确的技术选型和架构决策；
- 任务拆解：将选定的最终方案进一步拆解成一个清晰的、可执行的、有先后顺序的"开发任务清单"。

产出物：一份包含"方案对比表"和最终"技术方案与任务清单"的文档。

AI 的角色：在这个阶段，AI 是你的"架构设计顾问"。它擅长根据约束生成不同风格的方案并填充对比表格的细节。但最终的决策，必须由你来做。

第三步：落地（Implementation）——开始动手吧！

目标：只有在第二阶段的"技术方案"和"任务清单"被最终确认后，才进入这个阶段。此阶段的目标是高效、精确地将设计转化为代码。

核心活动：按照任务清单的顺序逐一完成编码；为新代码编写测试；对 AI 生成的代码进行人工审查；更新相关项目文档。

产出物：可工作的、经过测试的、符合规范的代码。

AI 的角色：在这个阶段，AI 才终于可以扮演它最被熟知的角色——"高速代码生成器"。因为所有的"思考"和"决策"工作都已在前面完成，此时的 AI 是在一个极其确定的、无歧义的"轨道"上行进，它的速度优势才能被安全、高效地发挥出来。

这个"三步走"流程就像一个强制性的"阀门"：思考优先于行动（没有想清楚"是什么"和"怎么走"之前，阀门是关闭的，任何代码都无法流出）；人类掌握决策权（在"谋局"阶段有明确的、需要人类介入的"决策点"）；执行阶段高效（所有需要"讨论"的问题都已在前面解决）。

### 19.3 适用边界：三步走 vs 全自动模式

"先调研、再谋局、后落地"并不与 Workflow/Job 的全自动模式矛盾。前者是面对风险与未知时的防御性流程，后者是已经把路径和约束固化后的授权；两者是风险分级，不是谁取代谁。先用下表选择模式，再在所选模式内执行。

| 判定条件 | 采用模式 | 为什么可以这样做 | 不满足或出现例外时 |
|----------|----------|------------------|--------------------|
| 高风险、陌生领域，或需要新架构 | 三步走：调研 → 谋局 → 落地 | 先澄清问题、比较方案，并由人作出业务与架构决策，避免把未知直接变成代码 | 停在调研或谋局，补齐信息、方案与人工决策；不得以自动化跳过这些步骤 |
| 蓝图成熟、技术路径已验证、风险低，且测试电网完备：第 25 章的覆盖率 CI 门禁、完整回归测试与关键验收均可运行 | Workflow/Job 全自动 | 自动化可在明确蓝图和可验证的护栏内高效完成重复性执行，并用门禁持续证明没有退化 | 任一门禁失败、回归不全、结果未知，或发现新风险时，立即降级为三步走；无法界定风险时停止并请人判断 |

全自动只获得执行已明确蓝图的权限，不获得业务决策权，也不获得生产环境的授权。无论采用哪种模式，业务取舍、生产发布与例外批准仍由人负责；测试失败、信息未知或门禁不能证明安全时，系统应降级或停止，而不是把"全自动"当作继续推进的理由。

### 19.4 每一步怎么问、问什么（附提问模板）

理论是灰色的，生命之树常青。让我们看一下在实战中，如何通过具体的提问来引导 AI 走完这"三步走"的每一步。以下模板经实践打磨，你可以根据需求调整，但其背后的"思维结构"是通用的。

阶段一：调研（Research）——像侦探一样盘问 AI。

目标：榨干 AI 作为"信息检索器"的价值，构建对问题的全面认知。核心句式："扮演一个 XX 角色""为我分析/拆解/列出""识别风险""不要提供任何解决方案"。

【模板 19.1：需求澄清与分解】

> 你的提问：
> Context: We have received a new feature request from our product manager. The original request is: "我想要一个'智能推荐'功能，根据用户的浏览历史，向他们推荐相关的文章。"
>
> Your Role: Act as a Senior Business Analyst. Your task is to break down this high-level, ambiguous requirement into a list of specific, answerable questions that we need to clarify before any technical work can begin.
>
> Task:
> 1. Deconstruct the Requirement: Break the core request into smaller, functional components.
> 2. Identify Ambiguities: For each component, list the key questions we need to ask the product manager to define the scope and success criteria. Examples: What defines "recent" history? What does "related" mean? How many recommendations to show?
> 3. Define Boundaries: List what is explicitly out of scope for this feature's first version.
>
> Constraint: Do not, under any circumstances, suggest any technical implementation or solution at this stage. Your entire focus is on clarifying the "What", not the "How".

【模板 19.2：技术选型预研】

> 你的提问：
> Context: For our "Article Recommendation" feature, we need to choose a method to calculate the "relatedness" between articles. Let's assume articles have tags.
>
> Your Role: Act as a Research Engineer. Your task is to conduct a preliminary investigation into common techniques for this problem.
>
> Task:
> 1. Identify Techniques: List at least three common algorithms or techniques for calculating similarity based on tags (e.g., Jaccard Similarity, TF-IDF with Cosine Similarity, etc.).
> 2. Summarize Pros and Cons: For each technique, provide a brief 2-3 sentence summary of its core idea, and list its main advantages and disadvantages. Focus on computational complexity, ease of implementation, and quality of results.
> 3. Find Libraries: For each technique, identify one popular and well-maintained library in [你的技术栈，比如：Python] that implements it.
>
> Constraint: Do not recommend a "best" option. Your goal is to provide an objective, neutral summary of the available options for my review.

阶段二：谋局（Strategizing）——像将军一样沙盘推演。

目标：让 AI 生成多个平行方案，并强制它进行"自我辩论"，最终由你来裁决。核心句式："设计方案 A/B/C""创建一个对比表格""根据以下标准进行评估""我决定选择方案 X，请为我制定执行计划"。

【模板 19.3：多方案设计与对比】

> 你的提问：
> Context: Based on our research, we have the necessary information to design the architecture for the "Article Recommendation" feature. Our core constraints are: the calculation must be fast (under 50ms), and it must run on our existing [Python/Flask] backend.
>
> Your Role: Act as a Solutions Architect. Your task is to propose and compare three distinct architectural approaches.
>
> Task:
> 1. Propose Three Solutions:
>    - Solution A (Simple & Fast): An approach based on pre-calculating and caching similarity scores. Describe how and when this pre-calculation would happen.
>    - Solution B (Real-time & Flexible): An approach that calculates similarity on-the-fly with every request. Describe how to optimize this.
>    - Solution C (Hybrid): A combination of the two, e.g., using a faster, simpler algorithm for real-time and a more complex one for offline batch processing.
> 2. Create a Comparison Table: Generate a markdown table that compares these three solutions across: Performance (Latency), Data Freshness, Implementation Complexity, Infrastructure Cost, Scalability.
> 3. Provide a Recommendation: After the table, briefly state which solution you would recommend and why, explicitly stating the trade-offs it makes.

【模板 19.4：决策确认与任务拆解】

> 你的提问：
> Context: I have reviewed the options. My Decision: We will proceed with Solution A (Pre-calculation). The trade-off of slightly less fresh data is acceptable for the gain in performance and simplicity.
>
> Your Role: Act as a Tech Lead. Your task is to take this architectural decision and break it down into a concrete, step-by-step implementation plan.
>
> Task:
> 1. Define Data Models: Specify any new database tables or data structures needed.
> 2. Outline Key Modules/Functions: List the main new functions or classes we will need to create. For each, give it a clear name and a one-sentence description of its responsibility.
> 3. Create a Sequential Task List: Generate a numbered list of development tasks in the logical order they should be completed. This should be a checklist an engineer can follow.
>
> Constraint: All tasks should be small enough to be completed in a single coding session.

阶段三：落地（Implementation）——像工匠一样精雕细琢。

目标：在完全确定的轨道上，最大化 AI 的代码生成效率。核心句式："根据我们的计划，执行任务 X""为这个函数编写代码""为这段代码编写测试"。

【模板 19.5：聚焦式编码指令】

> 你的提问：
> Context: We are now implementing the plan. Our current task is: "Backend: Implement the Jaccard similarity calculation logic."
>
> Your Role: Act as a Senior Pair Programmer.
> Task: Write the Python function calculate_jaccard_similarity(tags1: set, tags2: set) -> float.
>
> Constraints:
> - The function must be pure, with no side effects.
> - It must handle cases where one or both sets are empty (return 0.0).
> - Include a clear docstring explaining the formula.
>
> After you provide the function, immediately provide a second code block with three unit test cases for it using the unittest framework.

通过这套模板，你将原本一次性的、模糊的"给我代码"，变成了一场结构化的、由你主导的、层层递进的"深度工作坊"。你不再是 AI 的"用户"，而是它的"流程管理者"。

### 【流程图解】复杂需求的强制流转路径

为了让你对这个流程有更直观的理解，下面是流程全图，清晰展示信息和决策如何在三个阶段之间流转，以及人类决策者在其中的关键"门禁"作用。

<!-- code-example:chapter-19-E2 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
                          ┌──────────────────────────────────────────────┐
                          │             思考区（NO CODE ZONE）             │
 需求输入（模糊）          │                                              │
    │                     ▼                                              │
    ├───► 【阶段一：调研】──► AI 生成需求分析与技术预研                     │
    │         ▲                （模板 19.1 & 19.2）                        │
    │         │                    │                                      │
    │         └────── 人类审查：信息是否充分？──否（继续调研）/ 是（继续）    │
    │                                                    │               │
    │                                                    ▼               │
    │                              【阶段二：谋局】──► AI 生成多种方案对比    │
    │                                    ▲             （模板 19.3）        │
    │                                    │                │               │
    │                                    └── 人类决策：选择方案 A/B/C       │
    │                                                        │            │
    │                                                        ▼            │
    │                                        【模板 19.4】AI 生成最终方案    │
    │                                          与任务清单                    │
    │                                                        │            │
    │                                                        ▼            │
    │                                         人类最终确认：计划是否清晰？    │
    │                                          是 ── 批准执行！             │
    └───────────────────────────────────────┬──────────────────────────────┘
                                             ▼
                              ┌──────────────────────────────┐
                              │          执行区（CODING ZONE）  │
                              │                               │
                              │  【阶段三：落地】──► AI 生成代码   │
                              │   （模板 19.5，逐个任务）& 测试    │
                              │        │                       │
                              │        ▼                       │
                              │   人类审查 & 集成验证             │
                              │   否 ── 回到落地   │  是 ──► 完成 │
                              └──────────────────────────────┘
```

图解说明：

- 思考区 vs 执行区：当上文的适用边界将任务判为三步走时，整个流程被一道清晰的界线分为"思考区"和"执行区"。在思考区内，绝对不允许产出任何实质性的业务代码；在执行区内，AI 才被允许生成代码。人类在两个关键节点——方案选择（粉色菱形）和计划确认（粉色菱形）——行使"门禁"职责。这道界线，就是"剥夺执行权"的物理呈现。

### 【实操】用"三步走"处理一个典型需求

题目：请用"调研 → 谋局 → 落地"处理下面这个需求：产品经理说"我们希望给 App 增加一个'附近的人'功能，让用户可以看到附近的商家。"

引导：

1. 调研阶段：不要提任何方案！让 AI 扮演业务分析师，列出需要向产品经理澄清的问题（"附近"的定义？范围多大？是否需要实时定位？涉及哪些隐私合规？）
2. 谋局阶段：让 AI 扮演解决方案架构师，提出至少 3 种技术方案（如：基于地理坐标的精确计算 / 基于 GeoHash 的网格方案 / 基于第三方地图 SDK），并给出对比表。
3. 决策：由你（人类）选择方案——注意权衡开发成本、精度、扩展性。
4. 落地阶段：让 AI 扮演 Tech Lead，把决策拆成任务清单，然后逐个执行。

验收要点：学员是否在调研阶段保持了"不提方案"？是否让 AI 提出了多个方案而非一个？决策是否由人做出而非 AI？落地前是否有明确的任务清单？

---

<!-- cognitive-load-checkpoint -->
## 暂停整理：先完成本章最小闭环

先只写出“只读分析”与“实施授权”之间的一条关系，并把它填进执行权门禁单。确认这一步有输入、判断和证据后，再加入“验收再行动”；三项尚未连通时，不进入独立练习。

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-19.md`，写上版本、决定、证据和缺项。

为未知平台错误设计三阶段任务：只读收集、可评审计划、获授权实施。为每阶段写退出条件和禁止动作。

<!-- chapter-artifact-requirement -->
### 本章必交产物：执行权门禁单

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 执行权门禁单写明从“只读分析”到“实施授权”的进入条件
- O2: 执行权门禁单至少包含一个继续分支、一个停止分支和各自责任人
- O3: 产物记录一个请求的当前权限、允许动作、禁止动作和升级对象

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

研究交付复现和候选原因，不能编辑或泄露原始日志；计划写最小改动、检查和恢复；实施需范围已明确并有授权。阶段分离适合不确定或高风险任务，简单可逆改动不必仪式化；研究完毕也不自动获得生产权限。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；执行权门禁单、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Transformers 文本生成策略](https://huggingface.co/docs/transformers/generation_strategies) — Hugging Face, 2026-09-17. 贪心、采样和束搜索使用不同的下一 token 选择策略，解码选择会影响输出。
- [Git 官方参考](https://git-scm.com/docs) — Git project, 2026-09-17. 版本、分支、提交与恢复操作须按实际仓库状态验证。