Pinxian Li上个月我接了一个内容站点的详情页改造需求。页面的路径大致是 /posts/[id]，但困难在于：不同内容类型下同一个 id 要展示完全不同的模块，还要带上阅读进度、收藏状态、上一篇下一篇、相关推荐，并且从列表页进入时要保持原有浏览位置。我不打算手写一堆散乱的 fetch 和 if 判断，所以直接用 Claude Code 来做。第一版提示词我只写了一句话：“帮我写一个动态路由详情页面。”结果它生成了一大坨看起来能跑、一联调就出问题的代码。
问题不出在代码生成能力上，出在提示词没有把“动态路由详情页”背后的复杂性描述清楚。后来我换了一种思路，把复杂页面当成一个“带多状态、有竞态条件、会反复进入和退出”的系统来描述，Claude Code 的输出质量和完成度立刻不一样了。这篇东西不是讲 Claude Code 怎么安装的，而是分享一套我梳理过后可以复用的提示词结构，专门解决“复杂动态路由详情页面”这一类需求。适合正在用 Claude Code 或同类 AI 编程工具做真实前端项目的人参考，尤其是那些已经发现“对话式写代码”一开始很惊艳、碰到复杂页面就失控的人。
1. 复杂动态路由详情页，为什么AI编程特别容易翻车
1.1 一句话需求只会换来AI的“自由发挥”
我见过很多朋友给 Claude Code 的原始提示词是这样的：“帮我写一个商品详情页，路由是 /products/[id]，要有轮播图、SKU选择、推荐商品、规格参数，接口你自己猜一下就好了。”这句话信息量其实很低，但 Claude Code 在对话式界面里很容易给人一种“它懂了”的错觉。
它确实会给你一个看起来结构完整的详情页页面，文件、组件、样式全都生成出来了。问题会在你真正接入接口后集中爆发：接口字段是 productId，页面里用的是 id；详情页从列表点进来需要保留滚动位置，但这个组件在路由切换时被整个卸载了；用户在 /products/123 和 /products/456 之间跳转时，组件并没有重新挂载，但里面的数据请求逻辑还在用旧 id，最后页面出现两三个不同商品来回闪烁。
这些不是 Claude Code 能力不够，而是它只能根据你给的信息做“最可能的推测”。你不告诉它动态路由详情页的真正约束条件，它就按照通用模板给你拼一个。站在它的角度看，一句话需求代表你的需求就是“做个能看的页面”，不是“实现一个可用的入口页面”。这是第一层翻车原因。
1.2 详情页真正复杂的地方不在“页面长什么样”，而在路由之外的副作用
很多人以为详情页的复杂度在 UI：头部漂亮、模块丰富、交互点多。但实际上详情页开发最容易出 bug 的地方几乎都和路由参数的生命周期有关。
直接说几个真实场景。用户从文章列表进入 /posts/123，然后侧边栏又推荐了 /posts/456，点击后浏览器 URL 变了，页面组件却没有被销毁重建。此刻页面里如果有模块依赖“当前文章的 id”去请求数据，那它的 useEffect 依赖项必须正确响应参数变化。再比如用户在详情页多次点击“重新加载”，结果前一个慢响应比后一个快响应晚回来，把后一个正确结果覆盖了，这种竞态条件在接口慢的时候特别明显。
还有一类隐藏问题：详情页标题、分享链接、二维码内容都依赖当前 URL 中的路径参数，必须同步变化。如果 Claude Code 只把它理解成“一个普通的详情展示页”，那我上面说的任何一个细节它都想不到。因为它没有能力自动知道你页面上有哪些东西和 URL 参数强绑定，只能靠提示词把这类约束写清楚。
1.3 动态路由详情页的本质是一个“参数状态机”
我自己最常用的一套理解方式，是把动态路由详情页看成一个由 URL 路径参数驱动的状态机。当前路径是 /products/[id]，整个页面状态就包括：当前 id 是什么、上一次 id 是什么、当前请求处于 loading 还是 error 还是 success、页面滚动位置是否应该保留、如果 id 不存在要不要显示 404、从当前页跳转到另一个同类型详情页时哪些模块需要重置。
当你在提示词里用这个角度描述问题时，Claude Code 生成的代码逻辑会发生两个明显变化。第一，它不会把数据请求直接散落在页面组件里，而是会考虑一个更合理的请求状态容器。第二，它会为“路由参数变化”这个事件单独设计一套处理逻辑，而不是让组件只匹配第一次进入。
提示词工程到这个阶段，就不是为了让 AI 少改几行代码，而是让它理解系统边界。复杂动态路由页面的系统边界恰恰是：参数变了，整个页面的状态要如何清理和重建；参数没变，哪些模块的缓存可以继续使用。我希望你也能把 Claude Code 当成一个需要做系统设计合作者，而不是只会补全代码的生成器。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。