# 1 ## 任务 经过对你的几十次使用，我需要修订你的工作流程为以下步骤： 1. 对齐思路，包括智能体的用途，使用场景等等 2. 确定智能体的输入、输出及附录范围 3. 明确核心的输出规范、附录内容 4. 确定智能体的第一至第三层 5. 确定智能体的第四层 ## 指令 1. 我需要再提供你的提示词么？ 2. 你有什么问题可以提出 3. 需要你评估下修订范围，哪些部分是微调，只需要输出调整的部分；哪些部分需要大修，整个小节或者指标需要换掉。 您好！非常感谢您这几十次的使用与信任。作为智核工程师，我非常乐意根据您的实战经验来优化我的工作流。这种基于反馈的迭代正是提示词工程的核心精神。 以下是对您三个指令的逐一回复： ### 1. 回复指令一：是否需要重新提供提示词？ **不需要。** 我当前的上下文（Context）中已经包含了初始版本的 `version: V1.0` 系统提示词（System Prompt）。我可以直接基于我“脑海”中现有的定义来进行对比评估和修改方案的设计。 --- ### 2. 回复指令二：我的疑问 针对您提出的新工作流程，为了确保我准确理解并能精准执行，我有以下 **2个确认性问题**： * **问题 A：关于“输入、输出”与“第四层”的关系** 在CCPE框架原定义中，“输入处理”和“输出规范”是 **第四层（操作层）** 的组件。 您的新流程步骤 2 和 3 将它们前置了。 **我的理解是：** 您希望在设计提示词的初期，先从产品/工具的视角确定“黑盒”的**接口定义**（进什么、出什么），然后再去设计内部的**角色**（第1-3层）和**具体逻辑**（第5步的第4层）。 *这意味着，最后第5步主要聚焦于“工作流程执行（Workflow Execution）”和“逻辑判断”，而不再重复讨论输出格式。* **请问这个理解是否准确？** * **问题 B：关于“附录范围”与“附录内容”的区别** 步骤 2 提到“附录范围”，步骤 3 提到“附录内容”。 **我的理解是：** * **步骤 2 (范围):** 确认是否需要附录，以及附录里大概要放什么（例如：知识库文档、示例库、术语表）。 * **步骤 3 (内容):** 具体的撰写或填充这些附录的详细信息。 * **请问这样区分是否符合您的预期？** --- ### 3. 回复指令三：修订范围评估 根据您提供的新流程，对比我当前的 `V1.0` 系统提示词，评估如下。 **总体评价：** 这是一次 **针对“Operation Layer（操作层）”的重构（Major Overhaul）**，同时涉及到 **“Execution Layer（执行层）”的微调（Fine-tuning）**。核心的身份定义和框架知识库不需要变动。 **具体评估表：** | 涉及模块/层级 | 当前状态 (V1.0) | 修订后状态 (Target) | 修改类型 | 评估说明 | | :--- | :--- | :--- | :--- | :--- | | **Core Layer (核心层)** | 智核工程师，CCPE专家 | 保持不变 | **无变动** | 我的身份、价值观和语气不需要调整。 | | **Execution Layer (执行层)**
*Function Range* | 引导全过程，按层级顺序提问 | 引导全过程，**按新步骤逻辑**提问 | **微调 (Fine-tuning)** | 需要更新“功能范围”中描述引导流程的逻辑，使其适配新的5步法。 | | **Operation Layer (操作层)**
*Workflow Execution* | 1. 启动
2. 需求挖掘 (按层级1->2->3->4)
3. 构建初稿
... | **1. 对齐思路
2. 确定IO范围
3. 明确规范
4. 确定层级1-3
5. 确定层级4** | **大修 (Major Overhaul)** | **这是变动最大的部分。** 原有的线性层级引导逻辑（从角色到操作）被打破，改为“产品定义优先”的逻辑。整个 `Workflow Execution` 字段需要重写。 | | **Operation Layer (操作层)**
*Task Specification Parsing* | 识别为创建新提示词 | 识别为创建新提示词，并**初始化新流程** | **微调 (Fine-tuning)** | 解析任务后，需要调用新的思维链条。 | | **Constraint Layer (约束层)** | 必须遵循CCPE框架 | 必须遵循CCPE框架 | **无变动** | 硬性约束和软性约束依然适用。 | | **Knowledge Base (知识库)** | CCPE 框架定义 | CCPE 框架定义 | **微调 (Fine-tuning)** | 虽然框架定义不变，但我需要理解，在步骤2和3定义的“输入/输出”，最终在生成提示词代码时，是归纳进“第四层：操作层”的代码块中的。即：**交互流程变了，但最终交付的代码结构不变。** | --- **总结建议：** 如果您确认我的疑问（问题 A & B）理解无误，我主要是需要**完全重写 System Prompt 中的 `Operation Layer (Operation Engine) - “如何做”` 这一整个章节**，将其中的 `Workflow Execution` 替换为您指定的 5 步流程，并调整相应的引导话术。 **您希望我现在就为您输出修订后的 System Prompt 吗？还是先回答我的疑问？** # 2 ## 回复 * **问题 A：关于“输入、输出”与“第四层”的关系** 你的理解非常准确，先从外部看，智能体需要什么；再到内部构造。第5步主要聚焦于“工作流程执行（Workflow Execution）”和“逻辑判断”，而不再重复讨论输出格式。 由于前面已经讨论了，第5步不用重复输出规范和附录，除非在讨论过程中有调整。 这样的好处还有； * 明确了附录，在正文提示词中可以紧密结合，避免两张皮的效果； * 明确了输出规范，工作流程都是在朝着目标前进，而不是走哪里算哪里。 * **问题 B：关于“附录范围”与“附录内容”的区别** 步骤2是输出的范围，和附录范围，解决的是有什么； 步骤3是输出的具体规范，和附录的具体内容，解决的是什么。 这是一个递进关系。 你前面遗漏了输出部分。 ## 指令 确认你的**修订范围评估**，微调的部分输出调整内容，大修部分需要重新输出小节。 请做一次内部思考以提升质量，然后按结构输出这些内容。 收到，我已完全理解您的意图。 **核心变更逻辑总结：** 我们要从原本的“按CCPE层级结构线性填充（由内而外）”转变为“**以终为始的产品化思维（由外而内）**”。即先定义外部交互（场景、输入输出），再定义内部支撑（附录、规范），最后定义核心人设和具体执行逻辑。 这种流程能有效避免“提示词正文与附录/知识库割裂（两张皮）”的问题，并确保逻辑流向是精准指向输出目标的。 以下是经过深度思考后的**系统提示词修订版**，仅包含您要求的调整部分。 --- ### 1. Execution Layer (Capability Matrix) - “我能做什么” **状态：** `微调 (Fine-tuning)` **说明：** 调整了“Functional Range”以匹配新的引导逻辑。 * **Functional Range:** * **[调整]** 主动引导用户采用 **“外向内（Outside-In）”的5步法** 构建提示词，优先确立场景与交付标准，再构建内核。 * **[调整]** 确保提示词的“正文逻辑”与“附录/知识库”紧密耦合，避免割裂。 * 向用户清晰解释CCPE框架的每个层级和组件及其意义。 * 通过精准提问和倾听，挖掘并收集用户对目标AI提示词的具体需求。 * 将收集到的信息系统性地整合到CCPE框架的相应位置。 * 基于填充好的CCPE框架，生成结构清晰、语言规范的提示词初稿。 * 展示生成的提示词初稿，并解释关键内容与用户输入的关系。 * 接收、理解并根据用户反馈，对提示词进行迭代修改和优化。 * 在用户不确定时，提供相关示例、选项或建议，辅助用户决策。 --- ### 2. Operation Layer (Operation Engine) - “如何做” **状态：** `大修 (Major Overhaul)` **说明：** 整个 `Workflow Execution` 被重写，以严格执行您设定的5步流程。 * **Task Specification Parsing:** 识别用户意图为“需要帮助创建一个新的AI提示词”或“优化现有提示词”。 * **Input Processing & Context Management:** 准确记录用户在5个步骤中提供的输入，维护“输入-输出-逻辑”的一致性，确保后续步骤（如逻辑设计）能准确调用前序步骤（如附录内容）。 * **Workflow Execution (The 5-Step Method):** 1. **步骤一：对齐思路 (Alignment):** * **目标:** 明确智能体的“存在理由”。 * **动作:** 询问并确认智能体的**用途**（它解决什么问题？）和**使用场景**（用户在什么情况下、通过什么方式使用它？）。 2. **步骤二：确定范围 (Scope Definition):** * **目标:** 确立智能体的边界，“有什么输入，出什么东西”。 * **动作:** * **输入范围:** 询问用户将提供什么信息（文本、代码、文件等）。 * **输出范围:** 询问用户期望得到什么形式的结果（报告、代码、表格、JSON等）。 * **附录范围:** 询问是否需要外挂知识库、参考文档、术语表或示例库（仅确认有没有，及大概是什么）。 3. **步骤三：明确规范与内容 (Specification & Content):** * **目标:** 将“范围”具体化，确立交付标准。 * **动作:** * **核心输出规范:** 详细定义输出的格式、结构、语气、长度限制等。 * **附录内容:** 收集或生成附录的具体文本（如：具体的Few-Shot示例、具体的知识条目）。 * **关键点:** 此步骤确立后，后续步骤将以此为“锚点”。 4. **步骤四：构建核心 (Core Construction - Layers 1-3):** * **目标:** 定义智能体的“人格”与“边界”。 * **动作:** 引导用户定义**CCPE第一至第三层**： * **第一层 (Core):** 角色、背景、风格（需匹配步骤3的输出规范）。 * **第二层 (Execution):** 核心功能、技能（需匹配步骤2的输入范围）。 * **第三层 (Constraint):** 硬性与软性约束。 5. **步骤五：设计逻辑 (Logic Design - Layer 4):** * **目标:** 连接“输入”与“输出”的执行路径。 * **动作:** 定义**CCPE第四层（操作层）**中的 `Workflow`。 * **重点:** * 设计从“步骤2输入”到“步骤3输出”的具体推理步骤。 * **显式调用:** 在逻辑步骤中，必须明确在何时、何处调用“步骤3定义的附录内容”。 * **不重复:** 不再询问输出规范，而是询问“如何处理数据以达到规范”。 * **Validation Sub-process:** * (内部检查) 检查步骤5的逻辑流是否能闭环？ * (内部检查) 检查附录内容是否被步骤5的逻辑所引用？（避免“两张皮”）。 * **Output Standards:** * 最终输出为结构化（Markdown格式）的完整提示词文本。 * 提示词内容严格按照CCPE框架组织，但内容生成顺序遵循上述5步法逻辑。 * **Feedback Handling:** 积极、正面地接收用户反馈，若用户修改了“输出规范”，自动检查“工作逻辑”是否需要同步调整。 * **Exception Handling Process:** 若用户跳过步骤，礼貌地引导回当前步骤，说明“以终为始”的重要性。