AI编程提效的真实瓶颈：不是工具不行，是需求没说清楚

最近参加公司内部的AI交流会，散场后和几个同事聊起来，发现一个很有意思的现象：大家都在用AI编程工具，有人用Cursor，有人用Claude Code，有人用GitHub Copilot，但提效的感受差异很大。有人说「已经离不开了」，有人说「也就那样吧，省不了多少事」。

工具都差不多，差距到底在哪？我琢磨了一下，觉得核心就两个问题：第一，你能不能把需求说清楚？第二，你知不知道怎么让AI去执行？

听起来简单，但这两个问题里藏着AI编程提效的真正瓶颈。而且如果非要排个优先级，第一个问题比第二个重要得多。

需求清晰度决定了AI输出的天花板

「让AI做什么」这个问题，本质上是需求问题。需求通常分两类：产品需求和技术需求。产品需求说的是"要实现什么功能"，技术需求说的是"用什么方案实现"。不管哪种，核心就一件事——你能不能把事情说明白，让对方清楚知道要做什么。

举个最常见的例子。你跟AI说「帮我加一个登录功能」，这算说清楚了吗？不算。用什么登录方式？手机号、邮箱、还是微信授权？登录成功跳哪？失败怎么提示？需要记住登录状态吗？多久过期？密码要不要加密存储？用什么算法？这些细节你不交代，AI只能按自己的理解来，出来的东西大概率不是你要的。然后你看着生成的代码说「不对，我要的不是这样的」，改了一版又一版，算下来可能比自己写还慢。

再说一个更隐蔽的场景。你让AI「优化这个接口的性能」，但没有告诉它当前的瓶颈在数据库查询还是网络IO，没有告诉它这个接口的QPS基线和目标值，也没有告诉它是否允许引入新的依赖。AI拿到这个指令，只能按最常见的优化路径走一遍——加索引、加缓存、异步化——做完你可能发现它优化的根本不是你的瓶颈。你花时间review它生成的代码，发现方向不对，全部推翻重来。这种"无效交互"才是AI编程最浪费时间的部分。

有些人可能会觉得，工具越来越强，对需求的要求应该越来越低才对。但我的观察恰恰相反：AI编程提效的上限，不取决于工具的能力，而取决于你描述需求的能力。工具越强，它越能在模糊需求下产出"看起来能跑"的代码，但"看起来能跑"和"真的是你要的"之间的差距，才是反复修改、来回拉扯的根源。

理解工具机制：让AI"可持续"地执行

需求想清楚了，下一个问题是：怎么把需求有效地传达给AI，而且不是一次性的，是可持续、可复现的。

不同的AI编程工具有不同的机制。以Claude Code为例，它提供了好几种"喂需求"的方式：

• spec文档

  ：用Markdown写项目的上下文、架构决策、编码规范，让AI知道你的项目长什么样；

• Skill

  ：把重复出现的操作流程封装成可复用的技能，下次直接调用；

• Sub Agent

  ：把复杂任务拆成多个子任务，交给不同的Agent并行处理；

• Rules

  ：定义行为约束，告诉AI哪些事情不能做、哪些风格要遵守；

• 引用文件

  ：直接让AI读取项目中的相关文件，理解现有代码的结构和约定。

这些机制不是为了炫技，每一个都在解决一个具体问题。

spec文档解决的是"项目上下文"问题。没有spec，AI每次都要从零开始理解你的项目——用的什么框架、什么目录结构、什么命名规范。有了spec，AI一开始就知道这些约定，生成的代码天然就符合你的项目风格。这就好比你带一个新人入职，第一件事不是直接派活，而是先让他了解项目的整体情况。

Skill解决的是"重复指导"的问题。如果你发现自己在反复跟AI解释同一类操作——比如"每次写新接口都要按这个格式来""提交代码前要跑这些检查"——那就把它封装成一个Skill，下次一句话调用就行。这本质上就是把你的最佳实践固化下来，让它可复用、可传播。

Rules解决的是"约束"问题。有些东西不是需求，而是底线——不能用any类型、必须处理错误、日志格式要统一。这些约束如果你不提前说，AI不会自己遵守。

理解这些机制的目的很简单：让AI编程从"每次手动输入prompt"变成一个有流程、可复现的工程化过程。只有这样，提效才是可持续的，而不是碰运气。

大部分团队的需求，只是个"想法"

前面说了两个问题：把需求说清楚，以及理解工具机制。这两个缺了哪个都不行。但说实话，第二个问题好解决——花点时间研究工具文档，写几个spec，封装几个Skill，很快就能上手。真正难的是第一个。

我在实际工作中观察到一个现象：大部分个人、团队甚至公司，需求描述的载体——不管是文档、口头传达还是JIRA上的工单——往往不够细致，不够标准。有些需求在我看来只是一个"想法"，它没有被完善成一个标准化、体系化的东西。

对比一下就清楚了。

「我们需要一个用户管理模块」——这是一个想法。它只描述了方向，没有细节。

「我们需要一个用户管理模块，支持用户的增删改查，用户有三种角色（管理员、编辑者、查看者），管理员可以修改所有用户信息，编辑者只能修改自己的，查看者只能看。需要支持批量导入用户（Excel格式），导入时要做格式校验和去重，失败的数据生成错误报告供下载。」——这是一个需求。它有角色、有权限、有场景、有异常处理。

这两者的区别在于：想法只有表面，需求有层次。想法告诉你"去哪"，需求还告诉你"怎么去、中间有什么坑、到了怎么验收"。

以前这种模糊的需求还能凑合。为什么？因为你把一个"想法"丢给一个有经验的开发者，他会凭经验补全你的意思——不明白的地方跑过来问你，边界情况自己判断，来回几轮也就做出来了。这个"人肉补全"机制帮你兜了底。

但AI不会这样。你给它一个"想法"，它不会主动问你"这个场景你希望怎么处理"，它只会按你给的信息去生成代码。你的需求里缺了什么，生成的代码里就会缺什么。以前那个帮你兜底的"人肉补全"机制，失效了。

这就是为什么AI编程时代，需求描述的质量变得前所未有地重要——不是因为它是一个全新的要求，而是因为以前的容错机制没了。

大部分需求不是"说清楚"了，只是"说过了"。说清楚和说过了之间的差距，就是你拿到AI生成的代码后还需要改多少遍。

七个维度，把"想法"变成"需求"

说到"需求要结构化"，很多人第一反应是"又要搞文档模板那一套了"。

不是。

结构化需求的本质不是填表格，而是逼自己把每个维度想到位。一个真正说清楚的需求，至少要覆盖这七个方面：

• 为什么

  ——背景和动机，让执行者理解意图而不是机械执行；

• 目标

  ——要达成什么效果，有没有具体的性能指标或数据指标；

• 表面是什么

  ——功能长什么样，用户能看到什么，交互流程是怎样的；

• 下层有什么

  ——数据怎么流转，状态怎么管理，依赖哪些服务，跟哪些模块有交互；

• 边界是什么

  ——什么在范围内，什么明确不在。哪些场景要处理，哪些场景这次不处理；

• 细节处理

  ——异常情况怎么办，边界值怎么处理，并发情况怎么兜底；

• 约束是什么

  ——必须遵守哪些规则、哪些规范，不能违反哪些约定；

• 验收标准

  ——怎么判断做完了、做对了。

你不需要每次都写一个面面俱到的文档。有些需求天然就简单，七个维度过一遍可能一分钟都不用。但至少在动手之前，自己过一遍，看看有没有明显缺失的地方。

说个真实的感受：很多一开始觉得"想清楚了"的需求，在过这七个维度的时候才会暴露出模糊地带。「这个场景要处理吗？」「这个接口的并发上限是多少？」「失败了是重试还是直接报错？」——这些问题如果不在需求阶段想清楚，就会在代码review阶段变成来回拉扯。

所以我说，结构化需求不是填模板，是一种思考方式。模板只是手段，目的是让你在动手之前就把事情想明白。想明白了，写下来也好，口述也好，传给AI也好，都只是一个传递形式的问题。

先把需求想清楚，再研究工具怎么用

如果你正在考虑用AI编程工具来提升效率，不管是自己用还是团队推，我的建议是：先花精力把需求描述的质量提上来，再去研究工具的各种机制。

这个顺序不能反。工具的spec、Skill、Sub Agent这些机制，都是在需求清晰的前提下才能发挥作用的。需求本身含糊不清，再好的工具机制也只是让AI更快地产出一个你不满意的结果。工具解决的是"怎么做"的问题，但"做什么"如果没想清楚，执行得越快，返工得越快。

而且这件事有个好处：练习需求描述不需要学任何新技术，不需要装任何工具，今天就可以开始。下次写需求的时候，多花十分钟过一遍那七个维度，看看有没有遗漏。坚持做一段时间，你会发现不仅是AI理解得更准了，你自己对要做什么的理解也更深了。

如果你真的想把AI编程做成团队里可持续的提效手段——不是靠个别"prompt高手"撑着，而是每个人都能稳定地产出高质量结果——那前置的需求描述，务必做成结构化、标准化的输出。这是提效的地基，没有这个地基，上面盖什么都白搭。

AI不会替你思考需求，它只会替你执行需求。想不清楚，执行再好也是南辕北辙。