企业官网建设流程全解析

1. 先搞清楚：代码提示词到底在解决什么问题

1.1 "帮我写个爬虫"这种提示词为什么总是翻车

我见过太多朋友兴冲冲地打开对话框，输入一句"帮我写个爬虫"，然后等着奇迹发生。结果模型确实很给面子，刷刷刷写了几十个函数出来，从请求头到解析逻辑一应俱全。但你把它粘贴进项目里一跑，要么反爬校验过不去，要么目标站点的结构和模型预想的不一样，要么频率限制把对方服务器搞得不耐烦，直接把你的出口IP封了。

这种时候大多数人会得出一个结论：这AI写代码不行。但我得说句公道话，问题往往不在模型，而在提示词本身。"帮我写个爬虫"这句话信息量太低，低到跟"帮我做个网站"差不多。模型没有长在你的脑子里，它根本不知道你爬的是什么站点、数据存在什么格式、运行环境有没有代理、一天需要跑多少次。它只能在所有可能性里猜一个最像"标准答案"的东西给你。

这个道理放到人类协作里就特别明显。你让一个刚入职的实习生"把数据整理一下"，他大概率给你交一份你根本没法用的表格。你要真想要那个结果，必须告诉他：按哪一列排序、空值怎么处理、日期用什么格式、结果输出成Excel还是CSV。写提示词也是一样的逻辑，只是你在跟一个知识面极广但对你一无所知的"实习生"打交道。

1.2 代码本质上是"约束的集合"，提示词就是约束的输送管道

我自己的体会是：代码不是"魔法的产物"，而是"精确约束的产物"。一段能真正拿出去跑的代码，里面每一个分支、每一个边界判断，本质上都是你对业务规则的一次固化。比如一个文件名重命名脚本，你嘴上说着"把日期改成YYYYMMDD格式"，但脑子里的真实意图可能是"只要文件名的第6到13位是日期的就统一格式，不是的话就不动它"。这种约束如果不说出来，模型根本无从下手。

所以，代码编写提示词的核心功能，不是"命令"模型去写代码，而是把你脑中的完整约束尽可能准确地搬运到一个文本对话里。这正好也是语言模型最擅长的事：它不是在"理解"代码，而是在"预测"一段符合你上下文的、概率最高的文本续写。你给它的约束越精确定义，它生成的代码就越接近你想要的那个解；你给的约束越含糊，它就越倾向于生成一种"看起来正确"但实际哪都不对的平庸代码。

从这个角度重新看提示词工程，它就不那么玄学了。你不需要背什么复杂的咒语，你需要的是锻炼一种"把需求翻译成约束"的能力。这个能力跟编程本身一样重要，甚至从投入产出比来看，它比多刷两百道算法题划算得多。

2. 一份拿过去就能改着用的编程提示词结构

2.1 六要素框架：角色、任务、输入、约束、输出、验收

我写过的编程提示词没有一千条也有几百条了。沉下来复盘之后发现，凡是效果好、迭代次数少的，背后都有一个极其相似的骨架。我把它总结成六个要素，不一定每个场景都用得到，但缺一个都要多花两轮对话去补。

这六个要素里，最容易被忽略的是"输出"和"验收"。普通用户写提示词，写到"任务"就停手了，能写"约束"的都算讲究。但你想一想，代码跑完以后你要拿什么判断它对不对？你总得有一个可观测的结果。如果你告诉模型"重命名完成后打印一个对照表"，你就能自己一眼看出它有没有把不该动的文件改掉。这个验收动作不仅是给你看的，也是让模型在生成代码时更谨慎——因为它知道最终会有人以这个输出为准去检查它。

2.2 一个贯穿全文的案例：文件批量重命名脚本

为了让上面这六要素更落地，我拿一个真实的小任务从头到尾演示一遍。假设我需要一个Python脚本，功能是把我下载目录里的一大堆文件重命名，把文件名中的日期统一成标准格式，同时不改变扩展名。这个任务很小，恰恰因为它小，才能看清提示词里每一句话对输出质量的影响。

最先一版，我直接问："用Python写个脚本，把文件名中的日期统一成YYYYMMDD格式。"

模型回了一个能用但很脆的脚本：它假设日期总在文件名开头、假设日期中间用横杠分隔、假设所有文件都是文本文件。如果文件名是"report-2024-01-05-final.pdf"，它也能处理，但如果某个文件名是"Screenshot from 2024.01.05 at 14-22-11.png"，就完全乱了。这就是典型的"任务描述清楚、约束稀疏"导致的。

后来我改用六要素框架重写了一遍提示词：

我是一名经常从网页后台下载报表的运营人员，需要整理下载目录。 任务：编写一个Python脚本，扫描指定目录，把文件名中以中文或横杠/点分隔的日期统一格式化为YYYYMMDD，并保持扩展名不变。 输入样例： - 销售报表-2024-01-05.xlsx - Billing Jan 5 2024.pdf - screenshot-2024.01.05.png 约束： 1. 不递归子目录，只处理当前目录。 2. 不修改任何非日期部分的文件名。 3. 对文件名的原始顺序不做假设。 4. 只使用Python标准库，不引入额外依赖。 输出：执行后列出每个文件的"原文件名 -> 新文件名"，并在重命名失败时给出原因。 验收：我会用一个包含上面三类样例文件的空目录运行脚本，要求全部正确转换且无报错。

同一件事，两种提示词，生成的代码质量差了一个量级。前者只能在理想文件名上工作，后者能在你手头的真实目录里直接开工。诸位不妨下次接到任何小任务时，都把这个六要素过一遍，别急着让模型动手。

3. 我最常用的几种提示词技巧，以及它们背后的逻辑

3.1 描述业务场景，而不是描述功能列表

很多开发者写提示词有一个习惯：上来就罗列需求清单——"要有进度条""要支持断点续传""要能解压zip"。功能列表没问题，但如果整个提示词全是一串功能名词，模型根本不知道这些功能之间是什么优先级、它们为谁服务。

我更推荐的做法是先花两句话描述业务场景。比如上面那个下载报表的例子，我告诉模型"我是运营人员，每天要从后台导出报表"。这句话不是废话，它给了模型一个隐性信息：这个脚本的使用者很可能不擅长命令行，所以错误提示要中文、最好自动处理常见的权限问题，而且不会去修改不是自己创建的文件。你看，两句场景描述能影响一堆技术决策。

这背后的逻辑也很简单：语言模型是在大量真实文本上训练的，它见过无数个"运营人员写的脚本"和无数个"后端工程师写的基础库"。当你把自己定位成一个角色，模型生成的代码就会更贴合这个角色在实际工作中会遇到的约束条件。反过来，你只丢给它一个功能列表，它就会把代码写成"给另一个程序员看的"风格，充斥着抽象类和接口。

3.2 把模糊规则翻译成可执行判定

提示词里最怕出现的词是"合理地""适当地""智能地"这类主观副词。比如"智能地判断日期"，模型只能愣在原地，因为它不知道你的"智能标准"到底是什么。你要做的是把这种主观判断翻译成可执行的判定条件。

举一个常见需求：一个CGI脚本要输出合规的JSON。用户写"对输入数据做合法性检查"，模型会写出来一个检查了所有常见漏洞的"万能校验"，看起来面面俱到但实际无法按你的规则收紧。更好的写法是明确判定规则：所有字段必须存在、数字字段必须大于0且小于1000、如果email字段为空就丢弃这条记录而不是报错终止、每条记录里超过三个非法字段就跳过并在日志里记录。每一条都要是一个能写成if语句的条件。

我给这种改写方式起过一个名字叫"面向if的提示词写作法"。你在写提示词的时候，心里默想：这句话能不能直接变成一个if条件？如果能，那没问题；如果不能，说明这句话还得再拆细。这样做还有个额外的好处——你会在写提示词阶段就发现那些原本以为"不需要特别说明"的业务规则，而这些规则恰恰是线上事故的大头来源。

3.3 用示例代替描述，输出格式立即可预期

如果你希望模型产出某种固定格式的数据（比如JSON配置、CSV行、特定风格的函数签名），最有效的做法不是描述这个格式，而是直接给它一个示例。语言模型对模式识别的能力远强于对抽象叙述的理解，这个概念在学习领域叫"少样本学习"，在提示词工程里同样适用。

我举个例子。我想让模型给我生成一条正则表达式来匹配中国大陆手机号。如果我只说"匹配中国大陆手机号"，模型大概率给你一个能用但要么过松、要么过紧的正则。如果你在提示词里追一句：

例如：13812345678 应匹配，8613812345678 也应匹配，12345 不应匹配。

模型的输出精度立刻上升。为什么？因为示例本质上给模型划定了一个范围边界。它不再需要猜测"你说的手机号到底带不带国家区号""要不要校验第二位数"，它只需要在自己的知识范围内找一个能同时满足你给出正反样例的模式。

我建议每条提示词里至少带一对正例和反例。正例告诉模型你想要什么，反例告诉模型你不想要什么。这两者提供的信息量往往比五句抽象描述还要多。

4. 从一次性问答到持续协作：模型的迭代式工作流

4.1 先让模型交付最小可用版本，再逐层加约束

有一个特别容易犯的错误：一上来就要求模型一次性写一个"生产级完整解决方案"，并且所有细节都在第一条提示词里交代完毕。结果通常是模型输出一个超长文件，表面上功能齐全，实际上每个模块都很毛糙，运行起来处处报错。

我的习惯是先让模型交付一个"能跑通的最小版本"。比如我需要一个订单统计报表，第一轮提示词只要求它读取一个指定格式的CSV，按订单状态分组，输出数量统计。这一步应该是十五到二十行代码的事。跑通了以后，第二轮再加"过滤掉取消状态的订单"；第三轮再加"按月份额外分一层透视"；第四轮再要求输出格式从控制台改成HTML。每一步加一个约束，每次都我能快速验证，出了问题也知道是哪一轮引入的。

这和搭积木是一个道理。你不可能让一个实习生一口气按照你的终版需求把整栋楼盖完，但你可以让他先搭一个结构简单的毛坯房，然后一间一间地改。模型的工作模式尤其适合这种渐进式构建——它的上下文窗口有限，你把所有需求塞进一条提示词里，越到后面它越容易遗忘前面提到的某个细节。

4.2 带着报错原文回来，别只扔一句"还是不行"

模型迭代过程中最让人血压升高的对话模式是：用户跑完代码，回来说"还是不行"。没有报错信息、没有输入数据样例、没有期望输出的说明。模型面对这种反馈只能玩猜谜游戏，猜测你在哪一行遇到的失败。

正确的沟通方式极其简单：把报错堆栈完整贴回去，再加上当前代码和一两行输入样例。我用这套方法以后，通常一轮回复就能解决问题，而大多数人会在"还是不行"和"我不是说了吗"之间来回消耗五六轮。

还有一个小细节：当模型给出修复版代码时，你最好在提示词尾部注明"请解释你改动了哪里以及为什么"。这个问题会让模型在输出前重新审视自己的修复逻辑，减少它"为了修复而修复"却引入新问题的概率。这一招对排查那种隐藏很深的状态相关问题特别有效。

4.3 大任务拆分：一个"订单管理后台"是怎么变成五个子提示词的

有一次我需要快速生成一个带前端页面的后台管理原型，任务是管理用户和订单。我如果不拆分，一条提示词丢进去，模型大概率会生成一个多文件项目，但各文件之间互相引用不匹配，接口字段名对不上。后来我强制自己把它拆成了五个子提示词，每个子提示词只负责一件事：

• 第一轮：设计数据库表结构，输出建表SQL，并写明每张表的字段全集和各字段含义。
• 第二轮：基于上一轮的SQL设计结果生成后端API，返回字段名和第一轮保持一致。
• 第三轮：生成前端列表页和数据新增页，直接引用第二轮返回的API字段名。
• 第四轮：补上登录鉴权和权限控制。
• 第五轮：整体联调，检查接口路径、方法、参数各环节是否匹配。

这个过程中，每一轮的产物都会作为下一轮提示词的输入粘贴进去。用一个极其重要的原则：每一轮结束时生成的代码我必须要求模型"附带一份返回数据样例"，这样下一轮模型就能照葫芦画瓢。整套流程走下来，效率和输出质量比一次性大满灌高太多。

5. 代码提示词的无效区：那些模型天生搞不定的地方

5.1 不要指望模型替你做架构决策

提示词写得再精细，也有模型不应该替你拍板的事情。比如项目该用单体架构还是微服务、数据库该选关系型还是文档型、某些核心链路该同步实现还是异步解耦。这些决策依赖你对业务量、团队分工、运维能力的判断，而不是模型对"最佳实践"的推演。你把这类问题抛给模型，它只会给你一套听起来无比正确的标准答案，而这个答案未必适合你的场景。

所以我的实践是：涉及架构选型的判断，我会先在提示词里明确给出方向。

比如"项目规模小于50个接口，团队两到三人，数据一致性要求高，请采用单体架构，不要引入消息队列"。明确指定方向，然后让模型在这个既定范围里发挥。这不是不自信，而是清楚边界在哪里——模型是很好的执行者，但不是可靠的技术顾问。

5.2 安全相关的输出必须二次人工审查

模型生成代码里最容易出现"看起来正常实则危险"的地方，是命令注入、SQL注入和不安全的反序列化。这几个领域的实现细节往往藏在代码分支的犄角旮旯，模型不会主动提示你它的写法存在风险，因为训练数据里这种错误写法太常见了，模型并不知道你的上下文里的输入到底可信到什么程度。

我自己有一条铁律：凡是涉及用户输入拼接、文件路径拼接、执行系统命令、处理上传文件这四类代码，模型生成后我必然要人工逐行走查一遍。不看走查结果绝不进版本库。我把这条写进了我给自己团队用的代码提示词模板里：

注意：所有用户输入必须经过参数化处理，禁止拼接执行；禁止使用eval；涉及路径操作必须使用pathlib或强制规范化后再使用。如果代码中存在任何从外部不可信源获取的输入，请单独标注并在注释中说明处理方式。

有这段话和没有这段话，模型的输出差异非常大。没有的时候，它常常给你string拼接的写法；有了之后，它会主动使用参数化查询。你不需要模型理解所有安全风险，你只需要用提示词把它推到安全写法的轨道上。

5.3 提示词的"时效黑洞"：版本变化和库更新

还有一个反复踩坑的点：语言模型的知识是有截止时间的。你对它说"用某个库的某个新API，请生成对应代码"，它可能根本不知道这个新API存在，却依然一本正经地写出一个老版本用法。更麻烦的是，有些库在版本升级后改了函数签名，模型还在按旧版输出，你跑起来会出现诡异的TypeError。

针对这种情况，我的做法是把关键第三方库的版本号写进提示词，并让模型明确标注它在回答中假设的版本。比如：

使用Python 3.11编写的脚本，pandas版本为2.1.0。如果某个函数在pandas 2.0以上有破坏性变更，请按最新版API实现。

如果我在代码生成后遇到疑似版本兼容问题，我还会把官方文档里相关函数的说明片段贴进对话里。这个做法很笨，但极其有效——模型拿到文档后百分之百不会再按旧知识瞎编。不要嫌贴文档麻烦，一条提示词多花两分钟，能省掉整个下午的排查时间。

6. 把提示词本身当代码来维护：版本、模板、回归

6.1 为常见任务沉淀自己的提示词模板库

我以前总是临时抱佛脚，每次要写脚本都从头组织提示词，效率很低。后面我意识到，很多任务是重复出现的：生成数据清洗脚本、生成接口联调测试、生成CI脚本、生成文档结构。为什么不把沉淀下来的高质量提示词也当作代码一样管理？

我第一次整理模板库的时候，给自己定了一个简单规则：每个模板必须包含六要素、至少一对正反样例、以及一两个"上次踩坑后补上的约束"。这个规则让模板基本做到可以无脑复制、改参数、发送三步走。后来我大概攒了二十多个常用模板，要么是某个固定系统的接口对接，要么是固定格式批处理任务。平均来说，一个以前要花四十分钟调教模型的场景，现在两分钟内就能得到能跑的版本。

6.2 给提示词加版本号，就像给接口加版本号

提示词这东西看着不像代码，但它确有版本。原因很简单：同一个任务，我可能上个月用某个模型版本跑通了，这个月换了新模型之后同样的提示词输出质量明显下降。这时候"回退到上一个能用的提示词版本"就变得格外实用。

我的维护方式是给每个模板文件加一个简单的变更记录：

版本：v3 变更说明：增加对空目录的边界处理要求；将错误信息改为中文； 适用模型：某系列模型 4.0+

这个变更记录不需要多花哨，就是几行注释，但它能帮你快速定位"到底是我改坏了提示词，还是模型变了"。我自己就经历过一次：某个任务用旧提示词跑得好好的，我优化了一版提示词后输出突然变得极其啰嗦，回滚之后发现其实模型那几天更新了服务端策略，跟我的提示词没关系。如果没有版本记录，这种排查会变得非常痛苦。

6.3 对提示词做"回归测试"：一组固定的验收样例

既然把提示词当代码维护，那自然少不了回归测试。我对于反复使用的高频模板，会准备一组固定的输入样例和一个固定的预期输出，每隔一段时间跑一遍，确认当前模型对这份提示词的支持度没有退化。

以报表生成脚本为例，我的回归样例是那三个极端文件：一个超长文件名、一个包含Unicode字符和中文字符的文件、一个没有日期信息但文件名格式看起来很像日期的文件。每次换新模型或者升级提示词之后，我会用这三个样例过一遍。三项全过，说明模板状态健康；有一项失败，就知道是哪类边界条件触发的问题，再针对性补一条约束。

这套方法听起来有点过工程化，但经过了三次大版本模型更替之后，我越来越确信它是值得的。大语言模型的行为本身就具有一定概率性，你上一次跑对了不代表这次一定对，有了回归测试，至少能给自己一个兜底的稳定预期。

我以前总觉得提示词是"一次性的、用完就扔的对话文本"，后来被一遍遍教做人之后才明白，它其实跟代码一样，需要结构、需要版本、需要测试、需要持续维护。区别只在于，提示词的"编译环境"是另一个黑盒，你没法debug到内部，只能通过约束框架让输出可控。而你能控制的那些约束越多，这个黑盒表现得就越像一个靠谱的协作者。