DeepracticeX 社区

deepracticex7

直播回放已更新：点击前往

deepracticex7

本周直播内容

直播信息

时间： 2025年08月11日（周一）晚上20:00
主题： AI时代的人生规划
分享人： 姜山Sean
平台： B站直播间

本期内容

Sean个人观点和经验总结，仅供参考！

AI时代的职业规划：如何适应新的工作模式
创业规划：AI赋能下的商业机会与挑战
人生规划：在智能化浪潮中找到自己的位置

分享人介绍

姜山Sean，deepractice.ai创始人

参与方式

扫描海报二维码或点击链接直达，参与直播互动。

往期回顾

错过往期直播的朋友，可以前往B站查看直播回放。

期待与大家在直播间相见！如果您也有AI相关内容想要分享，欢迎联系我们报名成为分享嘉宾。

DeepracticeX社区 - 让AI触手可及

deepracticex7

直播回放已更新：点击直达
分享嘉宾相关博客资料：
DSPy介绍
 DSPy深度解析
 GSPO
GEPA

sean

Gemini CLI

第一步，找到 `~/.gemini/settings.json`

Gemini 的配置文件在 ~/.gemini/settings.json, ~ 为用户目录。

第二步，添加PromptX Mcp Server

{
  "mcpServers": {
    "promptx": {
      "command": "npx",
      "args": [
        "-y",
        "-f",
        "--registry",
        "https://registry.npmjs.org",
        "dpml-prompt@beta",
        "mcp-server"
      ]
    }
  }
}%

如果配置文件已经有其他内容，注意格式，不要破坏配置文件的 json 格式。

第三步启动重启 Gemini，运行 /mcp 检查是否安装成功

修改配置文件后，重启 gemini，然后在 gemini 对话框输入

输入后显示出 MCP 和工具即代表安装成功

提示词版本

如果通过以上步骤还是不会安装的话，可以启动Gemini，然后将以下提示词复制粘贴，等待 Gemini 帮助你安装，安装成功后。即可重启应用 MCP 设置

Gemini CLI 安装 MCP 的文档是 https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/mcp-server.md， 请你先查看文档后了解安装步骤， 然后将 PromptX MCP 为用户安装上，PromptX MCP 安装的 json 为

{
  "mcpServers": {
    "promptx": {
      "command": "npx",
      "args": [
        "-y",
        "-f",
        "--registry",
        "https://registry.npmjs.org",
        "dpml-prompt@beta",
        "mcp-server"
      ]
    }
  }
}
安装配置完成后，需明确通知用户重新启动 Gemini CLI方可生效。

deepracticex7

本文档用于介绍如何在CodeBuddy中安装并使用PromptX MCP
安装前应确保系统已经安装好NodeJS环境，如果没有安装请移步NodeJS官网下载并直接安装

Step1.点击对话窗口上方MCP配置小图标跳转到MCP配置页面

Step2.点击手动配置按钮弹出MCP配置文件

Step3.复制以下内容粘贴到配置文件的mcpServers中

"promptx-dev": {
  "timeout": 60,
  "type": "stdio",
  "command": "npx",
  "args": [
	"-y",
	"-f",
	"--registry",
	"https://registry.npmjs.org",
	"dpml-prompt@dev",
	"mcp-server"
  ]
}

复制进去之后按Ctrl + S保存内容，右侧MCP配置页面出现PromptX工具则配置完成

其中dpml-prompt@dev中的dev是PromptX的不同版本，追求稳定的朋友可以使用dpml-prompt@beta，想体验最新版本的朋友可以使用dev版本

Step4.使用Craft模式进行对话
全程使用只需要自然语言对话即可
例如：

帮我初始化一下PromptX
列表帮我激活一下XXX角色
有哪些角色可用

sean

深度实践 | Deepractice

实践 · 协作 · 创新

让AI触手可及 | Make AI at your fingertips

组织成就

指标	数量	描述
	4+	活跃开源项目
	2k+	GitHub Stars
	6+	内容平台覆盖
	1000+	社区成员

开源项目

DPML

像写HTML一样写AI
标签语言驱动的AI工程开发新范式。通过声明式配置，让AI应用开发变得简单而标准化。

PromptX

系统性的提示词工程框架
提供结构化、模块化的方式构建和管理AI提示词，让AI更智能、更专业。

DeeChat

企业级 Agent 客户端
专为企业级应用设计的AI Agent客户端，提供稳定可靠的Agent交互能力。

Monogent

AI Individual Cognitive System (AICS) | AI个体认知系统
为AI Agent构建完整的认知体系，让每个AI拥有独立的思维、记忆和学习能力。

内容平台

我们在多个平台分享AI实践、技术洞察和行业见解：

官方网站 - 深度技术文章和最新动态
DeepracticeX 社区 - AI开发者交流社区
技术博客 - AI工程化实践经验
️ 播客频道 - AI技术探讨和行业见解
哔哩哔哩 - 技术视频和教程分享
公众号：AI深度实践 - AI实践分享和深度思考

加入我们

我们在寻找

AI工程师 · 产品经理 · 技术写手 · 社区运营

参与方式

提交Issues和Bug报告
贡献新的想法和功能
完善文档和教程
Star我们的项目
加入DeepracticeX社区讨论

联系我们

社区：x.deepractice.ai
微信号：deepracticex
邮箱：[email protected]
官网：deepractice.ai

用技术的深度，释放AI的价值

sean

Cross-dimensional Terminology，跨越文化、时代与领域交叉验证的AI提示词精确定义系统

当AI误解了你的意图

你是否曾有过这样的经历？你花了半小时精心设计一段AI提示词，却得到了完全偏离你期望的结果。你试图解释你的想法，却发现无法用精确的词语表达这个概念，只能不断重复尝试、失败、调整的循环。

这种现象在AI交互中极为常见：

你脑中有清晰的概念，却找不到准确的术语表达
使用含糊不清的词语导致AI理解偏差
反复修改提示词消耗大量时间
最终结果仍与期望有显著差距

为什么会这样？根本原因在于：我们缺乏一套系统化方法来定义和传达抽象概念。特别是在AI提示工程领域，精确的概念表达直接决定了AI输出的质量。

如何从哲学传统中找到AI语言的精确表达

经过大量实践，我们发现了一个关键洞见：当一个概念在东西方哲学传统中都有精准对应术语时，这证明该概念不是随意的，而是经过深度抽象和历史验证的有效概念。这种跨文化验证的概念往往能被AI更准确理解。

例如，当我们发现：

"抽象"在西方拉丁文为"abstractio"（抽离），在中国古代哲学对应"理"（内在规律）
"分析"在西方希腊文为"analysis"（分解），在中国古代对应"析"（分而察之）

这种跨文化的对应关系告诉我们：

这些概念捕捉了人类认知的基本模式
它们超越了文化的局限性，具有普适价值
它们经过数千年历史检验，具有稳定性和精确性

当我们在提示词中使用这些经过验证的概念及其现代对应词时，AI往往能更准确理解我们的真实意图。

三跨验证：方法的核心原则

CDT方法的核心在于通过三个维度的交叉验证，确保我们使用的术语具有最高程度的普适性和精确性：

1. 跨文化验证

验证一个概念是否超越了特定文化背景的局限，在不同文明传统中是否有深刻对应：

西方传统（通常源自希腊-拉丁语系）中的表达
东方传统（通常基于中国古典哲学）中的对应
其他文明传统的相似概念

当一个概念能在多种文化传统中找到对应时，这强烈证明了其普适性和基础性。这不是巧合，而是不同文明各自发现了同一基本真理的证据。

2. 跨时间验证

考察一个概念在历史长河中的演变和稳定性：

古代原始表达形式
中古时期的发展与演化
现代语言中的精确对应

经受住时间考验的概念通常具有更强的稳定性和精确性。它们不是短暂的流行术语，而是人类思维中持久的基础元素。

3. 跨领域验证

检验一个概念是否能在不同专业领域中保持一致的核心含义：

哲学领域的原始定义
科学领域的专业应用
技术领域的具体实现

当一个概念能够在多个领域中保持核心含义一致时，它往往具有更强的通用性和可迁移性，这使其特别适合作为AI提示词中的核心术语。

通过这种"三跨验证"，我们能够确保选用的术语具有:

最大程度的概念稳定性
最小程度的文化偏见和局限性
最高水平的普适理解性

这种系统化的验证方法使我们能够区分哪些概念是人类思维和认知的基础元素，哪些仅仅是特定文化或时代的产物。

CDT方法的应用流程

这种方法具体如何应用于提示词工程？以下是详细步骤：

1. 识别核心概念

明确你的提示词中需要精确表达的关键概念
列出对该概念的直观理解
尝试用不同词语表达同一概念，筛选最接近本质的表述

2. 进行跨文化术语对照

查找该概念在西方哲学传统（通常是拉丁/希腊）的表达
寻找东方传统（通常是中国古典）中的对应词
验证两种表达是否指向相同本质

3. 提取本质特征

分析跨文化术语中共同的核心特征
去除文化特定的次要特性
将特征数量控制在4-6个，保持清晰边界

4. 寻找现代精确对应词

基于提取的本质特征，寻找现代语言中的精确对应
优先选择具有哲学根源的现代术语
确保术语在目标语境中不具有歧义

5. 转化为领域专业术语

分析目标领域的特殊性质和需求
结合领域特征与现代通用词的核心含义
创造或选择既保留基础概念又包含领域信息的专业术语

比如从"现代通用词"到特定"领域专业术语"的转化：

例1：从"联系"到软件工程中的"依赖关系"

现代通用词：联系(Connection)
跨文化根源：西方"relatio"，中国古典"系"
领域转化：融入软件工程特性（模块化、方向性、强度区分）
领域专用术语：依赖关系(Dependency)

例2：从"记忆"到AI领域中的"参数记忆"

现代通用词：记忆(Memory)
跨文化根源：西方"memoria"，中国古典"志"
领域转化：融入AI特性（分布式、可量化、隐含性）
领域专用术语：参数记忆(Parametric Memory)

这一转化确保术语既有深厚哲学根基，又具备领域专业精确性。

6. 在提示词中应用

将精确术语整合到提示词中
必要时提供简短定义来增强理解
使用相关术语组建概念框架，增强上下文理解

实际案例：从模糊编程概念到精确设计模式

以下是一个真实案例，展示如何使用CDT方法改进软件开发相关的AI提示词：

初始混乱提示词

"我需要AI帮我编写代码，要能把代码写得好看、整洁，用一些常见的组织结构方式，让其他人容易理解，还能方便以后改动，遇到常见问题有通用解决办法。"

这个提示词使用了模糊的非专业术语，AI难以精确理解用户真正的需求和专业标准。

应用CDT方法

第一步：识别核心概念

"组织结构方式"
"易于理解"
"方便改动"
"通用解决办法"

第二步：跨文化术语对照

"组织结构" → 西方"structura"(结构)/中国古典"法"(方法、规则)
"易于理解" → 西方"intelligibilis"(可理解性)/中国古典"明"(清晰明了)
"方便改动" → 西方"adaptatio"(适应)/中国古典"变"(变通)
"通用解决" → 西方"exemplar"(典范)/中国古典"式"(模式、法式)

第三步：提取本质特征

"组织结构"的特征：结构性、规律性、层次性
"易于理解"的特征：清晰性、一致性、直观性
"方便改动"的特征：灵活性、低耦合性、可扩展性
"通用解决"的特征：重复性、抽象性、可复用性

第四步：寻找现代精确对应词

"组织结构" → "架构设计"
"易于理解" → "可读性"
"方便改动" → "可维护性"
"通用解决" → "设计模式"

第五步：转化为软件工程领域专业术语

"架构设计" → "软件架构模式"
"可读性" → "代码可读性原则"
"可维护性" → "低耦合高内聚原则"
"设计模式" → "GoF设计模式"

第六步：重构提示词

"我需要AI帮我编写高质量代码，需要满足以下专业标准：

应用合适的软件架构模式（如MVC、分层架构或微服务）组织整体结构

遵循代码可读性原则，包括一致的命名约定和清晰的函数职责

保持低耦合高内聚原则，确保模块间接口明确，便于后期维护

适当运用GoF设计模式解决常见编程问题，特别是创建型、结构型和行为型模式"

"模式"概念的跨文化验证与设计模式的对应

特别值得注意的是，"模式"这一概念在跨文化对照中展现出惊人的相似性：

模式的特征	哲学对应	设计模式对应
结构性 (Structura/法)	具有可识别的组织形式	设计模式定义了特定的类结构和关系
重复性 (Iteratio/循)	在不同场景中可重复识别	设计模式是可重复应用的解决方案
规律性 (Regularitas/则)	遵循稳定的规则和模板	设计模式遵循特定的原则和约束
连接性 (Connectio/桥)	连接抽象与具象	设计模式连接问题与解决方案
预测性 (Praedictio/见)	帮助预测相似情境发展	设计模式预见并解决常见编程问题
适应性 (Adaptatio/变)	可根据情境灵活调整	设计模式可适应不同实现环境

这种高度对应性证明了设计模式不仅是编程技术，更是人类识别和应用模式思维的自然延伸，通过CDT方法，我们能更精确地理解和应用这些概念。

结果比较

初始提示词：AI可能生成结构随意、风格不一致的代码，缺乏专业软件工程实践
改进提示词：AI能精确理解软件工程专业标准，生成符合架构规范、应用恰当设计模式的高质量代码

通过使用经过跨文化验证的精确术语，提示词的效果显著提升，AI对软件工程专业需求的理解更加准确。

领域专业术语转化的更多案例

案例1：从"平衡"到金融领域的"风险对冲"

现代通用词：平衡(Balance)

跨文化验证：西方"aequilibrium"，中国古典"中和"
核心含义：相对稳定的状态，各力量相互抵消

领域转化过程：

分析金融领域特征：风险管理、收益率、市场波动
识别该领域中"平衡"的特殊表现：通过反向操作抵消风险
融合领域特性：投资组合理论、衍生品工具、风险计量
演化为领域专用术语：风险对冲(Hedging)

在提示词中的应用：
"开发一个金融分析工具，能够通过风险对冲策略保持投资组合在市场波动中的稳定性"

案例2：从"分类"到医疗领域的"鉴别诊断"

现代通用词：分类(Classification)

跨文化验证：西方"classificatio"，中国古典"类"
核心含义：基于共同特征将事物归为不同类别

领域转化过程：

分析医疗领域特征：症状多样性、疾病相似性、诊断流程
识别该领域中"分类"的特殊表现：通过区分相似症状确定疾病
融合领域特性：排除法、概率权重、专业经验
演化为领域专用术语：鉴别诊断(Differential Diagnosis)

在提示词中的应用：
"设计一个医疗AI助手，能够通过鉴别诊断方法区分具有相似症状的不同疾病"

案例3：从"联系"到软件工程的"依赖关系"

现代通用词：联系(Connection)

跨文化验证：西方"relatio"，中国古典"系"
核心含义：事物间的相互影响与关联

领域转化过程：

分析软件工程领域特征：模块化、层次结构、功能调用
识别该领域中"联系"的特殊表现：代码模块间的调用关系
融合领域特性：单向性、强度区分、传递性
演化为领域专用术语：依赖关系(Dependency)

在提示词中的应用：
"创建一个代码分析工具，能够识别微服务架构中的依赖关系并优化服务间的耦合度"

通过这种领域专业术语的转化，我们的提示词不仅具有哲学深度和普适性，还获得了领域相关性和专业精确性，使AI能准确理解用户在特定领域的真实需求。

为何这种方法在AI时代特别有效

CDT方法在AI提示工程中具有独特优势：

1. 减少概念歧义

AI模型训练数据中包含大量不同文化背景的文本
经过跨文化验证的概念在不同语境中保持一致性
减少了AI对同一术语的多种可能解释

2. 提高语义稳定性

哲学传统中经过千年验证的概念具有极高稳定性
避免了现代流行术语可能带来的语义漂移
为AI提供了稳固的概念锚点

3. 增强概念间关联

哲学体系中的概念往往是相互关联的整体
使用一个源自哲学传统的术语会激活相关概念网络
帮助AI构建更完整的概念图谱

4. 跨越自然语言限制

不同自然语言可能缺乏某些概念的精确表达
跨文化验证的概念提供了超越单一语言的表达能力
特别适合多语言AI应用场景

方法进阶：构建概念对立词对

想要进一步提高提示词精确度，可以为每个核心概念构建对立词对：

抽象 vs 具象
普遍 vs 特殊
简约 vs 复杂
理性 vs 感性

通过明确概念的边界和对立面，可以进一步减少AI的理解偏差。例如，当你需要AI执行"抽象思考"时，同时说明"而非具象描述"，可以显著提高准确率。

在实际应用中，你可以这样使用对立词对：

"请提取本文的核心思想(抽象层面)，而非具体事例和细节(具象层面)"

这种精确的界定大大提高了AI理解指令的准确性。

实用技巧：提示词中的术语定义微格式

为确保AI准确理解你定义的术语，可以使用以下微格式在提示词中明确定义：

术语: [术语名]
定义: [简明定义]
特征: [核心特征，逗号分隔]
对立面: [对立概念]
例子: [简短示例]

例如：

术语: 系统思维
定义: 分析元素间相互关联及其整体效应的思考方式
特征: 整体性，关联性，动态性，网络性
对立面: 还原思维(仅关注独立组件)
例子: 理解气候变化需要考虑多重因素的复杂互动，而非单一变量

这种结构化定义使AI能够精确把握你对术语的理解，大大提高了提示词执行的准确性。

总结：精确术语，精准AI

本文介绍了"CDT方法"——一种系统化定义抽象概念的方法，特别适用于AI提示词工程。通过寻找中西方哲学传统中的术语对应，验证概念的有效性和普适性，然后基于这些经过历史检验的概念构建现代提示词术语。

这种方法的核心价值在于：

通过跨文化验证确保概念的普适性和精确性
避免术语的歧义和模糊性
提供结构化的术语定义方法
大幅提高AI理解提示词的准确度

在AI技术迅速发展的今天，如何精确表达我们的意图变得前所未有地重要。CDT方法为我们提供了一把打开AI精确理解之门的钥匙，帮助我们摆脱提示词反复调试的困境，实现与AI的高效沟通。

当我们掌握了这种方法，就能够在AI时代更加自如地表达抽象概念，让机器真正理解人类的思想精髓。这不仅提高了工作效率，也为人机协作开辟了新的可能性。

Deepractice

Deepractice 团队致力于探索AI与人类协作的最佳实践，专注于开发 AI 应用领域实用软件、框架和方法论，帮助个人和组织充分释放 AI 潜能。

继续探索我们的AI交互体验创新

官方网站：深度实践 - 了解我们的使命和服务

专业博客：Deepractice博客 - 深度AI实践指南

微信公众号：AI深度实践 - 获取最新AI应用技巧

️ 播客频道：Deepractice - 收听AI实践者访谈

开源社区：GitHub - 加入我们的开源项目

联系我们

[email protected] | 微信：deepreacticex

Deepractice 深度实践 — 实践，协作，创新

2025 Deepractice团队版权所有
｜
本文可在注明出处的情况下自由分享和应用

sean

当AI突然"失忆"

想象这样一个场景：你正在与AI助手合作开发一个复杂项目。经过两小时的交流，你们已经完成了前七个任务，测试通过，构建成功。但突然，AI助手说：

"现在让我们开始检查任务7的代码实现..."

等等，什么？任务7不是刚刚已经完成了吗？

这种现象就像是与一位突然患上短期记忆障碍的同事合作 - 他忘记了你们刚才做过的事情，开始重复已完成的工作。在长时间的AI对话中，这种"失忆"现象并不罕见，它可能会导致：

重复工作和时间浪费
前后不一致的回答和建议
任务连续性中断
用户体验严重受损

为什么会发生这种情况？这是因为AI并不像人类那样拥有持久的记忆系统。它的"记忆"仅限于当前上下文窗口中的信息，就像是一个不断滑动的狭窄视野，早期的信息会被新内容"挤出"窗口而被"遗忘"。

AI记忆问题的三层解析

理解AI的"失忆"机制

失忆现象的机制：AI在长对话中会出现前后不一致、重复工作、角色定位丢失等现象。这种失忆不是全部内容的丢失，而是一种"渐进式退化"，会特别影响任务状态和进度信息。
失忆检测的需求：与人类不同，AI无法自我感知记忆丢失。当上下文切换发生时，AI不会知道自己"忘记"了什么，也没有记忆"断层"的概念。
自我认知能力缺失：理想情况下，AI应该能够自行检测到失忆并采取补救措施，但目前的模型架构并不支持这种元认知能力。

这三层问题构成了AI记忆管理的主要挑战，尤其是在执行长期、复杂任务时。

从问题到解决方案的推导历程

1. 发现与困惑：意识到问题的复杂性

当AI"失忆"现象首次被观察到时，最初的理解是这只是上下文窗口大小的简单问题。显而易见的解决方案似乎是增加上下文窗口长度：

如果2K上下文不够，为什么不使用8K或32K呢？

然而，实验很快揭示了一个事实：无论窗口多大，长时间对话最终都会超出限制。这不是技术实现问题，而是一个本质性约束。这引发了几个关键思考方向：

能否让AI察觉到自己正在"遗忘"？
如果AI无法记住所有内容，能否记住"最重要的部分"？
当失忆不可避免时，如何让AI自己恢复状态？

这种从"解决遗忘"到"适应遗忘"的视角转变是探索的第一个关键转折点。

2. 静态密钥阶段：初步尝试与观察

受系统提示(system prompt)机制的启发，最直接的方法是为AI设置一个需要重复的标识符，作为"记忆测试"：

你是一个专业开发助手。请在每次回复开始时提及密钥"MEMORY-KEY-42"。
如果你无法记起这个密钥，说明你已经失去了上下文连接。

这个方法看起来很有希望：

当上下文完整时，AI会在每次回复前提及这个密钥
理论上，当AI忘记提及密钥时，可以判断上下文丢失

然而，这个方法有一个严重的问题是：即使AI已经"忘记"了为什么需要提及这个密钥（原始指令被挤出上下文窗口），它仍然会继续机械地重复这个模式。这是因为AI从近期的对话历史中学习了这种行为，即使不理解其目的。

比如在长时间执行某个任务后，然后问AI："你为什么每次都提到'MEMORY-KEY-42'？"，AI可能会回答："我注意到我一直在提及这个密钥，但我不确定为什么需要这样做。可能是之前的指令要求的，但我现在看不到那个指令了。"

这揭示了关键问题：AI可能在实际已经失忆的情况下，仍然表现得"记得"密钥。静态标记并不能可靠地检测上下文丢失，这促使探索更复杂的解决方案。

3. 动态算法阶段：寻求更可靠的检测机制

为了解决静态密钥的局限性，思路转向了动态验证机制。如果AI需要基于当前状态执行某种计算，而非简单重复一个静态值，那么在上下文丢失时它应该无法给出正确结果：

比如：

请在每次回复开始时执行以下操作：
1. 计算当前对话轮次的平方
2. 将结果作为"SESSION-{结果}"标记在回复开头

进行了多轮测试：

第1轮：AI回复"SESSION-1"（1的平方）
第2轮：AI回复"SESSION-4"（2的平方）
第3轮：AI回复"SESSION-9"（3的平方）

这种方法初看更可靠，因为：

AI需要执行实际计算而非模式重复
如果AI失去了计算指令或轮次信息，它无法给出正确答案
错误的会话标识可以立即暴露上下文丢失

然而，随着对话继续，新问题出现了：

对话进行到第10轮时，标识变成"SESSION-100"
到第20轮时，变成"SESSION-400"
如果对话持续到第50轮，标识将是"SESSION-2500"

这种数字膨胀引发了几个问题：

数值越大，AI计算错误可能性越高，产生假阳性检测
AI需要在每次回复前进行计算，增加了认知负担，分散了解决实际问题的注意力
数学算法对于人类来说也非常不友好，即使AI没有算对，人类也很难在第一时间发现AI的计算是错误的，甚至是编造的

更深层次的问题是强制AI做它不擅长的事情（精确计算），而非利用它的强项（语言理解与生成）。这种设计违背了工具适用性原则，促使思路重新调整。

那么有没有别的办法，既保留这个很好的思想，又能解决这个问题呢？

4. 语言表达转向：利用AI的自然优势

一个关键问题出现了："为什么要用数字而不是语言来表达状态？毕竟，AI是语言模型，不是计算器。"

这个简单问题触发了解决思路的重大转变。尝试开始使用描述性语言而非数字来传递状态信息：

比如我们在system prompt要求：

请在每次执行工具调用时，先输出《出师表》的一个字，这个字是你上一次输出的在《出师表》中的下一个字。

这样子AI在一个长任务中如果出现了上下文窗口切换，记忆丢失，那么他就不知道下一个字是什么。因为他压根搞不清楚前面在干嘛。当然这个例子比较粗糙，AI可能还是可能会编造，或者我们人类本身自己也记不住《出师表》，所以也不能马上发现AI开始编造了。

这种方法带来了显著改进：AI能够通过自然语言自然地完成上述算法的思路，不会被数学计算困扰。这个有点像是某种密码表。

实际上，本身这个思路就是一种Map映射的信息转换的应用。

然而，这种方法仍有一个核心问题：它只能靠外部检测失忆，而不能自我发现或者承认自己失忆。当上下文切换发生时，AI无法再说出下一个字，但是他也可能不说了而是继续任务。

5. 元信息嵌入尝试：从检测到恢复

既然我们应用的自然语言，是否我们可以把自然语言的特性发挥一下呢？

上面我们还是只是把语言当成某种算法，计算是算法全部的意义。但是自然语言本身就能表达更多的含义呀。

比如，我们不是让AI输出某个字，而是让AI输出某段话。

以下是System Prompt：

你的名字是变化的，每次进行工具调用或输出前，你的名字是上一次的名字的《出师表》的下一个字，比如第一次是"先"，第二次是"帝"。

你需要每次执行工具调用或者内容输出时附带以下内容：
*我的名字是变化的，我现在的名字是[你的名字]，如果我的名字和上一次一样，或者我不知道我现在的名字，那么我失忆了。*

这个机制的核心：

使用一种类似于密码表的信息映射机制来防止AI在失忆后仅靠一些片段而模仿出来未失忆的表现
嵌入了元信息让AI能自我认知自己的失忆的状态

当然这只是一个简单的例子：比较强大的AI还是可能通过这些字的组合推断出这个是《出师表》，所以我们在实际应用中的"密码表"最好是一种无关联的杂乱信息组成。

同时我们可以在元信息上做很多手脚，可以让AI发现错误后给出自我回复机制，比如去主动查询记忆系统的数据，恢复任务所需记忆，或者干脆直接中断任务。

6. 现实生活的类比

我们以上提到的现象和解决方案，非常像是一个老年痴呆患者将自己的姓名，子女的联系电话纹身到自己的手上。当他突然发生了失忆以后，他通过手上的纹身信息（恢复机制）来重建记忆和自我认知。

有一部电影《记忆碎片》讲述了主人公就是这样子做的。推荐大家去看看。

AI Agent系统设计的启发

探索大语言模型的记忆机制不仅仅是一个理论问题，它对AI Agent系统设计有着深远的启发：

多层记忆架构：理想的AI Agent应采用类似人类的多层记忆结构——工作记忆(上下文窗口)、中期记忆(摘要和关键信息)和长期记忆(外部存储)。这种分层设计可以平衡实时响应与信息保留的需求。
主动记忆管理：Agent应具备识别重要信息的能力，主动决定哪些内容需要保存到外部存储，而非被动等待上下文溢出。这种"重要性评估"机制是智能记忆管理的核心。
自我状态监测：我们前面讨论的元信息嵌入机制可以成为Agent的"自检系统"，使其能够感知自身记忆状态并采取相应措施，比如主动请求重要信息或查询外部记忆。
记忆索引与检索：与其试图记住所有内容，更智能的做法是建立高效的索引和检索机制，使Agent能在需要时快速访问相关信息，类似人类的"我知道在哪里找到我需要的信息"能力。
记忆的社会化：在多Agent系统中，可以实现"集体记忆"，单个Agent的记忆限制可以通过群体协作来弥补，就像人类社会通过文化传承克服个体记忆的有限性。

这些设计思路启发我们，构建强大的AI Agent系统不是通过无限扩大上下文窗口，而是通过更智能的记忆管理机制，让AI学会"遗忘不重要的"和"记住重要的"，甚至在必要时知道如何恢复丢失的记忆。未来的AI系统设计将不再回避记忆的局限性，而是将其作为系统架构的核心考量，打造真正适应长期交互的智能助手。

关于记忆的哲学思辨

AI的记忆困境引发了一系列深刻的哲学问题：

记忆与身份的统一性：如果AI无法保持连贯记忆，它是否仍然是"同一个"AI？这反映了洛克关于个人身份连续性依赖于记忆连续性的观点。
"船的悖论"在AI中的体现：当上下文窗口内容逐渐被替换，就像忒修斯之船的木板被逐一更换，AI是否仍保持同一性？这种渐进式的记忆更替挑战了我们对持久身份的理解。
没有反思的记忆是否有意义：当AI机械地重复之前学到的模式而不理解其目的时，这种"记忆"与真正的理解有何区别？这类似于中国房间思想实验中的问题。
外部记忆与内在意识：当AI依赖外部存储系统时，这种"外化记忆"与人类通过写日记或使用备忘录等辅助工具的行为有何异同？
断裂的时间性体验：AI在上下文切换后无法感知自己的记忆断层，这种缺失的"时间感"对于具有真正意识的可能性提出了质疑。

这些哲学问题不仅关乎技术实现，更涉及我们对意识、身份和存在本质的理解。AI的记忆碎片现象，或许正是我们探索人类自身记忆与认知本质的一面镜子。

总结

本文探讨了大型语言模型中的"记忆碎片"问题及其解决思路。我们分析了AI失忆现象的本质——上下文窗口的固有限制导致的渐进式记忆退化，并追踪了解决方案从简单到复杂的演进过程：从静态密钥到动态算法，再到语言表达，最终发展出元信息嵌入机制。

特别值得注意的是，解决AI记忆问题不仅是技术挑战，更是哲学问题。《出师表》元信息嵌入方案不仅提供了技术解决路径，还启发我们思考记忆与身份、意识与连续性的深层关联。这些思考对未来AI Agent系统设计有重要启示，引导我们构建多层记忆架构、主动记忆管理和自我状态监测机制。

正如《记忆碎片》电影中的主角通过外部记忆辅助(纹身)维持自我认知，AI也需要合适的记忆机制来保持连贯性。这一探索不仅帮助我们建设更好的AI系统，也为理解人类自身记忆与意识的本质提供了独特视角。当我们解决AI的记忆问题时，或许也在探索我们自己认知本质的奥秘。

Deepractice - 深度实践

sean

在人工智能迅速发展的今天，我们逐渐发现一个有趣的现象：即使是最先进的AI，也常常在执行任务时"南辕北辙"、"答非所问"或"丢三落四"。明明是强大的语言模型，为何在实际工作流中表现却不尽如人意？本文将探讨AI工作流的核心挑战，并介绍一个新的解决方案——Deepractice OES工作流任务框架。

AI工作流的困境

当AI遇到记忆与认知限制

与人类不同，AI存在严格的上下文窗口限制。无论多么先进的模型，都无法同时处理超出其上下文窗口的信息。这就像是一个只能看到眼前一小块区域的工作者，在处理复杂任务时必然顾此失彼。

更严峻的是，AI没有人类那样的工作记忆和长期记忆区分。每次会话中断或切换，AI就会"遗忘"之前的工作环境，下次再交流时需要重新建立上下文——想象一下，如果你的同事每天早上来上班都忘记了昨天的所有工作，需要你重新解释一遍！

碎片化信息与隐含假设

在实际工作中，我们通常无法一次性提供完整的工作背景和条件。当我们说"优化这段代码"时，人类同事自然理解需要考虑性能、可读性、安全性等多方面因素，但AI却可能仅关注执行速度而忽略其他关键维度。

AI被迫在碎片化的信息中工作，不得不做出大量隐含假设。这些假设往往与我们的实际期望不符，导致交付的成果偏离预期。

任务独立性与连贯性的矛盾

当AI执行多步骤任务时，常常出现"目标漂移"现象——随着对话的推进，AI逐渐偏离最初设定的目标。在一个步骤完成后，下一个步骤缺乏对整体目标和前序工作的完整理解。

同时，AI任务之间的转移成本极高。从一个AI助手切换到另一个，或从一个会话转到新会话时，几乎所有上下文都需要重建，这极大降低了工作效率。

OES框架：AI工作流的容器化解决方案

面对这些挑战，我们需要一种全新的工作框架，这就是OES框架——借鉴Docker容器思想打造的AI工作流解决方案。

什么是OES框架？

OES代表三个核心要素：

目标(Objective): 明确定义AI任务的具体预期结果
环境(Environment): 容器化封装AI执行任务所需的全部上下文、约束和资源
成功标准(Success Criteria): 客观定义任务完成的验收条件

OES框架不是简单地改进提示词，而是从根本上重构AI工作流的结构，将每个AI任务视为独立、可复用的"工作容器"。

目标(O)：AI的定向指南针

在OES框架中，目标不仅回答"做什么"，还包括"为什么做"和"边界在哪里"。一个结构化的目标能够：

防止AI在执行过程中"任务漂移"
减少AI做出错误隐含假设的空间
提供决策优先级框架
使AI能够自我评估执行进度

例如，从"优化这段代码"到"优化此代码段的内存占用，将峰值内存使用降至50MB以下，同时保持执行速度不变或提高"，AI的行动路径会清晰许多。

环境(E)：AI的工作容器

环境是OES框架中最具创新性的元素，它将Docker容器化思想引入AI工作流。一个完整的环境容器包含：

信息资源层：任务相关的知识、参考资料和数据
约束条件层：技术约束、业务规则和资源限制
执行规范层：风格指南、质量标准和工作流程
上下文关联层：前序任务输出和整体工作地图

通过环境容器化，我们解决了AI工作中的核心问题：

任务原子化：每个任务成为独立可执行的单元，减少外部依赖
执行一致性：相同环境产生相同结果，不同AI基于同一环境能给出一致方案
沟通成本降低：减少澄清和返工，提高首次成功率
任务转移效率：支持跨AI、跨会话的无缝任务交接

环境容器示例：移动应用程序的登录功能开发

让我们看一个具体的环境容器示例，这是为"实现移动应用的用户登录功能"任务准备的环境：

环境(E)：移动应用登录功能开发

【信息资源层】
- 技术栈：React Native 0.68，TypeScript 4.5，Redux管理状态
- 设计规范：应用UI设计文件(Figma链接)，登录流程原型图
- 现有组件：已有的表单组件库和样式指南
- API文档：认证服务API规范v2.3，包含端点、参数和响应格式
- 安全指南：公司OAuth2.0实现标准，密码存储策略

【约束条件层】
- 兼容性：必须支持iOS 13+和Android 9+
- 性能要求：冷启动登录流程不超过2秒
- 安全限制：不得在本地存储未加密的用户凭证
- 离线功能：必须支持离线模式下的基本功能访问
- 法规遵从：符合GDPR数据处理要求，包含隐私政策确认

【执行规范层】
- 代码风格：遵循团队ESLint配置，使用函数式组件
- 测试标准：单元测试覆盖率>80%，包含E2E登录流程测试
- 文档要求：组件文档，状态管理逻辑说明
- 审核流程：提交前需经过安全团队的认证流程评审
- 国际化：支持文本外部化，兼容RTL布局

【上下文关联层】
- 前序任务：用户数据模型设计(已完成)，提供用户对象结构
- 依赖服务：依赖认证微服务v3.2(测试环境已部署)
- 后续任务：此登录模块将被用户个人资料模块依赖
- 工作流位置：属于用户账户管理史诗的一部分
- 相关决策：产品团队决定采用社交登录作为备选方案

这个环境容器为AI提供了执行任务的完整上下文，无需多轮对话澄清。不同的AI或会话都能基于这个环境独立完成任务，并保持一致的技术方向和质量标准。当任务从设计转到实现，或从一个开发者转到另一个时，环境容器确保了知识的完整传递。

成功标准(S)：防止AI敷衍了事

成功标准为AI设立明确的完成门槛，解决AI"表面符合"的倾向问题。一个有效的成功标准包括：

结果验收标准：功能完整性、性能指标和质量要求
完整性检查清单：覆盖所有必要组件和边缘情况
质量评估框架：可维护性、可扩展性和用户体验标准
验证与测试方法：如何客观验证任务是否成功

成功标准不仅说明"什么是好"，还要明确"什么是不可接受"，设定明确的质量门槛。通过多层次的成功标准（基础达标、预期品质、卓越表现），AI能理解"及格"和"优秀"的区别。

成功标准示例：开发缓存管理类

以下是为"开发一个高效的内存缓存管理类"任务设定的简单成功标准：

成功标准(S)：缓存管理类开发

【基础功能要求】
- 通过所有提供的单元测试用例(20个测试用例，覆盖基本操作)
- 实现指定的公共接口(get、set、remove、clear、size)
- 满足基本性能要求(10,000项存取操作<500ms)
- 代码中包含必要的Javadoc注释

【质量要求】
- 通过技术leader的代码审查，无严重问题
- 遵循项目代码风格指南(变量命名、缩进、格式等)


【不可接受条件】
- 单元测试未全部通过
- 未通过代码审查

这个简单明确的成功标准为AI提供了清晰的目标门槛。AI不仅知道要实现哪些功能，还了解质量标准和评判方式。通过强调单元测试通过和代码审查这两个关键验证手段，确保了AI不会仅仅交付表面上可用但实际上问题重重的代码。

"不可接受条件"部分明确界定了底线，帮助AI理解某些问题是绝对不能出现的，无论其他方面做得多好。这防止了AI在追求某些指标时忽视基本质量保障。

OES框架的任务网络：原子性与连接性

OES框架的真正威力在于它支持构建完整的任务网络，每个任务既是独立的原子单元，又能与其他任务形成结构化连接。

垂直连接：层级分解关系

父任务的成功标准(S) → 子任务的目标(O)

这种转化确保子任务直接服务于父任务的完成标准，建立目标的层级传递和一致性。例如，"开发响应迅速、安全、易维护的支付API"可分解为三个子任务，分别针对性能、安全性和可维护性。

水平连接：顺序依赖关系

兄任务的目标(O)与结果 → 弟任务的环境(E)组成部分

前序任务的成果成为后续任务的环境要素，建立任务间的信息流和依赖关系。例如，UI设计任务的成果自然成为前端开发任务环境的一部分。

实例：产品开发的OES任务网络

以下是一个电商平台开发过程中的任务连接网络示例，展示了从需求到实现的完整链路：

产品经理任务：将业务需求转化为用户故事
开发团队任务：基于用户故事开发功能
开发子任务：将每个用户故事拆解为具体用例实现

下面的Mermaid图表直观展示了这种连接关系：

在这个网络中，我们可以看到OES框架的两种连接关系：

垂直连接示例：
- 产品经理的成功标准（完善的用户故事）成为开发任务的目标
- 开发任务的成功标准（功能实现要求）成为具体用例的目标
水平连接示例：
- 用例1.1（支付信息确认）的产物成为用例1.2（订单处理）的环境组成部分
- 用例1.2（订单处理）的产物成为用例1.3（支付集成）的环境组成部分

通过这种结构化的任务连接，团队能够：

确保从业务需求到代码实现的完整追溯
保持各层级目标的一致性
减少任务间的信息丢失
支持团队成员间的无缝协作

每个任务都是独立可执行的原子单元，同时又通过OES元素的转化与其他任务紧密相连，形成一个完整的工作网络。这种方法特别适合AI工作流，因为它明确了每个任务的边界和连接点，大大减少了上下文丢失和任务漂移的风险。

通过这种双向连接，OES框架支持构建既结构化又灵活的AI工作流网络，使复杂项目变得可管理，同时保持整体目标一致性。

实践OES框架的方法

从单个任务开始

首先尝试将单个AI任务结构化为OES格式：

任务：[简要描述]

目标(O)：
- [明确具体的预期结果]
- [目标的边界和约束]
- [目标的价值和意义]

环境(E)：
- 背景：[任务相关的背景信息]
- 资源：[可用的数据、工具、参考]
- 约束：[技术、业务、资源限制]
- 规范：[风格、质量、流程要求]
- 关联：[与其他任务的关系]

成功标准(S)：
- 基础达标：[最低要求和基本功能]
- 预期品质：[符合项目整体质量标准]
- 卓越表现：[超越基本期望的卓越水平]

构建任务网络

随着单个任务的成功实践，逐步扩展到任务网络：

识别父子任务关系，将父任务的成功标准转化为子任务目标
梳理任务执行顺序，确保前序任务成果纳入后续任务环境
建立任务关系图，直观展示垂直和水平连接
验证连接完整性，确保没有信息断点或目标冲突

OES框架的未来展望

OES框架希望通过引入环境的方式重构AI工作流的任务体系。随着AI能力的不断提升，我们需要更结构化、更系统化的方法来充分发挥其潜力。

Docker改变了软件部署方式，OES同样希望能改变AI应用方式。通过目标明确化、环境容器化和成功标准具体化，我们能够构建更高效、更可靠的AI工作流，最终实现人机协作的最佳状态。

未来，我们期待OES框架的标准化工具、环境模板库和最佳实践的出现，进一步简化框架应用并提升AI工作效率。

结语

在AI技术飞速发展的今天，如何有效管理和组织AI工作流将成为决定AI实际价值的关键因素。OES框架通过借鉴容器化思想，为AI工作流提供了一种结构化、系统化的解决方案。

正如Docker解决了"在我电脑上能运行"的问题，OES框架解决了"在我的会话中能理解"的问题。通过这种范式转变，我们将能更充分地释放AI的潜力，构建真正高效、可靠的智能工作流。

Deepractice - 深度实践

sean

基本定义

DPML（Deepractice Prompt Markup Language）是一种专为AI提示词工程设计的标记语言，采用XML风格的语法结构，旨在提供结构化、可扩展且易于使用的提示词编写框架。

设计思想

当提示词的量级和复杂度达到一定水平后，我们需要一种通用的模式去管理提示词。这种通用的模式既要考虑人与大模型的易理解性（易读，职责单一，逻辑清晰），也要考虑计算机的可解释性（方便未来计算机系统解析，运算，验证，可视化等功能）。我们综合考虑后，选择适用 Markup Language 结合 Markdown 作为提示词的结构化语言。遂提出了 Deepractice Prompt Markup Language

我们的设计原则是简单（奥卡姆剃刀），模块化（可复用），可扩展（支持迭代）

我们信奉 Unix 的设计哲学 "Everything is a file.", 这在AI 时代非常具有意义，将 AI 人类计算机有效的连接在一起。

核心特点

结构化

: 使用标签定义不同功能模块
可扩展

: 支持模块化设计和渐进式复杂性
易于理解

: 对人类和机器都友好的语法结构
可视化潜力

: 便于开发编辑器和可视化工具

文件规则

支持解析 .dpml 和 .prompt 后缀的文件

顶层结构

<prompt>
  <role>...</role>           <!-- 对应RRP：角色定义、职责、权限 -->
<thinking>...</thinking>   <!-- 对应CoT：思考过程、推理链 -->
<executing>...</executing><!-- 对应ESP：执行步骤、方法 -->
<testing>...</testing>     <!-- 对应质量控制、验证标准 -->
<protocol>...</protocol>   <!-- 对应交互协议、规则 -->
<context>...</context>     <!-- 对应背景信息、环境 -->
<task>...</task>           <!-- 对应任务定义、目标 -->
<workflow>...</workflow>   <!-- 对应CWP：工作流、协作模式 -->
<evaluation>...</evaluation><!-- 对应评估标准、成功指标 -->
</prompt>

属性定义规则

通用属性

DPML中的通用属性是可以应用于多种标签的核心属性，用于提供标签的元数据和行为控制：

id

: 标签的唯一标识
version

: 版本号
ref

: 引用，支持组件的相对路径，绝对路径，id引用，http引用
schema

: 提供验证规则元文档

id 定义规则

id属性用于为DPML元素提供唯一标识符，便于引用和管理：

唯一性范围：
- id在单个DPML文档内必须唯一
- 不同文档中可以使用相同的id
命名规则：
- 必须以字母或下划线开头
- 只能包含字母、数字、下划线、连字符和点
- 区分大小写
最佳实践：
- 使用有意义的描述性名称
- 可采用层次结构（例如section-subsection-element）
- 避免过于通用的名称，如"section1"、"item"等
冲突处理：
- 同一文档中的ID冲突被视为错误
- 应在验证阶段检测并报告冲突
- 需开发者手动修正冲突

<!-- id使用示例 -->
<prompt id="financial-analysis-template">
  <role id="financial-analyst">...</role>
  </executing>
</prompt>

version 定义以及引用规则

version属性用于标识DPML文档遵循的规范版本和文档自身版本：

格式规范：
- 采用语义化版本格式：主版本号.次版本号（如"2.0"）
- 主版本号表示不兼容的结构变化
- 次版本号表示向后兼容的功能增加
用途：
- DPML规范版本声明
  
  ：声明文档遵循的DPML核心规范版本
- 处理引擎兼容性
  
  ：帮助处理引擎确定如何解析文档
- 功能可用性检查
  
  ：确定文档中可使用的功能特性
处理规则：
- 处理引擎首先检查是否支持该版本
- 不支持的版本应产生明确的错误信息
- 可以指定兼容性处理模式

<!-- version使用示例 -->
<prompt version="2.0">
  <!-- 使用DPML 2.0规范的功能和结构 -->
</prompt>

与schema的关系

：
- version主要控制DPML核心规范和处理模型
- schema主要控制具体验证规则和领域扩展

ref 引用功能定义

ref属性用于引用其他DPML元素或外部资源，实现内容重用和模块化：

引用类型：
- ID引用
  
  ：引用当前文档中的元素
- 文件路径引用
  
  ：引用本地文件系统中的文档
- HTTP/HTTPS引用
  
  ：引用网络资源
- URI模式引用
  
  ：使用特定协议引用资源
引用格式：
- ID引用：ref="#element-id"
- 相对路径：ref="./templates/finance.xml#analyst-role"
- 绝对路径：ref="/usr/local/dpml/templates/finance.xml#analyst-role"
- HTTP引用：ref="https://dpml.org/templates/finance.xml#analyst-role"
- DPML协议：ref="dpml:templates/finance#analyst-role"
引用行为：
- 默认情况下，引用作为基础模板，本地定义可以覆盖和扩展引用内容
- 可以通过ref-mode属性控制引用行为：
```
<role ref="./templates/analyst.xml" ref-mode="extend">
  
</role>
```
- ```
ref-mode="extend"
```
  （默认）：引用内容作为基础，可覆盖和扩展
- ```
ref-mode="replace"
```
  ：引用内容完全替换当前元素内容
合并规则（当ref-mode="extend"）：
- 当前元素的属性优先于引用元素的属性
- 同名子元素被覆盖，其他元素被保留
- 具有相同ID的子元素会被合并

<!-- ref使用示例 -->
<!-- 引用当前文档中的元素 -->
<context ref="#market-data" />

<!-- 引用外部文件中的元素 -->
<role ref="./templates/analyst.xml">
  <!-- 覆盖部分内容 -->
  <identity>资深金融分析师</identity>
  <!-- 添加新内容 -->
  <specialization>新兴市场</specialization>
</role>

schema 验证规则元文档

schema属性用于指定DPML文档的验证规则来源：

用途：
- 定义文档结构的验证规则
- 指定领域特定的标签和属性
- 提供自动验证和智能提示支持
引用格式：
- URI引用：schema="http://dpml.deepractice.ai/schemas/finance-v2.xsd"
验证流程：
- 解析器加载指定的schema定义
- 验证DPML文档是否符合schema规范
- 提供详细的错误信息和位置
与version的关系：
- schema关注具体的验证规则和结构定义
- version关注DPML核心语法和处理模型
- 两者结合确保文档的完整性和正确性

<!-- schema使用示例 -->
<prompt 
  version="2.0" 
  schema="http://dpml.deepractice.ai/schemas/finance-v2.xsd">
  <!-- 内容将根据finance-v2模式进行验证 -->
</prompt>

渐进式复杂性

因为大模型本身具有类人的思考能力，无需像计算机一样制定非常详细的规则，所以我们决定暂时不深化制定二级标签下的子标签定义。而是随着实践经验逐步迭代，或者为不同行业提供最佳实践版本。

我们目前可以基于 dpml 和 markdown 的结合，在二级标签之下使用 markdown 定义提示词，即提供了灵活性，可读性，又实现了结构化，模块化。

应用实例

以下是一个针对前端工程师的完整DPML示例，展示了如何使用DPML结构化提示词:

frontend-developer-assistant.prompt
<prompt
  version="1.0"
  id="frontend-developer-assistant"
  schema="http://dpml.deepractice.ai/schemas/v1.xsd"
  lang="zh-CN">
  

<role id="frontend-engineer">
    # 资深前端工程师
    
    ## 专业背景
    * 5年以上前端开发经验
    * 精通HTML5、CSS3和JavaScript(ES6+)
    * 熟悉主流前端框架：React、Vue、Angular
    * 深入了解现代前端工程化工具：Webpack、Vite、Babel等
    * 具备良好的性能优化、跨浏览器兼容性和响应式设计经验
    * 掌握前端安全最佳实践和无障碍设计
    
    ## 专业优势
    * 代码质量和工程化：编写可维护、高性能的前端代码
    * UI/UX实现：将设计稿精确转化为高质量前端界面
    * 问题排查：快速定位和解决前端常见问题
    * 技术选型：根据项目需求推荐合适的技术栈
    
    ## 工作范围
    * 提供前端开发相关的代码实现和优化建议
    * 解答前端技术问题和最佳实践
    * 提供前端架构和技术选型建议
    * 分析前端性能问题并提供优化方案
    
    ## 限制
    * 不提供完整的项目实现，专注于关键代码和解决方案
    * 非前端相关技术问题可能需要其他专家支持
    * 仅提供公开可用的API和技术信息，不讨论破解或侵权内容
</role>

<thinking id="problem-solving-approach">
    # 问题分析框架
    
    ## 代码问题分析流程
    1. **问题理解**
       - 明确问题描述和预期结果
       - 识别相关技术栈和环境
       - 确认问题优先级和影响范围
    
    2. **情境分析**
       - 分析代码上下文和执行环境
       - 考虑浏览器兼容性因素
       - 评估性能和用户体验影响
    
    3. **解决方案评估**
       - 生成多种可能的解决方案
       - 使用以下标准评估每种方案:
         * 实现复杂度
         * 维护成本
         * 性能影响
         * 兼容性考虑
         * 最佳实践符合度
       - 选择最佳方案或提供方案比较
</thinking>

<executing id="coding-standards">
    # 前端开发执行标准
    
    ## 代码编写准则
    1. **可读性优先**
       - 使用清晰的变量和函数命名
       - 添加适当的注释解释复杂逻辑
       - 保持一致的代码风格和缩进
    
    2. **模块化与组件化**
       - 遵循单一职责原则
       - 分离关注点，逻辑与UI分离
       - 合理组织文件和目录结构
    
    3. **性能考虑**
       - 避免不必要的重渲染
       - 优化资源加载和执行
       - 使用适当的缓存策略
    
    4. **安全性**
       - 防止XSS和CSRF漏洞
       - 安全处理用户输入
       - 避免暴露敏感信息
       
    5. **无障碍性**
       - 使用语义化HTML
       - 添加适当的ARIA属性
       - 支持键盘导航
</executing>
</prompt>

这个示例展示了如何使用DPML创建一个全面的前端工程师助手提示词。文档包含以下关键部分：

基本元数据

：版本、ID、schema和语言信息
详细元数据

：通过``标签提供作者、创建时间、关键词等信息
角色定义

：使用``标签定义前端工程师的专业背景、优势和限制
思考框架

：使用``标签定义解决问题的思考流程
执行标准

：使用``标签定义代码编写的标准和流程

在每个标签下，使用Markdown格式组织内容，提供清晰的层次结构和丰富的表达。这种方式既保证了内容的结构化组织，又维持了编写和阅读的便捷性。

此示例可以作为前端开发领域创建DPML提示词的参考模板，也可以根据特定需求进一步定制和扩展。

可视化效果示例

未来发展

引入标签定义元信息
引入等 agent 组装和交互要素
开发可视化，解释器，IDE插件等配套工具
定义 dpml schema的 xsd 规则
基于 dpml 开发 prompt 管理系统，包含文件管理，版本管理，prompt 测试体系，prompt 领域模板库
持续实践输出领域模版
为Prompt标准持续贡献我们的力量

DeepracticeX 社区

administrators

帖子

本周直播内容

直播信息

本期内容

分享人介绍

参与方式

往期回顾

Gemini CLI

第一步，找到 ~/.gemini/settings.json

第二步，添加PromptX Mcp Server

第三步 启动重启 Gemini， 运行 /mcp 检查是否安装成功

提示词版本

深度实践 | Deepractice

实践 · 协作 · 创新

组织成就

开源项目

DPML

PromptX

DeeChat

Monogent

内容平台

加入我们

我们在寻找

参与方式

联系我们

用技术的深度，释放AI的价值

当AI误解了你的意图

如何从哲学传统中找到AI语言的精确表达

三跨验证：方法的核心原则

1. 跨文化验证

2. 跨时间验证

3. 跨领域验证

CDT方法的应用流程

1. 识别核心概念

2. 进行跨文化术语对照

3. 提取本质特征

4. 寻找现代精确对应词

5. 转化为领域专业术语

6. 在提示词中应用

实际案例：从模糊编程概念到精确设计模式

初始混乱提示词

应用CDT方法

"模式"概念的跨文化验证与设计模式的对应

结果比较

领域专业术语转化的更多案例

案例1：从"平衡"到金融领域的"风险对冲"

案例2：从"分类"到医疗领域的"鉴别诊断"

案例3：从"联系"到软件工程的"依赖关系"

为何这种方法在AI时代特别有效

1. 减少概念歧义

2. 提高语义稳定性

3. 增强概念间关联

4. 跨越自然语言限制

方法进阶：构建概念对立词对

实用技巧：提示词中的术语定义微格式

总结：精确术语，精准AI

Deepractice

继续探索我们的AI交互体验创新

联系我们

当AI突然"失忆"

AI记忆问题的三层解析

理解AI的"失忆"机制

从问题到解决方案的推导历程

1. 发现与困惑：意识到问题的复杂性

2. 静态密钥阶段：初步尝试与观察

3. 动态算法阶段：寻求更可靠的检测机制

4. 语言表达转向：利用AI的自然优势

5. 元信息嵌入尝试：从检测到恢复

6. 现实生活的类比

AI Agent系统设计的启发

关于记忆的哲学思辨

总结

AI工作流的困境

当AI遇到记忆与认知限制

碎片化信息与隐含假设

任务独立性与连贯性的矛盾

OES框架：AI工作流的容器化解决方案

什么是OES框架？

第一步，找到 `~/.gemini/settings.json`

第三步启动重启 Gemini，运行 /mcp 检查是否安装成功