检查清单与记录模板

做到哪一步，就来这里挑需要的表。不用全部填一遍，同一件事也不用存好几份。密码、真实名单和密钥别写进准备公开的资料。

一｜需求问题记录

要记什么	怎样写
问题编号和原话	第几个问题，甲方原来怎么说
你现在怎么理解	哪些确定，哪些只是猜的
还要问什么	比如审核通过后能不能取消，为什么需要确认
甲方怎么回答	哪天、在哪说的，有没有补充
现在能不能继续	已说清、只回答一半、没回答；哪件事得先等着

确认的规则编上号。甲方后来改口，保留前后记录，别直接删掉旧话，不然过几天谁也说不清为什么变了。

二｜原型演示记录

原型就是正式开发前的页面和操作草稿。比如用假记录演示从报名跳到结果页，先让甲方看懂准备怎么做。

要记什么	怎样写
这次演示哪件事	比如从提交报名走到后台审核
开始时是什么情况	活动没截止，账号可以访问
依次点哪里	按真正使用顺序写
应该出现什么	提交后待审核，审核后显示通过
哪些只是演示	哪些是假数据，哪些没连接真实保存
甲方提出什么	原话和对应页面
最后决定怎么改	改样式还是改功能，哪些资料也要改

失败、没数据、没有权限时也要展示。权限就是账号能做哪些事，比如只允许看自己报名的记录。

三｜技术决定记录

要记什么	怎样写
要解决什么麻烦	对应哪个已经说好的功能
比过哪些办法	至少说清有没有更简单的做法
为什么选这个	时间、费用、会不会维护，实际理由是什么
还要准备什么	比如额外安装的程序、外部账号或服务
花多少钱	哪些免费，哪些按用量收费
真试过什么	条件、结果，以及还没试的地方
什么时候要重新考虑	比如人数明显增加，或者外部服务用不了

不懂的技术名字先问到明白。没有测过，就别写「肯定很快」；只因为自己熟悉，就如实记「我比较熟悉」。

四｜开发会话交接

会话就是一次聊天。换了聊天窗口，别以为新的 AI 自然知道前面做过什么。

要记什么	怎样写
当前资料在哪	现在有效的需求、页面草稿、样式和开发方案
当前代码是哪份	版本、位置，哪些改动还没保存成一个版本
已经做成什么	真正可用的功能，不把计划写成完成
这次只做什么	哪些暂时别做，缺什么材料才能继续
你实际试过什么	步骤、结果、截图或程序记录在哪
哪些不能直接动	删除数据、增加费用等，需要先问谁
接下来怎么做	下一件事、没解决的问题，以及改坏了怎么恢复

让新会话说明读过哪些资料。打不开的就说打不开，不能只看文件名猜内容。

五｜一条功能验收记录

验收就是检查「做到什么样算合格」。比如最后一个名额审核通过后，再审一条必须被拒绝。

要记什么	活动报名示例
按哪条规则检查	第 2 条：只有审核通过才占名额，不能超过上限
开始时准备什么	假活动限 30 人，已有 29 条通过
你做什么操作	把一条待审核报名改为通过
本来应该怎样	通过数变 30，重新查看也一样
实际发生什么	试完再填，不提前写「通过」
怎样证明	哪个版本、哪个测试位置、截图或程序记录
这次没试到什么	两次同时审核要另外试，不能默认也没问题

一次成功只证明这一次的条件。失败情况、账号限制和同时操作，分别准备检查。

六｜AI 审查问题记录

审查就是让 AI 检查代码和设置，找可能有问题的地方。比如它发现换个报名编号就能看到别人资料，你还得按它说的办法核实。

要记什么	为什么要记
哪里有问题，怎么出现	能找到文件和操作办法，不是一句「有风险」
为什么算问题	违反甲方哪条要求，或者可能造成什么损失
有什么根据	它看到了什么、实际试了什么
你核实后怎样	真有问题，还是 AI 看错了，依据是什么
准备怎样改	为什么要这样改，有没有动得更少的办法
改完有没有影响别的地方	原来允许的操作还行不行，相关页面有没有坏
还剩什么没解决	谁继续查，什么时候处理，能不能交付

没看过、没运行过的部分，写清楚。不能把「没有发现」写成「已经保证安全」。

七｜Bug 求助材料

Bug 就是程序做错了或没按预期工作，比如取消成功后刷新又变回已报名。

要带什么	怎样写
你想要什么结果	取消后应该一直显示已取消
实际怎么了	刚点成功，刷新又恢复
怎样能再出现	从登录开始，尽量少的几步
在哪里、哪版发生	测试还是正式使用，代码和软件版本
最近动过什么	哪次改动之后开始出现
看到什么错误	原始报错、时间、相关程序记录
已经试过什么	每种办法的实际结果，别只列方法名
希望帮你判断什么	现在卡在哪个具体问题

发出去前隐藏密码、真实姓名和联系方式。换成假编号时保持前后一致，否则帮你的人也接不上发生顺序。私有代码能否提供也先确认。

暂时找不到帮助，就留住能用的版本，先不碰可能丢数据的操作。几个 AI 都赞成，也不等于你有权动甲方的数据。

八｜高风险变更说明

动手前要回答	具体内容
到底要动哪儿	哪台机器、哪个数据库、哪些记录
为什么非改不可	解决什么，有没有不删除数据的办法
会影响什么	哪些功能、已有记录、使用时间和费用
谁同意了什么	允许的具体操作，不是一句笼统「可以改」
改坏了怎么回来	保存过什么，是否真的恢复试过
怎样算成功，何时停	具体检查结果，出现什么立刻暂停
改完谁继续看	观察什么，发现问题找谁

换回旧代码不一定看得懂新数据；恢复昨天备份又可能丢掉今天记录。把这些后果写出来，不只写「失败就退回去」。

九｜发布与交付

发布就是把新版本换到实际使用的地方，比如甲方正在访问的网站。交付还包括让甲方知道怎么用、怎么处理故障。

• [ ] 知道交的是哪一版，需要的软件版本也写清了。
• [ ] 换个没有你私人设置的地方，照说明也能启动。
• [ ] 设置怎么填、密码怎么拿说清了，秘密没有公开。
• [ ] 调整数据的步骤试过，备份也真的恢复过。
• [ ] 主要功能、失败情况和账号限制都检查过。
• [ ] 没做、没试和已知有问题的地方已经说明。
• [ ] 甲方按说好的规则实际用过，结果有记录。
• [ ] 出错什么时候停、怎么恢复、以后找谁都说清了。

十｜做完后的理解检查

问自己什么	怎样证明
点提交后经过哪几步	能找到发送、检查、保存和返回结果的代码
为什么允许或拒绝	能拿甲方一条规则说明代码里的判断
能不能改一点	先猜影响，再改一个小地方并实际试过
还不会什么	写成下次要找出来、要试一次的具体问题

没做到就如实记。背得出 AI 的介绍，和自己能找到、能判断，不是同一件事。