方法选型与组合实践
方法选型不是为整个项目永久贴标签，而是判断当前工作缺什么证据。订单导出的用户价值、权限规则、任务容量和恢复能力可以分别处于不同确定程度，需要不同方法解决。
从当前阻塞选择下一步
先确认目标和风险，再确认验证条件。业务不清楚时先做用户观察；技术不可行性未排除时先做实验；目标和验证都明确时才扩大实现范围。即使工期很紧，也不能用生成代码代替这些判断。
| 场景 | 方法组合 | 为什么这样选 | 完成依据 |
|---|---|---|---|
| 新功能方向不明 | 原型 / Vibe + 用户试用 | 优先发现需求错误 | 具体反馈和继续、调整或停止决策 |
| 固定格式的客户交付 | 阶段基线 + 内部迭代 + 验收追踪 | 外部合同稳定，内部仍需早联调 | 格式、兼容、交付证据与基线一致 |
| 持续产品开发 | 迭代增量 + Scrum / 看板 + 工程测试 + DevOps | 同时缩短需求、实现和运行反馈 | 可用增量与运行效果 |
| 维护与故障修复 | 看板 + 复现 / TDD + 受控发布 | 到达不规则，正确性比功能扩张更重要 | 原症状消失，回归和恢复检查通过 |
| 性能、设备或迁移风险 | 螺旋式试验 + 规格 + 分阶段交付 | 错误方案代价高，先验证可行性 | 代表性环境下的基准和兼容结果 |
| 明确的多文件修改 | 轻量规格 + Agentic + 独立评审 | 执行工作可委托，判断责任仍明确 | 差异、检查与行为验收一致 |
订单导出的一条完整路线
探索阶段使用合成数据，先做字段、筛选和下载原型。运营试用后确认按支付时间筛选、金额可对账、文件名包含范围；如果这些反馈尚未稳定，继续扩大系统实现没有依据。探索结果应保留已确认行为和仍未回答的问题。
规格阶段补齐角色和租户隔离、字段白名单、数据量上限、异步状态、文件有效期和失败处理。用 BDD 场景评审关键规则，必要时先做性能试验。完成标准是任务能够执行和验收，并非“需求文档已创建”。
实现阶段按可验收增量拆分。先做受控 CSV，再做异步任务和历史。Scrum 管目标或看板管流动，Agent 负责范围明确的实现工作。每批都运行基线、补行为检查、审查差异，发现新事实时同步规格。
发布阶段使用同一可追溯制品，先验证实际依赖和配置，再按环境约定开放。观察任务失败、队列积压、数据库压力和下载鉴权；异常时停止新任务、处理已有任务并执行恢复方案。关闭按钮不是完整恢复，因为后台可能仍在执行。
异步任务为什么需要明确状态
示例状态可包括 QUEUED、RUNNING、SUCCEEDED、FAILED 和 EXPIRED。创建成功只表示任务被接受，下载成功要求任务完成、文件仍有效且请求者获授权。失败重试是否创建新执行记录，必须由任务合同决定。
Worker 在 RUNNING 期间退出，不能让任务永久悬挂。可以依据已有调度机制使用执行租约或心跳检测，再按幂等规则重试或标记失败；这些机制需要集成检查。字段白名单、任务归属和文件清理也应保持一致。
这说明“支持异步导出”不是一个标题，而是一组对象关系和状态规则。规格驱动帮助澄清，TDD 检查局部状态，集成测试检查队列和存储，DevOps 检查运行与恢复，Agent 可以在这些边界内实现。
根据风险调整流程强度
轻量任务可以只记录目标、范围和验证，例如修改文件命名规则。标准功能需要权限示例、状态、相关测试和评审。公共接口、迁移、隐私与资金行为还要补兼容、恢复、审计和环境授权。流程强度取决于改错的影响和验证难度，不能只按代码量判断。
执行中出现数据库迁移或跨服务变更，应升级方案与验证；确认只是局部纯函数修改，可以简化流程。每次升级或简化都要保留具体理由，否则团队会在“凡事写完整规格”和“凡事直接生成”之间摇摆。
失败反例与修正
| 看似更快的做法 | 实际后果 | 修正方式 |
|---|---|---|
| 原型接上生产数据就交付 | 演示路径掩盖隔离和下载风险 | 先补规格、权限和独立验收 |
| 多个 Agent 同时修改共享状态 | 接口和语义冲突，集成返工 | 先定合同，再分范围和集成验证 |
| 只看测试通过和覆盖率 | 错误预期也可能全部通过 | 核对业务断言，检查真实入口与文件 |
| 为赶进度绕过评审和恢复验证 | 故障成本转移到线上 | 缩小交付范围，保留必要质量门禁 |
| 只优化生成速度 | 评审堆积，交付变慢 | 控制 WIP，测等待与返工 |
验收时对照目标、规则、差异、运行结果和恢复方式，确认每项证据覆盖的范围。方法有效的标志是团队能够说明为什么这样实现、怎样证明正确，以及失败后如何处理。