企业官网建设流程全解析

同一个生活工作台，HY3（混元3）做了三遍还在报错，最后连一个能双击打开的成品都没交付；切到 DS4（DeepSeek 4）后，一次把三个真 bug 全定位出来，逐个修掉，再用「真实双击」的方式把每项修复都验证通过。

差在哪？不是谁更会写代码，而是两件事：推理是不是在绕路，编码是不是够精准，验证是不是够科学。

这篇文章不聊参数表，就把这一单从头到尾摊开讲：报错到底分几层、HY3 卡在哪个假想上、DS4 的推理和编码各自做了什么、我事后总结的五条调试心法。

一、先还原现场——一个「一键做同款」，怎么变成了排障现场

任务本身不复杂。我想用 WorkBuddy 的资料库能力「一键做同款」，把参考页那个「日常集 · 生活工作台」复刻成一个集成式的本地工作台，包含七个模块：

中途需求收窄过一次——用户拍板「我要的就是本地版本」，于是目标变成：一个单文件 HTML、双击即开、数据存本机浏览器、零外部依赖。

问题就出在这里。第一轮用 HY3 跑，我从头到尾没拿到一个能正常双击打开的成品，看到的是一连串报错。

二、HY3 卡在哪——把「报错」和「环境」混为一谈，原地打转

复盘这一单，HY3 身上暴露的问题，不是「不会写」，而是两个更隐蔽的毛病。

毛病一：报错没分层，一看报错就慌。

当时实际出现的报错分了两类，性质完全不同：

HY3 把这两层搅在一起了。撞上 429、400 就当成「任务做不下去了」，反复重试、反复卡住；而代码侧那三个真 bug，它从头到尾没当成问题去查，一直在服务侧的报错上打转。

毛病二：目标不稳，在线版和本地版之间反复横跳。

任务先是要「数据在线双向同步」，后来又改成「本地版本」。这个需求变化本身没问题，但 HY3 没有据此重新收敛目标，而是两头都抓：一会儿去建资料库数据表，一会儿又改回 localStorage，来回折腾，每一步都没走完，自然交不出东西。

说实话，这里我也有责任——需求中途转向，我没把「现在只做本地版」这个决定钉死。但 HY3 的表现，是把「环境/服务」当成了主要矛盾，而真正的矛盾——代码里那三个 bug——一直被晾在一边。

三、DS4 怎么破——推理先定位，编码再精准改

切到 DS4，同样的现场，它走的是完全不同的路线。我把它的动作拆成「推理」和「编码」两段看，因为这两段恰好是它和 HY3 拉开差距的地方。

推理模式：不猜，先分层定位

DS4 没有一上来就改代码，而是先做了一件 HY3 没做的事——先把「到底哪坏了」查清楚，再动手。它的排查是一条清晰的漏斗：

第一步，做静态语法检查。把 HTML 里那 9.5 万字符的内联脚本抽出来，单独跑一遍语法检查：

node--check/tmp/_inline.js

结果是语法通过。这一步排除了「代码根本跑不起来」这种低级故障，把范围缩小到「运行期逻辑 bug」。

第二步，做真实场景冒烟。关键在这里——它没有用 WorkBuddy 的预览面板测，而是用file://协议直接打开这个 HTML 文件，模拟用户「双击」的真实场景，同时把运行期的报错全部拦下来：

page.on('pageerror',e=>errors.push(e.message));page.on('console',m=>{if(m.type()==='error')errors.push(m.text());});awaitpage.goto('file:///.../index.html',{waitUntil:'load'});

这一步价值很大。预览 iframe 里往往注入了资料库 SDK，会把某些 bug 掩盖掉；而file://双击是零注入的，能暴露出「没有 SDK 时页面到底能不能跑」这个真实问题。

第三步，用 DOM 探针定位具体 bug。冒烟测试跑完后，不再凭感觉，而是直接查 DOM 里的具体元素，把每个可疑点都变成「有/没有」的硬结论。

三步走完，三个真 bug 全浮出来了。下面是它们各自的样子。

编码模式：行级精准修改，不用大锤

定位之后，DS4 的改法也很克制——用行级替换，一处一处改，而不是把整个文件重写一遍。这种「小切口」的改法，最大好处是不会顺带改坏别的东西。这一单里最典型的是时光档案那一处，后面单独讲。

两个模型面对同一个现场，行为差异可以浓缩成一张表：

四、三个真 bug 逐个拆——白屏、失效、英文 key

Bug 1：boot 里的硬门，导致双击直接白屏

这是最致命的一个。本地双击打不开，根子在初始化函数里的一段硬门逻辑：

vardb=window.__SMART_PAGE__&&window.__SMART_PAGE__.database;if(!db){showAlert('没有检测到资料库的运行环境……');refreshAll();return;}

看懂了吗？它先判断「有没有资料库 SDK」，没有就直接弹错、返回，后面的渲染根本不执行。用户在本地双击这个 HTML，浏览器里当然没有__SMART_PAGE__，于是直接白屏 + 弹错。

DS4 的修法不是删掉这段，而是给它配一个「降级兜底」——没有 SDK 时，用 localStorage 模拟一套同样接口的本地数据库：

vardb=(window.__SMART_PAGE__&&window.__SMART_PAGE__.database)||makeLocalDB();varIS_LOCAL=!!db.__local;

makeLocalDB()实现了query / addRecord / updateRecord / deleteRecord这一整套接口，只是底层从云端换成了 localStorage。这样，同一个页面，有 SDK 走在线，没 SDK 走本地，两套环境自动切换，硬门也就不需要了。

Bug 2：记账「分类筛选」是个摆设

需求里明明白白写了「分类筛选」，但实际打开，流水面板那个下拉框里只有孤零零一个「全部分类」，点开什么都没有。

查下去发现，过滤逻辑其实是有的，renderMoney()里已经写了按分类过滤的代码，但下拉框里的分类选项从来没被填进去。等于过滤器装好了，筛选项没接上。

修法是在渲染枚举的时候，从数据里 + 枚举定义里把分类收集起来，动态填进下拉框：

varcats={};rows('money').forEach(function(r){if(r['分类'])cats[r['分类']]=1;});pickOpts('money','分类').forEach(function(o){cats[o.text]=1;});fillSelect($('#moneyFilter'),Object.keys(cats),'全部分类');

改完后下拉框里出现「其他 / 餐饮 / 居家 / 交通 / 购物 / 医疗 / 学习 / 娱乐 / 人情」十个分类，筛选真正可用。

Bug 3：时光档案里冒出英文 key

时光档案是「回看生活」的页面，把各模块的记录按日期汇总成时间线。结果每条记录右边的小标签，显示的是planner、money这种原始表名，而不是「日程统筹」「记账理财」。

根因很简单：渲染的时候直接输出了内部 key，没做中文映射。修法就是加一张映射表，显示时用中文，过滤时仍用原始 key：

varMODULE_LABEL={money:'记账理财',fitness:'减脂健身',planner:'日程统筹',shopping:'待买清单',media:'书影音'};// 渲染时：'<em>'+esc(MODULE_LABEL[x.k]||x.k)+'</em>'

三处都是「看起来小、一查就明」的 bug，但 HY3 始终没走到「查」这一步。

五、措施为什么科学——五条可复用的调试心法

这一单最有价值的，不是那三行修复，而是 DS4 排查问题的那套动作。我把它们提炼成五条，每条都能直接套用到别的项目上。

第一条：先验证，再修改，别靠假设。HY3 的问题是默认「代码是对的，环境有问题」，所以一直去搞环境、搞部署。DS4 反过来，先做语法检查、再做冒烟测试，用事实说话，排除了「语法错」才去查「逻辑错」。顺序对了，范围就缩对了。

第二条：真实场景优先，别信预览面板。预览 iframe 和真实双击是两个环境，一个注入 SDK，一个零注入。用file://协议测，才能复现用户真实遇到的问题。这一条直接决定了「双击白屏」这个 bug 能不能被发现。

第三条：分层定位，从静态到动态再到功能。语法检查（静态）→ 拦截运行期报错（动态）→ DOM 探针（功能），一层层往下钻，每一层都能给出确定结论，而不是「我觉得可能是什么」。

第四条：精准编辑，用行级替换而不是整体重写。改 bug 最怕「顺手改坏别的」。行级替换把改动范围锁死在最小单元，也方便回滚和对比。

第五条：交付要有可验证的证据。DS4 修完每个 bug，都对应一个能复跑的验证脚本，输出「通过/失败」的硬结果——比如记账写入后刷新，数据还在不在；八个视图能不能都渲染出来。用证据交付，而不是用一句「我修好了」交付。

五条归成一句话：把「猜」换成「查」，把「改」换成「验证过的改」。

六、避坑指南

坑 1：报错要分层，别让服务侧报错带偏你。

429、400 这种是模型服务侧的临时故障，和你的代码一毛钱关系都没有。看到它，正确动作是换模型或重试，而不是停下来怀疑任务本身。把服务侧故障和代码 bug 分开看，是第一条要练的基本功。

坑 2：「环境问题」是最省事的借口，但往往不是真相。

白屏了，第一反应是「环境不对、得部署」——这是最偷懒的归因。先问一句：代码本身在零环境下能不能跑？很多「环境问题」，其实是「初始化逻辑有个硬门」这样的代码问题。

坑 3：目标不稳，反复横跳，是最大的时间黑洞。

需求一旦确认「只做本地版」，就把在线版那摊事放下，一条路走到交付。两头都抓，结果就是两头都半途而废。这一单我踩过，你也别踩。

坑 4：测试脚本的 key 写错，会误报「写入失败」。

本地存储是以各数据表的 databaseId 作为 key 存的，不是表名money这种。我写验证脚本时一度用错了 key，读出「写入前 0 条、写入后 0 条」，差点误判功能坏了。查这类问题，先确认自己读的 key 对不对。

坑 5：真实双击场景，和预览面板是两回事。

这一单「双击白屏」的 bug，在预览面板里根本看不出来，因为面板注入了 SDK。验证交付，务必用file://双击这个动作来测，才算数。

七、总结

回头看这一单，HY3 和 DS4 的差距，浓缩成一句话：HY3 在报错里原地打转，DS4 把报错拆成两层、把 bug 拆成三个、把验证做成可复跑的证据。

「推理」的价值在于——先想清楚「哪一层坏了、坏在哪」，再决定动哪里；「编码」的价值在于——改动足够小、足够精准，不制造新问题；而「措施的科学性」，本质是让每一步都有据可查，而不是靠手感。

下次你在 WB 里让 AI 干活遇到报错，先别急着让它「重试」或「换个思路」，先问它一句：这一层到底是服务侧故障，还是代码里的真 bug？查清楚了再动手。这一问，往往就是少折腾一小时的分水岭。

写在最后：一个邀请

如果这篇对比对你有参考价值，说明咱们是同一类人——都相信 AI 不该只会聊天，得真刀真枪帮我把活干完。

我日常用的就是 WorkBuddy。上面每一组对比里的结论，都不是看参数表写出来的，是和它一起干活磨出来的。

如果你也想试试，用我的邀请链接注册，咱们就算「绑定的师徒」——你用的时候卡住了、踩坑了，随时来问我：

https://www.workbuddy.cn/events/invite?inviteCode=yit89z2wu1

免费注册，没有门槛。早用上，早把那些重复劳动甩给 AI。

专栏导航

本文是「腾讯小龙虾 WorkBuddy 专栏」第 75 篇。