1. 我第一次意识到AI 约束也需要架构我原来的规则是不断叠加出来的遇到一个问题就让 AI 把当次经验写进去。久而久之规则混在一起、杂乱无章无论是我还是 AI都很难根据实际场景快速定位应该遵循什么。当我看到重新梳理后的版本时才意识到问题不只是标题不够清晰而是缺少整体架构。共性约束放在前面项目特性约束放在后面不同场景有对应的标题和规则入口。这样的条理性让 AI 更容易准确执行也让我第一次有能力审查这些规则本身。2. 以前我是怎样让 AI 维护规则的以前只要开发中出现一次问题或者我担心它以后重复出现我就会让 AI 把这次经验写进规则里。我的出发点是避免重复犯错但当时没有区分它是项目特性、某个场景的限制还是应该长期执行的共性规则。结果就是许多本应有条件的要求被写成了绝对规则。更关键的是我会审查 AI 对工程代码的修改却几乎不审查它对规则文档的修改。代码至少还能结合功能和编译结果判断规则一旦混乱会在之后的每一次开发中持续影响 AI 的决策而我当时并没有意识到这一点。3. 为什么“遇到问题就追加规则”会失控当规则不断增加、缺少分层和定位路径时AI 很难在当前任务中准确找到真正适用的约束规则之间还可能相互冲突。最后的结果是我写进文档的规则并没有在开发时被有效执行。典型问题是把特殊场景的经验写成绝对要求。例如某次硬件交互改动确实需要增加调试入口或目标机验证并不代表所有硬件相关改动都应自动新增调试命令某次结构复杂的接口需要详细注释也不代表每个函数都应该补充同等粒度的注释。前者会制造无关改动后者会增加维护和审查成本。如果再出现另一条规则要求“最小修改、避免无关改动”两者就可能冲突。我自己无法判断哪条规则应优先AI 的执行也会变得不可控。现在回看我不应该等到规则越来越乱才处理。只要发现 AI 的执行开始混乱、反复遗漏某些要求或出现无关的额外改动就应当把它视为一次规则系统的检查信号而不只是继续追加一条新规则。4. 我看到的好规则优先级、分层与可定位性我后来理解好的规则并不是越多越好而是应当有明确的优先级、清晰的章节和可定位的场景入口。共性约束应放在前面项目特性和专项规则放在后面。这样做的目的是让 AI 能根据当前任务的实际场景找到并执行对应的逻辑约束普通修改遵循通用开发流程涉及某个项目、模块或高风险操作时再进入相应的专项规则。它不需要把无关限制强行套到当前任务上效率和准确性才能同时提高。我认为关键原则可以概括为**AI 在满足场景条件时执行这个场景的逻辑。**5. 我给自己建立的规则审查框架四个特性今后每当考虑新增或修改一条 AI 规则时我都会先检查它是否满足以下四个特性。一致性新规则不能与已有规则冲突。一旦新旧规则冲突我自己都无法判断哪个才是正确的也就无法完成有效审阅AI 面对互相矛盾的约束执行结果也会变得不可控。规则再具体、再严格建立在冲突之上都没有意义。有效性一条规则的收益应大于执行成本。如果它原本只适合特殊场景却被扩大为所有任务都必须遵守的要求那么它不仅会增加不必要的检查和修改成本也会让简单任务变慢。这样的规则即使没有直接冲突也不值得作为通用规则保留。边界性对于只适用于某个项目、模块或风险场景的规则不能只写结论。规则需要明确适用场景并放在对应标题下写清楚触发条件。只有当 AI 满足这些条件时才执行这一场景的逻辑避免把局部约束误用到所有开发任务中。证据性如果只是一次偶发现象或相关工程事实还没有验证清楚就不应立刻把它写成长期规则。可以先结合自己的理解向 AI 再次确认要求它检查代码、配置、调用关系或历史现象弄清问题是否真实、是否可能重复出现、是否值得抽象为规则证据不足时宁可保留为待观察的问题也不要匆忙追加约束。6. 从让 AI 写代码到让 AI 按规则工作这次经历让我意识到我要做的不只是让 AI 帮我完成开发任务更重要的是让 AI 自身也成为可维护的工作系统。我需要理解规则如何影响 AI 的判断审查规则是否一致、有效、有边界且有证据再让 AI 在明确场景下执行对应逻辑。这样AI 不再只是一个被动执行指令的工具而能成为我理解开发过程、提升系统设计能力和提高工程效率的协作对象。对我来说这也是一个提醒嵌入式开发的价值不只是把功能写出来还包括建立能够持续演进、可以审查和验证的工程方法。AI 是这个方法的一部分而不是方法本身。AI 规则治理框架 适用对象需要让 AI 长期参与软件开发、调试和文档维护的个人或团队。 不包含任何项目路径、产品信息、代码实现或内部工具配置。 ## 一、文档分层 建议按“越通用越靠前、越具体越靠后”的顺序组织。 1. 规则优先级与冲突处理 2. 任务执行闭环 3. 权限与安全边界 4. 编辑、实现和兼容性要求 5. 测试、验证与交付 6. 规则文档自身的维护治理 7. 项目事实、模块导航与专项约束 通用规则只描述跨项目可复用的决策方式项目事实、模块入口、产品约束和历史案例放入专项章节不能混入最高优先级规则。 ## 二、每次开发任务的闭环 1. 判断任务类型和风险等级。 2. 检查已有改动保护用户现场。 3. 对照需求、源码、配置和调用链定位真实入口。 4. 判断是否存在影响方案的缺失信息有则提出具体待确认项。 5. 在授权范围内做最小实现。 6. 按风险选择验证差异审查、静态检查、编译、测试或目标环境验证。 7. 汇报改动、已验证内容、未验证项和剩余风险。 简单且边界明确的小改动可直接执行新功能、跨模块修改、协议/持久化/并发/硬件交互或验收不清的需求应先完成开发前审查。 ## 三、规则的写法 一条可执行规则至少包含 - **触发条件**什么时候适用 - **要求动作**AI 应执行什么 - **边界或例外**什么时候不适用 - **验证方式**如何确认执行正确 示例结构 markdown ### [场景名称] 当 [明确触发条件] 时 - 执行 [具体动作]。 - 检查 [风险点或事实依据]。 - 若 [例外条件]则 [替代动作或向用户确认]。 - 通过 [验证方式] 确认结果。 仅在安全、兼容性或不可逆风险确实不存在合理例外时使用“必须”“不得”等绝对措辞。普通工程实践应写清条件和例外。 ## 四、新增规则的四性审查 | 特性 | 审查问题 | 不满足时的处理 | | --- | --- | --- | | 一致性 | 是否与既有规则、授权边界或验证要求冲突 | 合并、改写或删除冲突规则后再写入。 | | 有效性 | 能否明显减少误改、返工或定位成本是否让简单任务变慢 | 降低强度、缩小范围或不写入。 | | 边界性 | 是共性规则、项目约束还是单一场景经验触发条件是否明确 | 放入对应章节并补充条件和例外。 | | 证据性 | 工程事实是否已核验问题是否会重复发生且值得抽象 | 先验证或记录为待观察项不升级为长期规则。 | ## 五、规则维护流程 新增、删除或改写规则前 1. 完整阅读共同规则和目标项目的专项章节。 2. 搜索现有表述优先修订、合并或删除旧规则不在文末机械追加。 3. 进行四性审查并评估执行成本和副作用。 4. 确认规则归属跨项目共性规则应同步项目事实只放入受影响项目。 5. 修改后通读受影响章节检查标题归属、顺序、交叉引用和重复内容。 6. 检查差异、格式、编码和暂存范围说明更新原因与影响。 不应自动写入单次命令失败、未经验证的推测、临时环境状态、会话记录以及被上位规则覆盖的重复要求。 ## 六、触发“规则系统复查”的信号 出现以下现象时优先审查规则体系而不是再追加一条规则 - AI 反复遗漏已写入的要求。 - AI 为了遵守规则产生无关修改或过度设计。 - 同一任务中不同规则给出相反方向。 - 人无法判断哪条规则优先或无法解释其适用范围。 - 规则越来越长却没有提升交付效率或准确性。 ## 七、维护者的最小审查清单 - 这条规则是否真的需要长期存在 - 它是否有可核验的事实依据 - 它与旧规则是否冲突 - 它会不会把特殊情形扩大成所有任务的负担 - 它的触发条件、动作、例外和验证是否足够明确 - 它应属于共同规则还是项目专项 - 能否修订旧规则来表达而不是新增一条