#代码设计

宝玉
3个月前
我最初鼓吹 Claude Code 的时候,就特别说明了新手就不要去用了,因为你可能打开也不知道该干嘛!但是对于铁锤这样的老手来说,只是没切换思维模式,逼着自己用一段时间就会适应,并且习惯了就再也离不开了。 程序员熟手要用好 Claude Code,最大的转变来源于思维的转变和开发习惯的转变。 这个转变就是先设计再写提示词,然后用提示词生成代码。 “先设计再写代码”这话其实老生常谈,但是说和做是不一样的,虽然我们软件开发都号称是先设计再开发,那通常是针对整体的系统设计,但是到具体实现的时候,很少有人会这么做,因为编程的细节,它不是一下子就清晰的,就算你是个老手,在没实现过的模块,在没有写完的时候是没有完全想清楚的,只有去动手写,一边写一边想,写完一部分在调整甚至推翻重写,这样反反复复写完才算是把它搞明白了。 如果再让你把写过的模块重新实现一遍,那就简单直接多了,能很快写完,因为整个设计已经了然于胸,只剩下代码实现了。 写代码有些像写文章,你写作的速度是跟不上你脑子思考的速度的,所以你脑子构思好的东西,还要花很长时间的输出才能成文,类似的你思考好的架构要花时间才能写成代码并且编译运行。 但写代码又不完全像写文章,因为文字是有艺术性的,你的风格、用词、结构没有特定的套路,要反复斟酌,很费时间,AI 生成的文字很难满足这些方面的要求(有 AI 味),但代码无所谓,相对结构比较固定,而且能稳定运行的话,代码写的差一点也不是不可以接受。 所以写文章像我们这样天天写字的人,反而不太爱用 AI 写,因为它写出来的东西有一种奇怪的 AI 味,自己都不爱看更不要说你的读者了。 但是写代码不一样,你想清楚了设计,把设计写成提 Prompt,让 AI 去生成代码,以现在 Claude 4 的能力,并不会与你期望的有太大出入,如果有出入,要么就是小问题,再补加要求就能解决,甚至手动调整;如果有大的出入,那一定是你设计的问题,是你提示词没有写清楚,那么就回退一步,回滚代码,调整设计,重写提示词,那么就能重新生成正确。 这样设计到提示词,提示词再到代码的好处就是重构起来也特别容易,你不需要去大量手动修改代码,只要把重构的要求写成提示词,Claude Code 这样的 Agent 会很快帮你改好。 当然这样做的一个前提:就是每一次不要修改太多,不要生成太多代码,不然就可能会失控。 另一个改变就是:Review 代码和测试。 很多人没有 Review 代码的习惯,更没有测试自己代码的习惯,每次让 AI 生成代码,我都会仔细看一遍生成的结果,看代码和我期望的是不是一样的——如果我自己写,会怎么样写,它的方案是更好还是更早,更好我可以学习,也欣然接受,凑合那就这样了,不够好我就回滚调整提示词,或者追加一下要求。 测试也很重要,单元测试这种用例是要自己设计自己review的,手工测试也必不可少,尽可能让测试成本降低,比如通过命令行去测试、测试代码去测试,这样每次生成完都可以马上测试马上验证,有问题就回滚或者修复。 这样刚开始做是很不习惯的,但是当你适应后,你会喜欢这样的开发方式,结果也会更好。 顺便说一下,Swift 代码没问题的,我也用 Claude Code 写过的,质量很不错。
宝玉
7个月前
收到一位新手算法工程师的来信,咨询我: >“在 AI 时代,既然 AI 能生成高效的算法实现,那么新手该如何有效进行代码的设计和验证?” 这确实是当下新手工程师特别关心的问题。毕竟,AI 现在能轻松产出高质量的实现代码,可新人既缺乏“拆解需求”和“设计方案”的经验,又需要面对迅速变动的技术场景,难免会容易焦虑着急。 很多人会设想一种“理想状态”:我们先把需求细分成相对独立且定义明确的模块,然后把接口、数据结构、边界条件等都告诉 AI,AI 再自动完成这个模块的实现。最后,只要进行验证,就大功告成了。但现实中,别说新手,就算是已经有了几年开发经验的工程师而言,要掌握从需求到模块的拆分,再到最后测试和调优,这条链路很长,也很考验“工程能力”。 所以我对于 AI 时代的工程师的建议是:: > AI 时代,工程师仍需要掌握两大基础能力:编程技能和工程能力。 --- ** 编程技能:AI 时代仍需“做中学” 很多人会问:既然 AI 能写代码了,那我是不是就不用苦练“自己写”这件事?答案并不绝对。 - 编程是技能 就像学游泳或学骑车,如果你从头到尾都不下水,只是在岸上看视频或让别人代替你游,你自己很难真正学会。编程同理,需要动手才能真正理解和掌握。 - AI 帮你加速,但不能完全取代你的动手实践 比如,你遇到一个功能需求,不妨先自行思考一下可能的实现思路,然后让 AI 生成一个方案。接着,你可以亲手去改动、调试,甚至故意“手写一遍”看是否顺畅,或者是否能够理解 AI 生成的关键逻辑。只有这样,你才能更熟练地掌握编程能力,真正知道代码在做什么,而不只是“让 AI 代写”。 - 写得快已不再是全部目标 过去我们常常追求写代码又快又好,可是在 AI 的帮助下,“写得快”可以部分交给 AI,我们更多精力应投入到结构设计、逻辑思考、验证测试等更具价值的工作上。 --- ** 工程能力:从需求到可持续维护的系统 要想真正把需求落地成一套可运行、可维护、可演进的软件系统,工程能力就尤其关键了。它涉及到从需求分析、架构设计、实现编码、验证测试、运维部署到持续迭代的一整个流程,也可以理解为把需求变成可持续维护系统的综合能力。 试着想象一下,一个合格的(也可以说是“专业的”)工程师在日常开发中都要做些什么: 1. 需求和场景理解 - 与需求方沟通,确认数据规模、并发量、安全合规要求等,这能避免后续返工或踩坑。 2. 架构设计与技术选型 - 考虑技术栈、模块划分、API 设计等,并兼顾成本、性能、可扩展性,才能保证后面不会“撞墙”。 3. 测试与质量保证 - 包含单元测试、集成测试、端到端测试等,各类测试在不同层面保障质量。 - 通过持续集成(CI),快速发现改动对已有功能的影响。 - 新手尤其要培养“多写单元测试、用测试验证逻辑”的习惯,这对识别 AI 生成代码的缺陷非常有效。 4. 运维与监控 - 上线后如何发现错误、记录日志并快速定位问题,如何保障系统稳定运行,都需要事先规划。 5. 团队协作与项目管理 - 多人协作怎么做 Code Review?版本管理和需求排期如何安排?这些都属于工程能力的一部分,也是让团队高效协作的关键。 --- ** AI 时代下,工程能力的新挑战与机遇 虽然 AI 在编程层面突飞猛进,可以生成各种模块、自动化测试脚本,但在以下这些方面依旧需要人类发挥主导作用: 1. 掌控需求到实现的链路 - AI 只能依据你给的描述去生成实现。若需求描述和拆分不到位,AI 写出的代码很可能在后期难以集成或维护。 - 只有具备扎实的工程能力,才能确保需求、设计、实现三位一体。 2. 审阅与调试 AI 生成代码 - AI 写的实现并不总是完善,它可能忽略边界条件,也可能在性能或安全合规上欠考虑。 - 需要工程经验去审阅、调试,并结合单元测试、日志监控等手段,验证代码的正确性和鲁棒性。 3. 架构与模块拆分 - 哪些部分适合让 AI 来生成?哪些部分需资深工程师自己写? - 整个系统的版本、模块管理如何协调?在这些领域里,工程师对系统全局的把控能力非常重要。 4. 数据与安全合规 - 特别是算法工程师,常常涉及数据管线、数据隐私与合规等复杂场景。 - AI 生成一段跑模型的代码很容易,但若要兼顾隐私合规、合理负载、监控报警,就离不开工程化的思维。 --- ** 如何提升工程能力:实战中历练,持续总结 既然工程能力如此重要,该如何让自己成长得更快?以下几点建议可能对你有所帮助: 1. 多动手维护实际项目 - 读书和看文档可以打基础,但实际开发的踩坑和复盘最能帮你快速建立认知。小到个人开源项目,大到公司内部复杂系统,都能让你看到“设计-实现-测试-部署”的全流程。 2. 吸收业界最佳实践 - 去读优秀开源项目的源码,仔细观察他们如何组织目录结构、如何写测试、如何做持续集成;或者在团队里多参与 Code Review,学习他人写码和思考的方式。 3. 熟悉工具链与自动化 - 尝试了解并实践 CI/CD 流程,掌握单元测试框架、配置管理、运维监控工具等。这些在实际工程中都是必不可少的一环。 4. 主动思考架构与性能 - 无论是后端服务的分布式架构,前端的工程化,还是机器学习训练管线等,都有相应的设计模式和性能优化思路。多思考如何在逻辑与工程层面做得更好,而不是单纯依赖 AI 给出的实现。 5. 培养文档与沟通习惯 - 工程并非个人英雄主义。“写在你脑海里”的想法也需要变成清晰的文档、需求说明、接口规范、部署指南,这样不仅帮助团队,也有利于自我总结。 --- 总结一下: - 在 AI 时代,能帮我们写代码的“工具”越来越多,但“如何保证写得对”“如何把需求从无到有构建成高可维护、高可靠的系统”才是人类工程师真正的价值所在。 - 编程技能仍需“做中学”:AI 辅助写代码并不能完全替代亲自动手,不然难以真正掌握技术本质。通过实际项目增强经验:多踩坑、多总结,是积累工程思维的关键。 - 对于新手工程师,首先要在实践中不断提升编程技能,要能理解代码、能手写关键逻辑,另一方面,更要把精力放在工程能力上:需求分析、架构设计、模块拆分、测试与持续集成等。 - AI 不能替你做“架构设计与技术选型”:它只能在给定的框架内去编程,如何拆分、怎么确保安全与性能,依旧仰赖工程师的决策。 希望以上这些思路对你有所启发,也祝你能在 AI 时代下,快速成长为一名具备强大工程能力的算法工程师。加油!