从让 AI 写代码到让 AI 按规则工作：嵌入式工程师的实践思考

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 为了遵守规则产生无关修改或过度设计。 - 同一任务中不同规则给出相反方向。 - 人无法判断哪条规则优先，或无法解释其适用范围。 - 规则越来越长，却没有提升交付效率或准确性。 ## 七、维护者的最小审查清单 - 这条规则是否真的需要长期存在？ - 它是否有可核验的事实依据？ - 它与旧规则是否冲突？ - 它会不会把特殊情形扩大成所有任务的负担？ - 它的触发条件、动作、例外和验证是否足够明确？ - 它应属于共同规则还是项目专项？ - 能否修订旧规则来表达，而不是新增一条？