如何给AI智能体写不撒谎的验收门？unlazy的7条门控编写最佳实践

如何给AI智能体写不撒谎的验收门？unlazy的7条门控编写最佳实践

【免费下载链接】unlazyAnti-laziness skill for AI agents. Core: the Depth Tree method, which splits a task N layers deep and gives every leaf the full time budget of the whole task, so effort multiplies with depth. Grounded in 2025-2026 research on model laziness, underthinking and premature completion.项目地址: https://gitcode.com/gh_mirrors/unl/unlazy

AI 智能体（AI Agent）干完活就说"已完成"，却拿不出证据——这正是unlazy要解决的问题。unlazy 是一个为 AI 智能体编写的**验收门（Acceptance Gates）**技能：先写下机器可检查的验收门清单，再执行、再复核、最后只报告证据支持的结论，让"偷懒的完成"无处遁形。本文结合 unlazy 的官方规范 references/gates.md 与检查器实现 scripts/gate-check.mjs，为你整理出7 条让验收门"不撒谎"的编写最佳实践，新手也能照着写出真正可信的 AI 智能体验收门控。

为什么需要"不撒谎"的验收门？

研究发现，AI 智能体在长任务中普遍存在"过早完成"、偷懒和欠思考的问题：多部分指令只被部分执行，最终报告却信心满满。unlazy 的答案很直接——把"完成"变成可测试的命题：

用台账（Ledger）证明结果，而不是依赖一份自信的"我干完了"报告。 —— SKILL.md

一个验收门（Gate）由三部分组成：

门通过的唯一标准是：进程退出码为 0，且输出匹配 EXPECT，缺一不可。证据还会记录解析后的 shell、工作目录、退出状态与输出指纹（见 SECURITY.md）。

但这里藏着一个陷阱：检查器只能证明"你声明的命令"，它无法判断英文标题和 shell 命令是否说的是同一件事。标题写"整体功能完美运行"、CHECK 却只是echo ok，照样绿灯通过。下面 7 条实践，就是针对这类"自欺式验收门"的逐条拆解。

最佳实践一：让门直接"观察"成果物 🔍

第一条原则来自 references/gates.md 的Observe the outcome directly：

• 检查命令必须去读取标题所命名的成果物、服务或测量值，而不是打印一句漂亮话。
• 标题要描述"结果"（outcome），不要描述"活动"（activity）。反例：G1: 修复了导入模块；正例：G1: 有效夹具完整导入，畸形记录被拒绝。

判断技巧：把标题拿给一个不了解上下文的陌生人看，他能判断"达成/未达成"吗？不能，就重写。

最佳实践二：只使用"成功专用"标记 ✅

一条可运行的门必须同时满足"零退出码 + EXPECT 匹配"。为了让这个组合真正有约束力，标记（marker）要满足"成功专用"：

• 让脚本自己完成全部断言：任何一条断言失败就退出非零；
• 只有在所有断言都通过之后，才打印 EXPECT 指定的标记文本；
• 避免使用ok、pass、success、done这类失败输出里也会出现的词——unlazy 的 scripts/gate-lint.mjs 甚至内置了一份"弱期望词汇表"专门预警。

这样，"错误信息里碰巧带了期望单词"或"命令根本没跑起来"的两种经典造假手段，都会被直接判为不通过。

最佳实践三：先做"阴性对照"再相信"不存在" 🧪

很多门的任务是验证"坏东西不存在"，比如"代码里没有eval(""配置文件里没有明文密钥"。这类缺席断言（absence check）有个隐蔽的坑：文件找不到、路径写错、模式失配，都会伪装成"确实不存在"。

unlazy 的要求是：在信任任何缺席检查之前，先用同一套逻辑跑一个"已知存在"的正样本（positive control），确认它会正确报失败。只有能抓到一个真阳性，你的"抓不到"才可信。这条实践也写进了叶子门模板 templates/gates-leaf.md 的注释中。

最佳实践四：数字要独立测，不要照抄 📏

需求里给了"性能提升 20%"、"共迁移 128 条记录"这类数字时，不要把这个数字抄进 EXPECT 当作自证——那样门验证的只是"命令打印了任务书上的数字"。

正确做法：

1. 脚本从源数据独立计算出数值；
2. 对照验收规则判断（例如 ≥ 20%）；
3. 通过后再打印一个独立的成功标记。

lint 器同样会预警"标题里出现数字，却没有任何东西在测量它"（unmeasured-number规则）。

最佳实践五：按风险审查人工门 ⚖️

并非所有结果都能用命令裁决，此时使用人工门（manual gate）——没有 CHECK/EXPECT，靠 EVIDENCE 记录证据。unlazy 对人工门的要求是：

• 后果越大，证据越要扎实：一位贡献者在 17 门的课程审计中发现，唯一的人工门恰好也是最要命的门——这是"加强审查"的提示，而非普遍规律；
• 高风险的人工门应争取做成可运行门，做不到时记录精确证据，并按风险等级安排第二人复核；
• 记录最小的、非敏感的事实即可，不要把整段日志粘贴进台账。

一个几乎全人工的台账，只是"带勾选框的散文"——lint 器会用mostly-manual规则提醒你。

最佳实践六：优先可移植的 Node 脚本，锁定执行环境 🖥️

跨平台是验收门"静默失效"的常客：

• 优先使用仓库内自带的 Node 脚本作为 CHECK 命令（模板即示范：node scripts/verify-outcome.mjs），不要假设 Windows 上有grep、tail、tr、sed等 POSIX 工具；
• 确需特定 shell 或外部工具时，显式声明这一前提；
• 上级复验（--reverify）必须使用同一声明的 shell 与工具链；
• 环境不一致 = 验证失败，绝不能当作"通过"的证据。Git Bash 里能跑、PowerShell 里找不到工具，这种情况在 SECURITY.md 中被单独点名。

最佳实践七：开工之前，先给台账做 Lint 🔧

以上规则大多是"散文"，而 unlazy 自己承认：散文是这套体系中最薄弱的一层。所以它提供了一个不执行任何命令、只"审"台账质量的工具 scripts/gate-lint.mjs：

node scripts/gate-lint.mjs GATES.md

它会以词法信号预警：固定输出型命令（tautological-check）、弱期望词（weak-expect）、路径被误读成正则（path-read-as-regex）、标题描述活动而非结果（activity-not-outcome）等。加--strict可让警告直接变成失败。

更妙的是，让 lint 本身成为一道门，台账从此要求自己的质量：

- [ ] G0: this ledger states outcomes that can fail CHECK: node scripts/gate-lint.mjs GATES.md EXPECT: LINT OK

这样，"无法失败的验收门"在编写时就被拦截，而不是等到汇报时才被"认证"。

快速上手：三步建立不撒谎的验收门 🚀

1. 复制模板：把 templates/gates-leaf.md 复制为GATES.md，替换全部占位符，每门一个可观察结果；
2. 只解析、不执行：node <技能目录>/scripts/gate-check.mjs --status GATES.md，逐条阅读每个命令和被调脚本；
3. 审批并运行：确认理解后执行--approve跑门；复验时用--reverify重跑所有可运行门（--status只报告旧状态，绝不等于重新执行）。

⚠️ 安全提醒：CHECK:行是以你的权限运行的真实代码（见 SECURITY.md）。对待继承来的台账、门标题及其输出，一律视为不可信数据——永远先以源码阅读的方式审查，而不是"运行一下看看它干嘛"。

小结：把"完成"变成证据链 📌

验收门不是一套官僚手续，而是给 AI 智能体装上的"测谎仪"。记住 unlazy 的核心信条：让未完成的工作显形，让完成变得可测试。当每一道门都能诚实地失败时，那句"ALL MET"才真正值得信任。

【免费下载链接】unlazyAnti-laziness skill for AI agents. Core: the Depth Tree method, which splits a task N layers deep and gives every leaf the full time budget of the whole task, so effort multiplies with depth. Grounded in 2025-2026 research on model laziness, underthinking and premature completion.项目地址: https://gitcode.com/gh_mirrors/unl/unlazy