常见误区｜出现这些信号，先停下来判断

“代码生成了很多，应该快完成了”

文件越写越多，页面越看越像成品，很容易觉得只差一点。可代码多，只能说明写了很多，证明不了甲方要的东西已经能用。

挑一件实际的事试试：提交一条报名，刷新，再去后台查。如果刷新就没了，前面的成功提示只是摆设。哪些真做了、哪些是假演示、哪些还没试，要分开记。

“AI 都说已经修好了”

它讲得很完整，又列了一串检查命令，你可能就放心了。可命令写出来，不代表真的执行过；它也可能只改了一个表面症状。

按原来出错的几步再做一次，再试试原来好用的地方。日志就是程序自己留下的运行记录，比如保存失败的原因；必要时把它和数据一起查，别只听总结。

“调用 review skill，就完成安全检查了”

看到专业名字，会觉得已经请到一个自动找问题的专家。review 是检查，skill 可以理解为教 AI 按哪些步骤检查的说明书；比如要求它逐个查账号限制。

说明书再好，也得看 AI 看到了哪些代码、能运行什么、实际查了什么。报告说「有漏洞」，就要它指出位置、怎么出现、会怎样；说「没发现」，也不能推成所有地方都安全。

“多个 AI 同意，所以可以执行”

问三个都说可以，很像三个人投了赞成票。但如果它们都拿着同一份错误资料，可能只是一起猜错了。

先找依据：甲方真这么说过吗？实际试过吗？会删数据的操作是谁同意的？业务问甲方，技术上拿不准就找懂的人，不能靠 AI 的数量补上事实和许可。

“修不好，再让它多试几次”

第一次没好，当然想再试。可每次都顺手改更多文件，旧问题还在，新问题又来了，最后连原来能用的版本都找不到。

先停一下，留住现场。写清怎样再出现、最近改过什么、每次试了什么结果。一次查一个原因；不要同时换依赖、改目录、改设置，否则好了也不知道为什么好。

依赖就是项目需要借用的软件或代码库，比如图片处理库。随意升级它，原来的用法可能失效，不一定能修好当前错误。

“只是本地操作，不会影响别人”

窗口开在自己电脑上，确实让人感觉安全。但这个程序可能正在连接甲方的数据库。你在本机点删除，删掉的仍然是真记录。

操作前核对实际连到哪里、账号允许动什么。数据库名字里带「test」也不够，连接地址和真实用途要查清楚。看不懂就先别写入。

“先做完，权限以后补”

先把功能跑起来很有成就感，账号限制看起来像最后加一道锁。可前面如果已经允许随便读取、修改，就可能存了不该存的数据。

权限就是一个账号能做哪些事，比如只能看自己的报名。后端是接收页面消息、真正处理数据的程序；只藏按钮，它仍可能接受别人直接发来的修改消息。

做到提交，就一起做该有的身份和范围检查。还没保护好的功能，只能留在明确的测试地方，不能说已经可以正式使用。

“提示词再长一点就会更可靠”

结果不满意，就再加几句「必须」「绝对」「高级专家」，很像把要求写严就能解决。但缺的可能是事实、工具能力，或者一句话里要求彼此冲突。

先看是哪种问题。比如不提供价格数据，却要求算准预算，头衔再多也没用。把缺的资料补上，把冲突的要求排个先后，再用结果检查是否改善。

“把整个聊天发过去，就不会丢信息”

复制全部聊天看起来最保险，什么也没少。问题是旧要求、推翻过的方案、还没实现的计划也一起进去了，新的 AI 不一定知道哪句才算数。

先整理现在说好的规则、当前代码、做完什么、还有什么问题、接下来干什么。需要细节再附资料，并确认它确实读过。资料多不等于资料清楚。

“备份文件在，就能随时恢复”

看见文件，就像看见手机照片已经上传，心里自然踏实。可它可能没存全、密码丢了，或者只存了数据，没存上传文件。

找个不碰真实使用的测试地方，恢复一次并打开检查。还要算清楚：昨天备份之后的新报名会不会丢，旧程序能不能读。真出事时再第一次试，往往来不及。

“甲方说简单一点，就不用做这些”

听到简单，就容易把问问题、留旧版、做检查都当成多余步骤。但甲方通常是希望功能少一点、使用方便，不是希望记录会丢、别人能偷看名单。

小项目少写文档没问题。至少说清做什么、做到什么算合格、改坏怎么回来，再亲自试一次。省掉这些，后面的返工通常更费事。

怎样控制时间和调用费用？

每次开工先说清这次只做什么、做成什么就停。写一小段能试的功能，马上试；甲方改要求，马上改相关资料，别让后面的 AI 按旧话重做。

不用反复找不同模型全文改写同一份材料。模型就是提供回答的 AI 程序，不同模型能力和价格不同，比如改个标题不一定要用最贵的那个。

也别只看一次便宜多少。如果便宜的回答导致写错、重做两天，总花费未必低。顺手记一下大返工为什么发生，下一次少走这条弯路，比一味缩短提示词更有用。