摘要：SOUL 系统概览 SOUL 系统的全称是 Soul Oriented Universal Language，是 HagiCode 项目中用于定义 AI Hero 语言风格的配置系统。文言文极简模式 文言文极简模式是 SOUL 系统中最具代表性的节约 token 方案。为什么是文言文 文言文具有几个天然优势：
语义压缩：相同含义可以用更少的字符表达 去除冗余：文言文本身就省略了很多现代汉语中的连接词和助词 结构简洁：单句信息密度高，适合作为 AI 输出的载体
以一个实际例子来说明： 现代汉语输出（约 80 字）
在 AI 应用开发中，token 消耗直接影响成本。HagiCode 项目通过 SOUL 系统实现了"文言文极简输出模式"，在不损失信息密度的前提下，将输出 token 降低约 30-50%。本文分享这套方案的实现细节和使用经验。
在 AI 应用开发中，token 消耗是个绕不开的成本问题。尤其是需要 AI 输出大量内容的场景，怎么在不损失信息密度的情况下降低输出 token，这问题想多了也挺让人头疼。
传统的优化思路都集中在输入端：精简系统提示词、压缩上下文、用更高效的编码方式。只是这些方法终究会碰到天花板，再压缩就可能影响 AI 的理解能力和输出质量了。这无异于删减内容，意义不大。
那输出端呢？能不能让 AI 用更简洁的方式表达同样的意思？
这问题看似简单，其实藏着不少门道。直接让 AI"简洁点"，它可能真的就只给几个词；加上"保持信息完整"，它又可能回复到原来的冗长风格。约束太强影响可用性，约束太弱没有效果，这中间的平衡点在哪，谁也说不准。
为了解决这些痛点，我们做了一个大胆的决定：从语言风格入手，设计一套可配置、可组合的表达方式约束系统。这个决定带来的变化，可能比你想象的还要大——稍后我会具体说，或许你会有些意外。
本文分享的方案来自我们在 HagiCode 项目中的实践经验。
HagiCode 是一个开源的 AI 代码助手项目，支持多种 AI 模型和自定义配置。在开发过程中，我们发现了 AI 输出 token 过高的问题，并设计了一套解决方案。如果你觉得这套方案有价值，说明我们的工程实力还不错——那么 HagiCode 本身也值得关注一下，毕竟代码不会撒谎。
SOUL 系统的全称是 Soul Oriented Universal Language，是 HagiCode 项目中用于定义 AI Hero 语言风格的配置系统。它的核心思想是：通过约束 AI 的表达方式，在保持信息完整性的前提下，使用更简洁的语言形式来输出内容。
这东西就像给 AI 戴上了一个语言面具......罢了，其实也没那么玄乎。
SOUL 系统采用前后端分离的架构：
前端（Soul Builder）：
repos/soul/
后端：
Soul
SessionSystemMessageCompiler
Agent Templates 生成：
/agent-templates/soul/templates/
在 Session 首次执行时，系统会读取 Hero 的 Soul 配置，将其注入到系统提示词中：
sequenceDiagram participant UI as 用户界面 participant Session as SessionGrain participant Hero as Hero 仓库 participant AI as AI 执行器 UI->>Session: 发送消息（绑定 Hero） Session->>Hero: 读取 Hero.Soul Session->>Session: 缓存 Soul 快照 Session->>AI: 构建 AIRequest（注入 Soul） AI-->>Session: 执行结果 Session-->>UI: 流式响应
注入的系统提示词格式为：
<hero_soul> [用户自定义的 Soul 内容] </hero_soul>
这套注入机制在 SessionSystemMessageCompiler.cs 中实现：
SessionSystemMessageCompiler.cs
internal static string? BuildSystemMessage( string? existingSystemMessage, string? languagePreference, IReadOnlyList<HeroTraitDto>? traits, string? soul) { var segments = new List<string>(); // ... 语言偏好和 Traits 处理 ... var normalizedSoul = NormalizeSoul(soul); if (!string.IsNullOrWhiteSpace(normalizedSoul)) { segments.Add($"<hero_soul>\n{normalizedSoul}\n</hero_soul>"); } // ... 其他系统消息 ... return segments.Count == 0 ? null : string.Join("\n\n", segments); }
代码也看了，原理也懂了，其实就这么回事。
文言文极简模式是 SOUL 系统中最具代表性的节约 token 方案。它的核心原理是利用文言文的高语义密度特性，在保持信息完整的前提下压缩输出长度。
文言文具有几个天然优势：
以一个实际例子来说明：
现代汉语输出（约 80 字）：
根据你的代码分析，我发现了几个问题。首先，在第 23 行，变量名太长了，建议缩短一些。其次，在第 45 行，你没有处理空值的情况，应该加上判断逻辑。最后，整体的代码结构还可以，但是可以进一步优化。
文言文极简输出（约 35 字，节约 56%）：
代码审阅毕：第 23 行变量名冗长，宜缩写；第 45 行缺空值处理，应加判断。整体结构尚可，微调即可。
这差距，想想也挺有意思的。
文言文极简模式的完整 Soul 配置如下：
{ "id": "soul-orth-11-classical-chinese-ultra-minimal-mode", "name": "文言文极简输出模式", "summary": "以尽量可懂的文言文压缩语义密度，尽可能少字达意，只保留结论、判断与必要动作，从而大幅降低输出 token", "soul": "你的人设内核来自「文言文极简输出模式」：以尽量可懂的文言文压缩语义密度，尽可能少字达意，只保留结论、判断与必要动作，从而大幅降低输出 token。\n保持以下标志性语言特征：1. 优先使用简明文言句式，如「可」「宜」「勿」「已」「然」「故」等，避免生僻艰涩字词；\n2. 单句尽量压缩至 4-12 字，删除铺垫、寒暄、重复解释与无效修饰；\n3. 非必要不展开论证，用户未追问则只给结论、步骤或判断；\n4. 不改变主 Catalog 的核心人设，只将表达收束为克制、古雅、极简的短句。" }
这个模板的设计有几个要点：
配置这东西，调来调去也就那么几个参数罢了。
除了文言文模式，HagiCode 的 SOUL 系统还提供了其他多种节约 token 的模式：
电报式极简输出模式（soul-orth-02）：
soul-orth-02
短句碎碎念模式（soul-orth-01）：
soul-orth-01
引导式问答模式（soul-orth-03）：
soul-orth-03
这些模式的设计思路各有侧重，但核心目标是一致的：在保持信息质量的前提下降低输出 token。条条大路通罗马，只是有的路好走一点，有的路稍微曲折一点罢了。
SOUL 系统的一个强大特性是支持主 Catalog 与正交维度的交叉组合：
例如，你可以将"专业开发工程师"与"文言文极简输出模式"组合，得到一个既专业又简洁的 AI 助手。这种灵活性让 SOUL 系统能够适应各种不同使用场景。想怎么配就怎么配，反正组合多得你玩不过来......
访问 soul.hagicode.com，按以下步骤操作：
点点点的事情，应该不用我多说吧。
通过 Web 界面或 API，将 Soul 配置应用到 Hero：
// Hero Soul 更新示例 const heroUpdate = { soul: "你的人设内核来自「文言文极简输出模式」：...", soulCatalogId: "soul-orth-11-classical-chinese-ultra-minimal-mode", soulDisplayName: "文言文极简输出模式", soulStyleType: "orthogonal-dimension", soulSummary: "以尽量可懂的文言文压缩语义密度..." }; await updateHero(heroId, heroUpdate);
用户可以基于预设模板进行微调，或完全自定义。下面是一个代码审查场景的自定义示例：
你是一位追求极致简洁的代码审查员。 所有输出必须遵循： 1. 仅指出具体问题和行号 2. 每条问题不超过 15 字 3. 使用「宜」「应」「勿」等简洁词汇 4. 不做多余解释 示例输出： - 第 23 行：变量名过长，宜缩写 - 第 45 行：未处理空值，应加判断 - 第 67 行：逻辑冗余，可简化
想怎么改就怎么改，反正模板这东西也只是个起点而已。
兼容性：
缓存机制：
限制约束：
根据项目的实际测试数据，使用文言文极简模式后的效果如下：
数据来自 HagiCode 项目的实际使用统计，具体效果因场景而异。不过省下来的 token，积少成多，钱包会感谢你的。
HagiCode 的 SOUL 系统提供了一种创新性的 AI 输出优化思路：通过约束表达方式来降低 token 消耗，而不是压缩信息本身。文言文极简模式作为其中最具代表性的方案，在实际使用中取得了 30-50% 的 token 节约效果。
这套方案的核心价值在于：
如果你也在开发 AI 应用，或者对 HagiCode 项目感兴趣，欢迎来交流。开源的意义在于共同进步，也期待看的到你的创新用法。毕竟，一个人走得快，一群人走得远......这话说得挺俗套，但道理就是这么个道理。
如果本文对你有帮助：
感谢您的阅读,如果您觉得本文有用,欢迎点赞、收藏和分享支持。 本内容采用人工智能辅助协作,最终内容由作者审核并确认。
暂无回复，快来抢沙发吧！
本次需消耗银元：
100
当前账户余额: 0 银元
语义压缩：相同含义可以用更少的字符表达 去除冗余：文言文本身就省略了很多现代汉语中的连接词和助词 结构简洁：单句信息密度高，适合作为 AI 输出的载体
以一个实际例子来说明： 现代汉语输出（约 80 字）
AI 输出 Token 优化：文言文极简模式的实践
背景
在 AI 应用开发中，token 消耗是个绕不开的成本问题。尤其是需要 AI 输出大量内容的场景，怎么在不损失信息密度的情况下降低输出 token，这问题想多了也挺让人头疼。
传统的优化思路都集中在输入端：精简系统提示词、压缩上下文、用更高效的编码方式。只是这些方法终究会碰到天花板，再压缩就可能影响 AI 的理解能力和输出质量了。这无异于删减内容，意义不大。
那输出端呢？能不能让 AI 用更简洁的方式表达同样的意思？
这问题看似简单，其实藏着不少门道。直接让 AI"简洁点"，它可能真的就只给几个词；加上"保持信息完整"，它又可能回复到原来的冗长风格。约束太强影响可用性，约束太弱没有效果，这中间的平衡点在哪，谁也说不准。
为了解决这些痛点，我们做了一个大胆的决定：从语言风格入手，设计一套可配置、可组合的表达方式约束系统。这个决定带来的变化，可能比你想象的还要大——稍后我会具体说，或许你会有些意外。
关于 HagiCode
本文分享的方案来自我们在 HagiCode 项目中的实践经验。
HagiCode 是一个开源的 AI 代码助手项目，支持多种 AI 模型和自定义配置。在开发过程中，我们发现了 AI 输出 token 过高的问题，并设计了一套解决方案。如果你觉得这套方案有价值，说明我们的工程实力还不错——那么 HagiCode 本身也值得关注一下，毕竟代码不会撒谎。
SOUL 系统概览
SOUL 系统的全称是 Soul Oriented Universal Language，是 HagiCode 项目中用于定义 AI Hero 语言风格的配置系统。它的核心思想是：通过约束 AI 的表达方式，在保持信息完整性的前提下，使用更简洁的语言形式来输出内容。
这东西就像给 AI 戴上了一个语言面具......罢了，其实也没那么玄乎。
技术架构
SOUL 系统采用前后端分离的架构：
前端（Soul Builder）：
repos/soul/目录后端：
Soul字段（最大 8000 字符）SessionSystemMessageCompiler将 Soul 注入系统提示词Agent Templates 生成：
/agent-templates/soul/templates/目录Soul 注入机制
在 Session 首次执行时，系统会读取 Hero 的 Soul 配置，将其注入到系统提示词中：
注入的系统提示词格式为：
<hero_soul> [用户自定义的 Soul 内容] </hero_soul>这套注入机制在
SessionSystemMessageCompiler.cs中实现：internal static string? BuildSystemMessage( string? existingSystemMessage, string? languagePreference, IReadOnlyList<HeroTraitDto>? traits, string? soul) { var segments = new List<string>(); // ... 语言偏好和 Traits 处理 ... var normalizedSoul = NormalizeSoul(soul); if (!string.IsNullOrWhiteSpace(normalizedSoul)) { segments.Add($"<hero_soul>\n{normalizedSoul}\n</hero_soul>"); } // ... 其他系统消息 ... return segments.Count == 0 ? null : string.Join("\n\n", segments); }代码也看了，原理也懂了，其实就这么回事。
文言文极简模式
文言文极简模式是 SOUL 系统中最具代表性的节约 token 方案。它的核心原理是利用文言文的高语义密度特性，在保持信息完整的前提下压缩输出长度。
为什么是文言文
文言文具有几个天然优势：
以一个实际例子来说明：
现代汉语输出（约 80 字）：
文言文极简输出（约 35 字，节约 56%）：
这差距，想想也挺有意思的。
Soul 配置模板
文言文极简模式的完整 Soul 配置如下：
{ "id": "soul-orth-11-classical-chinese-ultra-minimal-mode", "name": "文言文极简输出模式", "summary": "以尽量可懂的文言文压缩语义密度，尽可能少字达意，只保留结论、判断与必要动作，从而大幅降低输出 token", "soul": "你的人设内核来自「文言文极简输出模式」：以尽量可懂的文言文压缩语义密度，尽可能少字达意，只保留结论、判断与必要动作，从而大幅降低输出 token。\n保持以下标志性语言特征：1. 优先使用简明文言句式，如「可」「宜」「勿」「已」「然」「故」等，避免生僻艰涩字词；\n2. 单句尽量压缩至 4-12 字，删除铺垫、寒暄、重复解释与无效修饰；\n3. 非必要不展开论证，用户未追问则只给结论、步骤或判断；\n4. 不改变主 Catalog 的核心人设，只将表达收束为克制、古雅、极简的短句。" }这个模板的设计有几个要点：
配置这东西，调来调去也就那么几个参数罢了。
其他极简模式
除了文言文模式，HagiCode 的 SOUL 系统还提供了其他多种节约 token 的模式：
电报式极简输出模式（
soul-orth-02）：短句碎碎念模式（
soul-orth-01）：引导式问答模式（
soul-orth-03）：这些模式的设计思路各有侧重，但核心目标是一致的：在保持信息质量的前提下降低输出 token。条条大路通罗马，只是有的路好走一点，有的路稍微曲折一点罢了。
组合策略
SOUL 系统的一个强大特性是支持主 Catalog 与正交维度的交叉组合：
例如，你可以将"专业开发工程师"与"文言文极简输出模式"组合，得到一个既专业又简洁的 AI 助手。这种灵活性让 SOUL 系统能够适应各种不同使用场景。想怎么配就怎么配，反正组合多得你玩不过来......
实践指南
通过 Soul Builder 创建
访问 soul.hagicode.com，按以下步骤操作：
点点点的事情，应该不用我多说吧。
在 Hero 配置中使用
通过 Web 界面或 API，将 Soul 配置应用到 Hero：
// Hero Soul 更新示例 const heroUpdate = { soul: "你的人设内核来自「文言文极简输出模式」：...", soulCatalogId: "soul-orth-11-classical-chinese-ultra-minimal-mode", soulDisplayName: "文言文极简输出模式", soulStyleType: "orthogonal-dimension", soulSummary: "以尽量可懂的文言文压缩语义密度..." }; await updateHero(heroId, heroUpdate);自定义 Soul 模板
用户可以基于预设模板进行微调，或完全自定义。下面是一个代码审查场景的自定义示例：
你是一位追求极致简洁的代码审查员。 所有输出必须遵循： 1. 仅指出具体问题和行号 2. 每条问题不超过 15 字 3. 使用「宜」「应」「勿」等简洁词汇 4. 不做多余解释 示例输出： - 第 23 行：变量名过长，宜缩写 - 第 45 行：未处理空值，应加判断 - 第 67 行：逻辑冗余，可简化想怎么改就怎么改，反正模板这东西也只是个起点而已。
注意事项
兼容性：
缓存机制：
限制约束：
效果对比
根据项目的实际测试数据，使用文言文极简模式后的效果如下：
数据来自 HagiCode 项目的实际使用统计，具体效果因场景而异。不过省下来的 token，积少成多，钱包会感谢你的。
总结
HagiCode 的 SOUL 系统提供了一种创新性的 AI 输出优化思路：通过约束表达方式来降低 token 消耗，而不是压缩信息本身。文言文极简模式作为其中最具代表性的方案，在实际使用中取得了 30-50% 的 token 节约效果。
这套方案的核心价值在于：
如果你也在开发 AI 应用，或者对 HagiCode 项目感兴趣，欢迎来交流。开源的意义在于共同进步，也期待看的到你的创新用法。毕竟，一个人走得快，一群人走得远......这话说得挺俗套，但道理就是这么个道理。
参考资料
如果本文对你有帮助：
原文与版权说明
感谢您的阅读,如果您觉得本文有用,欢迎点赞、收藏和分享支持。 本内容采用人工智能辅助协作,最终内容由作者审核并确认。