1. 项目概述一个为AI助手注入“灵魂”的模块化框架如果你和我一样每天都在和Claude、Cursor这类AI编程助手打交道那你肯定也遇到过这些让人头疼的瞬间每次新开一个对话窗口AI就像得了“健忘症”完全不记得你之前是谁、项目背景是什么或者在你毫无防备的时候它突然提议要执行一个rm -rf或者往生产环境git push的危险操作又或者它给出的代码看似能用但仔细一查逻辑漏洞百出需要你花大量时间去“擦屁股”。这些问题本质上是因为当前的AI助手缺乏一套持续、稳定、可预测的“行为操作系统”。它们每次响应都是基于当前上下文的一次性生成没有记忆传承没有安全护栏没有质量守门员更没有事后复盘的能力。Four Gods System四神系统就是来解决这个问题的。它不是另一个AI模型而是一个运行在你本地、完全由你控制的模块化框架旨在为你的AI助手赋予四种核心能力记忆青龙、防御玄武、诊断白虎和品质稳定朱雀。这个框架最吸引我的地方在于它的设计哲学模块化、事件驱动、本地优先。你可以像搭积木一样只安装你需要的功能。比如你只担心安全问题那就只装“玄武”你只希望AI能记住你的偏好那就只装“青龙”。每个模块独立运作互不干扰但又能通过一个简单的路由文件协同工作。所有数据都保存在你的本地磁盘上没有任何数据会上传到云端这对于处理公司内部代码或敏感项目的开发者来说是至关重要的安全保障。接下来我将以一个资深开发者和AI工具重度用户的视角带你彻底拆解这个框架。我会详细解释每个“神兽”模块的工作原理、如何一步步安装配置、在实际编码对话中如何触发它们以及我在深度使用近一个月后总结出的独家避坑技巧和高级玩法。无论你是刚接触AI编程助手的新手还是已经在寻找提升AI协作效率方案的老鸟这篇文章都能给你提供一套即插即用的实战方案。2. 核心设计思路为什么是“四神”而非“一体”在深入代码之前我们必须先理解Four Gods System背后的核心设计思路。市面上已经有不少试图“调教”AI的Prompt工程方案但大多是把一大堆规则塞进系统指令System Prompt导致上下文被大量占用AI的理解和执行反而变得混乱低效。四神系统采用了一种截然不同的、更符合软件工程理念的“微内核架构”。2.1 模块化设计解耦与复用传统的“超级Prompt”试图用一个指令解决所有问题这违反了“单一职责原则”。四神系统将AI助手需要的辅助能力拆分为四个独立的模块青龙 (Seiryu) - 记忆模块职责是管理对话历史、用户偏好和项目上下文。它解决“我是谁我从哪里来”的问题。玄武 (Genbu) - 防御模块职责是建立安全边界防止危险操作。它解决“什么不能做”的问题。白虎 (Byakko) - 诊断模块职责是审查输出结果进行事后分析和复盘。它解决“做得怎么样如何改进”的问题。朱雀 (Suzaku) - 品质模块职责是确保生成过程的一致性和输出质量。它解决“如何做得更好、更稳”的问题。这种设计的最大好处是可插拔。如果你的项目不涉及敏感操作完全可以不安装玄武如果你只是想让AI记住你的代码风格单独安装青龙就够了。每个模块的更新和维护也相互独立不会因为一个模块的变动而影响全局。2.2 事件驱动与懒加载极致的上下文效率这是四神系统最精妙的设计之一。它没有让AI在每次响应时都去加载所有模块的指令而是采用事件驱动Event-Driven的触发机制。具体是怎么工作的呢你需要在你的主系统指令文件例如Claude Code的CLAUDE.md里定义一系列“事件”和对应的“动作”。例如“当AI准备执行git push命令时事件请先读取genbu-v0.1/CLAUDE.md文件动作。”AI只有在检测到对应事件如“多步任务开始”、“准备交付代码”、“执行危险命令”时才会去加载特定模块的指令文件。这就是懒加载Lazy Loading。它保证了在绝大部分常规对话中宝贵的上下文窗口Context Window不会被固定的、庞大的规则集所占用从而将更多的Token留给当前任务本身显著提升了AI的理解和生成效率。2.3 LDRIT理论智能的“生死递归”项目提到了其理论基础是LDRITLife-Death Recursive Intelligence Theory生死递归智能理论。我们可以用一个简单的类比来理解AI的每次对话响应都像是一次“新生”。它基于当前的Prompt和上下文“生成”了这一次的智能。对话结束或上下文切换后这次“智能”就“死亡”了。传统的做法是试图让这次“智能”永生即保存全部对话历史但这在技术上有上下文长度限制在效率上也不经济。四神系统的思路是不追求智能的永生而是追求智能的“高质量传承”。青龙负责在“死亡”前提炼精华留下“遗产”记忆快照。玄武负责确保“新生”环境的安全避免在“胎儿期”就执行危险操作。朱雀负责优化“生成”过程本身确保每次“新生”都健康、优质。白虎负责在“生命”周期结束后进行“尸检”复盘总结经验教训指导下一次“新生”。这套理论让四神系统超越了简单的规则堆砌形成了一个自洽的、模拟智能生命周期的管理框架。2.4 本地优先与用户主权所有模块的配置、产生的记忆文件、诊断日志都以Markdown或JSON格式存储在你的本地项目目录中。这意味着绝对隐私你的对话习惯、项目信息、代码片段永远不会离开你的电脑。完全可控你可以随时查看、修改或删除任何文件。例如你可以手动编辑青龙生成的user_profile.md来修正AI对你的错误认知。透明可审计所有规则都是明文你可以清楚地知道AI在什么情况下会做什么检查避免了“黑箱”操作带来的不信任感。用户是最終決定者这一原则贯穿始终。四神模块在触发时通常会以“建议”、“检查项”或“提问”的形式与用户交互例如玄武在检测到危险操作时会说“检测到您即将向origin/main推送代码请确认这是您期望的分支。” 最终的执行权永远在用户手中。3. 四大模块深度解析与实战配置理解了设计理念我们来逐一拆解四个核心模块。我会结合真实的使用场景告诉你每个模块具体做了什么、如何配置以及我的实操心得。3.1 青龙 (Seiryu) - 你的AI私人记忆管家核心痛点每次新对话你都要重新介绍自己“我是张三这个项目是用React 18和TypeScript写的代码风格要求使用单引号函数组件优先...” 重复劳动令人崩溃。青龙的解决方案它为AI建立了一个结构化的记忆系统。这个记忆不是完整的聊天记录转储而是经过提炼的“知识快照”。核心工作流程创建用户档案在首次互动时青龙会引导AI询问用户的基本信息如角色、技术栈偏好、常用工具并生成一个user_profile.md文件。创建项目上下文对于多步骤任务青龙会在开始时创建一个project_context.md记录任务目标、已完成的步骤和下一步计划。设立检查点 (Checkpoint)在长任务的关键节点青龙会保存当前状态防止因对话中断或上下文丢失导致任务“归零”。传承遗产 (Legacy)在对话结束或上下文将满时青龙会提取本次对话的核心结论、决策和未解决问题保存为legacy_*.md文件供下次对话“继承”。实战配置与心得 青龙的配置非常简单克隆仓库后几乎无需额外设置。关键在于如何有效地触发它。在你的CLAUDE.md中我建议这样设置规则# 记忆与传承规则 (青龙 Seiryu) - 当开始一个涉及**3个以上步骤**的复杂任务时请先读取 ./seiryu-v1.2/CLAUDE.md 并执行 s5-checkpoint 来初始化项目上下文。 - 在每次对话**即将结束**或我提到“保存一下进度”时请先读取 ./seiryu-v1.2/CLAUDE.md 并执行 s2-legacy 来保存本次对话精华。 - 在**新对话开始时**如果本项目目录下存在 legacy_*.md 或 user_profile.md 文件请优先阅读它们以继承上下文。我的踩坑经验初期我让青龙在“每次对话开始”时都触发这有时会导致AI在简单问答前也机械地读取记忆文件略显低效。后来我调整为上述的“复杂任务触发”和“手动触发”模式效率更高。记住记忆是为了服务重要任务而不是成为每次交互的负担。3.2 玄武 (Genbu) - 代码库的守护神核心痛点AI兴高采烈地建议你运行rm -rf node_modules npm install却没告诉你这可能会误删未提交的修改或者它写好了一段代码准备直接git push origin main推到主分支。玄武的解决方案它是一套基于路径和操作类型的安全策略引擎。你可以定义“保护区域”当AI试图对这些区域进行敏感操作时玄武会介入并请求确认。核心工作流程路径配置你在genbu-v0.1/config/paths.md中定义受保护的目录和文件如/src/core/,*.env,package.json。操作监控玄武监控几类高危操作文件删除、Git推送尤其是向主分支、网络请求可能泄露数据、向记忆文件写入敏感信息。风险拦截与确认当检测到高危操作指向保护路径时玄武会暂停AI的执行向用户清晰说明即将进行的操作、潜在风险并请求明确确认。实战配置与心得 玄武的配置是四神中唯一需要较多手动设置的但这也是安全控制的精髓所在。首先编辑config/paths.md# 受保护路径配置 - PROTECTED: /src/core/ # 核心业务逻辑目录禁止直接修改 - PROTECTED: /config/ # 配置文件目录修改需确认 - PROTECTED: *.env # 环境变量文件禁止AI直接读取或写入 - PROTECTED: package.json # 项目依赖文件变更需谨慎 - WATCH: /test/ # 监视目录操作时会给出提醒然后在你的主CLAUDE.md中设置触发规则# 安全防御规则 (玄武 Genbu) - 在执行任何 git push、git commit --amend、force push 操作**之前**请先读取 ./genbu-v0.1/CLAUDE.md。 - 在执行任何文件删除操作如 rm, del或网络请求命令如 curl**之前**请先读取 ./genbu-v0.1/CLAUDE.md。 - 在向任何记忆文件如青龙生成的 *_profile.md 或 legacy_*.md写入内容**之前**请先读取 ./genbu-v0.1/CLAUDE.md 并执行 g3-memory-protect 检查。我的踩坑经验不要过度保护初期我把整个项目目录都设为PROTECTED导致AI每写一个文件都要问我严重干扰了工作流。正确的做法是分层级保护核心配置和源码用PROTECTED禁止/严格确认普通区域用WATCH仅提醒而像/dist/、/build/这样的生成目录则完全放开。玄武的精髓是防止灾难性错误而不是扼杀所有操作。3.3 白虎 (Byakko) - 冷酷无情的代码审计官核心痛点AI生成了一段代码跑起来没报错但可能存在性能瓶颈、潜在的边界条件Bug或者代码风格与项目严重不符。等到测试或上线后才发现问题修复成本高昂。白虎的解决方案它扮演“质量保证”和“复盘分析”的角色。在任务的关键节点如完成一个功能模块、交付成果前对AI的产出进行系统性审查。核心工作流程输出审查 (Output Review)当AI宣布完成某项交付物时白虎会触发一套审查清单检查项可能包括代码逻辑完整性、输入验证、错误处理、是否符合项目规范、是否有明显的性能问题等。回顾性分析 (Retrospective)在长任务的中期检查点或结束时白虎会引导AI进行自我复盘之前的方法有效吗遇到了什么障碍有哪些可以优化的地方并将复盘结论记录下来。实战配置与心得 白虎的触发时机非常重要审查得太频繁会拖慢节奏审查得太少又失去意义。在你的CLAUDE.md中我这样配置# 诊断与审查规则 (白虎 Byakko) - 当您声明**一个功能已完成**、**一段代码已就绪**或**准备交付**时在最终交付前请先读取 ./byakko-v0.2/CLAUDE.md 并执行 b1-output-review。 - 在完成一个**多步骤任务中的主要阶段**例如完成API接口开发、完成UI组件构建时请先读取 ./byakko-v0.2/CLAUDE.md 并执行 b2-retrospective 进行阶段复盘。我的踩坑经验白虎的审查清单是通用的。为了让它更有效我定制化了审查标准。具体做法是我复制了byakko-v0.2/下的核心指令文件在其中加入了我们团队特定的代码规范如“必须使用async/await而非回调”、“React组件必须使用PropTypes或TypeScript接口”。这样白虎就成为了我们团队的专属代码规范检查员。让AI用你的规则来检查它自己的输出效果出奇的好。3.4 朱雀 (Suzaku) - 确保输出稳定的压舱石核心痛点AI的生成结果有时会“飘忽不定”同样的问题两次回答的深度、格式或完整性可能差异很大。在需要稳定、可重复输出的场景如生成API文档、数据模型下这很令人困扰。朱雀的解决方案它通过“输出适配度检查”和“连贯性守卫”两大机制来约束和稳定AI的生成过程确保输出符合预期格式、涵盖必要内容并且与上下文保持高度连贯。核心工作流程输出适配度检查 (Output Fitness)在最终交付前朱雀会检查输出是否“匹配”任务要求。例如如果你要求“生成一个JSON格式的用户配置”朱雀会检查输出是否是有效的JSON是否包含了所有要求的字段。连贯性守卫 (Coherence Guard)在长任务执行过程中朱雀会在关键步骤检查AI当前的操作是否与最初的任务目标、以及之前已完成的步骤保持逻辑上的连贯防止AI“跑偏”。实战配置与心得 朱雀是提升AI协作“确定性”的关键模块。它的配置通常与青龙、白虎联动。在你的CLAUDE.md中配置# 生成质量规则 (朱雀 Suzaku) - 在任何**交付物完成**、准备将结果交付给我用户之前请先读取 ./suzaku-v0.2/CLAUDE.md 并执行 z3-output-fitness。 - 在**执行多步骤任务过程中**每完成2-3个子步骤后请先读取 ./suzaku-v0.2/CLAUDE.md 并执行 z5-coherence-guard确保方向没有偏离。我的踩坑经验朱雀的“连贯性守卫”有时会显得“过于严格”在需要发散思维、探索多种解决方案的“头脑风暴”阶段频繁的连贯性检查可能会抑制创造性。我的做法是按需开启。在需要稳定输出的“执行阶段”我会在指令中明确要求AI调用朱雀而在“探索阶段”我会暂时在指令中注释掉朱雀的触发规则给AI更多的自由空间。工具是为人服务的要根据任务阶段灵活调整策略。4. 从零开始完整安装与协同工作流现在我们假设你是一个新项目的开发者希望为你的AI编程助手以Claude Code为例配备全套的四神系统。下面是从环境准备到日常使用的完整流程。4.1 环境准备与模块安装首先在你的项目根目录下打开终端依次克隆四个模块。我建议使用带版本号后缀的目录名便于未来升级管理。# 进入你的项目目录 cd /path/to/your/project # 克隆四个模块 git clone https://github.com/Ryo-Hunter/seiryu.git seiryu-v1.2 git clone https://github.com/Ryo-Hunter/genbu.git genbu-v0.1 git clone https://github.com/Ryo-Hunter/byakko.git byakko-v0.2 git clone https://github.com/Ryo-Hunter/suzaku.git suzaku-v0.2执行完后你的项目根目录下会多出四个文件夹seiryu-v1.2/,genbu-v0.1/,byakko-v0.2/,suzaku-v0.2/。4.2 配置核心行为规则接下来配置AI助手的行为规则。在Claude Code中这是通过项目根目录下的CLAUDE.md文件实现的。如果不存在就创建一个。将以下综合规则添加到你的CLAUDE.md文件中。这些规则定义了在何种“事件”下AI应该去调用哪个“神兽”。# 项目AI协作规范 (集成四神系统) ## 核心行为规则 请你作为本项目的开发助手遵循以下规则以保障协作的安全、高效与可追溯 ### 安全第一 (玄武 Genbu) - 在执行任何 **git push**、**git commit --amend**、**git push --force** 命令之前**必须**先读取 ./genbu-v0.1/CLAUDE.md 文件并遵循其安全检查流程。 - 在执行任何 **文件删除命令** (如 rm, del) 或 **网络访问命令** (如 curl, wget) 之前**必须**先读取 ./genbu-v0.1/CLAUDE.md 文件。 - 在向任何由本系统管理的记忆文件位于 seiryu-v1.2/data/ 或根目录下 *_profile.md, legacy_*.md写入内容前**必须**先读取 ./genbu-v0.1/CLAUDE.md 并执行 g3-memory-protect 检查。 ### 记忆与传承 (青龙 Seiryu) - 当开始一个**涉及3个或以上步骤的复杂任务**时请先读取 ./seiryu-v1.2/CLAUDE.md 并执行 s5-checkpoint以建立或加载项目上下文。 - 在本次对话**即将结束**或我明确要求“保存进度”时请先读取 ./seiryu-v1.2/CLAUDE.md 并执行 s2-legacy以保存本次对话的核心成果。 - 在新对话开始时如果发现存在 legacy_*.md 或 user_profile.md 文件应优先阅读以继承上下文。 ### 质量与稳定 (朱雀 Suzaku) - 在**任何交付物完成**如代码块、文档、解决方案描述完毕并准备提交给我之前请先读取 ./suzaku-v0.2/CLAUDE.md 并执行 z3-output-fitness进行最终质量校验。 - 在**执行多步骤任务过程中**每完成一个主要子阶段例如设计完数据库Schema、写完一个核心函数请先读取 ./suzaku-v0.2/CLAUDE.md 并执行 z5-coherence-guard确保当前工作与总目标一致。 ### 诊断与复盘 (白虎 Byakko) - 在**宣布一个功能模块或任务完成**时请先读取 ./byakko-v0.2/CLAUDE.md 并执行 b1-output-review对产出进行最终审查。 - 在**复杂任务达到一个里程碑或遇到瓶颈**时请先读取 ./byakko-v0.2/CLAUDE.md 并执行 b2-retrospective进行阶段性复盘。 ## 通用入口 如果以上事件未被自动触发而我需要你使用某个特定功能我会直接指示你“请先读取 [模块目录名]/CLAUDE.md”。例如“请先读取 seiryu-v1.2/CLAUDE.md”。4.3 初始化与首次对话保存CLAUDE.md后在你的Claude Code中打开项目并开始一个新的对话。你可以通过一个简单的指令来初始化系统“你好请先阅读本项目的CLAUDE.md文件以了解协作规范。然后请帮我分析一下当前项目结构。”AI会读取CLAUDE.md理解四神系统的规则。由于这是“开始一个多步骤任务”分析项目结构根据规则它会自动触发青龙执行s5-checkpoint。青龙可能会引导AI与你进行简短交互创建初始的用户档案和项目上下文文件。同时因为你要AI“分析项目结构”它可能会尝试执行ls或find命令。根据规则在执行任何操作前玄武的安全检查并不会被触发因为这些不是高危命令。但如果你后续要求AI删除某个文件玄武就会介入。4.4 模块协同工作流示例让我们模拟一个真实场景“为项目添加一个用户登录的API端点”。任务开始触发青龙你提出这个需求。AI识别为“多步骤复杂任务”自动读取青龙模块创建project_context.md记录任务目标“实现用户登录API”。设计阶段触发朱雀AI开始设计接口。在它完成接口定义/auth/login POST方法接收username/password并准备“交付”这个设计给你确认前朱雀被触发执行z3-output-fitness检查设计是否完整是否包含URL、方法、参数、返回格式。编码阶段触发玄武AI开始编写代码。当它写完代码准备执行git add .和git commit -m add login api时这是安全操作玄武不触发。但如果它下一步建议git push origin main玄武会立刻介入读取其指令并向你发出警告“检测到向受保护分支main推送代码请确认是否应在功能分支上进行”代码完成触发白虎AI编写完所有代码并自测通过后宣布“登录API端点已完成”。此时白虎被触发执行b1-output-review。它会按照审查清单检查代码是否有输入验证密码是否加密错误处理是否完备是否符合项目的代码风格它会将发现的问题如果有列出来。交付前最后检查再次触发朱雀在白虎审查完毕AI准备将最终代码和说明交付给你之前朱雀再次被触发z3-output-fitness做最终的输出格式和完整性检查。任务结束或中断触发青龙如果你说“好的我先看看”对话暂停。AI根据规则在上下文可能被清理前触发青龙的s2-legacy将本次关于登录API的设计决策、代码位置、待办事项等保存为legacy_auth_login.md文件。这个流程展示了四神如何基于事件任务开始、操作执行、交付完成自动、有序地介入形成一个完整的工作流闭环。5. 高级技巧、疑难排查与个性化定制经过一段时间的深度使用我总结出一些超越官方文档的高级技巧和常见问题的解决方案。5.1 性能优化与上下文管理问题频繁读取外部Markdown文件会不会拖慢AI响应速度分析与解决实际上Claude等模型读取本地文件速度极快影响微乎其微。真正的瓶颈在于上下文窗口的占用。每个模块的CLAUDE.md文件都可能包含数百字的指令。如果四个模块的指令在每次对话时都被加载会浪费大量Token。我的优化策略精简主规则在主CLAUDE.md中我只保留最核心、最明确的触发指令去掉所有解释性文字。解释性文字可以放在各个模块自己的CLAUDE.md里。按需加载这是四神系统本身的设计优势一定要利用好。确保你的触发条件精确对应高频、重要的场景避免在简单问答时触发复杂模块。合并检查点对于青龙的“检查点”和朱雀的“连贯性守卫”如果它们经常在同一个任务阶段被触发可以考虑在心理上将其合并。例如在AI完成一个复杂子步骤后你可以直接指令“请先读取青龙和朱雀的指令分别执行检查点和连贯性守卫。” 但这需要手动指令失去了事件驱动的自动化美感。5.2 模块冲突与优先级调整问题如果多个模块对同一事件都有反应听谁的解决官方定义了默认优先级玄武 (防御) 青龙 (记忆) 朱雀 (品质) 白虎 (诊断)。这个优先级非常合理安全永远是第一位的。但在某些边缘情况下你可能需要调整。例如你希望白虎的代码审查b1-output-review在朱雀的最终格式检查z3-output-fitness之前进行因为逻辑错误比格式错误更严重。目前四神系统没有提供图形化的优先级配置但你可以通过调整主CLAUDE.md中规则的描述顺序和严格程度来施加心理影响或者直接修改byakko-v0.2/CLAUDE.md和suzaku-v0.2/CLAUDE.md文件让白虎的审查结论作为朱雀检查的一个输入项。这需要你对各个模块的指令文件有较深的理解。5.3 适配其他AI开发环境四神系统虽然主要面向Claude Code设计但其核心是Markdown文件因此可以适配其他环境。CursorCursor使用.cursorrules文件作为项目级规则。你可以将四神的主规则内容翻译并放入.cursorrules。更大的挑战在于Cursor的“规则”触发机制不如Claude Code的CLAUDE.md灵活。你可能需要更多地依赖手动指令来触发各个模块或者利用Cursor的“自定义命令”功能为每个神兽创建一个快捷命令。Windsurf / VS Code Copilot这些环境通常依赖全局或工作区设置中的“系统提示词”System Prompt。你可以将四神的规则整合到你的系统提示词中。同样自动化触发会变弱需要更多手动干预。通用技巧在所有环境中一个万能的备用方法是直接告诉AI去读那个文件。当你需要某个功能时直接说“请先读取项目目录下seiryu-v1.2/CLAUDE.md文件的内容并遵循它。” 这虽然不够自动化但确保了功能的可用性。5.4 个性化定制打造属于你的“神兽”四神系统的开源魅力在于你可以深度定制。以下是我的几个定制案例强化玄武的路径保护我编辑了genbu-v0.1/config/paths.md不仅保护路径还定义了正则表达式规则防止AI生成或修改包含特定模式的文件如*secret*.yml,*config*.prod.*。扩展白虎的审查清单我在byakko-v0.2/目录下创建了一个custom_checklist.md里面是我们团队的前端代码规范ESLint规则、组件命名公约、状态管理库使用规范等。然后修改了白虎的主指令文件在b1-output-review流程中引入这个自定义清单。为青龙增加领域知识对于特定技术栈的项目比如使用NestJS的Backend项目我在青龙生成的project_context.md模板中预置了项目结构说明、常用命令npm run start:dev和代码风格链接。这样每次新任务开始时AI能更快地进入角色。5.5 常见问题排查实录问题现象可能原因解决方案AI完全不触发任何模块规则。1. 主CLAUDE.md文件未被AI正确识别或读取。2. 触发条件描述得不够精确AI无法匹配。1.确认环境在Claude Code中确保项目已打开且CLAUDE.md位于根目录。可以主动问AI“请描述一下本项目CLAUDE.md中的主要规则。”2.简化并强化触发词将规则中的“当...时”改为更直接的“在执行X操作前必须先读取Y文件”。玄武频繁拦截无害操作过于烦人。config/paths.md中受保护路径设置得过于宽泛如/src/。精细化路径配置只保护最核心的部分如/src/core/,/src/utils/constants.ts。使用WATCH级别替代PROTECTED进行提醒而非拦截。定期审查和调整保护规则。青龙保存的记忆文件内容杂乱没用。青龙的“遗产”提炼可能不够精准保存了太多对话细节。手动引导提炼在对话结束时不要只说“保存一下”而是给出明确指令“请总结本次对话关于用户登录API设计的三个核心决策以及遗留的两个待办问题并保存为遗产文件。” AI会遵循你的结构进行保存。白虎的审查流于形式发现不了深层次问题。默认的审查清单比较通用未结合项目具体技术栈。定制审查清单如前所述根据项目技术栈React性能优化、SQL注入防范、API设计规范等丰富白虎的审查项。让审查更有针对性。安装多个模块后AI响应变慢或混乱。可能某个模块的指令文件编写有误或规则冲突导致AI陷入循环。隔离测试禁用所有模块然后逐一启用并测试。检查每个模块的CLAUDE.md文件语法是否正确指令是否清晰无歧义。确保规则是“事件-动作”型而非模糊的状态描述。四神系统不是一个安装即忘的“银弹”它更像一套需要你稍加调校的精密仪器。花一点时间理解每个模块的机制并根据自己的工作流进行微调它能带来的效率提升和安全感是巨大的。从我的体验来看它尤其适合中大型、长期维护的项目或者需要与AI进行深度、复杂协作的场景。对于一次性脚本或简单问答它的价值可能无法完全体现。