范围管理并非微观管理

发布: (2026年1月2日 GMT+8 22:00)
6 min read
原文: Dev.to

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 可能会进入循环:

  1. 检查代码 → 看起来没问题
  2. 检查测试 → 看起来没问题
  3. 再次检查代码 → 仍然没问题
  4. 再次检查测试 → 仍然没问题
  5. 卡住

问题仍然存在,但它超出了 AI 的上下文范围,并非分析能力的不足。

案例研究:OHLC 条形测试之谜

情境

  • 构建 OHLC(开‑高‑低‑收)条形聚合
  • 1 分钟条形:测试通过 ✓
  • 5 分钟条形:测试间歇性失败 ✗

AI 的回应

AI 检查了:

  • 聚合逻辑 → 正确
  • 时间窗口计算 → 正确
  • 数据结构 → 正确
  • 边缘情况 → 已处理

每次审查都未发现问题,但测试仍偶尔失败。

人为干预

“执行时间会影响结果吗?”

发现

测试数据是基于 系统时钟时间 生成的。代码使用 DateTime.Now 来创建测试夹具。

  • 在 10:01 运行 → 5 分钟窗口对齐方式一
  • 在 10:03 运行 → 5 分钟窗口对齐方式不同

该测试并非不稳定;它是 时间依赖 的。相同的逻辑,在不同的执行时刻,会产生不同的边界条件。

AI 为什么会错过

系统时钟没有出现在对话、代码审查范围或需求中。它完全超出了 AI 的上下文。没有任何“更仔细检查”能够发现它,除非有人指出这个盲点。

Context‑Outside Events

In ContextOutside Context
Source codeSystem environment
Test codeExecution timing
Error messagesInfrastructure state
DocumentationRuntime 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 辅助开发中胜过单纯的提示优化。

Back to Blog

相关文章

阅读更多 »

没人再知道发生了什么

封面图片:Nobody Knows What's Happening Anymore https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2...