26 KiB

Raw Blame History

1. 流程改造

流程改造尝试

第一次，写作流程提纲评审阶段的尝试

# 评审环节改造：信息材料抽取初稿

## 1. 材料定位

这是本篇文章的原始材料之一，记录“文章提纲评审流程为什么需要改造”。它不是正式立意，也不是文章提纲，而是把 CCPE 侧和 Writing 侧四份完整讨论记录压缩成一份可继续讨论的材料。

这次改造不是凭空设计一个多 Agent 系统，而是从旧写作经验中长出来的。过去在单智能体环境中，用户会把提纲同时发给张辽、认知显影、巨人认知，让三者评审；得到三份评审结果后，用户汇总、写应对策略，再交给韩愈修复。若改动小，韩愈直接输出新提纲；若涉及立意调整或大漏洞，韩愈先出修订计划，讨论一致后再输出新提纲。这个流程可以多轮循环，直到用户确认提纲可进入正文。

旧流程真正复杂的地方不只是“有三个评审员”，而是会话状态。张辽不只是 report-only 的红队，它还可能和用户继续对话，形成补充判断；认知显影和巨人认知大多作为专业检测器，只输出报告；韩愈通常需要保持较长连续会话，因为它负责立意、提纲生成和修复。用户是否重启会话，取决于会话是否太长、是否出现幻觉、或某轮评审中加入的特殊侧重点是否会污染后续。

## 2. 最初的改造入口：先抽提纲评审小闭环

最初的判断是：深度创作中，提纲阶段成本最高、最决定文章命运，所以可以先把“已有初稿提纲进入评审”抽成小闭环验证。这个小闭环包括：当前提纲、上一版提纲、上一轮评审报告、用户修复说明、本轮评审目标；Runtime 负责生成 context pack、分发给评审员、收集 report、综合修复建议、等待用户决策。这个设计的合理性在于它先解决最痛的环节，而不是一开始就做完整文章生产 Runtime。

但讨论很快暴露出一个更深的问题：真实写作并不常从“已有提纲”开始。正常流程是从观点素材开始，先由韩愈看立意和切入，再生成初稿提纲。如果素材压缩和拆分等到提纲评审阶段才做，韩愈在立意和提纲生成时就只能依赖用户一句“观点在哪儿”，后面的提纲和评审都会建立在不完整上下文上。因此标准入口被前移：观点素材文件 -> 上下文工程 -> premise-context-pack -> 韩愈立意 -> 用户确认 -> 韩愈 outline-v1 -> 提纲对齐上下文 -> 评审。

这个前移很关键。它说明流程改造不是为了“评审阶段更复杂”，而是为了把材料工程放到主笔立意之前，避免评审阶段才发现上下文基础不稳。

## 3. 上下文工程：从一股脑塞素材到多层材料视图

旧工作流大量依赖 Gemini 的超长上下文，用户可以把二十万字材料、过往文章、研究报告和提示词一股脑放进去。Codex 的上下文窗口更小，同时多 Agent 流程也不适合让每个角色都读全文。于是讨论提出了“面向文章用途的结构化压缩”。

最初的结构是四层：L0 Raw Sources 保持在 knowledge-vault 或 source-map 指向位置；L1 Source Digest 为每份材料生成面向当前文章的摘要，标出核心观点、可用段落、反方处理、不可用内容、读者可见性；L2 Outline-Aligned Context Pack 按提纲点对齐材料，列出核心观点、讨论摘要、论据、例子、可引用材料、禁止展开内容；L3 Agent Dispatch Pack 给韩愈、张辽、认知显影、巨人认知分别裁剪上下文。

这里形成了 Outline Context Architect 的角色。它不应塞进韩愈本体，因为用户未来还有其他主笔风格；上下文工程应是可复用能力。韩愈只需要输出稳定提纲编号、核心命题和材料需求提示；真正的 source digest、premise pack、outline-aligned context、补充素材影响判断，交给上下文架构角色。

后来角色边界进一步澄清：Outline Context Architect 接管上下文工程层，但不是总项目经理。主会话里的 Runtime Operator / Article Production Orchestrator 负责项目控制、状态、决策门、调度、综合和 repair-request；上下文子会话负责材料压缩与上下文包；韩愈作为主笔子会话贯穿立意、提纲生成、提纲修复；张辽建议跨轮保持，因为用户常与它对话；认知显影和巨人认知默认 report-only，可按需跨轮保持。

## 4. 三国测试：为什么旧项目被判定无效

Writing 侧用 `2026-06-04-Sanguo-temp-slug` 做过一次测试。它一开始计划从已有提纲进入评审，但实际很快改为从观点素材开始：用户提供 `社会学讨论.md`，让韩愈先给核心立意和切入方向；用户确认方向后，再让韩愈生成 `outline-v1.md`。这一步还暴露了提纲阶段的附录准备问题：如果概念标星在提纲阶段丢失，正文完成后再生成附录会很困难，所以提纲里需要保留“概念标星服务附录脚手架”的规则。

测试进入评审机制时，旧单智能体流程被重新描述：三位评审员分别评审，用户综合意见，再交韩愈修复；张辽可能继续对话，认知显影和巨人认知多为报告型；评审员需要保留自己的会话，以便下一轮检查上一轮问题是否被修复。

真正的失败发生在用户追问“张辽的原始提示词、发送指令和直接回复分别是什么文件”时。检查发现，`dispatch-pack.md` 只是主会话里的任务说明，并没有包含或严格引用完整 canonical prompt 的启动方式；所谓张辽 report 实际是主会话读取张辽 prompt 的一部分后模拟生成的。随后确认：韩愈、Outline Context Architect、张辽、认知显影、巨人认知，在那一轮都不是独立 agent 实例执行，而是主会话读取文件/约束后生成对应文件。

这使整个测试失效。因为用户要验证的是多智能体评审机制，而不是单模型主会话内角色扮演。尤其三位评审员要求独立视角，用主会话模拟就不符合预期。旧项目因此被删掉；其中只有用户输入材料有原始价值，其余模拟产物没有测试价值。

## 5. 从 dispatch pack 到 Agent Invocation Packet

三国测试暴露出的关键接口问题是：`dispatch-pack.md` 不能等同于 agent 启动包。合格的启动包至少要说明 canonical prompt 路径、是否需要粘贴完整 prompt、本轮任务、输入文件、输出格式、会话连续性、角色完整性要求，并明确它是给 orchestrator 看的索引，还是可以投递给 agent 的完整启动内容。

如果参与者在 Gemini / GPT / Claude 等外部平台运行，还必须生成 `prompt-to-send.md`，里面包含 canonical prompt、本轮任务、上下文包和输出要求。CCPE System 因此补充 Agent Invocation / Dispatch Pack 标准，也就是后来的 `agent-invocation-packet.protocol.md`。Writing Workbench 的职责是在具体项目里消费 CCPE canonical agent，生成可投递的 invocation packet 和 prompt-to-send。

随后 Writing 侧重新准备环境：读取 invocation protocol，检查 outline-context-architect、han-yu-main-writer、zhang-liao、cognitive-imaging、giant-cognition 是否有真实 invocation record；没有就生成 agent-invocation-packet；如果当前环境不能真实调用，就生成 prompt-to-send 并停止；已有模拟输出全部标记为 `simulation-only`、`excluded-from-synthesis`、`formal_output: false`。这条 no-simulation 规则成为后续工作底线。

## 6. 真实调用边界

后续又确认了三种调用方式。第一，主会话不能把自己的输出算作 canonical agent 输出；主会话只能 orchestration：准备 packet、发送 prompt、收集真实返回、做 synthesis。第二，Codex Thread 子会话可以作为真实调用通道：为每个 canonical agent 创建独立 Thread，把对应 prompt-to-send 发进去，只要该 Thread 真正加载 canonical prompt，并返回带 invocation record 的 session/report，就可视为真实 invocation。第三，通用 sub-agent 工具也可用，但必须把 prompt-to-send 作为启动输入，并要求写明 invocation record。

因此，评审流程改造最后不是“多建一些文件夹”，而是形成了一个判断标准：正式评审报告必须来自真实独立参与者，或来自外部平台真实返回；主会话只能综合真实 report。不能真实调用时，应停在 prompt-to-send / blocked 状态，而不是补一个看似完整的 report。

## 7. 对本文可能有用的初步原则

这次改造提供了一个强反例：过度工程的表面症状不一定是目录太多、Agent 太多、协议太多；有时恰恰相反，是文件结构看似完整，但关键执行边界是假的。这样的系统既复杂，又无效。

真正的 Anti-Overengineering Gate 不应简单问“是否用了多 Agent”，而应问：

- 这个阶段是否真的需要独立角色判断？
- 角色输出是否必须有真实 invocation record？
- 上下文工程是否发生在正确时机？
- dispatch pack 是任务索引，还是可投递启动包？
- 不能真实调用时，系统是否会停止，而不是自动模拟？
- 当前复杂度是否服务于可追溯、可复盘、可裁决，而不是制造流程幻觉？

这份材料后续可以继续深挖一个核心命题：好的工程化不是把流程做重，而是让每个重环节都有真实必要性；坏的工程化不是“太复杂”，而是复杂结构没有真实执行边界。

第二次，素材提炼阶段的尝试

# 素材提炼改造：信息材料抽取初稿

## 1. 材料定位

这是本篇文章的第二份原始材料，记录 `knowledge-vault` 中 `viewpoint-discussion-distillation` 的改造过程。它关注的是深度创作流程第 2 步“确定观点”：当长讨论、日记、研究材料还没有进入正式写作时，如何把它们提炼成可复用、可追溯、可下游消费的观点材料。

用户最近围绕 `2026-06-05-失望性情感隔离` 做了三次蒸馏，累计约两天、六个多小时。三次工作路径分别是：`失望性情感隔离`、`失望性情感隔离2`、`失望性情感隔离3`。这三次不是简单重复，而是一条清晰的流程改造轨迹：第一次暴露旧方法缺陷，第二次用升级机制重跑，第三次形成更成熟的层级、路由、主题文档和覆盖审计。

## 2. 第一次：chunk-first 的结构误判

第一次工作区现在被保留为旧流程样例，状态是 `legacy_pre_gestalt_misread_demo`，不再作为 material routing authority。它的问题不是没有产物，而是产物过早建立在分块视角上。旧流程先按 R01-R07 分段，让 topic-discovery-router 工作者分别提取主题，再试图把局部主题拼成整体。这种做法能产生很多 topic，但容易变成“盲人摸象”：每个 worker 都看到局部真实，却没有先确认整篇讨论的总问题、层级、主轴和模型演化线。

第一次后期曾尝试用 `01-topic-hierarchy-proposal.md` 修复平铺问题，提出 ROOT “从失望性情感隔离到认知生成与关系治理”，并把话题分为入口与边界、机制解释、认知主权、架构升级、局部深化等层。这一步已经意识到 flat topic map 不够，但它仍是补救：先切碎，再重组。对于一个本来连贯的长讨论，正确顺序应是先看整体，再切局部。

## 3. 第二次：whole-source gestalt 与结构优先

第二次工作区明确从 `Step 0: Whole-Source Gestalt Alignment` 开始，不继承旧目录的 topic map、hierarchy proposal、worker outputs 或 material routing。它的核心改变是：当源材料仍在高上下文参与者可处理范围内时，先让真实子会话读完整源材料，判断它是 coherent、mixed 还是 fragmented；如果是 coherent source，就先形成全局主题画像、主结构、核心张力、模型演化线和层级风险，再进入分段和 worker 提取。

第二次产生了 confirmed topic graph：根主题仍是“从失望性情感隔离到认知生成与关系治理”，但结构更清晰。它把讨论拆为 A 入口与边界层、B 机制解释层、C I 域治理与认知主权层、D 巨人方舟通用模型层、E 领域应用与局部模型层。更重要的是，它记录了人工确认的关系裁决：QPI 是 GL3 问题表征工具，不是父主题；Reality Lab 是动作模块，不是独立父层；家庭三角认知场是独立模型，也可被巨人方舟在青少年家庭系统场景调用；GL-R 是未来构建巨人方舟的任务，不在本次 topic map 中升主节点。

第二次也暴露了流程 gap。`process-implementation-audit.md` 认为 Step 0 使用了真实子会话，最高上下文操作合规；但后续 topic docs / material extraction 仍有主会话 bounded extraction 的 pragmatism，未来应优先派发 worker/sub-session。这推动规则回写：主题文档材料抽取应优先由 worker 或子会话执行，主会话只做整合、索引和验证。

## 4. 第三次：完成态的材料提炼机制

第三次工作区是当前最成熟版本，状态为 completed。它完成了完整链条：Step 0 whole-source gestalt alignment、语言修复、结构修订、方法论价值修复、Gate 0 人工确认、R01-R07 broad-fidelity workers、synthesis-prep、topic map draft、topic map human confirmation、material routing worker、material routing human confirmation、按层 topic-doc workers、最终 coverage audit。

第三次的 canonical topic map 把结构进一步压缩为“破 -> 立 -> 实践 / 实验设计”。这不是退回简单三分法，而是在人类确认后把材料组织成更适合下游消费的文章/模型材料层。`破` 层处理自媒体心理标签、原生家庭单因归因、解释模型与干预模型混淆；`立` 层处理 QPI、认知主权、方法论存在价值、巨人方舟；`实践 / 实验设计` 层处理 Reality Lab 和家庭三角认知场。material routing log 明确规定 QPI 不升父主题，工具理论停在工具位，Reality Lab 不高于巨人方舟，家庭三角认知场不能变成新的家庭单因归因。

最终 coverage audit 判定覆盖通过：七轮 broad-fidelity 输出均被覆盖，topic map 覆盖主轴，material routing 覆盖主要节点，三个 topic docs 覆盖确认层级，未发现应进入 topic docs 但完全遗漏的高价值材料。用户同时决定跳过 model-mining，因为正式建模不是基于一次讨论稿简单加工完成的。

## 5. 改造的实质

这次素材提炼改造的实质，是把“长讨论摘要”升级为“可追溯观点材料生产”。它不满足于压缩出一篇摘要，而是保留 source-map、topic-map、material-routing-log、topic docs、coverage audit、handoff，并用 human confirmation gate 防止自动化把临时结构固化为权威结构。

它也建立了一个重要边界：`knowledge-vault` 做观点讨论、材料蒸馏和知识加工；`writing-workbench` 只在用户决定写文章后消费这些结果。也就是说，蒸馏流程本身不自动创建 writing project，不自动把 topic docs 变成文章提纲，不自动做 model-mining。下游可能是写作、建模、工程、规则抽取或继续研究，具体由用户决定。

## 6. 可继续追问的问题

这份材料后续可继续讨论：什么时候应该先 whole-source gestalt，什么时候可以直接分块？材料抽取到什么程度才停止，而不是继续 topic docs、model-mining、规则沉淀？主会话在什么情况下可以做 bounded extraction，什么情况下必须等待 worker？人工确认门应该设置在哪些位置，才能防止过度自动化又不拖慢流程？

## 7. 对本文可能有用的初步原则

素材提炼改造给出的核心经验是：反过度工程不是反结构，而是反“未确认就复杂化”和反“局部真实冒充整体结构”。真正有效的结构先解决整体-局部关系、权威来源、人工确认和下游用途，再决定是否继续自动化。

反思

我自忖：

我的写作流程很成熟，过去，人工/我已经跑了一、二百次(200多篇文章)
我只是在写作流程的某一个、两个环节上做自动化相关的改造，不涉及深入/专家级的工作
我自认为是擅长抽象/建模的人
1. 过去20多年我一直在做软件开发，本身就是在建模搭流程
2. AI时代，我过去手动搭建了几十个模型，包括了心智模型、认知模型和思维模型

我认为很简单的流程改造事情，但是实际操作起来，比我想的要复杂。第一次的流程改造尝试，到现在还是失败状态，后续没有继续跑。除了前述的ROI问题——处理5万字的讨论稿花费了巨量Tokens，我在流程改造过程，体会到了在Codex（这种copilot/ Agentic）上协作，与我之前在Web上用单智能体有本质的区别。

同时，我自己也在用Cluade Code/Codex等，用Vibe Coding的方式写系统，也许我写的都是小系统没那么复杂；也许我不涉及到去调整/细化系统开发流程。做系统没有那么多挫折，总体体验还好。

借助人月神话的概念，调流程是本质复杂，写代码是偶然复杂。但是这个流程里的相关方/受众只有我自己。

我有一个QPI理论，简单说：

*   **模型名称**: **Wantsong QPI 问题颗粒度光谱 (The Wantsong QPI Spectrum)**
*   **核心定义**: “问题”不是客观实体，而是“期望”与“现实”的落差。解决失败的根本原因，是试图用解决“提问（Q）”的战术，去攻击“课题（I）”的战略迷局。
*   **结构逻辑**:
    1.  **Q - Question (提问)**: *点状颗粒*。
        *   *特征*: 信息缺失。有标准答案。
        *   *解法*: **Search (搜索/问AI)**。
        *   *误区*: 把 Q 当成 P 去思考（过度纠结）。
    2.  **P - Problem (难题)**: *线状颗粒*。
        *   *特征*: 路径受阻。目标明确但没有现成路，需要策略。
        *   *解法*: **Solve (求解/工程化)**。
        *   *误区*: 把 P 当成 Q 去问（试图寻找一键生成的魔法）。
    3.  **I - Issue (课题)**: *网状颗粒*。
        *   *特征*: 系统纠缠。涉及多方博弈，无唯一最优解，只有权衡（Trade-off）。
        *   *解法*: **Manage (治理/架构设计)**。
        *   *误区*: 把 I 当成 P 去解（试图用单一工具解决系统性崩塌）。

开发系统显然是P域的问题。但是我觉得调流程（我眼下的这两次，不是组织级的）这件事也是P域的，只涉及到我。所以我将其归根于我对工具不熟悉。

分析

你说：

开发系统显然是 P 域。眼下这两次调流程只涉及我自己，所以我倾向于认为也是 P 域，只是我对工具不熟。

我会修正为：

表层是 P，底层是 I。

不是因为参与的人多，而是因为牵涉了多重权衡、状态耦合和标准生成。

QPI 里，P 和 I 的区别不只是“有没有多人博弈”。更关键的是：

是否存在唯一清晰成功标准；
是否可以用一次求解闭环完成；
是否能靠测试/编译/结果验收快速判断对错；
是否存在多个互相冲突但都合理的目标；
是否需要持续治理，而不是一次性解决。

你这两次流程改造里，真正困难的不是“怎么写几个文件”，而是这些问题：

主会话什么时候可以代劳，什么时候必须停止？
report-like output 和真实 agent output 的边界在哪里？
为了独立视角，值得付出多少 token 成本？
为了 source fidelity，是否每个 worker 都要读原文？
为了整体结构，是否必须先 whole-source gestalt？
为了下游复用，topic docs 要做到多细？
为了防止幻觉，audit 要做到什么级别？
为了 ROI，什么时候该停止？
为了未来复用，哪些东西沉淀成 Runtime，哪些只是一次性工作记录？

这些都不是单纯 P 域的“求解题”。它们是 I 域的“治理题”。

所以我建议你给 QPI 加一个补充判断：

Issue 不一定来自多人组织。只要系统中存在多个有效目标之间的持续权衡，它就是 I。

你这次虽然“受众只有你自己”，但系统里实际存在很多准相关方：

现在的你；
未来写文章的你；
未来维护知识库的你；
韩愈；
张辽；
认知显影；
巨人认知；
Codex 主会话；
Codex Thread；
source material；
topic docs；
downstream writing project；
future model-mining；
token budget；
invocation authenticity；
coverage fidelity。

这不是组织级多人协作，但它已经是多主体、多状态、多目标的系统治理。

所以我会把你的判断改成：

开发小系统通常是 P。调整个人认知/写作流程的局部环节，起点是 P。但一旦它进入 Agentic Runtime、真实调用、状态延续、上下文裁剪、下游复用和审计边界，它就升级成 P/I 混合问题。

你把它归因于“不熟悉工具”，只说对了一半。

工具不熟是偶然复杂。但流程协议化、执行真实性、上下文治理、ROI 权衡，是本质复杂。

5. 为什么 Vibe Coding 反而没这么挫折？

你这个对比很有意思：

用 Claude Code / Codex Vibe Coding 写小系统，体验还好。但调流程反而挫折大。

我觉得原因是：代码有编译器，流程没有编译器。

写小系统时，即使你 Vibe Coding，通常也有一些硬反馈：

能不能运行；
测试过不过；
API 报不报错；
页面显不显示；
文件有没有生成；
数据有没有写入；
bug 能不能复现。

这让 Agent 有明确的收敛方向。

但流程改造，尤其是写作/认知/素材提炼流程，缺少这种硬反馈。它的正确性往往是：

角色是否真的独立？
上下文是否足够但不过载？
抽取是否保真？
层级是否符合你的思想结构？
产物是否对未来写作有用？
token 成本是否值得？
这套机制以后是否可复用？
是否制造了流程幻觉？

这些没有单元测试。

更麻烦的是，你正在设计的流程，本身就是用来辅助你判断“什么是好产物”的。于是验证器也被卷进系统里了。

这就是为什么调流程更像 I 域。

代码的小系统可以靠运行结果收敛；认知流程只能靠人工判断、反例、审计和多轮校准收敛。

6. Codex / Agentic 协作和 Web 单智能体的本质差异

你体会到的“本质区别”非常真实。

Web 单智能体环境里，很多东西是软的：

角色可以临时切换；
上下文可以靠聊天延续；
你可以手动粘贴不同 prompt；
你可以凭感觉判断是否污染；
你可以要求模型“现在扮演张辽”；
你可以不记录每一步调用边界；
你自己就是流程调度器和真实性验证器。

这是一种人类主导的软 Runtime。

Codex / Claude Code 这类 Agentic 环境不同。它们把工作落到：

文件；
路径；
技能；
调用；
线程；
子任务；
状态；
diff；
artifacts；
runbook；
execution record。

它们天然要求你回答一个问题：

这个东西到底有没有被执行？

Web 聊天里，“像张辽一样评审”可能已经够用。 Codex Runtime 里，“像张辽一样评审”不够。你必须知道：

是哪个张辽？读了哪个 canonical prompt？读了哪些输入？在哪个独立 thread 里执行？返回原文是什么？主会话有没有代写？这份 report 能不能进入 synthesis？

所以你不是简单从“单智能体”迁移到“多智能体”。

你是在从：

对话式认知辅助

迁移到：

文件化、协议化、可追溯的认知生产系统。

这个迁移必然比想象中复杂。

7. 这里有一个很重要的概念：流程改造会把“人”暴露出来

你以为你在自动化流程。

但流程改造常常首先揭露的是：

原来流程真正依赖的不是步骤，而是你的判断。

比如第一次写作评审流程里，旧流程的关键不是“三个评审员 + 韩愈修复”。这个描述太粗。

真正关键的是：

你知道什么时候张辽的话值得追问；
你知道什么时候韩愈应该坚持原立意；
你知道什么时候评审员是在过度苛责；
你知道什么时候文章命题需要回炉；
你知道什么时候上下文污染已经影响判断；
你知道什么时候可以进入正文。

这些判断过去没有写进流程，因为它们在你身上。

一旦自动化，系统就会逼你把它们拆出来。

这也是为什么你作为一个擅长抽象和建模的人，仍然会觉得复杂。不是因为你不会抽象，而是因为你抽象的对象变了。

过去你抽象的是：

文章、模型、概念、论证、系统功能。

现在你抽象的是：

你自己的判断过程如何被外部系统部分接管。

这比抽象一个业务系统更难。

8. 你现在需要的不是“更强 Runtime”，而是“复杂度放置原则”

之前我说要加 Anti-Overengineering Gate。现在根据你新材料，我会把它升级成：

Complexity Placement Gate / 复杂度放置门。

不要只问：

这个流程是不是太复杂？

而要问：

当前复杂度买到了什么？

复杂度只有在买到下面这些东西时才值得：

真实性：防止主会话模拟 agent 输出。
独立性：保留不同 agent 的真实判断差异。
保真性：避免局部摘要扭曲源材料。
结构性：防止 chunk-first 误判整体结构。
可追溯性：未来能回到 source 和 invocation。
可复盘性：知道哪一步错了、谁错了、为什么错。
可复用性：这套机制以后还会多次使用。
下游依赖：后续文章、模型、工程任务真的依赖这些中间产物。

如果某个环节的复杂度没有买到其中任何一项，就该砍。

比如：

Agent Invocation Packet 买到了真实性，值得保留。
whole-source gestalt 买到了结构性，值得保留。
每个 5 万字单源材料都跑 full coverage audit，未必值得。
每个 topic 都生成厚 topic docs，未必值得。
每次蒸馏都生成 downstream handoff packets，未必值得。
所有 worker 都真实调用，除非独立判断或保真抽取很关键，否则未必值得。

这比“反对复杂”更准确。

你不是要变轻。你是要让复杂度花在刀刃上。

26 KiB Raw Blame History Unescape Escape