"帮我做一个请假报销审批后台，界面简洁一点。"把这句话交给 AI，做出几张页面并不是什么难事。但难的是让申请、审批、驳回、再次提交能沿着同一套规则走下去。
下面借一个用墨刀AI客户端生成的"轻批·请假与报销审批台"的页面案例，拆开说说提示词怎么写、AI工具怎么选。这个示例展示了待审批列表、流程节点、请假申请表、报销明细表和结果通知等页面。
一、需求怎么写，AI 才知道要生成什么
审批后台最容易漏的是谁能点、点完流向谁、驳回后申请人能不能修改。第一轮提示词先交代角色、页面、主流程和交付范围，少写"高级感""功能完善"这样的形容词。
以这个案例为例，可以这样输入：
请生成一个请假与报销审批后台的可运行前端应用。角色先按申请人、直属主管、财务三类设计，实际审批权限和顺序如无材料依据，请列为待确认，不要自行定规则。页面包括待审批列表、流程节点、请假申请表、报销明细表、结果通知。先打通一条演示路径：申请人提交报销单 → 主管查看详情并同意或驳回 → 申请人查看结果。列表需能按请假/报销、待处理/已处理筛选，并能进入详情。请用明确标记的演示数据，交付可运行的前端项目、运行方法及尚未接入的接口清单。先列出你理解的页面与状态，再生成代码。
这段提示词并没有替公司决定报销额度、审批层级或请假天数，那些规则要从制度和真实流程里补。如果只是为了评审页面，可以先用演示数据；若准备进入开发，就要把字段校验、状态转移和接口来源另附一张表。看到列表里有"已超时"，还得追问：超时阈值是多少，谁收到提醒，超时后能否继续审批？没答案就先留空。
二、选 AI 生成应用工具，先看能否接着改
现在让 AI 生成一个产品页面 HTML 很简单，单页展示适合快速沟通视觉方向，但要做"应用"，我更关心页面之间的数据和状态能不能对上，以及生成结果能否继续作为项目维护。选 AI 生成应用工具时，可以拿同一段需求做一轮小测试：下载或打开前端代码，按说明运行，走一遍提交到审批的路径，再改一个规则，看列表、详情和通知有没有一起更新。
可以重点检查这几点：
- 交付的是完整项目还是只能预览的页面？
- 筛选、表单校验、驳回理由、返回修改等交互是实际执行，还是按钮点了只弹一句提示？
- 演示数据与真实接口有没有分界，后面替换数据源是否方便？
- 代码结构能否让人接手，而不是每补一个流程就重生成整页。
复杂链路通常需要多轮补充，第一版看起来齐全，并不代表业务已闭环。
这个审批后台的产研工具背景，让"申请表、审批列表、流程节点"这类页面组织方式比较贴近产品讨论场景，墨刀 AI 客户端可以处理本地项目文件，适合围绕已有项目继续迭代。不过具体业务规则仍要由人提供，生成后也要逐项验收。
如果目标主要是进入代码仓库继续开发，Codex 在读代码、改代码和运行验证上也很方便。不过界面可能出现不符合国内业务习惯的文案或视觉样式，可以补充本地设计规范与页面参考，比如有支持 MCP 的设计工具时，通过连接读取设计上下文，再让代码工具修改。
给两类工具同一条"驳回后允许修改再提交"的变更要求，看看谁能把状态、入口、文案和代码一起改对，选型会更有依据。
三、生成前先梳理需求，后面才能少返工
提示词写得再长，也补不出团队尚未决定的规则。所以 AI 开始生成前，我会先把提示词的结构压成：角色与权限表、状态流转表、字段与校验表。至少要让 AI 知道谁发起、谁处理、什么条件下结束，以及每个页面读写哪些数据。
也可以先用 AI 做整理需求，不急着让它生成页面。比如这版提示词：
我会提供现有流程说明、申请表字段和审批规则。请先整理成三张表：①角色能查看和执行的动作；②请假与报销单的状态、触发动作、下一状态；③字段名称、是否必填、来源、校验和展示页面。每条规则注明来自哪份材料。材料互相矛盾时并列写出；缺少审批顺序、额度、超时阈值等信息时标"待确认"。不要补造制度。最后列出会影响前端页面生成的五个关键问题，暂不写代码。
确认这三张表后，再发指令："按已确认的表生成可运行前端；先完成报销提交到主管审批这一条路径。请写明项目启动命令、各页面入口、演示数据位置、尚未接入的接口，以及仍需业务确认的规则。任何未确认规则不要写成确定文案。"这样拿到第一版时，能知道该从哪里查错。
在验收 AI 生成应用时要试试漏填必填项，驳回后重新提交，以无权限角色打开审批详情。表单有没有提示、状态有没有同步、按钮有没有被正确限制，能说明它是不是一个可继续开发的应用。预览页能展示到哪一步，就写到哪一步；后端接口、权限校验和通知送达需要另行验证。