AI辅助编码已经有一段时间了，现在我已经不再亲自阅读AI生成的代码了。为什么不读了？因为这根本不符合技术进化的方向。未来的模型必然会越来越庞大和智能，就像现在的Claude Opus 4.5，我私下称它为“天才”。在健全的工程化约束下，代码的质量已经被控制在相当精准的水平了。
你为什么还在读AI写的代码？
很多人仍然坚持逐行审查AI写出的代码，背后的原因通常离不开两点：
- 不信任感：总感觉AI写的没有自己好，认为AI无法真正理解复杂的业务逻辑。但在质疑这一点前，不妨先看看自己的技术债记录或BUG修复清单——你真的写得更好、更稳健吗？
- 恐惧感：担心代码是“黑箱”生成的，一旦后期出问题，自己会无从下手排查。
坦白说，一开始我也被这两个问题困扰。但比这更令人沮丧的，是一种深深的无力感。
你无法阻止AI技术的迭代，你也无法企及AI的“日产万行”效率。几个月前，我曾尝试跟上AI的节奏去阅读代码。起初还能勉强应对，但随着模型的快速进化，我清醒地认识到一个事实：人脑的阅读速度，永远追不上AI的生成速度。
所以，我做出了选择：不读了。
不读代码，如何把控质量？
答案是：工程化。
软件工程发展到今天，已经积累了非常成熟的工程化理念与实践。我将过去常用的工程方法论全部整合起来，结合AI的能力，覆盖了从需求到上线的整个开发闭环。
完整的工程化流程
我搭建了一套基于AI辅助的完整工作流，具体如下：
| 阶段 |
具体做法 |
| 需求分析 |
接收需求后，在Cursor中通过定制的skill与AI进行深入讨论，结合现有代码库分析，生成可行方案后提交至Jira/Ones等需求管理平台。 |
| 方案设计 |
需求讨论的过程会直接产出整体技术方案，直接保存到对应的需求文档中，形成记录。 |
| 编码实现 |
以 Golang 项目为例，采用 DDD（领域驱动设计）与 TDD（测试驱动开发）模型，让AI自主完成编码、编写单元测试、并运行集成测试。 |
| 质量测试 |
不读代码怎么测试？想想公司的测试工程师——他们通常也不读你的源码，但照样能完成测试。我们编写端到端（E2E）自动化测试来覆盖核心业务场景，执行后直接去相应平台验证数据的正确性即可。 |
| 产品发布 |
通过发布的专用skill，自动生成版本变更日志（Changelog）和面向用户的功能使用文档。 |
| 线上排查 |
当Web平台出现问题时，用户通常会提供问题链接。此时可以让Cursor自行调用浏览器，自主阅读代码、查询日志和数据库。注意：日志和数据库可能位于独立的审计平台，第一步需要先处理好鉴权问题。 |
关于Skill的深入理解
这里提到的Skill并非通用的MCP（模型上下文协议）或工具。它必须是：
- 与你的专业技能包深度结合的
- 流程化、可复用的
- 针对特定场景高度优化的
在上述开发流程的每一个环节中，你都可以深入挖掘并沉淀出属于自己的、高效的Skill。
总结与思维转变
核心观点：在 AI 时代，开发者的核心角色正在从“代码编写者”向“质量与流程的把控者”演变。
三个必须完成的关键认知转变：
- 放下必须人肉审查的执念：不要试图用有限的人脑阅读速度去追赶无限的AI生成速度，这是一场注定失败的竞赛。
- 全面拥抱工程化方法：用 TDD、E2E测试、自动化流水线等工程实践来验证质量，取代低效的逐行代码审查。
- 建立并迭代自己的Skill体系：将个人的开发经验与工作流程固化为一系列可复用、可优化的Skill，让AI在你的规则框架内高效、可靠地工作。
最终目标：让AI在严谨的工程化框架内自由发挥创造力，而你只需要聚焦于最终的结果是否正确——这就像测试工程师从来不读你的每一行源码，但他们构建的测试体系同样能保障产品质量。
思维转变远比工具本身更重要。当你不再纠结于“这行代码语法是否优雅”，而是深入思考“这个系统的验证机制是否足够鲁棒”时，你就真正掌握了AI辅助开发的正确姿势，走上了提升工程效能的快车道。关于如何构建这样的工程化体系，你可以在 云栈社区 的 后端 & 架构 板块找到更多同行者的实践与讨论。 | 
发表于 昨天 09:03
|
查看: 0|
回复: 0
