get-shit-done review 提示词自动裁剪：为 ollama / llama.cpp / lm-studio 等小上下文本地模型定制 code review 提示词预算

get-shit-done review 提示词自动裁剪：为 ollama / llama.cpp / lm-studio 等小上下文本地模型定制 code review 提示词预算

【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done

导读

在 get-shit-done 项目中，code review 需要把项目上下文、研究资料、需求与各阶段 PLAN 组装成超长提示词（prompt），而 ollama、llama.cpp、lm-studio 这类本地模型服务器通常只有很小的上下文窗口，直接喂入会溢出或截断。本文介绍仓库新增的review.max_prompt_tokens与review.max_prompt_tokens_per_reviewer配置键体系：它们如何让系统在组装评审提示词后按确定性策略自动裁剪，如何在 REVIEWS.md 中留下裁剪痕迹，以及如何通过逐级配置为不同本地推理后端独立设定预算。读完你可以在自己的本地模型环境中精确控制评审提示词的体积，并理解其底层调用链。

一、功能定位：解决本地小上下文模型的评审提示词超限问题

该功能最早在 .changeset/jolly-pandas-parade.md（changesettype: Added，关联 PR 3081）中登记。核心诉求非常具体：

自动裁剪已组装好的评审提示词，使其适配小上下文本地模型服务器（ollama、llama.cpp、lm-studio）。

在 get-shit-done 的评审流程里，提示词由多个信息来源拼接而成，越完整的评审输入越占用 token。本地模型服务器有两个天然约束：

• 上下文窗口小，长提示词会触发远端截断或直接报错；
• 窗口内留给「推理」的空间被输入挤占，评审质量下降。

因此不能只在拼装前限制单一部分的大小，还需要在「全部拼装完成」后再对整体做一次收缩——这正是本功能切入的位置：对组装后的完整评审提示词执行自动裁剪（auto-trim）。

二、配置键：全局预算与按后端细分的预算

功能引入两个命名空间清晰的配置键，二者均登记在配置参考文档 docs/CONFIGURATION.md 与 SDK 配置 schema 清单 sdk/shared/config-schema.manifest.json 中。

review.max_prompt_tokens_per_reviewer的后缀即本地模型服务器类型，仓库实际使用的子键包括：

• review.max_prompt_tokens_per_reviewer.ollama
• review.max_prompt_tokens_per_reviewer.llama_cpp
• review.max_prompt_tokens_per_reviewer.lm_studio

一个典型的配置示意（具体数值需按本地模型的实际上下文窗口设定）：

[review] max_prompt_tokens = 4096 [review.max_prompt_tokens_per_reviewer] ollama = 8192 llama_cpp = 4096 lm_studio = 2048

回退语义：某个后端没有单独的子键配置时，自动落到全局的review.max_prompt_tokens。这一点可以由 get-shit-done/workflows/review.md 的运行时读取逻辑直接印证（见下文「四」）。

注意：上述取值仅为说明层级关系，仓库文档中未给出默认值，实际数值应以你所用本地模型的可接受上下文长度为基准。

三、确定性裁剪策略：先降级、再收缩、后截断

裁剪不是"随机删行"，而是一套确定性（deterministic）、可预期、可复现的逐步策略。裁剪顺序为：

1. 优先整段丢弃：依次丢弃CONTEXT→RESEARCH→REQUIREMENTS段落；
2. 头部收缩PROJECT.md：对项目说明做 head-shrink（收缩其开头部分，保留尽可能多的尾部实质内容）；
3. 按比例截断 PLAN：对多个 PLAN 做尾部截断（tail-truncate），并按比例分配剩余预算，避免某个 PLAN 被整体牺牲。

对这套顺序可以这样理解（推断自策略命名与顺序）：

• CONTEXT（上下文）最「可重建」，通常可从工作区重新抽取，最先丢弃代价最小；
• RESEARCH（研究资料）属于支撑性材料，次之；
• REQUIREMENTS（需求）是评审的对齐基准，放在第三位被丢弃；
• PROJECT.md是项目全局说明，采用头部收缩而不是整体删除，保留可能包含结论/现状描述的中后部内容；
• PLAN 是评审的直接对象、必须保留，所以放到最后只做尾部截断，并通过按比例分配预算让多份 PLAN 尽量公平地各让一步。

整个顺序意味着：评审对象（PLAN）本身最后才被触碰，系统先消耗那些信息增益较低、冗余度较高的外围材料，从而在尽量保住评审核心语义的前提下把提示词压到预算之内。

四、运行时读取链路：review.md 如何拿到预算

裁剪预算并非写死在代码中，而是评审工作流在运行时动态查询。在 get-shit-done/workflows/review.md 中可以看到对每个后端分别取预算并带兜底的典型片段：

OLLAMA_REVIEWER_BUDGET=$( gsd-sdk query config-get review.max_prompt_tokens_per_reviewer.ollama 2>/dev/null \ | jq -r '.' 2>/dev/null || echo "null" ) if [ -z "$OLLAMA_REVIEWER_BUDGET" ] || [ "$OLLAMA_REVIEWER_BUDGET" = "null" ]; then OLLAMA_REVIEWER_BUDGET=$( gsd-sdk query config-get review.max_prompt_tokens 2>/dev/null \ | jq -r '.' 2>/dev/null || echo "null" ) fi

（同样模式在 get-shit-done/workflows/review.md 中分别针对.ollama（L327-L329）、.lm_studio（L375-L377）、.llama_cpp（L428-L430）重复出现。）

从中可以得出三个确定的事实：

1. 预算通过gsd-sdk query config-get <key>从配置系统读取，返回值用jq提取；
2. 读取顺序遵循"专用键优先、全局键兜底"的优先级；
3. 整条命令对失败静默（2>/dev/null）并在异常时返回"null"，随后回落到全局配置。

也就是说，只要本地配置了review.max_prompt_tokens_per_reviewer.ollama，使用 ollama 的评审者就会拿到更贴合的独立预算；未配置时自动共享review.max_prompt_tokens。裁剪器正是以这个预算为上限，对拼装完成的提示词按第三节的策略执行收缩。

五、裁剪痕迹：REVIEWS.md frontmatter 与评审者可见的披露

提示词被裁剪会对评审覆盖度产生影响，因此功能同时建立了可追溯性：

• 元数据落盘：发生裁剪时，裁剪元数据会写入 REVIEWS.md 的 frontmatter（即评审记录文件的 YAML 头部），用于记录本次评审提示词经历了裁剪这一事实；
• 披露给评审者：当裁剪发生时，评审者会在提示词中看到一条可见的披露说明（disclosure note），明确告知"当前提示词因上下文预算被自动裁剪过"，避免评审模型在不自知的情况下产出"遗漏某部分依据"的结论。

这两点设计让自动裁剪不至于"悄悄降级"评审质量：无论是事后查看 REVIEWS.md 记录，还是评审模型自身读到的提示词，都能感知并警觉裁剪的存在。这既是运维审计的需要，也是对评审结果可靠性的兜底。

六、配置治理与一致性校验

新增配置键不是孤立字符串，而是进入仓库既有配置治理体系的。依据如下：

• 配置 schema 清单 sdk/shared/config-schema.manifest.json 收录了review.max_prompt_tokens与review.max_prompt_tokens_per_reviewer相关键；
• 文档侧，docs/CONFIGURATION.md、docs/FEATURES.md、docs/INVENTORY.md 均覆盖了对该配置的描述；
• 测试侧，tests/config-schema-sdk-parity.test.cjs 引用了这些键。

从测试文件的命名与位置可以推断，这类 parity 测试用于守护 SDK 侧配置 schema 与文档/清单之间的一致性，防止"文档写了但 schema 没登记"或反向漂移。也就是说，你在文档中看到的键就是 SDK 与运行时实际认领的键，二者由测试约束保持同步。

七、适用场景与使用建议

结合上述机制，本功能最适合以下环境与诉求：

1. 纯本地推理栈：团队评审全部或部分走 ollama / llama.cpp / lm-studio，且这些模型的上下文窗口明显小于云端模型；
2. 多后端混合：不同评审任务被分派到不同本地后端——利用_per_reviewer.<backend>子键给窗口更小的后端单独设更紧的预算，不必拖累其他后端；
3. 评审质量可审计：依赖 REVIEWS.md frontmatter 元数据与评审者可见披露说明，在压缩输入的同时保留"此次评审被裁剪过"的可追溯记录。

实践建议：

• 先从全局review.max_prompt_tokens设一个能稳定通过的值，再为窗口更小的后端逐步调低对应子键；
• 观察 REVIEWS.md 中是否频繁出现裁剪元数据——如果几乎每次评审都在裁剪，说明预算定得过紧，应上调预算或精简评审输入源，而不是继续依赖末位截断；
• 关注 PLAN 段的比例截断：预算极紧时各 PLAN 都会"变短",此时应优先检查是否可以把评审拆分为多个更聚焦的评审，从源头降低对裁剪的依赖。

结语

review.max_prompt_tokens与review.max_prompt_tokens_per_reviewer为 get-shit-done 的本地化评审补上了最后一块拼图：既有"全局统一预算"，又有"按 ollama / llama.cpp / lm-studio 细分"的精细控制；裁剪执行采用 CONTEXT → RESEARCH → REQUIREMENTS 依次丢弃、PROJECT.md 头部收缩、PLAN 尾部按比例截断的确定性策略；同时通过 REVIEWS.md frontmatter 元数据与评审者可见披露说明保留完整审计轨迹。配置键由 docs/CONFIGURATION.md 与 sdk/shared/config-schema.manifest.json 双向登记，并由 tests/config-schema-sdk-parity.test.cjs 守护一致性，整体机制从"拼装 → 裁剪 → 记录 → 披露"形成闭环——这正是让 code review 在小上下文本地模型上既跑得动、又裁得明、还审得清的关键设计。

【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done