昨天花了大半天读鸭哥的墨记项目。一块挂在墙上的彩色电子纸，每两小时把你最近在干什么画成一幅画。代码不多，但读完的感受是——干净。不是"写得工整"那种干净，是架构上的干净。
我在群里分享了读后感之后，又顺着这个思路看了不少东西。现在坐下来把一些判断理清楚。
画一条线
墨记最根本的架构决策只有一句话：采集层是代码，判断层是 AI，中间只过一个纯文本文件。
采集层做的事很确定：读微信数据库、读 AI session 导出、调邮件命令行。两小时的时间窗硬过滤，不需要理解，不需要判断。
判断层做的事只有 AI 能做：从一堆原始素材里挑一个最有张力的瞬间，写一段画面描述，生成一幅画。
两层之间不知道对方在用什么模型、从哪来数据。每层在自己的边界内做到最好，互不侵入。
这个分层说出来很简单，但真正做的时候你会发现，大部分人的第一反应会是两个方向：要么把采集也丢给 agent 做（反正 AI 什么都能干），要么连判断也写成代码模板（反正规则写全了也行）。
鸭哥的 rfc.md 里把这两种被否决的方案都写清楚了：全 agent 方案的问题不是"做不了"，而是采集是确定性的，交给 agent 平添不确定性且贵。全 code 方案的问题也不是"写不出来"，而是硬编码理解不了"什么瞬间值得画"。
把确定性留给代码，把判断留给 AI。这不是一个设计偏好，而是一个成本和可靠性的权衡。
我读完之后的感受是：这条线的画法，几乎决定了一个 AI 项目能走多远。线画在什么地方，哪些归代码、哪些归 AI，每个决策背后都是一次"工程确定性"和"AI 不确定性"之间的取舍。
天天都说编排，到底在编排什么
在传统开发里，编排就是胶水代码——你知道数据从哪来、过哪几个模块、落到哪去，写死就行。但在 AI 项目里，编排层第一次变成了核心层。因为它编排的不是几个函数调用，也不是几个 agent 的先后顺序，而是"确定性"和"不确定性"之间的边界。
墨记里有几个决策特别典型。第一个是：什么时候用单次 API call，什么时候升级为 agent。默认走单次调用——确定性最高、最快、最便宜。只有需要动态补料的时候才把 agent 拉进来。这不是技术选型，是风险控制。
第二个是：哪些 skill 只通过命令行调用（绝不 import 别人源码），哪个 skill 需要内化进本项目。邮件的解析逻辑在别人仓库里，墨记只调它的 CLI。图像生成被内化了，因为用途高度特化——固定 3:4 竖版 + E6 六色 + 特定 prompt 范式，需要独立演化。这里没有对错，只有取舍。
第三个是：每个环节失败之后怎么降级。信息不足就采全天素材画"今日拼贴"，生成被 moderation 拦了就换措辞重试，最终兜底保留上一幅。不是"期待 AI 不要出错"，而是"假设 AI 一定会出错，然后设计兜底路径"。
这些决策不是一次性拍板的。它们在项目的每个环节反复出现。编排层真正的功夫，就是在这些岔路口持续做出正确的选择。
测试驱动，并不只是为了开发时一把梭
这是最反直觉的一点。
很多人觉得 AI 项目里 AI 帮你写代码了，测试可以少写一点。但墨记的 tests/ 目录里有 12 个文件、1100 多行测试代码，覆盖了 config、collector、synthesize、各个数据源、pipeline，CI 在每次 push 和 PR 时自动跑 pytest。
一个单人开源项目放了这么重的测试，在 AI 圈很少见。
我一开始的理解也很传统：测试重，是为了开发时防止 AI 一把梭写崩，至少能抓住一些 bug。后来我跟鸭哥沟通，他补了一句话，我才突然反应过来。他的原话大概是：test 重，它的主要目标都不是说抓住 bug，而是帮 AI 能够自主迭代。
这句话很关键。传统测试更多是在开发期兜底：这次改动有没有把旧功能弄坏。但 AI 项目不是一次开发完就结束。它会在使用中不断加数据源、换模型、调 prompt、改降级链路。每一次迭代，AI 都可能重新进入项目，继续改代码、改文档、改行为。如果没有测试，AI 不知道什么地方不能碰，也不知道自己这次"优化"有没有把系统原来的能力打掉。
所以这里的 test 不是开发前的一把梭保护，也不只是抓 bug。它更像给 AI 留下的可执行规格。下一个 AI session 进来，不只读 README 和 AGENTS.md，还能通过测试知道：哪些行为必须保持，哪些边界不能越过，哪些退化会被立刻抓出来。
这也是为什么测试在 AI 项目里反而更重要。因为你不是只在保护今天这版代码，你是在给后面每一次 AI 自主迭代铺轨道。没有这条轨道，所谓自主迭代只是持续漂移。
从流水线到组织
写到这里，我突然意识到一件事。编排不是传统意义的编排，测试不是传统意义的测试——这两个判断背后，其实指向同一个更根本的变化。
传统软件开发是一套生产流水线。需求确定，设计固定，开发完成，测试通过，上线运行。每个环节可预测，输入输出明确。你是在造一个东西，然后让它稳定地跑。
但 AI 能力加入之后，这套逻辑变了。一个 AI 项目从上线那一刻起，不是进入了"维护期"，而是进入了一段持续的演化。数据源会变，模型会换，prompt 会演化，降级链路会被新的边界场景触发。每一次改动，AI 都可能重新进入代码。而且这些改动不是一次性的，是持续发生的，就像一个人在工作中不断学习、调整、改进。
这更像什么？这不像流水线。这像一个组织的运作。
一个组织不会只靠一套固定的工序运转。它会在稳定的基础设施之上，允许局部的动态扩展——今天加一个采集源，明天调一下判断逻辑，后天换一个输出形态。它也会追求自我学习和迭代——这一次出错的教训变成下一次的规则，这一次的经验变成下一个 AI session 的上下文。
再看墨记就会发现，它的设计不是"把一件事做对"，而是"让一个系统能持续变对"。采集层的确定性代码是组织的骨干——不可变、可审计。编排层的决策规则是组织的流程——明确，但可以演进。测试是组织的制度——不是管人的，是管每次变化的边界。AI 判断层像组织里的专业人士——负责需要理解和判断的事，但行为被骨干、流程和制度框在一个安全的范围里。
编排不是传统的编排，因为编排的不再是工序，而是确定性、不确定性和自我迭代之间的关系。测试不是传统的测试，因为测试的不再是一次交付的质量，而是这个组织每一次演化时，安全边界有没有被打破。
AI 项目的架构设计，真正的命题不是"AI 应该做什么"，而是"一个有智能参与的系统，怎样可持续地运转下去"。