向小黄鸭解释报错本来就有用为了把问题讲清楚我们会重新整理输入、预期和实际结果。接上模型以后这个动作更方便了也多了一个风险——回复太像结论容易让人跳过验证。我想做的调试助手只负责整理材料与提出假设。它不把“听起来合理”标成“已经修复”也不根据几句抱怨推断人的心理状态。一次合格的输出至少应当说清楚看到了什么、还缺什么、下一步如何证伪。检查与执行要分开Chrome 的 2026 年 10 月 DevTools 月报介绍了 MCP 的 JavaScript 执行控制例如--no-javascript-evaluation。这篇月报实际发表于 9 月 22 日“十月版”不能改写成十月刚发布。对独立工具的启发很具体允许读日志与允许执行脚本应当是不同开关。下面的例子没有连接模型也不执行日志中的任何内容。它把输入整理成一份调试请求输出两种互相竞争的解释配置不一致或输入不符合约定。候选解释只是示例不是从日志推导出的诊断。真正使用时应把模型回复放在“假设”栏并要求每项附一个可观察的验证步骤。脱敏是第二道防线提交前先选择最小日志片段删除账号、路径和业务数据再做规则过滤。例子会遮住常见 token、Bearer 和邮箱但这种正则不认识全部秘密换一种字段名、把凭证写进 URL 查询串都可能漏掉。它不能成为“日志可以随便上传”的理由。本地运行node duck.js可验证常见敏感字段被遮住、空日志被拒绝、输入长度受限。这里没有上传服务、自动修复或浏览器集成也没有做通用 DLP 检测。若要真正发送模型请求界面应该先展示将发送的原文取得用户的具体确认并把执行权限留在另一道门后。我喜欢小黄鸭的原因不是它总能回答而是它提醒人把问题讲完整。AI 助手也应保留这份克制先帮我形成一个能验证的问题再等证据决定结论。可独立运行的核心例子function redact(text) { return text .replace(/\bBearer\s[A-Za-z0-9._~\/-]/gi, Bearer [已遮蔽]) .replace(/\b(token|api[_-]?key|password)\s*[:]\s*[^\s,;]/gi, $1[已遮蔽]) .replace(/[A-Z0-9._%-][A-Z0-9.-]\.[A-Z]{2,}/gi, [邮箱]); } function request(log, expected, actual) { if (!log.trim() || !expected.trim() || !actual.trim()) throw Error(请补充日志、预期与实际结果); if ([log,expected,actual].some(x x.length 4000)) throw Error(请缩小为最小复现); return { evidence:redact(log), expected:redact(expected), actual:redact(actual), permission:只整理材料不执行命令, hypotheses:[ {label:示例假设配置不同, verify:对照两次运行的配置差异}, {label:示例假设输入不同, verify:固定同一份最小输入后重跑} ], status:待人工验证 }; } const samplerequest(tokenabc123 usermeexample.com, 返回200, 返回401); if (sample.evidence.includes(abc123) || sample.evidence.includes(me)) throw Error(脱敏回归失败); let rejectedfalse; try { request(, 200, 401); } catch { rejectedtrue; } if (!rejected) throw Error(空日志应被拒绝); console.log(JSON.stringify(sample,null,2));
