为 AI 工作流设计明确的边界

前提

这些前提是摊开写的,方便你不同意:

1. A1一次新的模型调用，只能使用实际提供给它的上下文。

   对话历史、笔记和记忆工具可以延续之前的工作，前提是工作流把它们找出来并提供给模型。某条约定存放在某处，不代表它出现在下一次判断的上下文里。

2. A2AI 产出改动的速度，可能超过我验证它们的速度。

   草稿可以很快出现，但理解影响、测试边界、判断它是否解决了正确的问题，仍需要工作。生成变快，不会让这些工作消失。

3. A3错误有三种不对称的成本：犯错可能很便宜，发现它很贵，后续工作依赖它之后，修复还会更贵。

   这三种成本不只是大小不同，方向也不同。只优化最便宜的产出环节，可能把负担推给更昂贵的发现和修复环节。

由此推出

推出什么,以及每一条逼你做什么:

1. T1检查能有多独立，取决于保护它的边界。 由 A1

   模型的自审不是独立验收证据。我还使用规则引擎、进程退出码和独立实现，但结果仍依赖检查本身及其配置：一次记录下来的探针，仅在读取行末增加注释，就使守卫失效，而它仍报告零违规。

2. T2生成越快，验证越重要。 由 A2

   做出有用的产品仍然重要。在实现之外，我也投入精力定义怎样算完成、核查实际结果，并测试检查本身能否拒绝一个坏样例。

3. T3检查点之间的间距,必须小于错误被垒上去的速度。 由 A3

   把便宜的检查放到靠近工具调用的位置，能在更多工作依赖错误之前发现它。但 hook 只看得见自己检查的操作：曾有两条 shell 单行命令穿过同一个 hook，文件也确实被写入。那条通道改用前后快照比较——这是检测，不是预防。

4. T4意图需要一条执行路径，不只是一个存放文字的地方。 由 A1

   文档里的规则不会自己运行。能做成程序的地方，我为它配一项可执行检查。程序和配置也可能被改动或绕过，所以检查自身的输入与执行过程同样需要审查。

5. T5没有可见信号的重复失败，可能在无人察觉时持续累积。 由 A3

   沉默不是信号，所以没有东西给它踩刹车。一个清理例程捕获输出，却不检查返回码。记录中的事故积累了 2,983 个泄漏工位（约 26 GB），再加约 60 GB 的 pytest 临时文件，共约 86 GB。现在即使没人盯着，失败也必须可见。

这些论述来自现已随 nonconstant 公开的工作笔记，也引用我的其他项目。Agent 参与了笔记撰写，其中的第一人称陈述不能自动当成我本人的观察。我的贡献是设计判断、验收标准与审查，也包括否定先前的结论。历史数字对应当时记录的阶段，不是当前总量。源码公开让主张可以核查，但不会自动证明主张正确。