文章摘要
文章围绕AI辅助代码开发中未知项的处理展开。介绍未知项分为四类，强调梳理规划未知项是核心技能。阐述借助AI挖掘未知项的方法，以及开发前、中、后期应对未知项的策略。还给出Fable发布视频开发案例，指出应缩小蓝图与现实差距，让AI理清未知项。

在使用AI辅助代码开发的过程中，尤其是借助长任务协作工具时，我们常常会遇到一个经典的矛盾：我们预设的工作蓝图（也就是提交给AI的提示、上下文和技能要求）和实际的工作现场（代码库、真实业务约束）之间存在差距。这个差距，就是我们所说的未知项（unknowns）。当AI遇到未知项时，只能基于对用户意图的最佳猜测做决策，任务规模越大，遇到的未知项就越多。

Fable是第一个让开发者明显感受到工作质量直接取决于能否清晰梳理未知项的AI模型。值得注意的是，提前规划并不足够，很多未知项会在开发深入后才浮现，甚至会让你意识到需要完全调整解决方案。因此，和Fable协作其实是一个在开发前、中、后不断迭代发现未知项的过程。

理清你的未知项分类

当我们向AI提出需求时，可以将未知项分为四类：

  • Known Knowns（已知已知）：就是我们明确写在提示词里的内容，也就是我们清楚告诉AI我们想要什么。
  • Known Unknowns（已知未知）：我们意识到自己还有没想清楚的部分，清楚知道自己存在认知盲区。
  • Unknown Knowns（未知已知）：一些我们习以为常、不会主动写进提示词，但当看到结果时就能立刻识别出是否符合预期的细节，比如视觉风格、交互逻辑的隐性标准。
  • Unknown Unknowns（未知未知）：我们完全没有考虑过的盲区，既不知道自己不知道什么，也不清楚相关领域的标准和坑点。

优秀的AI开发者会尽量减少未知项，他们对需求和代码库的理解更深入，但即使是专家也会预设未知项的存在。而梳理和规划未知项本身就是智能编码的核心技能之一，这个技能可以通过和AI工具协作不断提升。

借助AI工具高效挖掘未知项

给AI下指令是一种微妙的平衡。如果指令过于具体，AI会严格按照要求执行，即使此时转向另一条路径可能更合适；如果指令过于模糊，AI又会基于通用行业最佳实践做出假设，这些假设未必贴合你的具体任务。忽视未知项会导致两种问题：要么AI陷入不必要的细节，要么偏离任务方向。

AI可以帮助我们更快发现未知项：它能快速检索代码库和网络信息，比我们更快掌握陌生领域的知识，也能更快从失败中迭代。关键是要向AI清晰传递你的起点：比如当前的思考进度、你对问题和代码库的熟悉程度，让它成为你的协作伙伴。HTML格式的产物是可视化和表达问题的最佳方式，能帮助我们更清晰地传递需求和反馈。

开发前期：提前识别未知项

盲检盲区

当我们在陌生的代码区域开发功能，或者接触不熟悉的领域时，很容易存在大量未知未知。我们可以直接让AI帮我们梳理盲区，比如明确告诉AI你对当前模块的熟悉程度，让它帮你找出相关的未知项，优化后续的提示词。

我正在添加新的认证提供商，但对项目的认证模块完全不了解，能否帮我做一次盲区检查，找出相关的未知未知，帮我优化后续的提示词？

我需要给视频做调色，但完全不懂色彩分级，能否帮我理清这个领域的未知盲区，让我后续能更清晰地提出需求？

头脑风暴与原型制作

当我们面对很多未知已知的领域，也就是隐性的判断标准需要看到结果才能确认，我们可以让AI和我们一起做头脑风暴和原型。在早期识别未知已知非常重要，因为到开发后期再调整的成本会高很多，小的需求变化可能导致代码结构大幅调整，AI回退修改也会更困难。

比如我们只是想在某个页面加个按钮，但不想改动后端路由和前端状态，或者视觉设计很难用语言描述，但看到就能识别好坏，这时可以让AI生成多个设计方向的原型。每次开发session前先做头脑风暴，能帮助我们明确项目范围，避免范围过窄或过宽。

我想做一个数据仪表盘，但没有视觉设计经验，也不清楚有哪些可行的方向，帮我做4个不同设计风格的HTML页面，让我可以选择反馈。

在接入真实逻辑前，先做一个单独的HTML文件，用模拟数据制作新的编辑器工具栏，我想先确认布局是否符合预期，再修改真实应用代码。

用户在注册后流失，帮我搜索代码库，头脑风暴10个可以介入优化的节点，从低成本到高复杂度排序，我会告诉你哪些方向符合预期。

需求访谈

在充分头脑风暴后，我们可能还有未明确的未知项，这时可以让AI围绕模糊点向我们提问，引导我们理清需求。需要给AI足够的上下文来让它的问题更有针对性。

针对所有模糊的地方，一次问我一个问题，优先选择那些会影响整体架构的问题。

参考复用

当我们无法清晰描述需求时，最好的方式是提供参考。除了图表、文档、图片，最好的参考是源代码。比如我们可以让AI查看某个特定文件夹的代码，即使是其他语言编写的，来复用其中的实现逻辑。

vendor/rate-limiter 目录下的Rust库实现了我需要的退避策略，帮我阅读它的代码，然后在我们的TypeScript API客户端中实现相同的语义。

AI设计工具也是如此，我们可以直接指向喜欢的网站模块，让AI读取底层代码，而不仅仅是截图，这样能获得更完整的细节，包括标签结构、组件构建方式等。

开发计划制定

当我们准备进入开发阶段时，可以让AI生成一份开发计划，重点关注最可能变化的部分，比如数据模型、类型接口、用户交互流程，这样AI可以提前暴露我们需要调整的地方。

用HTML格式编写开发计划，开头先列出我最可能需要修改的决策点：数据模型变化、新的类型接口、所有用户可见的内容，机械重构部分放在最后，这部分我信任你的判断。

开发中期：动态应对未知项

开发记录与调整

即使我们做了充分的计划，仍然会有未知项隐藏在开发过程中，AI可能会在开发中发现代码的边缘情况，需要调整原有方案。我们可以让AI维护一个临时的开发记录文件，比如 implementation-notes.md 或者HTML格式的文件，记录它做出的决策，方便后续复盘优化。

帮我维护一个 implementation-notes.md 文件，如果遇到需要偏离原计划的边缘情况，选择保守方案，并将调整记录在“Deviations”栏目下，然后继续推进开发。

开发后期：验证与对齐

成果汇报与解释

交付成果时，获得团队的支持和批准非常重要。我们可以将原型、开发计划、开发记录整合成一份解释文档，帮助评审者快速理解，尤其是当评审者一开始也有相同的未知项时，能加速理解过程，也能让专家确认我们是否考虑到了他们预期的未知项和常见问题。

将原型、开发计划和开发记录整合成一份单独的文档，我可以直接发到团队沟通工具中争取支持，开头先放上演示动图。

成果测试与复盘

经过长时间的开发session后，AI可能完成了比我们预期更多的内容，仅仅阅读代码差异很难完全理解所有改动，因为很多行为依赖现有的代码逻辑。我们可以让AI基于上下文生成一份HTML报告，说明所有改动，并在底部附上测试题，只有通过测试我们才能确认完全理解了改动内容，再合并代码。

我想确保自己完全理解这次的所有改动，帮我生成一份HTML报告，清晰说明改动内容，让我能带着完整的上下文、具体实现细节读懂它，并在底部附上关于这些改动的测试题，我必须通过测试才能合并代码。

实战案例：Fable发布视频的开发过程

Fable的发布视频完全是用Claude Code剪辑完成的，这对作者来说是一个陌生的领域。首先，作者知道AI可以剪辑视频和转录，但不确定准确性，于是让AI解释转录技术的原理，比如语音识别的工作方式，以及能否用工具准确去除口癖和过长停顿。

然后，作者想让AI生成和配音同步的UI，但不确定能否实现，于是让AI用相关工具和转录文本生成一个原型视频，验证可行性。最后，视频整体色调偏暗，作者知道需要色彩分级，但不懂相关知识，一开始想让AI生成多个版本供选择，但后来意识到自己根本不知道“好”的色彩标准是什么，于是改为让AI讲解色彩分级知识，从而理清自己的未知项。

总结：缩小蓝图与现实的差距

AI模型能力越强，只要方法得当，我们能完成的任务就越多。当长任务返回的结果不符合预期时，往往意味着我们需要花更多时间梳理未知项，或者生成更清晰的开发计划，让AI能够围绕未知项做出合理的调整。

每一份解释文档、头脑风暴记录、需求访谈记录、原型和参考代码，都是低成本的方式，帮助我们在修复成本变高之前，发现那些我们之前不知道的盲区。所以，在下一次开发项目时，先让AI帮你理清所有的未知项。

塔猴是一个专注于为用户提供系统学习、内容创作与商业连接的AIGC综合服务平台，致力于为每一位AI探索者打造理想的创作、成长家园。在塔猴，你不仅可以学习众多AIGC类实战课程，获得与时俱进的AIGC技能和视野，还有机会获得长期商业合作和接单机会！点击进入：https://www.tahou.com/

AI生成内容提示：本文由人工智能辅助创作，内容仅供参考，不代表平台观点。请注意核实信息的准确性，并理性判断。

以上内容不代表本平台立场，仅供读者参考