当前位置：首页 > news >正文

我画了一张流程图，83 分钟后，Codex 把它做成了一个能跑的工单原型

news 2026/8/9 21:33:29

前沿AI旅社 · 普通人用 CODEX

我画了一张流程图

83 分钟后，它能跑了

读错 1 次 · 纠正 1 次 · 六项通过

我画了一张流程图，83 分钟后，Codex 把它做成了一个能跑的工单原型

今天和一位企业老板聊 Codex，他卡在三个最基础的问题上：

不会用，不知道能拿它做什么，也不知道该怎么问。

我后来发现，继续跟他解释 Codex 会写代码、会改文件、会跑测试，没有太大意义。一个从来没接触过这类工具的人，听完只会多记几个名词，还是不知道下一步该做什么。

所以我换了一个讲法。我拿出一张纸，随手画了一个售后工单流程。

图：我本人手绘的虚构售后流程，第二个方框是“后台派单”

图很潦草，只有几个方框和箭头：客户报修，后台派单，技师接单，上门处理，管理者查看结果。

我想验证一件很具体的事：一个不从代码开始的人，能不能先把自己熟悉的业务画出来，再让 Codex 把它推进成一个真正能操作的原型？

结果是，83 分钟以后，我得到了一套可以在浏览器里跑起来的工单网页。

但过程不是“一张图丢进去，AI 一次生成”。

READ

第一次，它就读错了

“后台派单”被读成“信息收集”

我发出的第一轮提示很克制，只让 Codex 看图，不让它写代码：

PROMPT 01 · 只识图，不写代码

附件是我本人刚刚手绘的一张虚构业务流程图，内容不对应任何真实客户或已上线项目。 先不要写代码，不要创建文件，也不要替我扩展需求。请只完成下面四件事：1. 用中文复述你从图片中实际读到的角色。2. 按箭头顺序复述主流程、所有状态和分支条件。3. 用“看清楚 / 看不清楚 / 图片里没有”三类，列出你对页面、字段、规则的识别结果。4. 明确告诉我：你是否真的读取了这张附件；如果当前无法读取，请直接说无法读取，不要根据我这段文字猜图中内容。 这一轮禁止写代码，禁止把演示场景描述成成都、天津或任何客户案例。

它确实读取了图片，但把第二个方框理解成了“信息收集”。

我没有重开一个对话，也没有重新画一张更漂亮的图。我直接在同一个线程里纠正：

你的复述与我的手绘图有不一致的地方，第二个方框是后台派单，当然信息收集是前置条件。

这是整次实验唯一一次人工纠正。

如果我只留下最后成功的画面，读者看到的会是“上传一张图，系统自动完成”。可真实过程里有前面这次读错。图片和业务规则都要核对，人先确认它听懂了什么，再决定要不要往下做。

我反而觉得，这次读错让实验更有价值。

普通人使用 Codex，不需要先寻找一句永远不会出错的神奇提示词。更要紧的是，自己知道必须对哪些业务事实负责。第二个方框到底是“信息收集”还是“后台派单”，写代码的人可以不知道，画流程的人必须知道。

RESULT

83 分钟后，它真的能操作

不是效果图，是本地可运行网页

纠正完流程，我让 Codex 开始实现。最后得到的是一套本地网页原型，不是一张静态图片。里面有四个演示角色：

客户填写报修信息，提交后得到工单号。

调度选择技师和截止时间。

技师接单、开始处理、填写结果并完成。

管理者查看各状态数量和已超时工单。

状态不能随便跳。工单必须按照“待派单 → 待上门 → 处理中 → 已完成”往下走。截止时间已经过去、工单又没有完成时，页面会标红。

图：编辑部用源码内置虚构数据在 375px 视口复测的管理页

THIS RUN

83 分钟 · 纠正 1 次

按作者记录失败或返工 0 次，六项手动验收全部通过

“失败 0”不等于 Codex 没犯错。前面的识图错误真实发生过，我也确实纠正了它。这里的“失败或返工 0 次”，只表示纠正理解后，后续实现没有出现需要我打回重做的失败。

我本人在页面里走了六项闭环：提交工单、派单、技师接单与处理、完成、看板更新、超时标红，全部通过。

编辑部随后又在源码目录重新跑了一遍自动测试和生产构建。5 个测试文件、18 项测试全部通过，构建成功。还在 375px 宽度下逐个打开客户、调度、技师和管理者页面，没有发现横向溢出。

这些检查能证明第一版原型跑通了。它们不能证明这是一套可以直接交给企业上线的系统。

THRESHOLD

降低的是参与门槛

先讲业务，不等于不用工程

以前，一位业务负责人有一个想法，通常要先把它写成需求，再交给产品经理和工程师。中间只要有一个人理解偏了，做出来的东西就可能和最初的问题不是一回事。

Codex 改变的地方，是业务负责人可以更早地参与。

他不必先学会 React、TypeScript 或数据库，也不必先把每个页面画成专业原型。他可以先把自己每天在做的事情讲清楚，哪怕第一份输入只是一张很难看的手绘图。

但“讲清业务”不是说一句“帮我做个工单系统”。这次真正让 Codex 可以继续工作的，是下面这些内容：

谁在用客户、调度、技师、管理者，每个人能看到和操作的东西不同。

顺序是什么先报修，再派单，技师接单后才能处理，完成以后管理者看到结果。

什么不能发生没有派单不能直接完成，技师不能处理别人的工单，完成时必须填写结果。

怎样才算做完六项闭环要点通，非法状态要拦住，刷新以后数据还要在。

这四件事，本来就属于业务。普通人不需要先学会写代码，才有资格说清楚角色、顺序、规则和验收。相反，如果这些东西自己都说不清楚，找再强的工程师，也只能一边做一边猜。

Codex 降低的是参与软件开发的门槛。

懂业务但不会编程的人，可以从讲清业务开始。验证、上线和工程责任仍然在。

PROMPTS

三轮提示，完整公开

先听懂，再实现，最后验收

我没有用一句超级长的提示，把识图、开发和验收全部混在一起。我把过程分成三轮。第一轮只确认它有没有看懂；第二轮再实现；第三轮停止加功能，只做验收和必要修复。

第一轮提示在前面已经完整贴出。下面是我实际使用的第二轮和第三轮。你可以照着结构改成自己的流程，核心答案都在正文里，不需要另外找我领取提示词。

第二轮：纠正理解后，再让它实现

PROMPT 02 · 实现原型

现在开始把这个流程做成一套可运行的中文网页原型。请在当前空白工作区直接完成实现、测试和本地运行，不要只给我教程或代码片段，也不要等我逐个确认技术细节。 这是一个公开演示，不对应真实客户。所有姓名、电话、地址、技师、工单、时效和统计数字必须是明显虚构的数据。不要接入任何外部 API、短信、微信、真实账号或客户系统。 技术范围： - 使用 Vite + React + TypeScript。 - 使用 localStorage 保存演示数据，刷新后数据仍在。 - 使用角色切换器模拟“客户、调度、技师、管理者”，不做真实登录。 - 移动端优先，375px 宽度必须可以正常操作，同时兼容电脑。 - 提供“重置演示数据”按钮。 - 不添加 AI 故障判断、自动派单、聊天机器人或其他额外功能。 业务范围：1. 客户页：姓名、联系电话、服务地址、设备类型、故障描述、期望上门时间为必填，故障图片可选；提交后生成唯一工单号并显示状态。2. 调度页：查看待派单工单，选择虚构技师并设置截止时间后派单。3. 技师页：只能看到分配给自己的工单；按顺序执行“接单 → 开始处理 → 填写处理结果 → 完成”，结果图片可选。4. 管理页：显示待派单、待上门、处理中、已完成、已超时数量和最近工单。5. 合法主状态只有“待派单 → 待上门 → 处理中 → 已完成”，禁止跳步。6. 截止时间早于当前时间且未完成时，显示红色“已超时”；已完成工单不能继续显示超时。7. 内置至少一条已经超时的虚构工单，打开系统即可看到效果。 错误处理： - 必填项缺失时阻止提交，并在对应字段旁显示中文提示。 - 未选择技师或截止时间时不能派单。 - 完成工单时处理结果必填。 - localStorage 数据损坏时显示可理解的恢复提示，并允许重置。 - 图片只在当前浏览器本地预览；存储空间不足时给出提示。 开发与验证方式： - 先为状态流转、超时判断、持久化和核心闭环写测试，确认测试在实现前因缺少行为而失败，再写最小实现使其通过。 - 完成后运行全部测试和生产构建。 - 如果当前 Codex 环境具有浏览器测试能力，再检查 375px 手机宽度和桌面宽度；如果没有，明确写“未自动完成视觉检查”，不要假装检查过。 - 发现错误就继续修复，但不要超出上述范围增加功能。 最后只向我报告：启动方式、本地访问地址、测试与构建结果、你实际创建的主要文件、仍存在的限制。不要声称我已经手动验收，也不要把它描述成生产系统。

这里最有用的不是 Vite、React 这些技术名词。真正有用的是我把边界写得很清楚：这是公开演示，只用虚构数据，不接真实系统；第一版不做 AI 判断和自动派单；必须有合法状态；必须能验收；做不到的检查要明确说没做。

技术栈可以让 Codex 根据项目重新选择，业务边界不能交给它猜。

第三轮：停止加功能，只验收

PROMPT 03 · 六项验收

现在停止增加功能，只对现有原型做验收和必要修复。 请用自动化测试和当前环境中真实可用的浏览器能力，逐项验证下面六件事：1. 客户提交完整工单后得到唯一工单号。2. 调度能给这张工单分配技师和截止时间。3. 被分配的技师能接单并进入“处理中”。4. 技师填写处理结果后能完成工单；非法状态跳转会被阻止。5. 管理看板数量随状态变化，刷新页面后数据仍保留。6. 已超过截止时间且未完成的工单标红；已完成工单不再标为超时。 先运行现有测试；覆盖不足时补测试，再运行生产构建。只修复与这六项有关的失败，不增加新功能。 最终请返回一个六行表格，列出“验收项、实际验证方法、结果、证据”。另外单独列出：执行过的命令、测试数量、构建结果、浏览器视觉检查是否真实执行、所有仍未验证的部分。 如果某项因为当前环境限制没有实际验证，必须写“未验证”，不能推断为通过。不要声称我已经手动验收。

第三轮的作用，是把“看起来做完了”变成“到底哪几件事真的通过了”。

AI 很容易继续往系统里加功能。你说一句“再完善一点”，它可能继续加自动派单、聊天机器人、消息通知，最后页面更热闹，原本要验证的闭环反而没人检查。

我宁愿先停下来，把六件小事一项项点通。

BOUNDARY

这离真正上线还很远

原型能跑，不等于生产系统

有人会反驳：普通人看不懂代码，做出一个原型又有什么用？如果他把原型当成正式系统，风险不是更大吗？

这个反方成立。

**当前原型没有：**正式账号、角色权限、服务器数据库、多设备同步、审计、消息通知和企业系统集成。电话字段目前只检查有没有填写。

如果把它交给一家企业直接使用，我不会同意。它的价值在另一个地方。

以前业务负责人说“我想做个工单系统”，技术团队要靠会议和文档理解他的意思。现在他可以先拿出一个能点的版本：这里该由谁操作，这个状态顺序对不对，哪个字段是多余的，超时规则应该怎样算。讨论对象从一句模糊愿望，变成了可以共同检查的东西。

原型能提前暴露理解偏差，帮助业务和技术更快对齐。