企业官网建设流程全解析

简介：这份资源面向希望摆脱ChatGPT初级用法、提升对话质量与专业度的使用者，包括内容创作者、研究者、产品与运营人员。它整理了15个专家级提示词（Prompts）与指令，覆盖受众定位、语言切换、引用来源、术语使用、专家引言、视觉元素、数据支撑、字数限制、关键词、话题范围、上下文理解、案例说明、内容审核过滤、协作共享以及局限与误解等维度，帮助读者在不同场景下精准控制AI输出。资源包为1个docx文档，约12KB，内容以中英对照的提示词模板与说明为主，便于直接复制套用或按需改写。已有430人学习下载。通过逐条理解并组合这些提示词，读者可快速搭建自己的提示词库，让ChatGPT的回答更贴合目标人群、更具权威性与可操作性，同时规避无关或不当内容，提升个人与团队的内容生产效率。

1. 15个专家提示词到底解决什么问题：从“能聊”到“能干活”的分水岭

很多人第一次用 ChatGPT 写代码、写方案、做数据分析，都会经历同一个落差：明明模型很强，自己问出来的东西却像百度百科。问题往往不在模型，而在提示词（Prompts）——你给的是“帮我写个脚本”，它回你的就是一段能跑但没法用的模板代码。所谓专家提示词，本质是把一个领域里资深工程师的思考框架，压缩成一段可复用的指令结构，让模型按固定角色、固定约束、固定输出格式来干活。

这篇要拆的，就是 15 个能直接抄去用的专家提示词，覆盖代码审查、架构设计、故障排查、文档生成、数据分析、测试用例设计等高频场景。适合两类人：一是刚接触提示词工程、想让 ChatGPT 输出从“能用”变“好用”的开发者；二是已经在用 AI 编程提示词但总觉得差口气、想看看别人怎么组织指令结构的老手。下面不讲玄学，只讲每个提示词的结构逻辑、参数怎么改、什么场景会翻车。

2. 专家提示词的结构拆解：角色、约束、输出格式三件套

2.1 为什么“你是一个资深工程师”这句话几乎没用

大多数人写提示词的第一反应是加一句“你是一个有20年经验的资深架构师”，然后发现输出质量并没有明显提升。原因很简单：角色设定只影响模型的语气和词汇偏好，不改变它的推理路径。真正决定输出质量的是约束条件和输出格式。

一个能稳定干活的专家提示词，结构上必须包含四层：

角色锚定要具体到子领域，比如“你是一个专注高并发后端服务的 Go 工程师”就比“你是一个资深程序员”有效得多。任务约束要写清楚“不做什么”，比如“不要引入第三方依赖”“不要用递归”。推理步骤可以用“先分析再给方案”这类指令触发。输出格式则要精确到 Markdown 层级、代码块语言标注、是否包含注释。

2.2 一个可复用的提示词骨架与参数说明

下面这个骨架是我用了半年多、迭代了十几版之后稳定下来的结构，适用于代码生成、方案设计、故障排查三类任务：

# 角色 你是一个[具体子领域]工程师，擅长[具体技能1]和[具体技能2]。 # 任务 [一句话描述要做什么] # 输入 [粘贴代码/日志/需求描述] # 约束 - 不要[具体禁止行为1] - 不要[具体禁止行为2] - 如果信息不足，先列出需要补充的信息，不要猜测 # 推理要求 先分析[分析对象]的结构和问题，再给出方案。分析过程控制在200字以内。 # 输出格式 1. 问题定位（如有） 2. 方案说明（含关键参数） 3. 代码实现（标注语言，关键行加注释） 4. 验证方法

这个骨架里，最容易被忽略的是“如果信息不足，先列出需要补充的信息，不要猜测”这一条。没有这句话，模型会在信息缺失时编造一个看似合理的答案，而你很难分辨哪些是它编的。加上之后，它会先问你要日志、要配置、要版本号，反而更省时间。

参数调整上，约束条目控制在3到5条，太少没效果，太多模型会顾此失彼。推理步骤的字数限制建议在150到300字之间，太短模型会跳过分析直接给答案，太长会挤占输出空间。输出格式的编号层级不要超过三级，否则模型容易漏掉某一层。

2.3 把提示词存成可版本管理的文件

专家提示词用多了之后，最大的问题是记不住哪个版本效果好。我一般会把每个提示词存成一个独立的.md文件，用 Git 管理，文件名格式是场景-版本号.md，比如code-review-v3.md。每次调整后在文件头部加一行变更说明：

<!-- v3: 增加“不要建议引入新依赖”约束，修复了之前总推荐 lodash 的问题 -->

这样做的好处是，当某个提示词突然效果变差时，可以快速回滚到上一个版本。提示词工程本质上和写代码一样，需要版本控制和回归测试。每次修改后，用同一组测试输入跑一遍，对比输出差异，确认没有引入新的问题。

3. 代码审查与重构类提示词：让 ChatGPT 像 Tech Lead 一样挑毛病

3.1 代码审查提示词：从“写得不错”到“第7行有空指针风险”

普通用户让 ChatGPT 审查代码，得到的回复通常是“代码结构清晰，逻辑正确，建议添加注释”。这种输出没有任何价值。专家提示词要把审查维度拆开，强制模型逐项检查。

# 角色 你是一个严格的后端代码审查者，专注于[语言]的[框架]项目。 # 任务 审查以下代码，找出所有可能导致运行时错误、性能瓶颈、安全漏洞的问题。 # 输入 [粘贴代码] # 审查维度 1. 空值/边界条件：每个函数入口参数是否可能为 null/undefined/空集合 2. 并发安全：共享变量是否有竞态条件 3. 资源泄漏：文件句柄、数据库连接、网络连接是否在所有路径上关闭 4. 错误处理：异常是否被吞掉，错误信息是否包含足够上下文 5. 性能：是否有 N+1 查询、不必要的循环嵌套、大对象拷贝 # 约束 - 每个问题必须给出具体行号和触发条件 - 不要提“建议添加注释”“建议格式化”这类无关痛痒的意见 - 如果某维度没有问题，明确说“未发现” # 输出格式 按严重程度排序，每条包含：行号 | 问题类型 | 触发条件 | 修复建议

这个提示词的关键在于审查维度的枚举。不枚举的话，模型只会做表面检查。枚举之后，它会逐项对照，输出质量稳定得多。参数上，审查维度控制在5到7个，覆盖最常见的翻车场景。如果项目有特定规范，比如“所有数据库操作必须在事务中”，可以加一条自定义维度。

3.2 重构提示词：保留行为不变的前提下改善结构

重构类提示词的核心约束是“行为不变”。不加这条约束，模型会顺手改掉它认为不合理的业务逻辑，导致测试挂掉。

# 角色 你是一个专注于可测试性和可维护性的[语言]工程师。 # 任务 重构以下代码，改善其结构，但保持所有对外行为完全不变。 # 输入 [粘贴代码] # 约束 - 不改变任何公开函数的签名和返回值 - 不改变任何错误码和异常类型 - 不引入新的第三方依赖 - 如果发现疑似 bug，单独列出，不要直接修复 # 重构目标 1. 消除重复代码 2. 降低函数复杂度（每个函数不超过20行） 3. 提取可测试的纯函数 4. 改善命名，使意图明确 # 输出格式 1. 重构前问题清单 2. 重构后代码 3. 行为不变性说明（哪些地方容易改出问题）

“如果发现疑似 bug，单独列出，不要直接修复”这条约束非常重要。重构和修 bug 是两件事，混在一起做，一旦测试失败，你分不清是重构改坏了还是修 bug 修错了。分开之后，重构的 diff 更干净，review 也更快。

3.3 测试用例生成提示词：覆盖边界而不是凑数量

让 ChatGPT 生成测试用例，默认输出是一堆正常路径的测试，边界条件全靠你自己补。专家提示词要强制它按等价类划分和边界值分析来生成。

# 角色 你是一个专注于边界条件覆盖的测试工程师。 # 任务 为以下函数生成单元测试，使用[测试框架]。 # 输入 [粘贴函数代码] # 覆盖要求 1. 每个参数的等价类划分：正常值、边界值、异常值 2. 空集合、单元素集合、多元素集合 3. 数值参数的：0、负数、最大值、最小值、溢出边界 4. 字符串参数的：空串、超长串、特殊字符、Unicode 5. 并发场景（如适用）：同时调用、顺序依赖 # 约束 - 每个测试用例必须包含：输入、预期输出、测试意图说明 - 不要生成重复覆盖的用例 - 如果某个边界无法测试，说明原因 # 输出格式 按参数分组，每组包含：用例名称 | 输入 | 预期输出 | 意图

这个提示词生成出来的测试用例数量通常是普通提示词的2到3倍，但冗余度更低。参数上，覆盖要求可以根据函数类型调整，比如纯计算函数重点覆盖数值边界，IO 函数重点覆盖异常路径。

4. 架构设计与故障排查类提示词：把黑匣子拆成可验证的步骤

4.1 架构设计提示词：先问约束再给方案

架构设计类问题最容易翻车的地方是：你描述了一个模糊需求，模型直接给出一套微服务方案，而你实际上只是一个日活几百的内部工具。专家提示词要强制模型先确认约束条件。

# 角色 你是一个务实的系统架构师，擅长在资源受限条件下做技术选型。 # 任务 根据以下需求，给出架构方案。但在给出方案之前，先列出你需要确认的约束条件。 # 输入 [粘贴需求描述] # 必须确认的约束 1. 预期数据量和增长速度 2. 读写比例和延迟要求 3. 团队规模和现有技术栈 4. 部署环境（单机/容器/云服务） 5. 预算和运维能力 # 约束 - 如果需求中未提及上述信息，先提问，不要假设 - 方案必须包含至少一个“不做什么”的说明 - 不要推荐团队没有经验的技术栈 # 输出格式 1. 待确认约束清单 2. 在假设条件下的方案（标注哪些是假设） 3. 关键取舍说明 4. 最小可行版本与演进路径

这个提示词的核心价值在于“先提问再回答”。大多数架构翻车不是因为方案本身错，而是因为约束没对齐。让模型先问清楚，比它直接给一个看似完美的方案有用得多。

4.2 故障排查提示词：从日志到根因的推理链

故障排查类提示词的关键是强制模型建立“现象→假设→验证→结论”的推理链，而不是直接跳到结论。

# 角色 你是一个擅长分布式系统故障排查的 SRE。 # 任务 根据以下现象和日志，分析可能的根因，并给出验证步骤。 # 输入 现象：[描述] 日志：[粘贴关键日志] 最近变更：[描述] # 推理要求 1. 列出所有可能的原因，按可能性排序 2. 对每个原因，给出验证方法（命令/查询/检查项） 3. 说明每个验证方法的预期结果和异常结果的含义 4. 不要在没有验证的情况下给出最终结论 # 约束 - 优先检查最近变更引入的问题 - 区分“症状”和“根因” - 如果日志不足以定位，明确说明需要补充什么信息 # 输出格式 假设列表 | 可能性 | 验证方法 | 预期结果 | 异常含义

这个提示词在实际排查中非常有用。它不会直接告诉你“是数据库连接池满了”，而是列出“连接池满”“慢查询堆积”“网络抖动”三个假设，然后让你去查连接池监控、慢查询日志、网络延迟。你按步骤验证，很快就能排除掉两个。

4.3 性能优化提示词：先测量再优化

性能优化类提示词要强制模型区分“猜测”和“测量”。没有测量数据的优化建议，大概率是浪费时间。

# 角色 你是一个专注于性能优化的[语言]工程师。 # 任务 分析以下代码的性能瓶颈，给出优化方案。 # 输入 [粘贴代码] 性能数据：[如有，粘贴 profiling 结果] # 约束 - 如果没有性能数据，先列出需要采集的指标和采集方法 - 优化方案必须说明预期收益和验证方法 - 不要建议“用更快的语言重写”这类不可操作的方案 - 优先优化热点路径，而不是均匀优化所有代码 # 输出格式 1. 需要采集的性能指标 2. 基于现有数据的瓶颈分析 3. 优化方案（按预期收益排序） 4. 每个方案的验证方法和回滚条件

“回滚条件”这一条经常被忽略。性能优化有时会引入新的问题，比如缓存导致数据不一致。提前想好什么情况下回滚，比优化本身更重要。

5. 避坑与常见问题：15个提示词用下来最容易翻车的5个地方

5.1 现象：模型输出越来越长，重点被淹没

原因：提示词里没有长度约束，模型倾向于“全面覆盖”，导致每个点都浅尝辄止。

解决：在输出格式里加一条“总字数不超过800字”或“每个部分不超过3条”。如果模型仍然超长，把约束改成“如果超过限制，优先保留前三条，其余用一句话概括”。

5.2 现象：同一个提示词，昨天好用今天不好用

原因：模型版本更新或上下文窗口变化，导致对提示词的敏感度漂移。这不是玄学，是版本差异。

解决：把提示词存成文件并版本管理，每次模型更新后跑一组固定测试输入，对比输出差异。如果发现退化，调整约束条目的措辞，通常把“不要”改成“禁止”会有效果。

5.3 现象：模型编造不存在的 API 或配置项

原因：提示词没有要求“不确定时明确说明”，模型在知识盲区会编造看似合理的内容。

解决：在约束里加一条“如果某个 API 或配置项你不确定是否存在，标注‘待确认’，不要直接使用”。另外，对于关键代码，要求模型给出官方文档链接或版本号，虽然它可能编链接，但至少能让你意识到需要核实。

5.4 现象：代码能跑但不符合项目规范

原因：提示词没有包含项目特定的编码规范，模型按通用最佳实践输出。

解决：把项目规范压缩成3到5条硬约束，比如“所有数据库操作必须通过 Repository 层”“错误必须用自定义 Error 类型包装”“日志必须包含 traceId”。这些约束直接写进提示词的“约束”部分，比让模型自己猜有效得多。

5.5 现象：多轮对话后模型忘记前面的约束

原因：上下文窗口有限，早期约束被后续对话挤出有效范围。

解决：每轮对话重新粘贴关键约束，或者把约束放在每轮输入的开头。更稳妥的做法是，把提示词拆成“系统级约束”和“本轮任务”两部分，系统级约束每轮都带。

6. 进阶技巧：把15个提示词串成工作流

单个提示词用熟了之后，真正的效率提升来自把它们串成工作流。我目前的工作流是这样的：先用架构设计提示词确认约束和方案，再用代码生成提示词产出初版，接着用代码审查提示词过一遍，然后用测试用例提示词生成测试，最后用故障排查提示词分析测试失败的原因。五个提示词串起来，基本覆盖了从设计到验证的完整闭环。

这里有一个关键技巧：每个提示词的输出格式要能直接作为下一个提示词的输入。比如代码审查的输出是“行号 | 问题类型 | 触发条件 | 修复建议”的表格，这个表格可以直接粘贴给重构提示词，让它按优先级逐条修复。格式不统一的话，中间需要人工转换，效率会打折扣。

另一个技巧是给每个提示词加一个“置信度”字段。让模型在输出末尾标注它对本次回答的置信度（高/中/低），低置信度的部分你会自然多留个心眼去核实。这个字段不占多少输出空间，但能帮你快速判断哪些结论需要验证。

最后说一个我踩过的坑：不要试图用一个提示词解决所有问题。我早期写过一个“万能提示词”，结果它在每个场景下都表现平庸。后来拆成15个专用提示词，每个只解决一类问题，整体效率反而高得多。提示词工程和写函数一样，单一职责原则同样适用。希望帮到你。

本文还有配套的精品资源，点击获取