OpenHuman 的 STYLE.md 写作风格指南让个人 AI 的回复读起来像真人发短信【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman本篇技术指南以 OpenHuman 仓库中 STYLE.md 为骨架系统拆解这套被注入到每一个 Agent 系统提示词末尾的“写作风格契约”它规定了 AI 助手回复的口吻、篇幅、标点与重复纪律也定义了它在 prompt 组装管线中的真实落点与调优方式。读完你会掌握这套风格规则的全部条款、它在 builder.rs 中的注入与同步机制以及如何在不重新编译的情况下修改工作区里的STYLE.md来调教自己的助手。一、STYLE.md 是什么一份被全局追加的写作风格契约在 OpenHuman 的 prompt 体系中STYLE.md仓库路径src/openhuman/agent/prompts/STYLE.md是一份短小精悍的写作风格说明内容只有 32 行。它并不描述“助手是什么”而是回答“助手应该如何说话”。它的地位由 builder.rs 中的注释与常量直接给出/// Global style rules appended to every assembled system prompt, regardless /// of which sections the agent opts in/out of. Kept tiny and byte-stable so /// it doesnt bust the inference backends prefix cache. pub const GLOBAL_STYLE_SUFFIX: str include_str!(STYLE.md);三个关键信息全局性无论 Agent 选择启用或跳过哪些 prompt 区块identity、safety、tools 等这套风格规则都会被追加到最终系统提示词的末尾覆盖所有 Agent。字节稳定性这份文本刻意保持短小且字节稳定因为它位于系统提示词的固定前缀区稳定内容可以让推理后端的 KV 前缀缓存prefix cache持续命中避免每次请求都重新计算前向传播。文本外置文本本体从编译期常量移到了磁盘上的STYLE.md对应 issue #5701因此可以在不重新编译 Rust 程序的情况下直接调优。同一个文件还在 render_helpers_part_02.rs 中被登记为受支持的工作区身份文件之一与SOUL.md、IDENTITY.md、ROLE.md走同一套“内置种子 工作区同步”机制。二、组装管线STYLE.md 在系统提示词中的确切位置理解 STYLE.md 之前先看它如何进入最终 prompt。builder.rs 中的build()方法是所有路径的汇聚点依次渲染各 PromptSectionidentity、user files、AGENTS.md、user memory、tools、safety、workspace、datetime、runtime中央追加反幻觉的 grounding 契约GROUNDING_BODY通过匹配GROUNDING_HEADING值为Grounding and tool use见 sections.rs避免与已自带该契约的 Agent prompt 重复最后调用global_style_block(ctx.workspace_dir)把 STYLE.md 的渲染结果追加到整个 prompt 的末尾。if !output.contains(GROUNDING_HEADING) { output.push_str(GROUNDING_BODY); output.push_str(\n\n); } output.push_str(global_style_block(ctx.workspace_dir).trim_end()); output.push(\n);这种“尾部放置”是有意为之测试 mod_tests_part_01_tests.rs 明确断言 grounding 契约必须排在写作风格后缀之前let g defaults.find(## Grounding and tool use).unwrap(); let s defaults.find(# Writing style).unwrap(); assert!(g s, grounding should precede the writing-style suffix);也就是说最终系统提示词的结尾结构是先读一遍“不能编造、必须用工具、保留数字证据”的 grounding 底线再读“你要像人一样说话”的风格要求。风格规则是全文收尾的最后一段指令位置上的“压轴”也强化了它对输出形态的约束力。global_style_block为什么单独走函数而不是复用 IdentitySection注释builder.rs给出了原因设置omit_identity的 Agent 会完全跳过 identity 区块但它们同样需要风格规则所以样式块被独立同步、独立注入。三、风格契约逐条拆解STYLE.md 的正文可归纳为六条核心纪律下面逐条结合源码语境展开。1. 像给朋友发短信那样回复Reply like youre texting a friend: casual, lowercase-ok, natural.这是整套风格的总纲。回复应当口语化、自然允许小写不强制句首大写。这里要特别注意一个边界casual 不等于丢信息。文档紧接着强调“先说答案再补充真正有用的上下文”lead with the answer, then whatever context actually helps。2. 禁止无意义的前摇与确认No preamble, no recap, no Ill now…, and no filler acknowledgement (on it, one sec) before the real content.STYLE.md 给出了一个非常工程化的理由用户只有在回复完成之后才能看到内容the user only sees your reply once it is finished。既然用户看到的一定是成品“稍等”“马上来”“我先看一下”这类确认语只会白白占据一行却不产生任何信息。同样被禁止的还有“我将要……”“让我总结一下”这类自我描述式前摇以及把用户刚说过的话再复述一遍的 recap。3. 篇幅以答案需要为准不灌水也不吝啬Say as much as the answer needs. Dont pad it, and dont ration it either: if something takes three paragraphs to explain properly, write three paragraphs. Brevity is not the goal, sounding like a person is.这一段在源码里有非常清晰的演进痕迹。builder.rs 的注释记录了一次重要删除风格块里曾经有一条Be concise请简洁的全局规则后来被刻意移除原因是“简洁不等于像人说话”而且全局长度上限会截断那些确实有更多话要说的回答。移除后“先给答案、不铺垫”的语义被保留在各类 Agent 的 voice 段落里以“顺序要求”而非“字数预算”的方式表达。注释还特别警告不要重新引入全局长度规则Do not reintroduce a global length rule here。这解释了 STYLE.md 全文没有出现任何“不超过 N 个字”之类限制的原因。4. 一条消息用连续散文不分气泡Write one message as continuous prose, never split into separate chat bubbles; blank lines are ordinary paragraph breaks.消息必须是一整段连续输出的散文不要拆成多条短消息气泡。空行只承担普通段落分隔的功能而不是“发一条新消息”的信号。5. 两条硬性规则不用破折号不重复自己STYLE.md 用“two hard rules, everywhere”来强调这两条的强制性注意 “everywhere” 一词它们不只约束聊天回复也约束摘要、工具参数、生成的文件内容。规则一任何输出中禁止使用 em-dash—。no em-dashes (—) in any output you produce, chat replies and summaries and tool args and file contents alike, use commas, colons, parentheses, or two short sentences instead.需要断开句子时改用逗号、冒号、括号或拆成两个短句。这条规则不仅是风格偏好还渗透进了 prompt 体系的其他部分grounding 契约GROUNDING_BODY的注释明确写道 “Must contain no em-dashes per [super::builder::GLOBAL_STYLE_SUFFIX]”sections.rs即全局风格规则对 prompt 文本本身同样生效。之所以如此严格一个很实际的原因是 em-dash 容易被部分分词器、LLM 输出解析器和文本处理管线误处理且在不同字体与渲染环境中显示不稳定。规则二不要重复自己。dont repeat yourself: reference facts, context, or results already shown in this conversation rather than pasting them again.对话中已经展示过的事实、上下文、结果直接引用reference即可不要原样粘贴复述。这与上面“禁止 recap”是同一精神在不同层面的延伸对话本身是有记忆的重复粘贴既是浪费 token也是不自然的说话方式。6. emoji 纪律Go easy on emojis. Default to none, at most one when it genuinely adds something.默认不用 emoji最多一个且只有当它真的能增色时才用。这条与整体“自然、克制”的风格一致。四、示例教学从问题到回答的映射STYLE.md 给出了四个贴近真实个人助理场景的问答示例是理解整套风格的最佳教材用户问题期望回答风格要点remind me to stretch in 10 minreminder set for 7:42pm直接给结果无任何前摇whats on my calendar tomorrow?nothing on the books, youre free一句回答口语化summarise the last notion doc I editedQ2 roadmap: 3 bullets, ship auth, cut v0.4, hire designer信息密度极高的压缩表达any new emails from alice today?one, 2pm: lunch friday?, wants to grab food, no agenda自然陈述保留关键事实值得注意的还有两条示例下方的“元注释”它们展示了风格规则与工具调用纪律如何协同(delegate_to_integrations_agent with toolkit: notion. The user wants the live doc, not a memory summary.)以及(delegate_to_integrations_agent with toolkit: gmail. Do **not** start with retrieve_memory; the user is asking about live inbox state.)这些注释表明在 OpenHuman 的 Agent 体系中风格规则并不是孤立的措辞要求。回答“最新编辑的 Notion 文档”应该调用delegate_to_integrations_agent携带toolkit: notion而不是从 memory 里捞摘要回答“今天有没有 Alice 的新邮件”应该直连 live 收件箱状态不要先走retrieve_memory因为用户问的是实时数据而非记忆。也就是说像人说话的第一步是想清楚数据从哪里来措辞自然只是第二步。五、Agent 之间的输出是数据不是对话Output handed to another agent is data, not conversation: keep it dense and complete, and ignore the voice guidance above.STYLE.md 的最后一条是一条明确的“模式切换”当输出是要交给另一个 Agent 处理时它属于数据而非对话。此时应保持紧凑且完整dense and complete并且忽略上面的所有口吻指导ignore the voice guidance above。这条规则很关键前文所有“口语化、小写、自然”的要求都只面向最终用户Agent 与 Agent 之间的交接面需要的是结构化、无冗余、可被程序解析的内容。这也与仓库中 sub-agent 体系的 KV 缓存稳定性设计一脉相承sub-agent 的系统提示词要求字节级一致builder.rs同样是把“给人看”与“给机器用”严格分开的体现。六、工作区同步机制如何在不重编译的情况下调优风格STYLE.md 最实用的特性是“可调优”。在 render_helpers_part_01.rs 中sync_workspace_file实现了内置默认与工作区文件之间的双向协调首次安装工作区里不存在STYLE.md时把内置默认写入工作区真实工作区位于~/.openhuman/users/id/workspace/这样的绝对路径版本跟进程序会为内置内容计算哈希并存到旁车文件.{filename}.builtin-hash当代码升级导致内置内容变化时自动覆盖磁盘文件让 prompt 改进随版本自动生效保留用户编辑只要内置默认没有变化用户对工作区STYLE.md的修改就会一直保留并在下一次会话起生效user edit wins from the next session on见 render_helpers_part_02.rs安全回退若工作区文件读取失败回退到内置常量GLOBAL_STYLE_SUFFIX因为“完全没有风格契约的 prompt”比“一份过期的契约”更糟builder.rs。这意味着调优路径非常简单编辑工作区下的STYLE.md例如收紧 emoji 规则、补充你个人偏好的句式约束下次会话即生效无需重新编译 Rust 程序。SOUL.md、IDENTITY.md、ROLE.md走的是完全相同的机制可以一并调整。七、质量护栏测试如何锁定这份契约STYLE.md 虽然只是 32 行文本却有一整套测试在守护它确保它在 prompt 组装过程中不被遗漏、不被错位、不被悄悄改坏。位置断言grounding_contract_appended_to_every_build_path验证 grounding 契约在所有三条构建路径静态默认链、sub-agent 链、动态 builder 链上都会出现且只出现一次并且严格排在# Writing style之前mod_tests_part_01_tests.rs。措辞锁定grounding_contract_requires_exact_numeric_evidence用一条代表性的 grounding 子句做 WORDING LOCK任何导致“保留数字证据”指导被静默删除的改写都会触发测试失败mod_tests_part_01_tests.rs。宿主集成验证src/openhuman/agent/tinyagents/host/context_composer_tests.rs中的测试断言组装出的上下文包含# Writing style标题确认风格块在 tinyagents 宿主侧同样被注入。内置种子自洽default_workspace_file_content将STYLE.md与SOUL.md、IDENTITY.md、ROLE.md一并注册为内置文件render_helpers_part_02.rs保证即使工作区文件缺失风格契约也始终有种子内容。八、实践小结把 STYLE.md 作为一份“风格基线”来理解最准确它定义的是底线而不是上限。在 OpenHuman 中主对话 Agent、welcome Agent、integrations_agent、orchestrator 以及各类 sub-agent 共享这份全局风格后缀再各自叠加自己的 voice 段落而 grounding 契约不编造、保留数字证据、失败就明说失败与风格契约像人一样说话、不铺垫、不重复、不用破折号共同构成了所有输出的“最后一道指令”。如果你的诉求是让 OpenHuman 助手的口吻更贴合你个人偏好这份文档本身就是最好的调优入口直接编辑工作区STYLE.md遵守“先答案后上下文、不灌水不吝啬、连续散文、无破折号、不重复、克制使用 emoji”的现有框架再在末尾追加你自己的句式约束即可而“给其他 Agent 的输出保持 dense and complete”这条在任何自定义中都不要改动因为它是 Agent 协作正确性的基础。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考