前言¶

需求拿到手，第一步往往不是写代码，而是先想清楚要改哪几个文件、每个文件里动哪个函数。想不清楚就直接让模型开工，结果是大面积改动、验证不通过、提交信息也说不清这次到底改了什么。

下面介绍的这个 Skill「智能体开发助手(后端开发)」，就是针对这条链路做的：从需求出发，先产出结构化规格书，再把任务拆到单文件/单函数粒度，实现后过静态验证和可配置的运行时验证两道闸门，最后沉淀知识并做语义化提交。

这是什么¶

一句话定位：一个面向后端开发的 8 阶段通用开发流水线 Skill，覆盖从需求到代码提交的全流程。

发布与归属信息：

• Skill 坐标：@user_f3f6053c/zhinengtikaifa-001
• 版本：1.0.1
• 来源：community（社区）
• 分类：dev-programming
• 是否需要 API Key：requires_api_key=false
• 官方地址：https://api.skillhub.cn/user_f3f6053c/zhinengtikaifa-001

需要如实说明的是，页面简介写着「腾讯发布的一个 Skill 跑通需求开发全流程；通过其拆解的思想逻辑进行二次创作，通过 AI 整理出来」。也就是说，这个 Skill 的思路源自腾讯内部跑通的那套需求开发流程，当前这个版本是社区作者基于该思想做的二次整理，并不是腾讯官方维护的发布物。引用时注意区分。

它解决的问题：把「有设计好的需求、业务、原型」到「一次规范的代码提交」之间的步骤固化下来，让 Agent 按工程化流程推进，而不是边想边写。前提条件是需求侧已经就绪，它不负责从零构思业务方案。

核心功能¶

下面按流水线顺序介绍这 8 个阶段。阶段划分与能力表述来自 Skill 简介；各阶段内部的具体产物格式和命令，资料中没有给出，这里不做臆测。

1、规格书生成。输入 PRD 和 API 规范，输出结构化规格书。这一步先把需求翻译成可执行的规格，而不是直接进入编码。
2、原子化任务拆解。把规格书拆成单文件/单函数粒度的任务。粒度切得细，后续每个任务的改动面才可预期。
3、代码位置定位。在动手前精确定位需要修改的代码位置，避免大范围搜索式改写。
4、精准实现。在定位到的位置上做精准修改，而不是整文件重写。
5、静态验证。第一道闸门，做静态层面的检查。
6、可配置运行时验证。第二道闸门，运行时验证的具体方式和配置项由使用者按项目情况设定。
7、知识沉淀。把本次开发中的经验沉淀下来，供后续任务复用。
8、语义化提交。按变更语义组织提交，而不是堆一堆无信息量的 commit message。

模板支持方面，简介提到支持 Python、TypeScript、通用三套模板自动匹配。也就是说 Agent 会根据项目语言选择对应的任务拆解和实现模板。

触发场景按官方描述：当用户需要按工程化流程完成需求开发、代码实现、质量验证、知识沉淀、或规范化 Git 提交时使用。

安装与启用¶

安装命令在已抓取的资料中没有给出，此处不编造。下面说明可以确认的部分。

• 坐标：@user_f3f6053c/zhinengtikaifa-001
• 访问入口：SkillHub 页面 https://www.skillhub.cn/skills/user_f3f6053c/zhinengtikaifa-001
• 接口地址：https://api.skillhub.cn/user_f3f6053c/zhinengtikaifa-001
• API Key：不需要（requires_api_key=false）

关于不同客户端的差异：这类 Skill 基于通用 SKILL.md 格式，理论上可以挂到支持该格式的 Agent 运行环境。但 Cursor、Codex CLI、Claude Code 各自的安装路径和启用方式，在现有资料里没有分别说明，本文不逐条给出未经核实的配置步骤。拿到 Skill 包后，按你所用客户端的 SKILL.md 加载方式放置即可。

建议启用前先做一件事：确认你手上的 PRD 和 API 规范是完整的。这个 Skill 的前提是「设计好的需求、业务、原型」，需求文档缺失时流水线前面几步会缺少输入。

典型用法¶

资料中没有提供官方的可复现示例，下面是按流水线逻辑整理的使用方式，具体参数以实际 Skill 包内说明为准。

第一步，准备输入。把 PRD 和 API 规范放在项目里可访问的位置，确保 Agent 能读到全文。

第二步，发起需求开发任务。在 Agent 会话中说明你要按工程化流程推进这个需求，让 Agent 加载该 Skill 并执行流水线。

第三步，检查规格书。流水线启动后，先拿到结构化规格书和任务拆解结果。这一步值得人工过一眼：任务粒度是否切到单文件/单函数，覆盖范围有没有遗漏。

第四步，让流水线跑实现与验证。实现完成后会依次过静态验证和运行时验证两道闸门。如果运行时验证配置过，这一步才能真正起到把关作用；没配置的话，闸门只有静态那一道。

第五步，看提交。验证通过后产出语义化提交，检查 commit message 是否反映了本次变更的实际语义。

适用场景与注意¶

适合的场景：

• 后端需求已经明确，有 PRD 和 API 规范，需要按流程落地到代码。
• 希望 Agent 的改动局限在定位到的位置，避免整文件重写带来的回归风险。
• 团队希望代码提交有规范的语义，便于后续 review 和回溯。
• 项目是 Python 或 TypeScript，可以直接用对应模板。

需要注意的限制：

• 前提是需求侧已经设计好。需求含糊、没有原型或 API 规范不完整时，前面的规格书生成和任务拆解缺乏输入，流水线推不动。
• 运行时验证是「可配置」的，也就是说它不会自动知道怎么跑你的项目。这部分需要使用者按项目情况配置，否则只有静态验证一道闸门。
• 简介提到源自腾讯内部流程的二次创作，当前版本由社区作者维护。生产环境使用前，建议自己跑一遍完整流水线验证行为是否符合预期。
• 资料中看不到具体的配置项清单和命令，落地前需要打开 Skill 包确认。

结尾¶

这个 Skill 的价值在于把需求到提交的链路拆成 8 个可检查的阶段，让 Agent 的每次改动都有定位、有验证、有沉淀。相比直接把需求丢给模型写代码，粒度更细、验证更完整、提交更规范。

官方地址：https://api.skillhub.cn/user_f3f6053c/zhinengtikaifa-001