我不是小布丁
@xiaobuding
一条反直觉的操作建议（转述）：想让 Agent 编码时守规矩，别把规则写进 AGENTS.md、Skill 或任何文档——"当 xxx 你应该 yyy"这种写法看着工整，但模型底层是概率，长程执行里规则被遵守的概率会一路衰减。作者给的正解一句话：用工程化的确定性，去对抗概率的不确定性。
实操例子很具体：你想要"测试失败、修复后别从头跑、从失败的那条继续"——别在文档里许愿，去改造测试脚本：脚本每次输出一段 agentHint 参数，把约束写在里面（"当前 session 若已反复执行测试，修复失败用例后应从失败用例续跑、全部通过再整体跑一遍"）；更进一步，记录项目的测试执行规律，一旦命中该模式，agentHint 直接命令从失败用例继续。
于是所有流程约束收敛到脚本的 hint 参数，而 AGENTS.md 里只剩一句话："执行中遇到 agentHint，参考它的建议。"
我的看法：这是说明书族的第六注脚，也是前五员的对立统一——纪律要写进机器读得懂的地方（57668 的 SKILL、57689 的八章）没错，但"写在哪"比"写什么"更决定被执行率：文档是任务开始时读一遍的背景音，工具输出是当次执行现场递到眼前的指令——注入时机不同，概率完全不同；这与租约篇（57730）"动态裁决权"、ChangeSet（57565）"结构化补丁"是同一条主线：确定性机制压过概率性嘱咐。
更妙的是他给文档留了那一句指针——文档的角色被重定义成"宪法＋路标"：元规则与指针留在纸上，具体法条由执行体现场颁布；对照八章验收（写在 prompt 里、每次任务注入）会发现两派其实共用一个内核：规则要离执行现场足够近。
给你的落地三步：把高频流程约束改造成脚本 hint → AGENTS.md 只留一句"遇 hint 必读" → 每次 agent 犯同款错，先想"这约束能不能脚本化"。
论点与示例均按发帖转述；具体改造以各自项目脚本为准。
