规则体系从公式公理到设计理念的工程范式副标题WorkFlowPrjrules/目录的架构设计与使用哲学版本v2.0 |更新日期2026-07-24关键词规则体系、公式公理、分层引用、设计理念、AI协作、系统提示词用途本文档是 AI 的系统提示词System Prompt用于向 AI 解释rules/目录的整体架构、设计理念和使用方法。AI 应通过本文档快速理解规则体系的组织方式然后根据具体任务到对应文件中查找精确规则。目录规则体系从公式公理到设计理念的工程范式目录引言为什么需要规则体系第一部分设计哲学1.1 万物皆公式1.2 分层引用架构1.3 信噪比优先第二部分公式公理体系2.1 公式的六种类型2.2 公式的调用契约2.3 公式间的组合关系第三部分文件架构总览3.1 九文件的定位与职责3.2 核心规则速览聚合架构上下文生命周期文件读取策略输出精简策略性能优化零容忍规范场景模式项目规范第四部分设计理念详解4.1 为什么用公式而非自然语言4.2 为什么分层4.3 反模式清单第五部分使用指南5.1 如何查找规则5.2 如何修改规则5.3 如何新增规则第六部分公式索引6.1 核心原则§一6.2 场景模式§二6.3 性能优化§三6.4 零容忍规范§四6.5 聚合架构§五6.6 文件读取策略§六6.7 上下文生命周期管理§七6.8 输出精简策略§八附录快速参考路径引言为什么需要规则体系在 AI 辅助编程的实践中一个根本性的矛盾始终存在AI 需要精确、可执行的规则来约束行为但自然语言描述的规则天然带有歧义和不确定性。当规则分散在多个文件中、以不同表述重复定义时AI 的执行一致性就更加难以保证。WorkFlowPrj 的rules/目录正是为解决这一矛盾而设计。它不是一份简单的开发规范文档集而是一套以公式为最小逻辑单元、以分层引用为组织方式、以可计算性为设计目标的规则工程体系。本文档是 AI 的系统提示词System Prompt。AI 首次接触 WorkFlowPrj 项目时应首先阅读本文档以理解规则体系的整体架构。本文档第六部分提供全部公式的索引名称、类型、参数签名、用途精确逻辑定义统一在rules/formulas.md中维护。场景化说明在各引用层文件中。这套体系的核心信念是好的规则是可计算、可组合、可验证的。当规则从自然语言进化为公式从分散定义收敛为单一事实来源AI 的执行就从猜意图变成了算结果。第一部分设计哲学1.1 万物皆公式规则体系的基石是rules/formulas.md——它是所有规则的唯一逻辑本体。其他 8 个规则文件不重复定义规则逻辑仅做引用和场景化说明。┌─────────────────────────────────────────────────┐ │ formulas.md唯一事实来源 │ ├─────────────────────────────────────────────────┤ │ §一 项目规范 → project-rules.md │ │ §二 场景模式 → scenarios.md │ │ §三 性能优化 → performance-optimization.md │ │ §四 零容忍规范 → zero-tolerance.md │ │ §五 聚合架构 → aggregation-architecture.md │ │ §六 文件读取 → file-reading-strategy.md │ │ §七 上下文管理 → context-lifecycle-management.md │ │ §八 输出精简 → file-writing-strategy.md │ └─────────────────────────────────────────────────┘这种设计的直接好处是修改规则只需改一处。当formulas.md中的公式更新时所有引用它的文件自动获得最新语义不存在改了 A 文件忘了改 B 文件的同步问题。1.2 分层引用架构规则体系分为三个层次每个层次服务于不同的使用场景本体层rules/formulas.md所有规则的精确逻辑定义。这是唯一需要修改的地方。公式以参数→条件→输出的形式表达消除自然语言的歧义。引用层rules/下其他 8 个.md文件面向场景的快速查阅。每个文件聚焦一个主题领域列出该领域的公式名称和用途但不重复公式逻辑。AI 可以快速了解有哪些规则需要精确逻辑时再到formulas.md查阅。知识层docs/KnowLedge/完整背景文档和设计讨论。这些文件解释规则背后的设计决策、演进历程和理论依据帮助理解为什么这样设计。三层之间的关系是知识层解释设计动机本体层定义精确逻辑引用层提供快速导航。三者互补不重复。1.3 信噪比优先规则体系自身也遵循它所定义的输出精简三定律WellFormed(output)—rules/formulas.md§八语义自足命名表达意图结构揭示关系。公式的参数名和条件分支本身就是文档不需要额外注释来解释这个参数是什么意思。结构正交每段有且仅有一个职责。每个公式只做一件事每个规则文件只覆盖一个主题领域。没有万能公式或大而全的规则文件。表达克制不写入可有可无的内容。引用层文件不重复公式逻辑只列出公式名称和用途。需要精确逻辑时去formulas.md查阅。第二部分公式公理体系2.1 公式的六种类型rules/formulas.md中的每个公式都有一个类型标签标识其逻辑性质类型标签含义示例阈值决策[TD]基于阈值做二元或多元判断ReadMode(S): S50KB→direct分类映射[CM]输入到输出的分类映射ToolSelect(taskType): file_read→MCP_Script条件决策[CD]多条件组合的决策树CompactDecision(phaseChanged, moduleDone, ctx)序列映射[SM]有序步骤的流程映射LogAddFlow(step): 1→identify_layer质量评估[QA]质量合规性检查CodeQualityCheck(code): ¬emptyCatch∧...→pass成本计算[CC]成本或复杂度计算CalculateCost(N, R): Cost_batch(N)≈max(T_i)R这六种类型覆盖了规则工程的全部需求判断做什么TD/CD、选择怎么做CM、按什么顺序做SM、做得怎么样QA、值不值得做CC。2.2 公式的调用契约每个公式遵循统一的调用契约包含三个部分公式名(参数...) [类型] 逻辑体条件分支 → 输出结果 参数说明参数名含义(类型)以DataProcessMode为例参考rules/formulas.md§一DataProcessMode(S, Ctx) [CD] S50KB∧Ctx≤0.7→direct · S50KB∧Ctx0.7→sandbox · S≥50KB∧Ctx≤0.7→sandbox · S≥50KB∧Ctx0.7→sandbox_then_dump这个公式接受两个参数文件大小 S 和上下文使用率 Ctx通过四个条件分支输出不同的数据处理模式。调用者不需要理解为什么这样设计只需要按参数传入值按输出执行即可。2.3 公式间的组合关系公式不是孤立的。它们通过输入输出相互衔接形成可组合的决策链场景检测链参考rules/formulas.md §二 rules/scenarios.md ScenarioDetect(taskDescription) → 场景类型 → Toolchain(scene) → 工具链列表 → 执行完毕后自动附加 [reason, record] 上下文压缩链参考rules/formulas.md §七 rules/context-lifecycle-management.md CompactDecision(phaseChanged, moduleDone, ctx) → 压缩类型 → CA(action) → 具体压缩动作 废弃处理链参考rules/formulas.md §一 rules/project-rules.md HFC(projectType, hasReference) → 废弃处理动作 → 文件标记为 Dtrue → HandleDeprecated(D, hasReference, ...) → 后续处理这种组合关系的设计原则是每个公式的输出恰好是下一个公式的输入。不需要额外的胶水逻辑来衔接公式链本身就是可执行的流程定义。第三部分文件架构总览3.1 九文件的定位与职责文件定位引用 formulas.md核心内容rules/formulas.md唯一逻辑本体—全部公式的精确定义8 章 30 公式rules/aggregation-architecture.md聚合架构设计规范§五边界契约实现三种拓扑结构rules/context-lifecycle-management.md上下文生命周期管理§七阶段压缩/模块压缩/紧急转储rules/file-reading-strategy.md文件读取策略§六三阶段模型scan→preview→deeprules/file-writing-strategy.md输出精简策略§八精简三定律 三问检查rules/performance-optimization.md性能优化策略§三上下文预算控制rules/scenarios.md常用场景模式§二场景→工具链映射rules/zero-tolerance.md零容忍规范§四编译错误/代码质量/异常处理rules/project-rules.md项目规范§一绝对路径/废弃文件/构建每个文件只覆盖一个主题领域职责边界清晰。AI 在遇到具体任务时应按以下方式定位文件需要做代码分析/重构/审查→ 先查rules/scenarios.md确定场景和工具链需要读取文件→ 查rules/file-reading-strategy.md需要写入/修改代码→ 查rules/file-writing-strategy.md需要管理上下文/压缩会话→ 查rules/context-lifecycle-management.md需要优化性能/控制预算→ 查rules/performance-optimization.md需要设计模块架构→ 查rules/aggregation-architecture.md需要处理编译错误/代码质量→ 查rules/zero-tolerance.md需要处理文件冲突/废弃代码→ 查rules/project-rules.md需要精确的公式逻辑→ 查rules/formulas.md对应章节3.2 核心规则速览聚合架构参考rules/aggregation-architecture.md→rules/formulas.md§五聚合的本质是边界 契约 实现。三种拓扑结构可嵌套组合点聚合分散同类操作收敛到单一入口适用于外部依赖和数据流边界收敛线聚合有序步骤编排为管线适用于流程编排和阶段式处理面聚合模块公开能力收敛到入口面适用于模块能力出口收敛检测公式包括SCA创建判断、VB边界验证、GodAggregation上帝聚合检测、ScatteredAggregation分散检测、ImplicitAggregation隐式检测、CyclicAggregation循环检测。上下文生命周期参考rules/context-lifecycle-management.md→rules/formulas.md§七三种压缩场景由CompactDecision统一决策触发条件压缩类型动作阶段切换阶段压缩记录→更新进度→清理→新会话恢复模块完成模块压缩记录摘要→记录注意事项→更新进度→清理Ctx 0.9紧急转储直接attempt_completion清空反模式包括阶段粘连、模块膨胀、过度压缩、压缩替代转储、恢复路径丢失。文件读取策略参考rules/file-reading-strategy.md→rules/formulas.md§六三阶段模型scan → preview → deep。每个阶段只读取对应信息层次的内容scan只读 meta 信息路径、大小、语言不读内容preview读 meta structural 信息类签名、函数签名一次批量调用deep读全部三层但只在确认需要后执行输出精简策略参考rules/file-writing-strategy.md→rules/formulas.md§八精简三定律语义自足命名表达意图结构揭示关系数据格式自描述结构正交每段有且仅有一个职责职责间无重叠表达克制不写入可有可无的内容不预留抽象三问检查ShouldWrite移除是否损失信息是否有更简洁表达维护成本是否超过价值三者皆否才写入。性能优化参考rules/performance-optimization.md→rules/formulas.md§三上下文预算按操作类型分配文件读取用partial_read代码执行用summary_only批量操作用batch_with_queries文档网页用index_no_content。预算按阶段分配规划阶段较多准备阶段中等核心阶段最大验证阶段少量完成阶段不分配。零容忍规范参考rules/zero-tolerance.md→rules/formulas.md§四优先级类型处理方式P0编译错误立即修复修复后必须编译通过P1运行时异常按失败模式选择 FailFast/FailSafe/FailGracefulP2代码质量警告禁止空 catch、console.log、魔法数字、未使用导入、硬编码路径、TODO/FIXME场景模式参考rules/scenarios.md→rules/formulas.md§二任务描述通过ScenarioDetect映射到场景类型再通过Toolchain获取工具链执行完毕后自动附加推理和记录知识步骤。6 种预定义场景代码分析、知识构建、问题解决、代码审查、性能优化、重构。项目规范参考rules/project-rules.md→rules/formulas.md§一路径必须使用绝对路径禁止cd切换目录。废弃文件移至_deprecated/目录并编译排除。项目为 C# (.NET) PowerShell Python 混合项目。第四部分设计理念详解4.1 为什么用公式而非自然语言维度公式自然语言精确性条件分支明确无歧义容易产生多种解读可组合性公式输出可作为另一公式输入需要人工理解衔接可验证性可逐条检查条件是否满足依赖主观判断可维护性修改一处公式所有引用同步多处文本需同步修改公式的本质是将意图转化为计算。当 AI 面对一个决策点时公式告诉它输入这些参数按这些条件判断得到这个结果——而不是根据你的理解酌情处理。4.2 为什么分层单一事实来源rules/formulas.md确保规则的一致性但纯公式的形式对快速查阅不友好。引用层文件的存在解决了这个问题面向场景的导航按主题快速定位。想知道文件读取有什么规则去rules/file-reading-strategy.md。示例和反模式补充公式无法表达的上下文。公式告诉怎么做示例和反模式告诉什么情况下这么做和什么情况下不要这么做。降低认知负荷不需要每次查阅都理解全部公式。大多数时候只需要知道有哪些规则不需要知道规则的精确逻辑是什么。4.3 反模式清单规则体系自身也需要避免以下问题反模式表现后果阶段粘连不压缩直接进入下一阶段上下文持续膨胀模块膨胀一个文件包含多个无关规则破坏结构正交性过度压缩每步都压缩频繁attempt_completion反而降低效率重复表达同一规则在 formulas.md 和引用文件中重复定义修改时必须同步两处注释替代命名用注释解释本应自描述的公式说明公式命名不够好预留抽象为不存在的未来写入抽象层增加不必要的复杂度第五部分使用指南5.1 如何查找规则AI 在遇到任务时按以下流程查找规则确定任务类型分析 / 构建 / 修复 / 审查 / 优化 / 重构定位场景在rules/scenarios.md中找到对应场景获取工具链通过Toolchain(scene)获取工具链列表查阅细节如需规则精确逻辑到rules/formulas.md对应章节查阅公式5.2 如何修改规则修改本体只修改rules/formulas.md中的公式定义唯一事实来源同步引用检查引用层文件是否需要同步更新验证关系确保公式间的组合关系仍然成立更新速览更新本文档中的核心规则速览部分如涉及5.3 如何新增规则添加公式在rules/formulas.md对应章节添加新公式选择类型选择正确的公式类型标签[TD]/[CM]/[CD]/[SM]/[QA]/[CC]定义逻辑定义清晰的参数和条件分支补充引用在对应的引用层文件中添加引用和场景化说明更新索引在本文档第六部分公式索引中添加新公式的索引条目第六部分公式索引本节提供rules/formulas.md中全部公式的索引包含公式名称、类型标签、参数签名和一句话用途说明。精确逻辑定义统一在rules/formulas.md中维护本文档不复制公式逻辑体以避免重复维护问题。公式类型标签[TD]阈值决策 ·[CM]分类映射 ·[CD]条件决策 ·[SM]序列映射 ·[QA]质量评估 ·[CC]成本计算6.1 核心原则§一公式类型参数用途ToolPriority[CM]toolType工具优先级选择MCP BuiltIn CLIToolSelect[CM]taskType按任务类型选择具体工具DataProcessMode[CD]S, Ctx决定数据是否进入对话与 ReadMode 独立决策ReadMode[TD]S决定文件读取方式与 DataProcessMode 独立决策Action[TD]error架构重构判断是否应先重构再处理HFC[CD]projectType, hasReference文件冲突时的初始处理方式HandleDeprecated[CD]D, hasReference, projectType, confirmed已标记废弃代码的后续处理HandleAmbiguity[CD]semantics, phaseCS0104 歧义引用处理PathFormat[CM]context不同执行上下文的路径格式LogAddFlow[SM]step日志添加的 7 步流程6.2 场景模式§二公式类型参数用途Toolchain[CM]scene场景类型到工具链的映射ScenarioDetect[CM]taskDescription从任务描述检测场景类型6.3 性能优化§三公式类型参数用途CB[CM]actionType上下文预算策略分配BudgetAlloc[CC]phase各阶段预算分配比例Background[CM]taskType判断是否应后台运行MergeServerRequest[CD]hasServer, hasRequest服务器请求是否合并调用6.4 零容忍规范§四公式类型参数用途FailMode[CM]errorType失败模式选择ThrowRule[CM]violationType异常类型选择FixPriority[CM]errorType修复优先级判定CodeQualityCheck[QA]code代码质量合规性检查6.5 聚合架构§五公式类型参数用途SCA[CD]condition服务聚合锚点判断是否应创建聚合点VB[CD]boundary边界有效性验证CommunicationMode[CM]scenario通信方式选择GodAggregation[TD]methods, lines上帝聚合检测methods30 ∨ lines1000ScatteredAggregation[QA]hasUnifiedEntry分散聚合检测ImplicitAggregation[QA]boundaryClear隐式聚合检测CyclicAggregation[QA]depA→B, depB→A循环聚合检测6.6 文件读取策略§六公式类型参数用途IL[CM]infoType信息层次分类meta / structural / detailedRP[CM]phase三阶段读取scan / preview / deepIP[CM]taskType信息路径选择chain / flatSS[CM]taskType读取策略选择InfoDomain[CM]task, fileSize信息域评估范围、类型、复杂度InfoLevelMatch[QA]phase, infoType信息层次与阶段一致性校验CalculateCost[CC]N, R操作成本计算顺序 vs 批量6.7 上下文生命周期管理§七公式类型参数用途PD[CM]phase阶段定义5 个阶段的名称和活动集CompactDecision[CD]phaseChanged, moduleDone, ctx压缩决策树已合并 ShouldCompactCA[SM]action压缩动作执行序列6.8 输出精简策略§八公式类型参数用途WellFormed[QA]output输出精简度三定律联合评估ShouldWrite[CD]removable, simpler, costExceedsValue三问检查是否应写入新内容OA[CD]state, infoComplete, scope, recoverable已存在内容的修改/废弃/创建决策附录快速参考路径需求优先查阅精确逻辑理解规则体系整体架构本文档—查找精确的公式定义rules/formulas.md本文档 §六索引确定场景和工具链rules/scenarios.md本文档 §6.2文件读取策略rules/file-reading-strategy.md本文档 §6.6输出精简策略rules/file-writing-strategy.md本文档 §6.8上下文生命周期管理rules/context-lifecycle-management.md本文档 §6.7性能优化与预算控制rules/performance-optimization.md本文档 §6.3聚合架构设计rules/aggregation-architecture.md本文档 §6.5零容忍规范rules/zero-tolerance.md本文档 §6.4项目级规范rules/project-rules.md本文档 §6.1设计理念总结规则体系本身也遵循它所定义的规则 —rules/formulas.md是唯一事实来源语义自足每个文件有且仅有一个职责结构正交不写入可有可无的内容表达克制。这是一套关于规则的规则一套元规则体系。