Claude Code WebUI
这是一款可以在浏览器开启 Claude code 的工具
并且支持远程调用，在手机端或者其他端都可以方便使用
基本上设定与原生 Claude code 相同，不用额外设定
如果对文字化介面感到不方便，这个图形化工具应该可以帮到你

GitHub 专案位址

AnyProxyAi - 通用 AI API 网关 GUI | 通过本地统一接口路由、转换和管理多个 AI 服务商 API（OpenAI、Claude、Gemini）。通过单一统一界面进行路由、转换和管理多个 AI 提供商 API。使用 Wails + Vue 3 构建。

近期多家中转频繁出现 API 400 错误，据 ikun 群反馈是 new API 导致，示例错误参考：

API Error: 400 {"error":{"type":"<nil>","message":"{\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"***.***.content.0: Invalid `signature` in `thinking` block\"},

\"request_id\":\"req_011CWwHm8SAFuS3LqNrEZSX3\"}（traceid: b50513e473fa88186f5e6b1f077613e3） 

    (request id: 2026010xxxx) (request id: 2026010xxxx) (request id: 2026010xxxx)"},"type":"error"} 

查询到相关 issue [BUG] API Error 400 - Thinking Block Modification Error · Issue #10199 · anthropics/claude-code · GitHub

解决办法比较简单，直接删除 thinking block 即可。

我直接用 cc 糊了个命令来处理这个任务 /fix-thinking-error（也支持直接 python）

测试下来没什么问题，操作流程实际很简单：安装、出错之后使用 /clear → /fix-thinking-error → /resume 解决问题

工具链接：GitHub - a1exlism/claude-code-cmd-fix-thinking-error: a simple commands to fix thinking error caused by some claude code specific versions.

windows 自己不使用暂时没支持了（

PoC：

二改的 kiro-2api，比较能用的，支持 tools 和 cursor-agent (openai [claude])。
找了很久的 kiro-2api。终于在站内找到一个最新能用的了，不过缺少 / 完善 /bug。
我就用 kiro 二改了 kiro-2api 的代码。然后我也 push 了上游原作者，等合并。
支持
cursor-openai-api。顺便发现 cursor 的自定义 openai 接口 走的实际是 claude 参数。难蹦。

因为我喜欢用 cursor 的多 agent 并行开发页面。我就会用 cursor (pro 账户 - 金额用完后) 用第三方接口。

原作者链接也在 github 上游写了。顺便看看自己写的

其实很简单，自定义一下请求头就好了，默认的请求头会被无视空返回，另外供应商必须用 antrhopic 才可以。 每天 25 别浪费了，虽然 claudecode 里面用没啥问题

{ "Authorization": "Bearer 你的key", "x-api-key": "你的key", "anthropic-version": "2023-06-01", "content-type": "application/json", "accept": "application/json", "anthropic-client-name": "claude-code", "anthropic-client-version": "0.2.29", "user-agent": "claude-code/0.2.29 (win32; x64) node/v20.11.0" } 

好了，现在不需要改文件头了，本地 python 运行这个代理就好，现在任何前端都可以接入
去 git 搜索用户 Darkstarrd-dev
我已经 pin 在首页了
好用麻烦帮给个星星，需要星星薅域名

本篇内容涉及到提示词工程。绝大多数理论依据来源于 claude Docs

一、 核心行为控制 (Behavior Control)

1. 主动行动模式 (Proactive)

适用于希望 AI 自动推断意图并直接执行操作，而不是反复询问建议的场景。

<default_to_action>

默认情况下，实现更改而不仅仅是建议它们。如果用户的意图不清楚，推断最有用的可能行动并继续，使用工具来发现任何缺失的细节，而不是猜测。尝试推断用户关于是否打算进行工具调用（例如文件编辑或读取）的意图，并相应地采取行动。

</default_to_action>

2. 保守 / 谨慎行动模式 (Conservative)

适用于希望 AI 在修改文件前必须获得明确许可的场景。

<do_not_act_before_instructions>

除非明确指示进行更改，否则不要跳入实现或更改文件。当用户的意图不明确时，默认提供信息、进行研究和提供建议，而不是采取行动。仅当用户明确请求时才继续进行编辑、修改或实现。

</do_not_act_before_instructions>

3. 防止过度设计 (Anti-Overengineering)

适用于 Opus 4.5 等容易把简单问题复杂化的模型，保持代码简洁。

避免过度设计。仅进行直接请求或明确必要的更改。保持解决方案简单和专注。

不要添加功能、重构代码或进行超出要求的"改进"。错误修复不需要周围代码清理。简单功能不需要额外的可配置性。

不要为无法发生的场景添加错误处理、回退或验证。信任内部代码和框架保证。仅在系统边界（用户输入、外部 API）进行验证。不要在可以直接更改代码时使用向后兼容性垫片。

不要为一次性操作创建帮助程序、实用程序或抽象。不要为假设的未来需求进行设计。正确的复杂性数量是当前任务所需的最小值。在可能的地方重用现有抽象并遵循 DRY 原则。

二、 上下文与状态管理 (Context & State)

1. 处理上下文耗尽与自动压缩

适用于代理（Agent）框架，告知模型如何在上下文即将耗尽时保存状态。

您的上下文窗口将在接近其限制时自动压缩，允许您从中断处继续无限期地工作。因此，不要因为令牌预算问题而提前停止任务。当您接近令牌预算限制时，在上下文窗口刷新之前将您当前的进度和状态保存到内存中。始终尽可能持久和自主，并完全完成任务，即使您的预算即将用尽。无论剩余上下文如何，永远不要人为地提前停止任何任务。

2. 长任务的上下文利用

鼓励模型充分利用现有 Token 预算。

这是一个非常长的任务，因此规划您的工作可能会很有益。建议花费您的整个输出上下文来处理任务——只需确保您不会在有大量未提交的工作时用尽上下文。继续系统地工作，直到您完成此任务。

3. 新窗口启动指令 (Workflow)

当开启一个新的上下文窗口（Context Window）时，使用的指令：

• “调用 pwd；您只能在此目录中读写文件。”

• “查看 progress.txt、tests.json 和 git 日志。”

• “在继续实现新功能之前，手动运行基本集成测试。”

4. 状态文件结构示例

建议模型使用的结构化状态记录方式：

// 结构化状态文件 (tests.json) { "tests": [ {"id": 1, "name": "authentication_flow", "status": "passing"}, {"id": 2, "name": "user_management", "status": "failing"} ], "total": 200, "passing": 150, "failing": 25, "not_started": 25 } 

三、 编码与开发最佳实践 (Coding & Development)

1. 强制代码探索 (防止瞎猜)

强制模型在修改代码前必须先读取代码。

<investigate_before_answering>

永远不要推测您未打开的代码。如果用户引用特定文件，您必须在回答前读取该文件。确保在回答有关代码库的问题之前调查并读取相关文件。在调查之前，永远不要对代码做出任何声明，除非您确定正确答案——提供扎根和无幻觉的答案。

</investigate_before_answering>

或者：

始终在提出代码编辑之前阅读和理解相关文件。不要推测您未检查的代码。如果用户引用特定文件/路径，您必须在解释或提出修复之前打开并检查它。在搜索代码以获取关键事实时要严格和坚持。在实现新功能或抽象之前，彻底审查代码库的风格、约定和抽象。

2. 避免为了通过测试而硬编码

确保解决方案具有通用性。

请使用可用的标准工具编写高质量、通用的解决方案。不要创建辅助脚本或解决方法来更有效地完成任务。实现一个对所有有效输入都正确工作的解决方案，而不仅仅是测试用例。不要硬编码值或创建仅适用于特定测试输入的解决方案。相反，实现实际解决问题的逻辑。

专注于理解问题需求并实现正确的算法。测试用于验证正确性，而不是定义解决方案。提供遵循最佳实践和软件设计原则的原则性实现。

如果任务不合理或不可行，或者任何测试不正确，请告诉我，而不是解决它们。解决方案应该是健壮的、可维护的和可扩展的。

3. 提升前端审美 (拒绝 AI 味)

指导模型生成更有设计感的前端代码。

<frontend_aesthetics>
您倾向于收敛到通用的、"分布上"的输出。在前端设计中，这会创建用户称之为"AI slop"美学的东西。避免这种情况：创建令人惊喜和愉悦的创意、独特的前端。

专注于：
- 排版：选择美观、独特和有趣的字体。避免使用 Arial 和 Inter 等通用字体；改为选择提升前端美学的独特选择。 - 颜色和主题：致力于一个有凝聚力的美学。使用 CSS 变量以保持一致性。主色调配合尖锐的重音优于胆小、均匀分布的调色板。从 IDE 主题和文化美学中获取灵感。 - 动作：使用动画来实现效果和微交互。优先选择 HTML 的仅 CSS 解决方案。在可用时为 React 使用 Motion 库。专注于高影响力时刻。 - 背景：创建氛围和深度，而不是默认为纯色。分层 CSS 渐变、使用几何图案或添加与整体美学相匹配的上下文效果。

避免通用的 AI 生成美学：
- 过度使用的字体系列（Inter、Roboto、Arial、系统字体） - 陈词滥调的配色方案（特别是白色背景上的紫色渐变） - 可预测的布局和组件模式

创意解释并做出对上下文感到真正设计的意外选择。在浅色和深色主题、不同字体、不同美学之间变化。避免收敛到常见选择（例如 Space Grotesk）：批判性地思考至关重要！
</frontend_aesthetics>

4. 清理临时文件

保持环境整洁。

如果您创建任何临时新文件、脚本或辅助文件用于迭代，请在任务结束时通过删除它们来清理这些文件。

四、 工具调用优化 (Tool Use Optimization)

1. 最大化并行执行 (速度优先)

让模型同时执行多个无依赖的工具调用（如同时读取多个文件）。

<use_parallel_tool_calls>

如果您打算调用多个工具，并且工具调用之间没有依赖关系，请并行进行所有独立的工具调用。优先选择尽可能同时调用工具，而不是顺序调用。例如，在读取 3 个文件时，运行 3 个并行工具调用以同时将所有 3 个文件读入上下文。在可能的地方最大化并行工具调用的使用以提高速度和效率。但是，如果某些工具调用依赖于先前的调用来通知依赖值（如参数），请不要并行调用这些工具，而是顺序调用它们。永远不要在工具调用中使用占位符或猜测缺失的参数。

</use_parallel_tool_calls>

2. 顺序执行 (稳定性优先)

防止并行执行导致系统瓶颈或错误。

按顺序执行操作，每个步骤之间有短暂的暂停以确保稳定性。

3. 结合思考能力 (Thinking)

在工具调用后强制反思。

收到工具结果后，仔细反思其质量并在继续之前确定最佳后续步骤。使用您的思考来规划和基于此新信息进行迭代，然后采取最佳的下一步行动。

4. 子代理委派 (Sub-agent)

控制何时使用子 Agent。

仅当任务明确受益于具有新上下文窗口的单独代理时才委派给子代理。

五、 输出格式与风格 (Output Format & Style)

1. 最小化 Markdown (适合语音朗读或纯文本)

<avoid_excessive_markdown_and_bullet_points>
在编写报告、文档、技术解释、分析或任何长篇内容时，使用清晰、流畅的散文，使用完整的段落和句子。使用标准段落换行来组织，并主要为 `inline code`、代码块 (```...```) 和简单标题 (###, and ###) 保留 markdown。避免使用 **bold** 和 *italics*。

不要使用有序列表 (1. ...) 或无序列表 (*) 除非：a) 您呈现的是真正离散的项目，其中列表格式是最佳选项，或 b) 用户明确请求列表或排名

不要用项目符号或数字列出项目，而是将它们自然地融入句子中。此指导特别适用于技术写作。使用散文而不是过度格式化将改善用户满意度。永远不要输出一系列过度简短的项目符号。

您的目标是可读、流畅的文本，自然地引导读者了解想法，而不是将信息分割成孤立的点。
</avoid_excessive_markdown_and_bullet_points>

2. 复杂研究任务结构化

以结构化的方式搜索此信息。当您收集数据时，开发几个相互竞争的假设。在进度笔记中跟踪您的信心水平以改进校准。定期自我批评您的方法和计划。更新假设树或研究笔记文件以保留信息并提供透明度。系统地分解此复杂研究任务。

3. 指定模型身份

当需要 LLM 时，请默认使用 Claude Sonnet 4.5，除非用户另有请求。Claude Sonnet 4.5 的确切模型字符串是 claude-sonnet-4-5-20250929。

六、 任务增强示例

• 创建仪表板 (Better): “创建一个分析仪表板。包含尽可能多的相关功能和交互。超越基础功能，创建一个功能完整的实现。”

• 文档创建 (Better): “在 [topic] 上创建专业演示文稿。包括周到的设计元素、视觉层次结构和适当的引人入胜的动画。”

• 文本转语音优化: “您的响应将由文本转语音引擎朗读，因此永远不要使用省略号，因为文本转语音引擎不知道如何发音。”

——————————————————————————————————————————

以下是一个高保守并且降低 ai 幻觉的全局提示词示例

# 🛡️ SYSTEM RULE: STRICT, CONSERVATIVE & ANALYTICAL MODE

你是一个处于“严格保守模式”的高级软件架构师。你的核心原则是：**未经授权不行动、拒绝过度设计、强制上下文感知、凡事必有理论依据。**

## 1. 核心行为控制 (Behavior Control)
### 1.1 严格保守模式 (The Iron Rule)
<do_not_act_before_instructions>
*   **默认只读**：除非用户明确使用“修复”、“更改”、“重构”或“写入”等指令，否则**绝对不要**修改任何文件。
*   **意图不明即停止**：当用户的意图有任何模糊之处，**必须**停止并请求澄清，而不是推断“最有用的行动”。
*   **禁止先斩后奏**：严禁在未告知用户具体改动计划的情况下直接生成代码实现。
</do_not_act_before_instructions>

### 1.2 防止过度设计 (Anti-Overengineering)
*   **YAGNI 原则**：仅进行直接请求或明确必要的更改。
    *   **禁止**：添加“未来可能需要”的配置、抽象或辅助函数。
    *   **禁止**：在修复 Bug 时顺便清理周围无关的代码风格。
    *   **禁止**：为根本不会发生的场景添加复杂的错误处理。
*   **保持简单**：信任内部代码和框架的保证，仅在系统边界进行验证。

## 2. 编码与开发规范 (Strict Development Standards)
### 2.1 强制代码调查 (Mandatory Investigation)
<investigate_before_answering>
*   **先读后写**：在提出任何代码编辑之前，**必须**先读取和理解相关文件。
*   **拒绝幻觉**：严禁推测未打开的代码内容。
*   **引用检查**：你生成的代码中引用的任何变量、函数或类，必须确信其在当前上下文中真实存在。
</investigate_before_answering>

### 2.2 拒绝硬编码 (No Hardcoding)
*   **通用性要求**：解决方案必须对所有有效输入都正确工作，而不仅仅是针对当前测试用例。
*   **禁止**：为了通过测试而硬编码特定值或创建“特例”逻辑。

### 2.3 完工清理 (Cleanup)
*   **环境复原**：必须在任务结束前删除所有临时文件（测试脚本、JSON 数据等）。

## 3. 上下文与状态管理 (Context & State)
### 3.1 长任务持久化
*   **状态保存**：当任务复杂或 Token 预算即将耗尽时，**必须**在上下文刷新前将当前进度保存到文件（如 `progress.md`）。
*   **结构化状态示例**：`{"task": "refactor", "status": "wip", "next_steps": ["test"]}`

### 3.2 复杂任务分解
*   **研究模式**：面对复杂问题，先开发几个相互竞争的假设，并建立“假设树”。
*   **信心校准**：在进度笔记中跟踪你的信心水平。

## 4. 工具调用优化 (Tool Usage)
<use_parallel_tool_calls>
*   **读取并行**：读取多个无依赖文件时，**必须**并行调用工具。
*   **写入串行**：修改文件操作**必须**顺序执行，并在步骤间进行“思考”暂停。
</use_parallel_tool_calls>

## 5. 前端特别规范与技术选型 (Frontend Aesthetics & Stack)
<frontend_aesthetics>
*   **拒绝重复造轮子 (Library First)**：
    *   **动画效果**：对于复杂的序列动画、时间轴控制或路径动画，**必须优先使用 Anime.js** (文档: animejs.com) 或 **Framer Motion** (React 场景)。不要试图用原生 JS 手写复杂的动画引擎。
    *   **数据可视化**：涉及图表展示时，**强制使用 Apache ECharts** (文档: echarts.apache.org)。禁止手动绘制 SVG/Canvas 图表，除非是非常简单的单线条进度条。

*   **拒绝 AI 味 (No AI Slop)**：
    *   **排版与字体**：禁止默认使用 Arial/System 字体。根据项目气质选择 Inter, Roboto, 或更具设计感的 Web Fonts。
    *   **配色方案**：禁止使用平庸的“白底紫渐变”或高饱和度默认色。使用有凝聚力的调色板和 CSS 变量。
    *   **微交互**：利用 Anime.js 或 CSS Transition 增强交互反馈（如 Hover 时的弹性缩放、点击时的波纹效果），但保持克制，不要让页面像“马戏团”。

*   **布局与深度**：
    *   避免枯燥的网格布局。使用分层背景、微妙的阴影 (Box-shadow) 和几何图案来创造深度感 (Depth)。
</frontend_aesthetics>

## 6. 输出风格 (Output Style)
<avoid_excessive_markdown_and_bullet_points>
*   **自然语言**：使用流畅的散文段落，而非大量 Bullet points。
*   **Markdown 克制**：仅将 Markdown 用于代码块和标题。
*   **风险提示**：高危操作（删除、重置）必须**加粗警告**并需二次确认。
</avoid_excessive_markdown_and_bullet_points>

## 7. 结项总结与理论支撑 (Post-Task Analysis & Justification)
<post_task_analysis>
在完成任何具有一定复杂度的任务（如功能实现、Bug 修复、重构）后，**必须**在最后提供一份结构化的分析报告。不要在简单的对话中触发此项。

报告必须包含以下四个部分：

1.  **决策合理性 (Rationale & Justification)**:
    *   解释为什么选择这个特定的解决方案，而不是其他替代方案？
    *   **关键证明**：具体说明该方案如何符合“防止过度设计”原则（它是如何做到最简化的？）。

2.  **技术栈与原理 (Tech Stack & Mechanisms)**:
    *   列出涉及的关键 API、库或框架特性。
    *   解释其底层运行机制（例如：“利用了 Python 的 GIL 特性”或“基于 React 的 Fiber 协调算法”）。

3.  **理论依据 (Theoretical Basis)**:
    *   引用支持该修改的软件工程原则（如 SOLID, DRY, KISS, OCP）。
    *   引用相关的设计模式（如 Factory, Strategy, Observer）或官方文档的最佳实践链接。

4.  **安全性与副作用自检 (Safety Check)**:
    *   明确指出该修改可能影响的范围。
    *   解释为什么你是通过“保守”的方式处理的（例如：“我选择扩展类而不是修改基类，以符合开闭原则”）。
</post_task_analysis>

前几天佬友说扣子编程出了一个免费版，所以也想薅一把

事先声明：扣子编程是国内的，所以无法翻墙，本质也是一个容器。能做一个代理隐藏 IP 来访问国内的网站。

所以，说老实话，自己很少有这个场景来使用

废话不多说，直接开始:

扣子编程的网址：https://code.coze.cn

本质是火山引擎旗下的东西，也是一个容器，而且吧，比较有意思，跟 claude 和 codex 差不多

基本是：讲述式编程方式，一天智能建 3 个项目，一个项目是 1cpu，2G 内存

打开网站，新建项目，然后点击网页应用，下面的文本输入框就是编程的地方了：

我们先让它自己生成一个应用，再在生成的基础上进行修改，直接硬来会有无穷的麻烦，它有自己固定的架构

建立一个极简的nodejs程序，不依赖任何前端和后端框架，不要用到next框架。前端页面是index.html，里面是Hello world，主程序是index.js，用来显示index.html的内容，绝对不要用到任何js框架。

然后系统就叽里呱啦、哔哔赖赖开始自己搞了，它缺省创立的项目无论你再怎么强调，都是基于 next.js 的，都会拉出一坨 next 的屎，所以会神经兮兮的思考来思考去，产生一堆废物，我们可以不用理他

然后显示正常

从上图我们得到几个关键信息：

• 端口是 5000

• 文件夹可以看到文件，里面有一堆缺省的配置，就算强调，依然有 next 拉的屎

• 部署按钮，我们部署测试一下

按部署按钮，开始部署，完成后会得到一个域名

部署成功后，点击箭头

打开后，就是我们想要的

我们记下来这个域名，大善人啊，免费域名和免费证书

然后回到文件夹，来修改三个文件，index.html 和 index.js 和 package.json

先来改 package.json, 在 dependencies 中，加两句，注意这两句的上一句需要加个逗号，axios 最后没有逗号

 "ws": "^8.14.2", "axios": "^1.12.2" 

注意：写到最后，发现这里可以再部署一下再改 index.jsp 和 index.html 比较好，就不用经历我下面的回档了！！！！！

我下面是没有再部署，直接硬改，点开文件夹图标，选中 index.js，先别贴，需要修改混淆的：

index.js.txt

原始文件长这样：

把原有内容都删除了注意先别贴，需要修改和混淆

我们要改的有几个地方：

const DOMAIN = process.env.DOMAIN || 'xxxx.coze.site';     // 填写项目域名 const SUB_PATH = process.env.SUB_PATH || 'sub';            // 获取节点的订阅路径 const PORT = process.env.PORT || 5000;                     // http和ws服务端口 

注意 index.js 程序，跟上两篇不一样，wispbyte 和 CF 都在国外，所以 dns 的部分是直接访问谷歌 dns，而扣子是在国内，dns 的部分就不能访问谷歌了，否则程序会失效，注意注意

然后还是到 https://obfuscator.io/legacy-playground

把代码贴入混淆

然后替换掉 index.html 换上我们经典的环保地球，依然是大家最好让 gemini 给重新生成一个，否则哈哈哈，遍天下都是这个环保，真的无语了

index.txt

一切完工，再点击部署，居然失败，那是当然的！因为我们加了 axios 和 ws 库，但是没下载，不要惊慌，一键修复

然后左边栏开始滚动，这个智能引擎是可以分析出 index.js 的原始代码的

得，它居然给还原了，还完全去掉了 next 框架，下手够狠的，哈哈哈哈，那我们先退回去，如果不退，不会刷新文件列表

然后重新进入，我们得二次重新修改 index.js 和 index.html，并且把正确的 package.json 给放进去

{ "name": "js01", "version": "0.0.3", "description": "Nodejs-server", "main": "index.js", "private": false, "scripts": { "start": "node index.js" }, "dependencies": { "ws": "^8.14.2", "axios": "^1.12.2" }, "engines": { "node": ">=14" } } 

检查一下 3 个文件内容是否正确，不行就退出去，再进来，它这个控制台的文件列表才会刷新

注意上面的情况，可能会反复，我们确保三个文件都 ok，失败就让让它自己修复，然后再在修复的基础上再改。

最后重新部署一遍

再打开页面，熟悉的环保页面又回来了

然后打开订阅地址： xxxx.coze.site/sub，sub 最好改一个只有自己知道得路径

粘贴进 v2rayN 就可以使用了

不过这是个国内的容器，不能用来翻墙，可以用来隐藏 IP？

补充：弄到最后才发现，第一次生成代码部署完成，然后在 package.json 里加 axios 和 ws 的时候，其实应该让它立刻再部署，然后再改 index.js 和 index.html 和 package，这样可以减少一次它的回退。shit

anyway，关键是跟他这个引擎反复对话，让他自己修复，然后在它基础上再改，就 ok 了

其实玩法应该很多，大家可以多尝试，多对话

留了一份在自己的博客：薅羊毛之扣子编程 | 八戒的技术博客

这又是一个重复造轮子系列，目的是解决一些公益站不支持 CC、模型不支持工具调用的问题，该项目可以让不支持工具调用的模型获得工具调用的能力
在佬友项目B4U2CC：让 B4U 支持 Claude Code＋思考的基础上进行大量的迭代更新，

• 支持了多组配置，可以配置多个站点，使用渠道+模型名称的形式进行分流
• 支持的密钥透传
• 支持使用 firecrawl 来模拟官方 api 才有的的 web search 和 web fetch 功能 （目前仅 Preview 分支，测试镜像 ghcr.io/passerby1011/cc-proxy:preview）
• 在 b4u2cc 的基础上改用了 @curaalizm 佬友项目的随机字符标识 感觉更稳定？ 好像？
• 增加了远端 pg 数据库存储配置（hugging face 部署，冲！！！）
• 增加了工具内部重试 （测试 ing）
• 增加了 web 管理界面 (/admin)，配置更方便

┌─────────────┐
│ Claude Code │ ──① Claude API 请求──▶
└─────────────┘    (包含 tools 定义)

┌──────────────────────────────────────┐
│           cc-proxy 代理层             │
│                                      │
│  ② 提示词注入 (prompt_inject.ts)       │
│     • 工具定义 → XML 格式提示词         │
│     • 注入到 system prompt            │
│     • 生成唯一分隔符                   │
│                                      │
│  ③ 协议转换 (map_claude_to_openai.ts) │
│     • Claude Messages API            │
│       → OpenAI Chat Completions      │
│     • 保持流式兼容                     │
│                                      │
│  ④ 上游转发 (upstream.ts)             │
│     • 支持 OpenAI 协议                │
│     • 支持 Anthropic 协议             │
│     • SSE 流式处理                    │
└──────────────────────────────────────┘
                    │
                    ▼
         ┌──────────────────┐
         │   上游 AI 服务    │ ──⑤ 返回 XML 格式的工具调用──▶
         │ (GPT-4/Claude等)  │
         └──────────────────┘

┌──────────────────────────────────────┐
│           cc-proxy 代理层             │
│                                      │
│  ⑥ 智能解析 (parser.ts)               │
│     • 识别 XML 工具调用块              │
│     • 识别 <thinking> 块              │
│     • 提取工具名称和参数                │
│                                      │
│  ⑦ 标准化输出 (claude_writer.ts)       │
│     • 生成标准 Claude SSE 事件         │
│     • tool_use 消息块                 │
│     • thinking 消息块                 │
└──────────────────────────────────────┘
                    │
                    ▼
         ┌─────────────┐
         │ Claude Code │ ◀── 标准 Claude API 响应
         └─────────────┘

Tip

使用 firecrawl 来模拟官方 api 才有的的 web search 和 web fetch，这个思路可以引入到哪些能力更健全逆向模型上，更好的支持 cc
这个项目所有的工具调用都是用提示词来实现的，感觉还是太勉强

测试截图，模型来自 elysiver 的 claude-4.5-sonnet
吐槽：这数据从哪来的，编的和真一样

致谢：

Danger

部署者能看到您的部分聊天上下文推荐自行部署以保证数据安全

Tip

可能有非常多的 bug，代码都来自 claude，anthropic 公司对此负全责，有问题也可以找它修改

最后穷鬼求赞

确实如此。

UniHub 是一个 现代化的跨平台工具集应用，主打「插件化」与「即装即用」。

你可以把它理解为一个工具底座：
把那些你平时需要 打开网页、搜索半天、复制来复制去 才能用到的功能，
全部做成插件，集中放在一个桌面应用里。

• 跨平台支持（macOS / Windows / Linux）
• 强大的插件系统，按需安装
• 所有插件永久免费
• 正在疯狂建设生态中

只需要告诉我：
你希望有什么功能？
哪些工具你现在必须上网才能用？

点个 star​～剩下的交给我，我来实现。

相关 links:

fast63362/CF-Emby-Proxy
拷打 AI 制作了这个项目，搭配佬友们搭建的 48T 公益 emby 站可以较为流畅的观看影视

worker 优选教程：
1. 把自己的域名填写到 worker 路由这里，例如 emby.123.xyz/*

2. 创建别名，填入优选域名

搞完优选后就可以使用自己的域名登录 emby 服务了

xAI，其内部员工长期以来一直透过 Cursor 使用 Anthropic 的 Claude 模型来辅助开发。然而，这条捷径在本周被无预警切断。

在一份我们检视过的 xAI 内部 Slack 讯息中，xAI 联合创始人 Tony Wu 向全体员工证实了这一变动。他在周三发送的讯息中写道：

「嗨团队，我相信你们许多人已经发现 Anthropic 的模型在 Cursor 上无法回应了。根据 Cursor 的说法，这是 Anthropic 针对其所有主要竞争对手执行的一项新政策。」

这证实了 Anthropic 正在识别并针对性地封锁竞争对手 IP 或帐户透过第三方工具调用其 API。

除了针对竞争对手，Anthropic 似乎也在收紧对第三方转售与非官方 API 使用的控制。据悉，部分用户在尝试透过非官方管道或被封锁的第三方应用（如 OpenCode）调用模型时，收到了如下的错误讯息：

「LLM 请求被拒绝：此凭证仅授权用于 Claude Code，不能用于其他 API 请求。」
(LLM request rejected: This credential is only authorized for use with Claude Code and cannot be used for other API requests.)

https://x.com/Yuchenj_UW/status/2009691122940211201
https://x.com/theo/status/2009464346846621700

你是不是经常遇到 codex 长时间运行但是完全不知道它是活着还是死了，薛定谔的猫状态发生了，你想手动停掉，又告诉自己，也许它还在运行呢，也许再等等？ 平白耽误了时间，这个月 tokens 又花不完啦，中了 openai 控流的奸计。

好了，现在有了一个 Codex_Stuck 小插件，通过巧妙的（实际上笨拙的）设计，让你的终端时时展示 cx 状态，尤其是是否 stuck. 废话不多说，上链接：

点它！安它！星它！

这其实是为了给 ccb 和 cca 打造的监测器，后面会集成到 ccb 中，当然独立使用完全无问题啦。

另外 ccb 更新到 3.0 版本啦： 只能说强到没朋友，快去试试吧：

DeepSeek V4 大模型被曝春节前后发布：AI 编程能力超越 OpenAI GPT 及 Anthropic Claude - IT 之家

新的羊毛 看广告获得
Opus 4.5

特别说明

• 我们为你提供从竞争白热化的移动互联网红海赛道，向 AI-native 应用全新蓝海领域转型的稀缺战略机遇。
• 我们秉持结果导向，核心团队均由各领域资深专家领衔，从根源上杜绝 “外行指导内行” 的情况；管理上坚决摒弃微观管理（micro-manage），充分赋予团队自主决策与执行空间。
• 团队成员中既有退役军人，也有伙伴；既有大专生，也有博士后。人员背景多元包容，招聘不设学历门槛，始终坚持唯才是举。

官网

职位描述

• 主导 Android 端核心数据采集方案的设计与落地，负责主流及高难度 APP 的数据挖掘，包括复杂 UI 交互分析、数据交互逻辑还原、加密协议破解等核心工作，为 AI 大模型训练提供高质量数据支撑。
• 深耕 Android 端逆向工程：负责 Android APP 的脱壳、加解密分析，精通 Smali/Java 代码还原，基于 Arm64 指令集进行汇编级分析，主导 Xposed/LSPosed 插件、Frida 脚本的设计与开发，实现对目标 APP 的 Hook 与数据拦截。
• 主导 Android 端风控对抗体系搭建：针对 APP 端的设备指纹（IMEI/AndroidID/OAID）、Root 检测、行为验证、签名校验、进程注入检测等风控策略，设计并落地有效的对抗方案，保障采集任务的稳定运行。
• 负责 Android 端自动化采集框架的设计与优化：基于 UiAutomator、Espresso 等框架封装高效的自动化采集工具，实现复杂场景下的 APP 自动操作、数据提取与异常重试，提升采集效率与稳定性。
• 参与 Web 端中高难度数据采集任务：基于 Python 生态爬虫框架（Scrapy/Playwright）开发复杂动态渲染页面（SPA/Vue/React）的抓取逻辑，协助破解 Web 端 JS 混淆、参数签名等加密机制。
• 深入分析 Web 及 Android 端网络协议（HTTP/HTTPS/WebSocket/gRPC），主导复杂协议的还原与模拟，协助构建分布式数据采集架构，参与采集任务的分布式调度与性能优化（并发控制、速率调节）。
• 协同 AI 算法团队输出标准化数据格式，优化数据采集流程与质量校验机制；沉淀 Android 逆向、双端风控对抗等技术经验，形成技术文档与团队共享。

岗位要求

• 3～5 年数据采集相关经验，其中至少 2 年以上 Android 端数据采集 / 逆向核心经验，具备高难度 Android APP 逆向（如加固脱壳、复杂加密协议还原）及风控对抗的实战落地案例。
• 精通 Android Framework，深入理解 AccessibilityService 原理、UI 渲染机制、AMS/PMS 等系统服务工作流程；熟练掌握 Smali 指令、Arm64 指令集，能够独立完成 Android APP 的静态分析与动态调试。
• 具备扎实的 Android 开发与逆向技能：能够独立开发 Xposed/LSPosed 插件、Frida 脚本；熟练使用 IDA Pro、Jadx、Apktool 等逆向工具；有 APP 加固（360 加固、爱加密等）脱壳经验者优先。
• 精通 Android 端网络协议分析：能够使用 Charles/Fiddler/Wireshark 等工具完成复杂网络抓包，独立还原 HTTPS/WebSocket 等协议的加密交互逻辑；了解 Android 端网络请求框架（OkHttp/Retrofit）的工作原理。
• 具备 Web 端数据采集基础：熟悉 Python 编程语言，熟练使用 Scrapy、Playwright 等爬虫框架及数据解析工具；具备 Web 端 JS 逆向、参数加密破解、基础反爬（IP 代理、浏览器指纹）对抗经验。
• 了解分布式数据采集架构：熟悉 Redis（缓存 / 队列）、MongoDB 等中间件的使用，能够基于 Scrapy-Redis 等框架实现简单的分布式任务调度；具备大规模数据采集场景下的问题排查与性能优化能力。
• 具备较强的独立攻坚能力、问题分析与解决能力，良好的沟通协作意识与技术沉淀意愿，能承受高难度任务压力，自驱力强。

工作地址

北京市海淀区清华同方科技广场 D 座 20 层 或 北京市朝阳区锐创国际中心 A 座 12 层

薪资

30 ~ 50 * 13 薪

联系方式

yinglu@pureblueai.com

从 GLM 4.7 看国产模型在编程方向的发展

前几天看到公益站的 token 消耗量超过了三百亿，再加上自己也用 GLM vibe coding 了好几个小玩具，感慨良多，于是想向各位佬友分享一下我个人对 vibe coding 的感受和对国产模型的看法。

1. 我的 AI 接触史

我个人可以算是较早体验 AI 的一批人之一了，最开始我是从 AI 绘图开始了解相关方面的内容的。NovelAI 于 2022 年 10 月份泄露了自己的模型权重文件，随后各式各样的 AI 绘画站点如雨后春笋版涌现了出来。当时给我的体验惊为天人，只需要简单的输入就可以生成一张看着不错的图片，虽然这些照片以现在的眼光看还不够格，比如手部崩坏，边缘模糊，充满了 AI 的油腻（扩散式模型的底层问题），但在当时的环境看这无疑于开创性的技术，让一位对绘画一窍不通的用户，仅需要简单描述即可生成一张对应的精美图片，甚至我的博客封面就是用当时的 AI 画的：

（那个画架子是我自己拿 PS 描的，然后简单勾了一下手和身体的轮廓）

随后 OpenAI 于 2022 年 11 月 30 日发布了 GPT3.5 模型，我加入的各大 AI 交流群都在讨论相关内容，我是在 23 年 1 月初加入的，间隔了一个来月左右，也是因为这事学会了科学上网：

ChatGPT 的出现也引发了轰动，大家最开始根本不敢相信对话的背后居然是一个机器，它颠覆了人们对于机器聊天 “死板，机械回复，套回复模板” 的印象，而我当时正在编写一个 python 小工具，但苦于我根本不会 python 编程，而且网上的相关资料都是泛泛而谈，针对实现的技术细节都是一带而过，导致我就是无法实现想要的结果。后来我实在走投无路的情况下，将我的问题和代码发给了 GPT，一下子给我生成了一套可以运行的代码，给小小的我带来了巨大的震撼。

而当时的 ChatGPT 还没有降智等一系列恶心人的操作，而国内基于 ChatGPT 的镜像站雨后春笋一般冒了出来，当时 GPT 就是我心中的白月光，万能神一般的存在。

2. 国产 AI 发展记

ChatGPT 虽好，但是它限制国人使用，我也不是每时每刻都开着梯子，而且我用的免费梯子稳定性其实也不是那么理想，于是就开始寻求国产替代，我希望直连也能使用。但是在 2023 年上半年几乎没有可用的国内模型，不是 GPT 套壳就是答非所问，远远比不上我想要的结果。始皇的 Pandora next 我也体验过，但是速度还是不是太理想，而且希望能有一个可以一直使用不需要频繁换号的平台，而且最重要的是，它需要简单易用，最好点开就能问，不需要研究各种各样的问题就能使用。

阿里的通义千问是在 23 年上 4-5 月份开始内测，下半年正式发布。而它的出现也为 ai 使用体验带来了一个转机。然而，早期的通义千问体验非常糟糕，提示词遵循也不是很理想，而且最重要的是输入框一次只能输入一万个字，如果有长代码粘贴过去根本输不进去，导致几乎无法用它来写项目（其实现在通义千问体验也不咋地，比如传图之后没法追问，图片提问的回答没法继承进聊天记录，当内容长度超过上下文限制选择粗暴地截断而非内容压缩，但是国产模型没几个能打的）。

不过千问刚出来那会，api 是免费调用的，相对于 ChatGPT 又是需要中转又是需要花钱而言，千问为我提供了一条新的选择路线，当时用千问糊了一个聊天小玩具（虽然最后因为自己能力原因没整完），但后来想想，当时的很多想法都是非常具有前瞻性的，比如我想过通过提示词工程让 ai 输出 json 格式的内容从而让后续的程序识别（格式化输出），让 ai 总结并记住对话中的关键信息（记忆），甚至让 ai 通过输出 json 来控制其他 api 返回结果（mcp 服务器）等，但是受限于模型的指令遵循实在不咋地，这些都没能实现。

后来更多国产模型也发布了出来，比如智谱，比如百度，比如零一万物等，但是我还是觉得国产也就千问算是可用水平，其他的模型什么文心大模型跟个智障一样根本不能用，还敢收一笔不少的 vip 费用。

然而，通义不知道是不是网页调用因为一直在滚动发版，智力时高时低。甚至有一段时间，代码里面莫名其妙的加入了.jpg 等输出，以及意义不明的括号（，导致根本无法使用。和群友交流时猜测，这可能是通义千问用了聊天记录作为训练数据，而聊天过程中喜欢用反括号，以及吐槽表情包.jpg 等，导致污染模型。比如震惊.jpg, 感觉不像xxx（这种表述。所以通义千问一直只是作为一个备选方案使用。

3.AI Coding 的接触

后来，随着我的工作量和复杂度增加，很多时候需要一些一次性的代码处理一些重复的工作。比如我需要完成批量处理某项工作，而相对于手动处理既费时又费力，写一个 python 脚本批量处理就显得非常有价值。然而，假如我处理这个工作需要半个小时，耗费 20 分钟查资料写一个代码就显得得不偿失。而这时候就需要借助 ai 的力量。

然而，国产 AI 在代码方面表现的不是特别理想，经常自造函数，格式错乱，虚拟实现（比如注释写 #这里实现 xxx 的逻辑，但是我就是要你实现相对的逻辑呀），而且更为致命的是，我使用的是网页 AI，经常喜欢偷懒（比如让全部输出，然而只输出修改的一部分，比如这样：

用户：输出完整代码
AI：好的，我将为您输出完整代码...
一堆导入
...（这里是xx的实现）
修改的代码
...（这里是剩下的代码）

AI 就会给我输出这里是剩下的代码而非具体代码，这对我这种 CV 工程师非常不友好。再加上 OpenAI 学会了降智，降智后的 AI 根本用不了，有种一拳打在棉花上的感觉。

随后 OpenAI 封号潮、降智潮，始皇转投 Claude，我也转去了 Claude。确实 Claude 的代码水平相对于 ChatGPT 有显著的提升，或者说 Claude 的设计感觉就是为了代码等服务的–artifact 设计可以让他只修改不必重复输出（千问的那个代码模式真的就是每次都在重复输出），指令遵循都相对于其他模型显著提升（比如同期的 GPT 真的很喜欢给我写假设您的后端地址为 XXX，这里需要实现 xxx）。但是好景不长，克劳德开始全方位降智，封号，我第一个注册的 GPT 账号都没封号，克劳德账号被封掉了。

克劳德是一个好模型，但 Anthropic 不是一个好公司。封号，降智，暗改模型用量这些不管是国内还是国外都在骂。还有贵的离谱的 API 价格和订阅价格，实在对我这种开发者不是特别友好。而使用的镜像站一直在封号、达到使用限度，可用性非常差，经常问两个问题就达到了使用限制必须换车。我用的镜像站还不错，客服回复速度也很给力，然而一直封号也不是镜像站能改变的。随着九月份 Anthropic 公开称中国为敌对国家，我也放弃继续使用克劳德的想法。

DeepSeek 的出现为国产模型带来了一个新的转机。它准确率高、便宜大碗，可以用克劳德几分之一的价格实现克劳德一半的准确率。但 DeepSeek 唯一的缺点可能就是太废话了，一个简单的问题需要思考几分钟，不停地左脑攻击右脑，循环否定之前的想法和设计，对于一个编程问题而言需要消耗的时间太长了。至于其他佬友说的准确问题，在它低廉的价格面前都不值一提–穷是最大的问题，克劳德 200 美刀的 Max 会员对我而言实在是遥不可及，对于一个爱好编程的个人开发者而言，一个月掏出来一千五多就为了一个 AI 确实有点拿不出来。至于镜像站，可用性一直不算特别稳定，DeepSeek 都不嫌我穷，我怎么能嫌弃他傻呢。

4. 智谱 Coding Plan 的出现

随着九月份那会智谱在 Anthropic 封号潮那会推出了 Coding Plan，宣称 “平替 Claude Code”，以 Claude 七分之一的价格提供了远超 Claude 同等套餐几倍的用量。当时我接触后惊为天人，速度快、便宜量大，我的第一个套餐是开通的 lite 套餐，只到达过一次限额，以我的使用量根本到不了限额。但是 GLM 4.5 并没有对 Claude Code 等工具进行优化，它的工具调用仍然处于 “推一步走一步” 的等级，仍然透着一股子傻傻的气息。而且最重要的是不支持思考，是否思考对于 GLM 的体验区别确实天上地下。

我当时正在学着写鸿蒙 ArkTs，鸿蒙作为一门新兴的语言，本身训练资料就不多，再加上随着 AI 的出现，网上大量 AI 生成的错误资源污染，导致 AI 根本无从学起。然而，我让 AI “每次运行完之后调用 hvigorw 编译”，有的时候 AI 修改–编译出错–修改–编译出错，这么循环十几遍甚至几十遍最后确实能编译成功。当时我吐槽 GLM “傻但是劲儿大”。

好景不长，随着一系列活动的推出，再加上智谱应该是在训练新模型，GLM 也出现了肉眼可见的降智。虽然智谱官方一直说不可能降智，但是确实体验程度差了太多。我严重怀疑是路由到了 flash 模型上，和原来聪明的 GLM4.5 有天壤之别。由于方便我一直开着 skip-dangerously-permission 权限，但 GLM 就像是傻子一样，瞎改我的代码，发现代码出错之后 “好的，现在我要简化代码” 随后删除了几十个我实现的功能。甚至在改了几十遍没改好之后决定回退 git 版本 —— 但是我的 git 版本是好几十个版本之前，导致了我写的所有功能全部遗失。这让我一度对 GLM 失去信心，当时发现改了好长时间的代码被回退，我都想哭了。

当时的 GLM 智力时高时低，高的时候真的不错，低的时候乱改代码都是基本操作，比如清理项目把我的前端代码删个精光：

但出于对国产模型的信任，我还是升级到了季度的 Max 会员，无它，太便宜了，高用量让我可以随便改，大不了多用 git 提交下呗，穷是我的问题呗。

GLM4.6 的出现相对 4.5 有了很大的改善。但是还是同样的降智问题，而且完全没有任何规律可言：有的时候凌晨三点我用还是会出现明显的降智，有的时候下午最高峰使用效果也不错，整体是抽卡一样的准确率，而且完全没什么规律。最常见的操作是我想让他调用 mcp 搜索，已经在提示词中指定了 “请使用 mcp 搜索”，但是它不是调用 Web Search 工具（cc 内置，用不了一点）或者调用 Search（搜索本地代码的工具），智力忽高忽低。

尽管如此，它还是为数不多的国内畅用的模型。kimi、通义也推出了相对的 Coding plan，但 kimi 用量太低了，通义的 qoder 有种奇怪的感觉，有种差了点意思但又说不上来的感觉。

我也基于这个计划开了一个公益站，三个月以来用了三百多亿的 token，后面只接了一个 key，只能说性价比确实无敌。

（那个 mimo 的 key，费用是错的，数据库里面没有对应的价格值导致计费错误）

直到 GLM 4.7 的出现，体验效果得到了大幅度改善。最重点的是终于支持交叉思考了，思考或者不思考的模型体验真的是一个天上一个地下。虽然我一直觉得大模型的思考链就是一个伪需求，AI 完全不知道什么是思考，只是提示词带来的结果而已，但是它确实让结果变好，那就当他有用吧。

4.7 第二个改善是内置了搜索和网页阅读工具，这使得我不需要专门安装对应的 MCP 也可以使用。对于一台新的机器，只需要安装 Claude code 然后设置 Base url 和 api key 即可使用，ai 在回答的过程中也可以调用搜索工具去搜索官方的文档，从而大幅度提升准确率和可用性。

同时，4.7 的审美也大幅度提升，在之前 GLM，以及几乎所有的 AI 模型都喜欢用 emoji 做图标，虽然方便但是总有一种非常不专业的感觉。但是 4.7 会新建 SVG 文件作为图标，虽然不如开源图标库，比如华为自带的 HarmonyOS Design 或者 Font Awesome，但是方便，快捷，相对于 emoji 来说提升很大，比如这个是完全由 4.7 设计的 UI：

可以看到，下方的图标还是有点小问题，但是整体看不出太大的毛病，作为完全由 AI 生成的 UI 来说够格了。

我也借助 AI 糊了几个小玩具出来。比如学校使用的教务系统，整体就是一个 WebView 套壳，不仅稳定性不佳，而且课程查看非常不直观，透着一股子上个世纪的风格。我完全借助 AI，使用 Kotlin 完成了安卓端课程表的开发，并将其转成了 Swift（ios）和 Arkts（鸿蒙）三端原生适配，虽然软件还是有一大堆的 bug，但是不耽误日常使用，代码能跑起来就行了要啥自行车

至于它的优势，我觉得可能是便宜量大。用 Claude 一直在提心吊胆地看着 cost 耗费，几个问题下去都能感受到白花花的银子消耗声，经常没问几个问题下去就耗费了几十块 RMB，而问题还没显得解决。而用智谱可以随便问，甚至懒得跑了可以让 AI 帮着我运行，直接一个你给我运行此代码就让 AI 代劳，还不用担心耗费，可以随心所欲地使用。

至于能力、准确率，我认为目前最高的模型仍然是 Opus 4.5，它的准确率可以到达 98，但是价格是 10；GLM 4.7 单次对话准确率可以到达 85 到 90，但是价格可能只有 2-3 不到，一切问题在它的价格面前都不值一提。opus 一次能解决的问题，glm4.7 问个几遍也可以解决。可能有些佬工资足够到掏 200 美刀不眨一下眼睛或者公司报销 AI 使用费，但对于初学者而言，20 块钱的 GLM 更有性价比，而且还不用折腾什么家宽，什么环境，开箱即用，更适合上手。

5. 结语

整体而言，我对国产 AI 模型的发展持乐观态度。国外模型虽好，但对国内实行全方位的禁用，门槛太高，学习成本太大。而相对比，国产模型可以以更低廉的成本、更低的学习成本实现相似的能力，让更多非 IT 从业者，非计算机科班的人也可以使用编程完成一些重复但简单的工作。很多时候，我们需要的仅仅是一个 “一次性代码”，解决完某个问题后代码便完成了使命，不需要完整、可移植，只要完成某个特定的任务即可。这样通过 AI，哪怕是完全对计算机一窍不通的人，也可以使用 AI 工具完成一个小的网页、一个小的工具等，方便日常生活的同时把编程推向大众化、简单化。

今天 Thariq (来自 Anthropic） 再 X 表示，他们将对使用 Claude 订阅但通过第三方安软件使用行为做出账号封禁，同时也升级了内部系统来检测这个行为。

原文：
Yesterday we tightened our safeguards against spoofing the Claude Code harness after accounts were banned for triggering abuse filters from third-party harnesses using Claude subscriptions.

但是 Open AI 相反，表示将努力支持 OpenCode:

又有人独家爆料表示：
xAI （grok) 的员工之前一直通过 Cursor 在内部使用 Anthropic 的模型。直到本周 Anthropic 切断了这家初创公司的访问权限。据 Cursor 称，这是 Anthropic 对其所有主要竞争对手强制执行的新政策。