从“AI写代码尝试1”这个标题说起吧。这名字一看就是个人项目没有什么包装就是一次真实的、带编号的实验记录。我特别能理解这种命名方式因为我自己也是这么过来的——脑子里冒出一个新想法觉得可以借助AI快速落地于是打开编辑器就开始折腾过程中踩坑、绕路、改方案、调提示词最后把整个经历记录下来。这个系列如果继续走下去编号到“尝试2”、“尝试3”只是时间问题。我这篇博文就把整个过程完整拆开讲一遍包括一开始是怎么想的、用什么工具、怎么写提示词、遇到哪些问题、最后怎么排查和修正。整个过程适合两类人看一是对AI编程有好奇心但还在观望的开发者二是已经开始用AI但总感觉“生成的代码不太对劲”的实践者。前者可以少走弯路后者可以对照自己的流程找差距。1. 内容整体设计与思路拆解1.1 从需求出发AI写代码到底解决什么问题先说清楚这个“尝试1”要做什么。我给自己定的目标是用AI辅助完成一个小型可运行的工具脚本功能是批量处理本地文本文件——读取指定目录下的所有Markdown文档提取标题和首段内容生成一份汇总索引。这个需求足够小但又有明确的功能边界适合拿来检验AI写代码的完整链路。选这个任务是有讲究的。完全不写代码让AI直接输出大项目那是“Web开发”级别的需求一次会话里上下文根本装不下。真正适合AI辅助的是这种边界清晰、逻辑独立、单机可运行的小工具。它涉及文件读写、目录遍历、文本处理、格式化输出如果用手写大概一百来行Python对AI来说是一个能hold住但又需要推理的任务。我当时心里对AI的预期也很克制不是让它一步到位写出一份完美脚本而是让它承担**“骨架生成关键函数实现边界情况处理”**这三个环节中的大部分工作我在旁边做需求校验和代码审查。这其实是AI辅助编程最健康的使用姿势——AI负责把“写”的速度拉满人负责把“对不对”的关卡守住。1.2 为什么选择AI辅助而不是纯手写这里要说点实际的。纯手写一个一百多行的脚本对我来说并不难20分钟大概率能搞定。那为什么还要用AI因为我真正想验证的是“AI能不能在一个具体需求下产出一份可以直接修改使用的代码”而不是“AI能不能写hello world”。而且这类文本处理脚本有个特点逻辑链不长但细节容易漏。比如读取目录时要排除隐藏文件、处理中文编码时要保证不报错、Markdown解析时要识别不同层级的标题、空文件要跳过。这些细节如果我手写靠的是经验和记忆如果让AI写靠的是它在大规模代码语料里学到的通用处理模式。两者本质上在做同一件事但AI的覆盖速度更快能让我在几分钟内拿到一个候选版本。更重要的是AI辅助最大的增量价值在于反复试错成本低。手写代码改函数签名很烦AI生成代码出问题你把报错信息粘回去它就帮你改了。这个互动的节奏感比传统开发快得多。1.3 方案选型的底层逻辑在正式动手之前我还想明白了一件事AI写代码这件事工具链的选择比提示词的技巧更影响体验。我这次选的是ChatGPT对话模式加VSCode本地编辑器后来也试过几款IDE内置的AI插件这个对比心得后面详细说。选型的核心判断标准有四个一是上下文窗口够不够装下代码和报错二是代码生成后的可编辑性也就是能不能直接复制粘贴、涉及的依赖装起来方不方便三是生成代码的解释性AI有没有告诉我这段逻辑是干嘛的四是迭代修改的方便度报错信息能不能快速进入下一轮对话。按照这个标准对话式AI加本地编辑器的组合就是最稳的。因为脚本型项目不依赖复杂的工程结构AI生成单个文件、我直接保存运行出现错误就粘报错继续对话这个闭环比任何花哨的“AI agent”模式都来得可靠。2. 核心细节解析与实操要点2.1 提示词工程的三大原则很多人用AI写代码上来就是一句“帮我写个程序处理文件”然后抱怨AI写的不是想要的。我一开始也犯过这个错误后来逐步总结出一套适合自己的提示词写法核心是三条原则。第一给角色和场景。让AI知道它是在帮一个有Python基础的开发者写工具而不是在教初学者。这样它会默认用简洁的代码风格只保留必要的注释而不是满屏print来解释每一行。第二给输入输出样例。这是最重要的一条。AI理解抽象描述的能力有限但给它一个“输入是这样、输出是那样”的对照样例它的准确率会直线上升。我处理Markdown索引时直接在提示词里塞了一段原文和一段期望的输出格式AI马上抓到了“标题要保留井号层级、首段要截断60字”这些隐含需求。第三给约束条件。不要让AI自由发挥明确告诉它“不要引入额外依赖”“只使用标准库”“文件编码用UTF-8”“函数要有类型标注”。这些约束加起来决定了代码的实用性和可迁移性。所谓“规则设定”本质就是把项目里没写出来的规范提前告诉AI。2.2 面向AI编程的工程化习惯有了好提示词还需要配合工程化的使用习惯。这里分享几个我从实践中总结出来的要点。第一个是小步提交逐步确认。不要要求AI一次输出整个完整项目。我这次的尝试分了三次对话第一次只要求输出主函数框架和文件遍历逻辑第二次要求补充Markdown解析函数第三次要求处理空目录、无标题文件等边界情况。每一次AI的输出我都能在本地快速验证而不是攒一个大包袱最后一起排错。第二个是代码审查不可省。AI生成的代码语法上通常没什么问题但逻辑上偶尔会“自信地犯错误”。比如它可能会假设所有文件都是UTF-8编码或者在遍历目录时忘了忽略.git目录。这些隐患不是AI能自己发现的需要人工在拿到代码后做重点核查。我的习惯是拿到AI的完整输出后先通读一遍主逻辑再跑测试用例重点测边界情况。第三个是把报错当对话输入。一次生成的代码往往会遇到几个运行时报错。别自己钻进去一行行查直接把完整的报错堆栈贴回对话里告诉AI“这段代码运行报错了报错信息如下请分析原因并修改”。这是AI辅助编程效率最高的一种交互方式因为它能直接定位到出错的那几行给出的修改方案通常也很精准。2.3 参数与配置一次完整的需求描述示例以我这次的索引生成工具为例我把一份完整的需求描述整理成了这样你是一个Python开发助手。请在Windows环境下编写一个脚本功能如下 1. 遍历指定目录及其子目录下的所有.md文件 2. 忽略文件名以_开头或以.开头的文件/目录 3. 对每个.md文件解析第一个H1或H2标题并提取正文第一段 4. 生成一份INDEX.md内容包括文件相对路径、标题、首段摘要 5. 只使用Python标准库os、re、pathlib等不要引入第三方依赖 6. 所有文件操作使用UTF-8编码Windows下注意编码处理 7. 主函数接收目录路径作为命令行参数。 输入示例 目录 docs/a.md 内容为 # 项目启动说明 这是项目启动的第一段内容需要在索引中展示。 输出示例INDEX.md中对应的一行 - [docs/a.md](docs/a.md) | 项目启动说明 | 这是项目启动的第一段内容需要在索引中展…这个描述一次性把场景、约束、样例、边界全部交代清楚了。AI拿到之后在几十秒内生成了一个约80行的脚本我复制到本地跑了一下第一个版本除了没有处理“文件内容只有标题没有正文”的空段落情况其它功能全部正常。这是效率极高的一次体验。2.4 核心细节速查表对于想快速上手的人我把AI写代码链路中的关键细节整理成一张表照着操作基本不会跑偏。环节关键细节效果说明需求描述功能点逐条列出输入输出样例减少AI自行假设的空间约束设定明确依赖范围、编码、运行平台避免生成跑不起来的代码代码获取先骨架后细节分阶段索取便于逐步验证、控制质量运行验证准备2-3个测试文件覆盖边界快速暴露逻辑漏洞报错处理贴完整堆栈不自己闷头排查降低试错成本最终审查检查文件处理、异常分支、路径拼接AI的“自信错误”要靠人工兜底3. 实操过程与核心环节实现3.1 工具链的最终选择我这次尝试主要用的工具组合是“Windows 11 Python 3.11 VSCode ChatGPT网页对话”。为什么不是更自动化的工具我在开始之前其实做过一轮对比。“AI内嵌IDE”的方案比如GitHub Copilot最大的优势是代码补全和上下文感知在你写代码的过程中实时给建议。但它的强项是“填空式补全”更适合代码写到一半需要续写的场景。如果是一个从零到一的小工具Copilot反而发挥不出全部实力因为你要的更多是“整段生成”而不是“行级补全”。对话式AI的强项恰恰是“整段生成需求理解”。你把需求描述完整它一次性返回几十行代码这个交互方式跟“和同事对需求然后他写完给你”非常接近。缺点是需要自己在编辑器和浏览器之间来回切换但脚本开发本来就是单文件为主切换成本可以接受。我还试过几款国产AI编程助手比如Pycharm里的Fitten Code插件这类工具把对话窗口直接嵌进IDE里免去了来回切换的麻烦。实测下来体验也不错尤其适合“代码生成后立刻原地修改”的工作流。不过从可复制性的角度这篇文章还是以通用对话式AI的流程为主你完全可以把同样的提示词搬到任何一个主流AI模型里用。3.2 从需求到代码的完整对话记录实际操作时我的第一轮对话是这样的我请帮我写一个Python脚本用来扫描指定目录下的所有md文件生成索引。要求遍历子目录忽略隐藏目录提取第一个标题和第一段内容输出到INDEX.md。只允许用标准库。这是一个很粗犷的需求描述。AI给出的代码框架基本正确但有两个问题一是它用了一个Path.rglob(*.md)来遍历这个方式本身没问题但它没有过滤掉以点开头的隐藏目录二是它默认生成的INDEX.md会把扫描目录下的原INDEX.md也当成输入文件造成“索引自己索引自己”的情况。这两种问题就是我在前面提到的**“自信的错误”**。如果是新手直接把代码跑一遍看到结果里有奇怪的文件就会懵。而我的选择很简单把这两处问题重新描述给AI让它修改。我有两个问题需要修正。遍历时请过滤掉所有路径中包含隐藏目录的项也就是以点开头的目录另外要排除输出的INDEX.md自身。AI很快就给出了修正。它把遍历逻辑改成了“获取列表后用路径判断过滤”并且主动在遍历前检查文件名是否等于INDEX.md。这个修正思路是合理的虽然AI不会像人一样“记住”这些问题但它确实能理解描述并做出准确的修改。3.3 目录结构设计对AI生成质量的影响这个点我觉得特别值得展开。同一个脚本如果项目目录结构干净AI生成质量明显更高。为什么会这样因为AI是通过观察大量开源项目语料学习的它熟悉的标准结构是“src目录放代码、docs目录放文档、输出目录独立存在”。当你把需求描述成“扫描docs目录输出到output目录”AI对路径的思考就会顺畅很多。我对这块的理解是把你的目录结构先想清楚再让AI写代码比让AI一边写代码一边设计目录结构要可靠得多。我在尝试里实际使用的目录树很简洁my_ai_tool/ ├── docs/ # 被扫描的markdown文件存放目录 │ ├── sub_dir/ │ │ └── b.md │ └── a.md ├── output/ # 生成的索引文件输出目录 └── scan_md.py # AI生成的脚本目录结构简单AI就不用花精力去猜你需要哪个文件夹它可以把所有注意力放在文件读写和解析逻辑上。实测在明确了目录结构之后AI输出的代码几乎没有再出现过路径相关的低级错误。3.4 关键代码片段的审查笔记在AI生成的代码里我选取了一段核心的Markdown标题提取逻辑来做审查演示。它的实现思路是这样的def extract_title_and_first_para(file_path: Path) - tuple[str, str]: text file_path.read_text(encodingutf-8) lines [line.strip() for line in text.splitlines() if line.strip()] if not lines: return 无标题, 无内容 title for line in lines: if line.startswith(#): title line.lstrip(#).strip() break body next((line for line in lines if not line.startswith(#)), 无正文) return title or 无标题, body[:60] (… if len(body) 60 else )这段代码初看很顺但审查时我发现了一个典型问题它完全忽略了标题下方可能是空行或代码块的情况。如果文件内容是# 标题 python print(hello)正文开始这个写法里标题的提取是正确的但“第一段正文”会被误判为代码块里那行print(hello)。虽然在我的测试文件里没有触发但这是一个真实的边界缺陷。我把这个问题反馈给AI后它建议增加一个“跳过以三个反引号开头的内容块”的判断。 看到AI能基于描述修正这种逻辑我对它的判断是“适合做初级程序员但架构师还得是人”。这个定位我觉得很准确。 ### 3.5 运行验证与结果评估 代码修正后我在本地实际运行了一遍。扫描对象是docs目录下三个文件一个正常的一级标题文件、一个包含子目录的二级标题文件、一个只有正文没有标题的文件。运行结果如下表所示 | 输入文件 | 提取标题 | 首段摘要 | 是否正常 | | --- | --- | --- | --- | | docs/a.md | 项目启动说明 | 这是项目启动的第一段内容… | 正常 | | docs/sub_dir/b.md | 子项目配置指南 | 这个文档主要介绍配置文件写法… | 正常 | | docs/c.md | 无标题 | 这是一篇未设置标题的文档… | 标题兜底生效 | 三个用例全部通过。耗时从打开编辑器到生成最终INDEX.md大概15分钟其中至少一半时间在调整提示词和应对边界案例。这个结论和很多AI编程经验分享是一致的**AI把写代码的时间压缩到很短但需求分析和边界处理仍然是主要时间成本**。 ## 4. 常见问题与排查技巧实录 ### 4.1 没有代码提示是哪里出了问题 看热搜词里有人反复问“vscode写c没有代码提示”对这个我很想多说一句。很多人以为装了AI插件之后提示是自动的其实完全不是。VSCode的代码提示分为两层一层是语言服务器Language Server提供的静态分析和符号补全另一层才是AI插件的智能补全。如果你装了AI插件但还没有提示问题大概率出在**语言服务器没启动**。 排查思路很简单打开VSCode的命令面板CtrlShiftP输入“C/C: Log Diagnostics”或者查看右下角语言模式确认文件被正确识别为C语言再装一个C/C扩展ms-vscode.cpptools等右下角出现“正在加载工作台”提示语言服务器就绪了。AI补全插件比如GitHub Copilot或Fitten Code依赖语言服务器的符号索引服务器没起来AI再厉害也不知道你在写什么。 以我自己的经验这类问题80%以上都是“扩展没装全”或者“工作区没正确识别文件类型”而不是AI本身的问题。 ### 4.2 代码高亮异常和编辑器设置 还有一个热搜词“idea写代码时突然出现黄色高亮占好几行”这其实是IDE的代码检查提示。IntelliJ IDEA默认会高亮一些可疑代码比如未使用的变量、重复的代码块、可以被简化的表达式。很多人一看到黄色背景就以为代码写得有问题其实大部分情况只是“优化建议”不影响编译运行。 排查和处理方式我给你列清楚 - **先分辨颜色类型**红色是编译错误黄色是警告灰色是未使用。只有红色需要立刻处理。 - **鼠标悬停高亮区域**IDEA会弹出具体的提示信息比如“Expression can be simplified”或者“Unused assignment”。 - **按AltEnter**在光标处打开快速修复菜单可以选择自动简化或忽略。 - **如果是AI插件引起的误报**有些AI代码补全插件也会把自己的“建议标记”显示为高亮可以在插件设置里把“Code Vision”或“Inline Hints”关掉。 这些都是IDE层的问题和AI写代码本身关系不大。但如果你让AI生成了大段代码后粘进IDE突然看到一片黄色高亮心里会慌。搞清楚颜色语言后会好很多。 ### 4.3 AI生成代码跑不起来优先查这三处 结合我的尝试过程AI生成的小脚本跑不起来大体逃不出这三类原因。 第一类是**路径问题**。AI默认使用相对路径而你运行的当前工作目录和脚本所在目录不一致。解决方式是把输入路径写死为绝对路径或者在代码开头加一句os.chdir(os.path.dirname(os.path.abspath(__file__)))让脚本基于自身所在目录运行。 第二类是**编码问题**。Windows终端和文件读写默认编码是GBKPython3默认文件读取又是UTF-8。AI生成的代码在没有显式指定编码时一旦遇到中文内容就容易报UnicodeDecodeError。解决方式是所有读写操作都带encodingutf-8参数。 第三类是**依赖缺失**。如果AI生成的代码引入了第三方库而你的环境里没装运行就会直接ModuleNotFoundError。解决方式有两种一是让AI改用标准库重写二是在运行前先用pip install把缺失依赖装上。 我把这三类原因直接写进了一个速查表方便你对照排查 | 现象 | 最常见原因 | 快速处理 | | --- | --- | --- | | 文件找不到 | 相对路径基准不对 | 用绝对路径或改变脚本基准目录 | | 中文报错 | 编码未指定 | 读写文件全部加UTF-8 | | 模块不存在 | 第三方依赖缺失 | 安装依赖或让AI改用标准库 | | 输出为空 | 过滤条件过严 | 检查遍历时的文件名匹配规则 | | 程序卡死 | 遍历到特殊文件 | 增加异常捕获和超时机制 | ### 4.4 如何选择和评估“擅长写代码的AI” 我的尝试用下来AI模型之间在代码生成上的差异确实明显。有些模型擅长理解自然语言描述能写结构清晰的代码有些模型则更擅长把一个问题拆分后在多个文件间协调。关键在于你拿它做什么。 如果是写独立小脚本、数据处理工具、测试用例这种单文件任务主流的几个对话式AI模型都够用。优先选择**上下文窗口大、支持粘贴长代码、响应速度快**的因为这几项直接决定了交互效率。 如果是做大型项目的功能开发那就需要看AI是否具备“多文件上下文理解能力”。比如修改A文件时能不能从B文件里找到对应的函数定义。这类场景下IDE原生集成的AI插件通常比对话式AI更好用因为它们能直接读取当前项目的代码库。 如果是做测试开发或者自动化脚本这个场景其实特别适合AI写代码。因为测试用例的边界条件描述很清晰AI生成的代码只要能覆盖常见输入输出加上断言就能跑出一份可用的测试集。 我自己的心得是不要迷信“最强AI”这种说法把工具和场景匹配好任何一个主流的AI都能帮你把效率提升一倍以上。 ### 4.5 那些需要避开的内容坑 写这篇文章的时候我还浏览了一下标题关联的热搜词注意到有一些带有“无限制”“无禁词”之类的词汇这类内容恕我不展开也不会做任何推荐。真想用AI写好代码把重心放在提示词工程、工具链配合、代码审查这些正路上产出会是实打实的效率提升。那些打擦边球的需求既不能帮你提升技术也容易被平台判违规没必要投入精力。 AI写代码这件事本身最大的价值是“让编码回归设计”。你把大部分机械性的编码工作交给AI把省下来的时间放在架构设计、边界思考和代码审查上这种工作方式一旦适应是回不去的。 ## 5. 从尝试1到方法论沉淀下来的经验与下一步规划 ### 5.1 这次AI辅助编程尝试的成绩单 客观复盘一下这次“AI写代码尝试1”的收获。功能上做成了一个可用的Markdown批量索引工具源码在VSCode里跑通测试覆盖了常规文件和边界情况全部通过。过程中经历了三轮提示词迭代、两次代码审查、修掉了三个逻辑缺陷。最终代码量在100行上下AI生成的完成度约70%我修改和补充的部分约30%。 这个比例说明一件事**AI写代码不是“AI替代人”而是“AI承担初稿人承担终审”**。初稿的质量取决于提示词终审的质量取决于你的技术判断力。两者不可偏废。 ### 5.2 后续还可以怎么扩展这个项目 这次尝试的成果不是终点。我给自己留了几个扩展方向你要是感兴趣也可以照着做。 加一层“目录结构自动生成”。目前脚本只读取已有目录如果指定的输入目录不存在会直接报错。可以让AI加一个判断如果目录不存在就自动创建。 加一种“多格式输出”。目前只支持Markdown格式输出可以扩展成同时生成JSON格式的索引文件方便其他程序调用。 加一条“定时任务”。Windows的Task Scheduler可以定时运行这个脚本让它每天自动扫描一次文档目录自动维护索引。这个场景对经常写技术文档的人很有用。 加一个“批量重命名工具”。把扫描索引的逻辑反过来用把标题变成文件名或者在文件头部插入缺失的标题。 每个方向都够再开一个新的“尝试”系列。 ### 5.3 我现在的使用习惯 做了这次尝试之后我对AI辅助编程的使用方式发生了一些变化。现在遇到一个新的小需求我的第一反应不是打开一个空白文件从第一行开始写而是先把需求用自然语言整理成一、二、三条再打开AI对话窗口把需求描述贴进去让它给我一个“初稿”。不管这个初稿质量怎么样它都能让我在几分钟内进入“具体技术讨论”的状态——哪里的逻辑不合理、哪个边界没覆盖、哪种写法效率更高。 这个变化的核心是把“思考”和“打字”解耦了。以前写代码的时候打字的速度会局限思考的深度因为你要分心去应付语法、函数名和缩进。现在AI把这些都接管了我可以把所有脑力都放在“设计”这件事上。 最后再分享一个小技巧如果你决定开始自己的“AI写代码尝试N”系列务必保存好每一轮的提示词和AI回复。我当时就截了图存到笔记里后来回看才发现很多问题在第一轮就有预兆只是当时的我还不够敏感。把过程记录下来比结果本身更有复盘价值。