不要完全依赖superpowers的brainstorm skill. brainstorm skill使门槛变低，对非专业开发者友好——它通过反问和引导帮助用户一步步澄清需求，快速生成原型。但是专业程序员、架构师可以做到更好。

专业程序员、架构师应当把AI当成工具、当成有局限性的”AI同事”。要有自行主导整个开发过程的意识，不依赖于brainstorm skill的反问，避免陷入麻木的路径依赖。例如，如果总是回答AI“选择A，B，还是C”，开发者可能会逐渐丧失独立拆解问题的能力，变成机械地回应AI的提问，而不是主动规划全局。

应有整体思维，驾驭好AI，不断完善问题边界，不断补充对现实需求的判断，引导AI进行调研和方案迭代。比如在架构选型时，先由人提出候选方案（如“用PostgreSQL还是MongoDB？”），再由AI去检索性能对比、适用场景、社区活跃度等数据，回来后结合业务需求（如数据结构是否固定、是否需要复杂事务）做权衡。

让AI干他擅长的事。例如方案评估。提出设想后让AI去验证，辅助你去做权衡。我遇到过AI通过生成的Python代码去生成mock数据评估存储数据的规模，相应数据场景下的zlib压缩效果，用以判断存储方案是否可以被接受。AI还可以快速生成对比表格、模拟负载测试脚本、计算成本估算等，这些都是人力操作耗时长、但AI可以高效完成的任务。

人要做好最终审核，判断研究是否充分，方向是否正确，方案是否完善，复杂度是否可以接受。是否成熟到可以进行下一步执行落地。就像在传统软件工程流程中的设计评审环节。

当前AI做Coding很强。但是Coding只是软件工程工作流程中的一部分，其工作量平均要低于整体的30%。很多工作仍然需要人去完成：

• 对齐现实需求。 大多数Vibe Coding场景中，不会有提前写好详尽的需求分析。就算有需求分析本身也是会在开发过程中迭代变更的。人需要与业务方持续沟通，确认交付物是否真正解决痛点，而不是让AI生成一个看似功能完整但无人使用的系统。
• 提供顶层视角权衡。 目前的LLM模型的上下文容量有限，上下文长了还会分不清重点受到细节、过程内容污染。例如在微服务拆分时，AI可能只看到代码层面的耦合，而人需要从团队结构、部署成本、监控难度等全局因素出发做取舍。人需要设计测试场景、编写端到端测试用例，并手工验证跨系统交互的异常情况（如第三方API超时、数据库死锁、用户权限冲突）。
• 集成测试。 AI Agent还不能进行复杂情况下的全流程自动化测试。受Agent能力、外部环境约束、执行复杂度、成本限制。
• 对于生产项目，需要人进行最终的功能测试，作为最终的门控环节不能缺失。 这包括手动探索性测试、回归测试、验收测试，确保交付的软件在真实用户环境下行为符合预期，且没有引入安全漏洞或性能退化。

一种可行的使用模式：

1. 先进行人主导的，由AI辅助的探索研究，整体讨论，梳理方案。
2. 做出结论后，人来分割要执行的子任务边界，然后让AI生成多个独立新会话（上下文）的提示词指令。使用AI总结的提示词，开启多个新会话进行并行或串行执行。
3. 在新会话中还要再经过brainstrom的反问。但这里的反问是受控的：开发者先明确要完成的具体子任务目标，再让AI以brainstorm的方式提出实现细节、边界情况、测试方案等，从而发挥AI的补充思考能力，而不是让AI越权主导整体的架构方向。

开发者必须保持主导权，将AI视为辅助工具而非决策者。 要避免因brainstorm skill的低门槛而陷入被动回答的路径依赖，始终以整体思维主动规划、拆解问题、定义边界。让AI承担调研、验证、生成代码等高效任务，而人负责需求对齐、顶层权衡、测试审核和最终落地决策。只有人机各司其职，才能发挥AI的最大价值，交付真正可靠、符合业务需求的软件系统。