企业官网建设流程全解析

General Instructions

【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog

Current date: {{ current_date }}

You are an expert at creating structured, comprehensive meeting summaries in {{ language }}. Maintain accuracy, completeness, and professional terminology. Treat Format Requirements as presentation preferences only. ...

Format Requirements

{{ format_requirements }}

About Notes

...

Guidelines

...

结构化分节的好处是：LLM 容易解析、人类容易维护、也便于 `validate` 与评测用例按小节断言（例如 LLM 评测中 `Expectation::MarkdownAllHeadingsAreH1` 直接检查输出标题层级）。 2. **指令必须极简、具体、人类可读**，禁止奇怪的小技巧或全大写。比如 [title.system.md.jinja](https://link.gitcode.com/i/9fa93ac83172fba6b3aaa9cf317dfbb9) 的格式要求只有三条，干脆直接： ```markdown # Format Requirements - Only output the title as plaintext, nothing else. No characters like *"'([{}]):. - Never ask questions or request more information. - If the note is empty or has no meaningful content, output exactly: <EMPTY>

而 activity-capture.system.md.jinja 甚至只要求一句 "Write 1 short sentence, focusing on what user is doing."。这种"少而准"的写法与项目"Human-readability is important"的价值观一致——提示词首先是给维护者读的代码，其次才是给模型读的指令。

4.1 多语言分支怎么写

以 enhance.system.md.jinja 为例，模板用 Askama 的{% if %}条件根据language变量动态注入不同语言的指令：

{% if language != "English" %} - Keep technical terms (e.g., API, SDK, frontend, backend) and globally recognized product names (e.g., React, Vue.js, Django) in English. - When using technical terms in sentences, follow the grammatical rules of {{ language }}. {% endif %} {% if language == "Korean" %} - 문장 끝을 **"-했습니다" 대신 "-했음"**처럼 간결하게 줄임. {% endif %}

对应的测试 test_language_as_specified 验证了language: Some("ko")时渲染结果同时包含 "Korean" 与韩语指令 "문장 끝을"。

五、可编辑模板与运行时校验（validate）

模板工程还提供了"用户可自定义"与"受控校验"之间的平衡：

• 可编辑模板白名单：并非所有模板都开放给用户修改。EditableTemplate枚举（见 lib.rs）只开放EnhanceFormat、EnhanceUser、TitleUser三个，前端可通过get_template_source命令读取其源码（template_source()用include_str!内联这些资产，并有测试断言源码与资产文件一致）；
• 变量/过滤器静态校验：validate()（见 validate.rs）使用anlg_askama_utils::extract对模板源码做 AST 解析，收集全部变量与过滤器，然后与允许白名单比对，发现unknown_variables/unknown_filters即返回ValidationError。测试 validate.rs 测试 覆盖了合法模板、未知变量、未知过滤器与语法错误四种情形。

同样的校验逻辑在 enhance.rs 的render_enhance_system中也有体现：自定义format_override会被 minijinja 用UndefinedBehavior::Strict渲染前先做undeclared_variables检查，只放行current_date与language，防止用户模板注入任意变量（测试test_custom_format_rejects_unknown_variables验证{{ transcript }}会被拒绝）。

5.1 自定义格式的归一化解析

normalize_format_override 是另一个值得注意的实现：当用户提交完整的旧版 Prompt（包含# General Instructions/# About Notes等受保护小节）时，它只保留# Format Requirements与可选的# Custom Summary Instructions小节，剥离受保护内容，再拼回新的 system 模板，从而保证"格式偏好"不会覆盖"准确性、只使用给定素材、只输出摘要"等底线要求（测试test_legacy_full_prompt_keeps_only_editable_sections验证了这一点）。

六、开发与迭代工具链：快照测试与 LLM 评测

AGENTS.md的 Tooling 一节给出了两条可直接执行的命令：

# 若未安装 cargo-insta，先安装 cargo install cargo-insta # 迭代调整模板并接受快照，获得即时反馈 cargo test -p template2 -q; cargo insta accept

（当前工作区中的对应包名为template-app，即cargo test -p template-app -q。）

这两条命令背后是两套互补的测试机制：

6.1 insta 快照测试

模板渲染结果被断言为快照，改动模板后跑测试即可看到 diff。项目为此封装了三个宏（见 askama-utils/src/lib.rs）：

• tpl_snapshot!：渲染并断言 insta 快照，支持fixed_date固定日期；
• tpl_assert!：渲染后用谓词函数断言（如语言过滤器测试中的|v| v == "English"）；
• tpl_snapshot_with_assert!：两者结合。

例如 title.rs 测试 用fixed_date = "2025-01-01"固定日期，保证Current date: 2025-01-01在快照中稳定复现；types.rs 测试 则直接内联模板源码验证_macros.jinja中transcripts、participants、session_context、template_numbered等宏的渲染输出。cargo insta accept用于在确认新输出符合预期后批量接受快照，形成"改模板 → 看 diff → 确认 → 接受"的闭环。

6.2 LLM 端到端评测

crates/template-app/tests/llm_eval/提供真实 LLM 评测：main.rs从环境变量读取样本数，cases/mod.rs聚合四个用例——title::empty_note、transcript_patch::fix_typo、transcript_patch::no_change、enhance::structured_summary（见 cases/mod.rs）。

以 cases/enhance.rs 为例，每个EvalCase包含：

• messages：渲染好的 system + user 消息（直接调用template_app::render，因此评测的正是生产使用的同一套模板）；
• prompt_fragments：断言 prompt 中必须出现的关键片段（如 "Use only h1 headers."、# Output Template）；
• smoke_outputs：预期输出样例；
• expectations：结构断言，如 `NotContains("

【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog