让 Codex 做内部小工具前，先写清需求说明

开场故事

很多内部工具失败，不是因为 AI 不会写，而是因为需求没说清

公司里最容易让人心动的 AI 场景之一，就是让 Codex 帮忙做内部小工具。销售想要一个线索分配表，运营想要一个活动报名后台，财务想要一个报销预审页面，客服想要一个工单看板。大家的想法都很合理，因为这些工作每天都在消耗时间：复制表格、催人补字段、查聊天记录、改状态、做汇总。

但很多人第一次开口，会说一句很大的话：“帮我做一个内部管理工具。”这句话听起来像需求，其实只是愿望。Codex 能写页面、写表单、写规则、接数据，可它不知道你的团队怎么分工，谁能看哪些信息，哪个字段必须填，状态怎么流转，异常怎么处理，老板最后怎么验收。没有这些信息，AI 只能根据经验猜。

这篇教程训练的能力很具体：在让 Codex 做内部小工具之前，先写出一份普通业务同事也能看懂的需求说明。你不需要会写代码，但要能把业务目标、流程、角色、字段、异常和验收讲清楚。需求说明写清楚了，Codex 才更像一位能干活的新同事；需求说明含糊，AI 越能干，偏得越快。

本质解释

内部工具需求的本质：把一段混乱工作变成可执行规则

内部工具不是一个漂亮页面，也不是一个表单集合。它的本质，是把公司里一段反复发生、容易出错、需要多人配合的工作，变成固定流程和可检查规则。比如客户资料录入、报销申请、样品寄送、内容排期、门店巡检、售后工单，这些事原本散落在聊天、表格、邮件和人的记忆里。

用工作语言讲，需求说明就是把“大家平时怎么干活”翻译成“工具应该怎么配合”。谁先发起，谁补信息，谁审核，谁收到提醒，哪些数据必须留下，什么情况不能继续，最后老板看什么结果。写需求不是为了为难自己，而是为了把隐形规则摊开，减少 AI 猜错和团队扯皮。

所以，内部工具需求有三层。第一层是业务目标：为什么要做这个工具。第二层是操作规则：每天谁点什么、填什么、改什么。第三层是验收标准：做到什么程度才算能用。只写第一层，Codex 只能做演示品；写到第二层，工具开始能跑；写到第三层，老板才敢让团队真正使用。

• 业务目标：这个工具替团队减少哪类重复劳动。
• 操作规则：不同角色在什么节点做什么动作。
• 数据规则：哪些字段必须准确，哪些字段用于统计和追责。
• 异常规则：遇到缺资料、重复、退回、超时、权限不足时怎么办。
• 验收规则：用哪些样例证明工具真的符合业务。

错误做法

模糊想法为什么会失败：AI 会补空白，但补的不一定是你的公司

很多内部工具项目的失败，表面看是页面不好用、字段不对、权限混乱，根子上是开始时没有把空白填完。你说“做一个审批工具”，但没有说明是先主管审还是先财务审；你说“做一个客户管理表”，但没有说明销售能不能看别人的客户；你说“做一个库存登记”，但没有说明负数库存能不能提交。

Codex 遇到空白时，会尝试用常见做法补上。它可能给你做一个管理员和普通用户的权限结构，给你生成姓名、电话、状态、备注这些字段，给你安排一个提交按钮。这些看起来都合理，但真实公司里经常不是这样。销售主管可能只能看本组数据，财务只能改付款状态，运营可以导入但不能删除，老板需要看汇总但不应该误触编辑。

模糊想法失败还有一个原因：工具会把错误固化。以前在表格里填错，可能还能被同事发现；工具一旦上线，错误字段、错误权限、错误流程会变成系统规则。团队会围着错误工具工作，最后不是提效，而是制造更多绕路和补救。

业务痛点

先写痛点：不要从功能开始，要从工作里最疼的地方开始

很多人写需求时第一句就是“需要登录、列表、搜索、导出、审批”。这些都是功能，但不是痛点。功能是工具长什么样，痛点是为什么非做不可。如果痛点没有说清，Codex 很容易做出一个功能很多、但没人愿意用的工具。

写痛点时，可以问五个问题：这件事现在靠谁手工做？每天或每周发生多少次？最常出错的是哪一步？出错后谁来补救？老板现在最难看到什么？比如一个报销预审工具，真正的痛点可能不是“没有表单”，而是员工反复漏发票、财务反复退回、主管不知道卡在哪、月底汇总口径不一致。

痛点越具体，工具越容易做小。Codex 做内部工具最怕一开始就做大而全。更好的做法是先抓一个高频、明确、可验收的痛点，让工具跑通一条主线。等团队真的用起来，再加搜索、导出、报表、提醒和更多权限。

范围边界

先定最小可用版本：内部工具第一版不要做成公司大系统

老板和负责人很容易对内部工具抱有完整想象：最好能登录、分权限、接数据、自动提醒、导出报表、审批流、手机端、历史记录、图表看板全部都有。方向没错，但第一版全做，往往会拖慢进度，也会让需求不清的问题被放大。

最小可用版本的意思，是先做一条能真实跑通的工作闭环。比如线索分配工具，第一版可以只做线索录入、负责人分配、状态更新、重复手机号提示、主管查看。暂时不做复杂绩效报表、不接 CRM、不做自动打电话、不做多渠道归因。这样 Codex 的任务边界清楚，验收也清楚。

写需求说明时，一定要有“不做范围”。这不是削弱项目，而是保护项目。你可以写：“第一版不接第三方系统，不做自动通知，不开放外部客户访问，不支持批量删除。”有了这些边界，Codex 才不会为了显得完整而顺手加一堆你还没确认的东西。

• 先做一条主流程，不做所有可能分支。
• 先服务一个或两个核心角色，不覆盖全公司所有岗位。
• 先保存关键数据，不追求所有统计口径。
• 先人工验收，再谈自动化提醒和复杂集成。
• 先明确不做什么，避免 Codex 自行扩大范围。

流程图

把流程画出来：从谁发起，到谁确认，到哪里结束

流程图不是给技术团队看的装饰图，而是让业务流程一眼可见。很多争议只要画成流程图，就会立刻暴露：是不是少了审核人？退回后回到哪里？主管不处理会不会卡住？数据什么时候算完成？谁收到结果？这些问题如果不画出来，Codex 只能在代码里替你做决定。

一个内部工具的流程图，不需要复杂。你只要用“开始、填写、检查、审批、退回、完成、归档”这些工作词，把主线和异常线画出来。主线是正常情况下怎么走，异常线是缺资料、权限不足、重复提交、审批不通过、超时未处理时怎么走。只要这张图清楚，后面的字段、权限和验收都会更容易写。

下面这个文字版流程图，可以直接放进需求说明里。它看起来朴素，但足够让 Codex 理解工具的工作节奏。

员工或业务人员发起申请
  ↓
填写必填信息和上传附件
  ↓
系统检查：字段是否完整、是否重复、是否有权限
  ↓
如果检查失败：提示原因，停留在当前步骤
  ↓
如果检查通过：提交给负责人审核
  ↓
负责人审核
  ├─ 通过：进入下一步处理或标记完成
  └─ 退回：写明原因，回到发起人补充
  ↓
完成后记录处理人、处理时间、最终状态
  ↓
主管或老板查看汇总和异常清单

角色权限

权限不是技术词，而是公司里谁能看、谁能改、谁负责

很多非技术同事听到权限，会以为这是开发细节。其实权限首先是管理问题。它回答的是：谁可以看到哪些信息，谁可以发起动作，谁可以修改关键字段，谁可以审批，谁可以导出，谁做了操作要不要留下记录。内部工具最容易出事故的地方，往往不是按钮不好看，而是权限放得太宽。

不要只写“管理员”和“普通用户”。真实公司里，角色通常是业务角色：销售、销售主管、运营、财务、人事、仓库、客服、门店店长、老板。每个角色的工作边界不同。比如销售能看自己的客户，销售主管能看本组客户，财务能看付款信息但不一定能改客户跟进状态，老板能看全局汇总但不应该随手改一线记录。

写权限时，最好按“能看、能新增、能修改、能审批、能导出、不能做什么”六个维度描述。特别是不能做什么，一定要写。因为 Codex 如果只看到“主管能管理客户”，可能会默认主管能删除客户；但你的公司可能要求客户只能转移，不能删除。

角色权限说明

请把内部工具的权限按工作角色写清，不要只写管理员、普通用户。

角色一：[例如销售]
- 能看什么数据：
- 能创建什么记录：
- 能修改什么字段：
- 不能做什么：

角色二：[例如销售主管]
- 能看什么数据：
- 能审批什么动作：
- 能导出什么范围：
- 不能越过什么规则：

角色三：[例如财务]
- 能确认什么：
- 能退回什么：
- 需要留下什么操作记录：

共同要求：
- 涉及金额、客户资料、员工信息的动作必须有记录。
- 不确定权限时，先停下来问负责人，不要默认放开。

数据字段

字段不是表格列名，而是未来统计、追责和提醒的依据

内部工具一定会有字段。很多人写字段时，只写“姓名、电话、备注、状态”。这不够。字段要写清业务含义、谁填写、什么时候填写、是否必填、格式是什么、错误示例是什么、是否影响审批或统计。否则 Codex 可能做出一个能输入文字的框，但团队不知道怎么填才算正确。

比如“状态”这个字段，看似简单，实际非常关键。客户状态如果允许随便手输，就会出现“已联系”“联系过”“已经沟通”“沟通过了”四种写法，最后报表无法统计。更好的写法是固定选项：待联系、已联系、需报价、已成交、无效。再说明每个状态什么时候可以选，谁可以改，改了是否记录时间。

字段还决定工具以后能不能扩展。如果第一版没有记录负责人、创建时间、最后更新时间、处理人、状态变更原因，后面老板要看效率、超时、责任归属，就会很困难。所以字段清单不是琐碎细节，而是在为未来管理留证据。

• 必填字段：没有它就不能提交。
• 选填字段：有更好，但不影响主流程。
• 自动字段：创建时间、更新时间、创建人、处理人等由系统记录。
• 枚举字段：状态、类型、优先级这类字段尽量用固定选项。
• 敏感字段：金额、手机号、身份证、工资、客户资料要特别说明查看和导出权限。

数据字段清单

请把每个字段写成普通业务同事能看懂的说明。

字段名：
业务含义：
谁填写：
什么时候填写：
是否必填：
允许的格式或选项：
示例值：
错误示例：
是否影响统计、审批、提醒或权限：
修改后是否需要记录日志：

请至少覆盖：编号、负责人、客户或对象、状态、金额或数量、日期、备注、附件、审批人、创建时间、最后更新时间。

异常情况

异常不是以后再说，而是工具能不能真实使用的关键

真实工作从来不会只走主流程。有人漏填信息，有人重复提交，有人填错金额，有人没有权限，有人审批不通过，有人离职，有人上传错附件，有人超时不处理。如果需求说明只写正常流程，Codex 做出来的工具在演示时很好看，一到真实使用就卡住。

写异常情况时，可以从四类入手。第一类是信息异常：字段缺失、格式错误、附件不合格。第二类是流程异常：重复提交、审批退回、超时未处理。第三类是权限异常：用户看了不该看的数据，或尝试修改不该改的字段。第四类是业务异常：库存不足、客户重复、金额超限、日期冲突。

异常处理要写得具体。不要只写“报错提示”。要写提示给谁看、提示内容大概是什么、数据是否保存、流程是否继续、谁收到提醒、是否留下记录。这样 Codex 才能把异常做成真正的工作规则，而不是简单弹一个错误。

验收样例

验收样例要提前写：用真实数据证明工具能跑通

很多内部工具的验收，只停留在“页面能打开、按钮能点、数据能保存”。这只能证明工具像个工具，不能证明它适合你的业务。更好的验收方式，是在需求说明阶段就准备样例。每个样例包含输入、角色、操作、预期结果和错误边界。

验收样例最好覆盖四种情况：正常流程、权限不足、信息缺失、异常退回。比如报销预审工具，正常样例是员工提交完整发票和金额，主管通过后财务待确认；权限样例是普通员工尝试查看其他部门报销，应被阻止；信息缺失样例是没有发票附件，不能提交；异常样例是金额超过标准，必须进入额外审批。

提前写样例还有一个好处：它会倒逼你发现需求漏洞。如果你写不出“审批不通过后应该发生什么”，说明流程还没想清。不要等 Codex 写完再争论，开工前用样例把规则说透。

验收样例模板

请不要只说工具做好了。请用下面样例帮我验收：

样例一：正常流程
- 输入：
- 操作步骤：
- 预期结果：
- 页面应该显示：
- 数据应该保存：

样例二：权限不足
- 当前用户角色：
- 尝试动作：
- 预期提示：
- 数据是否应该改变：

样例三：信息缺失
- 缺少字段：
- 预期提示：
- 是否允许提交：

样例四：异常或退回
- 触发条件：
- 预期处理：
- 谁收到提醒：
- 是否留下记录：

AI 分工

Codex 能帮你检查和实现，但不能替负责人做业务决定

让 Codex 做内部工具，最稳的分工是：人负责决定，AI 负责整理、提醒、实现和检查。负责人要说清业务目标、角色边界、关键字段、审批规则和验收样例。Codex 可以帮你把这些内容整理成需求说明，可以指出缺口，可以建议最小版本，也可以根据确认后的说明写代码。

AI 不能替你决定哪些员工能看工资，不能替你决定客户归属规则，不能替你决定金额超过多少要审批，也不能替你承诺上线时间。它可以提醒这些地方有风险，但最终规则必须由业务负责人确认。内部工具牵涉公司数据、人员责任和管理流程，不能把责任外包给 AI。

一个实用做法是让 Codex 先当需求审查员，而不是开发员。你把初稿给它，让它先回答：哪里清楚，哪里缺失，哪里冲突，哪些地方可能影响权限和数据安全，第一版该收缩到什么范围。等这些问题确认后，再进入实现。这样 Codex 参与得更早，也更不容易做偏。

• 人负责业务目标、权限边界和最终验收。
• Codex 负责整理需求、发现缺口、提出实现步骤。
• 人确认规则后，Codex 再写代码或改项目。
• 涉及敏感数据和审批责任时，AI 只能提醒，不能拍板。

给 Codex 的任务提示词

我要做一个内部小工具，请先不要直接写代码。请先根据下面需求说明，帮我检查是否足够清楚。

工具名称：
使用对象：
要解决的业务痛点：
核心流程：
角色权限：
数据字段：
异常情况：
验收样例：
不做的范围：

请你先输出：
1. 这份说明里已经清楚的部分
2. 还缺少的关键问题
3. 哪些需求可能互相冲突
4. 最小可用版本应该先做哪些功能
5. 哪些地方涉及权限、数据安全或审批风险

在我确认前，不要写入文件，不要自行扩大范围。

老板验收

老板怎么验收：不用看代码，只看四件事

老板验收内部工具需求说明，不需要打开代码。只看四件事就够：痛点是否真实，流程是否闭环，权限是否安全，样例是否能证明。痛点真实，说明这个工具值得做；流程闭环，说明它能在团队里跑；权限安全，说明不会乱放数据；样例能证明，说明不是拍脑袋。

老板最应该警惕的汇报是“功能都做了”。功能做了不等于业务跑通。真正有价值的汇报应该像这样：“第一版只解决线索录入和分配；销售只能看自己线索，主管看本组，老板看汇总；手机号重复会阻止创建；验收样例覆盖正常提交、重复手机号、权限不足和主管改状态。”这类汇报让老板知道工具边界在哪里。

验收时还要问一个问题：这个工具上线后，谁负责维护规则？内部工具不是一次性页面，团队流程会变。客户状态可能要加，审批人可能会换，字段口径可能调整。如果没有规则负责人，工具很快会变成没人敢改的旧系统。

1. 看痛点：是否明确减少哪类人工重复、错误或等待。
2. 看流程：是否从发起到完成都有负责人和结束标志。
3. 看权限：是否说清谁能看、谁能改、谁能导出、谁不能做什么。
4. 看样例：是否用真实场景证明正常和异常都能处理。

案例一

案例一：销售线索分配工具，从一张混乱表格开始

一家 B2B 公司每天从官网、展会和渠道收到线索。过去运营把线索放进表格，再在群里提醒销售领取。问题是手机号重复、负责人不清、跟进状态写法混乱，老板月底看不出哪些线索真的被跟进。团队一开始想让 Codex 做一个“销售管理系统”，范围太大。

他们把需求收缩成第一版：只做线索录入、查重、分配负责人、更新状态和主管查看。本质痛点是减少重复线索和漏跟进。字段包括客户名、手机号、公司、来源、负责人、状态、下次跟进时间、备注、创建时间。权限规则是销售只看自己，主管看本组，老板看汇总，只有主管能改负责人。

验收样例很清楚：运营录入一个新手机号，应成功创建；再次录入同手机号，应提示已存在并显示负责人；销售尝试查看别人的线索，应无权查看；主管把线索转给另一名销售，应记录转移人和时间。Codex 拿到这样的说明后，做出来的工具就不会只是一个好看的客户表，而是能服务真实销售动作。

• 原始问题：表格分散、重复线索、状态口径混乱。
• 第一版范围：录入、查重、分配、状态更新、主管查看。
• 关键权限：销售看自己，主管看本组，老板看汇总。
• 关键验收：重复手机号不能创建新线索，转移负责人要留记录。

案例二

案例二：报销预审工具，真正要解决的是反复退回

一家小公司财务每周都要处理报销。员工在聊天里发截图，主管在群里回复同意，财务月底再整理。最大的问题不是没有系统，而是材料经常不完整：缺发票、金额不一致、项目名称写错、审批截图找不到。财务反复退回，员工也觉得麻烦。

他们让 Codex 做工具前，先写需求说明。第一版不做复杂财务系统，只做报销预审：员工提交金额、费用类型、项目、发票附件、说明；主管审核通过后，财务标记已确认或退回。字段里明确金额必须是数字，发票附件必填，费用类型用固定选项。异常里明确缺附件不能提交，金额超过 5000 元需要额外负责人确认。

权限上，员工只能看自己的报销；主管看自己要审批的报销；财务看全部待确认记录，但不能改员工原始金额，只能退回要求修改；老板看月度汇总。这样的需求说明让工具边界很清楚：它不是替代财务制度，而是先把材料收齐、流程留痕、退回原因标准化。

案例三

案例三：内容排期工具，先统一状态和责任人

内容团队常见的问题，是选题、撰稿、设计、审核、发布散在多个表格和聊天群里。负责人问“这篇文章到哪了”，每个人的回答口径都不一样：有人说写完了，其实还没审；有人说可以发，其实封面没做；有人说等反馈，但没人知道等谁。

这个工具的需求核心不是做一个漂亮日历，而是统一状态和责任。第一版只管理内容标题、渠道、负责人、当前状态、截止日期、下一步动作和阻塞原因。状态固定为选题中、撰稿中、待设计、待审核、待发布、已发布、暂停。每次状态变化必须记录操作者和时间。

验收样例包括：编辑创建选题后进入选题中；撰稿人提交初稿后变成待设计；审核不通过必须填写退回原因；超过截止日期且未发布，主管看板出现红色提醒。Codex 如果拿到这些规则，就能把排期工具做成团队协作看板，而不是又一张没人维护的表。

• 原始问题：状态口径不统一，责任人不清。
• 关键字段：标题、渠道、负责人、状态、截止日期、下一步动作、阻塞原因。
• 关键规则：状态固定选项，变化留痕。
• 老板验收：能一眼看到延期、阻塞和待审核内容。

案例四

案例四：门店巡检工具，异常照片比文字备注更重要

连锁门店巡检常常靠表格和照片群。巡检人员到店后拍照、写备注、发群，区域经理再翻聊天记录。问题是照片和检查项对不上，整改责任人不清，复查时间没有提醒，老板只能看零散截图，无法判断哪个门店问题最多。

需求说明把工具目标写得很朴素：巡检人员按检查项提交结果，异常项必须上传照片和描述，区域经理分配整改责任人，责任人提交整改结果，巡检人员或经理复查关闭。字段包括门店、检查日期、检查项、结果、异常照片、整改责任人、整改截止日期、复查状态。

权限也要贴近业务。巡检人员能新建巡检和提交复查，门店负责人只能看自己门店问题并提交整改，区域经理看辖区门店，老板看所有门店汇总。异常情况包括照片未上传不能提交异常项、超期未整改进入异常清单、复查不通过继续保持待整改。这样 Codex 才知道这个工具最重要的不是输入框，而是证据、责任和关闭流程。

常见错误

新手写内部工具需求，最容易犯这十二个错误

第一个错误，是只写功能，不写痛点。第二个错误，是只写正常流程，不写异常情况。第三个错误，是只写管理员和用户，不写真实岗位。第四个错误，是字段只写名字，不写格式、示例和填写责任。第五个错误，是没有固定状态选项，导致以后无法统计。

第六个错误，是默认所有人都能看全部数据。第七个错误，是没有说明删除、导出、审批这些高风险动作。第八个错误，是把第一版范围做得太大。第九个错误，是没有验收样例，只靠主观感觉验收。第十个错误，是让 Codex 直接写代码，不先审需求漏洞。第十一个错误，是没有老板验收口径。第十二个错误，是上线后没人维护规则。

这些错误不是技术问题，而是管理问题。解决办法也不复杂：每次写需求，都用“痛点、流程、角色、字段、异常、样例、边界”七件事过一遍。少一项，就先补齐，再让 Codex 开始实现。

检查清单

开工前检查清单：需求是否够 Codex 开始做

下面这张清单适合在你把任务交给 Codex 前使用。它不是形式主义，而是帮你判断需求是否从想法变成了可执行说明。如果大部分问题答不上来，说明还不该写代码，应该先补需求。

你可以把它当成项目负责人和 Codex 之间的开工门槛。过了这道门，Codex 的工作会更像按图施工；没过这道门，Codex 很可能变成边猜边做。

检查清单

输出质量检查清单：Codex 做完后看什么

当 Codex 根据需求说明做出内部工具后，验收不要只看界面。界面顺眼只是第一层，更重要的是流程是否符合需求、权限是否正确、字段是否按规则校验、异常是否能处理、样例是否全部跑通。

如果你不懂代码，也可以做业务验收。拿着提前写好的验收样例，一条条操作。正常样例能否完成，失败样例是否被拦住，权限样例是否看不到不该看的数据，退回样例是否回到正确的人手里。这个过程比听 Codex 说“已完成”可靠得多。

模板库

五个可复制模板：从想法到可开工说明

你不需要每次从空白页开始写需求。下面五个模板可以覆盖大多数内部小工具：完整需求说明、角色权限、字段清单、验收样例、给 Codex 的需求审查提示词。它们的共同目标，是把工作语言翻译成 Codex 可以执行的规则。

模板不是让你填得越多越好，而是逼你补齐关键空白。尤其是权限、异常和验收样例，很多团队一开始会漏掉。只要这些地方写清，Codex 后续实现的稳定性会明显提高。

内部小工具需求说明

一、业务背景
- 现在谁在做这件事：
- 目前怎么做：
- 为什么现在必须改：

二、工具目标
- 这个工具要帮谁省什么时间：
- 要减少哪类错误：
- 暂时不解决什么问题：

三、使用角色
- 谁可以新建：
- 谁可以编辑：
- 谁可以审核：
- 谁只能查看：

四、核心流程
- 第一步：
- 第二步：
- 第三步：
- 完成标志：

五、数据字段
- 必填字段：
- 选填字段：
- 自动生成字段：
- 不允许用户随便改的字段：

六、异常情况
- 信息缺失时怎么办：
- 重复提交时怎么办：
- 审批不通过时怎么办：
- 权限不足时怎么办：

七、验收样例
- 给 Codex 三条真实样例数据：
- 说明每条样例应该出现什么结果：
- 说明哪些结果算错误：

角色权限说明

请把内部工具的权限按工作角色写清，不要只写管理员、普通用户。

角色一：[例如销售]
- 能看什么数据：
- 能创建什么记录：
- 能修改什么字段：
- 不能做什么：

角色二：[例如销售主管]
- 能看什么数据：
- 能审批什么动作：
- 能导出什么范围：
- 不能越过什么规则：

角色三：[例如财务]
- 能确认什么：
- 能退回什么：
- 需要留下什么操作记录：

共同要求：
- 涉及金额、客户资料、员工信息的动作必须有记录。
- 不确定权限时，先停下来问负责人，不要默认放开。

数据字段清单

请把每个字段写成普通业务同事能看懂的说明。

字段名：
业务含义：
谁填写：
什么时候填写：
是否必填：
允许的格式或选项：
示例值：
错误示例：
是否影响统计、审批、提醒或权限：
修改后是否需要记录日志：

请至少覆盖：编号、负责人、客户或对象、状态、金额或数量、日期、备注、附件、审批人、创建时间、最后更新时间。

验收样例模板

请不要只说工具做好了。请用下面样例帮我验收：

样例一：正常流程
- 输入：
- 操作步骤：
- 预期结果：
- 页面应该显示：
- 数据应该保存：

样例二：权限不足
- 当前用户角色：
- 尝试动作：
- 预期提示：
- 数据是否应该改变：

样例三：信息缺失
- 缺少字段：
- 预期提示：
- 是否允许提交：

样例四：异常或退回
- 触发条件：
- 预期处理：
- 谁收到提醒：
- 是否留下记录：

给 Codex 的任务提示词

我要做一个内部小工具，请先不要直接写代码。请先根据下面需求说明，帮我检查是否足够清楚。

工具名称：
使用对象：
要解决的业务痛点：
核心流程：
角色权限：
数据字段：
异常情况：
验收样例：
不做的范围：

请你先输出：
1. 这份说明里已经清楚的部分
2. 还缺少的关键问题
3. 哪些需求可能互相冲突
4. 最小可用版本应该先做哪些功能
5. 哪些地方涉及权限、数据安全或审批风险

在我确认前，不要写入文件，不要自行扩大范围。

落地方法

一周写出第一版需求说明：每天只做一件事

如果你觉得一口气写完需求说明太难，可以用一周拆开做。第一天只写痛点和目标，别急着列功能。第二天画流程，把主线和退回线说清。第三天写角色权限。第四天写字段清单。第五天写异常情况。第六天写验收样例。第七天让 Codex 审查需求，补齐缺口，收缩第一版范围。

这个节奏适合老板、产品、运营负责人带团队一起做。每次讨论只围绕一个问题，不会陷入所有人同时争论页面、字段、权限和报表。等七天结束，你得到的不是一堆会议纪要，而是一份可以交给 Codex 开始实现的说明。

如果项目很小，也可以把一周压缩成半天。但顺序不要乱。先痛点，再流程；先角色，再字段；先异常，再验收；最后让 Codex 审需求。这个顺序符合真实工作从混乱到规则的过程。

1. 第一天：写清痛点、目标和不做范围。
2. 第二天：画主流程和异常流程。
3. 第三天：列真实岗位和权限边界。
4. 第四天：整理字段、格式、示例和必填规则。
5. 第五天：补充缺资料、重复、退回、超时、权限不足等异常。
6. 第六天：准备正常、失败、权限、退回四类验收样例。
7. 第七天：让 Codex 审查需求，再决定是否进入实现。

团队习惯

把需求说明变成团队习惯，而不是一次性文档

内部工具需求说明最有价值的地方，不是第一次写给 Codex 看，而是变成团队以后提需求的共同语言。以后有人说“做个工具”，大家就会自然追问：痛点是什么？流程怎么走？谁能看？字段有哪些？异常怎么办？怎么验收？这套语言一旦建立，团队和 AI 的协作都会稳定很多。

你可以把模板放进团队知识库、项目说明或固定任务表里。每次做新工具，都复制一份。做完后再把实际验收发现的问题补回模板，比如“所有金额字段都必须写币种”“导出功能必须限制负责人”“状态变更必须留原因”。这些经验会让下一次工具更稳。

不要期待第一份需求说明完美。内部工具本来就是边使用边调整的。关键是每次调整都要回到说明里，而不是只在聊天里说一句。需求说明是工具的说明书，也是团队记忆的一部分。

课后练习

课后练习：用你自己的工作，写一份可交给 Codex 的需求说明

练习一：从你团队里找一件每周至少发生三次、靠表格或聊天推动的工作。不要先想工具长什么样，只写现在怎么做、哪里最耗时、哪里最容易出错、谁最痛苦。这个练习训练的是从功能思维回到业务痛点。

练习二：为这件事画一张文字流程图。写出谁发起、谁补充、谁审核、谁完成、退回怎么办、超时怎么办。流程越朴素越好，但不能跳步。这个练习训练的是把隐形工作说出来。

练习三：列角色权限和字段清单。至少写三个角色，至少写十个字段。每个字段都要有业务含义、填写人、是否必填、示例值和错误示例。这个练习训练的是把表格列名变成工作规则。

练习四：写四条验收样例，分别覆盖正常流程、权限不足、信息缺失和异常退回。然后把整份说明交给 Codex，让它先审查，不让它写代码。看它能指出哪些缺口，再补一轮。

1. 选择一个真实、高频、重复的内部工作。
2. 写痛点和第一版不做范围。
3. 画主流程和异常流程。
4. 写角色权限和字段清单。
5. 准备四条验收样例。
6. 让 Codex 先审需求，再决定是否实现。

最后总结

让 Codex 做内部工具，真正的第一步是把工作讲清楚

内部小工具看起来是技术任务，本质上是管理任务。它把公司的重复工作、角色分工、数据规则、异常处理和验收口径固化下来。Codex 可以帮你实现得很快，但前提是你先告诉它什么叫做对，什么叫做错，什么叫做暂时不做。

一份好的内部工具需求说明，不需要像专业软件文档那样复杂。它只要讲清七件事：业务痛点、最小范围、流程图、角色权限、数据字段、异常情况、验收样例。老板用它验收方向，业务用它确认工作规则，产品用它拆任务，Codex 用它减少猜测。

记住这句话：AI 会干活，但需求说明决定它干的是不是你的活。下次你想说“帮我做个内部工具”时，先停一下，把这句话改成：“请先帮我审查这份内部工具需求说明，确认流程、权限、字段、异常和验收是否足够清楚。”这一步做好了，后面的代码和页面才有可靠的地基。

• 先讲痛点，不先堆功能。
• 先定最小范围，不一口吃成大系统。
• 先画流程，不让 Codex 猜顺序。
• 先写权限和字段，不把管理责任交给默认设置。
• 先准备验收样例，不用感觉判断好坏。