AI Coding 深度夜谈

老布在实践中观察到，小白（无知无畏）和顶级极客（如他自己做创新项目）都在狂热使用 AI，但中坚力量（大厂资深同事）往往持保留态度。

根本原因分析：

• 验证成本高昂： 在复杂的遗留系统中，AI 不理解历史逻辑。它生成的代码可能引入隐蔽 Bug（Race Condition 等）。
• 责任不对等： 如果 AI 搞崩了程序，背锅的是架构师自己。代码审查（PR Review）时，如果不仔细看 AI 写的每一行代码，风险极大。
• 结论： AI Coding 目前最适合 Greenfield（从0到1的新项目） 或 个人工具，而非重度维护的遗留系统。

老布分享了具体的工具使用策略，强调不要依赖单一模型，并指出了工具间的“商业屏蔽”现象。

混合工具链 (Toolchain)：

• 核心编码： 坚定选择 Cloud Code。老布表示和它“磨合”得最好，一次性运行成功率极高，不建议用免费工具浪费时间。
• 架构与探讨： 使用 ChatGPT Pro 进行技术方案探讨，补充知识盲区。
• 信息交叉验证： 使用 Gemini。
  *重要发现：ChatGPT 在回答 AI Coding 相关问题时，会刻意过滤掉竞品 "Cloud Code" 的信息。因此必须用 Gemini 等其他模型进行“左右互搏”，获取客观信息。

开发流程：

先生成 HTML 原型 -> 确认需求 -> 再生成具体端代码（如 SwiftUI）。在原型阶段，给组件起确定的名字（如 tab_main），建立人机共识，以便后续精确指挥修改。

老布提到，以前他作为管理者/产品经理，做方案需要找技术同事“访谈”，获取的是二手信息。现在他直接上手写代码。

• 信息颗粒度的质变： 只有亲自 Coding，才能从大量数据中总结出真正的一手认知。这种“体感”是看报告无法获得的。
• 判断力的提升： 只有自己做过，才能一眼识别出市面上的 AI 专家是在“吹牛”还是真有干货。
• 超级个体： 以前开发一个 APP 需要整个团队，现在老布一个人 4 天就能完成 Apple Watch 应用开发（从 0 到 上架），效率提升带来了极大的爽感。