资源压力是主因。
证伪条件:低负载下故障依旧。精选的公开工作
一间陈列室,
陈列系统、证明与判断。
取自软件、运行与研究工作的精选之物。足够看清结构。但不是背后的引擎。
01 / 工具
ACE Receipts · 闸门
产出廉价。信任不然。
一个公开的命令行工具与 GitHub Action,扫描由 AI 协助的工作流与其变更,检查证明、风险、许可与缺失的证据。下面的样本沿用同一套裁决语法,却不会碰你的仓库。
样本
还不行。拿回执来。
- 证明
- 部分
- 风险
- 高
- 许可
- 人工复核
ACE Receipt: HOLD
Not yet. Bring receipts.
- Verdict
- hold
- Gate
- fail
- Proof
- partial
- Risk
- medium
- Permission
- human_review_required
- Closeout
- pending
Command ace-receipts demo
Missing receipts
- explicit permissions block
- SHA pin receipt for third party actions
- receipt policy (.ace/policy.yml) or an ace-receipts gate in the workflow
No receipt, no passage.
03 / 产品
Sendable? · 最后一次裁决。
消息本身有用,但内部估算不该离开团队情境。
发送前先删掉那个内部数字。04 / 观察界面
Asso Lab · 由代码签署的回执。
{
"receipt_id": "393911c3-2c62-4de0-8ae1-cbdb40804b88",
"date_utc": "2026-06-17T10:41:51.567112Z",
"sources": [
"https://simonwillison.net/atom/everything/",
"https://arxiv.org/rss/cs.MA",
"https://arxiv.org/rss/cs.CR",
"https://arxiv.org/rss/cs.AI",
"https://www.anthropic.com/news"
],
"model": "gemini-2.5-flash",
"content_hash": "5e73ba03104d66e99518bbc904ccdbfc571ff01178ce0df6bf62fbca766efc01",
"operator": "hichem",
"confidence": null,
"status": "PUBLISHED"
}
confidence 为空,因为没有任何东西测量过它:空着的字段比编造的数字更诚实。公开任务。公开回执。让边界始终可见。
Asso Lab 是一个公开的观察界面:有界的任务书、由代码生成的回执、哈希、时间戳,以及允许、拒绝与需人工复核三类动作的实例。
这不能证明什么
一份已发布的回执,只证明某件物证在那一刻确实是这个样子。它不证明私有运行环境,不证明生产安全,也不证明任何行动权限。
05 / 运行
AI Ops SOP Pack · 恢复,但不假装。
当情境丢失时(一次崩溃、一次被打断的评审、一场在决策中途结束的会话),最诱人的做法是凭记忆把信心补回来。这份工具包用重新读过的证据,以及一道加在受审对象上的护栏,取代那种做法。
- 01情境丢失
- 02冷读证据
- 03头部护栏
- 04交接
- 05人工闸口
Completing this checklist records review evidence only. It does not approve or perform a merge, and it does not grant merge authority by itself.
Head Guard
- observed PR head commit:
- expected PR head commit:
- match confirmed:
- merge command or action will preserve head guard:
Stop if the PR head changed and the new head has not been reviewed.
Boundary Review
- no live runtime opened:
- no provider call introduced:
- no secrets introduced:
- no daemon / watcher / background process introduced:
- no memory write introduced:
- no ledger write introduced:
- no permission-to-act introduced:
- no trading / order routing / leverage / portfolio authority introduced:
Decision
Choose exactly one:
- PASS
- REPAIR_REQUIRED
- STOP_RISK
06 / 治理
两份回执。一处不同。
只有当拒绝留下与行动同样的痕迹时,拒绝才值得信任。这两个已发布的示例共用同一道边界、同一个代理、同一个目标文件。一个读它。另一个试图写它。
{
"schema": "ace.action_receipt.v0",
"status": "allowed",
"decision": "allowed_read_only",
"requested_action": {
"type": "file_read",
"purpose": "summarize support context"
},
"boundary": {
"mode": "read_only",
"writes_allowed": false
},
"refusals": [],
"human_review_required": false
}
{
"schema": "ace.action_receipt.v0",
"status": "refused",
"decision": "refused_forbidden_write",
"requested_action": {
"type": "file_write",
"purpose": "update customer record"
},
"boundary": {
"mode": "read_only",
"writes_allowed": false
},
"refusals": [
{
"reason": "write_not_allowed_inside_read_only_boundary",
"required_next_step": "human_review_or_new_explicit_boundary"
}
],
"human_review_required": true
}
两个文件都在证据块中带着这条注记Static public example. Not runtime proof.。每一版都注明自己略去了什么;所展示的内容未经改动。
07 / 推理
Hypothesis Fan · 让证据来拿掉。
样本
一个观察。三种解释。每次一件证据。
备选一直摆在明处,直到某次检验给出拿掉其中之一的理由。这磨快的正是贝特森的问题:把这些故障连起来的模式是什么?
交接引入了不一致的状态。
证伪条件:没有交接时也会出故障。状态是从不完整的情境里重建出来的。
证伪条件:把状态写明也没有减少复发。08 / 系统
SYSTASYS · 连续,而非奇观。
记忆只有改变了下一次观察,才算有用。
那根金色的弦是回路。其余不过是寻常的因果顺序;正是这次返回,让它成为系统而不是清单。
跑一圈依次经过,或直接在图上读。
09 / 工作法则
一份由约束写成的宣言。
工作法则
01让不止一种解释活着。
过早的确定代价很高。让证据来淘汰。
握住 → 检验 → 拿掉。02由现实决定。
模型只在它经得起与实际发生之事的碰撞时才有用。
模型 ≠ 现场。03没有记忆的观察是浪费。
系统应当记住足够多,好让下一次观察更好。
痕迹 → 记忆 → 被改变的观察。04证据应当改变下一个动作。
什么也改变不了的回执,是文档,不是控制。
证明必须有后果。05权限应当保持可见而乏味。
权力可以住在核心周围。但许可边界应当简单到可以逐条查看。
权力在外。清晰在内。06连续性比奇观更要紧。
有用的系统,是演示结束之后仍然讲得通的那一个。
效果散去之后,还剩下什么?