从决定开始，不从表单开始
说清这个工具支持哪个决定：批费用、分线索、关工单。支持决定的工具第一版很清楚；“管理某样东西”的工具通常没有第一版。
再说清谁做这个决定、多久做一次。频率决定这件事到底要不要做成工具。
先描述数据，再描述界面
列出字段、来源，以及哪个是唯一事实来源。多数失败的内部工具，本质是数据分歧套了一层界面。
写五条真实样例记录。真实样例比表结构有用，它能暴露缺失字段、重复和干净描述里看不到的别扭情况。
第一版要小
先要一个列表页、一个筛选、一个动作。在真实工作上用一周，再加东西。被用起来的小工具，胜过被称赞的完整工具。
发现缺什么时，描述你当时的替代做法。“我导出到表格又加了一列”比任何需求文档都更清楚地告诉 AI 下一版要什么。
在工作发生的地方修改
做内部工具的理由就是需求会变。把工具和修改请求放在同一处，改动就不用从立项开始。
每次修改按“它解锁了什么工作”来描述，而不是按“动了哪个组件”。 “我要在一个列表里看到上个月的审批”是需求；“加一个日期选择器”是对方案的猜测。
常见问题
我需要知道工具会怎么实现吗？
不需要。你要说清工作、数据和决定。实现是 AI 产出的东西，你通过使用来验收。
第一版要多久？
取决于数据，不取决于页面。字段和唯一事实来源清楚就快；有争议时，先解决争议。
需求变了怎么办？
这很正常。把修改请求留在工具旁边，描述它解锁的工作，而不是推倒重来。
能替代我们现有的主系统吗？
不能。把它当成读取主系统的聚焦工具。替换主系统是另一个项目，风险也不同。
下一步
写下那个决定、五条样例记录和第一版唯一需要的动作，然后只要这一版。上线后记录一周里你手工补了哪些步骤，它们就是下一版的需求。