zheng
b076815171
按 U-Claw-海外化改造方案.md 与 范围决策记录.md 实施。这是 fork，不回上游： 海外版删掉的正是上游的中国市场默认值。 阶段 0 地基 - 下载源全部改国际：脚本/CI 61 处 + lockfile 880 条 npmmirror URL 归零 （lockfile 那 880 条是 npm 的 resolved 字段，脚本层参数化根本绕不过它） - 移除 install.ps1 里三个第三方 GitHub 加速代理，bundle 改直连 + SHA256 校验 （原来只检查"文件大于 1MB"就解压运行） - 技能内容与分发分离：skills/manifest.json 单一来源，install.sh 1170→658 行、 install.ps1 721→546 行，两者技能内容归零 实测原来是三份不一致：skills-cn 完整、install.sh 约 40%、install.ps1 约 17%， 且 7 个通用技能只有 U 盘版有 —— 一键安装的用户一个能用的技能都没有 - Node 版本三种（v22.14/16/22.1）统一，新建 NODE_VERSION 单一来源 - Config 页三份合一。portable/Config.html 用根相对路径调 API 却只从 file:// 打开， 保存功能已静默失效两个月；现缩为 120 行重定向壳 - 测试接入 CI（此前 node --test 无人运行，所有断言形同虚设） 阶段 1 双语可用 - 浏览器侧 i18n：JSON 为源、生成经典 script（file:// 下 fetch 本地 JSON 被拦） 语言跟盘走不跟机器走：启动器写 data/.openclaw/locale.js - 8 处硬编码 lang="zh-CN" 归零，data-i18n 覆盖 213 处，词条 en/zh 各 279 条 - B3 单框 Key：12 张模型卡 → 一个输入框，前缀识别 provider， 服务端 /api/test-key 发 1-token 请求实测，错误映射成人话 Key 填错到得知：从"直到对话失败"降到 ≤1 秒 - 区域格式 SG：DD/MM/YYYY、12 小时、S$、Asia/Singapore （ICU 在 en-SG 下把 SGD 渲染成裸 $，与美元无法区分，故自行拼 S$） - README 内容分叉而非翻译，§1.3 证据清单逐条清零 阶段 2 降门槛 - 启动逻辑上移 lib/start.mjs：Windows-Start.bat 220→28 行、 Mac-Start.command 235→33 行 修掉 Mac 侧两个 bug：控制台端口硬编码 18788（回落时打开死页）、 微信插件从未在 Mac 上安装 - U 盘根目录 23 → 3 个可点文件，其余进 advanced/ - 首启向导：语言 → 用途（7 角色，manifest 驱动）→ 密钥，答过不再问 - 三档界面，Simple 档隐藏一切技术名词 - 自动自愈：启动失败先自查自修，修不好导出脱敏诊断包 （Doctor 从"用户要知道去点的工具"变成后台机制） 阶段 3 技能库 - 19 个英文技能，planned 归零。sg-weather / sg-transport 的端点均实测过 - SkillHub 从 56 张手写第三方卡片改为 manifest 生成：703→125 行，中文归零 其他 - origin.json 收拢所有运行时地址，tests/origin.test.mjs 保证迁移不会漏 - portable/ 下用户可见中文归零（由断言保证） - 82 项测试 未验证（本机无 Windows / 无 pwsh）： - install.ps1、setup.ps1 约 210 行改动从未经 PowerShell 解析器 - 完整启动路径仅在假 node + 假 openclaw 上冒烟 - 8 个 .bat 的盘根推导仅静态断言 详见 U盘实测清单.md 受阻： - 隐藏黑窗口 —— 需代码签名证书（.vbs 已被 Windows 弃用，替代方案都要签名） - 场景卡 —— OpenClaw 上游 Dashboard 无预填 prompt 接口 - 官网 36 条 —— 上游 2026-04-14 拆到私有仓库，无权限
2.6 KiB
name, description, metadata
| name | description | metadata | ||||
|---|---|---|---|---|---|---|
| claude-helper | Getting better results from the model - prompting, context, and knowing when the tool is wrong for the job |
|
Getting Better Results
How to ask, what to include, and when to stop asking.
The three things that change output most
1. Say what the output is for. "Summarise this" and "summarise this for someone deciding whether to attend" produce different, both-correct summaries. The purpose does more work than any phrasing trick.
2. Give the real material. A paraphrase of a document produces an answer about the paraphrase. Paste the document, attach the file, share the error in full — including the parts that look irrelevant.
3. Say what a good answer looks like. Length, format, who reads it. "Three bullets a non-technical manager can act on" beats "be concise".
What does not help
- Politeness formulas, threats, or claiming urgency
- "You are a world-class expert in…" — state the task, not a persona
- Asking the same thing again in the hope of a different answer. Change what you gave it instead.
When to start a new conversation
Long conversations drift. Start fresh when:
- You have changed subject entirely
- Earlier wrong turns keep resurfacing
- The context has filled with material that no longer matters
Carry forward a short summary rather than the whole history.
When the answer might be wrong
Language models produce fluent text regardless of whether they know the answer. Confidence is not a signal. Check independently when the answer involves:
- Specific numbers, dates, prices, versions — especially recent ones
- Citations, links, case law, standards — these get fabricated convincingly
- Anything you will act on without being able to reverse it
Ask for the reasoning or the source, and treat a refusal to give one as a warning.
When to use something else
- Arithmetic on real data — use a spreadsheet or a script, not the model
- Anything needing today's facts — the model needs to be given them
- Legal, medical or financial decisions — a draft to take to a professional, not the answer
Example prompts
Rewrite my prompt so it gets a more useful answer
What information are you missing to answer this properly?
Which parts of that answer should I verify before I use it?
Working notes
- When the user's request is ambiguous in a way that changes the answer, ask one question rather than producing two versions.
- Say plainly when something is outside what you can check, rather than hedging through it.