feature-new：从一句需求到一组可执行任务

feature-new 是我在公司项目里反复打磨的一套新功能设计与开发工作流，现在迭代到 v3.3.0——一个「路由器」式的技能：不预设语言、框架、目录结构，先把项目事实探测清楚，再决定用什么姿势干活。

它解决什么问题

让 AI 做新功能开发，最常见的翻车有两种：一是拿到需求直接开写，跳过设计，越写越乱；二是把某个项目的架构当万能模板，换个项目就水土不服。这个工作流把流程倒过来——先探测、再设计、后开发，每一步有明确的确认关卡。

核心流程

1. 项目探测：先读项目规范、README、构建清单、CI 配置和相邻实现，按七类 profile 判断项目形态——架构（DDD / 分层 / MVC / 六边形）、后端、前端、数据库、API、集成、测试。只启用被项目事实证实的 profile：没有 UI 就不创建前端任务，没有数据库就不生成迁移脚本。
2. 需求分析与设计（阶段一）：产出设计文档，结束默认暂停等用户确认。
3. 任务拆分（阶段二）：按依赖拓扑排序拆成任务文件，命名规则统一（显示名 → kebab-case slug → {NN}_{type}_{short-slug}.md），同样要确认。
4. 增量开发与验证（阶段三）：逐任务实现并跑验证闭环，不虚报完成。

几个关键机制

• 技术栈无关：核心流程不绑定任何技术；项目专属知识放在 profile 参考文件里（当前工作区附带 fjgtkj-2026 项目的术语映射，其他项目删掉 profiles 目录即为纯通用版）。
• 确认关卡与自动模式：阶段一、二默认暂停；加 --auto 后改为自检放行——但高风险项保持 blocked，自动模式不豁免。
• 诚实边界：缺少项目规范、关键调用链、迁移依据或验证命令时，把受影响任务标记为 blocked 并记录原因，而不是硬编。

产物

产物	说明
$DOC_PATH/$FILE_SLUG.html	单文件设计文档
$DOC_PATH/tasks/*.md	按依赖排序的任务文件
schema/ 迁移脚本	仅在检测到数据库和迁移机制时生成

这套流程的实战沉淀可以对照站内的两篇项目文章：《福建国土空间基础信息平台-数据中心》和《AI 智能客服助手》——它们的迭代节奏就是按「需求评审 → 任务拆分 → 增量验证」跑的。