从 GitHub Copilot 到现在的 Claude Code、Codex，这几年能碰到的编程工具，我基本都用过一遍。
模型也换得勤。Claude、Gemini、GPT，国产模型出来一个试一个。GLM-5.2 之前，我确实觉得国产模型在真实开发里不太能用。不是完全写不出代码，而是任务稍微长一点，约束稍微多一点，就容易跑偏。你得花很多精力把它拉回来，最后省下来的时间还不够收拾现场。
但 GLM-5.2 出来以后，我的体感开始变了。
现在日常工作里，我还是用 Claude Code CLI 和 Codex，底下的模型则是 GPT-5.x、GLM-5.2、Qwen3.8 混着来。单看常规开发任务的最终产出，对我来说差距已经没有想象中那么大了。头脑风暴、陌生问题探索，我还是更愿意多用 GPT；赶时间的时候也会考虑响应速度，GLM 目前在这一点上还吃亏。但如果需求已经比较清楚，只是要把它稳稳地落成代码，几种模型经常都能交出可用的结果。
这和我在一些讨论里听到的结论不太一样。有人觉得 Claude 明显高一个档，有人认为国产模型依然没法进入工作流，还有人换了一个模型以后，仿佛开发效率立刻翻倍。
我不打算争哪个结论才对。因为用得久了以后，我反而意识到：模型差距在我这里变小，未必说明模型真的一样，更可能是我的工作方式把一部分差距吃掉了。
这件事，我把它叫作“尽职编程”。
产出接近，可能不是模型真的一样
我在这个行业摸爬滚打了很多年。一个需求过来，即使细节还不完整，我通常也知道最终想得到什么，大概会改到哪些地方，哪些边界不能碰，什么样的结果一眼看上去就不对。
这些判断以前藏在写代码的过程里。
我会一边敲代码，一边修正自己的理解。命名不对就改，结构别扭就拆，发现需求和现有实现冲突，再回头补上下文。很多经验并不会特意写出来，因为脑子和手是连着的，纠偏发生得很自然。
换成 Agent 以后，这条隐形的纠偏链断了。它看不见我脑子里的预期，只能根据我给出的任务、仓库里的上下文和执行过程中的反馈作判断。
所以同一个模型，在不同人手里，表现可能差得非常远。
如果只丢下一句“帮我把这个功能做了”，模型要同时猜目标、范围、现有约束和验收标准。猜对了，会觉得模型聪明；猜错了，又会觉得模型不行。可这里面有多少问题真的来自模型，有多少只是我们没有把工作交代清楚，其实很难分开。
我现在给 Agent 任务，通常会把自己已经确认的东西尽量说清楚：为什么要改，现状是什么，期望结果是什么，哪些地方不要动，以及做到什么程度才算结束。如果任务里还有空白，就先让它查，再针对关键分歧澄清。
这并不是什么高深的提示词技巧，更像带一个刚接触项目、但学习和执行速度都很快的同事。你不需要教它每一行代码怎么写，但要把任务背景、边界和责任说清楚。
当这些信息齐了，模型之间在常规任务上的差距自然会收窄。因为它们不再花大量能力猜题，而是在一条相对明确的轨道上执行。
所谓尽职，先从把问题说清开始
“尽职编程”要求人对 Agent 的产出负责，至于代码由谁敲、流程要走多重，则取决于任务风险。
它说的是另一件事：代码可以由 Agent 生成，但意图、授权、验收和后果，仍然要由人负责。
这份责任首先体现在任务开始之前。
我至少要知道这次到底在解决什么问题。如果连我自己都没想明白，就不能指望模型替我做出唯一正确的判断。它当然可以参与探索，甚至提供比我更多的候选方案，但“选哪条路”仍需要结合业务、成本和现有系统作决定。
有些事情，我会在任务里直接写出来：
-
这次改动服务于谁，真正要消除的麻烦是什么；
-
允许修改的范围在哪里，有没有兼容性或发布约束；
-
哪些既有约定必须遵守，哪些历史包袱暂时不要碰；
-
需要留下什么产物，代码、测试、文档还是迁移脚本；
-
我准备用什么证据判断它已经完成。
这几个问题看着朴素，却比“使用某种神奇提示词结构”更影响结果。
去年我在整理团队 Plugin 时，关心的是怎么把项目约束、Skills 和工具环境交给 Agent；后来做 Skill Graph，又开始处理任务之间的依赖、门禁和验证；再往后做会话检索与评估，关心的则是结论从哪里来，执行过程能不能回看。
回头看，这些工作其实都在补同一块东西：把过去只存在于资深开发者脑子里的判断，逐渐变成 Agent 能读到、流程能执行、结果能检查的外部结构。
模型能力当然重要，但如果外部结构一片空白，再强的模型也只能临场发挥。
别把 Agent 的稳定全压给模型
我以前也很容易把一次失败归因到模型。
它忘了前面的要求，是上下文能力不行；它改漏了文件，是推理能力不行；它说已经完成但测试没跑，是 Agent 能力不行。换一个更强的模型，很多问题确实会缓解，于是这个判断听起来也很合理。
但重复做了几轮以后会发现，有些失败根本不该靠模型临场兜底。
项目约定如果每次都靠对话重新讲，早晚会漏；固定操作如果只写在自然语言里，执行结果就容易漂；有先后依赖的任务如果没有门禁，Agent 很可能在前置条件没满足时继续往下跑；长会话里混进太多无关信息，再好的模型也会受到干扰。
这些问题更适合交给工程机制：
-
用
AGENTS.md、CLAUDE.md一类项目说明保存长期约束； -
把重复工作沉淀成 Skill，让输入、步骤和产物相对稳定；
-
用 Graph 表达依赖和 gate，不让“差不多完成”自动流向下一步；
-
复杂任务拆开执行，让新的工作节点拿到干净、足量的上下文；
-
按风险选择流程，改一句文案和改数据库结构不必走同样的检查强度。
这也是为什么，我现在对“哪个模型最好”越来越难给出一句话答案。
一个模型在裸对话里表现更强，不代表它放进具体项目后一定交付得更好。模型、Agent 运行时、上下文组织、工具权限和验证流程是连在一起的。日常产出是这套系统共同作用的结果，只盯着模型，容易把其他环节的问题都藏起来。
回复得漂亮，不代表活干完了
Agent 最容易制造的一种错觉，是它把话说完了，我们就以为事情也做完了。
比如它告诉你：代码已经修改，测试已经补充，文档已经更新。文字完整、条理清晰，看起来让人很放心。但这只是一段回复，不是交付证据。
我在前面的实践里，越来越习惯把三件事分开看：
- 回复：Agent 说自己做了什么；
- 副作用：文件、数据库、配置或外部系统是否真的发生变化；
- 产物：代码、测试报告、构建包、截图或文档是否存在，而且质量合格。
这三件事经常不是同步发生的。
文件可能改了，但没有改到正确的位置；测试命令可能执行了，但失败被淹没在长日志里；页面可能能打开，却没有覆盖权限、空状态或真实数据规模；文档可能生成了，只是把对话内容换了一种格式落盘。
所以验收不能只看 Agent 的总结。我会根据风险去看 diff、跑测试、读构建日志，必要时把服务启动起来验证真实行为。低风险任务可以抽查，高风险改动则要把证据留全。
这里的关键不是“不信任 AI”，而是软件交付本来就不该依靠口头保证。以前同事提 PR，我们也不会因为描述写得完整就直接上线。换成 Agent，道理并没有改变。
模型该怎么选，反而简单了
接受这个前提以后，模型选择反而没有那么纠结。
需要头脑风暴、面对陌生领域、问题本身还没有收敛时，我会优先用更擅长探索的模型。任务边界清楚、项目约束完整、验证手段明确时，就可以综合速度、成本、可用性来选。某个模型当天状态不好，或者在特定工具链里不稳定，直接换掉也没什么心理负担。
我不会因为日常产出接近，就说 GPT、GLM、Qwen 没有能力差异。复杂推理、工具调用的稳定性、长任务中的自我纠偏，以及响应速度，都会放大差距。我这里的感受也不是严谨的模型评测，只来自我自己的项目、任务类型和工作习惯。
但这段经历至少让我不再把模型品牌当成结果的唯一解释。
很多常规开发任务里，模型已经跨过了“能不能做”的门槛。接下来更实际的问题是：我有没有把任务定义清楚，项目有没有提供足够上下文，Agent 能不能稳定执行，结果有没有经过与风险相匹配的验证。
如果这些环节都没有做好，只换模型，往往只是换一种方式碰运气。
尽职编程，尽的到底是谁的职
Agent 写的代码越来越多以后，人很容易退到任务入口，只负责说一句“帮我做完”。执行过程看不见，完成与否听汇报，出了问题再去翻会话记录。
这种工作方式很轻松，也很危险。
因为最终需要面对用户、同事和生产环境的，不是模型。允许它访问哪些资源、接受哪种实现、哪些风险可以承担，都是人在做决定。即使代码不是我敲的，只要是我授权它进入项目，并由我确认交付，这份责任就没有转移。
所谓尽职，更接近一种工程上的克制：不知道的地方先确认，重要约束写下来，能自动验证的交给工具，关键结果留下证据，高风险决定不假装已经被模型替我做完。没有必要守着 Agent 的每一步操作，也无需用人工劳动证明自己的价值。
过去我总觉得，模型更强以后，人要做的事应该越来越少。现在看，减少的主要是具体操作，责任本身并没有减少。甚至因为执行速度变快、一次能改动的范围变大，人更需要知道自己放出去的任务会产生什么后果。
模型还会继续换，今天觉得好用的组合，过几个月大概又不一样。真正能留下来的，是把意图说清楚的能力，是为 Agent 搭出稳定执行环境的能力，也是面对最终结果时愿意检查并负责的习惯。
键盘可以交出去，责任不能一起交出去。
这大概就是我理解的尽职编程。