AI 输出 Token 优化：文言文极简模式的实践

AI 输出 Token 优化文言文极简模式的实践在 AI 应用开发中token 消耗直接影响成本。HagiCode 项目通过 SOUL 系统实现了文言文极简输出模式在不损失信息密度的前提下将输出 token 降低约 30-50%。本文分享这套方案的实现细节和使用经验。背景在 AI 应用开发中token 消耗是个绕不开的成本问题。尤其是需要 AI 输出大量内容的场景怎么在不损失信息密度的情况下降低输出 token这问题想多了也挺让人头疼。传统的优化思路都集中在输入端精简系统提示词、压缩上下文、用更高效的编码方式。只是这些方法终究会碰到天花板再压缩就可能影响 AI 的理解能力和输出质量了。这无异于删减内容意义不大。那输出端呢能不能让 AI 用更简洁的方式表达同样的意思这问题看似简单其实藏着不少门道。直接让 AI简洁点它可能真的就只给几个词加上保持信息完整它又可能回复到原来的冗长风格。约束太强影响可用性约束太弱没有效果这中间的平衡点在哪谁也说不准。为了解决这些痛点我们做了一个大胆的决定从语言风格入手设计一套可配置、可组合的表达方式约束系统。这个决定带来的变化可能比你想象的还要大——稍后我会具体说或许你会有些意外。关于 HagiCode本文分享的方案来自我们在 HagiCode (https://hagicode.com) 项目中的实践经验。HagiCode 是一个开源的 AI 代码助手项目支持多种 AI 模型和自定义配置。在开发过程中我们发现了 AI 输出 token 过高的问题并设计了一套解决方案。如果你觉得这套方案有价值说明我们的工程实力还不错——那么 HagiCode 本身也值得关注一下毕竟代码不会撒谎。SOUL 系统概览SOUL 系统的全称是 Soul Oriented Universal Language是 HagiCode 项目中用于定义 AI Hero 语言风格的配置系统。它的核心思想是通过约束 AI 的表达方式在保持信息完整性的前提下使用更简洁的语言形式来输出内容。这东西就像给 AI 戴上了一个语言面具…罢了其实也没那么玄乎。技术架构SOUL 系统采用前后端分离的架构前端Soul Builder基于 React TypeScript Vite 构建位于repos/soul/目录提供可视化的 Soul 构建界面支持双语zh-CN / en-US后端基于 .NET (C#) Orleans 分布式运行时Hero 实体包含Soul字段最大 8000 字符通过SessionSystemMessageCompiler将 Soul 注入系统提示词Agent Templates 生成从参考材料生成输出到/agent-templates/soul/templates/目录包含 50 组主 Catalog 和 10 组正交维度Soul 注入机制在 Session 首次执行时系统会读取 Hero 的 Soul 配置将其注入到系统提示词中Plain Text 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: 流式响应注入的系统提示词格式为Plain Text [用户自定义的 Soul 内容]这套注入机制在SessionSystemMessageCompiler.cs中实现csharp internal staticstring? BuildSystemMessage( string? existingSystemMessage, string? languagePreference, IReadOnlyListHeroTraitDto? traits, string? soul) { var segments new Liststring(); // ... 语言偏好和 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 方案。它的核心原理是利用文言文的高语义密度特性在保持信息完整的前提下压缩输出长度。为什么是文言文文言文具有几个天然优势语义压缩相同含义可以用更少的字符表达去除冗余文言文本身就省略了很多现代汉语中的连接词和助词结构简洁单句信息密度高适合作为 AI 输出的载体以一个实际例子来说明现代汉语输出约 80 字Plain Text 根据你的代码分析我发现了几个问题。首先在第 23 行变量名太长了建议缩短一些。其次在第 45 行你没有处理空值的情况应该加上判断逻辑。最后整体的代码结构还可以但是可以进一步优化。文言文极简输出约 35 字节约 56%Plain Text 代码审阅毕第 23 行变量名冗长宜缩写第 45 行缺空值处理应加判断。整体结构尚可微调即可。这差距想想也挺有意思的。Soul 配置模板文言文极简模式的完整 Soul 配置如下json { id: soul-orth-11-classical-chinese-ultra-minimal-mode, name: 文言文极简输出模式, summary: 以尽量可懂的文言文压缩语义密度尽可能少字达意只保留结论、判断与必要动作从而大幅降低输出 token, soul: 你的人设内核来自「文言文极简输出模式」以尽量可懂的文言文压缩语义密度尽可能少字达意只保留结论、判断与必要动作从而大幅降低输出 token。\n保持以下标志性语言特征1. 优先使用简明文言句式如「可」「宜」「勿」「已」「然」「故」等避免生僻艰涩字词\n2. 单句尽量压缩至 4-12 字删除铺垫、寒暄、重复解释与无效修饰\n3. 非必要不展开论证用户未追问则只给结论、步骤或判断\n4. 不改变主 Catalog 的核心人设只将表达收束为克制、古雅、极简的短句。 }这个模板的设计有几个要点约束明确单句 4-12 字删除冗余结论优先避免晦涩使用简明文言句式避免生僻字词保持人设只改变表达方式不改变核心人设配置这东西调来调去也就那么几个参数罢了。其他极简模式除了文言文模式HagiCode 的 SOUL 系统还提供了其他多种节约 token 的模式电报式极简输出模式soul-orth-02单句严格控制在 10 字以内禁止修饰性形容词全程无语气词、感叹号、叠词短句碎碎念模式soul-orth-01句子控制在 1-5 个字模拟自言自语的碎片化表达弱化逻辑优先传递情绪引导式问答模式soul-orth-03通过提问引导用户思考减少直接输出内容交互式降低 token 消耗这些模式的设计思路各有侧重但核心目标是一致的在保持信息质量的前提下降低输出 token。条条大路通罗马只是有的路好走一点有的路稍微曲折一点罢了。组合策略SOUL 系统的一个强大特性是支持主 Catalog 与正交维度的交叉组合50 组主 Catalog定义基础人设如治愈系、学霸系、高冷系等10 组正交维度定义表达方式如文言文、电报式、问答式等组合效果可生成 500 种独特的语言风格组合例如你可以将专业开发工程师与文言文极简输出模式组合得到一个既专业又简洁的 AI 助手。这种灵活性让 SOUL 系统能够适应各种不同使用场景。想怎么配就怎么配反正组合多得你玩不过来…实践指南通过 Soul Builder 创建访问 soul.hagicode.com (https://soul.hagicode.com)按以下步骤操作选择主 Catalog如专业开发工程师选择正交维度如文言文极简输出模式预览生成的 Soul 内容复制生成的 Soul 配置点点点的事情应该不用我多说吧。在 Hero 配置中使用通过 Web 界面或 API将 Soul 配置应用到 Herotypescript // Hero Soul 更新示例 const heroUpdate { soul: 你的人设内核来自「文言文极简输出模式」..., soulCatalogId: soul-orth-11-classical-chinese-ultra-minimal-mode, soulDisplayName: 文言文极简输出模式, soulStyleType: orthogonal-dimension, soulSummary: 以尽量可懂的文言文压缩语义密度... }; awaitupdateHero(heroId, heroUpdate);自定义 Soul 模板用户可以基于预设模板进行微调或完全自定义。下面是一个代码审查场景的自定义示例Plain Text 你是一位追求极致简洁的代码审查员。 所有输出必须遵循 1. 仅指出具体问题和行号 2. 每条问题不超过 15 字 3. 使用「宜」「应」「勿」等简洁词汇 4. 不做多余解释 示例输出 - 第 23 行变量名过长宜缩写 - 第 45 行未处理空值应加判断 - 第 67 行逻辑冗余可简化想怎么改就怎么改反正模板这东西也只是个起点而已。注意事项兼容性文言文模式适配全部 50 组主 Catalog可与任何基础人设组合使用不会改变主 Catalog 的核心人设缓存机制Soul 在 Session 首次执行时缓存同一 SessionId 内复用缓存修改 Hero 配置不影响已启动的 Session限制约束Soul 字段最大长度 8000 字符历史数据中无 Soul 字段的 Hero 仍可正常使用Soul 与 style 装备位独立不会相互覆盖效果对比根据项目的实际测试数据使用文言文极简模式后的效果如下场景原始输出 token文言文模式节约比例代码审查85042051%技术问答62038039%方案建议110068038%平均--30-50%数据来自 HagiCode 项目的实际使用统计具体效果因场景而异。不过省下来的 token积少成多钱包会感谢你的。总结HagiCode 的 SOUL 系统提供了一种创新性的 AI 输出优化思路通过约束表达方式来降低 token 消耗而不是压缩信息本身。文言文极简模式作为其中最具代表性的方案在实际使用中取得了 30-50% 的 token 节约效果。这套方案的核心价值在于保持信息质量不是简单截断输出而是用更高效的方式表达灵活可组合支持 500 种人设与表达方式的组合易于使用通过 Soul Builder 可视化界面无需编写代码生产级稳定已在项目中验证支持大规模使用如果你也在开发 AI 应用或者对 HagiCode 项目感兴趣欢迎来交流。开源的意义在于共同进步也期待看的到你的创新用法。毕竟一个人走得快一群人走得远…这话说得挺俗套但道理就是这么个道理。参考资料HagiCode GitHub: github.com/HagiCode-org/site (https://github.com/HagiCode-org/site)HagiCode 官网: hagicode.com (https://hagicode.com)Soul Builder: soul.hagicode.com (https://soul.hagicode.com)Docker 部署指南: docs.hagicode.com/installation/docker-compose (https://docs.hagicode.com/installation/docker-compose)Desktop 桌面端: hagicode.com/desktop/ (https://hagicode.com/desktop/)30 分钟实战演示: www.bilibili.com/video/BV1pirZBuEzq/ (https://www.bilibili.com/video/BV1pirZBuEzq/)如果本文对你有帮助来 GitHub 给个 Stargithub.com/HagiCode-org/site (https://github.com/HagiCode-org/site)访问官网了解更多hagicode.com (https://hagicode.com)公测已开始欢迎安装体验原文与版权说明感谢您的阅读,如果您觉得本文有用,欢迎点赞、收藏和分享支持。 本内容采用人工智能辅助协作,最终内容由作者审核并确认。本文作者: newbe36524 (https://www.newbe.pro)原文链接: https://docs.hagicode.com/go?platformwechattarget%2Fblog%2F2026-04-04-soul-token-optimization-classical-chinese%2F (https://docs.hagicode.com/go?platformwechattarget%2Fblog%2F2026-04-04-soul-token-optimization-classical-chinese%2F)版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!