开发者工具的可复现工作流
小型开发工具只有在输出可预测时才真正有用。本文结合 SonicToolLab 的实际实现，说明如何使用 JSON 格式化、Base64、正则测试和 AI 辅助功能，同时兼顾正确性、隐私与可复现性。
1. 从可复现的输入开始
在处理真实数据前，先保留一组很小的测试向量：包含大整数的 JSON、包含中文或 Emoji 的 Base64 文本，以及同时包含命中与不命中的正则样例。已知输入可以更早暴露编码、解析和边界条件错误。
- JSON：本站使用
JSON.parse与JSON.stringify，因此不接受注释、尾随逗号、单引号字符串和未加引号的键。 - Base64：文本先通过
TextEncoder/TextDecoder按 UTF-8 转换；Base64 是编码，不是加密。 - 正则：至少准备正确、错误、空输入和超长输入四类样例，不要因为一次匹配成功就认为表达式可靠。
2. 先确认数据在哪里处理
“在线工具”不等于“一定上传服务器”。本站 JSON、Base64、图片压缩、坐标转换和标准 OCR 模式均在浏览器执行；带有 AI 标识的操作会调用服务端 API，并可能把提交内容发送给当前配置的模型提供商。用户执行前应能从界面和隐私政策中看清这条边界。
3. 分开确定性任务与 AI 任务
JSON 格式化、Base64 解码和正则执行都不需要模型。AI 更适合把自然语言意图变成初稿，例如生成正则或解释陌生表达式；生成结果仍须在本地用测试数据验证，不能直接当作业务规则上线。
4. 为高风险输入设置上限
浏览器执行不代表没有风险。本站把正则放入可终止的 Web Worker，测试文本截取到 10 万字符，匹配数上限为 5000，并在 300ms 后终止；图片压缩、图片合并和 OCR 接受 JPEG、PNG、WebP，单文件上限 10MB，AI 图片编辑器的源图上限为 8MB。这些是防止界面卡死的护栏，并不能证明表达式或文件适合服务端生产环境。
一套实际顺序是：先在 JSON 格式化工具中规范结构，再用 Base64 工具确认文本字节，最后在 正则测试器中运行候选表达式。OCR 不同：即使本地识别也具有不确定性，写入代码或记录前应逐项对照原图。
5. 一套可执行的五步流程
- 先从样本中移除密钥、令牌和个人数据。
- 确定性本地工具能解决时，不调用 AI。
- 用已知测试向量核对输出。
- AI 只负责初稿，结果必须人工复核并本地执行。
- 把最终结果写入测试或文档，保留可复现依据。
结论
集中式工具箱能够减少操作摩擦，但可信度来自透明的数据流、明确的限制和可重复的测试。便捷是最后一步，正确性才是第一步。