感受 ⛵与 AI 智能体协作编程可以说像是在航海一起驶向计划的目的港。我虽是那个舵手但能放手让 AI 来掌舵了。不过难免偏航不时需要人来纠正一下航向。我并没有甩手全权交给 AI想来是几个方面吧一是 AI 确实会偏航二是我懂编程有能力驾驭三是凭感觉、不那么激进。无论如何个人用 AI 编程一直感受挺好。到目前的变化就是更放得开手让 AI 做更多事情。也印证着或者说我在跟随着AI 日复一日的进步。变化 目前与 AI 协作编程最大的变化是我更多做引导决策而不是给明确指令。例如只给目标方向让 AI 设计、计划、执行、测试、审查、优化。换一句话说就是让 AI 参与了整个开发流程包括写文档。但想了一想之前难道不是么其实一直都是因为编程本就是这样。只是 AI 智能体把工作流整合了更符合编程习惯让 AI 参与更深度了。其实我这里少了几环需求分析、系统设计、技术选型等。前期这些一开始就先做了到 AI 这里主要是开发工作。环境 ️在聊心得之前先说一下环境。最近一直用的 Claude Code CLI。模型呢上月都是 DeepSeek V4 Pro这月则是 MiMo V2.5 Pro。之前用过 Claude Opus 4.7, Zhipu GLM 5.1。工作流则是用的各 Skill 手动指挥的而非直接端到端的实现。上次分享过。心得 心得分两方面先是 AI 编程通用的再是 CC 工具有关的。AI 编程1AI 编程还是编程曾经哪听说过“未来每一个人都要会编程”AI 让这变成了可能。编程往小了说也只是一种用工具的能力与会用 Excel 是一样的。以前用笔画表现在用 Excel 画更简单了。现在用 Excel 做的以后 AI 来做了。Excel 不够AI 自己编程创造去做。但编程往大了说它仍是软件工程。AI 编程也一样只有按工程办法来才能做好一个系统。也就是懂得软件工程、系统架构、研发流程的才能保证更高的下限。无论懂不懂编程如下几件事一定要沉淀下来文档使用说明编译、运行、测试、部署架构设计层次关系、边界约束接口设计接口协议、模块设计流程Git 规范: 修改提交必建分支防丢等提交前约束: 让 AI 审查、自测过 CI 等测试多级测试单元、集成、系统关键在于来一个新人或 AI 能自己上手、规范提交。2AI 智能体有何用AI 编程现在都是用 AI 智能体来编程也就是 AI Agent Coding。能刷到这一篇文章的想必都了解。简单说AI Agent 让大模型长出了手脚自己用编程工具。AI Agent 是围绕模型形成的一套工作流也自成一套小生态。那重点来了围绕模型谁的模型也就是说有适配性。Claude Code简称 CC当然与它自家的 Claude 模型最适配了。进一步说这也是为何各大模型厂商一定要出自己 AI Agent 的原因之一。也是我会切换用原厂 AI Agent 的理由之一。3AI 模型有何差异AI 模型是有差异。但 AI 编程使用差异不一定是模型带来的。先说模型自身的编程能力以我的经验即使相比以前 AI 聊天来编程产出质量差异并不大。但不可否认模型编程能力是有差异、在进步。只是对不懂编程、直提需求的人来说差异感受才会大得多。至于 AI 编程上的差异感受主要来源于两点一是刚提到的与 AI Agent 的适配性二是有没有依照软件工程的工作流。另外AI 模型的调用延时也当关注。这影响效率、甚至工作形态。4AI 编程为何偏航首先与人对需求理解有差异一样AI 对提示理解也不一定准确。所以对于复杂一点的提示要与 AI 讨论、扩散思路、澄清想法。这就是 /idea /grill-me /office-hours 这类技能的用途。如果有你不确定的只管问 AI 原因最后决策并沉淀进文档。如果发现 AI 误入歧途最好即时中止澄清后再继续。这也建议优先计划再执行。这也是 /spec /plan 等技能的用途。总不能每时每刻都盯着 AI 输出吧所以要计划清楚。其次AI 目前还是有上下文瓶颈遗忘约束或注意力不在。例如即使一些规则落盘进了 CLAUDE.md但 CC 长对话后还是忘了。此时要么让 AI 重读或阶段性重开。也是之前为何强调一定要沉淀文档、流程、测试。至于这个问题如何从根本上解决我认为即使无限上下文长度也并不能解决。因为注意力是有限的无论人和 AI 都一样。什么意思说到底给 AI 模型的仍是一段提示其中一部分是约定的基本约束但太长了给分配的注意力不还是少了么。就像我读一篇长科幻一开始有个基础约定读到最后就不记得了。除非这个约定是贯穿始终的。所以想法是要么 AI 模型对基础约束可固定注意力无论是分层次、还是加权重。这得等 AI 升级了。或者工程上简单一点基础约束在长文本里固定间隔插入多重申几次。最后则是编程本身就是要把控的不然“屎山”哪来的这与 AI 无关两个原因编程习惯与责任心、业务变更与紧急度。当然永远是冲突的、没时间的。其实第一要看的是重要性有些“屎山”在那也无所谓啦。反而有了 AI更有时间让代码保持健康度、提高质量下限。一是人工审核不对味的提示 AI 改。反正快。AI 也是一样不断堆砌代码。即使加了 Karpathy Skill 底层规则发现长对话后仍一样估计注意力不在了。例如函数参数越加越多得人工提示一句把参数封装一下。类或单文件里功能越来越多得人工提示怎么拆分组合一下。此外修改浮于表面不是本质、或不优美得人工审问或调试来补充信息。总之要人工剔除一下坏味道。二是AI 改动较多的一定让它自己审查一遍。挺周全。AI Agent 多角色其审查还挺专业各方向都照顾到了。也就是记得用 /review /simplify 等技能。三是一定阶段之后人工审查架构、整理重构。仍不足。只看 AI 的每次改动有些坏味道是发现不了的或者当时改动影响大先缓一缓的。所以一定阶段后一定要人工看看。或者等 AI 执行时浏览代码。也就是不定期微重构。一般涉及通用类型、常量魔法数封装抽象、特例模块化框架拆分组合、用设计模式CC 工具AI 编程、技能、工作流等都聊过了。CC 工具里也是一样的。它自身有关的心得反而没多少了。1阶段性重开会话CC 本身 context 到一定程度会自动 compact可以在配置里修改或手动执行 /compact。此外可以完成一个阶段后重开会话读取上手文档重新开始下一阶段任务。2选择性并行开发CC 本身会话时就能多开 Agent 来并行任务。此外可以用 worktree 来并行开发。但建议另开终端而不是对话建 worktree也不建议重命名。因为遇过问题。另外并行高强度使用会发现文本输入太慢所以如 TML 语音对话会是下一次交互革新吧。不过这也挺费脑的注意劳逸结合。3按需求选用模型