以前我对AI编程的理解，多少有点「口喷式开发」。我把需求说出来，Codex帮我写，写完我跑，报错了我再截图给它，继续修。你自己知道哪里有坑？哪里能忍？哪里坏了？自己修一下，也就过去了。可如果你要把程序做成能交付、能商业化、能给别人用的东西，只靠口喷就不够了。因为用户不会管你是不是用AI写的，也不会管你背后跑了多少模型？他只会问：这个功能为什么不稳定？这个按钮为什么点不了？这个数据为什么不准？我付了钱，为什么还要替你测试？这时候你就会发现，AI编程最缺的不是技术，而是工程秩序。猫大人跟我聊到多agent协调的时候，我突然意识到Codex如果配合Superpowers插件，再加上Plan模式和Goal模式。Superpowers里面的多agent能力，比如dispatching-parallel-agents和subagent-driven-development，可以把任务拆给不同角色。但这里有个前提不能光有多agent，还得有工程原则。不然就是一群人一起乱忙，热闹是热闹，最后做出来还是一坨屎山。但你要是想用AI做真正能商业化的程序，这四个东西绕不过去。设计模式不是让你背什么23种经典模式，也不是让你上来就搞一堆抽象类、工厂、策略、观察者。对AI编程来说，设计模式最重要的价值，是让你知道：遇到重复问题，不要每次都临时乱写。比如一个系统里有多个支付方式，你不能每来一个支付方式，就到处复制粘贴一段逻辑。你应该设计一个稳定的结构，让新增支付方式只改一个地方。很多AI生成的代码为什么看起来能跑，但后面越改越痛苦？因为它没有结构。它只是为了满足眼前需求，把东西一层一层糊上去。这就像装修房子，今天缺个插座，明天拉根明线，后天再接个排插。短期能用，长期就是安全隐患。不要一个文件里又处理登录，又查数据库，又发邮件，又写日志，又控制页面跳转。看起来很能干，实际上非常危险。因为你一句话说得很大，它就很努力地把所有东西塞进一个文件里，想一次性满足你。SRP就是让你提前拆开：用户模块管用户，支付模块管支付，通知模块管通知，数据清洗模块管数据清洗。高内聚，就是一个模块内部的东西，彼此强相关，放在一起有道理。拿火锅店举例，后厨切菜的人，就专心切菜；前厅服务员，就专心接待；收银就专心收钱。每个岗位内部动作很集中，这叫高内聚。但切菜师傅不要每切一盘肉，都必须问收银员能不能切；服务员也不要每上一盘菜，都要改后厨的刀法，这叫低耦合。如果你的订单模块一改，用户模块崩了；用户模块一改，支付模块崩了；支付模块一改，页面也崩了，那就说明耦合太高。所以高内聚低耦合，它是为了让AI和人都能看得懂、改得动、修得起。很多人一听测试就烦，觉得我功能都没写完，测什么测。因为AI最擅长的是执行，最容易出问题的是理解偏差。你不先告诉它什么叫对，它就会写出一堆看起来很像对的东西。这就像你请人装修，不是等装完了才说「我想要高级感」。你要提前说，卧室要几个插座，厨房水槽多大，动线怎么走，验收标准是什么。- Plan模式，让Codex拆需求、拆模块、拆风险。
- Goal模式持续执行，用Superpowers里的多agent能力做分工和审查。
请先进入Plan模式，帮我设计这个功能。先不要写代码。请从设计模式、SRP、高内聚低耦合、TDD四个角度拆解：1. 这个功能应该拆成哪些模块？2. 每个模块只负责什么？3. 哪些模块之间不能互相依赖？4. 哪些测试应该先写出来？5. 最后给我一个分阶段实现计划。
请按刚才的计划进入Goal模式执行。每完成一个模块，都要运行对应测试。如果测试失败，先解释失败原因，再修复。不要跳过测试，不要把多个模块混在一起改。
请使用多agent方式审查这个实现。一个agent检查是否符合需求文档；一个agent检查SRP和模块边界；一个agent检查测试覆盖；一个agent检查代码质量和耦合风险。最后汇总必须修改的问题，按优先级排序。
AI编程的第一性原理，不是生成代码，而是把需求变成可验证的结果。- Superpowers：让不同agent分工检查，别把所有问题都漏掉。
所以我现在越来越觉得，学AI编程不要只学怎么提需求，也不要只学怎么让AI写得快。
夜雨聆风
