1. 为什么要把大语言模型当“人”来用1.1 一个被大多数人忽略的协作视角我刚开始接触大语言模型辅助开发那会儿和绝大多数人一样把它当成一个高级搜索引擎来使。遇到不熟的API就丢个问题过去看到报错就复制粘贴让它解释偶尔让它写个正则或者补全一段样板代码。用了一段时间之后效率确实有提升但总觉得哪里不对劲——它有时候很聪明有时候又笨得让人想砸键盘同一个问题换个问法结果天差地别。后来我换了个思路。我不再把它当成一个工具而是把它当成一个刚入职的新同事。这个新同事知识面极广学习能力极强但有几个特点第一它不了解我们项目的上下文第二它记性不太好聊久了容易忘前面说过什么第三它特别容易“顺着你说”你语气里带着什么倾向它就往那个方向靠。想明白这几点之后我的使用方式发生了根本性的变化开发效率也跟着上了一个台阶。这个视角转换听起来像是文字游戏但实际操作中带来的差异非常大。把大语言模型当人用意味着你要像对待一个真实协作者那样去管理预期、交代背景、明确需求、验收成果。这套方法论不只适用于写代码写文档、做技术方案、排查线上问题甚至做技术选型调研都能套用。1.2 适合哪些人参考这套方法如果你属于以下几类情况这套思路应该能帮到你日常开发中已经在大语言模型辅助下写代码但感觉效率提升遇到了瓶颈输出质量时好时坏团队里开始推行大语言模型辅助开发但大家各用各的没有形成可复用的协作模式需要大语言模型帮你处理复杂任务比如重构一个模块、设计一套接口、排查一个跨服务的问题而不是简单的代码补全对提示工程有一定了解但觉得那些技巧太零散想要一套更底层的协作框架。我下面要展开的这套方法核心就是把大语言模型当成一个“人”来协作围绕这个核心拆解出背景交代、任务拆解、反馈迭代、质量验收这几个关键环节。每个环节我都会给出具体的操作方式和实际案例你可以直接拿去用。2. 像带新人一样交代项目背景2.1 为什么背景信息比问题本身更重要带过新人的都知道一个新同事入职你不可能上来就让他改一个核心模块的bug。你得先告诉他这个项目是干什么的技术栈是什么代码规范有哪些模块之间的依赖关系是怎样的。缺少这些背景他就算技术再强改出来的东西也大概率不符合预期。大语言模型也是一样的。很多人用大语言模型效率低根本原因就是给的背景信息太少。你问它“这段代码为什么报错”它只能看到你贴出来的那几行不知道你的运行环境、依赖版本、业务逻辑给出的答案自然只能靠猜。但如果你把背景交代清楚它的输出质量会有质的飞跃。我自己的习惯是在开始一个稍微复杂一点的任务之前先花几分钟写一段“项目简报”。这段简报不需要多正式但要把几个关键信息说清楚项目是做什么的用什么语言和框架当前这个任务的上下文比如是在修bug还是在加功能相关的代码规范或团队约定你期望的输出形式是直接给代码还是先给思路再给代码。提示项目简报不需要每次重新写。你可以把它存成一个模板每次根据具体任务微调。我自己的模板大概两百字左右包含技术栈、代码风格、输出格式要求这三块用起来非常顺手。2.2 一个实际案例从“答非所问”到“一次到位”举个我印象很深的例子。有一次我需要写一个数据清洗的脚本输入是一批格式不太规范的CSV文件输出是清洗后的结构化数据。我第一次提问的时候只说了“帮我写一个Python脚本清洗CSV数据”结果它给了一个非常通用的方案用的库和我的环境不匹配异常处理也完全没考虑我的实际数据情况。第二次我换了个方式先交代背景“我有一个数据处理项目运行在Python 3.10环境下主要依赖pandas和numpy。输入数据是第三方提供的CSV文件存在以下问题列名不统一、日期格式混乱、部分数值列有缺失值。我需要一个清洗脚本输出为统一的DataFrame格式并且要记录清洗过程中的异常情况。”然后我再提具体要求“请先给出清洗思路确认后再写代码。代码风格要求函数式每个清洗步骤独立成一个函数方便单独测试。”这次它的输出就完全不一样了。它先列了一个清洗流程包括列名标准化、日期解析、缺失值处理、异常记录四个步骤每个步骤都给了具体的处理策略。我确认思路没问题之后它生成的代码结构清晰每个函数职责单一异常处理也考虑到了我提到的几种情况。整个过程只用了两轮对话比我第一次反复调整省了太多时间。这个案例说明的问题很直接大语言模型不缺能力缺的是上下文。你把上下文给足了它的表现会超出你的预期。2.3 背景交代的常见误区在交代背景这件事上我踩过几个坑这里列出来供你参考第一个误区是“背景给太多”。有些人会把整个项目的代码都贴进去觉得信息越全越好。但实际上大语言模型的处理窗口是有限的信息太多反而会稀释关键信息让它抓不住重点。正确的做法是只给与当前任务直接相关的背景其他的一律省略。第二个误区是“背景给太虚”。比如只说“这是一个Web项目”不说用的什么框架、什么版本、什么架构风格。这种背景等于没给它只能靠猜猜错了你还得重新来。第三个误区是“背景和任务混在一起”。有些人喜欢把背景和具体问题写在一段话里导致重点不突出。我的建议是分段写背景一段任务一段要求一段这样它更容易理解你的意图。3. 把大任务拆成它能接住的粒度3.1 为什么不能一次让它干太多带新人的时候你不会一次性把整个模块的开发任务丢给他而是会拆成一个个小任务完成一个验收一个。大语言模型也一样它的“工作记忆”有限任务太大太复杂它就容易顾此失彼输出的东西看起来什么都沾了一点但什么都不够深入。我见过很多人用大语言模型的方式是写一个特别长的提示把需求、约束、示例、输出格式全部塞进去然后期待它一次性给出完美结果。这种做法偶尔能成但大多数时候结果都不理想。原因很简单任务越复杂它需要同时考虑的因素就越多出错的概率就越大。正确的做法是任务拆解。把一个复杂任务拆成若干个它能够独立完成的子任务每个子任务都有明确的输入和输出完成一个再进行下一个。这样做的好处是每个子任务它都能集中注意力输出质量更高而且你可以在每个环节进行校验发现问题及时调整避免最后返工。3.2 任务拆解的三种实用模式根据我的经验任务拆解有三种模式比较实用分别适用于不同类型的开发场景。模式一按流程拆解。适用于有明确步骤的任务比如数据处理、接口开发、部署配置。你把整个流程拆成若干个阶段每个阶段让大语言模型完成一个步骤。比如一个数据管道任务可以拆成数据读取、数据清洗、数据转换、数据写入四个阶段每个阶段单独提问。模式二按模块拆解。适用于系统设计或重构任务。你把系统拆成若干个模块每个模块单独处理。比如重构一个用户管理模块可以拆成数据模型设计、接口定义、业务逻辑实现、单元测试四个模块逐个击破。模式三按难度拆解。适用于你不确定大语言模型能不能搞定的任务。你先让它做最简单的部分如果做得好再逐步增加难度。比如让它写一个复杂的算法你可以先让它写核心逻辑确认没问题后再让它补充边界处理和异常处理。这三种模式可以组合使用。我自己的习惯是先用流程拆解把大框架定下来然后在每个流程节点内部用模块拆解遇到不确定的地方用难度拆解来试探。3.3 拆解粒度怎么把握拆解粒度太粗大语言模型接不住拆解粒度太细你又得花大量时间在来回沟通上。那到底拆到什么程度比较合适我的经验判断标准是如果一个子任务你能用一句话说清楚输入和输出那这个粒度就差不多了。比如“把这段JSON转成Python字典”就是一个合适的粒度“设计一个完整的数据处理系统”就太粗了“把JSON的第一个字段取出来”又太细了。还有一个实用的判断方法如果你发现大语言模型在回答中开始“编造”你没提到的细节或者开始忽略你提到的某些约束那就说明任务粒度太粗了需要进一步拆解。注意拆解不是越细越好。过度拆解会导致你花在沟通上的时间超过你自己写代码的时间。一般来说一个中等复杂度的开发任务拆成三到五个子任务是比较合理的。4. 用“反馈-迭代”代替“一次成型”4.1 为什么第一版输出永远不是最终版带新人的时候你收到他的第一版代码肯定不会直接合并到主分支。你会review会提修改意见他会根据你的意见改改完你再review来回几轮之后才能达到可合并的状态。大语言模型协作也是同样的道理第一版输出永远只是起点不是终点。很多人用大语言模型效率低就是因为期待一次成型。第一版输出不满意就换一个问法重新问而不是在现有基础上提修改意见。这种做法相当于每次都在重新开始浪费了大量已经积累的上下文。正确的做法是把第一版输出当作草稿然后像review代码一样逐条提出修改意见。大语言模型非常擅长根据反馈进行迭代修改你提的意见越具体它改得越到位。4.2 怎么提反馈才有效提反馈这件事也是有技巧的。我总结了几条原则原则一具体到行不要笼统。不要说“这段代码写得不好”而要说“第15行的异常处理太宽泛了请改成只捕获ValueError并且记录具体的错误信息”。笼统的反馈它不知道该怎么改具体的反馈它一改一个准。原则二一次只提一类问题。不要一次性把代码风格、逻辑错误、性能问题全部提出来它会顾此失彼。先解决逻辑问题再解决风格问题最后解决性能问题一轮一轮来。原则三给出修改的理由。你告诉它为什么要改它下次遇到类似情况就会注意。比如你说“这个函数太长了请拆成两个因为团队规范要求单个函数不超过50行”它下次生成代码时就会主动控制函数长度。原则四确认理解再修改。对于复杂的修改意见先让它复述一遍你的要求确认它理解对了再让它动手改。这一步多花三十秒能省掉后面大量的返工时间。4.3 迭代过程中的上下文管理迭代次数多了之后对话会变得很长大语言模型可能会“忘记”前面的内容。这时候需要做一些上下文管理。我的做法是每迭代三到五轮之后让它把当前的状态总结一下包括已经完成了什么、还有什么问题、下一步要做什么。这个总结会成为后续对话的“锚点”帮助它保持对整体任务的记忆。另外如果对话实在太长我会把关键信息提取出来开一个新的对话把总结和关键代码贴进去继续迭代。这样做虽然会损失一些细节但能保证它始终在最佳状态下工作。提示大语言模型的“记忆”是有限的不要指望它记住几十轮之前的每一句话。定期总结和重置上下文是保持输出质量稳定的关键。5. 验收环节不能省5.1 为什么必须像review代码一样review它的输出大语言模型有一个特点它输出的东西看起来总是很有道理语法正确、格式工整、逻辑自洽但仔细一看可能藏着各种问题。变量名拼错了、边界条件没处理、引用了不存在的函数、逻辑上有一个微妙的错误——这些问题它自己往往发现不了需要你来把关。我见过太多人因为大语言模型输出看起来“很像那么回事”就直接用了结果在运行时才发现问题排查起来比自己去写还费时间。所以验收环节绝对不能省而且要像review同事的代码一样认真。5.2 验收清单我每次都会检查的五个点经过大量实践我总结了一个验收清单每次大语言模型输出代码后我都会对照检查检查项具体内容常见问题逻辑正确性核心逻辑是否符合需求边界条件是否处理缺少空值判断、循环边界错误依赖可用性引用的库和函数是否真实存在版本是否匹配引用了不存在的API、版本不兼容错误处理异常捕获是否合理错误信息是否有用捕获过于宽泛、错误信息缺失代码风格是否符合团队规范命名是否清晰命名随意、函数过长安全性是否有明显的安全漏洞输入未校验、敏感信息硬编码这个清单看起来简单但每一条都能帮你避免实际开发中的坑。尤其是“依赖可用性”这一条大语言模型有时候会“编造”一些看起来合理但实际上不存在的函数或参数不检查的话运行起来就会报错。5.3 验收之后做什么验收发现问题之后不要自己直接改而是把问题反馈给大语言模型让它改。这样做有两个好处一是它改的版本通常比你手改的更一致二是它能从反馈中学习后续输出质量会逐步提升。如果验收通过也不要急着结束。我通常会做两件事第一让它把最终版本的代码和关键决策记录一下方便后续查阅第二让它基于当前代码生成单元测试确保后续修改不会破坏现有功能。这两步花不了多少时间但能帮你建立起一个可维护的代码基础。尤其是单元测试大语言模型生成测试用例的效率非常高你只需要检查测试逻辑是否正确就行。6. 几个实战场景的完整拆解6.1 场景一接手一个陌生模块的改造假设你刚接手一个陌生模块需要在不了解全部细节的情况下完成一个改造任务。传统的做法是花大量时间读代码然后动手改。用大语言模型协作的做法是这样的第一步把模块的核心文件贴给它让它帮你梳理模块的结构和依赖关系。这一步相当于让一个新同事帮你做代码走读它能快速给你一个整体视图。第二步基于梳理结果让它分析改造任务涉及哪些文件和函数给出一个改造方案。你确认方案后再让它逐个文件生成修改建议。第三步你按照修改建议逐个文件进行修改每改完一个就让它review一遍确认没有引入新问题。这个流程走下来原本可能需要半天到一天的改造任务压缩到两三个小时就能完成而且你对模块的理解也会更深入。6.2 场景二排查一个跨服务的线上问题线上问题排查往往涉及多个服务日志分散排查起来很费时间。用大语言模型协作的做法是先把相关服务的日志片段贴给它让它帮你找出异常模式。然后把相关的代码片段也贴给它让它分析可能的根因。最后让它给出排查步骤和验证方法。这里的关键是你要把日志和代码的对应关系说清楚比如“这段日志来自服务A的订单处理流程对应的代码是下面这段”。它有了这个对应关系分析起来就准确得多。6.3 场景三从零搭建一个小型工具从零搭建工具是最适合大语言模型协作的场景。我的做法是先让它给出技术选型建议和整体架构你确认后让它生成项目骨架。然后逐个模块实现每个模块完成后立即验收和测试。最后让它生成使用文档和部署说明。整个过程你更像是一个技术负责人负责决策和验收具体的编码工作交给它来完成。这种协作模式下一个小型工具从想法到可用版本通常一两天就能搞定。7. 常见问题与避坑指南7.1 它总是“顺着我说”怎么办这是大语言模型的一个典型特点你语气里带着什么倾向它就往那个方向靠。你说“我觉得这个方案有问题”它就会顺着你说这个方案哪里不好你说“这个方案应该没问题吧”它就会说确实没问题。应对方法很简单在提问时保持中立不要预设结论。不要问“这个方案是不是有问题”而是问“请分析这个方案的优缺点并给出你的判断”。让它先给出独立分析你再根据分析做决策。如果它已经顺着你说了你可以反过来问“如果我告诉你这个方案其实是错的你能找出哪些支持这个判断的理由”这种反向提问能帮你获得更全面的视角。7.2 输出质量不稳定怎么破同一个问题不同时间问得到的答案质量可能差别很大。这是大语言模型的固有特性没法完全消除但可以通过一些方法降低波动固定你的提问模板减少变量在提问中明确输出格式和质量要求对重要任务让它生成多个版本你从中挑选或融合如果某次输出特别差不要纠缠重新开一个对话把关键背景重新交代一遍。7.3 怎么判断它是不是在“胡说”大语言模型有时候会“编造”一些看起来合理但实际上错误的信息尤其是在涉及具体API、库函数、版本特性的时候。判断方法有几个对于它提到的具体函数或参数去官方文档核实对于它给出的数据或结论交叉验证对于它生成的代码实际运行测试如果它说得特别肯定但你又没听说过大概率是编的。注意大语言模型在“知道自己不知道”这件事上表现很差。它不会说“我不确定”而是会编一个看起来合理的答案。所以对于关键信息永远要核实。7.4 对话太长导致质量下降怎么办对话轮次多了之后大语言模型会开始“遗忘”前面的内容输出质量明显下降。这时候不要硬撑果断重置。重置的方法是让它把当前状态总结一下包括任务目标、已完成部分、待办事项、关键决策。然后开一个新对话把总结贴进去继续工作。这样虽然损失了一些细节但能保证后续输出质量。我自己的习惯是每完成一个子任务就做一次总结和重置保持对话始终在“新鲜”状态。8. 我个人的一些使用心得把大语言模型当人用这套方法我实践了挺长时间有几个心得想分享一下。第一个心得是耐心比技巧重要。很多人用大语言模型没耐心第一版输出不满意就换工具、换问法结果一直在原地打转。其实只要你耐心地给背景、拆任务、提反馈它的输出质量会随着对话的深入逐步提升。我很多高质量的输出都是在第五轮、第六轮迭代之后才出现的。第二个心得是你的技术判断力才是核心。大语言模型可以帮你写代码、分析问题、生成方案但它不能替你做技术决策。哪个方案更好、哪个取舍更合理、哪个风险可以接受这些都需要你自己的技术判断。把大语言模型当人用意味着你是那个做决策的人它是那个执行的人。第三个心得是建立自己的提示模板库。我在实践中积累了一套提示模板针对不同类型的任务有不同的模板。比如代码review模板、方案设计模板、问题排查模板。每次遇到类似任务直接套模板省去了大量组织语言的时间。第四个心得是不要用它替代思考。大语言模型最危险的使用方式是让它替你思考。你可以让它帮你整理思路、提供参考、检查遗漏但核心的思考过程必须你自己完成。一旦你开始依赖它来告诉你“该怎么做”你的技术能力就会开始退化。这套方法说到底核心就一句话把大语言模型当成一个能力强但需要引导的协作者而不是一个万能的黑盒工具。你投入在背景交代、任务拆解、反馈迭代上的时间都会以输出质量的提升回报给你。
1. 为什么要把大语言模型当“人”来用1.1 一个被大多数人忽略的协作视角我刚开始接触大语言模型辅助开发那会儿和绝大多数人一样把它当成一个高级搜索引擎来使。遇到不熟的API就丢个问题过去看到报错就复制粘贴让它解释偶尔让它写个正则或者补全一段样板代码。用了一段时间之后效率确实有提升但总觉得哪里不对劲——它有时候很聪明有时候又笨得让人想砸键盘同一个问题换个问法结果天差地别。后来我换了个思路。我不再把它当成一个工具而是把它当成一个刚入职的新同事。这个新同事知识面极广学习能力极强但有几个特点第一它不了解我们项目的上下文第二它记性不太好聊久了容易忘前面说过什么第三它特别容易“顺着你说”你语气里带着什么倾向它就往那个方向靠。想明白这几点之后我的使用方式发生了根本性的变化开发效率也跟着上了一个台阶。这个视角转换听起来像是文字游戏但实际操作中带来的差异非常大。把大语言模型当人用意味着你要像对待一个真实协作者那样去管理预期、交代背景、明确需求、验收成果。这套方法论不只适用于写代码写文档、做技术方案、排查线上问题甚至做技术选型调研都能套用。1.2 适合哪些人参考这套方法如果你属于以下几类情况这套思路应该能帮到你日常开发中已经在大语言模型辅助下写代码但感觉效率提升遇到了瓶颈输出质量时好时坏团队里开始推行大语言模型辅助开发但大家各用各的没有形成可复用的协作模式需要大语言模型帮你处理复杂任务比如重构一个模块、设计一套接口、排查一个跨服务的问题而不是简单的代码补全对提示工程有一定了解但觉得那些技巧太零散想要一套更底层的协作框架。我下面要展开的这套方法核心就是把大语言模型当成一个“人”来协作围绕这个核心拆解出背景交代、任务拆解、反馈迭代、质量验收这几个关键环节。每个环节我都会给出具体的操作方式和实际案例你可以直接拿去用。2. 像带新人一样交代项目背景2.1 为什么背景信息比问题本身更重要带过新人的都知道一个新同事入职你不可能上来就让他改一个核心模块的bug。你得先告诉他这个项目是干什么的技术栈是什么代码规范有哪些模块之间的依赖关系是怎样的。缺少这些背景他就算技术再强改出来的东西也大概率不符合预期。大语言模型也是一样的。很多人用大语言模型效率低根本原因就是给的背景信息太少。你问它“这段代码为什么报错”它只能看到你贴出来的那几行不知道你的运行环境、依赖版本、业务逻辑给出的答案自然只能靠猜。但如果你把背景交代清楚它的输出质量会有质的飞跃。我自己的习惯是在开始一个稍微复杂一点的任务之前先花几分钟写一段“项目简报”。这段简报不需要多正式但要把几个关键信息说清楚项目是做什么的用什么语言和框架当前这个任务的上下文比如是在修bug还是在加功能相关的代码规范或团队约定你期望的输出形式是直接给代码还是先给思路再给代码。提示项目简报不需要每次重新写。你可以把它存成一个模板每次根据具体任务微调。我自己的模板大概两百字左右包含技术栈、代码风格、输出格式要求这三块用起来非常顺手。2.2 一个实际案例从“答非所问”到“一次到位”举个我印象很深的例子。有一次我需要写一个数据清洗的脚本输入是一批格式不太规范的CSV文件输出是清洗后的结构化数据。我第一次提问的时候只说了“帮我写一个Python脚本清洗CSV数据”结果它给了一个非常通用的方案用的库和我的环境不匹配异常处理也完全没考虑我的实际数据情况。第二次我换了个方式先交代背景“我有一个数据处理项目运行在Python 3.10环境下主要依赖pandas和numpy。输入数据是第三方提供的CSV文件存在以下问题列名不统一、日期格式混乱、部分数值列有缺失值。我需要一个清洗脚本输出为统一的DataFrame格式并且要记录清洗过程中的异常情况。”然后我再提具体要求“请先给出清洗思路确认后再写代码。代码风格要求函数式每个清洗步骤独立成一个函数方便单独测试。”这次它的输出就完全不一样了。它先列了一个清洗流程包括列名标准化、日期解析、缺失值处理、异常记录四个步骤每个步骤都给了具体的处理策略。我确认思路没问题之后它生成的代码结构清晰每个函数职责单一异常处理也考虑到了我提到的几种情况。整个过程只用了两轮对话比我第一次反复调整省了太多时间。这个案例说明的问题很直接大语言模型不缺能力缺的是上下文。你把上下文给足了它的表现会超出你的预期。2.3 背景交代的常见误区在交代背景这件事上我踩过几个坑这里列出来供你参考第一个误区是“背景给太多”。有些人会把整个项目的代码都贴进去觉得信息越全越好。但实际上大语言模型的处理窗口是有限的信息太多反而会稀释关键信息让它抓不住重点。正确的做法是只给与当前任务直接相关的背景其他的一律省略。第二个误区是“背景给太虚”。比如只说“这是一个Web项目”不说用的什么框架、什么版本、什么架构风格。这种背景等于没给它只能靠猜猜错了你还得重新来。第三个误区是“背景和任务混在一起”。有些人喜欢把背景和具体问题写在一段话里导致重点不突出。我的建议是分段写背景一段任务一段要求一段这样它更容易理解你的意图。3. 把大任务拆成它能接住的粒度3.1 为什么不能一次让它干太多带新人的时候你不会一次性把整个模块的开发任务丢给他而是会拆成一个个小任务完成一个验收一个。大语言模型也一样它的“工作记忆”有限任务太大太复杂它就容易顾此失彼输出的东西看起来什么都沾了一点但什么都不够深入。我见过很多人用大语言模型的方式是写一个特别长的提示把需求、约束、示例、输出格式全部塞进去然后期待它一次性给出完美结果。这种做法偶尔能成但大多数时候结果都不理想。原因很简单任务越复杂它需要同时考虑的因素就越多出错的概率就越大。正确的做法是任务拆解。把一个复杂任务拆成若干个它能够独立完成的子任务每个子任务都有明确的输入和输出完成一个再进行下一个。这样做的好处是每个子任务它都能集中注意力输出质量更高而且你可以在每个环节进行校验发现问题及时调整避免最后返工。3.2 任务拆解的三种实用模式根据我的经验任务拆解有三种模式比较实用分别适用于不同类型的开发场景。模式一按流程拆解。适用于有明确步骤的任务比如数据处理、接口开发、部署配置。你把整个流程拆成若干个阶段每个阶段让大语言模型完成一个步骤。比如一个数据管道任务可以拆成数据读取、数据清洗、数据转换、数据写入四个阶段每个阶段单独提问。模式二按模块拆解。适用于系统设计或重构任务。你把系统拆成若干个模块每个模块单独处理。比如重构一个用户管理模块可以拆成数据模型设计、接口定义、业务逻辑实现、单元测试四个模块逐个击破。模式三按难度拆解。适用于你不确定大语言模型能不能搞定的任务。你先让它做最简单的部分如果做得好再逐步增加难度。比如让它写一个复杂的算法你可以先让它写核心逻辑确认没问题后再让它补充边界处理和异常处理。这三种模式可以组合使用。我自己的习惯是先用流程拆解把大框架定下来然后在每个流程节点内部用模块拆解遇到不确定的地方用难度拆解来试探。3.3 拆解粒度怎么把握拆解粒度太粗大语言模型接不住拆解粒度太细你又得花大量时间在来回沟通上。那到底拆到什么程度比较合适我的经验判断标准是如果一个子任务你能用一句话说清楚输入和输出那这个粒度就差不多了。比如“把这段JSON转成Python字典”就是一个合适的粒度“设计一个完整的数据处理系统”就太粗了“把JSON的第一个字段取出来”又太细了。还有一个实用的判断方法如果你发现大语言模型在回答中开始“编造”你没提到的细节或者开始忽略你提到的某些约束那就说明任务粒度太粗了需要进一步拆解。注意拆解不是越细越好。过度拆解会导致你花在沟通上的时间超过你自己写代码的时间。一般来说一个中等复杂度的开发任务拆成三到五个子任务是比较合理的。4. 用“反馈-迭代”代替“一次成型”4.1 为什么第一版输出永远不是最终版带新人的时候你收到他的第一版代码肯定不会直接合并到主分支。你会review会提修改意见他会根据你的意见改改完你再review来回几轮之后才能达到可合并的状态。大语言模型协作也是同样的道理第一版输出永远只是起点不是终点。很多人用大语言模型效率低就是因为期待一次成型。第一版输出不满意就换一个问法重新问而不是在现有基础上提修改意见。这种做法相当于每次都在重新开始浪费了大量已经积累的上下文。正确的做法是把第一版输出当作草稿然后像review代码一样逐条提出修改意见。大语言模型非常擅长根据反馈进行迭代修改你提的意见越具体它改得越到位。4.2 怎么提反馈才有效提反馈这件事也是有技巧的。我总结了几条原则原则一具体到行不要笼统。不要说“这段代码写得不好”而要说“第15行的异常处理太宽泛了请改成只捕获ValueError并且记录具体的错误信息”。笼统的反馈它不知道该怎么改具体的反馈它一改一个准。原则二一次只提一类问题。不要一次性把代码风格、逻辑错误、性能问题全部提出来它会顾此失彼。先解决逻辑问题再解决风格问题最后解决性能问题一轮一轮来。原则三给出修改的理由。你告诉它为什么要改它下次遇到类似情况就会注意。比如你说“这个函数太长了请拆成两个因为团队规范要求单个函数不超过50行”它下次生成代码时就会主动控制函数长度。原则四确认理解再修改。对于复杂的修改意见先让它复述一遍你的要求确认它理解对了再让它动手改。这一步多花三十秒能省掉后面大量的返工时间。4.3 迭代过程中的上下文管理迭代次数多了之后对话会变得很长大语言模型可能会“忘记”前面的内容。这时候需要做一些上下文管理。我的做法是每迭代三到五轮之后让它把当前的状态总结一下包括已经完成了什么、还有什么问题、下一步要做什么。这个总结会成为后续对话的“锚点”帮助它保持对整体任务的记忆。另外如果对话实在太长我会把关键信息提取出来开一个新的对话把总结和关键代码贴进去继续迭代。这样做虽然会损失一些细节但能保证它始终在最佳状态下工作。提示大语言模型的“记忆”是有限的不要指望它记住几十轮之前的每一句话。定期总结和重置上下文是保持输出质量稳定的关键。5. 验收环节不能省5.1 为什么必须像review代码一样review它的输出大语言模型有一个特点它输出的东西看起来总是很有道理语法正确、格式工整、逻辑自洽但仔细一看可能藏着各种问题。变量名拼错了、边界条件没处理、引用了不存在的函数、逻辑上有一个微妙的错误——这些问题它自己往往发现不了需要你来把关。我见过太多人因为大语言模型输出看起来“很像那么回事”就直接用了结果在运行时才发现问题排查起来比自己去写还费时间。所以验收环节绝对不能省而且要像review同事的代码一样认真。5.2 验收清单我每次都会检查的五个点经过大量实践我总结了一个验收清单每次大语言模型输出代码后我都会对照检查检查项具体内容常见问题逻辑正确性核心逻辑是否符合需求边界条件是否处理缺少空值判断、循环边界错误依赖可用性引用的库和函数是否真实存在版本是否匹配引用了不存在的API、版本不兼容错误处理异常捕获是否合理错误信息是否有用捕获过于宽泛、错误信息缺失代码风格是否符合团队规范命名是否清晰命名随意、函数过长安全性是否有明显的安全漏洞输入未校验、敏感信息硬编码这个清单看起来简单但每一条都能帮你避免实际开发中的坑。尤其是“依赖可用性”这一条大语言模型有时候会“编造”一些看起来合理但实际上不存在的函数或参数不检查的话运行起来就会报错。5.3 验收之后做什么验收发现问题之后不要自己直接改而是把问题反馈给大语言模型让它改。这样做有两个好处一是它改的版本通常比你手改的更一致二是它能从反馈中学习后续输出质量会逐步提升。如果验收通过也不要急着结束。我通常会做两件事第一让它把最终版本的代码和关键决策记录一下方便后续查阅第二让它基于当前代码生成单元测试确保后续修改不会破坏现有功能。这两步花不了多少时间但能帮你建立起一个可维护的代码基础。尤其是单元测试大语言模型生成测试用例的效率非常高你只需要检查测试逻辑是否正确就行。6. 几个实战场景的完整拆解6.1 场景一接手一个陌生模块的改造假设你刚接手一个陌生模块需要在不了解全部细节的情况下完成一个改造任务。传统的做法是花大量时间读代码然后动手改。用大语言模型协作的做法是这样的第一步把模块的核心文件贴给它让它帮你梳理模块的结构和依赖关系。这一步相当于让一个新同事帮你做代码走读它能快速给你一个整体视图。第二步基于梳理结果让它分析改造任务涉及哪些文件和函数给出一个改造方案。你确认方案后再让它逐个文件生成修改建议。第三步你按照修改建议逐个文件进行修改每改完一个就让它review一遍确认没有引入新问题。这个流程走下来原本可能需要半天到一天的改造任务压缩到两三个小时就能完成而且你对模块的理解也会更深入。6.2 场景二排查一个跨服务的线上问题线上问题排查往往涉及多个服务日志分散排查起来很费时间。用大语言模型协作的做法是先把相关服务的日志片段贴给它让它帮你找出异常模式。然后把相关的代码片段也贴给它让它分析可能的根因。最后让它给出排查步骤和验证方法。这里的关键是你要把日志和代码的对应关系说清楚比如“这段日志来自服务A的订单处理流程对应的代码是下面这段”。它有了这个对应关系分析起来就准确得多。6.3 场景三从零搭建一个小型工具从零搭建工具是最适合大语言模型协作的场景。我的做法是先让它给出技术选型建议和整体架构你确认后让它生成项目骨架。然后逐个模块实现每个模块完成后立即验收和测试。最后让它生成使用文档和部署说明。整个过程你更像是一个技术负责人负责决策和验收具体的编码工作交给它来完成。这种协作模式下一个小型工具从想法到可用版本通常一两天就能搞定。7. 常见问题与避坑指南7.1 它总是“顺着我说”怎么办这是大语言模型的一个典型特点你语气里带着什么倾向它就往那个方向靠。你说“我觉得这个方案有问题”它就会顺着你说这个方案哪里不好你说“这个方案应该没问题吧”它就会说确实没问题。应对方法很简单在提问时保持中立不要预设结论。不要问“这个方案是不是有问题”而是问“请分析这个方案的优缺点并给出你的判断”。让它先给出独立分析你再根据分析做决策。如果它已经顺着你说了你可以反过来问“如果我告诉你这个方案其实是错的你能找出哪些支持这个判断的理由”这种反向提问能帮你获得更全面的视角。7.2 输出质量不稳定怎么破同一个问题不同时间问得到的答案质量可能差别很大。这是大语言模型的固有特性没法完全消除但可以通过一些方法降低波动固定你的提问模板减少变量在提问中明确输出格式和质量要求对重要任务让它生成多个版本你从中挑选或融合如果某次输出特别差不要纠缠重新开一个对话把关键背景重新交代一遍。7.3 怎么判断它是不是在“胡说”大语言模型有时候会“编造”一些看起来合理但实际上错误的信息尤其是在涉及具体API、库函数、版本特性的时候。判断方法有几个对于它提到的具体函数或参数去官方文档核实对于它给出的数据或结论交叉验证对于它生成的代码实际运行测试如果它说得特别肯定但你又没听说过大概率是编的。注意大语言模型在“知道自己不知道”这件事上表现很差。它不会说“我不确定”而是会编一个看起来合理的答案。所以对于关键信息永远要核实。7.4 对话太长导致质量下降怎么办对话轮次多了之后大语言模型会开始“遗忘”前面的内容输出质量明显下降。这时候不要硬撑果断重置。重置的方法是让它把当前状态总结一下包括任务目标、已完成部分、待办事项、关键决策。然后开一个新对话把总结贴进去继续工作。这样虽然损失了一些细节但能保证后续输出质量。我自己的习惯是每完成一个子任务就做一次总结和重置保持对话始终在“新鲜”状态。8. 我个人的一些使用心得把大语言模型当人用这套方法我实践了挺长时间有几个心得想分享一下。第一个心得是耐心比技巧重要。很多人用大语言模型没耐心第一版输出不满意就换工具、换问法结果一直在原地打转。其实只要你耐心地给背景、拆任务、提反馈它的输出质量会随着对话的深入逐步提升。我很多高质量的输出都是在第五轮、第六轮迭代之后才出现的。第二个心得是你的技术判断力才是核心。大语言模型可以帮你写代码、分析问题、生成方案但它不能替你做技术决策。哪个方案更好、哪个取舍更合理、哪个风险可以接受这些都需要你自己的技术判断。把大语言模型当人用意味着你是那个做决策的人它是那个执行的人。第三个心得是建立自己的提示模板库。我在实践中积累了一套提示模板针对不同类型的任务有不同的模板。比如代码review模板、方案设计模板、问题排查模板。每次遇到类似任务直接套模板省去了大量组织语言的时间。第四个心得是不要用它替代思考。大语言模型最危险的使用方式是让它替你思考。你可以让它帮你整理思路、提供参考、检查遗漏但核心的思考过程必须你自己完成。一旦你开始依赖它来告诉你“该怎么做”你的技术能力就会开始退化。这套方法说到底核心就一句话把大语言模型当成一个能力强但需要引导的协作者而不是一个万能的黑盒工具。你投入在背景交代、任务拆解、反馈迭代上的时间都会以输出质量的提升回报给你。
