07｜开工前，把资料、理解和修改边界交代清楚

本章任务：把当前项目交代给 AI，检查它有没有理解错，再说清哪些能改、哪些得先问。
准备材料：确认过的需求、页面草稿、样式约定、开发做法，以及验收条件。验收条件就是“做到什么样算合格”，比如没权限的后台账号换个地址也看不到别的活动。
本章产出：一份当前资料目录、一份进度说明、一份改东西的规矩，以及改坏后怎样恢复的安排。

为什么新会话不能只说“继续开发”？

图中提示词仅作为示例，不建议作为实际项目中的提示词使用。

图解：文件放在那儿，不代表 AI 读过。 查看大图

你在上个会话说清楚了：提交先待审核，通过才占名额；截止前取消已通过的报名，要放回一个名额；取消待审核的，不能凭空多出名额。

换了个会话，你只给它几张页面图，再说“继续”。它不知道前面这些决定，可能按提交就占名额来做。页面一样，里面的逻辑却是另一套。

更麻烦的是，它可能看到一个旧文件，觉得那才是要求。你后来拿新规则检查，它也会说自己没写错。

所以先确认 AI 现在能看到的信息。 旧会话说过，不代表新会话知道；文件在目录里，也不代表它真的打开读了。

照着做：给开发会话一份清楚的起点

第一步：整理当前有效资料

图解：旧的版本收起来，别混进去。 查看大图

先做一张资料目录，像给一摞文件贴标签：哪份是当前需求，哪份是页面草稿，哪份写开发方法，哪些问题还没问清。

每项写清放在哪里、哪天确认、有什么用途。旧文件留着，但明确写“旧版，不照这份开发”。如果两份资料互相矛盾，先问清楚，不让 AI 自己挑一份。

例如原型里有候补按钮，但需求写本期不做候补。得先改掉或标明它不属于本期，否则开发会话可能顺着图把整个候补功能做出来。

已有代码时，还要记下怎么启动、当前保存的是哪个版本、最近改了什么、有没有尚未保存到版本记录里的改动。版本记录就像代码的存档，比如“修改取消功能前”的那一次保存。

只写做过的检查。命令已经列好但没有运行，要写“还没试”，不能写“测试通过”。否则新会话会跳过真正需要检查的地方。

这张目录不用很长，能让 AI 找到当前资料就行。把全部聊天重新粘一次，里面夹着旧主意，反而更容易弄混。

第二步：交代当前任务与现场状态

不要只给它整个项目目标。还要说：现在做到哪里，这次先做哪一小段，什么不能碰，缺什么暂时做不了。

比如“活动详情已经有了，这次只做提交后保存、刷新还能查到；审核和取消以后再做”。这样你能检查它有没有跑题，而不至于突然收到几十个新页面。

临时改过的决定，先补进资料。不能新规则只在你脑子里，文件里还写旧的，再要求 AI 自己猜到。

仅作为示例，不建议作为实际项目中的提示词使用。

我会给你当前资料目录。先打开里面的文件，再看现有代码，不要马上修改。告诉我你实际读了哪些、哪些打不开、哪里有矛盾。这次只做提交报名、保存、再查到结果这一小段。已有改动先保留，审核和通知等其他功能不要擅自添加。资料不够就问我。

如果它打不开文件，就提供必要内容，或换一种交付资料的方法。不能只凭文件名就接受“我理解了”。密码、服务密钥和真实个人资料，也不必因为交接就全部给它。

第三步：让 AI 复述，并用场景核对

复述就是让它用自己的话讲一遍准备做什么。你不是检查它会不会复印项目简介，而是看具体事情有没有讲错。

例如先问：“取消待审核的报名，会不会多出一个空位？”如果它回答会，就说明它没理解“待审核还没占名额”。这个错现在改一句就行，等代码写完再改，可能要动好几处。

再问：“只剩一个名额，两条申请同时审核，会怎样？”“后台账号换个活动编号，能不能看别的名单？”让它区分已经确认的规则、准备采用的做法，以及还没试过的部分。

仅作为示例，不建议作为实际项目中的提示词使用。

请先用自己的话解释当前要做的功能。拿提交报名、取消待审核记录、最后一个名额同时被审核、后台账号查看别的活动这几个情况举例。指出答案来自哪份资料，哪些只是你的建议。发现矛盾先说，不要选一个猜着做。等我确认你的理解和这次范围以后，再开始修改。

你发现它理解错了，就指出哪句话不对，把正确决定写回资料，再让它重新讲受影响的部分。不用每次把整个项目从头讲十遍。

“完全理解”不是保证书。如果登录条件没查清，暂时可以做不需要登录的页面草稿，但不能把猜出来的登录方法当成已确定方案。

把授权边界写成具体操作

授权边界就是“允许动什么、动到什么程度”。比如可以在测试项目里改按钮文字，但不能为了修按钮，顺手升级整个项目用的工具。

甲方说“功能这样做”，也不代表你可以直接删掉正在使用的报名数据，或者开一个要收费的服务。这些要单独确认。

准备做的事	先说清什么
在独立测试项目里改一段代码	哪些文件能动，改完怎么试，坏了怎么退回去。
改大家共用的功能或交换信息的入口	为什么非改不可，哪些页面会一起受影响，有没有别的办法。
安装新工具或增加付费服务	解决什么问题，多出多少费用，日后需要管什么。
删除记录、改真实运行设置	目标到底是哪一套，谁允许做，有没有备份，怎样恢复。

不能只交代“危险的先问我”。什么算危险，AI 和你可能理解不同。最好明确写出具体环境、文件或数据，以及允许的动作。

后果可以很具体：为修一个报名报错，AI 升级了页面工具，登录页也不能用了；你再让它修，改动越来越多，先前好用的地方全得重新试。时间和调用费用就是这样耗掉的。

所以范围扩大时，先听它解释原因、牵扯到哪里和替代做法，再决定。允许改一次测试数据，不代表以后所有数据操作都不用问。

数据库变更：先设计迁移，再考虑执行

图解：连的哪个库、有没有备份、谁同意了，缺一样先别动手。 查看大图

数据库就是存放报名等记录的地方，可以先想成一本分成多张表的账本。“字段”是表里的一项，比如报名时间、审核结果。

现在要增加“取消时间”。AI 说重建表最快——就是拆掉旧表，再造一张新的。你自己练习的空表可能无所谓，但里面已有三百条真实报名呢？

标题里说的“迁移”，就是把存放数据的方式从旧样子改成新样子。比如在原来的表上一点点加字段，不推倒重来。它仍然需要检查，不能看到没删表就认为没有风险。

执行前至少把下面几件事说清楚：

• 连的是哪里？ 本地启动的程序，也可能连到真实数据库。
• 具体改什么？ 加一项取消时间，还是删除旧项、改变原来数据的含义？
• 旧记录怎么办？ 以前的取消时间没存过，就不能凭空补一个时间。
• 旧程序还能读吗？ 新表改完，原来的代码可能还在运行。
• 怎么试，失败怎么办？ 不只要有脚本，还得知道恢复哪些东西。

先在独立测试库里，用虚构或去掉敏感信息的数据演练。备份是保存某个时刻的数据副本；恢复就是把它重新读回来。只看见一个备份文件，不代表真的恢复得了，要实际试过。

退回旧代码，不会让数据自动回到旧样子。 同样，恢复昨晚备份，今天新增的报名可能就没了。必须先说明会丢什么、能否补回来，不能到失败后才发现。

有时可以先加新字段，让新旧代码都能用，等切换完成再清理旧项；有时得保留现有数据继续修。不会判断就带着具体改动找懂的人问，别让 AI 直接试真实数据。

仅作为示例，不建议作为实际项目中的提示词使用。

现在只讨论给报名表加取消时间，不执行修改。请先检查现有表和数据情况，说明准备加什么、以前的记录怎么办、旧代码还能不能用。列出在测试库怎么试、怎样知道改对了、失败怎样恢复，以及可能丢哪些数据。没有获得指定数据库的允许前，不读取或修改真实数据。能在原表上加字段，就先解释为什么不必重建。

每一步结束，留下下一次能接上的记录

结束前留几句话：改了哪里、为什么改、实际试过什么、结果怎样、还有哪些没做、下次从哪里开始。

比如“提交已经能保存，刷新能查到；取消还没做；审核只画了页面，不能真正处理”。这比“基本完成”有用得多。

聊天越来越长、AI 开始忘事时，先把当前事实整理出来，再决定是否换会话。一直重复“按前面说的做”，它也可能找不到你指的那句话。

记录里不要留下密码和真实个人信息。它的用途是说明项目现状，不是把所有凭据打包交出去。

本章练习

AI 遇到字段报错，打算删除报名表再重建，还说“本地操作，很快”。

你先别批准。写出要问的几件事：实际连接哪里，里面有没有记录，只加缺少的字段能不能解决，已有修改有没有保存，备份能不能恢复。

再想想：如果它用“先删了再说”才能继续，这一步你能自己判断吗？判断不了就保留错误和现场，找懂的人看，不必硬着头皮答应。

怎样判断本章完成了？

• [ ] 当前资料找得到，旧版和新版不会混用。
• [ ] AI 实际读过关键资料，没执行的检查没有说成通过。
• [ ] 它用具体例子解释过规则，理解错的地方已经纠正。
• [ ] 这次先做什么、不能碰什么已经说清楚。
• [ ] 改数据之前，知道目标、影响、检查和恢复办法。
• [ ] 有风险的允许对应具体操作，没有一句“全都交给你”就放行。

卡住了怎么办？

不知道改动会影响多少地方，就先停止扩大修改。保留代码、报错、实际连接目标和最近操作，带着具体问题去找有相关经验的人问。

没备份、没确认允许、也不知道怎么恢复时，先别动真实系统。可以继续用虚构数据试办法，不需要为了让项目“继续往前”赌一把。

本章带走： 一份换会话也能接上的说明，以及哪些能动、哪些先停的具体约定。下一章开始一小段一小段地做，每段完成后都亲自试一下。