功能文档拆分器

面对长篇需求文档时的协作痛点

在敏捷开发中，早期的需求初稿往往只有一段简短的描述或一份粗糙的 Markdown 文件。当开发团队准备将其落地时，前端工程师需要明确页面状态与组件结构，后端工程师需要界定数据模型与接口契约。如果所有细节都混杂在一份 PRD 中，前后端往往会陷入互相等待或职责不清的困境，甚至导致接口定义不一致。

核心能力与工作流

@kunlungrowth/feature-doc-splitter 旨在解决这一协作摩擦。它不会直接生成业务代码，而是扮演资深技术文档工程师的角色，将你的初稿拆解为三份结构严谨的文档：overview.md、frontend.md 和 backend.md。

其核心工作流强调“代码优先”与“契约驱动”：

• 梳理代码与规则：在动笔前，它会先读取仓库中的 AGENTS.md 或既有文档约定，并通过代码检索找出可复用的现有组件、Hook、Schema 或服务，避免创造多余的抽象。
• 显式记录不确定性：对于需求中模糊的统计规则、权限或通知诉求，它会将其显式写入「假设」或「待确认事项」区块，而不是静默编造。
• 契约与图表分离：共享的接口契约只在总览文档中定义一次，前后端文档各自独立指导对应角色。同时，它会自动补充必要的 Mermaid 图，包括端到端业务流程图、多角色时序图以及前端交互图。
• 设计稿占位机制：若涉及新增 UI 表面且你需要设计稿，它可以创建一个标准的 Pencil 占位文件（如 docs/features/<name>/pencil/.pen），方便后续接入设计工具。

适用边界与注意事项

这个技能的定位是设计文档的编排者，而非代码生成器。它不适用于直接实现功能代码，也不负责绘制具体的 UI 视觉稿。

如果你只需要一份不拆分的传统 PRD，或者项目仅涉及单端开发而不需要前后端分离的契约定义，使用该技能可能会增加不必要的文档维护成本。此外，它生成的文档依赖仓库中已有的代码结构，如果仓库尚未初始化或代码极为稀疏，梳理出的职责边界可能会偏离实际工程现状。