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.mdchangesettype: 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评审提示词的全局 token 上限所有未单独配置的后端/评审者review.max_prompt_tokens_per_reviewer.backend按后端细分的评审者 token 上限仅作用于指定后端如.ollama、.llama_cpp、.lm_studioreview.max_prompt_tokens_per_reviewer的后缀即本地模型服务器类型仓库实际使用的子键包括review.max_prompt_tokens_per_reviewer.ollamareview.max_prompt_tokens_per_reviewer.llama_cppreview.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、可预期、可复现的逐步策略。裁剪顺序为优先整段丢弃依次丢弃CONTEXT→RESEARCH→REQUIREMENTS段落头部收缩PROJECT.md对项目说明做 head-shrink收缩其开头部分保留尽可能多的尾部实质内容按比例截断 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 中分别针对.ollamaL327-L329、.lm_studioL375-L377、.llama_cppL428-L430重复出现。从中可以得出三个确定的事实预算通过gsd-sdk query config-get key从配置系统读取返回值用jq提取读取顺序遵循专用键优先、全局键兜底的优先级整条命令对失败静默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 与运行时实际认领的键二者由测试约束保持同步。七、适用场景与使用建议结合上述机制本功能最适合以下环境与诉求纯本地推理栈团队评审全部或部分走 ollama / llama.cpp / lm-studio且这些模型的上下文窗口明显小于云端模型多后端混合不同评审任务被分派到不同本地后端——利用_per_reviewer.backend子键给窗口更小的后端单独设更紧的预算不必拖累其他后端评审质量可审计依赖 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/8 23:28:43 · 阅读 1.2k 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.mdchangesettype: 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评审提示词的全局 token 上限所有未单独配置的后端/评审者review.max_prompt_tokens_per_reviewer.backend按后端细分的评审者 token 上限仅作用于指定后端如.ollama、.llama_cpp、.lm_studioreview.max_prompt_tokens_per_reviewer的后缀即本地模型服务器类型仓库实际使用的子键包括review.max_prompt_tokens_per_reviewer.ollamareview.max_prompt_tokens_per_reviewer.llama_cppreview.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、可预期、可复现的逐步策略。裁剪顺序为优先整段丢弃依次丢弃CONTEXT→RESEARCH→REQUIREMENTS段落头部收缩PROJECT.md对项目说明做 head-shrink收缩其开头部分保留尽可能多的尾部实质内容按比例截断 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 中分别针对.ollamaL327-L329、.lm_studioL375-L377、.llama_cppL428-L430重复出现。从中可以得出三个确定的事实预算通过gsd-sdk query config-get key从配置系统读取返回值用jq提取读取顺序遵循专用键优先、全局键兜底的优先级整条命令对失败静默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 与运行时实际认领的键二者由测试约束保持同步。七、适用场景与使用建议结合上述机制本功能最适合以下环境与诉求纯本地推理栈团队评审全部或部分走 ollama / llama.cpp / lm-studio且这些模型的上下文窗口明显小于云端模型多后端混合不同评审任务被分派到不同本地后端——利用_per_reviewer.backend子键给窗口更小的后端单独设更紧的预算不必拖累其他后端评审质量可审计依赖 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考