AI 辅助独立创作与创意工具产品化：上下文预算与工具路由的实操边界
大模型处理非结构化创意时确实灵光，但在精确控制、结构转换和确定性规则上完全是个生手。解决这个问题的核心，不在于买更大上下文的 API Key，而在于重新划清上下文（Context）与工具（Tools）的工程分工。
上下文是感知记忆，工具是手臂与天平
把上下文当数据库用，是当下 AI 创意工具研发中最普遍的陷阱。
上下文窗口（Context Window）的本质是注意力算力的分配开销。一旦上下文膨胀到数十万 Token，模型的注意力就会被稀释，注意力机制在中间长文本段落的召回率会明显下降。如果让模型在 Prompt 里靠记忆去计算画布节点的坐标偏移，或者在 Prompt 里用文本去匹配 500 个样式模板，结果只能是概率性失效。
sequenceDiagram
autonumber
actor User as 用户编辑操作
participant Engine as 创意工具中枢 (Engine)
participant CtxMgr as 上下文裁剪器 (Context Manager)
participant ToolReg as 确定性工具链 (AST/Compiler)
participant LLM as LLM 决策引擎
User->>Engine: 修改节点属性并发送 Prompt
Engine->>CtxMgr: 提交原始历史与增量 Diff
CtxMgr->>CtxMgr: Token 预算评估与摘要压缩
CtxMgr–>>Engine: 返回精简 Prompt (< 8k tokens)
Engine->>LLM: 发送精简 Prompt + Tool Schemas
LLM–>>Engine: 返回 Tool Call (指定修改 node_03 坐标与颜色)
Engine->>ToolReg: 执行确定性工具 (node_03.update())
ToolReg–>>Engine: 返回执行状态 (Success, Hash)
Engine–>>User: 渲染最新画布状态
上下文只应当承担三件事：当前聚焦实体的元数据、用户最近两次的意图描述、以及提示词约束。至于样式的物理检验、Markdown 的 AST 解析、图表的自动排版、文件的 IO 读写，应全部交由确定性工具链（Compiler / AST Parser / WASM Engine）来完成。
用 tiktoken 监控 Token 泄漏
在搭建创作中枢时，我们可以在 Node.js 后端服务中直接挂载 tiktoken 和 HTTP 拦截器，查看每一轮请求的实际消耗。
终端执行测试命令：
curl -X POST http://127.0.0.1:8080/v1/context/analyze \\
-H "Content-Type: application/json" \\
-d '{"session_id": "sess_89211", "max_budget": 8000}'
输出日志中如果出现类似数据：
[Context Analysis] Session: sess_89211
– Raw System Prompt: 42,100 tokens (WARNING: High static overhead)
– Conversation History: 3,450 tokens
– Canvas AST Snapshot: 78,900 tokens (DANGER: Full state leaking)
– Free Budget Remaining: -94,450 tokens
这说明发生了典型的“全量状态泄漏”。画布的 AST 树不需要整个塞进 Prompt，只需要把用户当前选中的节点（Node ID）以及关联父节点序列提交给模型。
以下是负责上下文裁剪与工具派发的可落地的 TypeScript 实现：
import { get_encoding } from "tiktoken";
export interface NodeAST {
id: string;
type: string;
properties: Record<string, unknown>;
children?: string[];
}
export interface ContextWindowConfig {
maxTokenBudget: number;
systemPromptReserve: number;
toolSchemaReserve: number;
}
export class CreativeContextManager {
private encoder = get_encoding("cl100k_base");
private config: ContextWindowConfig;
constructor(config: ContextWindowConfig) {
this.config = config;
}
/**
* 提炼聚焦上下文，过滤无关 AST 节点
*/
public pruneCanvasAST(fullAst: Map<string, NodeAST>, activeNodeIds: string[]): Record<string, NodeAST> {
const pruned: Record<string, NodeAST> = {};
const queue = […activeNodeIds];
const visited = new Set<string>();
while (queue.length > 0) {
const currentId = queue.shift()!;
if (visited.has(currentId)) continue;
visited.add(currentId);
const node = fullAst.get(currentId);
if (node) {
// 裁剪掉巨量的数据矩阵，只留位置与基础类型
const { properties, …rest } = node;
const sanitizedProperties = { …properties };
delete sanitizedProperties.binaryBuffer; // 移除大型二进制缓存
delete sanitizedProperties.renderCache; // 移除渲染中间态
pruned[currentId] = {
…rest,
properties: sanitizedProperties
};
// 仅向上追踪两层父节点
if (node.children) {
queue.push(…node.children.slice(0, 5)); // 截断列表
}
}
}
return pruned;
}
/**
* 计算 Token 消耗并安全截断历史对话
*/
public packMessages(systemPrompt: string, prunedAst: Record<string, NodeAST>, history: Array<{ role: string; content: string }>) {
const systemTokens = this.encoder.encode(systemPrompt).length;
const astTokens = this.encoder.encode(JSON.stringify(prunedAst)).length;
const availableForHistory = this.config.maxTokenBudget – systemTokens – astTokens – this.config.toolSchemaReserve;
if (availableForHistory < 500) {
throw new Error(`Context budget exceeded before adding conversation history. AST Tokens: ${astTokens}`);
}
const packedHistory: Array<{ role: string; content: string }> = [];
let accumulatedTokens = 0;
// 从最新的对话开始逆向拼装
for (let i = history.length – 1; i >= 0; i–) {
const msg = history[i];
const msgTokens = this.encoder.encode(msg.content).length;
if (accumulatedTokens + msgTokens > availableForHistory) {
break; // 触发预算临界点，停止装载旧历史
}
accumulatedTokens += msgTokens;
packedHistory.unshift(msg);
}
return {
systemPrompt,
astContext: prunedAst,
messages: packedHistory,
metrics: {
systemTokens,
astTokens,
historyTokens: accumulatedTokens,
totalTokens: systemTokens + astTokens + accumulatedTokens
}
};
}
public destroy() {
this.encoder.free();
}
}
边界划分的三条铁律
在实践中区分“用 Prompt 解决”还是“写工具解决”，遵循三条判别规则：
拿着这套机制上线后，最直观的收益是 API 请求由于 Prompt 体积大幅收缩，首字响应时间（TTFTＩ短到了 850 毫秒。模型也不再乱报 JSON 格式错误。
防线检查清单
在发布创意工具升级前，把这几个工程指标核对一遍：
- 单次 API 请求中的 System Prompt 是否控制在 2000 Token 以内。
- 画布全量数据树是否已脱离上下文，改由 ID 粒度的增量截取器提交。
- 所有 Tool Calling 的返回结果是否挂载了强类型的 Schema Validator（如 Zod / JSON Schema）。
- 遇到 Token 超限告警时，系统是否具备自动截断旧历史并降级调用的机制。
