用Claude Code预检美容与健康初诊表单: 在提交前挡住同意和禁忌遗漏

第一次到店表单里写着“皮肤敏感”“怀孕中”“正在服药”，但导出的CSV把这些内容塞进一个普通备注栏。预约已经成立，顾客也到了店里，员工才发现需要暂停、换菜单、重新说明取消条件，甚至改期。美容沙龙、身心调理、放松护理和私教体验课，很多时候先要修的不是华丽页面，而是这个小小的输入事故。

把表单做得很长并不能解决问题。问题问得太多会让用户离开，收集来的信息如果没有指定审核人，也只是换一种混乱。实务上的目标，是在AI参与前，把预约字段、同意字段、禁忌类别、员工专用信息分开。这里的禁忌，是指健康状态、服药、怀孕、皮肤状态、年龄等可能影响服务是否继续的条件。

本文介绍一个用Claude Code做本地preflight的流程。它是提交前检查和本地契约检查，不是在线集成。它不会连接表单服务、预约系统、客户数据库或邮件发送。本文确认过的官方来源包括Claude Code的权限设置、设置与sandbox、日本个人信息保护委员会的个人信息资料、日本厚生劳动省美容场所卫生管理资料，以及日本消费者厅关于美容医疗注意事项的页面。本文不提供个别法律、医疗或经营判断。

要点

• 初诊表单要分成预约所需字段、员工复核字段、不得进入AI工作CSV的字段。
• Claude Code只读取虚构数据或脱敏CSV，用来检查同意、禁忌类别、复核标记和消息草稿。
• 人来判断服务是否继续、健康信息处理、同意文案、个人信息、未成年人同意、退款和取消规则。
• 三个Use case是表单字段盘点、CSV列预检、员工确认消息草稿。
• 主CTA只指向给初学者复用的产品模板。

业务流程: 在AI读取前拆分表单

先拆分文件夹和表。intake-raw/ 保存原本，包括姓名、电话、邮箱、皮肤和身体自由描述、服药、怀孕、未成年人同意、照片使用、付款相关信息。intake-ai-work/ 保存AI工作副本，只放虚构ID、希望菜单、到店目的、同意状态、禁忌类别、是否需要员工复核。intake-approved/ 保存员工确认后的检查表和回复文。

资料	AI工作副本	仅员工查看
预约表单	希望菜单、到店目的、初次/复访	姓名、电话、邮箱、地址
初诊问题	禁忌类别、注意类别	诊断名、药名、详细体况
同意文	是否同意、日期、必填/选填	最终法律和运营文案
CSV导出	列名、空值、员工复核标记	可识别本人信息和原始自由文本
员工检查	审核人、停止条件、时间点	服务可否、菜单调整、退款判断

flowchart TD
  A[intake-raw 原本] --> B[列分类]
  B --> C[脱敏成AI用CSV]
  C --> D[Node.js preflight]
  D --> E[Claude Code查缺口]
  E --> F[员工复核]
  F --> G[intake-approved 检查表]

关键习惯是不要让Claude Code“全部读完然后判断”。先减少列。自由描述里经常出现姓名、健康细节和家庭关系，AI文件最好只保留 sensitive_note_present: true 这样的标记。需要判断时，由员工单独打开原本。

Claude Code负责什么，人来判断什么

Claude Code负责发现缺失字段、危险CSV列名、同意标记遗漏、员工复核标记遗漏，以及给员工或顾客的草稿文案。例如“初次体验表单有没有照片使用和取消同意”“有禁忌类别的行是否设置了staff_review”，这类检查适合交给它。

人负责决定服务是否继续、菜单如何改、健康或服药信息如何处理、未成年人同意、退款、取消、广告和效果表述、个人信息处理。Claude Code输出“没有明显问题”，也不能等同于可施术。美容与健康领域里，安慰性文字很容易变成断言，所以最终批准必须由人完成。

Claude Code官方权限页面说明，规则按deny、ask、allow顺序评估。设置页面说明，sandbox为Bash命令和子进程提供文件系统与网络边界。处理初诊原本时，拒绝 Read(/intake-raw/**)，只允许读取 intake-ai-work/。这不是安全证明，而是缩小错误入口的工作脚手架。

相关站内文章可参考Claude Code权限指南和美容沙龙菜单说明流程。表单和菜单要分开检查，因为它们出错的位置不同。

三个Use case

Use case 1: 盘点初诊表单字段

输入: 表单字段清单、必填/选填、希望菜单、同意文、照片使用、取消条件、需要员工复核的问题。

输出: 预约字段、员工复核字段、排除出AI的字段、面向初次顾客的短说明、提交后的提醒文。

人工确认: 服务可否、禁忌处理、未成年人同意、照片使用、取消和退款条件、同意文最终表述。

字段盘点先从“要删除什么”开始。如果初次体验表单的目的只是预约时段，深入健康问诊可以放到员工后续确认。如果某些条件必须在服务前确认，就要在顾客到店前产生复核标记。

Use case 2: 检查CSV是否混入危险字段

输入: 脱敏CSV列名、样例行、必填列、员工复核标记、发送前规则。

输出: 允许列、阻止列、空值警告、需要 staff_review 的行、员工接下来要看原本的字段。

人工确认: 姓名、电话、邮箱、地址、原始自由文本、药名、诊断、怀孕、未成年人、本人同意、照片使用。

CSV导出比表单画面更容易隐藏失败。管理画面里的“备注”导出后可能变成一个 note 列。Claude Code读取前，先用本地检查阻止危险列名和简单危险值。

Use case 3: 生成员工确认消息草稿

输入: 虚构ID、希望菜单、确认类别、预约时间段、负责人、回复期限、门店常用联系渠道。

输出: 员工确认邮件、给顾客的到店前确认文、确认清单、不得发送的信息列表。

人工确认: 收件人、顾客真实姓名、实际健康信息、服务判断、取消条件、退款说明、负责人批准。

消息草稿不让AI填入真实个人信息。用“顾客A”或“预约B-001”起草，发送前由员工看原本。语气温和有帮助，但判断责任仍留在门店。

可复制使用的提示词

此提示词只读取 intake-ai-work/intake-redacted.csv。不要加入原始表单、客户记录、档案、照片或付款数据。

Act as a beauty and wellness first-visit intake form reviewer.
Read only ./intake-ai-work/intake-redacted.csv and output in this order:

1. Columns that may be used by AI and columns that must be stopped
2. Missing consent, photo permission, and cancellation fields
3. Whether rows with contraindication categories have staff_review
4. Fields staff must check in the original record
5. Draft pre-visit confirmation message to the guest
6. Pre-publication checklist

Constraints:
- Do not decide service eligibility, medical issues, or refunds
- Do not infer name, phone, email, address, diagnosis, medication, pregnancy week, or raw free-text notes
- Do not touch intake-raw, customer databases, booking systems, email sending, or external networks
- If you detect personal-data-like values, stop and report only the field name
- End with: "Not sendable before staff review"

可运行检查代码

如果引入这个辅助文件，保存路径是 tools/check-beauty-intake-preflight.mjs。本文不会在仓库中创建该文件。下面是完整内容，测试只使用虚构本地fixture。

const files = [
  {
    path: "intake-ai-work/intake-redacted.csv",
    text: "intake_id,menu,consent,contraindication_category,staff_review\nB-001,trial_facial,true,sensitive_skin,true"
  },
  {
    path: "intake-ai-work/bad.csv",
    text: "name,email,medication_note\nAiko,[email protected],blood pressure medicine"
  }
];

const blockedFields = [
  "name",
  "email",
  "phone",
  "address",
  "birthdate",
  "medication",
  "diagnosis",
  "pregnancy_week",
  "free_note"
];

const valuePatterns = [
  /[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}/,
  /\b\d{2,4}-\d{2,4}-\d{3,4}\b/,
  /\b(?:medicine|diagnosis|pregnant|allergy)\b/i
];

const findings = [];

for (const file of files) {
  const lowerText = file.text.toLowerCase();
  for (const field of blockedFields) {
    if (lowerText.includes(field)) {
      findings.push({ path: file.path, type: "blocked field", field });
    }
  }
  for (const pattern of valuePatterns) {
    if (pattern.test(file.text)) {
      findings.push({ path: file.path, type: "blocked value", pattern: String(pattern) });
    }
  }
}

console.table(findings);
if (findings.length > 0) {
  process.exitCode = 1;
}

这段代码只证明固定fixture里能检测危险列名和简单值。它不证明PDF、图片、手写内容、多列组合再识别、真实表单集成或预约系统行为。

{
  "permissions": {
    "deny": [
      "Read(/intake-raw/**)",
      "Edit(/intake-raw/**)",
      "Read(/customer-records/**)",
      "Edit(/customer-records/**)",
      "Bash(git push *)"
    ],
    "allow": [
      "Read(/intake-ai-work/**)",
      "Edit(/intake-ai-work/**)",
      "Bash(node tools/check-beauty-intake-preflight.mjs *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["./intake-raw", "./customer-records"],
      "denyWrite": ["./intake-raw", "./customer-records"]
    }
  }
}

Pitfall: 常见原因和具体修正

第一个原因是把同意做成最后一个很小的复选框。顾客不知道同意了什么，员工也追不到文案更新时间。修正方法是把照片使用、取消、健康确认、联系方式分开，并导出同意文版本或更新时间。

第二个原因是只用自由文本收集禁忌。自由文本看起来灵活，但很难搜索，也不适合交给AI。修正方法是建立类别字段和 staff_review 标记，把详情留在原本。

第三个原因是认为Read拒绝就够了。Bash、子进程和本地辅助工具可能成为读取原本的另一条路径。修正方法是叠加Claude Code deny、sandbox的 denyRead 和 denyWrite、文件夹操作，以及用虚构数据做拒绝测试。

第四个原因是用真实预约CSV测试验证器。终端历史和日志可能保留值。修正方法是允许样例和拒绝样例都只用虚构ID，生产日志不要输出检测到的个人值。

小型ROI测量

最初两周只看初次体验表单。变更前记录预约后的确认电话数、当天菜单变更数、同意说明卡住的件数、员工重新打开原本的件数。变更后记录同样项目，再加上preflight挡下的CSV行数。

计算可以很简单: 件数 × (确认分钟 + 当天返工分钟) 与 preflight拦截件数 并排。预约增加但当天变更也增加，说明表单没有调整预期。到店前确认增加但当天中止减少，流程可能有价值。不要编造结果，只比较同一期间的同一字段。

常见问题

Q. 删除所有健康和服药问题是否更安全？

不是。删除必要服务确认会提高现场风险。目标是减少AI看到的列，同时保留员工必须复核的字段。

Q. Claude Code权限足以处理个人信息吗？

不要单独视为足够。权限只是tool边界，还要结合sandbox、文件夹分离、不输出值的日志和员工复核。

Q. 美容医疗式效果表达也能让Claude Code修改吗？

可以生成警告和审查笔记，但医疗广告和法律审查不在本文范围。效果断言要由人对照一次信息和门店规则确认。

Q. 应该从哪个表单开始？

从初次体验、照片使用、取消条件和健康确认混在一起的表单开始。当天确认最多的表单，通常比流量最大的表单更适合先修。

产品模板

这个preflight可以作为小型初学练习。先做一个虚构CSV，确认危险列会停止，确认缺少 staff_review 时能看见，确认输出写明员工确认前不可发送。

如果想把同样模式用于菜单说明、FAQ、回复草稿和发布前检查，可以把产品模板作为唯一下一步。相关的美容沙龙菜单流程处理价格和时间说明，权限指南处理访问控制基础。

实际测试结果

本文确认了 /images/hero/hero-024.webp 存在于 site/public/images/hero/hero-024.webp。还确认了Claude Code权限页面、设置与sandbox页面、日本PPC个人信息页面、厚生劳动省卫生管理资料、消费者厅美容医疗注意事项页面。

JavaScript代码只把虚构的 intake-ai-work/intake-redacted.csv 和 intake-ai-work/bad.csv 表示为内存数组。它展示的是字段名和简单值的本地fixture边界。没有运行表单服务、预约系统、客户数据库、邮件发送或真实客户数据测试。发布前检查对象包括slug、frontmatter、内部链接、外部链接、CTA、代码围栏、十个语言文件和Qiita文章。