让 Codex 读懂已有墨刀原型，关键是连接墨刀 MCP 后，先定位项目，再读取页面与画布目录，最后逐个读取目标画布的布局、文字、组件和交互。拿到结构信息后，再让 Codex 整理页面职责、操作路径和交互说明；遇到没有画出来的业务规则，就留下待确认问题，不靠一张界面猜出完整需求。
这条路线适合接手旧项目、准备原型评审或补写交接文档。它和“给 AI 一句话，让它生成一套新原型”不同：输入已经存在，工作重点是读准、对应和解释。可以先从墨刀 AI MCP连接当前账号，再用下面的分步指令处理一个范围清楚的预约项目。
已有原型里，哪些信息值得让 Codex 来读
一张截图能展示视觉，但不一定告诉你控件属于哪个画布、按钮连向哪里、页面是否还有其他状态。结构化读取则有机会把目录、控件、文案和已设置的交互放在一起。对接手者来说，最有用的不是一段“整体设计清晰”的评价，而是能回到原型核对的答案：有几个页面、每页负责什么、关键操作怎样走、哪些规则还没有依据。
| 要回答的问题 | 主要依据 | 适合形成的结果 |
|---|---|---|
| 项目有哪些页面和状态 | 页面、画布目录 | 按任务组织的页面清单 |
| 某页显示哪些字段和操作 | 画布文字、组件、布局 | 字段与控件清单，附对应画布 |
| 点击后会发生什么 | 当前读取结果中的交互设置 | 触发操作、目标位置、已观察到的行为 |
| 读者能否理解当前界面 | 画布图像与结构信息一起看 | 具体到控件的歧义与改进建议 |
| 真实系统应该怎样扣费或分配权限 | 经确认的PRD、接口或业务规则 | 与页面相对应的补充规则，不能只从外观推断 |
这里要分清两件事：墨刀 MCP 负责把支持范围内的原型信息提供出来，Codex 负责组织、解释并继续处理材料。get_proto_details 是只读能力，不会直接修改画布，也不是一条将原型变成生产代码的命令。若目标是选择从零生成的工具链，可以另看AI 原型工作流组合；本篇继续处理已经存在的设计。
先完成连接，并确认读取的是谁的项目
先在墨刀 AI 头像菜单的“令牌设置”中创建个人空间令牌，再按官方接入页配置 Codex。令牌应由你在本机安全保存。下面配置引用环境变量 MODAO_TOKEN，不包含真实令牌；该变量需要在运行 Codex 的环境中可读取。
[mcp_servers.modao]
url = "https://modao.cc/agent-py/ai/mcp"
env_http_headers = { "modao-token" = "MODAO_TOKEN" }配置通常位于 ~/.codex/config.toml。如果正在使用桌面端，注意终端里临时设置的变量不一定会传给已经运行的应用；应按自己的启动方式设置环境后重新启动。Codex CLI 可通过 codex mcp list 查看服务，会话中也可查看 MCP 状态。完整设置可参照墨刀 MCP 连接教程与文末官方文档。
先查询墨刀账号状态，确认当前连接的账号与默认个人空间。然后列出当前可用的原型读取工具。不要新建任务、不要生成页面，也不要修改任何项目。
当前官方说明中，list_created_prototypes 查找的是当前账号本人创建的 proto2 原型，可以跨本人所属空间筛选，但不是列出所有能访问的团队文件。找不到项目时，先检查创建者、原型类型、账号和筛选条件，不要立刻认为文件丢失。能打开分享链接，也不等于它必然出现在这个查询范围里。
连接问题与项目范围是两类问题：前者检查地址、HTTP 传输、modao-token 请求头及令牌状态；后者检查项目是否符合查询条件。先用账号状态做只读验证，能减少反复试生成任务造成的混乱。
第一步：定位项目，先读目录，不急着总结整套业务
以下用“预约管理”作为练习项目名。你可以换成自己的项目，但应先圈定一条路径，例如“用户查看预约后修改时段”。本轮只看预约列表、预约详情、改期弹窗和确认页；先不把支付、会员或运营后台一起混进来。
查找我创建的“预约管理”原型。若有多个同名结果，列出项目名称、所属空间、更新时间和可用于区分的项目标识，让我选定。选定前不要读取所有项目，更不要新建同名原型。
找到项目后，保留返回的项目标识 project_cid。它用来请求目录；页面或画布的 target_key 要从目录结果中取得，不能用你猜的页面名称代替。一个目录中的页面可能容纳多个画布，页面名称和画布标识也不能混用。
读取选定项目的页面与画布目录。按原始名称列出页面、画布及对应标识，暂时不要评价设计。找出与“查看预约、修改时段、确认改期”有关的画布；有名称相近或无法判断的项，单独列出供我选择。
目录阶段只需要得到一张能定位的表。为了阅读方便，你可以给目标画布分配 P-01、P-02 等本地说明编号，但要保留原始名称与真实标识的对应关系。P-01 是交接文档中的编号，不是 MCP 自动返回的固定字段。
| 文档编号 | 练习中的画布名称 | 本轮任务 | 操作时填写 |
|---|---|---|---|
| P-01 | 预约列表 | 找到要改期的预约 | 目录实际返回的标识 |
| P-02 | 预约详情 | 核对日期、时段及联系人 | 目录实际返回的标识 |
| P-03 | 改期弹窗 | 选择新时段，确认或取消 | 目录实际返回的标识 |
| P-04 | 改期确认页 | 看清改期结果与下一步 | 目录实际返回的标识 |
如果原项目没有 P-03 对应的独立画布，先记录它可能在详情页内用弹层或状态表达，再读取相关画布检查。不要为了凑齐表格而添加一张页面。目录结构忠于原文件，文档结构则可以围绕任务重新组织。
第二步：逐个读取画布，把字段、操作和跳转分开整理
先读取预约详情，确认读到的内容确实属于当前目标。可以要求 Codex 保留原文控件名称，再按用途分类；不要一上来就把所有文字改写成“标准 PRD”，否则原型和文档之间容易失去对应关系。
用目录返回的目标标识读取“预约详情”画布。整理四类内容：①页面标题和主要信息；②输入或可选控件；③按钮与链接；④读取结果明确包含的交互。每项保留原始名称和可回查的画布/组件位置。没有返回的交互写“本次结果未提供”，不要补成默认行为。
例如，读到“预约日期”“预约时段”“联系人”和“改期”按钮，可以确认界面表达了这些信息；但它还没有证明“任何人都能改期”或“开场前两小时不可更改”。后两项是业务规则，需要原型中明确的状态、交互条件或另行提供的说明。
接着读取改期弹窗与确认页。重点检查原页面的信息怎样被带到下一步：改期时是否还能看到原来的日期；取消后回到哪里；确认页是否区分“改期成功”与“提交改期申请”。画布之间名称相似，只能作为查找线索，不能当作已经连通的证据。
请围绕“修改预约时段”整理路径：
起点：预约列表里选中一条预约。
逐步检查：进入详情 → 打开改期 → 选择新时段 → 确认。
对每一步分别写：读取到的操作、明确的目标、实际提供的条件、缺失信息。
补查取消与返回分支；不要因为没有看到失败状态就判断系统不会失败。
所有结论都附原始画布名称；需要业务规则才能判断的部分放到待确认列表。如果一次返回内容过多，就按画布分轮读取，并保存已经确认的目录表。大项目不必每轮从头读所有页面；处理哪个任务，就刷新哪个任务涉及的画布。文件更新后先核对名称和目录，旧的标识与说明不要不加检查地沿用。
第三步：把结构与画面一起看，避免“文字齐全却理解错”
结构读取适合找字段和连接关系，画面适合判断布局与视觉含义。比如“取消”既可能是关闭改期弹窗，也可能是取消整个预约；只看文字，容易误判。应结合按钮的位置、所在容器、周边说明和明确交互一起理解。
需要看画面时，可用目录取得的 project_cid 和 canvas_key 调用 export_proto_to_png，导出指定画布。按当前官方说明，它每次导出一张画布，返回图片链接及有效期，不是把整个项目一次打包。结构中的目标标识与导出需要的画布标识应分别使用实际返回值，不能凭名字互换。
导出选定的“预约详情”画布为 PNG，告诉我返回链接及有效期。将图像与刚才的结构摘要对照：区分“改期”“取消预约”“返回”三个动作；发现视觉含义与已读取交互不一致时，列出具体位置，不自行改原型。
三种情况值得优先记录：画面中有按钮，但读取结果没有明确目标；交互存在，但用户难以看出这是可以操作的入口；相同文案在不同位置承担不同动作。把这些写成“在哪里、当前是什么、需要确认什么”，比给整个项目打一个笼统分数更便于讨论。
第四步：生成交互说明，让每一句都能回到原型核对
读完目标画布后，再要求 Codex 生成文档。说明表不必把每个装饰元素都列一遍，应覆盖完成当前任务所需的动作、条件、反馈和异常。更详细的写法可参照AI 生成交互说明文档；这里重点是保留从原型到说明的来源对应。
根据本轮已读取的预约原型，生成 Markdown 交互说明。
列：画布与位置、用户动作、前置条件、界面变化、下一步、依据、待确认项。
规则：
1. 只把读取结果或我提供的业务材料写成已确认信息。
2. “建议补充”和“原型已表达”分开，不把建议写进当前行为。
3. 字段名、按钮名与原型保持一致。
4. 取消、失败、重复提交、时段已占用分别判断是否有依据。
5. 另给一份交接摘要：目标、范围、已确认路径、未决问题、关联画布。
不要改动原型，不生成新的页面。下表展示预约练习应怎样组织说明。它是填写方式，实际项目里每格都应替换为读取结果；尤其不能把“期望的正确行为”直接写成原型已经做到。
| 动作 | 原型中需要核对 | 没有依据时的写法 |
|---|---|---|
| 点击“改期” | 入口是否可见、目标画布或弹层、原日期是否保留 | 入口已显示，打开后的目标尚待核对 |
| 取消改期 | 是否只关闭弹层，原预约是否保持不变 | 本次读取未提供取消后的状态 |
| 确认新时段 | 何时显示处理中，完成后显示什么结果 | 已找到确认操作，提交期间行为未表达 |
| 新时段被占用 | 冲突反馈、保留输入、重新选择入口 | 需要确认占用规则并补充冲突状态 |
把文档中的每条确定性表达反问一次：“这是从哪里读到的？”能指向某个画布、组件或规则材料，才继续保留为事实；只有模型推断时，改为建议或待确认。对业务缺口的处理应具体，例如“预约开始前多久不能改期”，不要只写“完善业务规则”。
第五步：核对一条完整路径，再把材料交给同事
结构分析之后，仍应在原型预览里走一次当前任务。先从列表打开目标预约，再进入详情与改期，检查确认与取消是否按说明运行。发现文档与预览不同，先记录差异，不急着判断是设计错还是读取信息不完整。
可以把四份轻量材料留在同一个项目目录：
- 页面目录：原型链接、原始画布名称与本地编号，帮助同事定位。
- 交互说明：围绕本次路径整理的动作、条件、反馈与依据。
- 待确认问题：例如改期截止时间、时段占用判定、失败后保留哪些输入。
- 版本记录：这轮读取的时间、范围与后来发生的改动；记录实际检查，未走过的路径不标通过。
一次可用的交接并不是生成了一篇很长的 PRD，而是接手者能找到对应页面、复述主要行为，并知道哪些问题仍要问谁。例如“改期失败后重新选择时段”可以由设计与研发共同核对；“是否允许跨门店改期”则先由产品或业务负责人确定。
读取遇到问题时，按哪一层排查
| 现象 | 先检查 | 下一步 |
|---|---|---|
| 连接后没有原型读取工具 | 是否加载当前服务工具列表 | 刷新或重启客户端，与官方目录核对 |
| 查不到项目 | 账号、创建者、proto2类型、关键词范围 | 放宽筛选或确认项目归属，不重复建项目 |
| 读到不相关页面 | 选中的项目、页面与画布标识 | 重新取目录，按实际标识定位 |
| 只有文案，无法确定交互 | 本次返回是否提供相应交互与目标 | 结合画布和预览核对，缺失部分留待确认 |
| PNG链接过期 | 返回的有效期 | 按当前权限重新导出，不把临时链接长期贴进交接材料 |
| 原型修改后文档不一致 | 本次读取时间与受影响画布 | 刷新相关画布并只修订受影响说明 |
“原型读不到”不应该通过多生成一个新原型来解决；“业务规则没画出来”也不能通过让 AI 多写几段话来填平。把连接、范围、目标、信息完整性分层检查，通常更容易找到下一步。
下一次需求变化，怎样继续使用这套材料
假设后来预约规则改变，允许用户一次调整日期与人数。不要让 Codex 重写整套交接文档。先提供变更说明，刷新预约详情、改期与确认画布，再比较涉及的字段、条件和反馈；列表没有变化，就保留原来的说明。
本次只增加“改期时可调整人数”。重新读取相关画布，与上一版说明对照。分别列出已发生的变化、仍未表达的规则、需要业务确认的事项。保持其他页面编号和已确认内容不变，不修改原型，也不要把未读取到的状态写成已完成。
从一条短路径开始，会比直接要求“读懂整个产品并生成完整 PRD”更实用。读者第一次操作的目标可以很简单：找到自己的原型，读出一个画布，核对一个按钮，再形成一段同事能回查的说明。跑通之后，再逐步扩大到模块交接和版本差异。
配置与能力范围参考：OpenAI MCP 配置文档。原型工具的具体支持范围以文首墨刀官方接入页及调用返回为准。
