AI coding从辅助编程走向全流程接管1. 前言从三月份接触LLM和AI Coding Agent工具以来我的开发工作模式经历了一场静悄悄的变革。这场变革并非一夜之间的颠覆而是四个月里日复一日的微小调整逐渐累积而成的质变。最初只是出于好奇尝试OpenCode工具做Vibe Coding——在命令行上随手写几句功能描述让AI生成代码。那种意念编程的感觉确实新奇但很快我发现AI的能力边界完全取决于你给出的描述有多清晰。于是我开始尝试更系统化的方法把一个小功能的处理步骤完整写到usecase.md里再喂给AI Coding Agent。从随手描述到结构化文档这第一步看似微小却是我工作流转变的起点。随着实践的深入我开始把AI工具渗透到软件开发的每一个环节客户端测试工具用AI自动编写不再依赖测试人员的排期模拟服务器用AI自动搭建前后端联调不再互相等待多环境配置文件批量修改让Claude一次性搞定告别反复手动替换产品原型设计尝试用OpenDesign Claude取代Axure从静态线框图到可交互原型系统设计从PowerDesigner/StarUML的图形化操作转向Obsidian中Mermaid/PlantUML的Markdown描述运维系统Hermes Agent走进日常运维自动化脚本和运维流程全面接入PPT制作Obsidian采集资料 Claude分析资料自动生成演示文稿RD研发文档用Hermes/learn命令制作技能自动分析GitLab仓库中的代码和文档一键生成RD文件四个月的时间内我似乎没有改变什么——用的还是同一套代码仓库、同一台电脑、同样的IDE。但一切工作习惯都改变了。AI LLM并没有被神话成无所不能的魔法师它更像是一位极其高效但需要明确指令的执行者。它没有让我变成超级程序员而是让我变得更懒了——更善于把精力集中在真正有价值的思考上而不是消耗在重复性劳动中。2. AI编程工具链开源与商业并存的策略2.1 Claude Code主力引擎在几款工具中Claude Code (cc) 是我用的最强的。在相同的自建vLLM服务条件下无论是复杂架构的重构、多文件联动的修改还是从零搭建一个完整模块cc总能完成任务。它的长上下文窗口、对复杂上下文的保持能力、以及对代码整体结构的理解深度都明显优于其他工具。我的典型用法是把需求规格说明、系统设计文档和相关代码文件集中放在usecase目录下然后让cc读取这些文件按照步骤执行。对于大型任务我会先用/plan命令让cc生成执行计划确认无误后再用/edit模式执行。2.2 多工具并用的防御性策略我不会只依赖cc。原因很现实怕Anthropic公司哪天改变策略直接限制工具的使用或者大幅提高价格。软件开发的自主性不应该建立在对单一商业服务的绝对依赖之上。因此我同时使用Oh My Pi Agent (omp) 和 OpenCode (opencode) 作为补充工具链也安装过Qwen Code、Codex、Cline等工具进行对比测试。开源工具和商业工具并用的策略既保证了能力覆盖也保留了选择权。各工具的特点对比Claude Code推理能力强适合复杂任务商业服务|Oh My Pi Agent (omp)开源可自部署适合树莓派/嵌入式等边缘设备编码社区活跃|OpenCode (opencode)开源可自部署适合通用日常编码社区活跃Qwen Code对中文理解更好适合国内项目CodexOpenAI生态集成度高2.3 工具链的演进方向工具本身不是目的工具链的效率和稳定性才是。未来的方向是建立统一的接口抽象层让不同AI编码工具可以无缝切换建立工具能力的自动化评估体系根据任务类型自动选择最合适的工具本地部署的推理能力持续提升降低对云端服务的依赖3. AI编程的瓶颈耗时80%在哪里3.1 传统编程的耗时分布在传统的手工编程流程中手写编写代码的时间占比通常超过80%。需求分析由产品人员完成功能测试由测试人员负责开发工程师的核心价值被简化为把设计文档翻译成代码。这种分工模式的前提是代码编写是最耗时、最核心的环节。但这一前提在AI时代正在被颠覆。3.2 AI时代的耗时重新分布当我用AI来编程后耗时结构发生了根本性反转阶段传统模式耗时AI模式耗时占比变化需求分析产品人员1-3天我亲自分析1小时从他人负责到我主导系统设计2-5天 (UML工具)1-2小时 (AI生成mermaid)大幅压缩代码编写3-10天10-30分钟 (AI生成)压缩90%测试调试2-5天1-2小时 (AI辅助)大幅压缩文档编写1-3天30分钟 (AI生成)压缩80%在实际的业务系统开发中如果用AI编程我大概花1小时来分析需求和编写需求规格说明的Markdown文档最后喂给Claude执行。/plan可能只需1分钟/edit执行可能也只需1分钟。编写测试工具进行测试的过程和功能开发模式基本一致。3.3 核心洞察AI越强大需求分析越关键有一个深刻的体会在实际的业务系统开发过程中如果我们不写清楚需求说明不写清楚执行步骤就笼统地写上两三句再强大的LLM也不知道我想要具体干什么。我确实没有用过那些顶尖的闭源LLM所以很好奇那些号称晚上8小时自动长任务的案例——它们背后一定有极其详尽的输入文档和明确的执行规划。至少在我的编程活动中需求分析、系统设计、功能流程处理的Markdown文档编写耗时占比绝对在90%以上。我不可能晚上凌晨的时候写文档所以根本用不着晚上让AI开工。以前我们可以做一个简单的需求分析然后在写代码的过程中逐步梳理业务流程。AI时代则完全不同——如果不一次性写清楚随便写几句需求规格说明就喂给AI那就等着之后被一堆不符合预期的代码反复折磨吧。3.4 对团队角色的重新思考这种耗时分布的变化对团队角色分工有深远影响产品人员的价值需要重新定义当代码编写不再是最耗时的环节产品分析、用户研究、业务理解的价值更加凸显开发者的能力要求升级从会写代码变成会提需求、会设计系统、会评估AI输出测试人员的定位变化从执行测试脚本变成设计测试策略和边界条件4. 需求分析模式的转变4.1 传统模式碎片化、多系统、二进制文件以前的需求分析流程是这样的产品人员交给我一个Issue单和Axure界面或者第三方单位交给几份对接协议的Word文档我直接分析阅读文字和看图然后用UML工具画用例图最后在Readme之类任务单系统界面上回复整个过程基本涉及三到四个不同的系统Issue管理工具、Axure原型文件、UML设计工具、任务单系统。信息碎片化每次分析需求都要在多个工具间切换。4.2 新模式统一化、Markdown驱动、AI协同现在的需求分析流程完全不同了第一步信息收集与格式统一我会用Claude、Oh My Pi Agent (omp)、OpenCode (opencode) 工具分别把以下信息提取出来全部转换为Markdown文件放到系统仓库的usecase目录下Issue单内容 →issue-description.md产品界面截图 → 截图 文字说明 →ui-specification.md对接协议Word文档 → OCR提取 格式化 →integration-protocol.md历史相关代码和文档 → 直接放入目录可能是一份MD也可能是几份MD但至少所有信息都在一个子文件夹里了。这是关键变化从多系统碎片化信息到单一目录的聚合。第二步AI辅助需求分析对这些MD文档使用AI工具继续做进一步分析生成Mermaid/PlantUML用例图、时序图、活动图梳理业务规则和边界条件识别潜在风险和遗漏点生成可执行的验收标准4.3 Markdown驱动为什么格式比工具更重要一个重要的认知转变我越来越不在意用二进制文件来承载设计图了。传统的UML工具生成的是二进制文件.pd, .staruml, .rpproj等这些文件无法用Git做版本管理无法用文本diff工具查看变更AI模型无法直接阅读团队协作需要统一安装特定工具而Markdown格式承载UML图Mermaid/PlantUML的优势纯文本天然支持Git版本管理任何编辑器都能查看和编辑AI模型可以直接读取和理解可以嵌入到其他Markdown文档中形成完整的技术文档体系渲染后与二进制工具产出的图没有视觉差异这看似是工具选择的改变实则是工作流范式的转变从图形化工具驱动到文本描述驱动后者天然更适合AI时代。5. 设计工具的范式转变5.1 二十年的UML工具使用史我用了近二十年PowerDesigner画UML图后来切换到StarUML。无论是哪种工具它们都有一个共同特征二进制文件格式图形化操作界面。这种模式在AI出现之前是理所当然的——设计图就应该用设计工具来画。但AI时代带来了一个新的问题如何让AI理解并参与系统设计5.2 Mermaid/PlantUMLAI友好的设计语言常见做法是把需求分析MD喂给Claude让它自动生成Mermaid/PlantUML格式的UML设计图。这些图直接嵌入在MD文档中客户端API网关业务服务层数据访问层消息队列这种模式的优势设计即文档图不在独立的二进制文件中就在文档里随文档一起被Git管理AI可读可写AI可以直接生成、修改、分析这些图表版本可控每次变更都是文本diff清晰可追溯协作友好不需要统一安装任何设计工具5.3 从画图到写设计这背后更深层的变化是从前我花大量时间调整UML工具的格式、对齐、颜色、字体现在我把这些时间省下来花在更本质的事情上——思考系统的结构、模块的边界、数据的流向。设计工具的变革不是从PowerDesigner换成StarUML而是从图形化绘制转向文本化描述。Mermaid/PlantUML是手段真正的革命是系统设计过程本身被文本化和AI化。6. 产品设计的工作流创新6.1 从开发者视角到产品思维我不是产品人员从来也没做过产品人员。但AI工具正在模糊这个界限。过去产品需求和开发之间的沟通过程是产品开发最大的效率杀手之一产品写PRD开发读PRD开发理解后做设计产品看设计确认开发再实现……每个环节都有信息损耗。6.2 OpenDesign Claude开发者的产品设计实践现在我也尝试用OpenDesign工具配合Claude来做界面原型。流程大概是用文字描述需求在Markdown中详细描述页面功能、用户操作流程Claude生成原型描述让Claude把文字需求转化为结构化的原型描述可以导出为HTML线框图OpenDesign渲染将描述转化为可视化的界面原型迭代修改直接在Markdown中调整描述重新生成这个流程的核心价值在于开发者直接参与产品设计避免了需求传递中的信息损耗原型即代码设计变更可以直接版本管理快速验证几分钟就能看到一个可交互的原型6.3 局限性与未来展望当然这种模式还有局限生成的原型在交互细节和视觉精美程度上无法替代专业设计师的工作对于复杂的业务规则梳理仍然需要产品思维和经验AI生成的原型可能需要多次迭代才能达到可用水平但随着AI生成能力的提升特别是多模态模型的发展这个流程的可行性正在快速提高。也许不久的将来开发者只需要描述用户想要什么AI就能生成可用的产品原型。7. 后台系统开发二十年编码经验的AI化7.1 传统后台开发的瓶颈这是我本质上二十年没怎么变过的工作。C/Java/Python/Go——无非是积累了多种编程语言但开发的本质没有变化阅读需求、设计接口、编写代码、调试bug、优化性能。手写了二十年最深刻体会是编程能力的提升曲线在达到一定阶段后会变得非常平缓。一个写了十年代码的工程师和一个写了二十年代码的工程师在纯编码能力上的差距远小于他们之间的业务理解差距。7.2 AI对后台开发的重构使用AI之后后台开发的几个核心变化编码阶段被压缩在C/Java/Python/Go等编程过程中AI的编码速度和能力肯定比我强。纯coding这块基本被取代掉了——AI生成的代码在规范性、完整性、边界条件处理上通常优于手工编写。需求分析和系统设计成为新瓶颈好在需求分析和系统设计这块没人参与AI是不可能搞定的。原因很简单真实客户对需求的描述往往是模糊的、矛盾的、不完整的业务领域知识只有人类开发者才能理解技术方案的权衡决策需要人类的经验和判断AI时代开发者的核心竞争力从编码能力转向理解能力和判断能力能否准确理解客户真实需求能否设计出合理的系统架构能否评估AI生成代码的质量能否在复杂系统中做出正确的技术决策8. 前端系统开发从厌恶到接受8.1 前端恐惧症以前我是最厌恶前端开发的。十年前也搞过一阵子jQuery框架下的Web开发对HTML和CSS一点不感兴趣感觉就是写写布局、调调样式没有技术含量。JavaScript倒是能接受毕竟写逻辑代码的语言。那时候最头疼的需求就是帮我把前端也做了吧——意味着要面对一堆标签、样式、兼容性问题而且调试体验极差。8.2 AI如何改变了我的看法现在开始也用Claude试着写前端代码心态发生了根本性变化HTML CSS的AI生成HTML和CSS本质上是结构化和样式化的描述语言。对于AI来说这是最容易生成的代码类型之一——因为它们是所见即所得的验证标准非常明确。TypeScript不再讨厌有了AI的辅助TypeScript不再是我的敌人。AI生成的TypeScript代码在类型定义、接口设计、模块化组织上通常比我手工写的更规范。前后端开发流程的统一现在我可以用AI同时生成后端API和前端页面用AI编写测试工具模拟用户操作前后端联调由AI辅助的自动化工具完成这极大降低了做全栈开发的心理门槛。从前端恐惧症到前端也不过是代码AI是我认知转变的催化剂。9. 单元测试从谁写bug谁修到AI辅助的自动化9.1 坦白过去几乎不做单元测试有些事情不是技术难度多大而是方不方便的事情。在后台开发中以前基本是手工编写单元测试不好测试的模块常常让前端开发人员对接测试测试人员去做集成测试产品人员去做验收。我不会告诉你的是我基本上没有单元测试。不是不知道单元测试重要而是手工编写测试用例耗时耗力和写业务代码差不多测试维护成本高昂需求一变测试全废“谁写代码没有bug啊”——侥幸心理9.2 AI如何改变单元测试生态现在用Claude写Python测试工具很容易构造测试数据也不难AI生成测试用例的优势自动生成边界值AI天然擅长列举各种边界情况Mock数据快速构造不需要手动编写大量测试数据测试覆盖率追踪AI可以根据代码覆盖率建议补充测试回归测试自动化需求变更后AI可以自动更新受影响的测试用例实际效果一个之前没有单元测试的模块现在AI可以在5分钟内生成完整的测试套件测试用例的覆盖率和质量通常优于手工编写最关键是测试不再是开发的负担而是开发的自然延伸9.3 从要不要写测试到怎么写好测试AI工具让单元测试的门槛从需要大量时间投入降低到只需要描述期望行为。这个转变的意义不亚于从手工编译到自动构建工具的出现。未来可能的方向AI根据代码变更自动生成增量测试AI根据生产环境监控数据发现潜在边界场景AI根据用户反馈自动补充异常场景测试10. AI编程工具与传统编程工具的融合生态10.1 工具分工AI vs 传统AI编程工具不再是传统IDE的替代品而是与它们形成互补工具类型代表工具核心职责AI集成方式AI编码工具Claude Code, Oh My Pi Agent (omp), OpenCode (opencode)代码生成、重构、分析独立终端/CLIJava开发环境EclipseJava代码阅读、编译、调试作为AI的输出目标通用编辑器VSCode多语言代码阅读、调试、Vibe Coding集成AI插件Python IDEPyCharmPython项目阅读、调试远程连接AI输出10.2 具体集成模式Eclipse (Java专业环境)阅读和理解大型Java项目结构自动编译和构建AI生成的Java代码直接放入项目后在Eclipse中编译验证VSCode (通用开发环境)传统C代码环境前端系统HTML/CSS/TS/Vue开发代码阅读、自动编译Vibe Coding的快速原型验证PyCharm (Python专业环境)Python项目结构分析代码阅读和调试AI生成Python代码后的验证和调试10.3 工作流AI IDE的协同典型的工作流程需求分析阶段AI工具 Markdown文档不需要传统IDE设计阶段AI工具生成设计图Mermaid/PlantUML在Obsidian中查看编码阶段AI工具生成代码 → IDE中编译验证 → 发现问题 → 反馈给AI修正测试阶段AI生成测试代码 → IDE运行测试 → 分析测试结果部署运维Hermes Agent自动化执行11. Obsidian所有文档的统一入口门户11.1 为什么选择Obsidian把所有新写的文档都放到Obsidian目录下来统一管理这是一个经过深思熟虑的选择。核心理由文档统一入口门户比任何单点功能都重要。11.2 文档管理的核心原则统一格式自己写的文档尽量用Markdown格式其他渠道来的文档Word、PDF、HTML通过AI工具转换为Markdown统一目录通过mklink软连接把已有系统目录连接到Obsidian目录下保证所有文档可以在一个软件界面上查看阅读统一搜索Obsidian的全局搜索 标签系统快速定位任意文档11.3 工具选择功能 LLM我看重Obsidian的丰富插件生态而不是因为它能用LLM来分析一遍得到一个关系图——这个功能虽然酷但不是我最看重的。Obsidian的优势插件生态Dataview从Markdown中提取结构化数据构建动态视图Calendar按日期查看文档与工作日记天然契合Templater模板化文档创建保持文档格式统一Excalidraw手绘风格的流程图和思维导图Quick Add快速添加新笔记11.4 文档即代码Obsidian Markdown的组合让文档管理具备了代码管理的特性Git版本控制所有文档变更可追溯交叉引用双链笔记文档之间建立关联全局搜索毫秒级全文检索统一入口一个软件看所有文档12. Hermes Agent所有自动化的统一入口门户12.1 从个人工具到系统平台如果说Obsidian是所有文档的入口门户那么Hermes Agent就是所有自动化活动的入口门户。Hermes Agent把所有开发活动和运维活动的自动化集中起来它的强大技能体系和工具体系可以很好胜任这一切技能体系将重复性工作固化为可复用的技能工具集成连接Git、CI/CD、监控系统等各种工具定时任务Cron Job实现定时自动化子代理Delegate Task实现并行自动化12.2 典型自动化场景RD文档自动生成通过技能自动分析GitLab仓库中的代码和文档一键生成研发文档。这是Hermes Agent最典型的应用之一——从代码仓库到研发报告完全自动化。运维自动化服务器监控、日志分析、部署流程、故障排查等运维活动通过Hermes Agent的技能体系和工具集成实现半自动化甚至全自动化。知识库建设通过/learn命令将技术要点固化为技能建立可复用的技术知识库。面对老旧系统可以用Claude先分析一通给出design.md文档然后对局部模块单独提问——这个过程要善于提问题。12.3 门户化思维两个门户的价值Obsidian 文档门户所有文档的统一入口解决信息在哪里的问题Hermes Agent 自动化门户所有自动化流程的统一入口解决怎么自动化的问题这两个门户的组合构成了AI时代开发者的基础设施。13. AI工具不只是生产力工具更是学习工具13.1 作为技术学习工具借助LLM能力和技能工具Claude/OpenCode/OpenCode和Hermes Agent都是极好的学习工具。面对老旧系统的学习路径面对没接触过的代码系统你可以用Claude先整体分析一通给出design.md文档对局部模块单独提问深入了解细节让AI生成代码流程图和数据流图对不理解的概念直接问AI这个过程的关键是善于提问。AI的知识和推理能力取决于你提出的问题质量。专题学习资料的制作在Hermes Agent中可以就某个技术点制作专题学习资料。大部分情况下这种方式比去百度找文章效率更高——虽然不能百分之百保证质量但至少获取和整理知识变得容易了。13.2 作为思维训练工具AI工具还有一个被忽视的价值它强迫你学会清晰思考。以前写代码思路模糊也可以凑合。现在你必须在给AI下指令之前把需求分析清楚、把步骤写明白、把边界条件定义完整。这种必须先想清楚再动手的要求反而促进了思维能力的提升。13.3 AI工具学习的注意事项保持批判性思维AI的输出需要验证不能盲目相信理解而非复制不要只复制AI生成的代码要理解其背后的原理持续迭代AI工具的能力在快速演进需要持续学习和适应14. 结束语从三月份至今的四个月我经历了一场从AI辅助编程到AI全流程接管的转变。这场转变没有惊天动地也没有一夜暴富式的效率提升而是像水滴石穿一样在每一个细节中慢慢渗透。核心体会AI不是魔法它不会自动帮你思考但它会无限放大你的思考质量工具链不是越多越好关键是在合适的场景使用合适的工具Markdown是未来的设计语言文本化、版本化、AI友好的格式正在取代二进制工具需求分析是新的核心能力当代码生成变得廉价需求分析的质量决定了最终产品的价值AI是最好的学习工具没有之一ALL in AI!