企业官网建设流程全解析

Python 与 TypeScript CLI：处理不规范模型输出的工程边界

CLI 接模型服务时，经常遇到的不是“模型慢”，而是输出无法按预期结构解析：代码块外多了一句解释、字段类型漂移，或流式响应在中途断开。本文给出一个面向工具开发的处理框架；它不是某个生产系统的压测报告，也不预设任何延迟或资源指标。

先区分输入契约和展示文本

如果后续逻辑需要 JSON，就应把 JSON 看作协议，而不是从自然语言里猜出来的附属物。请求中说明 schema，响应端先提取结构化通道，再交给校验器。Python 可以用 Pydantic，TypeScript 可以用 Zod 或项目已有的 schema 工具。校验失败时返回可读错误和请求标识，而不是递归地把同一段输出重新喂给解析器。

一个常见的错误是用宽松正则在字符串里寻找花括号。它面对嵌套对象、转义字符和 Markdown 代码块很脆弱，也容易把不完整片段交给JSON.parse。更稳妥的做法是设定最大响应字节数、读取超时和单次解析次数；超过任一边界就结束本次任务，并将原始片段作为受控诊断信息保存。

Python 侧的责任

Python 进程适合承担编排和 I/O，但不应无上限创建协程。给每个外部调用设置 timeout，使用有界 semaphore 控制并发，并把取消信号传到下游请求。错误对象里保留错误类别，例如schema_invalid、upstream_timeout和transport_error，调用方才能决定是提示用户修改参数，还是稍后重试。

诊断日志不要直接打印完整 prompt 或模型响应。CLI 用户经常把路径、令牌或业务文本带进参数；记录长度、哈希、请求 ID 和脱敏后的错误片段，通常足以定位问题。需要复现时再由有权限的人读取受保护的原始记录。

TypeScript 侧的责任

TypeScript 命令行工具应在入口处完成参数解析和 schema 校验，把内部函数收到的类型收紧。不要用as SomeType跳过校验，也不要因为一个请求失败就让交互式会话退出。对于流式输出，先累积到明确的协议边界，再调用解析函数；中途断流时输出未完成状态，并给用户继续、重试或导出诊断编号的选择。

跨语言调用需要明确传递格式。Python 子进程若输出 JSON，stdout 应只写机器可读内容，人的提示写入 stderr；否则一行进度信息就能破坏 TypeScript 端的解析。退出码也要固定含义，避免上层把参数错误误判成网络故障。

如何验证这套边界

验证样例至少包括：合法 JSON、代码块包裹的 JSON、缺字段、字段类型错误、截断响应、超长响应和取消请求。每种样例检查三件事：命令是否在可预期时间内结束、是否给出可诊断的错误类别、是否没有泄露输入内容。再以真实项目的机器规格和调用量观察队列长度、错误分布与退出码，才可以讨论容量配置。

模型输出不可完全控制，CLI 可以控制的是接收、校验和失败返回的方式。把这些边界先写清楚，工具在异常输入下才不会用看似“智能”的重试掩盖问题。