范围管理并非微观管理
I’m happy to help translate the article, but I need the text you’d like translated. Could you please paste the content (excluding the source line you’ve already provided) here? Once I have the article text, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown, and any code blocks or URLs.
混乱
两者都涉及约束 AI,且看起来像是“给指令”,因此容易混淆。
但它们本质上是不同的。
| 微观管理 | 范围管理 |
|---|---|
| 控制 方式 | 定义 位置 |
| 规定实现方式 | 照亮盲点 |
| 消除 AI 判断 | 扩展 AI 认知 |
| 减慢输出 | 防止卡住的循环 |
微观管理使范围收窄。范围管理则照亮全局。
实际上范围管理的作用
AI 有视野范围:它只能看到上下文中的内容(代码、需求、对话历史)。
它看不到上下文之外的所有内容。
范围管理就是 为 AI 照亮它遗漏的区域。
没有范围管理:
┌───────────────┐
│ AI's Context │ ← AI 在此搜索
│ │
│ (code) │
│ (tests) │
│ (logs) │
└───────────────┘
盲点仍然是黑暗的。
有范围管理:
┌───────────────┐
│ AI's Context │
│ │
│ (code) │
│ (tests) │
│ (logs) │
└───────────────┘
│
▼ “还要考虑 X”
┌───────────────┐
│ Illuminated │ ← 现在可见
│ blind spot │
└───────────────┘
你不是在告诉 AI 如何 分析;而是向它展示 在哪里 查找。
当 AI 卡住时
没有范围管理,AI 可能会进入循环:
- 检查代码 → 看起来没问题
- 检查测试 → 看起来没问题
- 再次检查代码 → 仍然没问题
- 再次检查测试 → 仍然没问题
- 卡住
问题仍然存在,但它超出了 AI 的上下文范围,并非分析能力的不足。
案例研究:OHLC 条形测试之谜
情境
- 构建 OHLC(开‑高‑低‑收)条形聚合
- 1 分钟条形:测试通过 ✓
- 5 分钟条形:测试间歇性失败 ✗
AI 的回应
AI 检查了:
- 聚合逻辑 → 正确
- 时间窗口计算 → 正确
- 数据结构 → 正确
- 边缘情况 → 已处理
每次审查都未发现问题,但测试仍偶尔失败。
人为干预
“执行时间会影响结果吗?”
发现
测试数据是基于 系统时钟时间 生成的。代码使用 DateTime.Now 来创建测试夹具。
- 在 10:01 运行 → 5 分钟窗口对齐方式一
- 在 10:03 运行 → 5 分钟窗口对齐方式不同
该测试并非不稳定;它是 时间依赖 的。相同的逻辑,在不同的执行时刻,会产生不同的边界条件。
AI 为什么会错过
系统时钟没有出现在对话、代码审查范围或需求中。它完全超出了 AI 的上下文。没有任何“更仔细检查”能够发现它,除非有人指出这个盲点。
Context‑Outside Events
| In Context | Outside Context |
|---|---|
| Source code | System environment |
| Test code | Execution timing |
| Error messages | Infrastructure state |
| Documentation | Runtime dependencies |
When AI spins on a problem without progress, ask: What isn’t AI seeing?
The answer is usually something environmental, temporal, or infrastructural—things that don’t appear in code.
人类角色:超越框架的视角
| AI优势 | 人类优势 |
|---|---|
| 在上下文中进行深入分析 | 超越上下文的意识 |
| 对可见数据进行模式匹配 | 对不可见因素的直觉 |
| 彻底检查 | “如果代码中没有呢?” |
你不需要在分析上超越 AI;你需要 扩展框架。
实践中的范围管理
良好的范围管理
"Consider that this runs in a containerized environment with shared network resources."
"The database connection pool is limited to 10 connections."
"This service restarts nightly at 3 AM."
这些陈述提供了上下文,阐明了 AI 本身不会考虑的因素。
糟糕的范围管理(实际上是微观管理)
"Use a for loop, not a foreach."
"Put the null check on line 47."
"Name the variable 'tempCounter'."
这些控制实现细节,剥夺了 AI 的判断空间,却没有增加可见性。
差异概述
| 问题 | 微观管理 | 范围管理 |
|---|---|---|
| 你在指定什么? | 实现细节 | 环境上下文 |
| 对 AI 的影响是什么? | 限制选择 | 扩展认知 |
| 何时有用? | 很少 | 当 AI 卡住时 |
| 它增加了什么? | 你的偏好 | 你的可见性 |
何时注入上下文
表明 AI 需要范围管理而不是更多分析的迹象:
- 同样的检查重复出现且结果相同
- “我在代码中没有看到任何问题”
- 间歇性故障且没有规律可循
- 本地运行正常,CI 中失败
- 单独通过,整套测试失败
这些暗示 原因超出了 AI 当前的上下文。你的任务是:找出超出范围的因素并将其引入。
本文是 “超越提示工程” 系列的一部分,探讨结构性和文化性方法如何在 AI 辅助开发中胜过单纯的提示优化。