我把 AI 编程里的“未知项管理”整理成了一个可复用 Skill

使用者痛点

• 需求不完整，导致后期频繁返工。
• 上下文信息不足，Agent 无法准确定位业务与技术边界。
• 风险边界未识别，导致实现过程中出现不可预料的陷阱。
• 代码生成过早。假设被固化而非验证，增加后期调试成本。
• 缺乏可复用的工作流与决策模板，使每次迭代都从头开始。

背景与主要目标

这两年用 AI 写代码的人越来越多。但很多失败并不是因为模型不会写代码，而是因为它过早进入了“实现模式”。需求还没说透，仓库上下文还没看完整，风险边界还没被识别。Agent 就开始改文件、加抽象、补测试。其实，表面上进度很快，实际是在用代码把假设固化下来。

主要目标：

在真正动手之前、动手过程中、交付之后持续发现和管理未知项。

仓库内容概览

当前主要包含一个 skill：

skills/
├── discover-unknowns/
│ ├── SKILL.md
│ ├── agents/openai.yaml
│ └── references/prompt-patterns.md
└── discover-unknowns-zh/
├── SKILL.md
├── agents/openai.yaml
└── references/prompt-patterns.md

discover-unknowns 是英文版，discover-unknowns-zh 是中文版。

适用场景

• 需求模糊，使用者自己也还没完全想清楚。
• Agent 对业务、代码库或技术栈不熟悉。
• 改动会影响架构、数据模型、API、UX 或测试策略。按理说，
• 任务链路很长。过程中容易不断暴露新问题。不过，
• You want Agent first identify blind spots rar than jump straight into coding.

从主要思想来看。地图不是领地

This skill’s core stems from Thariq’s practical insight:

The prompts,plans,context and skills are just “maps”;其实，real codebase,user preferences,business constraints,quality standards and review process are “territory”.

A lot of issues arise when map and territory diverge.

• The requirement says “add an export feature”,but never mentions large data volume.
• An existing permission system is overlooked by Agent because it wasn’t retrieved.
• User wants a “clean interface”,but actually means a dense admin‑tool feel.
• The tests pass locally yet fail in production due to legacy migration constraints.
• A solution looks fine on paper but reviewers focus on rollout and rollback plans.

四类未知项拆分

The latter two are most troublesome categories.

"Unknown knowns" frequently appear in product design and copywriting—users struggle to describe m upfront but can judge instantly after seeing a prototype.

"Unknown unknowns" pose greater danger—y could be legacy baggage,boundary cases or performance bottlenecks that only surface during testing or review sessions.