LLM上下文与代码长度限制 | AI生成和翻译

Home 2026.05

问题： 既然 LLM 现在能处理 400k–1M token 的上下文，我们是否还需要将脚本控制在 200–300 行？一个自包含的 Python 脚本写到 800–1k 行是否可行，以及何时应该解耦？

回答：

对于自包含的 CLI 工具，800–1k 行完全没问题。过去所谓的“200 行限制”是基于人类可读性和维护性提出的启发式规则——它诞生于 LLM 辅助开发之前，那时你的整个代码库根本无法塞进上下文。

新的思维模型

真正的约束不是行数，而是认知单元：

旧世界：人类工作记忆能承载约 200 行
新世界：LLM 能承载约 800k token = 你的整个仓库

因此问题从“代码多短”转变为“什么是正确的封装单元”。

何时一个文件 800–1k 行是正确的

对于像 ww 这样的 CLI agent，单文件更优的情况包括：

你的 ww 仓库正是这种模式。一个 900 行的 ww.py，在同一个地方完成 LLM 编排、工具分发和 CLI 解析，比拆分为 cli.py、tools.py、agent.py、utils.py 更容易处理——因为解耦会通过 import、共享状态和接口契约产生隐性耦合，你需要额外记住这些关系。

何时真正需要解耦（实际触发条件）

只有当你遇到以下具体门槛时才进行拆分：

触发条件 操作
2 个以上脚本共享同一逻辑 提取到 lib/ 模块
不同的部署单元 分开为不同文件（例如 server.py 和 client.py）
不同的测试周期 将可测试核心与 CLI 胶水代码分离
文件超过约 1500 行 很可能包含两个不同的职责——找到分割点
两人同时编辑 Git 冲突压力 = 自然的拆分信号

针对你这类 ww 风格工具的实用规则

1 个工具 = 1 个文件，最多约 1200 行
跨工具的共享工具函数 = lib/common.py

ww/
  ww.py          # 900 行，自包含 agent
  zz.py          # 700 行，自包含
  iclaw.py       # 800 行
  lib/
    anthropic.py # 如果 3 个以上工具使用，共享 API 封装
    config.py    # 共享配置/环境加载

lib/ 的存在只在顶层脚本之间的重复真正发生且令人痛苦时才成立——而不是预先预防性地创建。

“自包含最佳”原则依然成立

保持脚本自包含的最有力理由是LLM 参与的编辑。当你把 ww.py 粘贴到 Claude 中，要求“添加流式支持”或“添加新的工具调用”时，所有内容都在一个文件中意味着：

这就是 Karpathy 的 train_gpt2.py 学派——一个 1000 行的文件，让有能力的开发者（或 LLM）能够从头到尾阅读并完全理解。这是优点，而非技术债务。

结论

Back Donate