WorkBuddy会静默截断超长输入，非卡顿或崩溃；单次请求限8K–12K字符，预处理阶段直接截尾；需手动分块、用对应tokenizer精确测token数，并优化PDF解析与prompt设计。

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

WorkBuddy 会截断输入，不是卡顿或崩溃

WorkBuddy 对单次请求的文本长度有硬性限制，超长文档提交后不会报错、不提示截断，而是静默丢弃超出部分——你看到的“处理完成”结果，可能只基于前 8K–12K 字符（具体取决于模型版本和 API 配置）。这不是性能问题，是设计上的输入守门机制。

• truncate 行为发生在预处理阶段，input_ids 超过 max_position_embeddings（如 Llama-3-8B 是 8192）时直接截尾
• PDF/Word 等文件上传后由解析服务转成纯文本，再送入 WorkBuddy；若解析出的文本本身含大量空格、换行、页眉页脚，实际有效内容可能远少于原始页数预期
• 用 len(text) 或 text.count(" ")+1 估算 token 数极不准；应改用对应 tokenizer 的 encode 方法，例如：

  from transformers import AutoTokenizer<br>tok = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct")<br>len(tok.encode("你的文本"))

分块处理必须自己做，WorkBuddy 不自动切片

它没有内置文档分块（chunking）逻辑，也不会保留跨块上下文。如果你把一份 50 页合同按整份提交，它只看到开头几页；想覆盖全文，得在调用前手动切分，并自行管理块间关系。

• 推荐按语义切分：优先在 "\n\n"、"## "、"第X条" 等结构标记处分割，而非固定字数切分
• 每块建议控制在 3K–6K tokens，预留至少 1K tokens 给 prompt 和输出空间，避免触发 max_new_tokens 截断
• 若需汇总多块结果（如“从全文提取所有违约责任条款”），不能靠多次独立调用后拼答案——得加一层聚合逻辑，比如用总结性 prompt 再喂一次各块摘要

PDF 解析质量直接影响 WorkBuddy 输出可靠性

WorkBuddy 不直接读 PDF，依赖上游 OCR 或文本提取服务。扫描版 PDF 若未开 OCR，或表格/多栏排版未对齐，解析结果可能是乱序文字堆叠，这时再强的模型也难纠错。

workbuddy-pet

WorkBuddy 桌宠工厂 —— 给一张角色图、一个 codex.pet 链接、一条 codex-pets.net 下载 URL、或一份现成的精灵表，就能自动创建一只可联动 WorkBuddy 状态的桌面宠物。当用户说"创建桌宠"、"做一只桌宠"、"用这张图做桌宠"、"从 codex.pet 安装桌宠"、"导入 codex 桌宠 XX"、"装一下 codex-pets.net 上的 XX&quo

下载

• 检查解析后文本是否含大量 ""、"□"、异常空格或颠倒段落序号——这些是解析失败信号
• 对扫描件，务必确认解析服务启用了 ocr=True（如 PyMuPDF 的 page.get_text(ocr=True)），否则纯图 PDF 返回空字符串
• 复杂表格建议先用 tabula-py 或 camelot 单独导出 CSV，再以结构化方式注入 prompt，比塞进大段解析文本更稳

长文档场景下，system prompt 要重写，不能复用短文本模板

默认 prompt 假设输入是对话级短文本，遇到万字合同或技术白皮书时，模型容易忽略关键约束条件（如“仅回答条款编号，不解释”），因为注意力被冗余描述稀释。

• 显式声明文档结构：“以下是一份包含 12 条款的 NDA，条款以‘第X条’开头，请逐条判断是否含保密期限定义”
• 强制输出格式放在 prompt 开头，而非末尾；模型对开头指令的记忆强度更高
• 避免使用“请仔细阅读全文”这类无效指令——它不改变截断事实，反而挤占 prompt 空间

真正卡住人的，从来不是模型能不能看长文档，而是谁在负责把“长”变成“可消化的块”，以及有没有验证那块到底被喂进去了多少。