---
title: "plan 和 sdd 的场景"
date: "2026-03"
category: "ai运用"
tags: ["ai运用"]
description: "plan 和 sdd 适合的场景是： 你知道该做什么 或者你相信 AI 会做什么 用akr的话来说的话，就是这种提前决定好情况和流程的ai使用，最适合情况已知而且非常成熟的情况下来做..."
source: "https://enriquemark.com/zh-hans/posts/plan%20%E5%92%8C%20sdd%20%E7%9A%84%E5%9C%BA%E6%99%AF"
---

plan 和 sdd 适合的场景是：

1. 你知道该做什么
2. 或者你相信 AI 会做什么

用akr的话来说的话，就是这种提前决定好情况和流程的ai使用，最适合情况已知而且非常成熟的情况下来做。但如果遇到的问题未知，或者是项目中期，各种问题出现的时候，我不知道，ai也没办法搞好。更不用说项目变大后，流程可能就不可预期了。
虽然我想过用agent团队的形式去实现，但这仍然会面临一个上下文污染、中断的问题，因此找个ai当项目经理盯着恐怕不是好办法。因此，从这个角度来看，定义明确的测试导向型开发就是比较好的解决方案——当然，是目前的暂定方案。
这里的核心关键点是定义清晰的边界和形式化的验证——测试程序本质上就是一个形式化的系统，因此他的输入和输出都是绝对明确的，因此边界就在这里被定义下来了。
akr的说法确实没错，反馈循环很重要，重点是这样的反馈从哪里来？测试当然就是一个。
但测试导向并非完美的，ai有可能会出线先射箭再画靶子的问题。他会绕着程序去写测试，最终导致测试结果就是量身定做的——这显然不是我们想要的良好测试样例。
恐怕如何写测试需要人类来指定一个原则，我倒是想到A家的宪法ai了，人类多少还是要给个边界限制——却并非完全的僵死的限制。他就像法官解释法律一样，ai可以按照自己的理解来灵活的解释，但边界范围却是明确的。

sdd：规范驱动开发（Specification-Driven Development, SDD）