AI编程新体验：InternLM2-Chat-1.8B结对编程实战演示

AI编程新体验InternLM2-Chat-1.8B结对编程实战演示1. 引言你有没有过这样的经历深夜对着屏幕想写一个功能思路卡壳身边又没人可以讨论。或者写了一段代码总觉得哪里不对劲但又说不出来。这时候如果有一个随时在线、思路清晰的编程伙伴那该多好。今天我们就来体验一下这种全新的编程方式。我找来了InternLM2-Chat-1.8B模型让它扮演我的“结对编程”搭档。我们一起来完成一个具体的编程任务用Python写一个递归遍历目录并统计文件类型的脚本。这不是一次简单的代码生成演示而是一场真实的、交互式的编程对话。我会像和真人搭档一样向它提出需求讨论实现思路让它写代码然后对代码提出疑问再让它修改优化。整个过程你会看到AI如何理解问题、如何思考、如何回应反馈以及最终如何交付一个可用的解决方案。准备好了吗让我们开始这场特别的编程协作。2. 任务设定与开场我决定从一个非常具体且常见的需求入手统计一个文件夹及其所有子文件夹中各种类型文件的数量。比如一个项目目录里有多少个.py文件、多少个.txt文件、多少个图片文件等等。这个需求看似简单但涉及文件系统操作、递归逻辑和数据结构统计很适合检验AI的编程协作能力。我打开了与InternLM2-Chat-1.8B的对话窗口输入了我们的第一个“用户故事”我开发者你好我需要写一个Python脚本。它的功能是递归遍历一个指定的目录统计该目录下包括所有子目录各种文件类型的数量并输出一个清晰的统计报告。你能帮我一步步实现吗AI结对伙伴当然可以。这是一个很实用的功能。我们可以分步来实现它。首先我们需要明确几个关键点输入脚本需要接收一个目录路径作为参数。核心逻辑递归遍历目录树收集所有文件的扩展名。统计对扩展名进行计数。输出将统计结果以易读的方式打印出来。我们先从最核心的递归遍历和文件收集开始写你觉得怎么样看它没有直接扔给我一大段代码而是先梳理了需求并提出了一个实现框架。这种“先讨论再动手”的方式正是结对编程的精髓。我同意了它的建议。3. 第一轮迭代核心遍历与统计基于我们达成的共识AI输出了第一版代码。import os from collections import defaultdict def count_file_types(directory_path): 递归统计目录中各类文件的数量。 Args: directory_path (str): 要统计的根目录路径。 Returns: dict: 一个字典键为文件扩展名如 .txt值为该类型文件的数量。 type_count defaultdict(int) for root, dirs, files in os.walk(directory_path): for file in files: # 获取文件扩展名并将其转换为小写以确保统计一致性如.TXT和.txt视为同一种 _, ext os.path.splitext(file) ext ext.lower() # 对于没有扩展名的文件将其归类为‘无扩展名’ if not ext: ext ‘no_extension’ type_count[ext] 1 return type_count if __name__ __main__: target_dir input(请输入要统计的目录路径: ).strip() if os.path.isdir(target_dir): result count_file_types(target_dir) print(\n文件类型统计结果) for ext, count in sorted(result.items()): print(f {ext}: {count} 个) else: print(错误输入的路径不是一个有效的目录。)代码看起来干净利落。它使用了os.walk来优雅地处理递归遍历用defaultdict(int)来简化计数逻辑还考虑到了文件扩展名大小写统一和无扩展名文件的情况。注释也写得清晰明了。我运行了一下针对我的一个测试目录它输出了类似这样的结果文件类型统计结果 .py: 15 个 .txt: 8 个 .md: 3 个 .jpg: 5 个 no_extension: 2 个功能基本实现了。但作为一个挑剔的“搭档”我觉得还有优化空间。于是我提出了第一轮反馈。4. 交互与优化让输出更友好我开发者代码运行得很好核心功能没问题。不过输出结果可以更友好一些吗比如把‘.py’显示为‘Python文件’把‘no_extension’显示为‘无扩展名文件’。另外能不能按文件数量从多到少排序这样我一眼就能看出哪种文件最多。AI结对伙伴很好的建议让输出更人性化确实能提升使用体验。我们可以创建一个扩展名到类型描述的映射字典。对于未知的扩展名可以保留原样。排序也很简单。我来修改一下输出部分的代码。很快它给出了修改后的版本主要更新了if __name__ “__main__”:部分# ... (count_file_types函数保持不变) ... if __name__ __main__: # 定义一个扩展名到友好名称的映射可根据需要扩充 friendly_names { ‘.py’: ‘Python文件’, ‘.txt’: ‘文本文件’, ‘.md’: ‘Markdown文件’, ‘.jpg’: ‘JPEG图像’, ‘.png’: ‘PNG图像’, ‘.pdf’: ‘PDF文档’, ‘.zip’: ‘ZIP压缩包’, ‘no_extension’: ‘无扩展名文件’ } target_dir input(请输入要统计的目录路径: ).strip() if os.path.isdir(target_dir): result count_file_types(target_dir) # 按文件数量降序排序 sorted_items sorted(result.items(), keylambda x: x[1], reverseTrue) print(f\n目录 ‘{target_dir}‘ 下的文件类型统计按数量降序) print(- * 50) total_files sum(result.values()) for ext, count in sorted_items: # 获取友好名称如果没有映射则使用扩展名本身 name friendly_names.get(ext, ext) print(f {name:20} {count:4d} 个) print(- * 50) print(f 文件总数{total_files} 个) else: print(错误输入的路径不是一个有效的目录。)再次运行输出变成了目录 ‘./my_project‘ 下的文件类型统计按数量降序 -------------------------------------------------- Python文件 15 个 文本文件 8 个 JPEG图像 5 个 Markdown文件 3 个 .log 2 个 无扩展名文件 2 个 -------------------------------------------------- 文件总数35 个这下看起来专业多了不仅排序了还有了友好的类型名称、分隔线和总计。对于映射表中没有的扩展名如.log它也做了回退处理直接显示扩展名。5. 深度探讨处理隐藏文件与性能考量代码已经很好用了但我想把这次结对编程推向更深层次的讨论看看AI能否处理一些边界情况和工程问题。我开发者很棒现在输出清晰多了。我还有两个问题想探讨有些系统文件或隐藏文件比如以点开头的.gitignore可能我不需要统计。能否增加一个过滤选项如果遍历一个非常大的目录比如整个硬盘这个脚本可能会占用较多内存因为os.walk是一次性遍历的。有没有更节省内存的迭代方式AI结对伙伴这两个都是非常实际的工程问题。过滤隐藏文件我们可以修改遍历逻辑在统计前检查文件名。在Unix/Linux系统中隐藏文件通常以点开头。我们可以添加一个参数来控制是否跳过它们。内存优化os.walk默认是自顶向下的生成器它本身不会一次性将所有结果加载到内存。但在极端深的目录树下dirs和files列表可能会比较大。更节省内存的方式是使用os.scandir()自己写递归它可以提供更高效的文件属性访问并且我们可以更精细地控制遍历过程。为了平衡代码复杂性和实用性我们先实现隐藏文件过滤功能。如果需要处理超大规模目录我们可以再重构为基于os.scandir的递归。你觉得这样可以吗我同意了它的分析。先解决过滤问题。它随后给出了增强版的count_file_types函数def count_file_types(directory_path, ignore_hiddenTrue): 递归统计目录中各类文件的数量。 Args: directory_path (str): 要统计的根目录路径。 ignore_hidden (bool): 是否忽略以点‘.’开头的隐藏文件。默认为True。 Returns: dict: 一个字典键为文件扩展名如 ‘.txt‘值为该类型文件的数量。 type_count defaultdict(int) for root, dirs, files in os.walk(directory_path): for file in files: # 如果启用忽略隐藏文件且文件名以点开头则跳过 if ignore_hidden and file.startswith(‘.’): continue _, ext os.path.splitext(file) ext ext.lower() if not ext: ext ‘no_extension’ type_count[ext] 1 return type_count它增加了一个ignore_hidden参数并在循环中增加了相应的判断逻辑。主程序调用时可以传入这个参数。这个改动简单而有效。关于第二个性能问题AI虽然没有直接重写代码但它清晰地解释了os.walk与os.scandir的差异并给出了一个简化的伪代码思路说明如何用后者实现更手动的、可能更省内存的递归。这表明它不仅能写代码还能理解不同方案背后的权衡。6. 最终成果与体验总结经过几轮交互我们得到了一个功能完善、输出友好、且考虑了一定边界情况的脚本。这场结对编程会话也接近尾声。我开发者非常感谢经过这几轮修改这个脚本已经完全满足我的需求了甚至比我想的还要周到。这次合作很愉快。AI结对伙伴不客气能帮到你很高兴。这个脚本现在具备了核心统计、友好输出、隐藏文件过滤等功能。如果你将来需要处理超大规模目录或者想增加按文件大小统计、过滤特定目录等功能我们可以继续在此基础上修改。随时可以再找我“结对”。回顾整个会话InternLM2-Chat-1.8B展现出了令人印象深刻的“结对编程”素养理解与拆解它能准确理解“递归遍历统计文件类型”这个自然语言描述的需求并将其拆解为输入、处理、输出等可执行的步骤。代码实现能力生成的Python代码结构清晰使用了合适的标准库os,collections并包含了基本的错误处理和边界情况考虑如无扩展名文件。交互与迭代它不仅能接受模糊的需求更能根据具体的反馈进行精准修改。从“优化输出”到“增加过滤功能”它都能快速理解意图并落实在代码上。技术讨论深度当被问及性能和高级方案时它能指出os.walk与os.scandir的区别并进行权衡分析这超出了简单的代码补全进入了方案设计的层面。当然它并非完美。在整个过程中我需要提出明确的、结构化的反馈。它更像一个反应迅速、知识渊博但需要明确引导的初级搭档。然而这对于解决日常编程中那些“知道要做什么但懒得敲细节”或者“想找个思路参考”的场景已经绰绰有余。7. 结语这次与InternLM2-Chat-1.8B的结对编程实战不仅仅是一次代码生成演示。它更像是一次对未来编程工作流的预演。AI不再是那个藏在自动补全后面的神秘工具而是走到了台前成为一个可以对话、可以讨论、可以共同迭代的编程伙伴。它可能不会完全替代人类开发者天马行空的架构设计能力但对于实现具体功能、编写样板代码、快速原型验证、甚至学习新的API用法来说这样一个随时在线的“搭档”无疑能极大提升效率减少孤独感甚至能在思路上给你带来意想不到的启发。下次当你面对一个编程任务时不妨也试着向AI描述你的问题和它聊一聊一起写写看。你可能会发现编程这件事从此多了一份不一样的乐趣和可能。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。