我把 Claude 锁进了一个盒子，里面塞满了详细的规格说明和文档，然后和家人出去过了一个周末。
设置了一个持续运行的编排器，它监控新的提交并提供审查，这些审查会在开发编排器完成一个任务后，被丢进它的上下文里。它们在一个连续循环中工作，直到开发编排器连续 15 分钟没有新的提交。
我定期检查进度和结果；它还在跑，而且到目前为止进展出奇地好。尽管有多个工作流和高思考预算，Token 消耗也不算灾难性（在 20x 计划下，仍低于每周限额的 50%）。
我大概每个月都会做一次这样的测试，就是丢一个离谱的任务，看看极限在哪；在有限的时间里能造出什么。然后我会非正式地评估功能、对设计意图的遵循程度，以及质量。这些结果从不公开；有时它们跟我的爱好有关，但有时只是些“如果这样会怎样”的抛砖引玉式实验/想法，我们在 Tabular Editor 内部讨论——大概从二月份开始，它们就变成了长期运行或自主的任务。
直到去年十一月左右，这些测试的结果在所有方面都很粗糙，老实说，我对自己的工作流或方法也一直不太认真或自律。然后（在 Opus 4.5 之后），功能突然到位了，但质量完全不行。几个月来，它慢慢能做得越来越多、越来越远，但并没有做得更好。
不过，在过去的一两个月里，似乎有些东西变了。我在小规模实验中注意到输出质量明显提升，大概是从我花了很多精力真正把工作流锁死、清理干净开始……努力确保一致性、安全性和可扩展性。我不确定是不是这个原因，但这可能确实有帮助。只是我不知道影响有多大。
但这次测试似乎已经显示出巨大的进步，甚至可能比上次我尝试类似的大实验时质量更高。我仍然对这个“铁疙瘩”持怀疑态度，已经不得不干预了一次，以避免它陷入死胡同……但到目前为止，还是挺让人惊讶的。这让我又开始重新思考很多事情。
我不确定，但 Claude Code 中动态工作流的新功能似乎在合适的上下文中带来了巨大变化，尤其是当你用正确的方式调教技能（skills），以及为你的场景量身定制自定义工具时。不过，我现在还不知道，是不是仅仅因为我的设置变了才带来了这种差异。
在我试图入睡时，我总结出了一些东西：
- 锁定你的记忆，并好好维护它。不要害怕临时用相关信息填满它。永远不要让 AI 来策划它，给 AI 一个 Obsidian 仓库或 Agent 文档库。
- 你应该使用技能（skills）。
- 不要只为了技术流程和格式/框架制作技术技能。当你用概念性和非技术性的流程上下文来补充它们时，技能效果最好。路由技能看起来也很棒，但我还不确定。
- 不要只是开箱即用地使用供应商提供的技能。找一个你喜欢的技能或模板，fork 它，然后拥有它。
- 不要用技能来替代工具，那很蠢。
- 你应该测试技能，但这真的很难，老实说，我还没想出什么评估方法，能让人觉得不是瞎扯淡。
- 不要用 AI 来制定计划或创建上下文。人类应该拥有它，AI 可以迭代、清理或完善它。
- /goal 非常棒，前提是你知道有一个你验证过的完整反馈循环。/loop 和 /schedule 感觉有点别扭。
- 我觉得动态工作流有些特别之处。但我现在还不确定。