最近在梳理自己过去一年用 LLM 辅助开发的真实体感时我意识到一件反直觉的事那些让我效率明显提升的时刻几乎都不是 LLM 替我把某一段代码敲完的时刻。恰恰相反真正改变工作节奏的是它帮我处理了那些“说不清、道不明、到处是问号”的环节——项目的需求边界、方案的取舍理由、一段报错背后的运行逻辑。这种状态用“Cloudy development”来形容非常贴切它不像任务清单那样清晰可见更像阴天里的能见度不足。你明明知道目标在那里但每一步都不确定。而 LLM 的加速本质上不是在替你的手指工作而是在替你的认知提升能见度。所以这篇文章想表达的核心判断很简单LLM 加速开发靠的不是“替我写代码”而是把开发过程中大量模糊、不确定、需要反复探索的部分变成了一种可以对话、可以验证、可以沉淀的工作流。如果你也曾经觉得“LLM 生成代码好像没有想象中好用”那很可能不是因为工具不行而是因为你仍然在把它当打字员用。1. 先搞清楚开发里真正“慢”的地方从来不是敲键盘1.1 确定性编码与模糊探索的差别很多人一提起用 LLM 做开发第一反应就是“让 AI 写代码”。这个印象本身没有错但它只覆盖了程序员工作中很窄的一部分。如果我们把日常开发拆开看会发现真正消耗时间的往往不是“写出代码”这个动作而是“确定该写什么”和“确定为什么这么写”的过程。我可以把开发任务粗略分成两类。第一类是确定性编码。比如把接口文档转成 TypeScript 类型定义把一个简单的 CRUD 接口按项目现有风格补齐把一段配置从一个环境迁移到另一个环境。这类任务输入明确、输出边界清楚LLM 或传统代码补全工具都能做得不错人也很难从中获得什么“认知提升”。第二类是模糊探索。比如一个刚接手的需求产品经理只说“要做个数据看板”但没有说清楚哪些指标最重要一个线上偶发异常日志只给了一句泛泛的报错没有人知道是哪一层出的问题一个技术方案摆在面前两种实现方式各有优劣但团队里没人能讲明白选型背后的取舍。这类任务有一个共同特征它们“看不清”。就像阴天里看远处的东西你只看到一个轮廓无法确定边界。过去我们解决这些问题的办法是拼经验、查资料、做实验、开讨论会偶尔还要靠一点直觉。这种状态就是我说 Cloudy development 的含义——它指的不是云端开发而是开发中那种“能见度不足”的模糊状态。1.2 那些“说不清但很耗时”的开发环节一旦你接受这种划分就会意识到一个事实大多数程序员每天花在“模糊探索”上的时间可能比花在“写法代码”上的时间更多。只不过这些时间被切得很碎你很难意识到它到底消耗在哪里。举几个真实到几乎每个人都经历过的例子你接到了一个看似简单的需求但打开编辑器之后脑子里马上冒出一串问题这个字段到底要不要冗余如果用户连续提交两次怎么办历史数据需不需要兼容需求文档里一句话带过背后隐藏的全是判断。你遇到一个报错错误信息读了三遍还是没弄明白到底是参数格式不对还是某个依赖版本冲突。你开始在搜索引擎和社区帖子里来回跳最后试了四五种方案才找到问题。你写完一段代码自己心里没有底不知道它能不能覆盖所有边界。于是你反复读自己的代码试图站在测试人员的角度找漏洞。这些环节都有一个共同的敌人不确定性。而 LLM 真正擅长的事情恰恰是处理这种“不明确”的信息。它会根据你给出的有限上下文生成一个或多个合理的解释、方案或候选答案。它未必总是对的但它能把原本只有轮廓的“阴天”变成一张可以继续追问的地图。2. LLM 加速的不是代码输出而是“把模糊变成清晰”2.1 如果只把 LLM 当补全工具你已经低估了它现在的代码补全工具做得越来越像“原生开发的一部分”但它解决的问题仍然比较表层你写了一半函数它帮你补完后半段你敲了一个常见的循环它把结构帮你补齐。这类工具的核心价值是减少击键量把重复性的语法劳动自动化。但 LLM 的能力边界远远不止于此。它真正特别的地方是可以在信息不完整、目标不明确的情况下帮助你生成“可供判断的候选方案”。举个例子。以前面提到的“数据看板”需求为例。如果你把需求原封不动丢给 LLM让它直接生成看板页面它大概率会给你一个看起来完整、但完全没有考虑到你业务语境的模板。这个模板可能能用但它解决的是“写一个页面”的问题而不是“这个看板到底该看什么”的问题。可如果你换一种用法先让 LLM 帮你拆解需求情况就完全不同了。你可以这样问这个需求是给谁看的他做决策时最需要哪几个数据如果数据延迟了一天会不会影响决策如果某个指标突然异常我们优先看出入口还是趋势这些问题不一定都由 LLM 来回答但它可以帮你把容易忽略的维度主动列出来。你不需要照单全收但它至少让你意识到原来这个需求背后还有好几层没有敲定的问题。这种价值不是“帮你写代码”而是“帮你想清楚”。它把一团模糊的需求拆成了一个个可以逐个确认的问题。每确认一个问题你面前的阴天就薄了一层。2.2 从一次需求拆解看 LLM 的真正价值我经常拿一个实际流程举例。假设你接到一个新功能要在现有系统里增加“批量导入并校验用户数据”的能力。如果直接让 LLM 写导入接口它可能会给出一个很标准的实现上传文件、读取解析、逐行校验、返回结果。表面上看代码没问题但你真拿去落地时会撞到一堆需求层面没有想清楚的问题导入文件最大支持多大是 1MB、100MB 还是 1GB文件编码是 UTF-8 还是可能有 GBK校验失败时是中断导入还是跳过错误行继续处理错误报告要精确到哪一行、哪一列、什么原因如果导入过程中系统重启数据要不要恢复这些问题如果不先想清楚代码写出来也经不起推敲。传统开发里你大概率是在写代码的过程中才逐个意识到它们然后一遍遍改逻辑。但如果你在动手前先用 LLM 做一轮“需求追问”把上面这些问题都列出来再带着这组问题去找产品经理确认开发效率会完全不一样。这不是因为 LLM 比你聪明而是因为它能够稳定地生成一份“常见边界检查清单”。你可以把它看作一个没有太多业务感情但阅读量很大、经验很广的同事。它提出的问题未必都适用但它能帮你打开思路让你从“闷头写代码”的状态里跳出来。3. 从设计到验证LLM 应该出现在流程的哪些节点3.1 需求澄清让模型先追问而不是先给代码最容易出效果也最容易被忽略的 LLM 使用场景是需求澄清阶段。大多数人的习惯是需求一拿到手就开始想代码结构、数据结构、接口怎么拆。这种习惯不能说错但很容易在前面没有对齐的情况下做出一个不在点上的实现。更好的做法是把需求原文丢给 LLM然后让它扮演一个“专门追问需求边界的人”。你可以明确告诉它不要写代码请先列出这个需求里所有可能影响实现的问题。比如数据来源、权限控制、异常场景、性能要求、兼容范围、后续扩展方向。我自己试过的体感是LLM 列出的问题里大约六成是你能想到的但剩下四成很可能是你匆匆扫需求时漏掉的。比如“导入过程中有重复数据怎么办”“如果第三方接口超时是重试还是直接失败”“用户没有权限时的表现算不算异常”。这些问题听起来琐碎但到了开发后期每一个都可能变成一个 bug 或一次返工。这个阶段真正的产出不是一段代码而是一份被问清楚的需求边界。你把这份边界带到评审会上沟通效率会明显提高因为你讨论的已经不是“我理解得对不对”而是“这些边界我们怎么定”。3.2 方案设计让模型给选项而不是给结论很多技术人员用 LLM 做方案设计时最容易犯的错误是让它直接给一个最终方案。比如“帮我设计一个订单系统的数据库表结构”然后期待它给出一个直接能用的答案。这种用法不是不行但结果往往比较平庸而且很难判断它是否适配你的业务场景。更建议的做法是让 LLM 先给你一组候选思路并说明各自的代价。你可以这样问订单表要不要做分库分表如果现在业务量不大直接用单表后期再迁移可行吗如果要做读写分离哪些查询走从库什么时候需要引入消息队列你会发现LLM 的价值在于帮你把“备选方案”和“选择维度”展开而不是替你拍板。因为方案选择往往取决于团队能力、历史包袱、资源成本和时间窗口这些信息模型并不完全知道。但如果你自己心里有一个大致倾向LLM 可以帮你从这个倾向出发推演可能的坑和测试点。我一般会把它拆成三步让模型给 2 到 3 个候选方案并标注每个方案的优缺点。针对自己倾向的那个方案让模型列出需要提前确认的技术风险。把模型生成的内容当作“检查清单”而不是“最终设计文档”。这个流程看起来很轻但它能显著减少“方案定完以后发现隐藏问题”的概率。3.3 调试与解释把报错变成可理解的路径调试是开发中另一个典型的高频、高模糊场景。报错信息有时候非常直接有时候则令人摸不着头脑。尤其是你碰上一些框架层面的堆栈信息可能只看到上百行调用链却不知道问题到底出在哪里。过去我们的做法是把报错复制到搜索引擎里在几篇两年前的帖子里翻答案。但现在 LLM 提供了一个更顺滑的路径把完整报错、相关代码片段、你的运行环境信息一起发过去让它先帮你解释“这条报错到底在说什么”再让它给出“最可能的几个原因”和“对应的排查动作”。我通常不会让 LLM 直接给我改好的代码而是先让它给出排查顺序。比如“先确认请求参数里有没有空值”“再看数据库连接池有没有被耗尽”“最后检查是不是某次发布导致注解扫描路径变了”。因为很多时候报错的真正原因需要你结合现场才能判断直接改代码反而容易带偏方向。这里要特别强调一点LLM 调试建议的价值不在于答案一定正确而在于它能帮你把“无数种可能”收敛成几个“值得先验证的方向”。有了这个方向你再去翻代码、看日志、复现问题就不会像无头苍蝇一样乱撞。4. 真正决定效率的是输入、验证和沉淀4.1 给模型“干净的上下文”比写提示词更重要很多人觉得用好 LLM 的关键是提示词技巧。这种说法只对了一半。根据我的经验决定输出质量的第一因素是你给模型的上下文是否干净、准确、相关。你可以想象你临时拉了一个同事进来帮你干活。如果你只说“帮我看看这段代码有什么问题”同事大概率只能给你一些泛泛的建议。但如果你把这个功能的目的、相关接口的数据结构、你尝试过的方案、以及报错出现的时机都摆出来他能给出的建议就会非常有针对性。LLM 也是一样的道理。在把一个问题抛给 LLM 之前至少要确认下面这些信息是否有交代清楚你在用什么技术栈项目大概是什么结构。你正在解决的原始需求是什么不只是表面现象。你尝试过哪些方案得到的反馈是什么。输入数据长什么样有没有长度、格式、编码上的限制。错误信息完整内容是什么最好不是只有一行摘要。这时候你会发现自己也在被迫梳理问题。这本身就是一种收益。很多时候你一个问题如果能被自己写清楚答案已经浮出水面一半了。4.2 让输出可验证小步试、片段化、不批量合并LLM 生成代码很容易但生成代码可以被直接信任不容易。你越是把一个完整模块丢给它它越容易在某个你意想不到的地方引入错误。这不是模型能力不够而是因为代码的正确性依赖太多外部事实项目的代码规范、中间件的版本行为、历史接口的兼容逻辑、团队内部约定。这些信息模型看不到。所以我建议一个很朴素的落地方式把任务切片让 LLM 生成片段然后你来验证。比如一个数据处理流程可以拆成这几步第一步让 LLM 生成“读取输入文件并做基础校验”的函数。第二步你用一张小样本文件验证输出是否符合预期。第三步根据验证结果再让 LLM 补上“错误行收集和汇总报告”的部分。第四步每个片段都单独跑通后再串成完整流程。这种做法看起来不如“一口气生成整个文件”那么酷但它的好处非常实在每步都有明确的验证点出问题时问题范围被限制在一个很小的片段里你排查起来会非常快。反过来如果一次性生成几百行代码中间有任何一步出错你都需要在一大段代码里反复定位节约下来的时间瞬间又被赔进去。4.3 把有效对话沉淀成团队可复用的模板LLM 辅助开发还有一个容易被忽略的长期价值你可以把一次有效的合作过程沉淀成团队内部的模板或文档。比如你和 LLM 一起梳理出一份“新接口开发前的检查清单”里面有输入校验、异常返回、日志埋点、并发安全、历史兼容等常见问题。那么下一次开发新接口时你就没必要再从零开始问一遍 LLM直接把这份清单作为开发规范的一部分即可。如果团队里使用统一的代码生成规范你还可以把常见任务的要求写成项目级提示词让所有成员在使用 LLM 时都按同一套输入格式提供上下文。这样做的好处不是让所有人都变成提示词高手而是让大模型输出的稳定性有基线当你给它的输入结构是统一的它的输出质量也相对可控。这些沉淀内容不需要很复杂一个 50 行的 Markdown 文档就够了。重点是把“这次偶然跑通的经验”变成“下次可以复用的流程”。从这个角度看LLM 不仅是一个工具还是一个帮你把隐性经验外化出来的入口。5. 用错方式LLM 反而会让开发变慢5.1 常见的三种“打字员”式用法虽然我一直在强调 LLM 的真正价值在于处理模糊性但在真实环境中大多数人还是习惯性地把它当成打字员。常见的表现有三种。第一种是让 LLM 直接生成完整模块。例如“帮我写一个完整的用户管理系统”生成出来的代码乍一看很完整但和项目的现有架构、规范、依赖版本很可能不匹配。你还需要花大量时间改造成自己的风格结果比自己写还累。第二种是复制报错后不做筛选直接把一堆日志原文粘贴进去。LLM 可能会被大量无关信息带偏给出一个表面合理、实际无关的方向。问题是如果你对报错本身不够熟悉你甚至不知道它给你的方向是不是在胡扯。第三种是把 LLM 的输出当作最终答案不加 review 就提交。我在一些团队里看过这种协作方式开发速度好像快了但代码评审时发现大量边界漏判、异常没有处理、名称随意到完全不可维护。这些代码积累到一定程度就会变成新的技术债。5.2 为什么看似高效实际在积累技术债你可能会问LLM 生成的代码不也是代码吗为什么非要认为它在积累技术债关键在于技术债的本质不是“代码写得差”而是“对代码的理解没有跟上代码的产出速度”。当你自己手写一段代码时你会经历思考、查错、修改、验证的过程你对这段代码的行为和边界是有直接体感的。但当你直接从 LLM 那里拿到一大段代码时你并没有经历这个过程。你只看到了最终输出但不知道它为什么这样设计也不知道它绕过哪些坑。一旦这段代码上线后出问题你就需要花更多时间去逆向理解它。这时候你之前省下的时间不仅被加倍还了回去还可能搭上额外的维护成本。这就是很多团队觉得自己“用上 AI 了但项目越来越乱”的原因。不是 LLM 不可用而是协作模式出了问题。你把它当成快速产出工具它就会给你快速产出但没人给你快速理解、快速验证、快速修正的能力。5.3 排查链路LLM 输出不可用的时候先查哪里当你在实际使用中发现 LLM 给出的代码跑不通、或者建议明显偏离方向时不要急着说“这个工具没用”。我建议你按下面这条链路排查先看现象。是编译报错、运行报错、逻辑不正确还是根本没有达到需求预期不同现象对应的问题层级不同。再看输入。你给模型的上下文是否完整项目结构、技术栈、数据结构、报错全文是否有遗漏最常见的问题是上下文太片段化模型只能靠猜。再看提示方式。你是让它直接给最终答案还是让它先给你解释和候选方案如果一上来就要完整模块输出很容易失控。再看验证方法。你有没有对 LLM 给的一个小片段做单测或小样本验证如果直接把大段代码放进主干问题定位成本会非常高。最后看工具边界。你用的模型版本、上下文长度、插件配置是否支持你当前的任务如果任务是深度业务逻辑建模不要指望模型能替代你整理业务规则。这条链路不是每次都从第一步走到最后一步但它能帮你快速把问题归类是你不会用还是模型不行还是任务本身不适合。6. 一个可复用的“LLM 辅助开发”动作清单6.1 四步走澄清、拆解、验证、沉淀把上面这些讨论收拢一下我会建议你在开发流程里固化一套动作清单名字可以叫“澄清、拆解、验证、沉淀”。看起来没什么玄机但它能非常有效地避免你陷入“让 LLM 直接写代码”的陷阱。第一步澄清。在动手前先把需求文案、相关代码位置、已知约束、期望输出告诉 LLM并让它先列出所有需要确认的边界问题。这一阶段不要让它写代码。第二步拆解。把整个任务拆成若干可以独立验证的小任务。每个小任务都要有明确的输入、输出和验证标准。例如“读取 CSV 并返回行数”和“对每一行做字段校验”就是两个可以分开的任务。第三步验证。每生成一个片段先单独测试确认结果符合预期后再集成。不要让未经验证的片段堆积起来。第四步沉淀。把使用过程中有效的问题模板、检查清单、错误案例整理成文档。下次遇到相似任务时直接调用这套流程而不是重新摸索。这套动作不一定每步都严格执行但它给了你一个稳定框架。尤其是在任务复杂、需求模糊的时候它能避免你被 LLM 的流畅输出带走最终把节奏掌握在自己手里。6.2 适合用 LLM 的场景与不适合的场景我也必须给这套方法画一条边界LLM 不是所有开发环节都适合介入。适合的场景通常具备以下特征信息比较琐碎但不需要特别深的领域知识需要快速生成候选方案但没有严格的历史包袱错误信息不清晰需要有经验的人给出一个尝试方向文档和注释写完但不够完整需要快速补充解释。不适合的场景通常是这些涉及核心业务命脉的架构决策比如微服务拆分边界、数据库分库键选择涉及安全合规的权限校验逻辑不能只靠模型建议需要强一致性的业务规则比如金融计费、订单状态机、同步流程以及团队里已经形成了明确约定和规范的地方这时 LLM 的自由发挥反而会破坏一致性。用一句话概括LLM 适合处理“不明确但需要发散探索”的任务不适合处理“明确但错误代价极高”的任务。前者靠它提升效率后者靠你自己守住底线。6.3 回到“Cloudy development”这个起点现在再回头看文章标题How LLMs accelerated Cloudy development? not by typing code for me。我想它想说的正是这里讲的这件事LLM 真正加速的是开发里那些“云里雾里”的环节。它像一个能照亮雾的手电筒能帮你看到路的大致走向但手电筒不会替你把路走完更不会替你做决定。下次当你打开编辑器面对一个需求不知从何下手时别急着让 LLM 帮你写第一行代码。你可以先让它帮你把问题问清楚把边界摊开把两条可能路径的代价摆出来。你会发现当这片迷雾散去代码本身反而成了整个流程里最简单、最不需要花费心力的那一小步。这才是 LLM 给开发者带来的真正变化它不是绕过思考而是把思考中最模糊的那部分变成一幅可以被审视、被质疑、被确认的草图。而最终为它负责的仍然是你自己。