你的 AI 编程设置是一个繁琐的工具。你的代码库是复杂的。
新型的 AI 编程工具承诺让 Agent 更加可靠。你会看到各种关于技能、超能力和规范驱动开发（spec-driven development）的框架。这些工具确实有效。它们帮助 Agent 遵循流程，而不是靠猜测。
但其中存在一个陷阱。人们认为为单一任务建立更好的设置就能创建一个连贯的系统。事实并非如此。
要理解其中的原因，可以使用 Cynefin 框架。它将问题分为两类：繁琐（Complicated）和复杂（Complex）。
繁琐问题 (Complicated Problems) 这类问题有可知的答案。你可以通过分析和技能来找到它。例子包括重构模块或编写验证函数。一旦找到了答案，你就可以重复执行。大多数 AI 编程工具都处于这个层面。它们专注于工作单元，使任务变得可重复且可验证。
复杂问题 (Complex Problems) 这类问题没有可预测的答案。系统是由各个部分交织而成的网络。结果只有在你采取行动后才会显现。四十次合并后的更改会在六个月后破坏架构吗？Agent A 会与 Agent B 产生冲突吗？你无法通过查看单个文件来找到这些答案。它们是从各部分的交互中涌现出来的。
当你期望用“繁琐”型工具来解决“复杂”问题时，错配就发生了。
一个工具可能会让 Agent 写出一个完美的函数。但如果一个任务使用 userId 而另一个任务使用 user_id，系统就会崩溃。这两个任务在孤立状态下都是“正确”的。这种失败是涌现性的（emergent）。它存在于交互之中，而非单一单元之中。
即使是巨大的上下文窗口也无法解决这个问题。更大的窗口能帮你看到更多内容，但“看到”并不等同于“推导”。你可以阅读整个代码库，却仍然无法预知它在生产负载下是否会发生死锁。那是一个运行时属性（runtime property）。
如何应对两者：
- 对于繁琐层：使用技能、规范（specs）和 TDD。这些可以使 Agent 的单个输出更加严谨。
- 对于复杂层：使用“探测-感知-响应”（probe-sense-respond）模式。你无法预测什么会出错。你必须进行合并、部署并观察。利用集成测试和可观测性（observability）来感知各部分组合时会发生什么。
不要被“更好的规范会让系统更稳定”这种承诺所误导。规范让单元变得可靠，但它们并不能让系统变得连贯。
根据领域匹配你的方法。使用工具来完善单元。使用实验来理解系统。
Optional learning community: https://t.me/GyaanSetuAi