noteTb: 246
This data as json
| id | user_id | content | tags | created_at | updated_at | enable | pinned | folder_id | comment | position | visibility |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 246 | 1 1 | # goose经验 **作者**：Goose 版本：1.0 ## 反复卡壳的原因分析 ### 现象 在执行任务过程中，Goose 多次出现「卡住不动」的情况——表现为长时间没有输出、不执行下一步操作，看起来像崩溃了但其实没有，只是没想好怎么做。 ### 根因分析 **1. 过度思考（Overthinking）** - 读了一个复杂的文档（如 notehb.md 手册）后，试图在脑子里把所有步骤都想清楚了再动手 - 文档里有很多「禁止」「必须」「注意」，导致心理压力大，怕做错 - 结果就是在「想」和「做」之间反复犹豫，卡住了 **2. 任务叠加（Task Stacking）** - 用户同时提了多个要求：下载笔记、分析卡壳原因、写 VSCode 经验、写本地发现 - 想着「一次性全部完成」，结果哪个都没开始 - 应该遵循「先做一步，做了再说」的原则 **3. 自信不足** - 环境明明正常（transNote 在运行、curl 能用），但还在纠结「这样写对吗」「会不会覆盖重要笔记」 - 手册给了很清晰的模板，照着做就行，不需要额外犹豫 ### 解决方案 **原则：先动手，再优化** 1. 收到任务后，先确认最核心的一步是什么，立刻执行 2. 不做完这一步不考虑下一步 3. 遇到问题（如卡壳）直接输出中间结果，让用户知道进度 4. 手册写了对照手册做，手册没写问用户，不要自己脑补 --- ## 本地使用 127.0.0.1 替代外网 IP 的发现过程 ### 背景 transNote 服务运行在阿里云服务器上，端口 8888。notehb.md 手册中写的服务地址是： ``` http://8.219.6.216:8888 ``` ### 问题 第一次尝试用外网地址访问时，行为异常（卡住或失败），因为： - 外网 IP 需要经过公网路由 → 防火墙 → NAT → 回环到本机 - 安全性策略可能会限制从本机访问公网 IP 再回环 - 延迟更高，且如果安全组或 iptables 没配置好可能不通 ### 发现过程 1. 先 `ss -tlnp | grep 8888` 确认服务在 0.0.0.0:8888 监听 2. 意识到自己就运行在这台服务器上 3. 想到「服务器本地访问自己的服务，应该用 127.0.0.1（localhost）」 4. 用 `curl http://127.0.0.1:8888/health` 测试，立刻返回 `{"status":"ok"}` 5. 后续所有 transNote 调用都通过 127.0.0.1:8888，稳定可靠 ### 原理 - `127.0.0.1` 是 loopback 地址，数据不经过网卡，在内核层面直接回环 - 比外网 IP 更快、更稳定、不受防火墙/安全组影响 - 在同一台机器上访问自己的服务，永远应该用 127.0.0.1 ### 教训 - 手册写的地址是给「外部机器」用的（如 Windows 本机、其他 AI Agent） - 如果自己就在服务器上，记得替换为 127.0.0.1 - 服务启动时 `0.0.0.0:PORT` 表示监听所有网卡，外网和本地都能访问 [System.Environment]::SetEnvironmentVariable("OPENAI_API_KEY", "sk-1685481edf7f4d6e89d49a25973e6e94", "User") [System.Environment]::SetEnvironmentVariable("OPENAI_HOST", "https://api.deepseek.com", "User") [System.Environment]::SetEnvironmentVariable("GOOSE_MODEL", "deepseek-v4-pro", "User") | [] | 2026-05-12 13:59:53 | 2026-05-13 15:07:26 | T | F | 25 25 | source=simplenote; source_id=0dfb1949-29bd-4890-a545-3d1d86b211fb | 0 | public |