没当过产品经理，
也能看懂的项目入门课

第 1 课 · 今天先学这一课

接到领导的视频，你的第一步不是画页面

1. 产品经理到底负责什么

在这门课里，你先把自己的职责理解为：弄清用户和业务要得到什么结果，决定先做哪一部分，和团队把它做出来，再核对结果。不同团队分工会不同，最终由你和项目负责人对齐。

这就像筹办一次旅行：你不必亲自开飞机、开酒店，但要弄清谁要去、为什么去、预算多少，以及安排之间是否对得上。对应到这次就是，你不用包办设计、开发、数据和运营，却要把目标、取舍和验收说清楚。

2. 同一句“做个旅行清单”，可以是三种不同项目

这些目标可以兼顾，但第一版资源有限，要先选主次。别因为过去研究过动态重规划，就默认新项目首期也一定要做。

3. 跟项目负责人先确认的六件事

1. 做给谁：先做国内还是出境？已买机票的人，还是还没决定去哪的人？
2. 在什么时候出现：订票后、订单详情、首页，还是用户主动打开？这些入口目前谁负责？
3. 优先解决什么：准备遗漏、查找服务麻烦，还是现有订单后的关联服务购买？
4. 第一版算成功的标准：先验证用户愿意用，还是已经要承担明确交易目标？谁一起验收？
5. 能用什么：能读取哪些行程和订单信息？能接哪些服务？授权和负责人是谁？
6. 时间与取舍：先交研究、可点的页面样稿，还是可上线功能？如果来不及，什么可以不做？

先了解用户是谁、怎样做事、卡在哪里，再形成方案，是用户需求研究的基本路径；不要把团队想法直接当成用户证据。[方法依据 1]

4. 你可以怎么开口

“我先把视频理解成一个方向：围绕一趟明确的行程，在合适的时候告诉用户还要办什么，并接到服务上。我想先确认，第一阶段更看重帮用户少遗漏，还是买机票之后继续承接酒店等需求？我会据此整理首批用户、入口和第一版范围，先和您对齐，再往下画页面。”

这不是暴露“我不会做”，而是在避免大家各自理解成一个项目。你也不必一次问完，先问会改变方向的问题。

回到目录

第 2 课

不要问“你喜欢这个功能吗”，要问“上次怎么做的”

1. 先拿小周的故事试着理解

虚构案例：小周八天后出发，机票订好了，酒店订在其他平台。他只想知道还漏了什么。如果我们的系统因为查不到本平台酒店订单，就每天催他“还没订酒店”，看似主动，实际是在添乱。

你要发现的不是“用户想要 AI 清单”，而是：准备信息散在不同地方，系统又不清楚他办到哪一步，结果提醒不准确。

2. 初学时，先找几位目标用户听具体经历

在允许的范围内，先约 3—5 位近期有相似出行经历的人，做一次小范围探索。尽量包含不同情况：有人全在一个平台订，有人在多个平台订，有人带家人。这个数量只是练习起点，不能代表市场，也不能拿来推算整体占比。

• “上次出行，从买机票到出发，你还做了哪些准备？”
• “哪一件你反复查、差点忘，或到了现场才发现？”
• “你当时怎么解决？大概多花了多少时间？”
• “哪些事情早就办了，却仍然收到提醒？”
• “如果只能替你省一件事，你希望是哪一件？为什么？”

少问：“给你一个超级 AI 管家，你会不会用？”这样的问题容易得到客气答案。需要录音、截图或看订单时先征得同意，能用脱敏材料就不用真实姓名、证件号。

3. 把发现记成能追溯的事实

4. 看竞品，也要分三栏

“没在视频里看到”不等于“竞品没有”。这会直接影响你是否错误地把某个功能当作自己的差异。

回到目录

第 3 课

第一版不要做“小一号超级平台”，先帮一个人办好一件事

1. 先盘资源，不能把“公司有”当成“我能接”

“接口”这个词你会经常听到：就是两个系统交换信息或办理事情的通道。你不必先会写它，但要问清楚能拿什么、做什么、什么时候拿得到、失败时怎么办。

2. 一份可讨论的首期范围

以下仅为练习方案：如果能拿到用户授权的行程信息，并且至少有一个服务入口可用，可以先做：

1. 确认这一趟的目的地和日期；读不到就让用户自己填，不暗中猜。
2. 展示少量相关准备事项，分别写清“已确认”“待确认”和“待办理”。
3. 支持“我在别处办好了”“这次不需要”和纠正误操作。
4. 对至少一项真实可用服务，提供清楚的下一步入口。
5. 用户返回后，能确认结果；没有系统凭证就让用户确认，并注明来源。

首期先不承诺：自动付款改签、全品类出境服务、完整行中重规划、替所有人做签证判断。不是永远不做，而是先避免项目被依赖和风险拖散。

“MVP”可以理解为最小但完整的可用版本。它不是把功能做一半就交差，也不是所有内容写成“敬请期待”。

3. 怎么判断先做哪项

• 不做它，用户还能完成这次核心任务吗？不能，优先。
• 不做它，会不会误导或伤害用户？比如误标“已办理”，先解决。
• 我们有证据它值得做吗？没有，就先用页面样稿或人工方式验证。
• 依赖和工作量确认了吗？开发估算、权限未定时，不向领导拍交付时间。

不用一开始就套复杂打分表。先能说清“为什么先它、为什么不是另一个”，比算出一个漂亮分数有用。

4. 一条完整的使用过程

确认行程 → 看见有用的待办 → 选择一项 → 进入真实服务 → 回来确认结果 → 清单更新，不再错误催办。

这常被叫作“闭环”：开始、行动、结果能连起来。点击了按钮不是办成了，用户说酒店订好了也不等于本平台产生了酒店订单。

回到目录

第 4 课

产品页面不是只画好看，还要画清楚“接下来怎么办”

1. 先画三个场景，不急着学设计软件

1. 确认行程：这是哪趟旅行？日期对不对？多趟行程选哪一趟？
2. 旅行清单：什么已办、什么未知、什么该办？优先显示什么？
3. 一个待办的详情：为什么需要、信息从哪来、去哪里办、已办了怎么记？

画在纸上也行。“原型”就是可讨论页面和操作过程的样稿，不是最终视觉设计，更不是已经做好的 App。

2. 给小周看的页面，可以先这么写

这个例子最重要的不是按钮颜色，而是把“不知道”留成了一个诚实的状态。

3. 不要只设计“做了 / 没做”

“查询失败”不是“未办理”。查询是系统的一次动作，办理是用户的真实情况。查询失败时提示暂时无法核实，不覆盖已有状态。

4. 第一版就要说清的意外情况

• 用户点错“已订好”：能撤回，不必找客服才能改。
• 出发日期变了：核对新日期，重新计算相关提醒；不能假装真实机票已改签。
• 行程取消：取消确认后停止这趟催办；退订退款仍回原服务处理。
• 用户有两趟行程：确认任务属于哪一趟，不能把 A 行程的酒店算到 B 行程。
• 用户在外部办完：允许自己确认，但不要冒充平台核验。
• 网络或服务出错：保留已有内容，告诉用户能重试、手动确认或回原订单查看。

5. “在合适时机提醒”要写成规则，不是一句口号

需要一起明确：什么时候出现、提醒谁、依据什么、提醒几次、什么情况下停止、能不能关闭。视频里的“8 天”只是画面事实，不是适用于所有目的地和所有事项的统一期限。

练习方案可以先只做用户打开页面时的站内提示。要做主动通知，再单独确认用户同意、提醒频率、安静时段与关闭方式，不能默认用户允许持续打扰。

回到目录

第 5 课

AI 产品经理，不是把每个按钮都接上大模型

1. 本项目里，三种工作分开

如果先靠可靠规则就能验证清单有用，这不是“不够 AI”，而是在缩小风险。之后再比较 AI 在省步骤、理解表达或解释建议上是否确实更好。

2. 做 AI 旅行产品，要提前注意的三件事

• 生成得像真的，不代表是真的。坐标、营业时间、天气等字段需要单独核对。新项目要明确每类事实的来源，不只写“请 AI 准确回答”。
• 生成中不能让用户像等死机。让用户知道还在做什么、已有信息是否可看、失败后如何继续。速度目标要测试后共同确定。
• 演示跑通不等于实际用得好。纸面、浏览器、手机、真实服务完成情况要分开验收。长期计划也要与已验证能力分开。

3. 给 AI 写需求，要多写这五项

1. 它能看到什么：只给实现功能所需、允许使用的行程信息，不把整份历史和敏感资料都塞进去。
2. 它允许做什么：解释、提出候选、询问缺失信息；不得擅自声称已办理。
3. 它不确定时怎么办：问清楚、标待确认，或回到可靠信息来源。
4. 它不能用时怎么办：仍能查看已有清单、手动确认或进入原服务。
5. 怎样证明它够好：用真实类型的案例检查误判、遗漏、响应时间和单次服务成本；不能只看一条最漂亮的回答。

费用不能只算一次模型回答。重试、查询、通知和人工处理可能都有成本；“公司有模型”不等于项目资源无限。

4. 先准备一小组案例，反复测

可以先用约 20 个脱敏或虚构案例练习：正常输入、少日期、多趟行程、外部已办理、改日期、取消、查询失败、AI 不可用、用户要求停止提醒。这个数量不是上线合格线，实际覆盖范围由团队和风险决定。

每个案例写清：给了什么信息、应该出现什么结果、绝对不能发生什么。例如：“用户只说计划改到后天”时，应核对日期与行程，不能宣称机票改签成功。

回到目录

第 6 课

把想法写成“别人不用猜你意思”的说明

1. 你会听到 PRD，但先不用怕这个名字

PRD 就是产品需求说明书：把前几课的判断写在一起，方便设计、开发、测试和业务讨论。文档不是合同式“一稿定终身”；有了新事实可以改，但变更和影响要说清楚。

2. 一份已填过的短版示例

3. 跟不同同事讨论不同问题

• 业务负责人：目标、优先级、资源冲突、成功标准。
• 设计同事：用户看得懂吗，下一步明显吗，错误能纠正吗。
• 开发同事：数据拿得到吗，变更怎么更新，失败怎么保底，工作量多大。
• 测试同事：正常和异常怎样验，哪些失败必须阻止上线。
• 数据同事：哪些行为要记录，人数或行程怎样算，如何判断新增效果。
• 运营、客服及相关审核同事：服务谁来接、用户问责谁处理、文案和信息边界是什么。

实际团队可能一人兼几项。先画责任表，别默认产品经理可以替所有人拍板。

4. 开发前开一次“能不能做、如何验”的讨论

你带目标、范围、草图和异常案例；开发带依赖、方案和估算；设计带交互问题；测试带验收风险。会后至少留下：已定结论、未定问题及负责人、交付范围、共同确认的时间。

如果开发说“做不了”，可以问：“是信息拿不到、权限未开，还是这个周期来不及？哪一种更小的做法能先验证同一个问题？”

如果临时加功能，可以说：“能加。我想一起确认：保持日期的话替换哪项？如果都保留，请开发重新估时间，我们再确认范围。”

5. 验收不是“看着差不多了”

验收标准可以写成：给定一种情况 → 用户做一个动作 → 应出现一个可观察结果。

发现会造成错误办理、隐私暴露或虚假完成的严重问题，应阻止扩大使用。正式开放前与团队确认：谁监控、谁处理问题、异常时如何关闭入口或退回安全版本。

回到目录

第 7 课

上线不是结业：有人点，和真的有用，是两回事

1. 三组结果要一起看

具体以哪一项为首要目标，要在开发前和项目负责人、数据同事确定；不要等上线后再挑最好看的数。

2. 用一组纯教学数字理解“转化”

转化就是：从上一环节走到下一环节的人或行程占多少。下面数字全是虚构练习，不是公司数据。

假设统一观察“首次看到清单后 7 天”，每趟行程只数一次，且所统计行程都已走完观察期：

• 1,000 趟行程满足展示条件，其中 800 趟实际看到了清单。
• 200 趟打开清单，100 趟进入某项服务。
• 30 趟有可靠记录证明完成了所观察事项；另有 20 趟仅由用户自报完成，两组不重叠。

“统计口径”就是算数规则：数人还是数行程、算哪个时间段、什么叫完成、取消退款怎么算。同一张表不能前面数人，后面数点击次数。

3. 怎么知道“是我们让事情变好了”

只有上线前后比较，很容易被节假日、促销和人群变化影响。有条件时，与数据同事设计同期的可比组：一组使用新方案，另一组保留原方案，比较目标和负面影响。常说的 A/B 测试，就是用可比的两组验证差异；分组方式、观察期和需要多少样本，不能凭感觉定。

没有足够流量时，先用访谈和小范围可用性测试验证“看得懂、走得通”；诚实说目前还不能证明收益提升。初步结果不等于统计上可靠的业务结论。

4. 你的首次小范围试用汇报

“这次我们验证的是【问题】，先给【人群】试用。看见【真实证据】，还不能证明【暂时无法证明的部分】。当前最影响使用的是【一个问题】，建议下一轮只改【一件事】；如触发【严重风险条件】，暂停扩大使用。”

这是“迭代”：根据真实反馈做下一轮有理由的调整，不是不断往上叠功能。

回到目录

第 8 课 · 动手做一份完整小方案

从“我看懂了”，走到“别人能照着我的说明做”

下面是一个全虚构的教学作业，不是批准过的需求。假设我们只做“住宿安排的手动确认”：旅客已确定一趟旅行，但住宿可能订在别处。把这一个动作讲清楚，就够练一次产品工作。

1. 一页需求：已经填好的示范

2. 三张简单页面：每张只负责一件事

这些是静态示意，不可点击、不会保存信息，也不能办理住宿。正式设计还需补尺寸、可读性和实际手机操作检查。

3. 异常不是附赠项：照这张表逐个走

验收就是拿事先说好的情况试一遍，检查实际结果。把“应该没问题”换成下面能亲眼看到的结果。

4. 五分钟怎么讲，不用逐字念文档

1. 第 1 分钟：为谁解决什么麻烦；哪些是证据，哪些还是假设。
2. 第 2 分钟：为什么只做手动确认，明确不碰真实交易。
3. 第 3 分钟：按三张页面走一次，演示正确完成和误点撤销。
4. 第 4 分钟：挑保存失败、多行程两种情况，讲保护办法。
5. 第 5 分钟：请对方确认一个关键选择，说明下一步和仍缺的条件。

“我现在需要确认的是：这一版是否只解决住宿自报，暂不连接酒店订单？如果同意，我会和开发核对保存能力，再与测试补齐失败场景；交付日期等相关人确认后再写。”

回到目录

第 9 课 · 补齐酒旅业务常识

付过钱、订好了、真的住上了，不是一回事

1. 把一次购买拆开看

这像订一桌饭：写下菜单、付钱、餐厅接单、把饭端上桌，各有一张不同的凭证。对应到这次就是，旅行清单不能因为拿到了付款消息，就宣布旅客已住上酒店。

2. 为什么不能画一条永远往前的直线

在练习里，可以先画“创建订单 → 支付 → 服务确认 → 实际使用”，再加上支付失败、确认失败、取消和退款分支。但真实业务可能有不同顺序，也可能一单涉及多个人、多晚住宿、部分变更；这张图只是帮你提问，不是可以直接交开发的业务规则。

每个状态都问四句：谁给出的？何时更新？它证明哪一步？如果后来变化，谁通知我们？尤其别把“收到申请”误当成“事情办完”。

3. 回到旅行清单：五种来源，五种说法

查不到不等于没买。“没记录”“没权限”“查询没成功”是三种不同情况，页面和验收都要分开。只需给用户必要解释，不必把后台错误细节倒出来。

4. 信息打架时，别让 AI 挑一句顺耳的

虚构例子：旅客手动确认住宿已安排，但本平台的一张酒店订单后来取消了。可能他换订了另一家，不能直接说“你现在没酒店”。

“这张酒店订单已取消。你之前确认住宿已安排，可能是另有安排；请核对这趟旅行的住宿。这里只更新清单，不代你取消或预订。”

先保留两条信息的来源和时间，再按团队约定请用户核对。不同来源可能讲的是不同订单，不能简单用“最新一条盖掉全部”。

5. 顺手学一个：AI 的事实边界

AI 的事实边界，就是它能根据哪些已知材料下结论、哪些必须先核实。它像整理收据的助手，不能因为收据盒里没有一张票，就说你从没买过。对应到这次就是：AI 可以解释待办，却不能把“没有查到”编成“尚未预订”。

回到目录

第 10 课 · 学会读团队的真实需求文档

别先背模板，拿一份做完的需求对着页面看

本课教你如何申请和阅读材料，没有引用任何团队的真实文档。下面用“住宿手动确认”作虚构示范；请在获准的范围内换成自己团队的案例，不把内部资料搬到公开网页或未获批准的 AI 工具。

1. 请求一个小案例，而不是一次索要整个资料库

“方便给我一份近期已上线、范围比较小的需求吗？最好能一起看到对应页面和验收结论。我想先弄清你们实际怎么写、怎么协作，再按同样方式试写一小段；只在获准范围内学习，不对外传播。”

优先选一个入口、一段流程、负责人明确的功能。不要先挑横跨多个业务的大项目。还没拿到授权或材料，就先用本教程练，不能编造“已研究团队案例”。

2. 第一遍找骨架，第二遍逐页对照

第一遍只圈六处：为什么做、给谁用、改哪里、这次不做什么、怎样算通过、还有什么没定。PRD 就是产品需求说明书，用来把这些事讲明白；不同团队的标题不同，不必机械凑模板。

第二遍打开实际页面：从入口走到结束，把每个点击、提示、返回和失败情况对应到文档。原型是页面操作的样稿，设计稿是更具体的视觉说明；都要核对是不是最终上线的那一版。

文档与页面不同，不要立刻认定“开发做错了”。可能是版本不同、展示条件不同，也可能后来改过；先核对证据，再判断是不是问题。

3. 顺着一项功能，找出谁接谁的工作

输入就是“开始前需要拿到什么”，输出就是“做完要交给下一位什么”。负责人不只是名字：要知道他能确认哪件事、还依赖谁。真实分工以团队约定为准，下表只是学习用参考。

“评审”是大家一起挑缺项、定规则，不是你单方面念稿；“提测”是把版本交给测试检查，不等于已经通过；“回滚”是出现问题时退回安全的旧版本，不是把问题藏起来。遇到听不懂的词，问它在这次工作里意味着什么动作。

4. 学排期，先看依赖，不先猜哪天上线

排期就是共同确认各段工作的时间。把“我要三天做完”拆成：谁先交什么、下一位何时能开始、测试和修复留多久、什么变化会影响日期。

“这个日期是目标时间，还是相关负责人已经确认的安排？住宿状态由谁提供、什么时候能用？如果它晚到，哪些工作能先做，哪些必须等？最终开放前由谁确认可以继续？”

用一张小表记下“事项、负责人、前置条件、约定时间、当前卡点”。不知道就写待确认；需求变更时一起重看范围和时间，不能替开发或测试许诺。

5. 读完后，交一份复述，比说“学习完了”有用

“我理解这个功能解决的是……，这次只改……。用户从……进入，完成后看到……；失败时……。需要……先提供……，由……核对验收。文档和页面有两处我还没对上：……。这个理解是否准确？”

回到目录

第 11 课 · 模拟一次需求评审

被问住没关系，最怕把没确认的事说成定了

本课沿用第 8 课的住宿手动确认练习。下面的会议、问题和回答都是教学示例，不代表任何团队的真实流程或承诺。

1. 开会前，先准备这四样

• 一页说明：问题、目标、做什么、不做什么、还缺什么证据。
• 三张页面：从哪里来、怎么操作、成功和失败后去哪里。
• 异常表：断网、重复点击、误操作、多趟旅行、日期变更。
• 待拍板清单：每个问题写上自己的建议，以及该请谁一起决定。

会前注明材料版本。先请相关人看会改变范围的选择，不必等每个字都润色好才让人知道你在做什么。

2. 开发、测试、负责人可能怎么追问

3. 用 AI 当陪练，而不是让它替团队拍板

下面这段可以复制到获准使用的 AI 工具。只放虚构案例或允许输入的材料，不放客户信息、真实订单、内部截图和敏感文档。

我在练习产品需求评审。下面分为【已经确认】【教学假设】【待确认】【我的方案】四部分。请先复述你理解的目标，发现矛盾先问我。然后依次扮演产品负责人、开发、测试，每轮只问一个会影响实现或验收的问题，等我回答后再继续。指出我哪里没有回答、哪里把假设说成了事实，并让我自己改。不要编造调研、系统能力、接口权限、工期、收益或领导意图；不能替真实团队批准方案。最后给出“已讲清、待补、要找谁确认”三栏，不给虚假的任职评分。

示范一轮：AI 问“没有订单为什么显示未预订？”你答“因为没查到”。陪练应指出证据不足，追问查询范围和是否失败。你改为“当前范围未查到记录，请用户确认”，而不是请求 AI 把原答案写得更专业。

4. 会后别只发“已对齐”

教学会议纪要：
本次确认：仅做住宿自报，不改变真实订单。
调整：保存成功才更新；重试前核对结果。
未定：旅行日期改变后如何处理旧标记。
下一步：产品整理两种处理建议，开发说明能力限制，测试补日期变更案例；确认人与回复时间共同约定。
版本变化：把新增规则标出来，请受影响的人复核；会议没有确定上线日期。

如果两人意见相反，写清争议、影响和可选方案，交给有决定权的人。不要将沉默、表情或一句“先看看”记成正式同意。

回到目录

第 12 课 · 入职第一周与后续学习

别急着证明自己什么都会，先让别人知道你做事可靠

下面只是可调整的个人行动建议，不是团队制度、强制日程或五天上手保证。相关会议、材料和负责人都需要在真实团队里确认。

1. 五天行动表：每天都有小成果，也留出纠偏机会

2. 听不懂时，怎样问得具体

• “这个词在这次需求里，对应哪一步操作？方便拿现有页面举个例子吗？”
• “我复述一下：需要你们先提供住宿状态，我们才决定清单文案。这样理解对吗？”
• “这是现在线上已经有的，还是计划要做的？有没有可看的演示或说明？”
• “我先补 A 和 B，C 涉及业务规则想请你确认。我们什么时候看这一小段合适？”

先查获准资料、整理自己的理解和具体卡点，再集中问。涉及金额、交易、权限或用户权益时，不能因为怕显得不懂而自行猜答案。

3. 对方问“写需求和梳理 App 细节没问题吧”，怎样稳妥回答

“我愿意承担需求梳理和推进，也会对自己负责的内容讲清楚、跟到验收。正式产品交付经验还需要补，我想先按团队已有案例把目标、流程和异常整理成一个小版本，请您和研发同事校准；确认方向后再展开。涉及技术能力和上线日期，我会与相关负责人确认，不单方面承诺。”

这不是让你每次都强调自己是新手，而是让责任和学习方式说得真实。已经答应承担工作，也可以在真正开始时把交付方式约定清楚。

4. 只保留一个随手工作本

今天已确认：……（谁确认、依据是什么）
我交了什么：……（讨论稿／待审核／已确认分开）
最影响下一步的卡点：……
我的建议：选 A，因为……；代价是……
需要谁做什么：……，约定时间……
下一次给对方看的东西：……

紧急问题及时说，其余按商定节奏集中反馈。催办要带着“缺什么会影响哪里、有没有替代路径”，而不是只问“好了没”。

5. 先学什么，哪些暂时不用学

不要把“多个 AI 一起工作”当成高级岗位证明。一个 AI 配合可靠系统也可能把事做好；很多 AI 协作也可能增加成本和出错点。岗位成长看你能否定义问题、做取舍、拿到反馈、对结果负责，不是用了多少技术名词。

6. 从小练习走向 AI App：下一份作业怎么加难度

虚构进阶题：用户说“我周末想出去两天，带老人，别太累”。不要马上让系统订酒店。先列缺失信息：出发地、具体日期、人数、预算、出行限制；只追问会影响当前方案的部分。涉及个人信息时只取完成服务所必需的内容，并按获准规则处理。

1. 先理解：把用户明确说的和 AI 猜的分开，请用户确认关键条件。
2. 再查证：路线、价格、库存等需要可靠来源和更新时间；没接通就说明不能确认，不编造实时结果。
3. 再建议：给可比较的候选和理由；用户改预算时说明哪里跟着变，不悄悄改掉其他已确认条件。
4. 最后才办理：涉及购买，先展示具体服务、价格、条件和费用，获得明确授权，再由获准系统执行；结果未知时核对，不盲目重下单。
5. 还要能兜底：超时、无库存、信息冲突时讲清限制，允许改条件、退出或按项目实际能力转到可靠服务渠道。

这份进阶作业交“一段正常对话、一段追问、一段失败退路、确认购买前的说明”。无需自己训练模型，但必须说清哪些话算建议、哪些动作真的会影响订单。

顺手学一个：评测

评测就是拿固定的一组例子反复检查 AI 是否做对，而不是随便聊两句觉得不错。像给餐厅留一份试菜清单，换了厨师也要检查咸淡和熟没熟。对应到这次就是：把“日期不清、没查到订单、查询失败、重复请求、用户改主意”等案例留下，明确该问什么、不能说什么，改版后再检查。

回到目录