8.0
热点
AI SCORE
编程提效2026-08-14 13:24
AI编程时代：系统设计比写代码更重要
dev.to · AI#AI编程#系统设计#Agent
Editor brief · 编辑速览
AI Agent每次任务都经历"读-想-写-验"的token消耗循环，代码结构直接影响成本、速度和正确性；工程师角色正从代码编写者转变为系统架构师。
How token economics make code structure a cost, speed, and correctness problem — not just a style one.
如果你是一名使用 AI 编程 Agent 的软件工程师，你的工作已经发生了根本性改变。你不再是那个写大多数代码改动的人。你是那个设计 Agent 运作系统的人——而你设计的系统好坏，有着可衡量的、不断累积的影响。
这不是关于"整洁代码是'最好有'"的抽象争论。Token 经济把代码结构变成了一个有真实数字支撑的 cost、速度和正确性问题。
在 AI Agent 出现之前，结构只是一种个人习惯。有些团队会强制执行，大多数团队则放任自流。代码怎么写都能跑。
现在，Agent 会持续地在你的代码库中写代码、改代码和推理。每次 Agent 接触你的仓库时，都会遵循同样的循环：
Read — 拉取文件、目录结构、依赖项、过往上下文。
Reason — 在规划变更时，将所有内容保留在 context window 中。
Write — 生成编辑或新代码，经常重新表述周围代码。
Verify — 重新阅读以检查变更，有时会跨越多个轮次。
这些步骤每一个都消耗 token。一次编码任务在完成前可能会多次循环这个过程。而每个 token 都有代价——不只是金钱，还有真实的 GPU 算力、延迟和准确率。
Token 是模型一次读取或写入的文本块——大约相当于 4 个英文字符。
但问题是：代码的 token 化效率比散文差。
符号、标点和缩进都会消耗 token，但它们本身几乎不携带语义含义。长标识符、样板代码和重复的 import 会快速膨胀 token 计数。calculateShippingCostForOrder 作为一个函数名，光是存在就消耗大约 8 个 token——还没做任何事。与此同时，fn 是一个 token，但无论对 Agent 还是对下一个阅读者，都没有传递任何有用信息。
冗长或重复的代码在读取和写入时 literally 更贵。不是比喻——是字面意义上的贵。
这是变得昂贵的地方。在一个 agentic 循环中，第 1 轮的大部分上下文会在第 2 轮、第 3 轮、第 4 轮被重新发送。上下文不是线性累加的——是复利式的。
同一个文件在每一轮都要被支付费用。如果那个文件有 2,400 行，而 Agent 只需要 90 行，那么每一轮的其余 2,310 行都要你来付账。
让我们把这个具体化。任务："修复结算定价中的四舍五入 bug。"
单体方式——一个 2,400 行的 orders.py：
# orders.py — 2,400 lines
def calculate_shipping(...): ...
def apply_discount(...): ...
def validate_inventory(...): ...
def send_email_receipt(...): ...
def log_analytics(...): ...
def checkout(cart, user):
total = round(cart.sum * 1.0725) # <- bug here
# … 40 more unrelated functions
Agent 为了安全地做一个一行修复，需要读取约 9,600 个 token，因为整个文件是一个单元。
模块化方式：
checkout/
├── cart.py (140 lines)
├── pricing.py (90 lines) ← bug lives here
└── checkout.py (110 lines)
# pricing.py
def apply_tax(subtotal):
return round(subtotal * 1.0725) # <- fix this
Bug 存在于一个 90 行的文件中。Agent 读取约 1,400 个 token。同样的修复，成本相差近 7 倍。
现代模型 API 提供 prompt caching：重复使用的上下文可以大约以新鲜读取 10% 的价格读回来。但 caching 只有在同一个上下文在轮次之间真正可复用时才能产生收益。
一个 90 行的 pricing.py 是稳定的、可缓存的。而那个每轮都被修改一半的 2,400 行上帝文件呢？它不断地使自己的缓存失效。结构决定了这个折扣你是否能够享受。
在模块化场景中，同样 5 轮会话在 pricing.py 上的花费大约便宜 3.5 倍——免费获得的，只需做到不每轮都重新向模型解释这个文件。
美元数字只是一个代理。自注意力——模型用来将每个 token 与所有其他 token 关联的机制——其成本增长比 token 计数增长得更快。
1x 上下文 → ~1x 算力
2x 上下文 → ~4x 算力
4x 上下文 → ~16x 算力
这不是线性的。上下文翻倍，算力翻四倍。这意味着更大的上下文在每一轮都会增加真实的延迟——还有真实的 GPU 小时数，总得有人为此买单。
对 18 个前沿模型的研究发现，随着输入长度增加，准确率会下降，而且往往在上下文窗口还没填满之前就开始了。这种模式在每个测试的模型中都是一致的：
开头的信息：~90% 准确率
中间的信息：~58% 准确率
结尾的信息：~87% 准确率
对于一个编码 Agent，这是继成本和算力之后的第三个杠杆。膨胀的文件不只是读取更贵——Agent 更容易 miss 或 misuse 埋藏在文件中间的那一个相关函数，准确率是可以衡量的。
任务："收紧邮箱验证规则。"同一个检查存在于 5 个文件中。
在整个代码库中 copy-paste：
# orders.py, billing.py, signup.py, support.py, admin.py — all contain:
return '@' in addr and '.' in addr
修复规则意味着找到并编辑 5 个地方——5 倍的 token，5 倍的遗漏概率。
通过单一模块共享：
# validators.py
def validate_email(addr):
return '@' in addr and '.' in addr
规则只修一次。每个调用点都正确了，无需触碰或重新读取。这不是什么新建议——DRY 作为一个原则已经存在几十年了。新的是：重复现在有了可衡量的每次调用成本——每当 Agent 穿越你的代码库时。
这部分的结论应该让你感到不适：AI 生成的代码建立在已有代码之上。Agent 所做的每一个修改，都成为下一个修改读取时的上下文。结构在两个方向上都是自我强化的。
良性循环：整洁、模块化的代码 → Agent 只需读取相关部分 → 小范围、边界清晰的修改，符合现有模式 → 下一个任务的起点更便宜。代码库持续产生红利。
恶性循环：纠缠蔓延的代码 → Agent 为了安全起见拉取远多于必要的内容 → 强行附加的修改让模式变得更乱 → 下一个任务比上一个更贵、更容易出错。
任务："从新的退款流程中调用这个。"Agent 能信任函数签名吗，还是必须读取完整函数体？
def do_stuff(a, b, c=None):
# ~40 lines of logic
# no types, no docstring
...
Agent 必须打开并读取完整函数体才能知道这个函数做什么。仅为了信任一次调用，就要多花约 150 个 token。
def apply_discount(
cart_total: float,
discount_pct: float,
*,
cap: float | None = None,
) -> float:
"""Applies a capped percentage discount."""
签名加上 docstring 通常就够了。函数体无需读取。
合理的反驳。现代编码 Agent 越来越多地使用 repo map、基于嵌入的搜索和代码库索引来只获取看起来相关的内容——而不是每次都盲目地读取整个文件。
但检索质量也取决于结构。清晰的边界和命名让检索系统容易识别什么是相关的。纠缠不清、边界模糊的代码会让自动化检索困惑，就像让一个快速浏览的人困惑一样。
更好的工具提升了每个人的底线。但它在已经结构良好的代码库上表现最好。这些工具缩小了差距，但没有消除它。
如果混乱的代码库让每个未来的 Agent 任务都更贵，解决方案不是停止在上面使用 AI。而是用 AI 来对付那些混乱本身。
边做边重构。当一个功能接触到混乱代码时，在扩展之前清理所触及的区域。不要强行附加。
把重构作为明确的预算项。把结构清理作为 Agent 使用中的正常 line item，而不是"某天再说"的项目。
让 Agent 提出边界。在功能之前先请求模块化方案，然后按方案实现。
这些不是什么新原则。新的是：每一项现在都对每次 Agent 交互产生了可衡量的影响：
模块化边界——清晰的边界限制了 Agent 为了安全修改一个东西而必须读取的内容。
强命名和接口——自描述的代码减少推理正确性所需的周围上下文。
Docs 和 README 作为上下文——为人类编写，但现在也是让 Agent 快速定位的最便宜方式。
测试作为护栏——让 Agent 依据测试验证自己，而不是重新读取整个周围系统。
不要上帝文件——一个 5,000 行的文件强制全读或全不读；小文件让 Agent 可以精确地限定范围。
显式依赖——隐藏的耦合在导致问题之前对 Agent 是不可见的。让它可见。
"架构师"在这里不是比喻。你最高杠杆的工作是设计一个系统，让下一个接触它的 Agent（无论人类还是其他）都能保持便宜、快速和正确。
每一次读取和写入都要计费，用的是美元和真实算力。结构是有复利效应的：整洁的代码让下一个任务保持便宜，混乱的代码让每个未来任务都更贵。而那些能够撬动的选择，不是宏大的架构重写——而是微小的、可衡量的决策。一次文件拆分。一个清晰的签名。一次共享模块代替 copy-paste。
这些都是你可以在发布前用 token 估算的事情。这就是新游戏规则。