AB
AB
AiBoss站

全部分类

教程

Claude

教程

用 Claude 分离提示词与实现会话完成业务系统开发

把「写提示词」和「写代码」拆成两个 Claude 会话，用模板化的实现提示词、禁止推测的规则、本地 mock 预览与细粒度 Git 提交，完成多页面业务系统开发。文中给出可直接套用的提示词模板、launch.json 配置、帮助文档与单元测试的委派方式，以及上下文溢出、改动范围失控等常见坑的应对办法。

用 Claude 做业务系统开发时，最常见的失败不是模型写不出代码，而是把「读懂需求」和「动手实现」塞进同一个会话里，导致上下文很快被填满、实现方向跑偏。本文要讲的是一套把这两件事拆开的工作方法：先在文档仓库里让 Claude 产出一份可复用的实现提示词，再在实现仓库里开一个新会话照着提示词写代码。Claude 在这里承担两个角色——设计阶段的「写提示词的人」和实现阶段的「写代码的人」，两者用一份结构化文档衔接。

这套方法适合已经在用 Claude 做实际项目开发、并且项目有需求文档或至少能整理出需求的人。它不依赖某个特定框架，前端页面、桌面应用、帮助文档、单元测试都能套用同一套流程。文中所有示例都基于一个虚构的「图书馆借阅管理系统」，页面名、函数名均为示例，请替换成你自己的业务对象。

准备工作

开始之前，需要把几样东西准备好，否则后面的模板会缺料。

  • 两个可访问的仓库：一个存放需求文档（需求定义书、页面清单、页面跳转图、数据库 schema），一个存放实现代码。两者分开是这套方法的前提，因为写提示词的会话不应该被实现细节干扰。
  • 页面素材：每个待实现页面的界面截图、页面项目清单（字段名、类型、必填与否、交互行为）。截图可以贴在对话里，项目清单最好整理成表格。
  • 本地可运行的 mock 环境：前端项目建议用 Vite 加 MSW（Mock Service Worker），这样后端接口还没就绪时页面也能跑起来，Claude 才能启动开发服务器并打开页面自查。
  • Claude Code 桌面应用：桌面版支持在项目里配置启动项，让 Claude 自己拉起 dev server 并在应用内浏览器打开页面。具体版本与功能可用性以官网当前信息为准。
  • 规则文件：每个仓库放一份 AGENTS.md 记录项目规则（技术栈、目录结构、「未经指示不新增第三方库」等），再放一份 CLAUDE.md 作为 Claude 的入口文件。

如果项目里还没有规则文件，建议先补上。规则文件的价值在后面「推测不让模型猜」和「限制改动范围」两节会体现得非常明显。

操作步骤

第一步：把写提示词和写代码拆成两个会话

这是整套方法里收益最大的一步。在文档仓库开一个会话，把需求定义书、页面清单、页面跳转图、数据库 schema 交给它，让它输出一份可以直接交给编码代理的实现提示词。提示词要明确要求输出在代码块里，而不是写成文件：

根据我贴上的页面截图和页面项目清单，为编码代理生成一份实现该页面的提示词。
不要写成 md 文件，直接放在代码块里输出。

之所以要强调「不要写成 md 文件」，是因为如果不加这句，Claude 常常会顺手在仓库里新建一个 Markdown 文件，你还得再去删。把输出限定在代码块里，复制粘贴更直接。

拆开之后有三个直接好处：实现会话从「规格已经整理好」的状态起步，不会花大量轮次去翻文档；提示词在动手之前可以被人工审阅，规格理解错了在这一步就能发现；提示词本身会留存下来，做相似页面时可以直接参考，例如「逾期费用计算参照『借出台账』的实现提示词」。

第二步：把实现提示词模板化

做过几个页面之后，提示词的结构会稳定下来。下面这份模板可以直接套用，把方括号里的内容替换成你的业务对象：

# 实现提示词：〇〇（页面ID 页面名）

## 委托内容
这个页面做什么，服务于什么业务。

## 作业推进方式
1. 动手前先调研实现仓库，掌握技术栈、目录结构、通用组件、API 写法。
   新库只有在现有能力无法实现时才允许引入。
2. 如果已有相似页面（例如其他检索弹窗），沿用其做法。
   相同逻辑要抽取复用，不要重复实现。
3. 缺少表或 API 时，先列出「在哪里加什么」的清单并报告，不要直接动手。
4. 属于「待确认事项」的地方不要自行决定规格。
   临时实现时留下 `TODO(要确认):`，并在完成报告中列出清单。
5. 计算逻辑与筛选条件必须附带单元测试。

## 参考资料
- 需求定义/〇〇_功能需求.md：对应章节
- 需求定义/〇〇_页面跳转图.drawio：跳转来源 → 本页面
- database/〇〇.sql：使用的表

## 页面布局
（用制表符画出的页面草图）

## 页面项目
| No | 项目名 | 类型 | 位置 | 行为 |

## 行为规格 / 输入校验 / 键盘操作

## 待确认事项
规格书无法确定的内容

## 验收条件

模板里最关键的是「作业推进方式」这一段，其中每一条几乎都对应一次踩坑后的补充：

  • 沿用既有做法：不写这一条，模型容易引入新库或自创写法，和项目风格割裂。
  • 抽取复用：例如「借出台账」和「逾期一览」的逾期费用计算来源相同，明确写出「复用借出台账的处理，不要重复实现逻辑」，可以避免两份算法各自演化。
  • 新增先列清单：防止模型擅自加 API 或加表。
  • 页面布局用制表符画草图：只给截图时布局理解容易偏，配一张用制表符画的线框草图，元素位置会稳定很多。

线框草图大致长这样，重点是标出元素相对位置和特殊状态：

┌ 读者选择 ─────────────────────────────┐
│ [读者检索 ] ← 黄色背景        [关闭] │
│ 编号 [        ]  姓名 [            ] │
│ ┌──────────────────────────────┐ │
│ │读者编号│姓名      │区分        │ │
│ │  ...   │          │            │ │
│ └──────────────────────────────┘ │
│ [确定]                                │
└──────────────────────────────────────┘

第三步：把「不许推测」写成硬规则

业务系统里最危险的情况是模型按常识编出一个看起来合理的规则。比如「逾期费用一天多少钱」「闭馆日算不算进逾期天数」，一旦由模型自行决定，页面能跑但业务是错的。因此每份提示词里都要固定写入下面几条：

  • 不明确的业务规则不要推测。
  • 实现、需求定义、测试三者冲突时，不要自行裁定哪个是对的。
  • 不清楚的地方单独记录：写代码时在代码里留 TODO(要确认):，并在完成报告中汇总；写文档时整理到 确认事项.md 并标注出处。

这样做的额外收益是：Claude 的完成报告可以直接当作「需要向业务方或专家确认的问题清单」使用。人工确认后，只需回一句「Q2 的检索部分请加一个检索按钮」就能继续推进，不需要重新解释背景。

第四步：配置启动项，让 Claude 自己打开页面

实现完成后，先让它把页面跑起来，而不是先去读代码。在项目里创建 .claude/launch.json：

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "mock-dev",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "dev"],
      "port": 5173
    }
  ]
}

同时开发多个仓库时，可以再加几份端口不同的配置（例如 5174、5176），避免端口冲突。配置好之后，直接说「我想确认页面，请启动起来」，Claude 会拉起 dev server 并在应用内浏览器打开页面。

看到页面之后，问题直接用聊天描述，不需要先定位代码：

  • 「借出明细、借出台账、逾期一览这三个页面，点关闭或返回时请回到菜单页面。」
  • 「目录显示了两次，请删掉第二个。」
  • 「点帮助链接页面没有切换。」

先看页面再读代码，把这个循环压短，是整套流程里最省时间的一环。

第五步：帮助文档分两段生成

面向普通使用者的操作手册同样可以交给 Claude，但要拆成两个阶段，否则它会顾此失彼：

  1. 生成 Markdown：读页面源码、需求定义书、场景测试，写出 Markdown 版帮助文档。
  2. 转成 HTML：把第一阶段的内容与实现对照修正，配上真实页面截图，输出 HTML 手册。

提示词里要把读者、写法、截图三方面的规则写细。可参考的片段如下：

为不熟悉系统的普通使用者编写页面帮助（操作手册），输出 Markdown。

■ 读者与文风
- 假设读者是第一次使用本系统的人。
- 避免专业术语和面向开发者的说明，用简短具体的表述。
- 按钮名、页面名、输入项名必须与页面实际显示一致。
- 操作步骤用编号，一步对应一个操作。

■ 内容结构
1. 本页面能做什么
2. 可用人群 / 操作前的准备
3. 页面打开方式
4. 基本操作步骤
5. 输入项说明（必填/选填、示例、输入限制）
6. 注意事项（保存、取消、删除的影响）
7. 遇到问题时的处理办法

实现或资料中无法确认的功能、限制、处理办法不要补充。
未实现的功能不要描述成可用功能。

■ 创建位置与改动范围
- 除 help 目录外不要修改任何文件。
- 不要在页面上添加帮助按钮，也不要改路由。

■ 完成时报告
简要报告创建的文件、覆盖的页面、无法参考的资料、主要确认事项。

■ 截图
- 拍摄开发/测试环境的真实页面，不要凭推测生成页面图像。
- 使用测试用虚构数据，不要拍到个人信息、机密信息、认证信息。
- 需要强调操作位置时，不要改变显示内容，叠加边框或编号即可。
- 因启动、登录、数据准备不足而无法拍摄时，不要伪造图片，报告所需准备。

其中「改动范围」和「不要伪造图片」两条最有效。Claude 会启动 mock 页面、操作浏览器截图、叠加红框和编号，再嵌入 HTML。如果截图条件不具备，它会如实报告缺什么，而不是编一张图。

第六步：把单元测试也按同样的方式委派

桌面端的老项目同样适用。以 .NET Framework 4.8 的 WPF 应用为例，先在一个会话里，把被测项目、通用作业规范（AGENTS.md）、内部 mock 库文档交给 Claude，让它生成一份「测试编写提示词」。产出的提示词通常包含：

  • 首先必读的资料（通用规范、mock 库 README、用法示例）
  • 可参考的既有测试项目，以及明确列出不能照抄的地方
  • 被测类清单与已确认的事实
  • 用 coverlet 统计覆盖率并输出 HTML 报告

测试写出来之后，不要笼统地说「提高覆盖率」，而是看报告点名函数：

当前整体覆盖率是 63%，请再提高一些。
UpdateLoanList() 的覆盖率是 25.97%，请提高这个函数的覆盖率。
请提高 SaveCategory() / MoveUp() / MoveDown() 的覆盖率。
之后用当前覆盖率输出 coverage.cobertura.xml 和 index.html。

点名具体函数比笼统要求整体提升更可控。遇到第三方 UI 组件的许可证校验导致页面类无法在测试中生成时，与其硬碰，不如问 Claude「许可证类问题的排查思路是什么」「在这里加调试能看出什么」，让它先给出调查方法。

第七步：Git 操作小步提交、集中开 PR

提交与 PR 也交给 Claude，常用说法只有两种：

请提交并 push。先不要开 PR。

请向 main 分支开 PR，用日语写明 issue-XX 的作业内容。

在合适的断点反复执行「提交并 push，先不开 PR」，等一组改动完整后再给出 issue 编号让它开 PR。提交信息和 PR 描述用团队通用语言书写，方便其他成员阅读。

第八步：区分 CLAUDE.md 与 AGENTS.md 的职责

两个文件不要混用。AGENTS.md 是项目规则本体，写技术栈、目录结构、「未经指示不新增第三方库」这类约束；CLAUDE.md 是 Claude 的入口，用 @AGENTS.md 引入规则本体，再根据应用类型切换要加载的文档：

# 通用设置
先确认 `APPLICATION.md` 中的应用类型。
- `with-login`：应用带登录页面的文档
- `no-login`：应用不带登录页面的文档
- 类型缺失或非法时，不要开始认证相关的实现

@AGENTS.md
@APPLICATION.md

另外，在 AGENTS.md 开头写上一句「本文件未经指示不得修改，可以提出改进建议」，防止规则文件本身被顺手改写。

一个完整示例

下面把流程串一遍，目标是在虚构的图书馆借阅管理系统里新增一个「读者检索弹窗」页面。

1. 在文档仓库开设计会话。 贴上弹窗截图、页面项目清单，并说明：

根据我贴上的页面截图和项目清单，生成实现该弹窗的提示词。
不要写成 md 文件，直接放在代码块里输出。

2. 审阅并补全提示词。 检查生成结果是否包含：委托内容、作业推进方式、参考资料路径、页面布局草图、页面项目表、行为规格、待确认事项、验收条件。把「作业推进方式」补成第二步给出的五条，并确认参考资料里的路径真实存在。

3. 在实现仓库开新会话。 把提示词整段粘贴进去，不要附加其他背景说明。此时会话从整理好的规格起步，不会再去翻需求文档。

4. 启动页面确认。 确认 .claude/launch.json 里已有 mock-dev 配置，然后说「我想确认页面，请启动起来」。页面打开后逐项对照：检索条件是否齐全、结果表格列是否与项目清单一致、关闭按钮是否回到菜单。

5. 用聊天修问题。 例如「点关闭后没有回到菜单页面，请修正」「读者编号列宽太窄，请调整」。每轮只提一到两个具体问题，改完再看页面。

6. 检查待确认事项。 让 Claude 汇总本次留下的 TODO(要确认):，例如「逾期读者是否允许借出」这类规格书没写清的点。人工确认后逐条回复，让它补实现。

7. 提交。 说「请提交并 push，先不要开 PR」。等这一批页面都完成后，再说「请向 main 分支开 PR，用日语写明 issue-XX 的作业内容」。

整个过程中，设计会话和实现会话互不干扰，提示词文件留在文档仓库里，下次做「馆藏检索弹窗」时可以直接参照。

注意事项

任务过大时上下文会溢出。 曾有一次把 26 个页面的帮助文档放进一个会话生成，对话自动摘要反复触发，即使启用了并行子代理，也很难追踪它当时在做什么。解决办法是把「生成 Markdown」和「转 HTML」拆开，并按页面分组切分会话。

不写改动范围，会改到无关文件。 有一次四个文件被改出数千行变更，只能整体回滚。此后每份提示词都固定写上「除〇〇以外不要修改任何文件」。

模板复用容易漏改。 把模板复制到另一个仓库时，参考资料路径和输出位置经常忘记替换，而 Claude 会严格按写的内容执行。建议把会变的部分（仓库名、输出位置、参考资料）集中放在模板开头，方便逐项核对。

dev server 起不来时先贴错误。 找不到 vite、帮助页不跳转、请求报错都很常见。把错误信息和页面状态原样贴过去说「请修好」，通常就能解决，不必自己先排查。

易变信息以官网为准。 桌面应用的功能范围、可用模型、配额与计费方式都可能调整，本文不给出具体数字，使用前请查阅官网当前信息。

返回