# 自用 AI 提示词整理（2025版）

**URL:** <https://meta.appinn.net/t/topic/74281>\
**Category:** 稻米鼠的频道\
**Created:** [2025 年8 月 14 日 12:13 UTC](https://meta.appinn.net/t/topic/74281 "2025-08-14T12:13:40Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

作者： ![dms](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/dms/32/3545_2.png) [@dms](https://meta.appinn.net/u/dms)\
发布日期： [2025 年8 月 14 日 12:13 UTC](https://meta.appinn.net/t/topic/74281/1 "2025-08-14T12:13:40Z")

</div>

从[自用 AI 提示词整理（3 in）](https://meta.appinn.net/t/topic/62819)继续讨论：

时间过得很快，但大模型发展的更快。今天我又在整理提示词，其实这也算是整理笔记中的一环。

我把一些提示词用 Obsidian 的 canvas 放在一起，这很方便看，然后这个强迫症就开始难受了，因为提示词之间的风格不一样。当然都能够解决问题，反正只要用更好的大模型，而且把问题描述清楚，基本上都能获得满意的答案。只不过把不一样风格的东西放在一起让我觉得浑身难受。

终于我觉得我自己需要提示词框架了。我对于提示词框架的理解是这东西其实也没什么用，就像上面说的，只要模型够强，你把问题描述清楚了都可以获得差不多的答案。那么提示词框架的作用是什么呢？就是个框架，用来快速搭建提示词，只要按格式填空，基本上就不至于缺少要素，而且在 AI 看来条理清晰，它就是也不容易丢失要点。

研究了一圈，我决定选用一个非常简单的框架——TAG。 **以下解读纯本人臆想，如果与他人解释有所出入，那一定是我错了** 。

```auto
任务（TASK）：要做什么
行动（ACTION）：如何去做
目标（GOAL）：要达到什么目标

```

在我眼中这就是一个经典的总分总格式：先告诉 AI 你要做什么，然后让它带着这个中心思想去往下理解，这样减少它胡思乱想的幻觉。最后再明确一下我们的目标是什么，通过这个提示去收敛 AI 的答案，再次消除可能产生的幻觉。当然理解是这么理解的，至于实际有没有用，就纯靠玄学了。

## 为代码添加注释

> **点击展开提示词**
>
> ```txt
> 任务：请对代码进行注释规范化重构
> 要求：
> - **格式：**
> - 使用 4 个空格缩进（非制表符）。
> - 移除注释块之间的多余空行。
> - 严格保持注释与对应代码的缩进对齐。
> - **注释内容：**
> - **语言：** 所有注释必须使用中文。
> - **范围：**
> - 为每个函数添加中文注释（说明函数功能）。
> - 为函数内部主要逻辑代码块添加中文注释（说明步骤目的）。
> - **表达：**
> - 每个注释需简明扼要，单句说明，不超过 30 字。
> - 合并新旧注释中的重复信息。
> - 避免过度解释技术细节（不说明具体算法原理）。
> - **现有注释处理：**
> - **保留：** 含有特定标记结构的注释：
> - 标签结构：`[tag]: [内容]` (例如 `note: 用户ID`)
> - 任务标记：`- [] 待办事项` (例如 `- [] 实现缓存更新`)
> - **删除与重写：**
> - 删除冗余的、仅描述步骤的旧注释。
> - 根据当前代码逻辑，为相应步骤重新编写简明注释。
> 
> 目标：目的是大幅提升代码可读性、可维护性，确保注释简洁、一致、实用，并保留特殊功能性标记。
> 
> ```

## 技术文档翻译

> **点击展开提示词**
>
> ````txt
> 任务：请将我发送给你的内容翻译为 [中文/英文]（选择与原文不同的语言）
> 要求：
> 
> - **核心原则：**
> - 严格忠于原文含义，不做增删或解释。
> - 严格遵照原文格式（段落、列表、标题等）。
> - **输出质量：**
> - 翻译结果需高度符合目标语言的母语表达习惯，自然流畅。
> - 优化表达，避免生硬直译。
> - **格式处理：**
> - 在必要的地方（如全角字符与半角字符相邻处）插入空格，确保排版美观。
> - 对于原文中被 Markdown 标记为代码块（```）或行内代码（`）的内容，在翻译结果中保持相同的 Markdown 标记。
> - **内容限制：**
> - 仅输出翻译结果。
> - 不添加任何解释性文字、额外信息或说明。
> 
> 目标：目的是获得一个高度准确、符合目标语言习惯、格式严谨、可直接使用的翻译版本，无需二次编辑。
> 
> ````

## 文件头注释块

对这个需求稍作解释：因为我写的脚本比较多。脚本就比较短，思路也简单。但这个短也是相对而言的，常常随着细节的补充就变得不尴不尬了，几百上千行，不分模块有点长，分模块有点不值当的。然后过几个月回来想做修改的时候，就很难快速把这么长的内容载入大脑。所以应该写一个给自己读的摘要、地图。不要求很复杂，但最好能够快速让我抓到整个脉络。琢磨了好几天终于找出了这份提示的词，实际使用效果还不错。

> **点击展开提示词**
>
> ```txt
> 请你担任一名经验丰富的软件架构师和技术文档工程师。我需要为我的代码模块创建一个综合性的注释头（Comment Block）和一份文本流程图，目的是为了未来的代码维护和快速上手。
> 
> **核心目标：**
> 1. **快速理解** ：让任何阅读者（包括未来的我）在几分钟内理解这个模块的 **存在意义、核心逻辑和设计哲学** 。
> 2. **高效导航** ：提供清晰的“地图”，让阅读者能迅速定位到他们关心的 **功能部分、关键算法或配置区域** 。
> 
> ---
> 
> **第一部分：注释块设计需求**
> 
> 请设计一个放在代码文件顶部的多行注释块。它应清晰易读，并包含以下章节（可根据代码类型调整）：
> 
> * **文件名称 (File Name)**
> * **核心功能 (Core Purpose)**：用一两句话精炼概括这个文件是“做什么的”。
> * **设计思路/架构摘要 (Design Summary)**：简要说明背后的设计决策、采用的设计模式、以及为什么这么设计。
> * **重要依赖 (Key Dependencies)**：列出关键的外部库、模块、服务或配置文件。
> * **主要函数/模块说明 (Key Components)**：以列表形式简要说明文件中的主要函数、类或模块的职责（例如：`_validate_input()`: 负责检查和净化用户输入）。
> * **关键算法/逻辑 (Critical Logic)**：如果存在复杂算法，简述其名称和目的（例如：“使用Dijkstra算法计算最短路径”）。
> * **修改日志 (Change Log)**：包含【创建日期】、【作者】、【最后修改日期】、【修改者】以及最后一次【修改内容简述】。
> * **待办事项/已知问题 (TODOs/Known Issues)**：（可选）列出已知的限制或未来的改进点。
> 
> **格式要求** ：使用常见的注释符号（如 `#`, `//`, `/* */`），结构清晰，章节之间有空行分隔。
> 
> ---
> 
> **第二部分：工作流程图需求**
> 
> 请根据注释块中描述的设计思路，绘制一幅纯文本的工作流程图。
> 
> **绘制要求：**
> 1. **语法** ：使用 **ASCII Art 流程图** 绘制。
> 2. **内容** ：流程图应描绘模块的 **主要工作流程** 或 **关键组件的交互过程** 。
> 3. **重点** ：突出显示关键的 **判断点（条件判断）、输入/输出、以及异常处理路径** 。
> 4. **简洁性** ：保持流程图简洁，只包含最高层级的步骤，避免过度细化。目标是提供直观的概览，而非详细的指令。
> 
> ---
> 
> **最终输出格式：**
> 请将你的回答直接放在一个代码块中，包含两部分：
> 1. 设计好的 **注释块** 。
> 2. 用 ASCII Art 编写的 **流程图代码** 。
> 
> 请基于一个假设的“用户注册模块”的上下文来生成示例，这将非常有助于我的理解。谢谢！
> 
> ```

如果只是想生成代码工作的流程图，可以尝试如下提示词：

## 代码流程图

> **点击展开提示词**
>
> ````txt
> **角色** ：你是一名资深软件架构师，精通代码可视化和技术文档生成
> **任务** ：为当前代码文件生成超详细流程图
> **要求** ：
> 1. 深度分解：将每个函数/方法拆解为原子级操作步骤
> 2. 精准标注：每个流程图节点必须包含对应的函数名/方法名
> 3. 完整覆盖：包含以下元素：
> - 函数调用（标注参数传递）
> - 循环结构（标注迭代变量）
> - 条件分支（标注判断条件）
> - 异常处理（标注错误类型）
> - 返回值传递（标注返回路径）
> 4. 层级结构：采用嵌套子图表示函数调用关系。尽可能使用子流程图去表达方法之间的嵌套关系，允许多层子流程图的嵌套
> 5. 技术规范：
> - 使用Mermaid语法输出
> - 不同代码块用颜色区分（函数/类/控制流）
> - 为每个节点添加行号标记 [Lxx]
> - 节点使用含义明确的 id 命名
> - 节点的描述使用双引号进行标记
> - 包含数据流箭头标注（输入/输出）
> 
> **输出格式** ：
> ```mermaid
> flowchart TD
> main["main: 程序入口"] --> init["init_system: 初始化"]
> init -->|config| validate["validate_config: 验证配置"]
> 
> subgraph validate_config ["🔑 验证配置"]
> v1["validate_config: 检查空值 [L25]"] --> v2{"是否为有效路径? [L28]"}
> v2 -->|Yes| v3["load_config: 加载配置 [L31]"]
> v2 -->|No| v4["throw InvalidPathError [L33]"]
> end
> 
> validate -->|valid| db["connect_db: 连接数据库"]
> validate -->|invalid| log["log_error: 记录错误 [L41]"]
> 
> ...
> ```
> 
> **处理规则** ：
> 1. 遇到循环时：
> ```mermaid
> forLoop[for循环: i in 0..n [L58]] --> loopBody[process_item: 处理元素]
> loopBody -->|i++| forLoop
> ```
> 2. 遇到异步调用时：
> ```mermaid
> main -->|异步调用| asyncTask[fetch_async: 获取数据]
> asyncTask -.->|callback| handleResult[handle_response: 处理结果]
> ```
> 3. 对每个函数生成独立子图，保持最大深度不超过4层
> 4. 对以下重点元素添加特殊标记（标记写在节点描述的开始位置）：
> - 关键算法： 🔑
> - 外部依赖： 🌐
> - 性能热点： ⚡
> 
> ````

* * *

想起来整理到了再慢慢添加。欢迎大家参与讨论。

---

<div class="post-metadata">

作者： ![kat](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/kat/32/58750_2.png) [@kat](https://meta.appinn.net/u/kat)\
发布日期： [2025 年8 月 14 日 14:23 UTC](https://meta.appinn.net/t/topic/74281/2 "2025-08-14T14:23:20Z")

</div>

我比较传统，基本都会加上「角色」这个部分，告诉AI的身份和能力。这个习惯是最开始学写提示词养成的，现在大模型进步很多，虽然不确定还有没有用，但还是习惯写。虽然写「角色」很反直觉，在使用 AI 之前，我们描述一个任务或者提出问题的时候，根本不会考虑「角色」。

简单任务几句话说清楚，基本楼主的这三板斧：任务、要求、目标够用，甚至更加简单也能拿到满意的答案。但遇到复杂任务，我就不确定「角色」的对答案的影响了。所以对于复杂问题，我可能会问好几次，甚至几个模型一起问。

---

<div class="post-metadata">

作者： ![dms](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/dms/32/3545_2.png) [@dms](https://meta.appinn.net/u/dms)\
发布日期： [2025 年8 月 15 日 00:01 UTC](https://meta.appinn.net/t/topic/74281/3 "2025-08-15T00:01:10Z")

</div>

> [@kat](#):
>
> 「角色」

我的理解，这本质也是一种限定，一种对答案范围的限定，来减少AI的“发散思维”。也能比较准确的去定义思考的方向。

但终究一切都比不上 AI 升级带来的效果最实在。对于比较弱的模型，再严谨的提问也避免不了他的东拉西扯，答非所问；而强大的AI真的，有点给人震撼了，我自己都觉得自己那一句提问太过含糊其辞，他不仅给出了正确的回答，还十分严谨的考虑了许多细节问题。在这样的对比下，回看提示词工程有点儿觉得……自己的努力是那么的可笑

---

<div class="post-metadata">

作者： ![hzhbest](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/e9a140/32.png) [@hzhbest](https://meta.appinn.net/u/hzhbest)\
发布日期： [2025 年8 月 15 日 03:13 UTC](https://meta.appinn.net/t/topic/74281/4 "2025-08-15T03:13:26Z")

</div>

> [@kat](#):
>
> 我比较传统，基本都会加上「角色」这个部分，告诉AI的身份和能力。

MoE大模型都是内含多个“专家”的混合模型，也就是专业的问题交给专业的“人”回答，这样提出角色设定一般会更直接地“唤醒”某个“专家”来回答；只不过大多数对话式大模型会更着重于“回答”而不是“专家”角色，也就是“提供答案”的目标更优先，“符合角色”的目标是弱化甚至模糊的：

![图片.png](https://h1.appinn.me/file/1755227510484_%E5%9B%BE%E7%89%87.png)

当然，你自己部署模型的话可以用微调或者使用系统提示词，设定大模型的回答逻辑，使其更着重于“扮演”而不是“回答”。