Agentic Coding Unknowns (智能体编程未知管理)
在大语言模型（如 Claude Fable 5 / Claude Code）展现出强悍的长时运行自主性时，软件开发的核心瓶颈逐渐从“编写代码的效率”转移到了**“界定并澄清未知情况（Unknowns）的能力”**。这一方法论构成了智能体工程的重要组成部分。
1. 核心心智模型：地图与疆域 (The Map and the Territory)
Source: 2026-07-07-x-x-com-trq212-status-2073100352921215386-s-46（来源未公开） & 2026-07-09-xiaohongshu-xhslink-com-o-5QgoCW5c1cG（来源未公开）
- 地图 (The Map)：开发者大脑中或输入给智能体的 Plan/Prompt/Spec（规格说明）。这是开发者主观期望与设计意图的表达。
- 疆域 (The Territory)：真实的代码库（Codebase）、实际运行环境、物理边界条件和真实世界约束。
- 未知 (Unknowns)：疆域中那些地图未写明或两者之间存在差异的部分。
当智能体在运行中遇到未知时，它必须基于对开发者意图的最佳猜测做出选择。如果地图不匹配疆域，智能体在漫游如此庞大的代码疆域时就会迷失或做出错误的假设。因此，软件开发的瓶颈从“编写代码的效率”变成了“将地图与疆域对齐、识别并解决未知的速度”。
2. 智能体编程中的未知矩阵 (Unknowns Matrix)
Source: 2026-07-09-xiaohongshu-xhslink-com-o-5QgoCW5c1cG（来源未公开）
为了系统化管理，可将智能体和开发者在环境中面临的未知信息划分为四个象限：
| 象限 | 名称 | 释义与智能体应对 |
|---|---|---|
| 1 | 已知已知 (Known Knowns) | 明确写入 Prompt / Spec 中的信息，清晰知道我们需要什么。 |
| 2 | 已知未知 (Known Unknowns) | 我们明确意识到但目前尚未确定的部分（例如“待探索的第三方 API 限制”，需要去探寻）。 |
| 3 | 未知已知 (Unknown Knowns) | 那些我们觉得理所当然、显而易见因而没有写下来的设计直觉（通常是“我们一看到不符合预期的结果就会知道”的事物）。 |
| 4 | 未知未知 (Unknown Unknowns) | 开发者完全没有考虑过、处于认知盲区的事物（例如底层的系统漏洞或级联错误）。 |
3. Fable 探测未知五大工具 (The 5 Tools for Finding Unknowns)
Source: 2026-07-09-xiaohongshu-xhslink-com-o-5QgoCW5c1cG（来源未公开）
为了防止智能体在长周期任务中偏离航道，优秀的智能体工程师会主动配合 Fable/Claude Code 使用以下五类探测工具：
3.1 盲点检测 (Blind Spot Pass) —— 应对“未知未知”
在不熟悉的代码库或新特性开发前，直接要求模型进行盲点扫描，找出潜在的设计冲突或技术陷阱。
- 提示词示例：“我正在此代码库中开发一个我不太熟悉的 OAuth 模块。请帮我做一个 blind spot pass，寻找有哪些在这个 codebase 里潜藏的未知未知（盲区），并教我如何提供更清晰的 context 来指引你。”
3.2 头脑风暴与多样性决策原型 (Brainstorms & Prototypes) —— 应对“未知已知”
人类常有“看到成品时才知道自己要什么”的设计本能（即未知已知）。在涉及 UI/UX、交互或者视觉 taste 时，绝不要直接修改生产代码。
- 最佳实践：让模型生成一个单独的 Dashboard HTML 页面，包含四种截然不同的视觉和设计决策原型，让用户通过对比反应，将脑海中隐含的审美直觉（未知已知）显性化。
3.3 深度反向面试 (Interviews) —— 澄清模糊架构
让智能体反过来扮演面试官，探求系统的架构边界。
- 最佳实践：对于复杂的 Spec，要求 Fable：“请对我进行反向 interview，列出 40 个可能会从根本上影响、改变系统架构设计的最关键问题。每次只问一个，帮我厘清设计模糊点。”通过这样的强互动把隐含在人脑中的信息挖出来。
3.4 源码/跨语言参考 (References) —— 提供另一张精确的地图
自然语言容易产生歧义，而代码本身就是最精准的地图。
- 最佳实践：直接将现有的其他系统、其他编程语言的实现，或者 HTML mockup 作为 reference 喂给模型。例如：“这是我们用 Rust 写的旧版组件代码。请你读懂它，并将其作为参考，用 TypeScript 重写它。”
3.5 实施记录与通关测试 (Implementation Notes & Quiz) —— 保持 Stay in the Loop
在实现过程中和实现后，防止人陷入无脑 approve 的点头循环（Nodding Loop）。
- Implementation Notes（实施日志）：要求模型在遇到未知偏离原方案时，将偏离方案（Deviations）的决策和理由记录在
implementation-notes.md中。 - Quiz（代码理解测试）：为了确保开发者在合并 PR 时真正理解了智能体自动生成的庞大代码，强制要求模型针对它所做的改动和逻辑向开发者发起一次测验（Quiz），只有开发者回答正确，才允许合并 PR。
4. 拒绝妥协 (Being Unreasonable) 与 Trade-offs 重塑
Source: 2026-07-09-xiaohongshu-xhslink-com-o-5QgoCW5c1cG（来源未公开）
Fable 以及更高级的智能体正在从根本上重塑软件开发中的权衡（Trade-offs）关系：
- 传统软件工程的妥协：在“Good (高品质)”、“Fast (快速交付)”、“Cheap (低成本/低资源)”之间，项目管理者通常只能三选二（Pick Two）。
- 智能体时代的 Pick Three (全选)：由于智能体使编程效率获得了数量级级别的提升（使原本耗时数周的工作在几小时内完成），好、快、省的边界被重塑了。Thork 指出，智能体工程师应当 “Being Unreasonable”（拒绝妥协、不再合理），不要被过去的“合理限制”框死。
- 从过程到价值：构建软件变得越来越容易，但“产生真正的商业价值 (generating value)”依旧很难。在技术无缝落地、生产力爆发的背景下，人类唯一的出路就是 stay in the loop（保持在控制回路中），勇于设立更雄心勃勃的目标，更少去妥协。
5. 关联页面
- agentic-engineering — Andrej Karpathy 提出的关于在 Vibe Coding 中保持 Quality Bar 的工程学，以及 Thork 提出的 Unhobbling Claude 实践
- loop-engineering — 智能体运行闭环、Maker-Checker 架构及评估策略
- learning-methods — 理解主权，“可以外包思考，但不能外包理解”的方法论