切换外观
06｜把需求变成能执行的开发方案
本章任务：弄清楚准备用什么做、为什么这样做，以及哪些地方要先试一下。
准备材料：确认过的需求、原型、视觉规范、验收条件和实际限制。原型就是提前讨论用的页面草稿；视觉规范是颜色、字号等样式约定；验收条件是“做成什么样算合格”，比如刷新后仍能查到报名。
本章产出：一份看得懂的开发做法、几次关键试验的结果，以及开工前还缺什么。
技术名称很多，不代表方案可靠
图中提示词仅作为示例，不建议作为实际项目中的提示词使用。
图解：每增加一项依赖，都要说明用途与代价。 查看大图
AI 给活动报名系统写了一长串方案：缓存、消息队列、好几个独立程序。你认不全，但觉得写这么多应该很专业。
先别点头。缓存就是把查过的结果暂存一份，下次少查一次原数据。比如把活动列表存起来，打开时可能更快，但活动改了，这份旧结果什么时候更新？你又多了一件要管的事。
消息队列则像取号排队：先把待办事情放进去，另一个程序稍后处理。比如稍后发邮件。它要安装、配置、观察有没有卡住，也要想清楚处理失败怎么补。
加一个东西，就多一处需要维护。 活动每天只有几十次访问，实际读取并不慢，又没有邮件功能，此时还要加这些吗？让 AI 说明理由，不能用“以后可能人多”替所有选择作决定。
当然，东西少也不自动代表可靠。名额只剩一个，两次审核却都通过了，再简单的方案也没把事做好。
照着做：先看约束，再比较实现
第一步：列出必须满足的条件
这里的“约束”，就是不能随便改变的实际条件。比如甲方只有一台现成服务器——也就是准备长期运行项目的那台电脑，不能再买三台。
先把这些条件列出来：从手机浏览器打开还是别的入口？有无现成代码？多久交付？能花多少钱？数据要保存多久？以后由什么方式维护？
再分清哪些是甲方明确要求，哪些只是你习惯的做法。你喜欢一种写法，不代表甲方要求必须用它。
比如甲方要求使用已有账号登录，就得拿到测试账号和说明资料。接口是两个程序交换信息的入口；这里就是你的项目向账号系统询问“这个账号能不能登录”。
先试这个入口能否连上。 如果等页面做完，才发现对方不提供权限，整个登录办法都可能要换。
第二步：让方案解释一条完整数据流
数据流就是信息从哪里来、经过哪里、最后到哪里的过程。比如你网购时填地址，页面发送给后台，后台保存，刷新订单还能看见。
活动报名也按这个办法讲。别只让 AI 说“前后端分离”，让它讲清点提交之后发生什么：
- 页面送过去活动编号和必要信息。
- 后台确认是谁提交的、活动是否截止、是否已经报过。
- 把这条报名保存下来，状态是待审核，暂时不占名额。
- 返回处理结果，之后还能查到这条记录。
后台就是不直接显示在页面上、负责处理和保存的程序。不能只在页面藏按钮：别人绕过页面直接发消息，后台仍要检查能不能做。
审核也一样。两次操作同时抢最后一个名额时，不能都先看见“还有一个”，再各自通过。方案要说明怎样避免最终多出一个名额，需要试验的地方如实写出来。
仅作为示例，不建议作为实际项目中的提示词使用。
请按现有需求和实际条件，说明这个报名系统准备怎么做。用“点提交之后发生什么”和“点审核通过之后发生什么”来讲，不要只列技术名词。每个重要选择都解释为什么需要、会多出什么工作、有没有更简单的办法。没确认的条件单独留下，不替甲方补答案。
第三步：比较技术栈适配，不只比较名字
技术栈就是做项目选用的那套工具，比如页面用什么写、后台用什么写、数据存在哪里。不是名字越新，组合起来就越适合你。
已有项目先看原来怎么做。只加一个报名字段，通常不值得为了“更新技术”把整个项目换一遍。否则原来能跑的页面、登录和发布方式都得重新检查。
新项目可以比较两三种做法：能完成必要功能吗？甲方的机器能运行吗？有没有清楚的说明？出了问题，你能否找到帮助？以后升级要做多少事？
速度也要放进具体条件里谈。一天几十次访问和一分钟几千次提交不是同一件事。先问实际规模，再试现有做法够不够，不凭想象增加设备和程序。
AI 提到某个工具支持什么，去查正在使用的版本说明。它可能记得旧用法，也可能编出不存在的设置。等写完再发现用不了，前面的代码就白做了。
风险高的部分，先做小试验
图解：先定义通过标准，再执行隔离试验。 查看大图
先试最可能让后面白做的地方，不是现在就偷偷把整个项目写完。
比如已有账号登录：先用假的报名页面和测试账号，试一次正确登录、一次密码错误、一次对方没回应。把账号问题搞清楚后，再围绕它写正式功能。
测试环境就是专门拿来试的地方，和正在使用的真实系统分开。这里用虚构记录，哪怕试坏，也不影响实际报名。
| 你担心什么 | 先试哪一点 | 留下什么 |
|---|---|---|
| 对方的登录入口连不上 | 用测试账号实际登录一次 | 实际返回、缺少的权限、错误原文 |
| 最后一个名额会被抢出两个 | 让两条申请同时尝试通过 | 最后通过数量、处理结果 |
| 换到甲方机器不能运行 | 先放一个最简单的程序过去启动 | 机器条件、运行步骤和结果 |
| 对方长时间不回应 | 在测试里模拟一直等不到结果 | 页面怎样提示，会不会重复处理 |
开始前先说好怎么算试成功。只写“试过了”没用，要说明试了什么、结果是什么、还有什么没试。
拿不到测试权限，就说明哪些工作因此做不了。可以先做其他部分，但别让 AI 写出一堆默认它能连上的代码。
试验用的代码也别直接当成正式成品。为了验证登录而随手写的几行，可能还没有错误处理和必要检查，要另外确认后再保留。
每增加一项依赖，都说明为什么
依赖就是项目运行时离不开的其他东西，比如保存报名记录的数据库，或发送邮件的外部服务。数据库可以理解为专门存放和查询记录的地方，例如活动表、报名表。
每多一个依赖，至少问四件事：它解决什么问题？不加行不行？坏了影响哪里？费用和维护怎么安排？
例如加缓存，可能让列表快一点，但报名人数变了，旧结果没更新，页面仍显示有空位。你得决定何时更新、如何查错，不能只算“读取更快”这一项好处。
再如加邮件通知。可以讨论本期先不做，也可以比较直接发送和排队发送。排队处理还要知道邮件有没有发出去、失败是否重试，不能发送失败却一直没人发现。
把这些事项记下来：用途、实际版本或服务要求、费用、准备情况、坏了怎么办。账号密码和密钥不要写进去；密钥像服务的通行证，别人拿到可能使用你的额度或读取数据。
仅作为示例，不建议作为实际项目中的提示词使用。
请逐项解释方案增加的工具或外部服务。它具体解决哪件已经确认的事？不用它会怎样？有没有更简单的做法？安装、费用、日常检查和出故障处理各多出什么工作？没有资料或还没试过的地方直接说，不因为常见方案里有，就默认我也需要。
把方案拆成可验证的实施顺序
图解：身份、权限、必填检查，要跟着功能一起做。 查看大图
先安排一小段能跑完、能自己试的功能。例如打开活动、提交报名、保存、刷新后还能查到。先把这一段做好，再安排审核和取消。
但“分开做”不等于把保护措施拖到最后。提交报名时，就要检查是谁提交、有没有截止、是否重复；审核时，就要检查后台账号能不能审这场活动，以及名额是否足够。
每一段写清：按哪条规则做、需要先准备什么、改哪里、做完怎么试。不写这些，AI 很容易做出一个提示成功、实际什么都没存的页面。
方案里还要考虑怎么在目标机器运行、出错去哪里看记录、坏了怎么恢复。运行记录通常叫日志，比如写下某次请求何时失败、失败原因是什么，用来找问题。
试验或开发时发现新情况，可以改方案。先说明影响和原因，把资料更新，再继续；别悄悄换掉关键工具，让下次接手的会话找不着头绪。
本章练习
AI 建议给活动列表加缓存，还说审核要先放进队列里。甲方没有说现在慢，也没有给出大量同时访问的要求。
请先写下要问它的问题，再比较不增加这些东西能不能做。你不需要先懂所有代码，至少要听得懂增加它们的理由。
可以想想：列表里的剩余名额会不会变旧？审核点完要等多久？排队程序停了，页面显示什么？这些都没说清，就还不能因为方案“很完整”而接受。
怎样判断本章完成了？
- [ ] 知道什么是甲方硬性要求，什么是偏好，什么还不知道。
- [ ] 能讲出提交和审核之后，信息怎样保存、怎样被再次查到。
- [ ] 每个主要工具都有理由，也知道它多带来哪些维护工作。
- [ ] 容易卡住后续的地方已经试过，或明确哪些工作要等。
- [ ] 测试账号、外部服务、费用等准备情况有记录。
- [ ] 开发拆成几小段，每段做完都知道怎么自己试。
卡住了怎么办？
听到一串名词看不懂，就请 AI 回到“我点一下按钮，后面发生什么”来解释。两种做法互相矛盾时，先比较它们假设的条件，不靠谁说得更自信决定。
最后一个名额怎样防止超额，你仍然判断不了，就带着规则、两种做法和试验结果去找懂的人问。没有验证过就写“还没验证”，比往方案里放一个自信的结论更有用。
本章带走： 一份能解释为什么这样做、做完怎么试的方案。下一章，把这些信息交给真正写代码的 AI，并说清楚哪些事不能擅自动。