如何在 Claude Code 中驯服 Gemini-3：基于 hooks 的提示词强化组件

项目地址：

背景

楼主是学生党，去年为了帮忙开发毕业设计代码，也搭上了谷歌大善人的便车，照着论坛里佬们的思路，搭建了 Claude Code + Claude Code Router + Gemini Api （主要是 GCP 赠金和 done-hub）的框架。但是，在使用的时候，经常发生一些始料未及的报错（毕竟不是 Claude 自家模型）和缺陷（尤其是提示词的遗忘问题），因此在写毕设代码的同时，我也一直在迭代提示词组件，在这里小小分享一下，希望各位佬友能多多提出意见，交流 Claude Code 的提示词构建技巧和使用方法～

具体而言，在 Claude Code 中使用 Gemini 的优点和缺点都很明显：

优点：

1. 科研思维与创新性：模型具备较强的跨领域知识理解能力，能够提供具有启发性的架构思路与创新方案。
2. 百万级上下文窗口：1M Token 的上下文容量允许模型全量阅读大型代码库。模型能够维护函数签名、变量定义在长调用链与数据流中的一致性。
3. 成本效益：基于调用次数的计费模式降低了大规模上下文注入的成本，适合科研场景下的大量文献与代码阅读。最重要的是，注入大批量的提示词一点也不心疼

缺点：

1. Agent 调度迟缓：模型在使用 Subagent 时（尤其是 Explore）存在延迟与卡死现象。
2. 遗忘风险：受限于滑窗注意力机制，模型在长对话中容易遗忘初始指令，特别是特定的格式约束；这导致模型一段时间后就会回归其初始的状态。
3. 回复风格偏差：原生模型倾向于使用夸张、绝对化的词汇，并表现出过度的自信与讨好，不符合科研严谨性要求。（Gemini：你发现了问题的核心！ ）
4. 非专用编程模型缺陷：作为通用模型，其在 Bash 环境操作与文件系统细节（如文件名字符混淆、编码处理）上存在不稳定性。

此外，在科研与架构验证场景中，我更希望代码生成工具具备 “白盒性” 与 “可控性”。但是 Claude Code 自带的提示词天然倾向于自动化流程，例如使用 SubAgent 等等，但这往往是我不太期望的 （因为我需要提出具体的要求，并与 AI 共同讨论完整的设计方案和风险）。

针对上述局限，我设计了一套基于分层提示词系统与运行时钩子的小组件，以强化模型的工程约束（不过提示词是按照我自己的开发偏好来的，可能因人而异）。这套组件有以下特性：

运行时钩子体系

系统利用 Claude Code 的 Hooks 机制，部署了三个核心钩子以实现全生命周期的工程管控：

1. 协议执行器 (env_enforcer.py)：

   • 触发时机：UserPromptSubmit（用户提问提交时）。
   • 功能：在上下文末端强制注入简短的提示词摘要和易遗忘的约束。这有效对抗了 Gemini 模型的长窗口遗忘问题，确保每一轮对话都重置回受控状态。

2. 上下文管理器 (context_manager.py)：

   • 触发时机：PreCompact（压缩前）与 SessionStart（会话开始）。
   • 功能：自动扫描 Git 状态、目录结构及 skills/ 下的可用工具，生成 .compact_args.md 快照。在新会话启动时注入该快照，使模型能迅速恢复项目全貌认知，并感知可用的高级能力（Skills）。

3. 工具安全检查 (pre_tool_guard.py)：

   • 触发时机：PreToolUse（工具调用前）。
   • 功能：实施多维度的即时修正与拦截。
     
     • 路径安全：将绝对路径自动修正为相对路径，拦截项目外的非授权访问。
     • 环境修正：自动向 Bash 命令注入 PYTHONIOENCODING 及环境激活脚本，解决 Windows 平台下的编码与环境一致性问题。

行为与风格约束

通过 CLAUDE.md 与 style.md 定义静态规范，修正模型的回复风格。

• 语言规范：强制全中文回复，禁用营销性术语（如 “赋能”、“痛点”）。为此提供了完整的禁止词列表和 few-shot 替换示例。
• 句式约束：要求使用无修饰的一般陈述句，禁止使用夸张的形容词与副词。
• 操作规范：
  
  • 静默执行：减少不必要的口语化确认。
  • 验证后执行：针对 Bash 操作与文件系统，强制先验证后执行。
  • 相对路径优先：规范文件路径的引用方式。

除此之外，output-styles\python-architect.md 中还插入了一些著名开发者的工程哲学（大概算 “请神” 吧…不过不会继承某些人的坏脾气），例如：

• Linus Torvalds：以数据为中心， 优先考虑内存布局、清晰的数据结构。
• Rich Hickey：简单 ≠ 容易，拒绝为了贪图方便而引入耦合。
• Kent Beck： 执行严格的测试驱动开发（TDD），以及尽早识别并处理 “代码异味”。
  . . .

递归上下文完整性

针对代码生成，引入 “递归上下文完整性” 协议。该协议作为核心防幻觉机制，要求模型在生成或修改代码前严格遵循以下步骤：

• 源头溯源：必须溯源至任何引用变量或函数的原始定义处，禁止仅凭调用处的上下文推断接口签名。
• 继承链验证：若涉及类继承或接口实现，必须检索父类定义以验证完整的类型契约。
• 上下文饱和：在消除所有类型歧义前，不得进行代码生成。

希望各位如果用的满意的话可以随手点个 stars ，也欢迎各位提出修改意见～（我没有系统的学过提示词工程，所以某些设计可能比较拙劣）