requirement-delivery

接需求提效

何时用

• 接到一个新需求或任务，需要快速产出可运行、可演示的成果时。
• 需求描述模糊、验收标准不清晰，担心做完方向不对时。
• 任务较大，不知道从哪里切入、如何拆解时。
• 时间紧张，需要优先打通核心流程、把次要功能后置时。

核心规则

1. 先澄清再动手

规则： 接到需求后，先列出验收标准与边界条件；有模糊之处，先向对方确认，不猜着做。

为什么： AI 极容易把"我理解的需求"当成"真实需求"——用户说"做一个导出功能"，AI 默默实现了 CSV 导出，结果对方要的是 Excel；用户说"优化一下性能"，AI 大幅重构了数据结构，结果对方只是想加个分页。这类方向性错误往往要到交付时才暴露，前面所有工时全部作废。

怎么做：

• 收到需求后，先不写代码，而是写出 2-4 条验收标准，发给对方确认：

  我理解这个需求的验收标准是：
  1. 用户点击"导出"按钮后，下载一个 .xlsx 文件
  2. 文件包含当前筛选结果中的所有行，字段顺序与表格列顺序一致
  3. 导出超过 1 万行时有进度提示，不卡死页面
  以上理解是否正确？有没有我遗漏的场景？
  

• 列出不确定的边界条件，例如：空列表怎么处理？文件名格式是什么？权限校验在哪一层？
• 确认完成再开始写代码，不要"边做边猜、做完再问"。

---

2. 拆成可交付小块

规则： 把需求拆成独立可演示的小块；优先打通核心路径（MVP），次要功能后置。

为什么： AI 倾向于一口气把"完整方案"全部写完再交付——结果往往是：核心逻辑正确，但周边逻辑（错误处理、边界分支、UI 细节）有缺漏，整体跑不起来，联调阶段才发现问题。拆成小块后，每一块都能独立验证，早发现早修正，整体风险大幅降低。

怎么做：

• 拿到需求先画出任务树，识别哪条是核心路径：

  需求：用户可以通过邮箱注册账号
  
  核心路径（MVP，优先做）：
  - [ ] POST /api/register 接口，写入 users 表
  - [ ] 返回 JWT token，前端可以登录
  
  次要功能（MVP 通过后再加）：
  - [ ] 邮件验证流程
  - [ ] 密码强度校验提示
  - [ ] 注册成功欢迎邮件
  

• 每块完成后，能独立运行一个最小 demo 或通过一个测试，再进入下一块。
• 不在"核心路径还没跑通"时去完善次要功能。

---

3. 复用优先

规则： 动手前先找现成的库、模板、或项目内已有代码；不从零造轮子。

为什么： AI 在生成代码时有一种惯性——直接写一套新实现，哪怕项目里已经有一模一样的工具函数，或者一个知名库早就解决了这个问题。这不仅浪费时间，还会在代码库里留下重复逻辑，日后维护时产生不一致。

怎么做：

• 在写任何工具函数或模块前，先搜索项目内的已有代码：

  # 检查项目内是否已有日期格式化工具
  grep -r "formatDate\|format_date\|dateFormat" src/ --include="*.ts" -l
  

• 依赖外部功能时，先查标准库和主流 npm/PyPI 包，再考虑自己写：
  • 日期处理 → date-fns / dayjs，不自己写 padZero
  • HTTP 请求 → axios / httpx，不自己封装 XMLHttpRequest
  • 数据校验 → zod / pydantic，不自己写 if typeof x !== 'string' 链
• 复用项目内已有代码时，读懂它的接口约定再调用，不要复制粘贴后再魔改。

---

4. 边做边验证

规则： 每完成一块，立即用真实场景自测一遍；不把验证堆到最后。

为什么： AI 写完一大段代码后统一"跑一下看看"，是最危险的工作方式。一旦出错，错误来源可能在任何一块代码里，定位成本极高。更常见的情况是：每一块单独看起来都合理，但组合在一起时有隐含的状态依赖或接口不匹配，早测早改成本是后测的十分之一。

怎么做：

• 每完成一个函数或接口，立即写一个最小调用验证：

  # 写完 parse_config() 后，立刻跑一遍：
  cfg = parse_config("tests/fixtures/sample.toml")
  assert cfg.host == "localhost"
  assert cfg.port == 5432
  print("parse_config OK")
  

• 后端接口写完，用 curl 或 Postman 打一个真实请求，不等前端联调才发现返回格式不对。
• 发现错误立即修，不要"先记着、做完再统一修"——堆积的 bug 会产生连锁效应。