Windows（管理员终端） ，注意，.codebuddy 必须存在，.codebuddy\rules 的rules 必须删除

一、模型选择

（一）deepseek-v4-pro

• 超长文本深度学术研究与复杂数学推理：依托 1M 上下文与 MoE 架构，在 AIME 2025 等数学基准达 94.5%，适合大规模论文综述、跨文献知识发现、复杂定理证明及科学研究中的多步逻辑推演
• 高敏感领域合规审查与风险分析：凭借开源第一梯队的代码可信度和低幻觉特性，适合金融衍生品模型审计、法律合同跨文档比对、监管合规长文本核查等对准确性要求极端苛刻的场景

（二）deepseek-v4-flash

• 高并发实时推理服务与边缘 AI 部署：速度比 Pro 快 3-4 倍且单 Mac Studio 可本地运行 1M 上下文，适合实时推荐系统、智能客服高并发后端、边缘设备（如工控机）上的离线语义理解
• 大规模私有知识库的即时检索增强（RAG）：结合 1M 上下文与极低缓存成本（$0.014/M），适合企业内部超大规模文档库（如百万页级技术手册、历史档案）的秒级语义检索与精准问答

（三）Qwen/Qwen3.6-27B

• 视觉-语言交互式教育与培训：原生多模态支持对教学视频、实验流程图、几何图形进行实时讲解与步骤拆解，适合 K12/职业教育中的"看图解题"、虚拟实验指导、交互式课件生成
• 工业视觉质检与多模态制造辅助：27B 稠密架构可部署于工厂边缘端，直接分析产品瑕疵照片、设备仪表盘读数、工程图纸，实现"视觉输入→工艺建议/维修方案"的闭环

（四）Pro/zai-org/GLM-5.1

• 自主科学实验设计与长周期研究执行：8 小时持续工作 + 自我评估优化能力，适合自动化假设验证、实验参数调优、科研数据清洗分析等需要长时间无人值守的科学研究工作流
• 超大规模软件生态的自动化演进维护：SWE-Bench Pro 全球最佳表现，适合操作系统内核级维护、大型开源社区的技术债自动修复、跨版本依赖迁移等需要深度理解复杂代码生态的任务

（五）Pro/moonshotai/Kimi-K2.6

• 超大规模多 Agent 协作模拟与复杂系统治理：300 子 Agent 并行 + 4000 协作步骤，适合城市级交通流量模拟、复杂供应链多节点协同优化、分布式科研团队的虚拟协作中枢
• 长周期沉浸式创意内容生产：13 小时连续编码/创作能力结合视觉深度融合，适合电影级互动叙事内容生成、大型游戏世界观与关卡设计的自动化构建、长期品牌视觉资产的系统性生产

二、经验精华

• 上下文管理
  • 建立索引，按需加载
  • 定期清理总结

三、多智能体工作

（一）Codebuddy子代理

官方文档： https://www.codebuddy.cn/docs/cli/sub-agents

四、多个 AI 编程工具使用同一个 rule

通过 mklink ，只能在 cmd 模式下，不能在 powershell 中运行

CodeBuddy

# Windows（管理员终端） ，注意，.codebuddy 必须存在，.codebuddy\rules 的rules 必须删除
mklink /J .codebuddy\rules .my-ai-rules 

# macOS/Linux 
ln -s .ai-rules .codebuddy/rules

Antigravity

# Windows
mklink /J .agent\rules .my-ai-rules

# macOS/Linux
ln -s .ai-rules .agent/rules

trae

# Windows
mklink /J .trae\rules .my-ai-rules

# macOS/Linux
ln -s .ai-rules .agent/rules

五、上下文 k 数的理解

• “128k 上下文” 中的「128k」指的是模型可处理的文本 Token（令牌）数量，而非文档存储容量的 KB（千字节）。
• 128k Token 对中文的覆盖度：≈9.6 万个中文字（128000 × 0.75），你的保险 MD 文档（约 400 行、数万字）仅需几万 Token 就能完整加载，128k 窗口无需分段拼接，可一次性处理全文；

六、Token 消耗

• 1千万token，可以分析40个pdf条款，pdf平均17页
  • K：Kilo 的缩写，代表千，1K Tokens = 1000 Tokens；
  • M：Mega 的缩写，代表百万，1M Tokens = 1,000,000 Tokens = 1000K Tokens；
• vison模型的输入和输出的 token 差不多量：

Open: Pasted image 20260202130643.png

GLM-OCR 0.9B 新出 - GLM-OCR 在0.9B参数下实现SOTA性能，超越多个权威基准测试。 - 针对复杂文档场景进行优化，支持表格、结构化提取、手写体等高难度任务。 - 成本极低，API价格仅为传统方案的1/10，处理千张A4扫描件仅需0.5元。

---

七、模型命名特点

Qwen3-VL-235B-A22B-Instruct - A = Activated（激活的），表示该模型采用MoE架构，仅激活部分专家参数而非全部 - 22B = 22 Billion（220亿），表示每个token在推理时仅激活约220亿参数 - 命名规则：Qwen3-VL-总参数量B-A激活参数量B-Instruct，因此Qwen3-VL-235B-A22B-Instruct表示：总参数量2350亿，每个token激活220亿参数的视觉语言指令微调模型

Qwen3-VL-235B-A22B-Instruct 对比 Qwen3-VL-32B-Instruct

对比维度	Qwen3-VL-235B-A22B-Instruct	Qwen3-VL-32B-Instruct
架构类型	MoE（混合专家）模型，94层，64个专家/层，每层激活4个专家	Dense（稠密）模型，无专家并行结构
总参数量	235B（2350亿），MoE模型典型特征	32B（320亿），稠密模型标准规模
激活参数量	22B（220亿），仅激活总参数的约9.36%	32B（全部激活），稠密模型推理时激活所有参数
性能定位	旗舰级视觉语言模型，在MMStar、AIME等复杂推理任务中表现顶尖	高性能轻量级模型，保持235B版本约85%能力覆盖
硬件需求	极高，需多GPU集群（如8×H100），推理成本高	中高，单/多GPU即可部署，硬件需求降低约60%
推理速度	较慢（因MoE路由开销），适合对延迟不敏感的高精度任务	较快（稠密模型无路由开销），适合实时交互场景
适用场景	复杂视觉推理、科学计算、专业领域多模态分析、视频深度理解	通用图文问答、OCR识别、基础视觉理解、移动端/边缘部署

Qwen3-VL-32B-Instruct 对比 Qwen3-VL-32B-Thinking

• 简单任务+高速度+有限硬件 → Instruct版本
• 复杂任务+高精度+充足硬件 → Thinking版本

模型	核心定位	设计理念	训练重点
Qwen3-VL-32B-Instruct	高效响应型多模态助手	"快速执行，稳定输出"，面向日常高频交互场景	指令遵循、快速问答、基础视觉理解、工具调用
Qwen3-VL-32B-Thinking	深度推理型视觉专家	"先思考，再作答"，面向复杂逻辑推理任务	思维链生成、多步推理、复杂视觉分析、反事实思考

• Instruct版本：采用直接响应机制，输入→理解→输出，无显式中间推理步骤，响应速度快，适合实时交互
• Thinking版本：引入强化学习驱动的思维链(CoT)机制，输入→思考(生成推理步骤)→验证→输出，实现"深度思考"

Qwen3-VL-32B-Instruct 最佳场景

1. 日常图文交互：聊天机器人、基础图像问答、OCR识别、简单翻译
2. 高频基础工具调用：文档扫描、图像分类、视频摘要、快速信息提取
3. 低延迟应用：实时客服、移动端APP集成、边缘计算设备
4. 大规模批量处理：文档OCR、图像标签生成、视频帧分析

Qwen3-VL-32B-Thinking 最佳场景

1. 复杂视觉推理：科学研究图像分析、工程图纸解读、医疗影像诊断辅助
2. 数学/逻辑难题：数学竞赛题、几何证明、逻辑推理、因果分析
3. 反事实与假设性思考："如果...会怎样"的场景模拟、风险评估、策略规划
4. 深度内容创作：基于图像的故事创作、产品设计思路生成、创意广告文案
5. AI代理任务：操作系统交互、GUI界面操作、多步骤工具组合使用

---

八、火山引擎API开通

火山引擎的使用，需要两个 Key：

1、API Key:

• API Key 管理中

2、接入点 API：

• 在线推理 > 自定义推理接入点 > 创建推理接入点

• 这个就是 接入点 API

九、Hook 钩子

Hook（中文常译「钩子」）的核心思想就像：

在程序执行的某个固定节点（比如「函数开始执行」「数据处理完成」「按钮被点击」），提前「挂」上一段你自己的代码。这样既不用修改原有程序的核心逻辑，又能在这个节点插入自定义操作。

举个生活例子：

你点外卖的默认流程是「下单 → 商家接单 → 配送 → 收货」。如果想在「商家接单」这个节点加个「给你发微信提醒」的操作，这个「提醒操作」就是一个 Hook—— 它挂在「接单」这个节点上，不改变外卖平台的核心流程，但实现了额外功能。

代码例子

# 1. 定义两个 Hook 函数（钩子）
def before_hook():
    """前置 Hook：函数执行前触发"""
    print("✅ 前置 Hook 触发：检查参数合法性、记录开始时间")

def after_hook():
    """后置 Hook：函数执行后触发"""
    print("✅ 后置 Hook 触发：记录执行结果、计算耗时")

# 2. 定义核心业务函数
def core_function():
    """核心业务逻辑：原本的功能"""
    # 执行前置 Hook
    before_hook()

    # 核心逻辑（真正要做的事）
    print("📌 核心业务执行：处理用户请求")

    # 执行后置 Hook
    after_hook()

# 3. 运行测试
if __name__ == "__main__":
    core_function()

# 输出结果
✅ 前置 Hook 触发：检查参数合法性、记录开始时间
📌 核心业务执行：处理用户请求
✅ 后置 Hook 触发：记录执行结果、计算耗时 

codebuddy cli 中使用 hook：

• 它分前置和后置

Hook 名称	触发时机	典型用途
pre-run	执行 codebuddy run <文件> 前	检查环境（Node / 依赖）、校验代码格式、权限检查
post-run	执行 codebuddy run <文件> 后	生成日志、清理临时文件、发送执行结果通知
pre-build	执行 codebuddy build 前	检查构建配置、校验源码完整性
post-build	执行 codebuddy build 后	压缩构建产物、上传到服务器、生成构建报告
pre-install	执行 codebuddy install 前	检查网络、清理旧依赖

Hook 机制说明
- 配置文件: .codebuddy/settings.json
- 脚本: .codebuddy/hooks/chat-log.py
- 触发时机: 每次 Agent 响应结束时（Stop 事件）
- 工作流程: 读取 transcript_path → 提取最后一轮对话 → 调用 chat_mark.py --user "..." --ai "..." → 直接写入 chat/*.md + MySQL
- 跳过规则: 用户输入 ≤ 4 字符时不记录（过滤"开启"等系统指令）
下次新会话启动后，对话记录应该会自动写入。如果 Hook 需要审查才能生效，请在 CodeBuddy 中执行 /hooks 确认。
---
Hook 是什么
Hook 就是自动触发的脚本。你不需要手动调用它，CodeBuddy 会在特定时机自动执行。
我配置的是 Stop Hook——每次我（AI）回复完成后，自动触发 .codebuddy/hooks/chat-log.py，把对话写入 chat/ 目录。
你唯一需要做的事
由于 .codebuddy/settings.json 是外部新建的文件，CodeBuddy 可能会要求你审查批准。操作方式：
1. 在 CodeBuddy CLI 中输入 /hooks 查看已注册的 Hook
2. 如果有提示需要审查，按提示确认即可
审查通过后，Hook 就会在每次对话结束时自动运行，你什么都不用管。

提示词Prompt

分行写更好

方案1:

Color palette:
#D6B844
#F1EFEA
#FEE28F
#C4892B
#171717

Style:
modern Chinese luxury,
premium consulting brand,
editorial minimalism,
high-end corporate branding,
luxury financial institution aesthetics,
strategic consulting visual language.

方案2:

Color palette:,#D6B844,#F1EFEA,#FEE28F,#C4892B,#171717.

Style:modern Chinese luxury,premium consulting brand,editorial minimalism,high-end corporate branding,luxury financial institution aesthetics,strategic consulting visual language.

方案1比方案2更好，因为：

• 语义边界清晰，解析歧义更低
• 层级结构明确，属性归类准确
• 注意力分配均匀，关键词权重稳定
• 契合训练数据范式，解析准确率更高