1. 先搞清楚 pdlc-skills 到底解决什么问题pdlc-skills 这个名字拆开看就很直白PDLC 是 Product Development Life Cycle产品开发生命周期的缩写skills 指的是一套可复用的技能模块。合在一起它想做的事情就是——把产品从需求到上线的整条链路拆成一个个可以被智能体Agent执行的标准化动作。我最早接触这套东西的时候第一反应是又是一个流程模板。但真正把它塞进一个正在跑的真实项目之后我发现它跟传统的 PRD 模板、TDD 模板有本质区别传统模板是给人看的文档格式pdlc-skills 是给智能体看的执行指令。这个区别决定了你用它的时候思路得换一换。具体来说它覆盖的核心环节包括需求发现与 PRD 生成从零散的想法、前端原型、甚至已有的页面交互中反向推导出结构化的产品需求文档TDD 任务拆解把 PRD 里的功能点拆成可测试、可验证的开发任务每个任务都有明确的输入输出和验收标准代码实现与 Git 工作流智能体根据任务描述生成代码并通过 Git 分支管理、commit 规范来保证可追溯验证与迭代跑测试、对比预期、修正偏差形成闭环适合谁来用我的判断是三类人一是手里有前端工程但缺 PRD 的独立开发者二是想用 Claude Code 这类工具提效但不知道怎么组织工作流的小团队三是已经在用智能体写代码但总觉得差点意思的工程师。如果你属于这三类下面的内容应该能帮你省不少试错时间。2. 把 pdlc-skills 落到真实项目的整体设计思路2.1 为什么不能直接照搬模板很多人拿到 pdlc-skills 的第一反应是把它当成一个填空模板把项目信息往里塞就完事了。我试过效果很差。原因是真实项目的上下文远比模板复杂你可能有遗留代码、有正在跑的线上服务、有不能动的数据库结构、有产品经理口头提的模糊需求。所以我的做法是把 pdlc-skills 当成一套约束框架而不是填充模板。框架的作用是告诉智能体你现在处于哪个阶段、这个阶段的输入是什么、输出应该长什么样、什么情况下算完成。至于具体内容得从你的真实项目里提取。举个例子PRD 生成这个环节模板可能会要求你填用户故事验收标准优先级。但在真实项目里你得先让智能体读你现有的前端代码理解页面之间的跳转关系、表单字段、按钮的交互逻辑然后才能写出靠谱的 PRD。这一步如果跳过生成的 PRD 就是空中楼阁。2.2 工具链选型的逻辑pdlc-skills 本身不绑定具体工具但实际用下来Claude Code 是目前配合度最高的。原因有三个第一Claude Code 支持在终端里直接操作文件系统和 Git这意味着智能体可以自己读代码、写代码、提交 commit不需要你手动搬运。第二它的上下文窗口足够大能一次性吃下一个中等规模前端工程的核心文件。第三它对 Markdown 格式的指令理解得比较准而 pdlc-skills 的输出基本都是 Markdown。Git 这边没什么好说的就是标准工作流。但有一个细节要注意智能体操作 Git 的时候分支命名和 commit message 必须提前约定好。我一般用feat/fix/docs/这样的前缀commit message 用type(scope): description的格式。这样后面回溯的时候一眼就能看出哪个 commit 是智能体生成的、对应哪个任务。2.3 整体流程的拆解我把整个流程分成四个阶段每个阶段对应 pdlc-skills 里的不同技能模块阶段输入输出对应技能需求反推前端工程代码、页面截图、口头需求结构化 PRDPRD 生成技能任务拆解PRD 文档TDD 任务列表任务拆解技能代码实现单个任务描述可运行的代码 commit编码技能 Git 技能验证迭代代码 测试用例测试报告 修正记录验证技能这个表格看起来简单但每个阶段的输入和输出之间的转换才是真正花时间的地方。下面我逐个拆。3. 核心环节的实操细节与避坑要点3.1 从现有前端工程反推 PRD 的具体做法这是整个流程里最容易被低估的一步。很多人觉得我有页面了PRD 随便写写就行但实际做下来从前端代码反推 PRD 需要解决三个问题页面之间的关系、数据的流向、交互的边界条件。我的操作步骤是这样的第一步让智能体扫描工程结构。用 Claude Code 打开项目根目录执行一条指令让它列出所有路由文件和对应的组件文件。比如# 在 Claude Code 里输入 请扫描 src/pages 和 src/router 目录列出所有页面路由和对应的组件文件路径这一步的目的是建立页面地图。智能体会输出一个列表告诉你有哪些页面、每个页面对应哪个组件文件。第二步逐个页面提取交互信息。对每个页面让智能体读取组件代码提取出表单字段有哪些、按钮点击后触发什么动作、页面跳转的目标是什么、有没有条件渲染的逻辑。这一步的输出是一份页面交互清单。第三步合并成 PRD。把页面交互清单按业务流程重新组织补上用户角色、使用场景、异常处理就得到了一份可用的 PRD。注意这一步不要让智能体一次性处理所有页面上下文会爆。我的经验是每次处理 3-5 个页面处理完一批就保存一次中间结果。3.2 TDD 任务拆解的粒度控制PRD 有了之后下一步是拆任务。这里有个坑拆得太粗智能体写代码的时候会跑偏拆得太细任务数量爆炸管理成本比写代码还高。我试过几种粒度最后稳定在一个任务对应一个可独立测试的功能点。具体标准是任务描述里必须包含输入、输出、验收条件任务完成后能写出一条对应的测试用例任务之间的依赖关系明确没有循环依赖举个例子如果 PRD 里有一个用户登录功能我不会拆成写登录页面写登录接口写登录逻辑这种按技术分层的拆法而是拆成用户输入手机号和验证码点击登录按钮系统校验验证码正确性验证码正确时系统生成 token 并跳转到首页验证码错误时页面显示错误提示按钮恢复可点击状态这样拆的好处是每个任务都是一个完整的行为单元智能体写代码的时候目标很明确测试的时候也容易验证。3.3 Git 工作流的约定与自动化智能体操作 Git 最容易出问题的地方是 commit 混乱。我见过最离谱的情况是智能体把三个不相关的修改塞进一个 commitmessage 写的是update code。这种 commit 后面根本没法回溯。我的做法是在项目根目录放一个.claude/instructions.md文件里面写清楚 Git 规范# Git 规范 ## 分支命名 - 新功能feat/功能名 - 修复fix/问题描述 - 文档docs/文档名 ## Commit Message 格式 type(scope): description type 可选值feat, fix, docs, refactor, test scope 是模块名 description 用中文不超过 50 字 ## 提交频率 每完成一个 TDD 任务提交一次不要攒着一起提交这个文件放在项目里Claude Code 每次操作 Git 之前都会读它commit 质量会明显提升。3.4 验证环节的自动化测试接入TDD 的核心是测试先行但实际用智能体写代码的时候我建议反过来先让智能体写代码再让它根据任务描述生成测试用例然后跑测试。原因是智能体对任务描述的理解可能和你的预期有偏差先写代码能快速暴露偏差再补测试能验证修正结果。测试框架的选择看你的技术栈。前端项目我一般用 Vitest后端用 Jest 或 Pytest。关键是要让智能体能自己跑测试、自己看结果、自己修正。Claude Code 支持执行终端命令所以这一步可以完全自动化。4. 完整实操流程从零到跑通一个真实项目4.1 环境准备与工具安装先把基础环境搭好。我假设你用的是 Windows 或者 macOSLinux 用户应该不需要看这部分。Git 安装与配置Windows 用户去 Git 官网下载安装包一路默认选项就行。安装完之后打开 Git Bash配置用户名和邮箱git config --global user.name 你的名字 git config --global user.email 你的邮箱macOS 用户如果装了 Homebrew直接brew install git就行。Claude Code 安装Claude Code 目前主要通过 npm 安装npm install -g anthropic-ai/claude-code安装完之后在项目目录下执行claude命令就能启动。如果你在 Windows 上遇到无法将 claude 项识别为 cmdlet的报错检查一下 npm 的全局 bin 目录有没有加到 PATH 里。注意Claude Code 需要配置 API Key 才能使用。具体配置方法参考官方文档这里不展开。项目初始化mkdir my-project cd my-project git init npm init -y然后把你现有的前端工程代码复制进来或者从远程仓库 clone 下来。4.2 用 pdlc-skills 生成第一版 PRD环境好了之后开始跑流程。第一步是让智能体读你的前端工程生成 PRD。在 Claude Code 里输入这样的指令请阅读 src 目录下的所有页面组件提取每个页面的 1. 页面名称和路由路径 2. 表单字段及其校验规则 3. 按钮和交互元素的动作 4. 页面跳转关系 然后按照以下结构生成 PRD - 产品概述 - 用户角色 - 功能列表按模块分组 - 每个功能的详细描述包含输入、处理逻辑、输出、异常情况智能体会花几分钟读代码然后输出一份 PRD。这份 PRD 不会完美但能覆盖 80% 的功能点。剩下的 20% 需要你手动补充主要是业务规则和边界条件。我一般会把生成的 PRD 保存成docs/PRD.md然后用 Git 提交一次git add docs/PRD.md git commit -m docs(prd): 基于前端工程生成第一版 PRD4.3 从 PRD 拆解 TDD 任务列表PRD 有了之后下一步是拆任务。指令可以这样写请阅读 docs/PRD.md把每个功能点拆解成可独立开发和测试的任务。 每个任务需要包含 - 任务编号 - 任务描述一句话说清楚要做什么 - 输入需要哪些数据或前置条件 - 输出完成后应该是什么状态 - 验收条件怎么判断任务完成了 - 依赖任务如果有 输出格式用 Markdown 表格。智能体会输出一个任务列表。我一般会检查一遍把太粗的任务再拆细把重复的任务合并。然后保存成docs/TASKS.md。这一步的关键是任务粒度。我的经验是一个任务对应的代码量控制在 50-200 行之间比较合适。太少说明拆得太细太多说明拆得太粗。4.4 逐个任务实现与 Git 提交任务列表有了之后就可以开始逐个实现了。对每个任务在 Claude Code 里输入请实现 TASKS.md 中的任务 #1。 要求 1. 先阅读相关代码文件理解现有结构 2. 实现功能 3. 写对应的测试用例 4. 跑测试确保通过 5. 提交 Gitcommit message 格式参考 .claude/instructions.md智能体会自动完成这一整套动作。你只需要在它完成后检查一下代码质量和测试结果。这里有个实操心得不要一次性让智能体实现多个任务。我试过让它一次做三个任务结果它把三个任务的代码混在一起测试也跑不通排查起来很痛苦。一个任务一个任务来虽然看起来慢但总体效率更高。4.5 验证与迭代所有任务实现完之后跑一遍完整的测试套件npm test如果有测试失败让智能体根据失败信息修正。修正完之后再跑一遍直到全部通过。然后做一次完整的功能验证启动开发服务器手动走一遍核心流程看看有没有智能体没覆盖到的边界情况。这一步不能省因为智能体写的代码在逻辑上可能没问题但在实际交互中可能有体验上的瑕疵。5. 常见问题与排查技巧实录5.1 智能体生成的 PRD 太笼统怎么办这是最常见的问题。智能体读代码的时候如果代码结构不清晰、注释少、命名不规范它提取出来的信息就会很粗糙。解决办法有两个一是先花时间整理代码结构把页面组件按功能模块分目录给关键函数加注释二是在指令里明确要求每个功能点必须包含至少一个具体的用户操作示例。第二个办法见效快但第一个办法是治本的。5.2 Git 提交冲突怎么处理智能体操作 Git 的时候如果遇到冲突它可能会卡住或者做出错误的合并决策。我的做法是在让智能体操作 Git 之前先手动确保工作区是干净的。具体来说每次让智能体开始一个新任务之前先执行git status确认没有未提交的修改然后git pull拉取最新代码。如果确实遇到了冲突不要让智能体自动解决手动处理完之后再继续。5.3 测试跑不通但代码看起来没问题这种情况通常是环境问题或者依赖问题。排查顺序检查 Node 版本是否匹配node -v检查依赖是否安装完整npm install检查测试配置文件是否正确检查是否有环境变量缺失如果以上都没问题让智能体输出详细的错误日志根据日志定位。5.4 智能体理解偏差导致代码跑偏智能体不是万能的它对任务描述的理解可能和你的预期有偏差。我的经验是任务描述里尽量用用户视角而不是技术视角。比如用户点击登录按钮后系统校验验证码比实现登录接口的验证码校验逻辑更容易被正确理解。如果发现跑偏了不要让它改一改而是重新描述任务让它从头实现。改比重写更耗时。5.5 常见问题速查表问题现象可能原因解决办法PRD 内容空洞代码结构混乱、注释少先整理代码结构或在指令里要求具体示例Git commit 混乱没有约定规范在.claude/instructions.md里写清楚规范测试跑不通环境或依赖问题按顺序检查 Node 版本、依赖、配置、环境变量代码跑偏任务描述太技术化改用用户视角描述任务重新实现智能体卡住上下文太长或任务太复杂拆小任务分批处理分支合并冲突工作区不干净操作前先git status和git pull6. 一些踩过坑之后总结的实操心得6.1 关于上下文管理Claude Code 的上下文窗口虽然大但也不是无限的。我的经验是每次对话聚焦一个任务任务完成后开新对话。不要在一个对话里连续做多个任务上下文会越来越乱智能体的表现会下降。如果任务确实需要参考之前的对话内容把关键信息保存成文件在新对话里让智能体读文件。6.2 关于代码审查智能体写的代码我建议至少做一次人工审查。重点看三个地方一是边界条件处理二是错误处理三是安全性相关的地方比如输入校验、权限判断。智能体在这些地方容易偷懒。6.3 关于迭代节奏不要追求一次跑通整个流程。我的做法是先用一个小功能比如一个简单的表单页面跑通全流程熟悉每个环节的操作和坑点然后再上大项目。这样试错成本低学到的东西也更扎实。6.4 关于工具版本Claude Code 和 pdlc-skills 都在快速迭代版本更新可能会带来行为变化。我的建议是在一个项目周期内锁定版本不要中途升级。等一个项目做完了再统一升级然后在新项目里验证新版本的行为。6.5 关于文档沉淀每跑完一个项目把过程中遇到的问题、解决办法、优化后的指令模板整理成文档。下次做新项目的时候直接复用这些文档效率会高很多。我自己的习惯是在项目根目录建一个docs/lessons-learned.md每次踩坑就记一笔。这个习惯看起来麻烦但长期来看回报很高。因为智能体工具的变化很快但如何组织工作流如何写清晰的指令如何管理 Git这些底层能力是通用的沉淀下来就是自己的资产。最后再分享一个小技巧如果你在 Windows 上跑 Claude Code 遇到虚拟化相关的报错检查一下系统的虚拟化功能有没有开启。这个报错跟 pdlc-skills 本身没关系是运行环境的问题开启之后就能正常用了。