用 Vibe Coding 做企业级高保真原型，可以用 brainstorming 澄清需求、writing-plans 拆解任务、frontend-design 完成界面，再用 webapp-testing 检查实际交互。把现成 Skills 与业务流程、界面规范、测试数据结合，分轮完成结构、视觉与状态，比只让 AI “做个高级后台”更容易得到可以评审的结果。以费用审批后台为例，最终应该能打开一笔“差旅报销 ¥1,280.00”，查看详情、填写意见、提交审批，并看见成功、失败、超时和重复处理时各自的反馈。
这类任务可以从墨刀 AI 客户端的本地项目开始：读取 PRD、设计规则和样本数据，先形成页面方案，再生成可运行预览。本文的“企业级”指包含多角色、业务状态和复杂交互的原型；用于评审的本地数据与角色切换不能代替正式系统的登录、权限和服务端实现。
这次要做出的原型长什么样
主画面是“费用审批”：左侧导航，顶部“待我处理 / 我已处理”页签，中间显示申请人、费用类型、金额、申请时间和业务状态的列表。点击一行，右侧打开详情抽屉，依次展示申请信息、费用明细、审批记录和当前可执行的操作。
业务流程只有四个阶段：申请人提交 → 主管审批 → 财务复核 → 归档。不要一开始加入预算管理、发票查验、支付和财务报表。先把一笔费用走通，再决定是否扩展。
| 角色 | 本轮操作 | 处理后发生什么 |
|---|---|---|
| 申请人 | 填写申请、提交；被退回后修改再提交 | 进入待主管审批，申请人继续查看进度 |
| 主管 | 查看负责范围内的申请，填写意见，通过或退回 | 通过后进入待财务复核；退回后交申请人修改 |
| 财务 | 查看待复核申请，通过或退回 | 通过后归档；退回后交申请人修改并重新走审批流程 |
先分清两个容易混淆的概念：“我已处理”是当前用户的工作视角，“已归档”是整笔申请的业务状态。主管审批成功后，这笔费用会进入主管的“我已处理”，但业务状态仍是“待财务复核”。如果 AI 把两者合并，页面看起来能操作，流程却已经画错。
先配置这组现成Skills，再准备项目材料
如果还不熟悉它们的分工，可先看原型设计 Skills 的选择与组合。本例只在对应步骤调用相关技能，不要求每轮同时运行整套技能。
本例使用下面这些公开 Skills，按各自仓库说明安装或加载，并保留依赖文件。规划、生成与检查分别选用，不需要在每一轮把所有技能一起调用。
| 阶段 | 现成Skill与入口 | 在本例中的任务 |
|---|---|---|
| 需求 | brainstorming | 只澄清审批角色和状态中仍不确定的部分 |
| 规划 | writing-plans | 将已确认的页面、数据与状态拆为实施步骤 |
| 高保真生成 | frontend-design | 在现有视觉约束内组织列表、详情与操作 |
| 界面检查 | web-design-guidelines | 检查生成代码的表单、焦点与反馈细节 |
| 浏览器走查 | webapp-testing | 操作本地预览，记录主流程及失败状态 |
| 发现错误后 | systematic-debugging | 复现问题并定位原因，不盲目重做页面 |
| 交付前 | verification-before-completion | 按实际检查结果说明完成情况 |
墨刀 AI 客户端可以读取本地项目材料并推进需求与生成任务；上述第三方 Skills 的直接调用，以已经按仓库说明加载它们的 Codex 环境为例。需要 Playwright 测试时，还要具备 Python、Playwright 和浏览器运行环境。若当前客户端没有对应 Skill，可以在 Codex 中完成规划与检查，再通过后文的墨刀 MCP 调用生成能力。
下面保留四份项目输入。其中 SKILL.md 是这个审批案例的编排文件，用来安排已安装 Skills 的调用顺序并附加业务规则；推荐的现成资源是上表中的实际项目。
第一步：准备四份可直接使用的输入文件
新建一个 expense-prototype 文件夹，将下面四份内容分别保存。它们把业务事实、视觉规则、数据和执行方法分开，后续修改其中一项时，不必推翻整套原型。
expense-prototype/
PRD.md
design-rules.md
mock-expenses.json
SKILL.md
outputs/PRD.md：用明确规则代替一句“做个审批后台”
# 费用审批原型
目标：让申请人、主管、财务走通一笔费用申请。
范围：申请列表、详情抽屉、新建申请、审批与退回。
不包含：真实登录、支付、发票查验、预算控制。
角色：
- 申请人：查看本人申请，新建；被退回后可修改再提交。
- 主管：处理分配给自己的待审批申请。
- 财务：本例约定可复核全部pending_finance申请。
- 申请人列表只显示applicantId等于当前用户ID的申请。
- 主管待办只显示managerId等于当前用户ID且为pending_manager的申请。
- 审批人的“我已处理”按history中actorId等于当前用户ID、
action为approve或return的记录筛选，不按角色或业务状态筛选。
角色切换同时切换身份：applicant→applicant-01，
manager→manager-01，finance→finance-01；具体用户见样本users。
新建申请绑定当前申请人ID；处理历史记录实际actorId及role。
演示角色入口不等于正式权限实现。
流程：
draft → pending_manager → pending_finance → archived
主管或财务退回 → returned
returned 修改并提交 → pending_manager
规则：
- 金额必须大于0，保留两位小数；合计来自费用明细。
- 退回必须填写理由；通过时意见可选。
- 提交中禁止再次提交相同审批动作。
- 明确失败时保留意见，允许重试。
- 超时且结果未知时先查询状态，不直接当作失败重发。
- 已被别人处理时刷新申请，不重复追加审批记录。
- 业务状态和“待我处理/我已处理”分开表达。
- “重置为流程起点”只重置EXP-DEMO-001：status=draft，
submittedAt=null，version=0，history=[]；保留ID、费用明细和金额，
切换至applicant-01。修改并提交该草稿，不另建同名申请。
- “恢复待审批样本”重新加载原JSON，供各异常路径单独演示。
完成标准：
能演示提交、主管通过、财务复核、归档；
能演示退回、明确失败、结果未知、重复处理和无权限。design-rules.md：让高保真先有秩序，再有装饰
# 费用审批界面规则
语言：简体中文，金额用人民币和两位小数。
风格：清晰、克制的办公后台，白底、浅灰分区、蓝色主操作。
字体：使用可用的中文系统字体，不依赖外网字体加载。
间距：以8px为基本单位；同级区域统一间距。
字号：正文14px，辅助信息12px，页面标题24px。
金额：右对齐并使用等宽数字，合计比明细更突出。
列表：先显示申请人、费用类型、金额、业务状态和操作。
详情：信息/费用明细/审批记录/操作区，顺序固定。
状态：文字与颜色共同表达，不只用颜色区分。
抽屉：宽屏从右侧打开；窄屏改为完整详情页。
按钮：同一区域只有一个主操作；提交中显示处理中。
演示控制：集中放在独立区域，不混入真实审批表单。如果团队已有组件库、品牌颜色和字号规范，用已有规范替换这份文件。要求 AI 沿用明确的样式约束，比“参考大厂、简洁高级”更容易获得一致结果。
mock-expenses.json：让页面从第一轮就带真实长度的数据
下列姓名和费用记录是供原型练习使用的样本。默认先展示主管待办：第一笔差旅报销的明细合计为 480 + 800 = 1,280 元；第二笔已进入财务复核。完整流程使用固定编号 EXP-DEMO-001：点击“重置为流程起点”将它恢复为草稿并清空历史，从申请人开始提交；异常演示则用“恢复待审批样本”重新加载下面的数据。
{
"users": [
{
"id": "applicant-01",
"role": "applicant",
"name": "林晓"
},
{
"id": "manager-01",
"role": "manager",
"name": "陈主管"
},
{
"id": "finance-01",
"role": "finance",
"name": "赵财务"
},
{
"id": "applicant-02",
"role": "applicant",
"name": "周宁"
},
{
"id": "manager-02",
"role": "manager",
"name": "吴主管"
}
],
"roleUserIds": {
"applicant": "applicant-01",
"manager": "manager-01",
"finance": "finance-01"
},
"currentRole": "manager",
"currentUserId": "manager-01",
"expenses": [
{
"id": "EXP-DEMO-001",
"title": "差旅报销",
"applicantId": "applicant-01",
"applicantName": "林晓",
"department": "产品部",
"managerId": "manager-01",
"status": "pending_manager",
"submittedAt": "2026-10-15 09:30",
"currency": "CNY",
"amount": 1280,
"items": [
{
"name": "城际交通",
"amount": 480
},
{
"name": "住宿",
"amount": 800
}
],
"reason": "客户需求访谈与现场沟通",
"version": 1,
"history": [
{
"role": "applicant",
"action": "submit",
"comment": "提交费用申请",
"actorId": "applicant-01"
}
]
},
{
"id": "EXP-DEMO-002",
"title": "项目资料印制",
"applicantId": "applicant-02",
"applicantName": "周宁",
"department": "运营部",
"managerId": "manager-02",
"status": "pending_finance",
"submittedAt": "2026-10-14 14:20",
"currency": "CNY",
"amount": 360,
"items": [
{
"name": "资料印制",
"amount": 360
}
],
"reason": "活动交付材料",
"version": 2,
"history": [
{
"actorId": "applicant-02",
"role": "applicant",
"action": "submit",
"comment": "提交费用申请"
},
{
"actorId": "manager-02",
"role": "manager",
"action": "approve",
"comment": "同意"
}
]
}
]
}SKILL.md：编排现成Skills，并附上审批项目规则
---
name: expense-prototype-workflow
description: 组织已安装的公开Skills完成费用审批原型。
---
# 本项目工作流
输入：PRD.md、design-rules.md、mock-expenses.json。
业务以PRD为准，视觉以design-rules为准。
缺少所需Skill或运行依赖时，先报告缺项。
调用顺序：
1. 有业务未知项时用brainstorming澄清。
2. 结构确认后用writing-plans拆解实施。
3. 用frontend-design实现已确认的页面。
4. 用web-design-guidelines检查生成的UI代码。
5. 用webapp-testing在浏览器检查主流程和异常。
6. 有可复现错误时用systematic-debugging修复。
7. 用verification-before-completion核对交付结果。
项目规则：
- 不连接真实业务接口，不使用真实人员或票据。
- 金额合计与明细一致，权限约束入口和操作。
- 失败保留意见；结果未知先查询；冲突不重复写历史。
- 主管已处理不等于整笔费用已归档。
- 角色切换同步用户ID，历史用actorId记录操作身份。
- 按PRD实现两种重置；整条主流程只操作EXP-DEMO-001。
- 保留输入原文件；输出写入outputs。
交付：页面说明、可运行预览、启动方式、
实际完成的检查和待处理问题。将这份项目编排文件交给客户端读取，并确认上表所需 Skills 已被实际加载。它负责说明“这个项目怎样用这些技能”，不替代公开 Skill 自带的脚本和参考材料。首次调用时，先让 AI 列出已读取的输入与可用技能。
第二步：先让 AI 输出结构，确认后再画高保真
在已能读取项目文件并加载上述 Skills 的客户端打开这个目录，第一次先整理结构。费用列表不需要把所有字段摊在一行，明细和审批历史适合放进抽屉；同样，主管与财务可以共享界面结构，但显示的待办与操作条件不同。
复制第一段任务指令：
读取本目录的 PRD.md、design-rules.md、mock-expenses.json 和 SKILL.md。先用 brainstorming 澄清尚未明确的审批规则，已给出的结论不要重复问；结构确认后，用 writing-plans 输出实施计划。先不要生成代码，输出费用审批原型的页面结构、角色操作表和状态转移表。主界面包含列表、待我处理/我已处理页签、详情抽屉和审批操作；检查主管已处理与业务已归档是否被区分。不要增加预算、支付或发票查验功能。把缺失规则单列，结构结果保存到 outputs/structure.md，保留输入文件不变。
看结构结果时，重点检查三件事：每个状态有没有下一步；每个按钮是否有角色和状态条件；退回再提交是否从主管审批重新开始。如果发现财务复核之前就归档，先改状态表，不要让 AI 在错误流程上继续美化。
第三步：生成能预览的 React 原型
结构确认后，再把视觉和交互一起交给 AI。这里选择 React，是因为需要共享列表与抽屉状态、切换角色、模拟请求结果，并让审批记录随操作更新。只想快速确认布局或简单交互时，也可以选择 HTML 原型；两种产物用途接近，但项目结构与运行方式不同。
复制第二段任务指令：
依据已确认的 outputs/structure.md 和四份输入文件，使用 frontend-design 形成页面实现方案，再生成费用审批高保真 React 原型。主画面展示“差旅报销 ¥1,280.00”，点击列表行打开详情抽屉；实现申请人、主管、财务的演示角色切换，以及提交、通过、退回、复核和归档。沿用 design-rules.md，不用无关装饰填满页面。用本地样本数据和可重置的模拟服务实现交互，不连接真实后台。演示控制区支持成功、明确失败、结果未知和已被他人处理，并实现PRD定义的“重置为流程起点”和“恢复待审批样本”。角色切换必须同步roleUserIds对应的用户ID，处理历史写入actorId，“我已处理”按实际处理人筛选。若产物为本地项目，放入 outputs/expense-app，提供 package.json、依赖说明、dev 启动命令及 README；若返回托管预览，则同时提供任务链接和可获取的产物信息。
拿到结果后先看它实际返回什么。若是托管预览，打开预览入口，等待页面加载后验证操作；若是可下载的项目，先阅读 README，按对应包管理器安装依赖并启动。采用上述约定的 npm 项目，通常从项目目录执行：
npm install
npm run dev打开终端返回的本地地址，不固定假设端口。若缺少 package.json、dev 脚本或入口文件，让 AI 补齐可运行交付物；不要把一张界面图片或一段 JSX 文本当成已经完成的预览。
第四步：把审批状态做完整，页面才真正可评审
高保真不只意味着配色和间距接近成品。审批后台最容易误导用户的地方，是提交后没有确定的结果，却把按钮恢复成可以继续点。下面这张表可以直接作为原型的状态约定。
| 发生什么 | 用户应该看见什么 | 下一步怎么走 |
|---|---|---|
| 点击通过，正在提交 | 按钮显示“处理中”，同一审批动作不能重复触发 | 等待明确结果，保留当前意见 |
| 请求明确失败，审批未生效 | 错误提示与重试入口，已填写意见仍在 | 修正问题或重试，不要求重新填写 |
| 等待超时，尚不清楚是否生效 | “结果确认中”，提供查询最新状态的操作 | 先查询；确认未生效后才允许重新提交 |
| 主管审批成功 | 提示“已通过，待财务复核”，移入主管的“我已处理” | 保留详情和审批记录，财务获得待办 |
| 另一人已经处理 | 说明申请状态已变化，并显示刷新后的状态 | 取消旧审批入口，不重复写入审批记录 |
| 当前角色不具备操作权限 | 按需要隐藏操作或说明不能处理的原因 | 仍按可见范围查看信息；不能绕过角色条件提交 |
在原型中，可以用模拟服务分别返回这几种结果。结果未知的场景尤其值得保留：例如先显示“确认中”，查询后得到“待财务复核”，就应按审批已成功更新页面，不能再提交一次。
重复审批还涉及列表与详情的一致性。主管打开抽屉时看到版本 1，如果模拟服务返回该记录已进入版本 2，应刷新记录、提示变化并停止旧动作。原型不必实现完整后台，但要把用户会看到的结果设计清楚。
如果只有托管预览、暂时拿不到源码，先在可访问的预览中检查操作路径，并记录尚未完成的代码检查；取得源码后再运行 web-design-guidelines。浏览器无法访问的路径，也应留下具体原因。
复制第三段迭代指令：
取得源码时，先用 web-design-guidelines 检查当前费用审批原型的UI代码；再用 webapp-testing 在可访问的预览中执行成功、明确失败、结果未知、并发冲突、无权限的路径。只有托管预览时，先完成可执行的浏览器检查，把代码检查记为待补。发现可复现错误时，用 systematic-debugging 定位原因并修复；保留已确认的导航、视觉和字段。失败保留审批意见；未知结果先查询；冲突刷新记录且不重复写入历史；主管通过后显示待财务复核，而不是已归档。修复列表、抽屉、页签计数和审批历史的同步。最后用 verification-before-completion 核对实际运行结果，在 outputs/interaction-check.md 记录改了哪些页面、已检查哪些路径及待确认事项。
第五步：用一笔 ¥1,280 的申请逐角色走通
不要只看 AI 的“已完成”文字。打开预览，点击“重置为流程起点”，确认 EXP-DEMO-001 已变为草稿、提交时间为空、历史为空，当前身份为 applicant-01。下面四步始终按这个编号查找，不再新建另一笔同名同金额申请。
- 申请人提交：以
applicant-01打开EXP-DEMO-001草稿，检查原有费用明细并提交。金额应保持 ¥1,280.00；状态进入待主管审批，历史新增actorId=applicant-01的提交记录。金额为空、为零或明细合计不一致时，应先给出对应提示。 - 主管通过：切换到
manager-01，打开编号EXP-DEMO-001的“差旅报销 ¥1,280.00”，填写意见并通过。成功后新增actorId=manager-01的通过记录，进入该主管的“我已处理”，业务状态是待财务复核。另一名主管的处理记录不能计入当前用户的页签。 - 财务复核：切换到
finance-01，按编号找到同一笔申请。金额、申请理由和主管意见应保持一致；通过后状态变成已归档，历史新增actorId=finance-01的通过记录，并进入该财务人员的“我已处理”。 - 回到申请人：切回
applicant-01，在本人申请中查看EXP-DEMO-001，能看到完整进度和最终状态，不出现属于主管或财务的审批按钮。
异常验证前，每次点击“恢复待审批样本”，以 manager-01 对 EXP-DEMO-001 单独检查：退回时未填理由是否被拦住；明确失败后意见是否还在；结果未知时是否先查询；切换无权限角色后能否从旧抽屉继续审批。对按钮没反应、标签没更新这类问题，向 AI 提供“当前角色、记录、操作步骤、实际结果、期望结果”，比只说“交互不对”更容易定位。
同时缩窄浏览器窗口，看看详情是否按约定成为完整页面，金额和操作是否仍可见。内容较长时应允许区域合理滚动，不要为了把所有信息塞进首屏而缩小字体。
已经在用 Codex？接入墨刀 MCP 复用同一份材料
这条路径把前面安装的 Skills 与墨刀生成能力接起来：Codex 在获得授权后读取材料、执行规划与检查技能，墨刀 MCP 负责发起生成并返回结果。Skills 本身不会因为配置了 MCP 自动安装，先确认技能和连接都可用。
先按墨刀 AI MCP 接入说明获取个人空间令牌，在启动 Codex 的环境中设置 MODAO_TOKEN。再在用户级 ~/.codex/config.toml 添加以下配置。这里只保存环境变量名称，不把真实令牌写进项目或文章。
[mcp_servers.modao]
url = "https://modao.cc/agent-py/ai/mcp"
env_http_headers = { "modao-token" = "MODAO_TOKEN" }重启或重新加载客户端后，通过 MCP 工具列表确认连接；使用 CLI 时也可运行 codex mcp list。如果使用的是桌面端，需确保启动该应用的环境能读取这个变量，不能只在另一个终端临时设置后就假定配置生效。
在 Codex 中发起任务：“读取本项目的四份输入文件和 outputs/structure.md，沿用 frontend-design 已确认的页面方案，使用墨刀 MCP 的 generate_react 生成费用审批原型，按已确认状态和界面规则执行。通过 get_task_result 获取任务状态与结果，返回预览、项目产物及后续可编辑方式。”如果这次需要的是 HTML 原型，将产物明确改为 generate_html。
生成结果支持导入时，可以调用 import_to_proto 继续编辑；应以返回结果支持的产物类型和导入结果为准，不能将“能生成 React”理解为任意 React 工程都能完整一键转成墨刀原型。MCP 也不等于自动读取旧原型或设计与代码双向同步。
第六步：把可运行预览变成团队能继续修改的交付物
当流程和状态验证完成后，再进入墨刀原型开展页面编辑与团队评审。采用可用的导入或打开方式后，先复查页面数量、核心控件和关键交互；本地预览与编辑器中的表现要分别确认，不能默认所有细节都会完全一致。
交付时放在一起的材料应有：本次原型或预览链接、四份输入文件、确认后的状态与权限规则、交互检查记录，以及仍未确定的问题。研发最需要知道的是“主管通过后为什么还没归档”“超时为什么不能直接重试”等具体决策，而不是一张缺少操作说明的漂亮截图。
下一轮增加预算控制或发票流程时，先修改 PRD 和 Skill 中对应的规则，再要求 AI 更新受影响的页面和状态。用清楚的输入维持每轮一致性，Vibe Coding 才能从一次性出图，变成能够持续推进的原型工作方式。
