在当下的开发环境中，使用 AI 辅助编码（AI-Assisted Coding）已经成为常态。无论是 GitHub Copilot 的自动补全，还是各类 Chat 模型的问答，都在极大提升我们的效率。
然而，当我们面临复杂的业务逻辑变更时，简单的“补全”或“单点修改”往往显得力不从心。最近，我们在一次涉及核心业务流程（服务发布/编辑）的逻辑改造中，尝试了一套基于 OpenSpec + Claude Opus 的 Agent 协作模式。
本文将分享我们在这次实战中的工作流、遇到的挑战以及对 AI 辅助开发的深度思考。
🛠️ 技术栈与工作流
本次实战我们采用了以下组合：
- 核心模型：Claude Opus 4.6（配合 VS Code Copilot）
- 规范工具：OpenSpec 1.0.2
- 输入素材：业务原型图 + 需求描述
核心思路：
采用先策划，后执行的策略——先利用 AI 分析需求并生成一份详细的开发任务清单（tasks.md），开发者介入修正这份清单，最后再交由 AI 执行代码编写。
🧐 资产文档分析：AI 的“脑补”与现实的差距
在让 AI 生成 tasks.md 后，我们并没有直接接受，而是进行了一轮深度的人工审查（Code Review 前置为 Plan Review）。
通过这次“纠偏”过程，我们发现了 AI 在处理复杂业务时容易出现的几个典型误区：
1. 过度设计 vs. 复用现有逻辑
现象：AI 倾向于“新增”。例如，在需要获取某些关联信息时，AI 往往建议新增一个查询方法（API 或 Store Action）。 修正：在实际的大型项目中，很多数据在父级或初始化阶段已经加载。我们将方案修正为直接复用现有列表数据，避免了不必要的网络请求和冗余代码。
2. 类型定义的“重新发明轮子”
现象：AI 会根据它对需求的理解，重新定义一套数据类型或接口。 修正：项目里通常已有成熟的类型定义。我们需要引导 AI 从项目现有的类型库中查找和引用，而不是在局部制造“类型孤岛”。
3. 范围蔓延（Scope Creep）
现象：AI 在分析需求时，有时会产生“过度联想”。比如本次需求仅涉及 A 模块的改动，AI 却认为 B 模块和 C 模块也需要同步修改。 修正：果断剔除与本次需求无关的模块改动。保持变更的原子性和最小化，是维护遗留系统的关键。
4. 业务规则的理解偏差
现象：这是最考验开发者的地方。AI 容易误解一些细腻的交互逻辑，比如“某种状态下禁止编辑”、“特定标签的展示时机”或“二次确认弹窗的触发条件”。 修正：这些逻辑往往隐含在交互细节中。我们需要手动修正 AI 生成的逻辑判断条件，确保交互逻辑的精准性（如去掉不必要的校验、修正展示条件的逻辑非关系等）。
💡 总结与反思
1. “没有文档”时的双刃剑
在缺乏后端接口文档的情况下，AI 设计出的任务逻辑往往是“合理但非最优”的。它能设计出一套跑得通的方案，但可能与项目目前的惯用方案（Best Practice）有所区别。这需要开发者具备强大的架构把控能力。
2. 核心前提：完全理解需求
这是最重要的一点。检查 AI 生成任务准确性的前提，是开发者自己要先完全理解需求。 如果开发者自己对需求一知半解，就无法发现 AI 文档中的错误（多余的改动、漏掉的逻辑、错误的理解）。
3. AI 文档的“不友好”特性
目前看来，AI 一次性生成的任务文档（Task Doc）往往包含错误、冗余或遗漏。对于开发者来说，直接阅读和修正这些文档通过会有一定的认知负担。
