在过去的数月中，我深度体验了包括 Claude Code 在内的多款自主编程智能体及 Spec 驱动编程工具，消耗了海量的 Token。本文将分享在这一过程中获得的真实经验与反思。
在自主编程智能体与 Spec 驱动编程日益成熟之际，我曾设想过一个高度自动化的理想编程流程，例如：
- 让 AI 自动编写并执行测试。
- 使用 Playwright 进行端到端测试。
- 自动访问应用页面，检查控制台错误并尝试自行修复。
- 自动截图并分析页面 UI 是否符合预期。
- AI 完成任务后发送通知。
- 让 AI 在编程过程中朗读重要决策。
- 根据开发计划自动执行任务列表。
- 开发基于智能体的项目管理系统，协调多智能体工作。
然而，经过近一个月的实践，尽管上述设想的功能大多得以实现，但最终效果远未达到“甩手掌柜”的理想状态。
产品定义：与AI对齐需求的效率陷阱
开启一个项目，首要步骤便是明确产品定义。我的初衷是与AI清晰对齐需求和目标，以求一劳永逸。
但实践中遇到了两个核心问题：
- 撰写详尽需求耗时巨大：像产品经理一样输出完整、无歧义的PRD，过程漫长，违背了提效初衷。
- 需求本身具有渐进性：多数情况下，我们无法一开始就确定所有细节，传统开发中“边做边改”的模式依然存在。
于是，我认为最有效的路径是与AI编程智能体进行“产品经理式”的讨论，反复对齐。这听起来很美好，但实际效率并不高。
效率问题的本质，揭示了当前人机协作中的一个普遍矛盾：要么AI的建议过于超前（需要我们付出高额学习成本去理解），要么我们不得不频繁纠正AI的方向（导致最终蓝图难以成型）。实际结果是，花费一整天与AI对话，可能仍无法产出一份经过你完整评审的、满意的需求文档。只有当需求极其简单明确时，效率才会显著提升。
经验一：避免将过于复杂的事务交给AI
此处的“复杂”特指需求、设计与架构的复杂性。当我布置一个设计任务时，AI往往会给出一份看起来完美但极其复杂的方案。其中可能90%的特性我都需要，但我清楚以当前资源无法实现或难以测试。
即使我手动删减一半内容，在实施阶段依然会觉得复杂。我猛然醒悟：我当下需要的或许不是一个“系统”，仅仅是一个“功能”或一个“页面”。AI有能力构建复杂事物，但你必须准备好承接随之而来的复杂性。
经验二：警惕“知识诅咒”，坚持结果导向
在实践自主编程智能体时，我深刻体会到：人很难真正掌握自己知识范围以外的东西。
例如，在实现一个3D材质功能时，我提出了“材质管理模块”的想法。AI据此给出了一个精良的设计，同时也引入了大量我未曾接触过的概念和术语。结果，这个项目几天后便宣告失败。最终，我花了一两个小时重新实现了一个仅包含必需功能的简易材质管理器。
“乱花渐欲迷人眼”在此情境下尤为贴切。如果能抵抗住AI那些“优秀但超纲”的建议诱惑，实践过程会轻松许多。请始终牢记，AI是工具，应以结果为导向，避免在非核心事务上过度耗费时间。
回归“传统”：AI辅助而非AI自主
在尝试了诸多酷炫的框架后，我回归了更“传统”的AI使用方式。像 Claude Code、Open Code、Roo Code 这类自主编程智能体工具逐渐在工具箱中吃灰，转而将它们作为“通用智能体”处理日常问题。
编程的主力重新变回了在IDE中，通过一句句的提示（如Copilot）来编写代码。这种方式对我来说效率更高，控制感也更强。
关于模型选择的思考
在编程任务中，我主要使用 glm-4.6 模型。对于一般性编程任务，它完全能够胜任。但在一些小众或特定技术领域（如为某平台开发Agent管理产品时），它对某些专有概念（如Commands/Skills）的理解会出现偏差。
即便提供官方文档网址或构建本地知识库，效果改善也有限。最终，切换到该平台自家的模型（如Claude Sonnet 4.5）后，问题才得以顺利解决。这表明，在处理与特定生态强相关的任务时，“自家模型”可能有独特优势。
反思：那些自动化的美好愿望
前文提及的诸多自动化设想，如自动测试、UI检查、语音通知等，虽然基本都实现了，但我却发现——我对这些功能本身失去了需求。过度的自动化并未带来预期的解放，反而引入了新的复杂性和维护成本。
实践建议总结
基于以上经验，对于希望利用AI提升编程效率的开发者，我有几点不成熟的建议：
- 从简入手：任何让你感到复杂的方法论或工具，都应考虑及时放弃。
- 定位为“辅助”：优先考虑AI辅助编程，而非一步到位的“自主编程”。
- 保持初心：明确核心目标，抵御AI提出的、可能带你偏离主线的“优秀”附加建议。
- 精简规范：除了核心的架构约束，不必编写过多、过细的AI规范文件（如冗长的 CLAUDE.md）。
发表于 6 天前
|
查看: 20|
回复: 0
