副标题：我为什么要做 CDF 受控开发流
最近我一直在思考一个问题：AI 编程到底应该更自由，还是更受控？
一、AI 新鲜期
前一阵子，我开始在公司内部推广 Codex，就像我当初推广 Node.js 一样。
同事刚开始用的时候很兴奋，跟我说：
我今天一个小时就做了一个页面，三天就做了一个 App。
这确实是 AI 编程最迷人的地方------它极大压缩了"想到"和"做到"之间的距离。以前一个想法可能只是停留在脑子里，或者躺在需求文档里；现在只要把它说出来，AI 很快就能帮你生成页面、接口、样式，甚至补上很多你原本懒得做、来不及做的细节。原来写代码也可以这么快，原来从脑子里冒出一个想法到变成功能，中间的距离可以被压缩得这么短。
但看着这个过程，我也开始意识到另一个问题：当 AI 能快速创造新东西的时候，它是不是也能快速制造新风险？速度快当然是优点，可如果方向错了、理解错了、改动越界了，这种速度也会变成风险放大器。
二、AI 入门期
当一个人刚开始用 AI 写代码时，最容易沉迷于它的速度。页面可以让 AI 改，接口可以让 AI 写，样式可以让 AI 补，报错可以让 AI 查，甚至一个完整的小工具都可以在很短时间里搭出来。以前我们是徒手搬砖，现在 AI 像是突然给开发者配了一辆半挂，一车一车地帮你拉砖，这种感觉很容易让人上头。
但只要用得久一点，就会慢慢发现，AI 的问题并不是它不会写代码，而是它有时候太敢写代码------它会误解需求，会自作主张，会在你只想改一个小地方的时候，顺手重构一大片。
也正是在这个阶段，我遇到了一个新的难题：我们到底要不要给 AI 更多限制？
我和龙哥聊过这个问题。他的观点很直接："不要给 AI 太多限制，限制越多，AI 越发挥不出来它的潜力。"
这句话是有道理的。AI 确实有创造力------在产品创意、技术方案探索、UI 风格尝试、文案创作，很多时候都需要让它发散。如果你让 AI 写小说，却一开始就把所有情节都限制死，它很可能写不出惊喜；如果你让 AI 做产品创意，却只允许它在你已有的框架里微调，它也很难给出真正有价值的新方向。
所以，在创意阶段，AI 确实应该发散。但编程是不是不一样？
三、编程为什么不一样？
我们常把高级程序员叫做工程师。工程师不是单纯写几行代码的人，而是设计、建造并维护一个工程系统的人------可以是一栋楼、一座桥，也可以是一个网站、一个支付模块、一个数据后台。只要它是工程，就不能只追求"快"，还要关心稳定性、可维护性、影响范围、回滚成本，以及最后能不能安全交付。
代码不是写完就结束了。它会上线，会影响用户，会影响收入，会影响数据，会影响后续维护，也会影响团队里的其他人。所以，AI 在创意阶段可以像一个头脑风暴伙伴，但进入工程现场以后，它就不能再像创意阶段一样随意发挥。
AI 编程的问题，不是要不要限制 AI，而是要不要工程化地组织 AI。
四、AI 编程的真正风险：不是不会写，而是太敢写
现在的 AI 已经能写很多代码------生成页面、补接口、改样式、写 SQL、生成测试、帮你接 SDK，甚至根据一个模糊需求直接做出一个看起来能跑的版本。但这恰恰也是它危险的地方，因为它写得太快，也改得太快。
很多时候，我们以为自己只是让 AI 改一个小问题，结果它顺手做了很多额外的决定：
- 你只是想修一个小 bug，它顺手重构了半个模块。
- 你只是想改一个按钮文案，它顺手调整了整个组件结构。
- 你只是想补一个接口字段，它顺手改了公共类型定义。
- 你只是想优化一个页面，它顺手引入了新的依赖。
- 你还没确认数据库结构，它已经开始改 SQL 和 ORM 模型。
- 它没理解旧逻辑，就自信地删除了一段"看起来没用"的代码。
- 需求还没问清楚，它先实现了一版复杂方案。
这些问题最麻烦的地方在于，它们一开始看起来都不像问题。AI 生成的代码可能能跑，页面可能能打开，功能可能能演示。但真正进入项目以后，你会发现结构变乱了，隐藏 bug 变多了，影响范围变大了，Review 成本变高了------它表面上帮你省了 30 分钟，后面可能让你多花 3 个小时排雷。
AI 最大的危险，不是它不会写代码，而是它太敢替你做决定。
五、可控不是反 AI，而是工程化
一说到"限制 AI"，很多人本能地会觉得这是在压制创造力。但我觉得这个说法不准确------可控不是反 AI，可控是工程化。
人类工程师写代码，本来就不是完全自由发挥。一个成熟的软件团队，通常会有需求评审、技术方案、影响面评估、代码规范、Code Review、测试、灰度、回滚方案。这些东西看起来都在"限制"工程师，但它们真正限制的不是能力，而是风险。没有人会觉得 Code Review 是在压制程序员，没有人会觉得测试是对工程师的不信任，没有人会觉得线上发布前做灰度是因为团队不想提高效率。
既然人类工程师都需要这些流程，那为什么到了 AI 编程这里，我们反而希望它完全自由发挥？AI 比人写得更快、改得更快、生成得更多，难道不是更需要流程管控？
所以我理解的"受控"，不是把 AI 管死，而是给 AI 建立工程边界。它控制的不是创造力，而是误解风险、越权修改、无关改动、过度设计、隐藏副作用这些工程上真正危险的东西。
真正的问题不是"AI 应不应该自由"，而是：什么时候让它自由，什么时候必须让它停下来。
六、CDF：我的受控开发流
基于这个思路，我开始设计自己的 CDF------Controlled Development Flow，受控开发流。
它不是一个简单的 Prompt，而是一套让 AI 在工程场景里先理解、再拆解、再评估、再执行的工作流：
text
理解需求 → 拆解任务 → 评估风险 → 制定计划 → 执行与 Review理解需求，是为了防止 AI 没听懂就开干；拆解任务，是为了防止一次性大改；评估风险，是为了判断这个任务到底应该自由发挥还是收紧边界；制定计划，是为了让修改路径可预期；执行与 Review，是为了让人清楚地知道重点应该检查哪里。
CDF 最关键的地方，是根据风险动态调整 AI 的自由度，而不是对所有任务一刀切地严格限制。低风险任务------改文案、补样式、修一个局部小问题------可以快速执行。中风险任务------改一个页面流程、补一个接口、调整一段业务逻辑------需要先说明方案，列出影响范围，再执行。高风险任务------数据库结构调整、支付订阅逻辑、权限系统、批量重构、线上核心流程修改------必须先暂停，分析依赖和影响面，等待人工确认，并生成 Review List。
这就是我理解的 AI 工程化：不是把 AI 套上枷锁，而是给 AI 编程加一个智能刹车系统------哪里可以直接做，哪里要先想清楚，哪里必须停下来等人确认。
七、CDF 控制的不是创造力，而是风险
很多人听到"受控开发流"，会觉得这是不是让 AI 变笨了。其实不是------CDF 控制的不是 AI 的创造力，而是工程风险。
在创意阶段，我依然希望 AI 发散。产品方向、UI 灵感、技术方案探索、文案命名，这些地方 AI 应该大胆想，给出十个方案、提出不同路线、挑战我的惯性思维。但当任务进入工程落地阶段，情况就变了。线上 Bug 修复、数据库改动、支付订阅逻辑、权限安全模块、老项目重构，这些场景必须更受控，因为这里不是试错成本高，而是出错后果大。
AI 在不同阶段应该扮演不同角色：创意阶段像顾问和头脑风暴伙伴，方案阶段像架构师助理，开发阶段像高级执行者，Review 阶段像质检员，重构阶段更像一个能力很强但必须严格监管的施工队。
所以真正成熟的 AI 使用方式，不是永远发散，也不是永远受控，而是：让 AI 在该发散的时候发散，在该受控的时候受控。 CDF 要解决的，就是后半部分的问题。
八、限制 AI 会不会降低效率？
有人可能会问：给 AI 加这么多规则，会不会降低效率？
会降低一部分表面速度。受控流程会让 AI 不能马上开写，它需要先理解、拆解、评估、计划，看起来确实慢了一点。但真正的效率，不是 AI 一次生成多少代码，而是 AI 写出来的代码，有多少能安全合并。
如果 AI 写得很快，但每次都跑偏、每次都要返工、每次都要人工排雷，这种快只是表面快。不受控的 AI 很容易造成：代码能跑但结构变乱，功能做完但隐藏 bug 增加，一次改动太大导致 Review 成本暴涨，表面省了半小时后面多花三小时排雷。
这就像开车------油门当然重要，但速度越快，刹车和方向盘越重要。当 AI 只能补全一行代码的时候，风险有限；当 AI 可以改一个文件、一个模块、一整个项目的时候，就必须有边界、有流程、有 Review、有回滚意识。受控不是拖慢 AI，而是在减少 AI 造成的返工和事故。
九、AI 编程更像开挖掘机，不是阿拉丁神灯
我越来越觉得，AI 编程更像开挖掘机，而不是阿拉丁神灯。
神灯的逻辑是：我说一个愿望，它给我一个结果。但工程不是这样------工程里有地基，有结构，有承重，有管线，有安全规范，有后期维护。AI 出现以后，我们确实像突然拥有了更强的机器：以前开发像手搬砖，现在像突然有了一辆卡车、一台挖掘机，它能一次搬很多砖，也能很快挖出很大一块地。
但机器越强，越需要图纸。没有图纸的卡车，一次能运几千块砖，也可能一次撞塌整面墙；没有边界的挖掘机，效率越高，破坏力也越大。所以 AI 编程真正需要的，不是一句"帮我做完"，而是图纸、路线和刹车。
CDF 不是为了让 AI 少干活，而是为了让 AI 知道该往哪里干、干到什么程度、哪里必须停下来等人确认。
十、结尾：AI 不是不能发散，但工程必须有刹车
回到最开始那个同事的兴奋------他说一个小时做了一个页面，三天做了一个 App。这种兴奋是对的，它代表 AI 编程真正释放了创造力，让很多原本被时间、精力、技术细节卡住的想法，突然有了落地的可能。在创意阶段，AI 确实应该大胆发散，帮助我们想更多方向，试更多可能，突破更多惯性。
但在工程落地阶段，它必须受控。因为工程最终不是看你生成了多少代码，而是看这些代码能不能稳定运行，能不能安全合并，能不能长期维护，能不能真正交付价值。
创意可以发散，工程必须受控。
我做 CDF 的原因，也在于此。我不是想给 AI 套上枷锁，只是想给 AI 编程加一个智能刹车系统。因为真正可持续的 AI 开发，不是让 AI 一次跑得多快，而是让它每一次都能安全抵达。
最后允许我打个广告,可以这样安装cdf，使用时候可以$cdf或/cdf
npx skills add github.com/webszy/my-s... --skill cdf -a codex -a claude-code -g -y