需求到交付闭环

先明确交付到底卡在哪

很多项目不是“没写完”，而是写完后仍然不可用：功能存在，但用户走不通；页面能打开，但刷新后数据丢了；代码没报错，但用户点按钮时不知道下一步该做什么。这个技能要处理的就是这类 从需求到验收 的缺口：把“代码写完”降级为必要条件，把“用户能完整使用、关键路径全打通、失败不丢数据”作为完成标准。

它如何组织一次交付

整个流程是六阶段闭环：理解需求 → 拆解任务 → 开发实施 → 验证质量 → 交付上线 → 复盘沉淀。

核心做法包括：

• 用一句话定义核心目标，并列出 3-5 条关键路径和明确的完成标志。
• 用 5W1H 补全隐含需求，例如角色、搜索筛选排序、空数据展示、失败处理和数据存储位置。
• 按交互元素类别拆解任务，而不是按页面顺序串行开发；同类问题一次扫完。
• 先搭骨架：数据模型和 Store、路由或页面切换、列表渲染、详情与模态、关联跳转，最后再处理装饰性交互。
• 每写完一个函数就自测语法、引用、边界条件和异常路径，不攒 bug。
• 对导航、提交、删除等关键交互使用 addEventListener 与 onclick 双保险。
• 交付前过四道闸门：目标闸门、风险闸门、质量闸门、验收闸门；尤其要做用户视角端到端检查。
• 复盘时把踩坑、可复用模式、决策逻辑写入 MEMORY 或 CHANGELOG，让下一次交付能复用。

适用边界与注意点

它适合接到新需求后，需要快速形成可用交付物的个人项目、副业项目或 AI 协作项目。对已有项目补全功能时，可以优先扫描未接通的交互元素；处理紧急 bug 时，可以压缩为“定位→修复→验证→记录”。

注意两点：第一，技能强调“零确认执行”，但前提是核心目标和完成边界已经定义清楚；否则容易在错误方向上狂奔。第二，它不替代产品判断、领域建模、安全测试和团队协作，只提供项目级执行纪律。长期迭代时，它更像是 self-evolving-loop 中的单次交付循环，而不是无限陪伴式协作。