requirement-deliverylisted

# 接需求提效 ## 何时用 - 接到一个新需求或任务，需要快速产出可运行、可演示的成果时。 - 需求描述模糊、验收标准不清晰，担心做完方向不对时。 - 任务较大，不知道从哪里切入、如何拆解时。 - 时间紧张，需要优先打通核心流程、把次要功能后置时。 ## 核心规则 ### 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 在生成代码时有一种惯性——直接写一套新实现，哪怕项目里已经有一模一样的工具函数，或者一个知名库早就解决了这个问题。这不仅浪费时间，还会在代码库里留下重复逻辑，日后维护时产生不一致。 **怎么做：** - 在写任何工具函数或模块前，先搜索项目内的已有代码： ```bash # 检查项目内是否已有日期格式化工具 grep -r "formatDate\|format_date\|dateFormat" src/ --include="*.ts" -l ``` - 依赖外部功能时，先查标准库和主流 npm/PyPI 包，再考虑自己写： - 日期处理 → `date-fns` / `dayjs`，不自己写 `padZero` - HTTP 请求 → `axios` / `h