前言¶

日常开发里两种常见的翻车：需求刚说两句就动手，写到一半才发现交互没对齐；改了代码忘了文档，交付物和说明互相打架，最后拿到的是源码，还要自己再加工才能用。下面介绍的这个 Skill 把「结构化调研 → 文档 → 编码 → 测试 → 交付打包」固定成一条流程，要求每个阶段的文档先经用户确认，再进入下一环。它面向从零开始的新项目或中大型新功能开发，不是给一句话脚本用的。

这是什么¶

一句话定位：一个社区 Skill，坐标 @user_2bb1379b/structured-dev-flow，版本 2.0.1，发布者 user_2bb1379b，来源 community，分类 dev-programming。它把开发流程明确规定为「开源调研 → 产品文档(PRD) → 交互文档 → 系统设计文档 → 编码 → 功能测试 → UI 交互测试 → 人机交互合理性校验 → 交付打包」。

它解决两个问题：一是代码和文档脱节，二是交付停在源码层面。流程要求每一阶段都产出文档，经用户确认后才进入下一阶段；全部完成后，打包可直接使用的产出物交付，而不是扔一份源码过来。

核心功能¶

固定的九步流程，顺序不能乱：

开源调研 → 产品文档(PRD) → 交互文档 → 系统设计文档 → 编码
→ 功能测试 → UI 交互测试 → 人机交互合理性校验 → 交付打包

每一步的要点：

1、开源调研：优先借鉴 GitHub 高分开源项目；
2、产品文档：产出 PRD；
3、交互文档：描述用户操作路径；
4、系统设计文档：进入编码前最后一份设计产物；
5、编码：接口与 Service 层必须写文档和注释（这是硬要求，不是建议）；
6、功能测试：验证业务功能；
7、UI 交互测试：验证页面上的实际交互；
8、人机交互合理性校验：按主流设计规范检查字体、字号、颜色、布局、触摸目标；
9、交付打包：产出可直接使用的成品。

每阶段文档须经用户确认后才进入下一阶段，这是整个流程的控制点。

文档与代码同步：修复问题或调整内容时，同步修改对应文档并记小版本，改后必回测；发现设计缺陷可以回溯修正文档，而不是让文档跟着代码跑偏。

安装与启用¶

该 Skill 发布在 SkillHub，标签 requires_api_key=false，说明不需要 API Key，加载后即可使用。官方地址：

https://api.skillhub.cn/user_2bb1379b/structured-dev-flow

SkillHub 页面：https://www.skillhub.cn/skills/user_2bb1379b/structured-dev-flow

接入方式沿用通用 SKILL.md 格式。本文未核实到官方安装命令与目录约定，安装时以 SkillHub 页面说明为准。

触发方式：用户说「按流程开发」「先出文档再写代码」「规范化开发」「新项目/新功能开发」等表述时触发。不需要额外配置，用自然语言调用即可。

典型用法¶

以中大型新功能开发为例，走一遍流程：

1 开源调研，优先看 GitHub 高分项目
2 产出 PRD，交用户确认
3 写交互文档，走一遍用户操作路径
4 写系统设计文档，接口与 Service 层留注释
5 用户确认后开始编码
6 功能测试 → UI 交互测试 → 人机交互合理性校验
7 打包可直接使用的成品交付

每一环的文档确认是硬门槛，跳过意味着流程还没走完。修复问题时先回到对应文档做改动，记一个小版本号，然后把相关功能回测一遍，确认文档和代码一致。

适用场景与注意¶

适合：从零开始的新项目、中大型新功能开发、需要长期维护和协作的任务。

不适合：一句话能完成的脚本、纯问答类任务。小型 bug 修复可以不用整套流程，但必须遵守变更与修复规则：同步改文档、记小版本、改后回测。

注意：这套流程会增加前期文档工作量，如果项目周期极短或需求高度不确定，前期投入可能超过收益。没有用户确认环节的自动化场景，也难以发挥它的作用。

写在最后¶

这个 Skill 的价值不在于「多写文档」，而是把文档确认当作过关的门槛，把打包交付当作流程终点，同时把接口与 Service 层的注释变成硬约束。适合需要长期维护、多人协作的项目。官方地址：https://api.skillhub.cn/user_2bb1379b/structured-dev-flow