从手写代码转向 AI 编排，我是如何通过构建工作流实现高效交付的
我最近在公司内部推行了一套实操方案，核心逻辑是：承认自己变“懒”了，不再追求手动敲代码的快感，而是花精力构建一个能让 AI 稳定产出的环境。在这种模式下，我的角色从一个 Code Writer 变成了 Reviewer 和 Architect。
为了避免 AI 产生幻觉导致项目崩盘，我建立了一套极其严苛的约束机制。首先是“双模型对冲”策略。在实际开发中，我将 95% 的具体实现交给 Claude，但 Review 环节必须强制交给 GPT-4o。因为两个模型的“性格”差异很大，Claude 倾向于给出优雅且完整的结构，但有时会忽略某些边界条件的逻辑漏洞，而 GPT-4o 则像个死磕细节的极客，能精准抓出潜在的 Bug。我习惯于将两者的输出放在同一个上下文中让它们互怼，最后由我拍板。
其次，我意识到在 AI 时代，文档的权重必须高于代码。很多人习惯直接喂代码片段，但这很容易导致 AI 给出敷衍的答案。我建立了一个详尽的 Markdown 文档库，涵盖了项目的架构说明、组件配方以及一套私有的 Cheat Sheet。每次开启一个新的 Session，我必须先喂入相关的文档，强制 AI 在一个明确的上下文约束中执行，而不是让它在概率分布中随机猜测。
为了解决那些最头疼的“隐形 Bug”，我专门维护了一个名为“沉默失败”的目录。这里记录了 36 个能通过编译但渲染会出错的典型坑位，包括具体的报错症状、产生原因以及对应的修复方案。我将这个清单作为 AI 的自检项，要求它在输出代码前必须对照该清单进行自检，有效避免了重复踩坑。
在代码优化阶段，我定义了一套特殊的“抛光”标准。AI 习惯于通过增加装饰性代码来理解所谓的“优化”，这往往会导致代码冗余。因此我写死了一条规则：Polish = Subtraction（优化即删减）。我列举了所有被我毙掉的冗余模式，强制 AI 在优化时优先考虑删除不必要的逻辑，而非增加补丁。
最后，为了确保功能真实可用，我引入了 WebMCP 运行时验证。通过 Agent 驱动 Chrome 浏览器，在三个不同的视口尺寸下进行实际点击操作，并实时监控控制台报错并截图。只有通过了这一层物理验证的功能，我才会将其合入主分支。
这种工作流最大的代价是丧失了那种“死磕数小时终于解决 Bug”的成就感，现在的开发心态变得非常佛系。但实测结果证明，通过极高成本的文档维护，换取的是极低成本的代码实现。前端开发的重心已经从“怎么写”转移到了“怎么定义”，这或许才是 AI 时代工程师真正的竞争力。
