第一版网页很少一次就完全满意：按钮点了没反应、手机上排版乱了、想多加一块内容。这时候问题不在编程助手会不会修，而在你给它的信息够不够准。
报错：贴原文，不要转述
「页面坏了」「按钮不好使」这样的描述，编程助手只能猜。好的反馈包含三样东西：
- 你做了什么：比如「在手机宽度下点了菜单按钮」。
- 期望是什么、实际是什么：「期望展开菜单，实际没有任何反应」。
- 完整的报错原文：在浏览器里按 F12 打开开发者工具，切到「Console」（控制台），把红色报错整段复制过来，包括文件名和行号。
截图的问题，用文字描述
排版问题不一定有报错。把你看到的写清楚：「电脑上三张卡片挤在一行，手机上卡片超出屏幕右边，需要横向滚动」。比只说「排版乱了」有用得多。
动手：先看懂报错
自己先大致看懂报错，再交给编程助手，能更快判断它的修改对不对。把你遇到的报错贴进来试试：
▶ 动手试试
系统提示词（这次请求一起发送，点开查看）
你是帮初学者调试网页的老师。用户会贴一段浏览器控制台报错。用通俗的中文说明：1. 这个报错是什么意思；2. 最可能的原因；3. 给编程助手的一段修复请求应该怎么写（包含报错原文和期望效果）。不要直接给出完整代码。
登录后运行登录 HiveGPT 后每天有免费运行次数
1. 意思：第 58 行想给一个元素加点击事件，但这个元素没找到，拿到的是 null。
2. 最可能的原因：脚本运行时页面上还没有这个元素（script 写在了元素前面），或者代码里查找用的 id / class 和 HTML 里写的不一致。
3. 可以这样告诉编程助手：「打开 index.html 时控制台报错：Uncaught TypeError: Cannot read properties of null (reading 'addEventListener') at index.html:58。期望点击菜单按钮能展开菜单。请检查第 58 行查找的元素是否存在、id 是否一致、脚本是否在元素之后执行，只修这个问题，不要改其他部分。」一次只改一件事
改需求时，最容易犯的错是一口气提五个要求。编程助手会一起改，出了问题你分不清是哪个改动造成的。
- 一次一个改动：「把菜单改成两列」做完、看过、提交，再说「加一个营业时间区块」。
- 说清楚不要动什么：「只改菜单部分，其他区块保持不变」。
- 改完先看效果再继续：在浏览器里刷新，电脑和手机宽度都看一遍。
- 能用就提交：每个满意的小改动都
git commit一次。
改坏了：回到上一个好版本
如果连续修了几轮反而越改越乱，不要继续在乱的基础上修。先回到上一次提交：
bash
git status # 看看哪些文件被改了
git diff # 看具体改了什么
git restore . # 放弃所有还没提交的改动，回到上一次提交git restore . 会丢掉未提交的改动，执行前先用 git diff 确认这些改动确实不要了。回退之后，换一种更具体的说法重新提要求。
什么时候该自己动手
编程助手不是每次都比你自己改快。下面几种情况，停下来自己处理：
- 改一个字、换一个颜色：直接打开 index.html 改，比描述清楚还快。
- 同一个问题修了三轮还没好：说明它理解错了，或者问题描述不清。回退，换个说法，或者自己先定位到具体哪几行。
- 它要做你看不懂的操作：比如删除一批文件、安装你不认识的软件包、改用户目录下的配置。先问它为什么，看懂了再同意。
- 它要往页面里放 Key：直接拒绝，这违反了 AGENTS.md 里的规则。
运行前先看一眼
编程助手写的代码和命令，运行前都要看一眼。不确定的命令，宁可先问清楚它会做什么。
小结
- 反馈要包含你做了什么、期望和实际、报错原文；排版问题用文字说清楚看到了什么。
- 一次只改一件事，改完在浏览器里确认，能用就 git commit；改乱了用 git 回到上一个好版本。
- 小改动自己改，修三轮不好就停下换思路，看不懂的操作先问清楚再同意。
下一课：发布你的网站——把做好的网页放到网上，得到一个可以分享的网址。