1. 接到一个只有标题的需求先别急着开工“帮我做个东西具体需求我还没写好。”这句话我听了不下几十次。做了这么多年项目最难的往往不是技术而是面对一个几乎空白的输入没有功能清单、没有技术约束、没有验收标准甚至文档标题都是空的。我自己就接过一个项目需求方发来的内容里只有一个文件夹名写着“效率工具”。没有需求文档没有原型图连一句话的需求描述都没给。今天就把这种“空标题”项目从零到一的完整落地过程拆开讲包括我怎么问需求、怎么定技术方案、怎么一步步做出第一版 Demo以及中途踩过的那些坑。这篇东西适合三类人看刚带项目的新手、经常跟模糊需求打交道的产品经理、以及所有被老板一句“你看着做”搞得手足无措的开发。1.1 空标题背后的三种真实信号拿到一个空标题或者只有几个含糊词的需求先别急着定义“对方不懂技术”。我观察下来这类需求背后通常对应三种情况。第一种是需求方确实没想清楚。他只有一个模糊的愿景比如“我想搞一个效率工具”但具体帮谁、解决什么、做到什么程度全都没有概念。这种情况最需要引导而不是直接催他给 PRD。第二种是对方默认你“应该懂”。比如很多团队里的管理者或运营觉得做技术的人天天研究各种工具肯定一看标题就知道要干什么。这种信任是好事但也很危险你猜错了方向整个项目白做。第三种是探索型项目。需求方自己也知道需求会变只是想先快速做一个 Demo 验证可行性。这种情况空标题反而是一种放权意味着你可以在 MVP 范围内自由决策。区分这三种信号决定了我之后用完全不同的沟通策略和资源投入。这也是整个项目的第一步不要埋头写代码而是先花半天甚至一天时间做需求澄清。1.2 五分钟需求访谈挖出三个关键维度不管项目标不标题我拿到需求后的第一件事都是组织一次需求访谈内部同事或外部客户都行。访谈不需要很长时间但必须围绕三个关键维度来问用户是谁、场景是什么、痛点有多痛。所谓用户不是泛泛的“大家”而要具体到角色。给谁用开发人员、产品经理、运营、还是普通家庭用户不同角色的使用习惯和功能预期差异很大。场景要问开放性问题比如“你希望他在什么时候打开这个工具是每天早上的第一件事还是周末集中处理”。这个问题能逼出真实的使用频次和功能边界。痛点问题我一般直接问“你之前用过哪些同类工具哪里不好用”。竞品的缺憾往往就是新项目的核心卖点。就拿那个“效率工具”项目举例需求方最后告诉我他们团队每天要花两小时在表格工具里手工汇总各渠道的任务进度这还不算每天更新时来回沟通的成本。两小时手工汇总这个痛点非常具体所以我立刻知道这个工具的底层核心应该是任务数据的自动归集和可视化而不是先去做花哨的界面。提醒一句访谈记录一定要当场写最好发给对方确认一遍。很多需求变来变去最后核对的时候这份确认记录就是你唯一能拿出来当依据的东西。2. 把模糊的愿景翻译成一份能执行的产品方案需求访谈做完我对项目的大方向有了判断但还是不能直接进开发。原因是愿景和目标之间隔着一张满是歧义的“翻译表”。比如需求方说“效率”可能指任务提醒也可能指数据分析还可能指流程自动化。这时候要把愿景翻译成“用户故事”和“功能清单”让所有人对“做什么”达成共识。2.1 先写用户故事再画功能地图我习惯用“作为某角色我希望某功能以便某价值”的句式把愿景拆成用户故事。就拿那个效率工具项目来演示作为团队负责人我希望在一个页面看到所有成员的任务状态以便我不用挨个问进度。作为普通成员我希望快速登记当天的工作进展以便减少汇报的时间成本。作为项目助理我希望系统自动生成周报以便我每周省下整理汇总的两小时。三条用户故事写出来核心功能群已经浮出水面任务登记、状态看板、周报生成。再往下拆功能地图每个用户故事又能拆成若干功能点。比如“任务登记”会涉及创建任务、设置优先级、指派负责人、更新状态等“周报生成”会涉及数据筛选、模板配置、自动导出。拆完之后不管功能多少我都会用“必须有、应该有、可以有”三个级别给它们排序。这个排序直接决定第一版 MVP 要做什么。优先级判断的核心原则其实就一条能不能直接消除需求方最痛的那个环节。手工汇总两小时才是痛点所以周报自动生成是第一优先级而状态看板和任务登记反而可以简化成最基础的版本。2.2 技术选型的底层逻辑小项目别自找麻烦技术选型这件事很多新人容易陷入“追新框架”的误区。我自己也踩过坑当年为了追求技术亮点把一个内部工具硬生生拆成微服务结果部署环境、服务通信、日志排查全成了负担项目差点烂尾。后来我的原则变成团队最熟悉什么就用什么没有绝对的“最优架构”只有“当前阶段最稳的组合”。当时我们团队最熟悉的是 Python 和 JavaScript于是后端选了轻量的 FastAPI前端选了 Vue3 加 Element Plus数据库直接用 PostgreSQL。为什么选这个组合理由很实在。第一FastAPI 天然支持异步对任务这类 IO 密集操作很友好而且自动生成接口文档省掉了大量手写文档的时间。第二Vue3 组件生态成熟做看板界面效率高。第三PostgreSQL 既能存关系型数据又有 JSON 类型可以承接后期灵活扩展的结构化需求。有些人可能会问为什么不直接上微服务我说句真心话一个日活可能只有几十人的内部工具微服务带来的分布式复杂度会直接把项目拖垮。单体应用加清晰的模块划分是这个体量最理性的选择。顺手算一笔账当有人问“这个系统能撑多少人”的时候我用最粗略的方式估算假设每人每天产生 50 条操作记录100 人一天的写入量就是 5000 条一个月 15 万条一年 180 万条。PostgreSQL 单表在单机环境下跑到几千万条都没问题所以这个量级根本不需要分库分表。这也是我后来跟需求方沟通时的底气技术上完全没有瓶颈瓶颈在需求本身。3. 实战从接口设计到第一版可运行 Demo方案定稿之后就进入最熟悉的环节写代码。但这里有一个我长期保持的习惯先做数据建模再做接口最后才写页面。顺序反过来会非常痛苦因为页面写一半发现字段不对返工成本极高。3.1 先建数据模型字段设计决定了系统的上限那个效率工具我设计了三张核心表用户表、任务表、进展记录表。这里我不会贴完整 SQL但有几个字段设计的思路值得说。用户表除了基本信息我加了一个“角色”字段区分管理员、负责人、普通成员三种权限。注意权限不是简单的功能菜单开关而是数据可见范围普通成员只能看自己的任务负责人可以看自己小组的所有任务管理员能看到全局。这个控制逻辑放在后端校验前端只有视图层。任务表的关键字段是状态字段我用了枚举待开始、进行中、已完成、已暂停。很多人喜欢用“0/1”这种布尔状态表示完成但真实工作流里“已暂停”和“进行中”状态非常普遍布尔字段根本表达不了。进展记录表是容易被忽略的一张表。很多人做任务管理只记录最终状态但我要求每更新一次任务状态就自动写一条进展记录内容包括操作人、操作时间、备注、变更前状态、变更后状态。这张表初期数据量只有几万条但它的价值在于以后所有周报、统计、审计都能从这里取数而不是靠猜。做数据建模时我常用的一个检查方法把所有字段逐个念一遍看你能否用一句大白话说清楚“这个字段是干什么的”。说不清楚就说明设计有问题。3.2 后端核心模块FastAPI 写一个任务接口选 FastAPI 还有一个好处代码量确实少。写一个任务的创建和查询接口整个逻辑不超过几十行。用一个简化版本说明from fastapi import FastAPI, Depends, HTTPException from pydantic import BaseModel from datetime import datetime app FastAPI() class TaskCreate(BaseModel): title: str owner_id: int priority: int 0 deadline: str | None None app.post(/tasks) async def create_task(task: TaskCreate): # 这里省略数据库连接池代码实际项目中直接存入 PostgreSQL return {task_id: 1, status: created, created_at: datetime.now()} app.get(/tasks/{task_id}) async def get_task(task_id: int): # 假设查库逻辑 task {task_id: task_id, title: 示例任务, status: 待开始} if not task: raise HTTPException(status_code404, detailTask not found) return task看着很简单对吧但接口层真正的复杂度从来不在 CRUD 本身而在权限校验和状态变更逻辑。真正的代码里创建任务时会先校验当前用户有没有权限给某个成员分配任务更新状态时会检查状态迁移是否合法比如“已完成”的任务不能直接回到“待开始”。这些规则如果散落在前端各个地方后期一改就崩。我建议把所有状态迁移规则抽成一个单独的校验函数让所有入口都走同一套判断逻辑避免出现“前端拦了、后端没拦”这种漏洞。3.3 把看板页面做成“一眼能看清”前端的核心是看板页。我的设计原则一个页面把信息说清楚减少跳转。任务列表按状态分栏每栏里是卡片卡片上只放四个核心信息任务名称、负责人、截止日期、优先级标记。当时有一个细节让我印象很深优先级标记用颜色表示后业务方反馈说“看不清”。后来我把“高优先级”的任务加了一个醒目的边框并在卡片左上角加了一个“紧急”角标问题立刻解决了。这件事给了我一个教训视觉设计不能只看美观要服务于扫视效率。看板看板核心就是“一眼看明白”。第一版 Demo 并不需要做得很精致但业务流程必须走得通创建任务、分配负责人、成员更新状态、负责人看板看到进度、周报自动生成。这五步走完需求方的痛点就解决了八成。3.4 验证与迭代不要想一口吃成胖子第一版 Demo 上线后我没有马上铺开做更多功能而是找了两名真正每天做表格汇总的同事试用。然后要求他们连续用一周每天把遇到的问题写在共享文档里。这一周收获的反馈比任何需求会都值钱。有人反馈找不到“修改截止日期”的入口有人希望状态更新时能自动带上备注模板还有人建议把周报自动发送到群聊。我按反馈频率重新排了优先级改入库和前端小步快跑。别小看这个“试用一周收集反馈”的流程它比你自己闷头做一个月功能更有效——因为需求不是你自己想象的而是用户真实使用的。4. 落地过程中躲不开的坑问题与排查实录写代码从来不是这个项目最耗时的部分最耗时的是跟预期不符、跟数据打架、跟环境纠缠。这里整理几个这个项目里真实踩过、也值得所有人注意的坑。4.1 需求变更学会说“这个版本不做”项目做到第二周需求方突然提出要加一个“甘特图”说想要更直观的时间线视图。这个需求听起来很合理但如果当时头脑一热直接做整个排期至少延后五天。我当时没有直接拒绝而是问了一句“甘特图是为了解决哪个具体问题”需求方回答“想看清每个成员的并行任务有没有冲突。”我于是说这个问题用现有的看板加一个“按成员筛选”功能就能解决成本大概是甘特图的二分之一而且下周五就能看到。最后做了成员筛选需求方也满意了。这个案例的原则归纳下来就一句话用户提出的是“解决方案”不是“需求”。我们要翻译回他背后的真实意图再去找更优的实现路径。4.2 数据问题旧数据导入与脏数据清洗我们一开始假设所有任务数据靠手工录入。但现实是团队已经在表格工具里维护了几百行任务记录负责人要求“新系统必须能导入旧数据”否则不接受这个系统。这一步比想象中麻烦。同一任务的名称前后不统一有人写“需求评审”有人写“评审会议”负责人字段还有空值。如果直接导入看板会一片混乱统计也会失准。我的处理方式是导入前先做数据清洗脚本对任务名称做了简单的去空格、统一大小写、同义词映射对缺失负责人字段的数据统一标记为“待指派”并在导入后生成一份“清洗报告”列出所有无法自动识别的数据让管理员手动处理。那次清洗花了一天但我非常确定这笔时间必须花因为垃圾数据进系统后面所有统计都是垃圾。4.3 部署环境的坑本地没问题一部署就白屏部署环节是老生常谈但永远在踩。当时我们把前端打包后放到服务器发现刷新页面就 404排查半天发现是 Nginx 没有做前端路由回退。Vue3 用 history 模式时路由是前端控制的Nginx 默认找不到路径就报 404必须配置 try_files。这个问题的排查其实不复杂但如果没有经验光靠临时搜索也能卡半天。我的建议是前端路由用 history 模式就必须配好对应的服务器回退规则或者干脆用 hash 模式稳定但 URL 里带个“#”号。内部工具我通常直接用 hash省心。类似这种部署问题还有很多比如静态资源缓存策略、反向代理的 WebSocket 支持、服务器时区不一致导致的时间显示偏差。我通常会在上线检查清单里逐项打勾而不是凭记忆——记忆这玩意在凌晨上线的时候最不可靠。4.4 回顾三个最有价值的判断项目复盘时我列了三个自己做对的判断每一个都直接影响项目成败。第一需求访谈做了但做了书面确认避免了后来需求漫天改时的扯皮。第二强制要求每条状态变更都记录进展流水这让周报和统计有了可靠的数据源。第三没有一上来就做甘特图而是用成员筛选先接住真实需求既保住了排期也留出了后续迭代的空间。我不会说自己全程没有失误。失误也有前端权限控制一开始做太细结果管理者觉得操作繁琐后来又简化了。这说明权限设计必须考虑可用性不能只从安全角度出发。安全做过头用户会绕开系统那样反而更加不安全。5. 交付不是终点文档、培训和后续迭代很多项目交付就结束了但我的习惯是交付前必须做好三件事写用户手册、做一次操作培训、约定迭代节奏。5.1 用户手册和培训写文档比写代码更考验耐心用户手册不要写几十页我通常控制在十页以内核心内容是五个部分登录方式、功能入口、常见操作三分钟上手、权限说明、常见问题。配截图比纯文字有效得多。培训环节我安排在周五下午因为那时候大家心态比较放松。培训的时候不用讲系统架构就现场演示一遍真实业务流程创建任务、指派成员、更新状态、查看看板、导出周报。演示完让每个人亲手操作一轮当场处理疑问。经验之谈超过八成的问题都出在浏览器兼容上。内部工具我建议直接限定主流浏览器的最新版本不接受旧浏览器适配的无底洞。用户手册第一句话就是“请使用 Chrome 或 Edge 最新版本访问”。5.2 迭代计划看懂数据再定方向第一版上线以后真正的项目其实才刚刚开始。我给自己定了一个数据观察期为期两周。看什么数据活跃用户数、任务创建数、状态更新数、周报导出次数。这四个指标能反映出系统是否被真正用起来也能告诉你哪些功能是虚的。如果两周内任务创建数持续增长说明系统被日常使用下一步可以做自动提醒、到期预警。如果创建量不高但查看频率高说明用户可能只是把系统当只读看板那就要深挖为什么他们没有更多互动。这种“数据驱动迭代”的习惯让我的后续改进每次都有依据而不是拍脑袋。很多系统死在“不上不下”做了但没人用没人用就没人提需求没人提需求就没人维护最后弃用。要打破这个循环关键就是项目初期少做功能多做数据验证。5.3 个人经验总结空标题项目最值钱的其实是决策过程看到这里你会发现一个“空标题”项目真正值钱的不是那几十行代码而是我在整个过程中不断做判断、做取舍的那套决策过程。技术永远是最不稀缺的部分真正稀缺的是“知道该做什么、不该做什么、先做什么、怎么做能减少返工”的判断力。现在再接到一个只有标题甚至完全没有标题的需求我反而会有点兴奋。因为我知道越模糊的需求越能体现项目负责人的拆分能力和沟通能力。这种能力不是看书学来的是在一个又一个“从零到一”的项目里磨出来的。最后分享一个我一直在用的简单技巧每次项目开完第一次需求会我会用笔在白板上写三句话——“核心用户是谁”“最痛的一个场景是什么”“第一版必须解决什么”。只要这三句话没写明白我就拒绝开工。这不是拖延这是对自己时间和对需求方预算最大的尊重。