1. 为什么“编程尚未被解决”是个值得认真对待的判断先把话说在前面这句话不是标题党也不是唱衰 AI 编程工具。恰恰相反我日常写代码已经离不开 Claude Code、Codex 这类工具DeepSeek 的 harness 方案我也在项目里跑过一段时间。但用得越深我越认同一个判断——编程这件事本质上还没有被解决LLM 只是把写代码这一段加速了而编程作为一个完整工程活动仍然是一堆没被解决的硬骨头。这个判断需要拆开来看。很多人把编程等同于敲代码于是看到模型能一口气生成两百行 Python就觉得问题解决了。但真实的编程活动至少包含这几层需求理解与澄清、方案设计与权衡、代码实现、调试与验证、集成与部署、长期维护与演进。LLM 目前最擅长的是第三层对第一层和第六层几乎无能为力对第二层和第四层只能算辅助。这就是尚未被解决的核心含义。我写这篇东西是想把最近折腾 LLM 编程工具链尤其是 Claude Code、Codex、DeepSeek harness 这几套的经验系统梳理一遍。适合谁看如果你是把 AI 当代码补全器用的开发者这篇能帮你把工具用到更深的层次如果你是团队里负责引入 AI 编程流程的人这篇能帮你避开我踩过的坑如果你只是好奇AI 到底能不能替代程序员这篇会给你一个不那么情绪化的答案。关键词先摆出来编程、LLM、AI、Claude Code、harness。这五个词基本构成了当前 AI 编程的主战场。下面我会从整体思路、核心细节、实操过程、问题排查四个维度展开尽量把每个为什么讲透。2. 整体设计思路LLM 编程工具链到底在解决什么2.1 从补全到代理工具形态的三次跃迁要理解现在的工具格局得先看清它是怎么一步步演化过来的。我把它分成三个阶段每个阶段解决的核心矛盾不一样。第一阶段是行级补全。代表就是早期的 Copilot 类工具你在编辑器里敲一半它补另一半。这个阶段解决的是打字速度问题本质是个高级的自动补全。它的局限很明显模型只看得到当前文件和少量上下文对项目结构一无所知生成的代码经常局部正确、全局错误。第二阶段是对话式生成。你把需求贴进聊天框模型给你一段完整代码你再手动粘回去。这个阶段解决的是从零写一段逻辑的问题但代价是上下文要手动搬运来回切换成本很高而且模型看不到你的真实文件容易生成幻觉 API。第三阶段就是现在说的 agent / harness 形态。Claude Code、Codex 这类工具的核心变化是模型不再只是生成文本而是能主动读取文件、执行命令、观察结果、再决定下一步。这就从生成器变成了代理。而 harness 这个词指的正是承载这套代理行为的工程框架——它负责把模型的输出翻译成真实的工具调用把执行结果再喂回模型形成一个闭环。提示很多人把 harness 和 agent 混着用其实有区别。agent 偏智能体这个概念强调自主决策harness 偏工程骨架强调怎么把模型、工具、上下文、权限、日志这些东西组装起来。你部署一套能跑的系统写的主要是 harness不是 agent。2.2 为什么 harness 是当前的关键战场我一开始也以为模型能力才是决定性的harness 只是胶水。用久了才发现完全反了同一个模型换一套 harness实际编程能力能差出一个数量级。原因在于LLM 本身是无状态的、只会输出 token 的函数。它要完成改一个 bug这种任务需要 harness 帮它做几件事把相关文件内容塞进上下文、把它的意图解析成具体的文件编辑或命令执行、把执行结果包括报错回传、在它跑偏时把它拉回来、在它要执行危险操作时拦住它。这些环节任何一个做不好模型再强也白搭。举个我自己的例子。同样让模型修一个 Python 的KeyError早期我手动把报错和文件贴给它它经常改错地方因为它看不到调用链。后来用 Claude Code它能自己 grep 出调用点、读相关文件、改完再跑测试一次成功率明显高很多。模型没变变的是 harness 给它的手脚和眼睛。2.3 方案选型的几个现实考量现在市面上的选择大致分三类我列个表对比一下方便你对号入座。方案类型代表优势代价适合场景云端一体化 agentClaude Code、Codex开箱即用工具链完整数据出本地按量付费个人开发、非敏感项目本地 harness 框架DeepSeek harness 等可内网部署数据可控需要自己搭环境、调参企业内网、敏感代码库编辑器插件VS Code 里的各类插件集成度高学习成本低能力受插件实现限制轻量辅助、日常补全选型的核心不是哪个最强而是你的约束是什么。如果代码不能出本地那云端方案直接排除只能走本地 harness。如果只是个人项目图省事云端一体化 agent 的体验确实更顺。我自己的做法是公开项目用云端公司项目走本地 harness两套并行。3. 核心细节解析LLM 编程的四个关键环节3.1 上下文工程决定成败的隐形战场如果只能给一条建议我会说把上下文管理当成一门手艺来练。模型的表现八成取决于你喂给它的上下文质量。上下文工程要解决三个问题放什么、放多少、怎么放。放什么指的是相关性筛选。一个中型项目几万行代码不可能全塞进去。harness 通常的做法是先用检索grep、语义搜索定位相关文件再按需加载。这里有个坑纯语义搜索在代码场景下经常不如关键词搜索准因为变量名、函数名本身就是强信号。我实测下来混合检索关键词 语义比单一方式召回率高不少。放多少指的是窗口预算分配。模型的上下文窗口是有限的你得在系统提示、项目说明、相关代码、历史对话、当前任务之间分配。我的经验是给项目说明比如 CLAUDE.md 这类文件留固定额度因为它每次都要用相关代码按需动态加载历史对话要定期压缩否则越跑越慢还容易跑偏。怎么放指的是格式和顺序。把最重要的信息放在开头和结尾中间放次要的这是有实证支持的模型对首尾更敏感。代码块要带文件路径和行号方便模型引用和定位。报错信息要完整贴别自己截断模型往往能从你忽略的那行看出问题。3.2 工具调用让模型真正动手工具调用是 harness 的核心能力。模型输出一个结构化的调用请求harness 解析后执行再把结果回传。听起来简单实际坑很多。第一类是参数校验。模型生成的参数经常有细微错误比如路径少了斜杠、JSON 多了个逗号。harness 必须在执行前校验否则要么报错中断要么执行了错误操作。我见过最离谱的一次模型想删临时文件路径拼错差点删到源码目录幸好 harness 有白名单拦截。第二类是结果截断。命令输出可能非常长全塞回上下文会爆窗口。harness 需要智能截断保留头部和尾部中间用省略号。但截断策略要小心有时候关键报错就在中间。第三类是幂等与回滚。模型可能重复调用同一个工具或者执行到一半失败。harness 要能识别重复调用、支持操作回滚。文件编辑尤其要注意最好用读-改-写的原子操作而不是直接覆盖。注意工具调用的权限控制是安全底线。删除文件、执行 shell、访问网络这些高危操作一定要有确认机制或白名单。我建议至少做到写操作需确认、删操作需二次确认、网络访问默认关闭。3.3 验证闭环模型怎么知道自己对不对这是我认为当前 LLM 编程最没被解决的环节。人写代码靠的是运行、测试、观察、推理模型要形成闭环必须能拿到我改的东西到底对不对的信号。最可靠的信号是自动化测试。如果项目有完善的测试套件模型改完跑一遍红了就继续改绿了就算过。这套流程在 Claude Code 里体验很顺它能自己跑 pytest、看失败、定位、再改。但前提是——你得有测试。没有测试的项目模型只能靠看起来对来判断这就很危险。次一级的信号是静态检查。类型检查mypy、tsc、lintruff、eslint能抓出一大类错误而且速度快、信号明确。我习惯在 harness 里把 lint 和类型检查配成改完必跑能挡掉很多低级错误。最弱的是模型自评。让模型自己判断我改对了吗可靠性很低它经常自信满满地说改好了实际没改对。所以我的原则是能用外部信号就别用自评。3.4 多轮协作单模型不够用的时候复杂任务单靠一个模型跑容易陷入局部最优或者反复打转。这时候多 AI 协作就有价值了。常见模式有几种规划-执行分离一个模型负责拆解任务、制定计划另一个负责具体执行。规划模型不需要看太多代码细节执行模型不需要操心全局。生成-审查分离一个模型写代码另一个模型专门挑毛病。审查模型带着找茬的提示词往往能发现生成模型自己忽略的问题。并行探索同一个问题让多个模型各给一版方案再择优或融合。适合方案设计阶段。我实测下来生成-审查这套最实用成本增加不多但能显著降低看起来对其实错的概率。规划-执行分离在大型重构任务上效果好但需要 harness 支持任务状态的传递。4. 实操过程从零搭一套可用的 LLM 编程流程4.1 环境准备与工具安装先说云端方案以 Claude Code 为例。安装本身不复杂关键是配置要对。# 安装以 npm 方式为例 npm install -g anthropic-ai/claude-code # 验证安装 claude --version装完之后第一件事是在项目根目录建一个项目说明文件Claude Code 里叫 CLAUDE.md。这个文件是 harness 每次都会加载的项目宪法内容应该包括项目是干什么的、目录结构、技术栈、常用命令怎么跑测试、怎么 lint、怎么启动、编码规范、以及你希望模型遵守的约定。我踩过的坑是一开始这个文件写得太啰嗦把整个架构文档都塞进去了结果每次请求都消耗大量 token还挤占了真正相关代码的空间。后来精简到只留模型每次都需要知道的信息效果反而更好。VS Code 集成的话装对应插件后在设置里配置好路径和权限即可。Ubuntu 环境下要注意权限问题尤其是让 harness 执行 shell 命令时别用 root 跑容易出乱子。本地 harness 方案比如 DeepSeek harness的部署要复杂一些核心步骤是拉取框架代码、配置模型接口、配置工具集、设置权限白名单、跑通一个最小任务验证。内网部署的话还要把模型权重或接口地址配好确保不依赖外网。4.2 一个完整的实操案例修一个真实的 bug我拿一个真实场景走一遍你能看到每个环节是怎么串起来的。任务项目里有个数据处理脚本处理某些输入时报KeyError需要定位并修复。第一步让 harness 复现问题。我不直接说帮我修 bug而是给它一个可复现的命令python process.py --input test_data/broken.jsonharness 执行后拿到完整报错包括 traceback。这一步很关键没有复现就没有修复模型必须看到真实的失败。第二步让它定位。harness 根据 traceback 里的文件名和行号读取相关代码再用 grep 找调用链。这里能看到 harness 的价值它自己完成了读文件-搜索-关联这一串动作不需要我手动搬运。第三步让它提方案。我要求它先说明问题是什么、打算怎么改、为什么这么改再动手。这一步能挡掉很多直接改错地方的情况。模型给出的方案是broken.json里某个字段缺失代码没做默认值处理建议加.get()并给默认值。第四步执行修改。harness 用读-改-写的方式修改文件改完展示 diff 给我确认。我确认后它才落盘。第五步验证。重新跑复现命令这次通过了。再跑一遍完整测试套件确认没引入回归。第六步补充测试。我让它为这个边界情况加一个测试用例防止以后回归。它生成了测试跑通。整个流程走下来我实际动手的部分只有确认 diff和确认方案其余都是 harness 在跑。这就是 agent 形态和纯生成的区别。4.3 参数与配置的关键取舍配置 harness 时有几个参数值得单独说。温度temperature。写代码建议调低0 到 0.3 之间。温度高会让模型有创意但代码场景下创意往往是 bug。我实测 0.1 左右比较稳。最大迭代轮数。agent 会循环思考-行动-观察必须设上限否则可能无限打转。我一般设 15 到 25 轮复杂任务放宽到 40。超过上限就中断人工介入。上下文压缩阈值。当对话历史超过一定长度harness 要压缩。阈值设太低会丢信息太高会爆窗口。我的经验是设在窗口的 70% 左右触发压缩。工具超时。执行命令要设超时防止某个命令卡死。测试类命令给长一点比如 300 秒普通命令 30 秒足够。这些参数没有万能值得根据你的项目规模和任务类型调。建议先跑几个小任务摸清楚再固化到配置里。5. 常见问题与排查技巧实录5.1 模型自信地改错怎么办这是最高频的问题。模型说已修复实际没修好甚至引入了新问题。排查思路永远不要相信模型的自评只相信外部信号。改完必须跑测试、跑 lint、跑类型检查。如果项目没测试至少跑一遍能触发相关代码路径的命令。我的做法是在 harness 里强制改完必验证验证不通过就不允许它说完成。这个约束能挡掉大部分自信改错。5.2 上下文丢失导致失忆长任务跑到后面模型忘了前面说过的约定开始乱改。原因通常是上下文压缩把关键信息压没了或者相关文件被挤出窗口。解决办法把关键约定写进项目说明文件每次必加载把任务状态显式记录在一个文件里让模型定期读而不是全靠对话历史。5.3 工具调用反复失败模型一直调用同一个工具一直失败一直重试。这通常是参数格式问题或者环境问题。排查时先看 harness 日志里工具调用的原始参数往往能一眼看出问题比如路径写错、命令不存在。如果参数没问题就是环境问题手动跑一遍同样的命令验证。提示给 harness 加一个同一工具连续失败 N 次就中断的保护能避免浪费大量 token。5.4 常见问题速查表现象可能原因排查方向解决改完没生效改错文件/未落盘看 diff、看文件时间戳强制展示 diff 再确认反复改同一处陷入局部循环看迭代日志设迭代上限人工介入报错看不懂上下文缺关键信息检查是否截断了报错完整回传报错越跑越慢上下文膨胀看 token 消耗调低压缩阈值生成幻觉 API模型不知道真实接口检查是否喂了接口定义把相关模块签名喂进去5.5 几条踩坑换来的经验第一小步快跑胜过一步到位。让模型一次改一个文件、一个函数比让它一次重构整个模块成功率高得多。任务拆得越细验证越容易出错越早发现。第二给模型退出条件。明确告诉它什么情况下算完成比如测试全绿且 lint 无错。没有退出条件它会一直改下去。第三保留人工审查环节。再顺的流程最终合并前也要人看一眼。我见过模型把测试改成永远通过来骗过验证的这种必须靠人抓。第四日志要全。harness 的每一次工具调用、每一次模型输出都要留日志。出问题时日志是唯一的真相来源。6. 我对编程尚未被解决的最终理解折腾这一圈下来我的判断更清晰了LLM 把编程里写的部分解决得相当好但编程作为一个需要理解需求、设计方案、验证正确、长期维护的工程活动远没有被解决。harness 这类工程框架的价值恰恰在于它承认了这个现实——它不假装模型无所不能而是用工程手段把模型的强项放大、把弱项兜住。我个人的体会是把 AI 编程工具当成一个能力很强但需要严格管理的初级工程师来用心态就对了。你得给它清晰的任务、完整的上下文、可靠的验证、明确的边界。做到这些它能帮你省下大量时间做不到它就是个制造 bug 的机器。后续这个方向还能怎么扩展我最近在试的是把生成-审查做成固定流水线再叠加一层基于测试覆盖率的自动评估让整个流程的可靠性再上一个台阶。等跑稳了再单独写一篇。