--- title: "Code is cheap. Don't write any.——AI Native，程序员如何提升五倍 coding 效率" source_url: "https://mp.weixin.qq.com/s/t04ysxZN2qEc3986r2gyTA" ingested: 2026-07-03 sha256: 3ecd0d255f300bb485efb699ae51655a6b824f5d231f5bc29758885e4be6be19 author: 无岳 publisher: 阿里云开发者 --- 最近 20 天，AI 帮我提交了 70 万行代码，10 个项目，同时并行。 不是 IDE 补全那种"AI 占 100%"。是把一个完整任务整包交出去——读地形、定方案、写实现、跑验证、修 bug——AI 自己全套跑完，我只在关键节点拽一下方向。 一、Code is cheap 当同样的变化进入复杂工程现场，会怎样改变一个工程师的产能结构？典型的研发场景：产品线多、内部平台复杂、存量系统长、权限和发布链路严格。过去真正昂贵的不是敲代码，而是读懂历史、找准边界、确认影响面、跑通验证、控制发布风险。现在一旦模型可以整包接住"读地形、定方案、写实现、跑验证、修 bug"这一串动作，代码本身就开始从稀缺资源，变成可以快速生成、快速验证、快速丢弃的过程产物。 真正要警觉的不是"AI 越来越强"——这件事大家都已经接受了。而是另一件事：代码本身，正在变得非常便宜。 二、泥头车与长尾 代码廉价化的第一个副作用，是长尾的极端拉伸。差距不是"会用 AI"和"不会用 AI"——这一拨差距其实已经不大，差不多人人都用过。真正在拉开的是用 AI 的层级差距。 头部的人（包括我自己）已经能用 AI 同时推进 5 个项目，把任务整包交给模型自动跑；尾部的人，还停留在用 LLM 写写单测、补几个注释的阶段。这不是技术能力的差距，是对 AI 的使用方式的差距——而这个差距，正在以周为单位放大。 放大它的不是 AI 自己。AI 不在乎任何人。它只是残忍地学习、代替、撞死所有跟不上它的人。这没有感情成分——它就是一辆不停加速的泥头车。 摆在每个人面前的只有两条路。第一条，在它撞到你之前多跑两步。第二条，爬上这辆车，无论姿势多狼狈——迅速把自己转型成 100% AI 工作者。 这篇文章讲的是第二条——爬上车的方法。这套方法叫 Harness。 三、大模型的两个底层事实 事实 1：大模型不是确定性函数。 大模型每说一句话、每写一行代码，本质都是"一个 token 接一个 token 往外吐"。每吐一个 token 之前，模型基于前面已经吐出的所有内容，对词表里所有可能的下一个 token（通常几万到十几万个）算一个概率分布。 这种机制有两个直接的结果。第一，模型每一步的输出不是"想清楚再说"，而是"按概率挑一个"。第二，每一步的小偏差会沿着链路累积——一旦某一步挑歪了一点，后面所有 token 都基于这个偏差继续挑下去，越走越远。 推论很直接：给它的自由空间越大，它跑偏的概率越大。 具体翻车的样子：你把一个相对模糊的目标交给它，它可能洋洋洒洒生成 500 行代码但方向完全不对；它修了一个 bug，顺手"优化"了你不想动的部分；你不知道它为什么这么写，不敢上线。 这也是 best-practice slop 的来源。不是简单的"AI 写得烂"，而是 AI 在一个过大的目标空间里，把网上最常见、最像最佳实践的套路糊上来，生成一套看似专业、结构漂亮，但不贴业务地形、不解决真实问题的平均产物。 工程对策是反 slop：任务开始前反复和模型讨论需求，让它复述目标；理解错了，人立刻纠正；证据不足，就继续搜索代码、日志、历史 spec；几轮之后，把目标、边界、证据、判断标准沉淀成一份精华文档（spec）。这一轮可能不写一行代码，但它已经把模型从"凭概率在巨大空间里乱选路"，挪到了"在清晰目标和边界内自主推进"。 事实 2：大模型的上下文窗口是有限的，而且给得太多反而会腐烂。 这是 transformer 注意力机制的内在限制。模型每生成一个 token，都要在上下文窗口里所有 token 之间分配注意力——窗口越长，每个 token 拿到的注意力权重越稀薄。"Lost in the Middle"——中间的信息最容易被遗忘。 多轮对话更糟：旧方案和新方案在窗口里共存，模型分不清"哪个是当前结论"；recency bias 让它过度看重最近几轮的内容。 自动总结只能延缓上下文腐烂，不能解决它。每次总结都是有损压缩。真正的解是定期重启（new-chat skill），用 spec 作为外部真相源喂给一个全新的 chat。 真正要节约的不是 token，是上下文——省 token 是成本问题，省上下文是质量问题。 四、方法论：水流理论 + 最小混沌单元 Harness 是一个 generic 概念——任何在 LLM 上做 delegation 的方法都能叫 Harness。 五、Harness 的 8 个关键组件 （文章中详细展开了 spec 编写、context 管理、checkpoint 设计、验证闭环、边界控制、错误恢复、new-chat skill 等具体技术） 六、实战经验 （阿里云内部落地的具体案例和量化数据） 七、new-chat skill 定期重启模式：用 spec 作为外部真相源，启动全新的 chat，避免上下文腐烂积累。 注：本文原文为长篇深度文章，以上为基于浏览器可访问内容提取的核心框架。完整内容请参阅原文。原文链接：https://mp.weixin.qq.com/s/t04ysxZN2qEc3986r2gyTA