夜雨聆风
新时代 AI 软件开发:一个后端工程师的实践思考
本文是阅读 Peter Steinberger（ClawdBot 创始人）访谈后，结合个人 AI 开发实践的感想与总结。
一、AI 开发工具的演进脉络
回顾 AI 辅助软件开发的演进历程，整体链路清晰可循：
在这条演进路径中，有一个核心主题贯穿始终——提效。
| 阶段 | 代表能力 | 提效体现 |
| 智能提示 | IDE 自动补全 | 缩短方法实现时间 |
| 代码生成器 | 框架样板代码生成 | 消除冗余低效的重复劳动 |
| 文档助手 | 设计文档、流程图生成 | 压缩前期设计工作量 |
| 开发助手 | 端到端代码生成 | 98% 的代码交由 AI 完成 |
二、实践历程：从怀疑到颠覆
阶段一：RooCode/KiloCode + OpenRouter
来到公司后，借助内部知识沉淀，我最早接触的是 RooCode/KiloCode + OpenRouter 组合。主要用于两件事：
-
1. 自动分析需求文档，产出设计文档 -
2. 根据设计文档，自动生成代码
文档生成：惊艳
在文档设计和撰写方面，体验极为惊艳——只需梳理出核心要点，架构图自动生成，文档结构自动成型，API 文档一并产出。我只需校验内容是否符合脑中预期即可。
代码生成：落差
然而代码生成的体验却令人失望。前面有多大的惊喜，此刻就有多大的期望落差。
生成的代码整体结构尚可，但内部逻辑与设计文档存在严重的幻觉问题。与其在错误的基础上修修补补，我宁愿它只输出伪代码，具体逻辑由我来重写——后续我也确实是这么做的。
阶段定位：文档绘图助手 + 代码脚手架生成器
阶段二：Claude Code 的无限可能
在公司内部的分享推广下，我接触到了 Claude Code，开启了一段全新的探索。
命令行风格相比 IDE 插件界面更具极客范儿。更关键的是，它展现出的强大能力让我看到了一个电脑助手的雏形——似乎以后再也不需要自己去找文件、打开软件、搜索下载资源了？
实践之后，确实如此。但我认为仅到这个程度还不够，于是继续用 Claude Code 探索更多可能性，结果相当不错。
认知转折点：这个阶段彻底颠覆了我早期对 AI 的不信任。
以前虽然也认为 AI 很强，但那更多是被他人的宣传文档灌输的”二手认知”。只有亲身被 AI “教导”一番，才会有刻骨铭心的感受。
阶段三：Augment + Opus 4 的当下
快进到现在的 Augment + Opus 4 组合——98% 的代码由 AI 生成。
这个数字或许主观，但通过账单和 Tokens 消耗来看，会更加直观。
一个大型需求，我按项目和功能拆分成 4-5 个会话来处理。究竟是 Agent 的差距、模型的差距，还是我对项目的熟悉度提升，我没有深入考究。但结果与之前相比，简直天壤之别：
- ❌ 不再需要删掉生成的代码自己重写
- ✅ 只需告诉它哪里有错误，它就能自行修正
- ✅ 甚至把日志贴给它，它就能自己分析问题原因
这是一个颠覆性的飞跃。 到目前为止，我只有极少量代码需要亲自编写，绝大部分代码和逻辑都由 Augment 完成。
三、被低估的核心环节：检查
在描述 AI 开发流程时，有一个极其重要却容易被忽视的环节——检查。
检查的三个维度
| 检查阶段 | 检查内容 | 关注重点 |
| 方案检查 | 设计文档的细节 | 逻辑是否自洽、边界是否覆盖、是否存在幻觉 |
| 代码检查 | 生成代码的逻辑 | 实现是否符合设计、是否有隐藏 Bug、是否符合规范 |
| 测试检查 | 实际运行的结果 | 功能是否正确、边界 Case 是否通过、性能是否达标 |
时间成本的真相
坦白讲，检查才是使用 AI 过程中最大的时间成本。
表面上看，AI 几秒钟就能生成一份设计文档、几分钟就能产出几百行代码。但实际上：
- 审阅一份 AI 生成的设计方案，需要逐条核对逻辑是否正确
- 检查一段 AI 生成的代码，需要逐行确认实现是否符合预期
- 测试一个 AI 实现的功能，需要覆盖各种边界场景
生成 5 分钟，检查 2 小时——这才是真实的时间分布。
本质：信任问题
检查成本居高不下的本质，是信任问题。
我们无法完全信任 AI 的输出，因为：
- AI 会产生幻觉，自信地输出错误内容
- AI 缺乏业务上下文，可能遗漏关键细节
- AI 的”正确”可能只是”看起来正确”
这种不信任并非偏见，而是基于实践的理性判断。正因如此，检查环节不可或缺。
信任的建立是渐进的
有趣的是，随着使用的深入，信任是可以逐步建立的：
- 对于熟悉的模式：检查可以快速扫过
- 对于复杂的逻辑：仍需逐行审阅
- 对于关键的功能：必须完整测试
信任不是非黑即白的，而是在不同场景下动态调整的。
四、踩坑与优化：建立高效工作流
遇到的问题
在使用 Augment 的过程中，也暴露出几个问题：
-
1. 上下文爆炸：Augment 会自动将大任务拆解为小任务，但如果将一个大功能塞进单个会话，会导致上下文膨胀 -
2. Tokens 海量消耗：随之而来的是 Tokens 的过度消耗 -
3. 插件稳定性：GoLand 插件反复崩溃，反而降低效能 -
4. 不复用的代价：若不复用上下文，又会出现幻觉和不准确的问题
当前最佳实践
经过摸索，我形成了一套相对高效的工作流：
⚠️ 标记的步骤是检查环节，也是实际耗时最多的环节。
效果验证
采用这套流程后：
- Tokens 消耗：45 万额度已消耗 24 万，相比此前明显降低
- 稳定性：插件卡死现象大幅减少
- 质量：代码准确率显著提升
- 检查效率：因为前置拆分充分，单次检查的范围更小、更聚焦
五、与 Peter Steinberger 的共鸣：从访谈中获得的启发
以下内容源自阅读 Peter Steinberger（ClawdBot 创始人）访谈后的思考与共鸣。
5.1 关于”闭环原则”
Peter 在访谈中反复强调一个核心观点：
“真正高效的秘诀在于：你必须把闭环做完整，让 agent 能自己 debug、自己测试。”
这与我的实践体验高度一致。检查之所以耗时，很大程度上是因为闭环不完整——AI 生成的代码无法自我验证，必须依赖人工介入。
Peter 的做法是：
- 每做一个功能，必须让 AI 写测试
- 把核心逻辑设计成可以用 CLI 跑
- 让 agent 能自己验证结果
这启发我思考：如何在我的工作流中建立更完整的反馈闭环？
5.2 关于角色转变：从”写代码”到”织代码”
Peter 用了一个很有意思的词——“织代码”（weaving）：
“我现在写代码用的动词都变了，’把代码织进现有结构里’，有时候甚至要先改结构，才能让它装得进去。”
这个比喻非常精准。我的角色确实在发生转变：
从”亲手写每一行代码”变成”引导 AI 把代码织进系统”。这不是偷懒，而是一种更高层次的抽象。
5.3 关于信任与放手
Peter 提到一个很重要的心态转变：
“很多没管过人的开发者，没有学会放手，接受’这段代码不是我理想中的样子，但它能让我更接近目标’。”
这句话击中了我。早期使用 AI 时，我总是对生成的代码不满意，觉得”不够优雅”、”不是我的风格”。但 Peter 的经验告诉我：
- 不完美的地方，永远可以之后再改
- 迭代式改进比一次性完美更重要
- 信任是在一次次”生成-检查-修正”的循环中建立的
5.4 关于”Prompt Request”
Peter 提出了一个颠覆性的观点：
“PR 在我眼里，越来越像是 Prompt Request。”
他甚至说：
“我读 prompt 的时间，比读代码还多。因为那是更高信号的信息：你是怎么得到这个结果的？”
这让我意识到，在 AI 时代，表达清楚”想要什么”比”怎么实现”更重要。好的 Prompt 本身就是一种设计文档。
5.5 关于学习与成长
Peter 说了一句让我印象深刻的话：
“我去年在软件架构和系统设计上学到的东西，比过去五年加起来都多。”
这与我的感受一致。使用 AI 的过程，反而让我成为了更好的工程师：
- 必须把架构想清楚，才能更容易验证
- 必须理解系统全貌，才能有效引导 AI
- 必须建立反馈闭环，才能保证质量
AI 不是让我变懒，而是逼我思考得更深。
六、小结与展望
核心感悟
-
1. AI 不是替代品，而是杠杆。 用好它的关键在于——合理拆分、有效引导、持续迭代。 -
2. 检查是隐藏的主角。 生成只是开始，检查才是保障质量的关键。AI 越强大，检查的价值越凸显——因为错误的代价也越大。 -
3. 信任需要时间。 对 AI 的信任不是一蹴而就的，而是在一次次”生成-检查-修正”的循环中逐步建立的。 -
4. 闭环是效率的关键。 正如 Peter 所说，让 agent 能自己验证结果，是提效的核心秘诀。 -
5. 角色在转变。 从”写代码”到”织代码”，从”实现者”到”架构师+审阅者”。
未来展望
Peter 在访谈中描绘了一个令人兴奋的未来：
“我突然意识到，我现在几乎什么都能做了。”
这种”无限可能”的感觉，我也在逐渐体会。随着模型能力的提升、工具链的完善，AI 辅助开发的边界还在不断扩展。
但同时，我也保持清醒：
- 技术在变，但软件工程的本质没变——可测试、可维护、可扩展
- 工具在变，但对品质的追求没变——用户体验、系统稳定、代码质量
- 角色在变，但责任没变——最终为结果负责的，依然是人
写于 2026 年 2 月
