梦老师接到一个项目，标题栏却是空的，没有需求文档、没有背景说明、甚至连一个像样的名字都没留下。这种“裸奔”状态看起来像是个烂摊子，但实际上它是最有意思的起点：因为没有预设框架，所有方向都由你来决定。这篇文章就聊聊，我是怎么把一个“【无标题】”的项目，一步步变成一套能跑、能维护、能交付的真实系统的。整个过程里没有玄学，只有一套可以反复使用的实操打法。
1. 面对空白标题，第一步不是写代码，而是先完成“需求考古”
一个空标题意味着需求方要么还没想清楚，要么默认你能“读懂空气”。这时候最忌讳的就是打开IDE直接开干，代码写了一半才发现方向完全跑偏，返工成本高到让人怀疑人生。我自己的习惯是，先用一个下午把自己当成侦探，把“无标题”背后真正想要的东西挖出来。
1.1 从三个角度还原项目的真实轮廓
所谓“需求考古”，就是从零散的线索里拼出全景图。我会按以下三个维度问自己：
- 业务目标：这个系统做完之后，谁来用、解决谁的什么问题？是内部提效，还是对外交付？如果是内部工具，那核心指标就是“省时间”；如果是对外产品，那核心指标可能就变成“体验好”或“可扩展”。
- 用户画像：使用者是技术人员，还是普通业务同学？这个差别极大。给技术人员做工具，可以接受命令行和配置文件；给普通用户做工具，就得老老实实做界面、做引导、做容错。
- 边界与约束：有没有现成的系统要对接？有没有硬性的技术栈要求？部署环境是内网还是公网？数据量预估是多少？这些不问清楚，后面都是雷。
1.2 需求不明确的“考古四步法”
没有需求文档，我就自己造一个出来。具体操作分四步：
- 把能接触到的相关人全部聊一遍，哪怕每人只聊十分钟。问的问题不要用“你想要什么”，而是用“你现在最头疼的是什么”，后者更容易得到真实答案。
- 把聊到的碎片信息全部写在白板上，用小便签归类，一类是“确定要做的”，一类是“可能要做的”，一类是“暂时不做的”。
- 基于归类结果，画一张最简单的草图，不管是页面流程图还是模块关系图，只要能拿给别人看懂就行。
- 拿着草图回去找需求方确认：“我理解你要的东西是这样的，对吗？”这一步能挡掉至少一半的返工。
提示：考古阶段最重要的产出物是一页纸的需求确认书。不用正式，但要把目标和边界写清楚，让对方签字确认或者至少回复一句“对”。别嫌麻烦，