企业官网建设流程全解析

从“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写代码链路中的关键细节整理成一张表，照着操作基本不会跑偏。

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(encoding='utf-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的命令面板（Ctrl+Shift+P），输入“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”。 - **按Alt+Enter**：在光标处打开快速修复菜单，可以选择自动简化或忽略。 - **如果是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终端和文件读写默认编码是GBK，Python3默认文件读取又是UTF-8。AI生成的代码在没有显式指定编码时，一旦遇到中文内容就容易报UnicodeDecodeError。解决方式是所有读写操作都带`encoding='utf-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回复。我当时就截了图存到笔记里，后来回看才发现，很多问题在第一轮就有预兆，只是当时的我还不够敏感。把过程记录下来，比结果本身更有复盘价值。