最近参加公司内部的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文档解决的是项目上下文问题。没有specAI每次都要从零开始理解你的项目——用的什么框架、什么目录结构、什么命名规范。有了specAI一开始就知道这些约定生成的代码天然就符合你的项目风格。这就好比你带一个新人入职第一件事不是直接派活而是先让他了解项目的整体情况。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不会替你思考需求它只会替你执行需求。想不清楚执行再好也是南辕北辙。