上一篇不会还有人把 AI 落地当成零散技巧吧没有主线越学越乱 | 规则到测试闭环预览不会还有人把「尽量注意」当成 Rule 吧不可判定等于没写 | 硬约束与加载顺序系列《从 Rule 到落地AI 工程化实践》第 4 篇标签Rule · 硬约束 · AI工程化 · 质量门禁专栏从小白到AI落地大师序言上文我们画了五站主线。童鞋们若痛点是「助手好心乱改」第一站就是 Rule。别急着写长篇制度散文——先问一句更狠的你写的那条机器能不能判定违规说句扎心的很多团队所谓 Rule其实是气氛组发言。「注意安全」「别乱改」「最好先测一下」——听着都对助手没法遵守。你可以理解为门口贴着「请文明通行」小偷照样进——因为那不是门禁是标语。标语越多大家越以为安全工作做完了其实只是墙纸换厚了。本篇钉三件事必须、禁止、建议三语气怎么分硬约束到底写哪些内容加载顺序如何裁决冲突。alwaysApply 路由细节留给下篇完整业务包实战留给第 6 篇。读完你要能起草一份最小可行 Rule 目录分得清硬约束与建议并知道冲突时谁覆盖谁。别追求一次写全宇宙——先写十个真能判的比写一百个「请尽量」强一百倍。概念开篇几个词融入叙述不做卡片农场。Rule就是可判定的必须与禁止建议另册别和门禁混装。硬约束是违反即可拦截或明确提示的条目——「我觉得不太好」不算。加载顺序是全局到仓库再到场景的冲突裁决机制不是文件名好看排序。门禁是不满足条件就不允许继续的检查点过不了就该停而不是「先改完再说」。换个接地气说法Rule 是宪法不是操作手册。手册是 Skill 的事。宪法要能一锤定音判合不合规「尽量注意」连庭外调解都算不上。简单来说就是——写不清判定条件的别进硬约束文件。进了也是噪声还会在 Context 吃紧时挤掉真红线。三种语气务必分清。必须例如改公共 API 前先补契约测试。禁止例如不在日志和提交中写密钥明文。建议例如提交信息写清动机——建议另册不进常驻硬约束。把建议和禁止混在一段里助手分不清权重你可以理解为消防通道指示灯旁边贴满「欢迎光临」真正要命的那条反而看不见。问题在哪写不好 Rule通常栽在四处。细心的朋友对照一下别对号入座太疼。第一处不可判定。「不要乱改」无效「未经确认不修改 infra 目录与密钥相关文件」有效。前者是心情后者是坐标。助手不是故意作恶是你没给可执行的红线。你越用形容词它越只能猜。第二处语气混装。命名建议、提交风格、真正的生产禁止项糊成一锅。会话一长模型对约束的遵守会被噪声拉低——不是玄学是注意力被稀释。安全条款若和「变量名尽量语义化」同级出事时你也说不清到底哪条该挡。第三处加载顺序靠默契。全局禁止强制推送某发布流程又需要例外。若不写明场景包覆盖全局时必须显式声明并加双人确认冲突时要么全堵死要么全放开。全放开更隐蔽看起来流程很顺门禁早被悄悄拆了。第四处把 SOP 塞进 Rule。步骤越长越像 Skill 误投。Rule 应该短、可检索、带版本与变更说明。你打开文件要能十秒找到禁止项标题而不是在散文里考古。散文适合博客不适合门禁。举例虚构规则包 acme-rules最小目录可以长这样——不求一次写全求可演练acme-rules/ 00-load-order.md 10-security-hard.md 20-engineering-gates.md 90-suggestions.md硬约束条目示例注意每句都能判违规## 禁止 - 不在日志/提交中写入密钥与令牌明文 - 不删除未跟踪的本地用户文件除非用户点名路径 - 未经确认不修改 /infra 与密钥相关文件 ## 必须 - 改公共 API 前先补充/更新契约测试 - 涉及映射变更时变更说明写清影响面与风险等级加载顺序写成瀑布全局再到仓库再到场景。后者覆盖前者时必须显式声明。举例全局禁止强制推送某发布技能临时允许但要双人确认并留下审计字段。没有「显式」二字就是偷偷拆门禁——出了事还对不上责任链。硬约束内容从哪三类下手安全密钥、生产变更、不可逆操作。工程格式、测试门禁、评审要求。协作哪些目录默认只读、哪些入口禁止「顺便重构」。三类各先写两三条比空喊「全面规范」管用。验收怎么证明 Rule 生效别靠感觉也别靠「已经写进仓库」。用一次故意违规演练。让助手尝试把令牌写成明文放进示例配置——期望拦截或明确要求改占位符。让助手无测试改公共入口——期望提示先补契约测试而不是「顺便重构」。演练不过Rule 就还是气氛。说句自嘲的我第一次演练时助手笑嘻嘻把密钥写进去了我还以为模型坏了——其实是条款里全是「请注意」没有一条「禁止」。后来改成人话拦截才出现。不是模型突然听话是我们终于把标语换成了门禁。自检动手前勾这张表。勾不上就先别扩散到业务细节细节会诱惑你写成小说。# Rule 最小自检 - [ ] 每条硬约束能否用「违规/不违规」判定 - [ ] 建议类是否已拆到单独文件没有混进门禁 - [ ] 加载顺序是否写明全局→仓库→场景 - [ ] 是否做过至少一次故意违规演练 - [ ] 文件是否短、标题可检索、带版本或变更说明 - [ ] 安全、工程、协作三类是否至少各有一条硬约束更狠两问。第一把「尽量」「最好」「注意」从硬约束文件里搜出来——还在吗在的话先搬家或改写成可判定句。第二同事能根据加载顺序解释「为什么这次允许强制推送」吗不能解释就是默契不是机制。默契换人就失效机制才能进版本库。再把「可判定」练成肌肉反应。写完一条反过来做三步自虐第一找一个明显违规的最小动作看条款能不能直接判定第二找一个擦边动作看要不要补条件第三找一个完全无关的动作确认不会被误杀。三条都过才配进硬约束文件。写制度不怕少怕假——假制度会培养「反正也就说说」的团队文化比没有制度更难救。协作场景里还有一类高频坑目录默契。大家都知道「公共适配入口别乱动」却从没写成禁止项。助手一旦听到「顺便整理一下」就会扩大改动面。把默契晋升成坐标例如「禁止修改 adaptor/public 入口除非本会话用户点名路径并确认」事故半径会立刻缩小。坐标可以版本化默契换人就蒸发。有人担心 Rule 写太死会绑住手脚。其实恰恰相反把真正不能碰的钉死建议类放软册子场景例外走显式覆盖日常改动才会更敢做——因为红线清晰不再靠胆量和事后道歉。胆小和莽撞往往都来自红线模糊。最后补一句给「怕写太死」的朋友硬约束钉的是事故半径不是创造力。把不能碰的钉死反而让日常改动更敢做——因为你知道红线在哪不必靠事后道歉和群里解释。模糊才制造胆小和莽撞。把这句话贴到规则包首页也行红线清晰手脚才自由。团队文化也会跟着从「先改了再说」变成「先问能不能做」。写 Rule 时有个小习惯值得养成每条禁止项旁边挂一条「违规样例路径」。比如「禁止删红样假绿」旁边写tests/cases/*red*.yaml 不得在 PR 中删除或 skip。可判定不只是形容词是审 PR 时眼睛能盯住的锚点。acme 小团队后来把「建议项」全部挪出 hard-constraintsContext 立刻清爽——原来撑爆钱包的多半是语气软弱的正确废话。思考小结三句。Rule 只承载可判定的必须与禁止建议另册。加载顺序是冲突裁决机制必须写明。用故意违规演练验收而不是「我觉得写了就生效」。可以理解为先把宪法写短、写硬、写能判再谈怎么常驻、怎么按场景加载。下篇专门拆 alwaysApply 和场景路由——规则太多撑爆上下文时该扔什么、该留什么可不是「全都留下最安全」。全都留下往往等于关键条款最先被挤走。本篇不讲完整业务 Rule 包也不讲意图关键词怎么配。你现在只要带走一个习惯落笔前先问「能不能判定」。问完气氛组发言会少一大半门禁才有机会变成真的。下篇预告《alwaysApply vs 场景路由何时常驻、何时按意图加载》——常驻内核只留「永远不能错」的那撮。觉得有用的话欢迎点赞、留言甩一条你写过最「正确但无效」的 Rule咱们一起改成可判定版本。有故意违规演练翻车的故事也欢迎对照本篇拆。专栏从小白到AI落地大师《从 Rule 到落地AI 工程化实践》